[
  {
    "path": ".gitattributes",
    "content": "* linguist-vendored\n*.md linguist-vendored=false\n"
  },
  {
    "path": ".github/CIP-TEMPLATE.md",
    "content": "---\nCIP: ?\nTitle: ?\nCategory: ?\nStatus: Proposed\nAuthors:\n    - John Doe <john.doe@email.domain>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/?\nCreated: YYYY-MM-DD\nLicense: CC-BY-4.0\n---\n\n<!-- Existing categories:\n\n- Meta      | For meta-CIPs which typically serves another category or group of categories.\n- Wallets   | For standardisation across wallets (hardware, full-node or light).\n- Tokens    | About tokens (fungible or non-fungible) and minting policies in general.\n- Metadata  | For proposals around metadata (on-chain or off-chain).\n- Tools     | A broad category for ecosystem tools not falling into any other category.\n- Plutus    | Changes or additions to Plutus\n- Ledger    | For proposals regarding the Cardano ledger (including Reward Sharing Schemes)\n- Consensus | For proposals affecting implementations of the Cardano Consensus layer and algorithms\n- Network   | Specifications and implementations of Cardano's network protocols and applications\n\n-->\n\n## Abstract\n<!-- A short (\\~200 word) description of the proposed solution and the technical issue being addressed. -->\n\n## Motivation: why is this CIP necessary?\n<!-- A clear explanation that introduces the reason for a proposal, its use cases and stakeholders. If the CIP changes an established design then it must outline design issues that motivate a rework. For complex proposals, authors must write a Cardano Problem Statement (CPS) as defined in CIP-9999 and link to it as the `Motivation`. -->\n\n## Specification\n<!-- The technical specification should describe the proposed improvement in sufficient technical detail. In particular, it should provide enough information that an implementation can be performed solely on the basis of the design in the CIP. This is necessary to facilitate multiple, interoperable implementations. This must include how the CIP should be versioned, if not covered under an optional Versioning main heading. If a proposal defines structure of on-chain data it must include a CDDL schema in its specification.-->\n\n## Rationale: how does this CIP achieve its goals?\n<!-- The rationale fleshes out the specification by describing what motivated the design and what led to particular design decisions. It should describe alternate designs considered and related work. The rationale should provide evidence of consensus within the community and discuss significant objections or concerns raised during the discussion.\n\nIt must also explain how the proposal affects the backward compatibility of existing solutions when applicable. If the proposal responds to a CPS, the 'Rationale' section should explain how it addresses the CPS, and answer any questions that the CPS poses for potential solutions.\n-->\n\n## Path to Active\n\n### Acceptance Criteria\n<!-- Describes what are the acceptance criteria whereby a proposal becomes 'Active' -->\n\n<!-- For core categories (Ledger, Plutus, Network, Consensus) the following SHOULD be included:\n- [ ] Implementation present within block producing nodes used by 80%+ of stake\n-->\n\n### Implementation Plan\n<!-- A plan to meet those criteria or `N/A` if an implementation plan is not applicable. -->\n\n<!-- OPTIONAL SECTIONS: see CIP-0001 > Document > Structure table -->\n\n## Copyright\n<!-- The CIP must be explicitly licensed under acceptable copyright terms. Uncomment the license you wish to use (delete the other one) and ensure it matches the License field in the header.\n\nIf AI/LLMs were used in the creation of the copyright text, the author may choose to include a disclaimer to describe their application within the proposal.\n-->\n\n<!-- This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). -->\n<!-- This CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0). -->\n"
  },
  {
    "path": ".github/CPS-TEMPLATE.md",
    "content": "---\nCPS: ?\nTitle: ?\nCategory: ?\nStatus: Open\nAuthors:\n    - John Doe <john.doe@email.domain>\nProposed Solutions: []\nDiscussions:\n    - Original pull request: https://github.com/cardano-foundation/CIPs/pull/?\nCreated: YYYY-MM-DD\nLicense: CC-BY-4.0\n---\n\n<!-- Existing categories:\n\n- Meta      | For meta-CIPs which typically serves another category or group of categories.\n- Wallets   | For standardisation across wallets (hardware, full-node or light).\n- Tokens    | About tokens (fungible or non-fungible) and minting policies in general.\n- Metadata  | For proposals around metadata (on-chain or off-chain).\n- Tools     | A broad category for ecosystem tools not falling into any other category.\n- Plutus    | Changes or additions to Plutus\n- Ledger    | For proposals regarding the Cardano ledger (including Reward Sharing Schemes)\n- Consensus | For proposals affecting implementations of the Cardano Consensus layer and algorithms\n- Network   | Specifications and implementations of Cardano's network protocols and applications\n\n-->\n\n## Abstract\n<!-- A short (\\~200 word) description of the target goals and the technical obstacles to those goals. -->\n\n## Problem\n<!-- A more elaborate description of the problem and its context. This section should explain what motivates the writing of the CPS document. -->\n\n## Use Cases\n<!-- A concrete set of examples written from a user's perspective, describing what and why they are trying to do. When they exist, this section should give a sense of the current alternatives and highlight why they are not suitable. -->\n\n## Goals\n<!-- A list of goals and non-goals a project is pursuing, ranked by importance. These goals should help understand the design space for the solution and what the underlying project is ultimately trying to achieve.\n\nGoals may also contain requirements for the project. For example, they may include anything from a deadline to a budget (in terms of complexity or time) to security concerns.\n\nFinally, goals may also serve as evaluation metrics to assess how good a proposed solution is. -->\n\n## Open Questions\n<!-- A set of questions to which any proposed solution should find an answer. Questions should help guide solutions design by highlighting some foreseen vulnerabilities or design flaws. Solutions in the form of CIP should thereby include these questions as part of their 'Rationale' section and provide an argued answer to each. -->\n\n<!-- OPTIONAL SECTIONS: see CIP-9999 > Specification > CPS > Structure table -->\n\n## Copyright\n<!-- The CPS must be explicitly licensed under acceptable copyright terms. Uncomment the license you wish to use (delete the other one) and ensure it matches the License field in the header.\n\nIf AI/LLMs were used in the creation of the copyright text, the author may choose to include a disclaimer to describe their application within the proposal.\n-->\n\n<!-- This CPS is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). -->\n<!-- This CPS is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0). -->\n"
  },
  {
    "path": ".github/CPS-VALIDATION.md",
    "content": "# CPS Validation Rules\n\nThis document describes all validation rules applied to Cardano Problem Statement (CPS) documents.\n\nThese validations are to be ran automatically via Github workflow using [`/scripts/validate-cps.py`](./scripts/validate-cps.py).\n\nThese attempt to codify the guidance described within [CIP-9999 | Cardano Problem Statements](../CIP-9999/README.md).\n\n## File-Level Validations\n\n| Validation | Description |\n| ---------- | ----------- |\n| File path | Must be in a `CPS-*` directory |\n| Line endings | Must use UNIX line endings (LF), not Windows (CRLF) or old Mac (CR) |\n| Frontmatter | Must have valid YAML frontmatter between `---` delimiters |\n| No H1 headings | H1 (`#`) headings are not allowed in the document body |\n\n## Header Field Validations\n\nAll 9 fields are **required**,\nmust appear in order,\nand no extra fields are allowed.\n\n| Field | Order | Validation Rules |\n| ----- | ----- | ---------------- |\n| **CPS** | 1 | Positive integer (`1`, `42`) or `?`/`??`/etc. for unassigned. No leading zeros. |\n| **Title** | 2 | 1-100 characters, no backticks (`` ` ``) |\n| **Category** | 3 | One of: `Meta`, `Wallets`, `Tokens`, `Metadata`, `Tools`, `Plutus`, `Ledger`, `Consensus`, `Network`, `?` |\n| **Status** | 4 | `Open`, `Solved`, or `Inactive` (optionally with reason, e.g., `Inactive (Superseded)`) |\n| **Authors** | 5 | Non-empty list, each entry: `Name <email>` |\n| **Proposed Solutions** | 6 | List (can be empty), each entry: `Label: URL` |\n| **Discussions** | 7 | Non-empty list, each entry: `Label: URL` |\n| **Created** | 8 | Date in `YYYY-MM-DD` format |\n| **License** | 9 | `CC-BY-4.0` or `Apache-2.0` |\n\n## CIP Label Validation\n\nFor the **Proposed Solutions** and **Discussions** fields,\nwhen an entry label matches the `CIP-NNNN` pattern,\nextra validation applies:\n\n| Rule | Description |\n| ---- | ----------- |\n| GitHub URL required | Must be `https://github.com/cardano-foundation/CIPs/...` |\n| Valid URL types | `/pull/NNN` (PR) or `/tree/{branch}/CIP-NNNN` or `/blob/{branch}/CIP-NNNN` (merged) |\n| `?` suffix for PRs | `CIP-0030?` required when linking to a pull request (candidate) |\n| No `?` for merged | `CIP-0030` (without `?`) required when linking to a merged CIP |\n\nNon-CIP labels (e.g., `Forum Post`, `Pull Request`) are allowed with any valid URL.\n\n## Required Sections (H2 Headers)\n\nThe following sections must exist in this order with **exact capitalization**.\n\n**No other H2 sections are allowed** except the optional sections listed below.\n\n| Order | Section |\n| ----- | ------- |\n| 1 | `Abstract` |\n| 2 | `Problem` |\n| 3 | `Use Cases` |\n| 4 | `Goals` |\n| 5 | `Open Questions` |\n| 6 | `Copyright` |\n\n## Optional Sections\n\nThe following sections are allowed with exact capitalization.\nThey **must** appear after `Open Questions` and before `Copyright`:\n\n- `References`\n- `Appendices`\n- `Acknowledgments` / `Acknowledgements`\n\nOptional sections appearing before any required section (other than `Copyright`) will cause validation to fail.\n"
  },
  {
    "path": ".github/schemas/cps-header.schema.json",
    "content": "{\n  \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n  \"$id\": \"https://github.com/cardano-foundation/CIPs/.github/schemas/cps-header.schema.json\",\n  \"title\": \"CPS Header Schema\",\n  \"description\": \"JSON Schema for validating YAML frontmatter headers in Cardano Problem Statements (CPSs)\",\n  \"type\": \"object\",\n  \"required\": [\n    \"CPS\",\n    \"Title\",\n    \"Category\",\n    \"Status\",\n    \"Authors\",\n    \"Proposed Solutions\",\n    \"Discussions\",\n    \"Created\",\n    \"License\"\n  ],\n  \"properties\": {\n    \"CPS\": {\n      \"description\": \"The CPS number (without leading 0), or one or more '?' before number has been assigned\",\n      \"oneOf\": [\n        {\n          \"type\": \"string\",\n          \"pattern\": \"^\\\\?+$\"\n        },\n        {\n          \"type\": \"integer\",\n          \"minimum\": 1\n        },\n        {\n          \"type\": \"string\",\n          \"pattern\": \"^[1-9]\\\\d*$\"\n        }\n      ]\n    },\n    \"Title\": {\n      \"description\": \"A succinct and descriptive title. Don't use backticks (`) in titles since they disrupt formatting in other contexts. Must be less than 100 characters.\",\n      \"type\": \"string\",\n      \"minLength\": 1,\n      \"maxLength\": 100,\n      \"not\": {\n        \"pattern\": \"`\"\n      }\n    },\n    \"Category\": {\n      \"description\": \"One of the editorially accepted categories covering one area of the ecosystem\",\n      \"type\": \"string\",\n      \"enum\": [\n        \"Meta\",\n        \"Wallets\",\n        \"Tokens\",\n        \"Metadata\",\n        \"Tools\",\n        \"Plutus\",\n        \"Ledger\",\n        \"Consensus\",\n        \"Network\",\n        \"?\"\n      ]\n    },\n    \"Status\": {\n      \"description\": \"Status of the CPS: Open, Solved, or Inactive (with optional reason)\",\n      \"type\": \"string\",\n      \"pattern\": \"^(Open|Solved|Inactive(?:\\\\s+\\\\(.*\\\\))?)$\"\n    },\n    \"Authors\": {\n      \"description\": \"A list of authors' real names and email addresses (e.g. John Doe <john.doe@email.domain>)\",\n      \"type\": \"array\",\n      \"minItems\": 1,\n      \"items\": {\n        \"type\": \"string\",\n        \"pattern\": \"^.+\\\\s+<.+>$\",\n        \"description\": \"Author entry in format: Name <email@domain.com>\"\n      }\n    },\n    \"Proposed Solutions\": {\n      \"description\": \"A list of CIPs addressing the problem, if any. Can be an empty array []. Each entry is 'Label: URL'. When label is CIP-NNNN, URL must be a GitHub CIPs repo link; use '?' suffix for PRs (candidates).\",\n      \"type\": \"array\",\n      \"items\": {\n        \"oneOf\": [\n          {\n            \"type\": \"string\",\n            \"minLength\": 1,\n            \"pattern\": \"^.+:\\\\s+https?://.+$\",\n            \"description\": \"Entry in format: 'Label: URL'\"\n          },\n          {\n            \"type\": \"object\",\n            \"minProperties\": 1,\n            \"maxProperties\": 1,\n            \"additionalProperties\": {\n              \"type\": \"string\",\n              \"format\": \"uri\"\n            },\n            \"description\": \"Dictionary format: {'Label': 'URL'}\"\n          }\n        ]\n      }\n    },\n    \"Discussions\": {\n      \"description\": \"A list of links where major technical discussions regarding this CPS happened. Must include a link to the pull request that created the CPS. Each entry must have a label followed by a colon and URL. Can be a string 'Label: URL' or a dictionary {'Label': 'URL'}.\",\n      \"type\": \"array\",\n      \"minItems\": 1,\n      \"items\": {\n        \"oneOf\": [\n          {\n            \"type\": \"string\",\n            \"pattern\": \"^.+:\\\\s+https?://.+$\",\n            \"description\": \"Entry in format: 'Label: URL'\"\n          },\n          {\n            \"type\": \"object\",\n            \"minProperties\": 1,\n            \"maxProperties\": 1,\n            \"additionalProperties\": {\n              \"type\": \"string\",\n              \"format\": \"uri\"\n            },\n            \"description\": \"Dictionary format: {'Label': 'URL'}\"\n          }\n        ]\n      }\n    },\n    \"Created\": {\n      \"description\": \"Date created on, in ISO 8601 (YYYY-MM-DD) format\",\n      \"type\": \"string\",\n      \"pattern\": \"^\\\\d{4}-\\\\d{2}-\\\\d{2}$\",\n      \"format\": \"date\"\n    },\n    \"License\": {\n      \"description\": \"Abbreviation of an approved license\",\n      \"type\": \"string\",\n      \"enum\": [\n        \"CC-BY-4.0\",\n        \"Apache-2.0\"\n      ]\n    }\n  },\n  \"additionalProperties\": false\n}\n\n"
  },
  {
    "path": ".github/scripts/validate-cps.py",
    "content": "#!/usr/bin/env python3\n\"\"\"\nValidation script for CPS README.md files.\nValidates YAML headers and required sections.\n\"\"\"\n\nimport sys\nimport re\nimport json\nimport yaml\nfrom pathlib import Path\nfrom typing import Dict, List, Set, Tuple, Optional\n\ntry:\n    import jsonschema\nexcept ImportError:\n    print(\"Error: jsonschema library is required. Install it with: pip install jsonschema\", file=sys.stderr)\n    sys.exit(1)\n\n\n# Required fields for CPS headers (in required order)\nCPS_REQUIRED_FIELDS_ORDER = [\n    'CPS', 'Title', 'Category', 'Status', 'Authors',\n    'Proposed Solutions', 'Discussions', 'Created', 'License'\n]\nCPS_REQUIRED_FIELDS = set(CPS_REQUIRED_FIELDS_ORDER)\n\n# Required sections (H2 headers) in required order\nCPS_REQUIRED_SECTIONS_ORDER = [\n    'Abstract',\n    'Problem',\n    'Use Cases',\n    'Goals',\n    'Open Questions',\n    'Copyright'\n]\nCPS_REQUIRED_SECTIONS = set(CPS_REQUIRED_SECTIONS_ORDER)\n\n# Optional H2 sections (allowed but not required)\n# These should appear after the required sections, before Copyright\nCPS_OPTIONAL_SECTIONS = {\n    'References',\n    'Appendices',\n    'Acknowledgments',\n    'Acknowledgements'\n}\n\n# Load CPS header schema\nSCHEMA_PATH = Path(__file__).parent.parent / 'schemas' / 'cps-header.schema.json'\nwith open(SCHEMA_PATH, 'r', encoding='utf-8') as f:\n    CPS_HEADER_SCHEMA = json.load(f)\n\n\ndef parse_frontmatter(content: str) -> Tuple[Optional[Dict], Optional[str], Optional[List[str]]]:\n    \"\"\"Parse YAML frontmatter from markdown content.\n\n    Returns:\n        Tuple of (frontmatter_dict, remaining_content, raw_lines) or (None, content, None) if no frontmatter\n    \"\"\"\n    # Check for frontmatter delimiters - must start with ---\n    if not content.startswith('---'):\n        return None, content, None\n\n    # Find the closing delimiter (--- on its own line)\n    # Split on '\\n---\\n' or '\\n---' at end of content\n    lines = content.split('\\n')\n    if lines[0] != '---':\n        return None, content, None\n\n    # Find the closing ---\n    end_idx = None\n    for i in range(1, len(lines)):\n        if lines[i] == '---':\n            end_idx = i\n            break\n\n    if end_idx is None:\n        return None, content, None\n\n    # Extract frontmatter (lines between the two --- markers)\n    frontmatter_lines = lines[1:end_idx]\n\n    # Preprocess: quote standalone '?' values (YAML interprets '?' as explicit key indicator)\n    processed_lines = []\n    for line in frontmatter_lines:\n        # Match lines like \"CPS: ?\" or \"Category: ?\" and quote the ?\n        if re.match(r'^[A-Za-z][A-Za-z ]*:\\s+\\?+\\s*$', line):\n            line = re.sub(r':\\s+(\\?+)\\s*$', r': \"\\1\"', line)\n        processed_lines.append(line)\n\n    frontmatter_text = '\\n'.join(processed_lines)\n\n    # Extract remaining content (everything after the closing ---)\n    remaining_lines = lines[end_idx + 1:]\n    remaining_content = '\\n'.join(remaining_lines)\n\n    try:\n        frontmatter = yaml.safe_load(frontmatter_text)\n        if frontmatter is None:\n            return None, content, None\n        return frontmatter, remaining_content, frontmatter_lines\n    except yaml.YAMLError as e:\n        return None, content, None\n    except ValueError as e:\n        # Catches invalid date values that YAML tries to parse (e.g., month 13)\n        return None, content, None\n\n\ndef extract_h2_headers(content: str) -> List[str]:\n    \"\"\"Extract all H2 headers (##) from markdown content.\"\"\"\n    h2_pattern = r'^##\\s+(.+)$'\n    headers = []\n    for line in content.split('\\n'):\n        match = re.match(h2_pattern, line)\n        if match:\n            headers.append(match.group(1).strip())\n    return headers\n\n\ndef extract_h1_headers(content: str) -> List[str]:\n    \"\"\"Extract all H1 headers (#) from markdown content.\"\"\"\n    h1_pattern = r'^#\\s+(.+)$'\n    headers = []\n    for line in content.split('\\n'):\n        match = re.match(h1_pattern, line)\n        if match:\n            headers.append(match.group(1).strip())\n    return headers\n\n\ndef validate_line_endings(file_path: Path) -> List[str]:\n    \"\"\"Validate that file uses UNIX line endings (LF, not CRLF).\n    \n    Returns:\n        List of error messages (empty if valid)\n    \"\"\"\n    errors = []\n    \n    try:\n        # Read file in binary mode to check line endings\n        with open(file_path, 'rb') as f:\n            content_bytes = f.read()\n        \n        # Check for CRLF (\\r\\n) - Windows line endings\n        if b'\\r\\n' in content_bytes:\n            errors.append(\"File uses Windows line endings (CRLF). Use UNIX line endings (LF) instead.\")\n        \n        # Check for standalone \\r without \\n (old Mac line endings)\n        # Replace CRLF first, then check for remaining CR\n        content_without_crlf = content_bytes.replace(b'\\r\\n', b'')\n        if b'\\r' in content_without_crlf:\n            errors.append(\"File uses old Mac line endings (CR). Use UNIX line endings (LF) instead.\")\n    except Exception as e:\n        errors.append(f\"Error checking line endings: {e}\")\n    \n    return errors\n\n\ndef validate_no_h1_headings(content: str) -> List[str]:\n    \"\"\"Validate that no H1 headings are present in the document.\n    \n    Returns:\n        List of error messages (empty if valid)\n    \"\"\"\n    errors = []\n    \n    h1_headers = extract_h1_headers(content)\n    if h1_headers:\n        errors.append(f\"H1 headings are not allowed. Found: {', '.join(h1_headers)}\")\n    \n    return errors\n\n\ndef _validate_field_order(frontmatter: Dict) -> List[str]:\n    \"\"\"Validate that header fields appear in the correct order.\n\n    Returns:\n        List of error messages (empty if valid)\n    \"\"\"\n    errors = []\n\n    # Get the actual order of fields in the frontmatter\n    actual_fields = list(frontmatter.keys())\n\n    # Filter to only known required fields (ignore any extra fields for order check)\n    actual_required = [f for f in actual_fields if f in CPS_REQUIRED_FIELDS]\n\n    # Build expected order based on which required fields are present\n    expected_order = [f for f in CPS_REQUIRED_FIELDS_ORDER if f in actual_required]\n\n    if actual_required != expected_order:\n        errors.append(\n            f\"Header fields are not in the correct order. \"\n            f\"Expected: {', '.join(expected_order)}. \"\n            f\"Got: {', '.join(actual_required)}\"\n        )\n\n    return errors\n\n\ndef validate_header(frontmatter: Dict) -> List[str]:\n    \"\"\"Validate the YAML frontmatter header for CPSs.\n\n    Returns:\n        List of error messages (empty if valid)\n    \"\"\"\n    errors = []\n\n    # Validate field order\n    errors.extend(_validate_field_order(frontmatter))\n\n    # Validate header fields using JSON Schema\n    try:\n        # Convert date objects to strings for schema validation\n        # JSON Schema expects dates as strings, but PyYAML may parse them as date objects\n        # Also normalize dictionary entries in lists to strings (YAML parses \"Label: URL\" as dict)\n        frontmatter_for_schema = {}\n        for key, value in frontmatter.items():\n            if key == 'Created' and hasattr(value, 'isoformat'):\n                # Handle date objects from PyYAML (datetime.date or datetime.datetime)\n                frontmatter_for_schema[key] = value.isoformat()\n            elif key in ('Proposed Solutions', 'Discussions') and isinstance(value, list):\n                # Convert dictionary entries to string format \"Label: URL\"\n                normalized_list = []\n                for item in value:\n                    if isinstance(item, dict):\n                        # Convert dict like {'Label': 'URL'} to string 'Label: URL'\n                        if len(item) == 1:\n                            label, url = next(iter(item.items()))\n                            normalized_list.append(f\"{label}: {url}\")\n                        else:\n                            # Multiple keys - join them\n                            normalized_list.append(\": \".join(f\"{k}: {v}\" for k, v in item.items()))\n                    elif isinstance(item, str):\n                        normalized_list.append(item)\n                    else:\n                        normalized_list.append(str(item))\n                frontmatter_for_schema[key] = normalized_list\n            else:\n                frontmatter_for_schema[key] = value\n\n        jsonschema.validate(instance=frontmatter_for_schema, schema=CPS_HEADER_SCHEMA)\n    except jsonschema.ValidationError as e:\n        # Format JSON Schema validation errors in a user-friendly way\n        error_path = '.'.join(str(p) for p in e.path) if e.path else 'root'\n        errors.append(f\"Header validation error at '{error_path}': {e.message}\")\n    except jsonschema.SchemaError as e:\n        errors.append(f\"Schema error: {e.message}\")\n\n    # Validate CIP label semantic rules (label/URL relationship)\n    if 'Proposed Solutions' in frontmatter:\n        errors.extend(_validate_cip_label_entries(frontmatter['Proposed Solutions'], 'Proposed Solutions'))\n    if 'Discussions' in frontmatter:\n        errors.extend(_validate_cip_label_entries(frontmatter['Discussions'], 'Discussions'))\n\n    return errors\n\n\ndef _validate_cip_label_entries(entries: list, field_name: str) -> List[str]:\n    \"\"\"Validate semantic rules for entries with CIP labels.\n\n    When a label matches CIP-NNNN pattern:\n    - URL must be a GitHub CIPs repository link (PR or merged CIP)\n    - Pull request URLs require '?' suffix on the CIP number (candidate)\n    - Merged CIP URLs must NOT have '?' suffix\n\n    Other labels are allowed with any valid URL.\n\n    Args:\n        entries: List of label-URL entries\n        field_name: Name of the field for error messages\n\n    Returns:\n        List of error messages (empty if valid)\n    \"\"\"\n    errors = []\n\n    if not isinstance(entries, list):\n        return errors\n\n    cip_label_pattern = re.compile(r'^(CIP-\\d+)(\\?)?$')\n    pr_pattern = re.compile(r'https://github\\.com/cardano-foundation/CIPs/pull/\\d+')\n    merged_pattern = re.compile(r'https://github\\.com/cardano-foundation/CIPs/(tree|blob)/[^/]+/CIP-\\d+')\n    github_cips_pattern = re.compile(r'^https://github\\.com/cardano-foundation/CIPs/(pull/\\d+|tree/[^/]+/CIP-\\d+|blob/[^/]+/CIP-\\d+)')\n\n    for i, entry in enumerate(entries):\n        # Normalize to label and URL\n        if isinstance(entry, dict) and len(entry) == 1:\n            label, url = next(iter(entry.items()))\n        elif isinstance(entry, str):\n            # Parse \"Label: URL\" format\n            match = re.match(r'^([^:]+):\\s+(.+)$', entry)\n            if not match:\n                continue\n            label, url = match.groups()\n        else:\n            continue\n\n        label = label.strip()\n        url = url.strip()\n\n        # Check if label matches CIP pattern - only then apply extra validation\n        label_match = cip_label_pattern.match(label)\n        if not label_match:\n            continue  # Non-CIP labels are allowed with any URL\n\n        cip_number = label_match.group(1)\n        has_question_mark = label_match.group(2) == '?'\n\n        # For CIP labels, URL must be a GitHub CIPs repository link\n        if not github_cips_pattern.match(url):\n            errors.append(\n                f\"'{field_name}' entry {i+1}: CIP label '{label}' requires a GitHub CIPs repository URL \"\n                f\"(pull request or merged CIP). Got: {url}\"\n            )\n            continue\n\n        is_pr = pr_pattern.search(url) is not None\n        is_merged = merged_pattern.search(url) is not None\n\n        if is_pr and not has_question_mark:\n            errors.append(\n                f\"'{field_name}' entry {i+1}: Pull request URL requires '?' suffix on CIP number \"\n                f\"(use '{cip_number}?' instead of '{cip_number}' to indicate candidate status)\"\n            )\n        elif is_merged and has_question_mark:\n            errors.append(\n                f\"'{field_name}' entry {i+1}: Merged CIP should not have '?' suffix \"\n                f\"(use '{cip_number}' instead of '{cip_number}?' since this CIP is merged)\"\n            )\n\n    return errors\n\n\ndef validate_sections(content: str) -> List[str]:\n    \"\"\"Validate required sections exist at H2 level for CPSs.\n\n    Returns:\n        List of error messages (empty if valid)\n    \"\"\"\n    errors = []\n\n    h2_headers = extract_h2_headers(content)\n    found_sections = set(h2_headers)\n\n    # Normalize headers to lowercase for case-insensitive comparison\n    found_sections_lower = {h.lower() for h in found_sections}\n    required_sections_lower = {h.lower() for h in CPS_REQUIRED_SECTIONS}\n    optional_sections_lower = {h.lower() for h in CPS_OPTIONAL_SECTIONS}\n\n    # Check for missing required sections (case-insensitive)\n    missing_sections_lower = required_sections_lower - found_sections_lower\n    if missing_sections_lower:\n        # Map back to original case from required_sections for error message\n        missing_sections = {orig for orig in CPS_REQUIRED_SECTIONS\n                          if orig.lower() in missing_sections_lower}\n        errors.append(f\"Missing required sections: {', '.join(sorted(missing_sections))}\")\n\n    # Check for unknown sections (not in required or optional)\n    allowed_sections_lower = required_sections_lower | optional_sections_lower\n    for header in h2_headers:\n        if header.lower() not in allowed_sections_lower:\n            errors.append(f\"Unknown section: '{header}'. Only required and optional sections are allowed.\")\n\n    # Build a mapping from lowercase to expected capitalization\n    expected_capitalization = {}\n    for section in CPS_REQUIRED_SECTIONS:\n        expected_capitalization[section.lower()] = section\n    for section in CPS_OPTIONAL_SECTIONS:\n        expected_capitalization[section.lower()] = section\n\n    # Check for incorrect capitalization\n    for header in h2_headers:\n        header_lower = header.lower()\n        if header_lower in expected_capitalization:\n            expected = expected_capitalization[header_lower]\n            if header != expected:\n                errors.append(f\"Section '{header}' has incorrect capitalization. Expected: '{expected}'\")\n\n    # Check section order\n    # Map found headers to their canonical names (for order comparison)\n    canonical_headers = []\n    for header in h2_headers:\n        header_lower = header.lower()\n        if header_lower in expected_capitalization:\n            canonical_headers.append(expected_capitalization[header_lower])\n        else:\n            canonical_headers.append(header)  # Keep unknown headers as-is\n\n    # Extract just the required sections in the order they appear\n    found_required_order = [h for h in canonical_headers if h in CPS_REQUIRED_SECTIONS]\n\n    # Build expected order based on which required sections are present\n    expected_required_order = [s for s in CPS_REQUIRED_SECTIONS_ORDER if s in found_required_order]\n\n    if found_required_order != expected_required_order:\n        errors.append(\n            f\"Sections are not in the correct order. \"\n            f\"Expected: {', '.join(expected_required_order)}. \"\n            f\"Got: {', '.join(found_required_order)}\"\n        )\n\n    # Check that optional sections appear only between \"Open Questions\" and \"Copyright\"\n    # Optional sections must not appear before any required section except Copyright\n    optional_sections_normalized = {s.lower() for s in CPS_OPTIONAL_SECTIONS}\n    required_before_optional = [s for s in CPS_REQUIRED_SECTIONS_ORDER if s != 'Copyright']\n\n    for i, header in enumerate(canonical_headers):\n        header_lower = header.lower()\n        if header_lower in optional_sections_normalized:\n            # This is an optional section - check what comes after it\n            for j in range(i + 1, len(canonical_headers)):\n                following_header = canonical_headers[j]\n                # If a required section (other than Copyright) follows an optional section, that's an error\n                if following_header in required_before_optional:\n                    errors.append(\n                        f\"Optional section '{header}' appears before required section '{following_header}'. \"\n                        f\"Optional sections must appear after 'Open Questions' and before 'Copyright'.\"\n                    )\n                    break\n\n    return errors\n\n\ndef is_cps_file(file_path: Path) -> bool:\n    \"\"\"Check if file path indicates a CPS document.\"\"\"\n    path_str = str(file_path)\n    # Normalize path separators and check for CPS- pattern\n    # Handles both absolute (/CPS-123/) and relative (CPS-123/) paths\n    # Also handles Windows paths (CPS-123\\README.md)\n    normalized_path = path_str.replace('\\\\', '/')\n    \n    # Check for CPS- pattern (with or without leading slash)\n    return bool(re.search(r'(^|/)CPS-', normalized_path, re.IGNORECASE))\n\n\ndef validate_file(file_path: Path) -> Tuple[bool, List[str]]:\n    \"\"\"Validate a single CPS README.md file.\n    \n    Returns:\n        Tuple of (is_valid, list_of_errors)\n    \"\"\"\n    errors = []\n    \n    # Check if this is a CPS file\n    if not is_cps_file(file_path):\n        return False, [f\"File path does not indicate a CPS document: {file_path}\"]\n    \n    # Validate line endings (must check raw file bytes)\n    line_ending_errors = validate_line_endings(file_path)\n    errors.extend(line_ending_errors)\n    \n    # Read file content\n    try:\n        content = file_path.read_text(encoding='utf-8')\n    except Exception as e:\n        return False, [f\"Error reading file: {e}\"]\n    \n    # Parse frontmatter\n    frontmatter, remaining_content, raw_lines = parse_frontmatter(content)\n    if frontmatter is None:\n        errors.append(\"Missing or invalid YAML frontmatter (must start with '---' and end with '---')\")\n        return False, errors\n\n    # Check for leading zeros in CPS field (YAML loses this information)\n    if raw_lines:\n        for line in raw_lines:\n            if re.match(r'^CPS:\\s+0\\d+', line):\n                errors.append(\"CPS number must not have leading zeros\")\n                break\n\n    # Validate header\n    header_errors = validate_header(frontmatter)\n    errors.extend(header_errors)\n    \n    # Validate no H1 headings\n    h1_errors = validate_no_h1_headings(remaining_content)\n    errors.extend(h1_errors)\n    \n    # Validate sections\n    section_errors = validate_sections(remaining_content)\n    errors.extend(section_errors)\n    \n    is_valid = len(errors) == 0\n    return is_valid, errors\n\n\ndef main():\n    \"\"\"Main entry point for the validation script.\"\"\"\n    if len(sys.argv) < 2:\n        print(\"Usage: validate-cps.py <file1> [file2] ...\", file=sys.stderr)\n        sys.exit(1)\n    \n    files_to_validate = [Path(f) for f in sys.argv[1:]]\n    all_valid = True\n    all_errors = []\n    \n    for file_path in files_to_validate:\n        if not file_path.exists():\n            print(f\"Error: File not found: {file_path}\", file=sys.stderr)\n            all_valid = False\n            continue\n        \n        is_valid, errors = validate_file(file_path)\n        \n        if not is_valid:\n            all_valid = False\n            print(f\"\\nValidation failed for {file_path}:\", file=sys.stderr)\n            for error in errors:\n                print(f\"  - {error}\", file=sys.stderr)\n            all_errors.append((file_path, errors))\n    \n    if not all_valid:\n        print(f\"\\nValidation failed for {len(all_errors)} file(s)\", file=sys.stderr)\n        sys.exit(1)\n    \n    print(f\"\\nAll {len(files_to_validate)} file(s) passed validation\", file=sys.stderr)\n    sys.exit(0)\n\n\nif __name__ == '__main__':\n    main()\n\n"
  },
  {
    "path": ".github/workflows/cip10-validation.yaml",
    "content": "name: CIP-10 - Validate Registry JSON on Pull Request\n\non:\n  pull_request:\n    paths:\n      - 'CIP-0010/registry.json'\n\njobs:\n  approve: # Pre-approval step\n    runs-on: ubuntu-latest\n    steps:\n    - name: Approve\n      run: echo For security reasons, all pull requests need to be approved first before running any automated CI.\n\n  validate-json:\n    runs-on: ubuntu-latest\n    steps:\n    - name: Checkout repository\n      uses: actions/checkout@v3\n\n    - name: Set up Node.js\n      uses: actions/setup-node@v3\n      with:\n        node-version: '21'\n\n    - name: Install dependencies\n      run: npm install ajv-cli\n\n    - name: Validate JSON against schema\n      run: npx ajv validate -s CIP-0010/registry.schema.json -d CIP-0010/registry.json  > /dev/null"
  },
  {
    "path": ".github/workflows/cps-validation.yaml",
    "content": "name: CPS Validation\n\non:\n  pull_request:\n    paths:\n      - 'CPS*/README.md'\n      - 'cps*/README.md'\n  workflow_dispatch:\n    inputs:\n      pr_number:\n        description: 'PR number to validate'\n        required: true\n        type: string\n\njobs:\n  validate:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout repository\n        uses: actions/checkout@v4\n        with:\n          fetch-depth: 0\n\n      - name: Fetch PR branch\n        if: github.event_name == 'workflow_dispatch'\n        run: |\n          git fetch origin pull/${{ github.event.inputs.pr_number }}/head:pr-branch\n          git checkout pr-branch\n\n      - name: Set up Python\n        uses: actions/setup-python@v5\n        with:\n          python-version: '3.11'\n\n      - name: Install dependencies\n        run: |\n          pip install pyyaml jsonschema\n\n      - name: Get CPS files to validate\n        id: get-files\n        run: |\n          if [ \"${{ github.event_name }}\" = \"workflow_dispatch\" ]; then\n            # Manual run: diff PR branch against master\n            FILES=$(git diff --name-only --diff-filter=ACMR origin/master...HEAD | grep -iE '^CPS-[^/]+/README\\.md$' || true)\n          else\n            # PR trigger: diff against base branch\n            FILES=$(git diff --name-only --diff-filter=ACMR HEAD~1 HEAD | grep -iE '^CPS-[^/]+/README\\.md$' || true)\n          fi\n\n          if [ -z \"$FILES\" ]; then\n            echo \"No CPS README.md files to validate\"\n            echo \"has_files=false\" >> $GITHUB_OUTPUT\n            exit 0\n          fi\n\n          # Convert newlines to spaces for passing as arguments\n          FILES_SPACE=$(echo \"$FILES\" | tr '\\n' ' ')\n          echo \"has_files=true\" >> $GITHUB_OUTPUT\n          echo \"files=$FILES_SPACE\" >> $GITHUB_OUTPUT\n\n      - name: Validate CPS files\n        if: steps.get-files.outputs.has_files == 'true'\n        run: |\n          FILES=\"${{ steps.get-files.outputs.files }}\"\n          echo \"Validating CPS files: $FILES\"\n          python3 .github/scripts/validate-cps.py $FILES\n"
  },
  {
    "path": "BiweeklyMeetings/2020-07-01.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [July 1 2020 notes](#july-1-2020-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n  * [Review](#review)\n    + [CIP2](#cip2)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 7/1/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>\n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n\n\n## July 1 2020 notes\n\n\n**Attending**: (Duncan, Sebastien, Frederic, Matthias) \n\n\n\n### Triage\n- Nothing to review yet!\n### Last Check\n=> **Action**: - merge PR (CIP1 copy tweak)\n### Review\n#### CIP2 \n> (Discussions already took place in that PR comments!)  \n> A few items to change for the current CIP2 PR   \n> Missing the fee - Description is wrong… Should the termination condition incorporate the idea that some inputs might be too small to spend? Or should it be part of the available  condition UTXO or Ignored (a choice) \nAdd a query about if the algorithm is clear in presence of a min UTXO output.. (was it considered for Byron?)\n> Possibly: remove “for Cardano” from the title  \n\n\n\n### Discussions\n- Side conversations for how the Wallet work for Shelley key derivations (currently on the Adrestia user guide, might be worth moving to the CIP).   \n- Other Qs regarding transaction Metadata (format allows for wide-range)...  \n- (could/should be freeform?)   \n- Describe a way of versioning metadata?   \n- Need some agreement on namespace else it might lead to confusion.  \n- CIP notes should be merged in post meeting in the CIP Repo - will be fleshed out in the coming week.  \n\n\n### Close\n- CIP1 Copy tweak PR - to merge asap.  \n- “Coin Selection Algorithms” PR agreed on, to be merged in as CIP2 ‘Draft’ if no issues next meeting (7/15)  \n- Meeting notes (these) to be added to the CIP repo itself for visibility on process.  \n\n\n(Close) \n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status \n\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n\n\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram\n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n\n\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n"
  },
  {
    "path": "BiweeklyMeetings/2020-07-15.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [July 15 2020 notes](#july-15-2020-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n  * [Review](#review)\n    + [CIP5](#cip5)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 7/15/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>\n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n\n\n## July 15 2020 notes\n\n\n**Attending**: (Duncan, Sebastien, Frederic, ~~Matthias~~) + Eystein (guest)\n\n\n\n### Triage\n- Still issues with the multi-review. \n- Need to add meeting notes to the repo.\n- Merge pr (copy tweak on CIP1). \n### Last Check\n=> **Action**: - merge pr (CIP2 - “Coin Selection” - DRAFT) \n### Review\n#### CIP5 \n>**Sebastian** - Happy with all.  \nNeed to resolve that Cardano Wallet and possibly CLI uses this list, but Haskell-Shelley Rust codebase doesn’t use this, and uses diff prefixes… and this should be the main issue there. I would have to go in there and fix the prefixes themselves.  \n>**D**: Reviewing the prefixes right now.  \n>**S**: We have diff prefixes for mainnet and testnet. Which is duplicating the header payload.  \n>**D**: It duplicates it but in an error checking way. If you need to render… The bit in the payload tells you that. And if mismatch, then you can address. In some sense, it duplicates and makes it visible to the user that they are dealing with a testnet address.  \n>**Eystein** - would be good to have multiple iteration prefixes per testnet  \n>**D**-> poor form - distinguishing is broken down. Addr is to prevent people from spending real money to testnet .. You don’t have that problem from testnet to testnet.  \n>**S**: “Diff addr type in Shelley” Vs. Jormungandr. The concern is that diff address types might be confusing to ppl. So for Daedalus and Yoroi we decided to only support grp addresses.\nFor Haskell-Shelley, we will have the same issue - so most likely those other addr. types will be hidden behind some flags of sorts.   \n>**D**: That’ll likely be up to the wallet itself to figure out which type to use.   \n>**E**: I don’t care if automated - I can see a usecase for both…  \n>**D**: The distinction between the internal addr struct is just not important to regular users. It’s probably more confusing to highlight those as 10 different combinations.. Of staking, base, ptr… \nAll of these can be by key or by script. Do we want to distinguish clearly? Is that helpful? Can it be actively un-helpful?\nBecause in the end they are all payment addresses.   \n>**S**: I think that would be a mess with users. I am more about enterprise vs. base. Because they all in a sense have their own chain - BIP44 sense? If you generate your addr for a single key. … this has to be displayed differently.   \n(..)   \n>**D**: Privacy in a wallet is the same as BTC or ETC - Under Matthias / Sebastien scheme, it’s easy to see they belong together. You only get privacy at the wallet account level.\n3 ways a pmt addr can refer to a stake. And therefore have stake or not:  \nNull (short)  \nPtr (short)    \nBase (long)  \n>**S**: Since all generated, the wallet will have to render … you’d have diff pages. Ex - a page for external addr page. Would need a way to toggle the rendering - to switch between base and ptr.  \n>**D**: There should be a default - it would never as standard mode for users do null staking..  \n>**S**: after the initial release the wallet would show default release.  \n>**D**: Wallet should not confuse users by presenting too many options… If easier to display short addr, should be simplified.  \n>**D**: It’s a disc to have with Matthias - for Seb. (+Darko)  \nShould we lump all Txs under one prefix?   \n>**S** - I am not yet convinced about the addr prefix. But not concerned.   \n>**D**: You don’t have to add the addr. if the wallet takes care of it for you.  \n>**S**: Every addr. in Yoroi could display what type it is… would deal with the combinations. Screen space was dedicated for that but could be freed if bech32 impl.   \n>**D**: Not majorly important.   \n\n### Discussions\n- Pool operators are thinking about a “Standardizing” CIP. \n- Opening up meetings visibility to the public.\n- Internal requests to consider CIP exploration re: Address management (for 100ks of i.e. exchanges). \n- Eystein as first guest - Reinvite an option to connect with community (Want to carefully open up meetings to public… at first 1-2 spots, later more). \n_Eystein had a good talk he did at the Cardano Summit in July - he understands governance / the need for CIPs._ \n\n### Close\n- **CIP5** as Draft OK to merge - will be iterated on.\n- **CIP2** Merged delayed till next meeting to round up last Qs.\n\n(missing - current minor PR qs - ex: where and how to store meeting notes) \n(Close) \n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status \n\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n\n\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram\n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n\n\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n"
  },
  {
    "path": "BiweeklyMeetings/2020-08-04.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [Aug 4 2020 notes](#august-4-2020-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n  * [Review](#review)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 8/4/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>\n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n\n\n## Aug 4 2020 notes\n\n\n**Attending**: (Duncan, Frederic, ~~Matthias~~, ~~Sebastien~~) + Ben (CF)\n\n\n\n### Triage\n- Merge pr (copy tweak on CIP1)   \n\n### Last Check\n- Merge CIP2 (Draft)   \n- Merge CIP5 (Draft)   \n\n### Review  \nN/A  \n### Discussions\n*(short discussion centered around new PRs - from the past two weeks - that should move forward as 'Draft' - we shouldn't be trying to have perfect PRs, rather enable reworking as 'Draft')* \n- Setup a CIP for protocol parameters (Ask Romain? Kevin / Alex) \n- Review Meeting #2 notes in next meeting to continue threads\n- Need to upload some version of the notes in the CIP repository for visibility\n- should CIP 2&5 add License file and readme? \n\n### Close\n- **CIP1** copy tweaks merged\n- **CIP2** merged as 'Draft'\n- **CIP5** merged as 'Draft'\n\n(Close) \n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status \n\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram\n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n\n\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n"
  },
  {
    "path": "BiweeklyMeetings/2020-08-11.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [August 11 2020 notes](#-11-2020-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n  * [Review](#review)\n      + [CIP5](#cip5)\n      + [CIP4](#cip4)\n      + [CIP3](#cip3)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 8/11/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>\n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n\n\n## August 11 2020 notes\n\n\n**Attending**: (~~Duncan~~, Frederic, Matthias, Sebastien) + Ben (CF)\n\n\n\n### Triage\nN/A\n\n### Last Check\nN/A\n\n### Review  \n#### CIP5\n> **Matthias** - Needs to be finalized a bit more to be moved to “Proposed”. The internals of addresses are not really relevant for users. I don’t see why having diff. prefixes would help. Except for Advanced users.  \n> **M** - It actually *could* go to “Proposed” right now  - it doesn’t prevent us from doing updates. The set of problems we are working on is changing, so having revisions on CIP makes sense. The issue of updating a CIP beyond a final setup would be done through an update.   \n> **Sebastien** - it would be nice to have a separate prefix for others… We can modify stuff after once that is settled… and that is fine as we will have to change things.   \n\n#### CIP4\n> **S** - Needs test vectors - should be quick. The Wallet checksum should be merged, it just got shipped.\nIn CIP4 there are 2 versions - the Shelley Account is using the new format - everything is working - we have a javascript inmplemetation. We are hopefully going to release as Yoroi extension. Would be nice to have it merged. My understanding is that both teams are fine - it makes more sense, it’s more secure - it’s a bit more complicated.  \n> **M** - I see you changed a lot more since I looked at it - will try to review it and move forward.  \n> **S** - That CIP will also be used by Ergo - it will be a multichain standard functionally (used by Ergo).   \n> **S** - I have a few examples in Emurgo test library - I don’t have the pictures… hope that’s ok.   \n#### CIP3\n> Still need more work before merging into Draft.\n\n### Discussions \n1. **M** - Change the README to the CIPx file… (change CIP1 content to reflect the structure) -> **Frederic**  \n2. Proper License files needed for CIP5 & CIP2 -> **M**  \n3. Some Stake pool operators think CIPs are a bit too complex - tried to convince Markus to write up a CIP to no avail... This seems like another way of not being heard. So StakePools wrote their own version. Some community members feel this isn’t fair… It might be good to push into a CIP? CIP engagement is still a bit too Silo’d  -  process could be *more* open. Would need someone in the community to “engage”. We could upload videos or notes in a more public way.  \n4. **M** - If ppl don’t want to write CIPs we can’t really force them. Since this is coming from the CF/IOHK/Emurgo - it frightens a bit the community. Having ppl from the community involved as CIP Editors might help?  \n5. **Ben** - (Different possible flows for CIP Editorship, to be continued next meeting)  \n\n### Close\n**TODO** Add license files to CIP5 & CIP2 (**Matthias**)  \n**TODO** Change Format of CIPs (in CIP 1) to have the structures of CIPs change to readme.md (instead CIPx.md) (**Frederic**)  \n(Close) \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status \n\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram\n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n\n\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n"
  },
  {
    "path": "BiweeklyMeetings/2020-08-25.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [August 25 2020 notes](#august-25-2020-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n  * [Review](#review)\n      + [CIP2](#cip2)\n      + [CIP5](#cip5)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 8/25/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>\n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n\n\n## August 25 2020 notes\n\n\n**Attending**: (Duncan, Frederic, Matthias, ~~Sebastien~~) + Ben (CF)\n\n\n\n### Triage\nN/A\n\n### Last Check\nMerging in meeting notes to publicize the process itself\n\n### Review  \n#### CIP2\n> **Matthias** - This is a lengthy CIP and will benefit from a more thorough review. \n\n#### CIP5\n> Discussion around currencies. Cardano does multi-asset by having a bundle. Address and tokens two separate entities.  \n**Matthias** propose to remove addr in prefixes to keep consistency. Remove reference.  \n**Duncan** will get rid of addr_bootstrap because it's confusing (can render a Byron address bip32 style). \n\n\n\n### Discussions \n1. **Frederic** brings up CIP stake pool meta-data concerns in the community. A discussion over badges for ITN pools, a CIP could be written? Just because a CIP is 'Active' doesn't mean implemented.  \n2. **F** suggests prioritizing community PRs towards 'Draft' to exemplify community ideas make it through. Ex: \"Extended Metadata\" [PR](https://github.com/cardano-foundation/CIPs/pull/15/files).  \n3. **D**  (discussing back and forth with SMASH server) mentions the metadata isn't on-chain or at least no link back to on-chain except through the URL.\n4. **M**: For CIP structure, would prefer moving to only using the 'Readme.md' file and cutting the 'Cip#.md' file.  \n**F**: Aligned - some delays might come due to auto-generated site. \n**M**: Not a blocker. Github keeps track of all.\n\n### Close\n**TODO** Invite community members to upcoming meeting (**Frederic**)  \n**On Hold** Change Format of CIPs (in CIP 1) (instead CIPx.md)  \n**TODO** Probe IOG for promised parameter CIP (**Frederic**)  \n(Close) \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status \n\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram\n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n\n\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n"
  },
  {
    "path": "BiweeklyMeetings/2020-09-08.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [September 08 2020 notes](#september-08-2020-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n  * [Review](#review)\n      + [Extended Metadata](#Extended-Metadata)\n      + [Curve Pledge Benefit](#Curve-Pledge-Benefit)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\nRough writeup of 9/8/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n## September 08 2020 notes\n**Attending**: (Duncan, Frederic, ~Matthias~, Sebastien) + Steve(CF) + Shawn, Markus, Mike (PR Authors) \n\n### Triage\nN/A\n\n### Last Check\nN/A \n\n### Review  \n\n#### Extended Metadata\n([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)\n\n#### Curve Pledge Benefit\n([PR](https://github.com/cardano-foundation/CIPs/pull/12) - potential CIP7) \n\n### Discussions \nN/A - not enough time due to extended reviews.  \n\n### Close\n**On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md) - awaiting Frontend fix to auto-gen site  \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status \n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram\n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n\n\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2020-09-22.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [September 22 2020 notes](#september-22-2020-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n  * [Review](#review)\n      + [Curve Pledge Benefit](#Curve-Pledge-Benefit)\n      + [Extended Metadata](#Extended-Metadata)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 9/22/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>\n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n\n\n## September 22 2020 notes\n\n\n**Attending**: (Duncan, Frederic, Matthias, Sebastien) + Jeremy(CF) + Shawn, Markus (PR Authors) + Collin (IOG)\n\n\n### Triage\nN/A\n\n### Last Check\nN/A \n\n### Review  \n\n\n#### Curve Pledge Benefit\n([PR](https://github.com/cardano-foundation/CIPs/pull/12) - potential CIP7) \n\n\n\n**Shawn** - (recap) Current pledging incentive mechanism linear setup is less than optimal for <1M ada. The superwhale end of the spectrum provides about 30% benefit for ppl able to pledge their own pool to saturation - By using a curve pledge mechanism instead of a linear one we can incentivise in a better way (for smaller folks/pools).\n(see graphs in the PR)  \n**Duncan** - Not as simple, incentive folks are exploring all scenarios  \n**Collin** - We don’t want for the high end to be the clear winner.I like the form of the solution - almost a smile shape. Not aligned with all but a solid proposal as-is.  \n**Duncan** - This has been raised internally with IOHK researchers already - they weren’t so positive about it, but have been looking at it.  \n**Colin** - They are in the long term equilibrium - but right now the linear isn’t working.  \n**Duncan** - It was mentioned it should probably be skewed in the opposite direction..  \n**Colin** - if you can get the delegation bonus as a big holder, you’re much better off splitting into tiny pools right now  \n**Duncan** - Researchers are aware of that -  which direction it goes non-linear might cause issues.  \nAt no point should it be non-rewarding to add more stake to your pool.  \n**Markus** - What about a ‘S’ curve mentioned by Charles?  \n**Colin** - (Showing example graph) = M * (1/p)  + N * p  \n**Markus** - There are some good points or reasons that this can help  \nWhat are the drawbacks or downsides based on a linear and non-linear approach?  \n**Frederic** - The conversation about the solution can take place once the CIP has been setup as Draft, suggest we move to merge the PR and let conversation take place beyond.  \n***[Move to MERGE as CIP7]*** (all agree)\n\n\n\n#### Extended Metadata\n([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)\n\n\n**Markus** - Recap on the conversation since last meeting: \nLast week Shawn gave some good proposals about a more standardized and well-thought structure for extended metadata.Need a response from ADA Pools as they implemented something without following the Script process.  \n**Duncan** - Is there the right balance of features to include? You can try to get consensus amongst operators. Mechanism is important to consider, the other attributes can be decided at a later state.  \n**Markus** - We reconsider the maximum size of the metadata file. All other things which are not very crucial, going out quick and sending messages to SPOs can be done in a different way. A potential Metadata proposal should  involve security risks considerations, not just adding  fields.  \n**Duncan** - Reasonable to say we can add a few extra fields for metadata and limit the total data size to 1,000 bytes... If security is important, we could have a design Field extended with a URL, have a verification key (public key) which is signed for extended metadata. This means you don’t have to use the same key as your pool code key...  \n**Markus** - Need to speak with more pool operators to see the approaches out there. I Will reach out and follow up.  \n**Frederic** - Might be good to have competing views and discuss publicly, Multiple CIPs can propose different implementation proposals.  \n**Markus** - Some pools have large teams and need metadata. “Cardano Scan” does a good job but is not known. Yoroi and Daedalus have uses of course too.  \n**Duncan**- Frontend Daedalus Devs might be concerned about showing metadata when there is a security concern. RSS feed is a good example of a feature in the extended markdown  \n**Sebastien** - The pool selection UI is outsourced for Yoroi. One feature we do care about is RSS feed, we would embed this into the UI. The existing proposal doesn't really talk about RSS feed into extended metadata.  \n**Matthias** - Re: Daedalus frontend considerations - hard to say, there is a need for the data. Onchain there is not a limit of data. It's enforced by the software (SMASH). we can increase this.  \nCan show the hash is on chain, there is a security risk and no way to verify you are looking at the right data. Having a key and hashing that the data is accurate is a good way.  \n**Duncan** - If there is a key in the first MD level to sign the second MD level, this is a good mechanism. You could use HTTPS, could have a fingerprint of the hashed certificate, cant be replaced by any other certificates.  \n**Markus** - Will look at rewriting the existing PR with assistance of ADApools and reframe/rework proposal next.  \n**Frederic** - Can be discussed in comments of the CIP as draft maybe? (would like to bring it in)  \n**Duncan** - People should discuss with others in the community (or IOHK).To Markus' rework: focus on security for feedback on Metadata standardization in the first version. Once there is a mechanism and two categories (Convenient and UnConvenient).  \nFocus on mechanism, security towards minimum amount of metadata to prevent issues.  \nFollow the JSON schema and explanation of each field. BIP44 or BIP32 has a template for similar extensions.  \nFuture CIPs might want to add additional Metadata fields and should be structured in this way… it’ll provide a template for future discussions.  \n**Frederic** - Wrapping up on the meeting: Review ‘CIP6’ in 2 weeks.  \n‘Merge of CIP7’ once Legal ok.  \nMarkus to talk to the community about security and minimal metadata...  \n**Sebastien** - CIP4 PR can likely be merged in/ a draft, should it merged? We brought it up in the past + it has been implemented in Yoroi already..  \n\n### Discussions \nN/A - not enough time due to extended reviews.  \nCIP4 to be looked at in async channels and moved to next meeting.\n\n\n### Close\n\n**On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md) - awaiting Frontend fix to auto-gen site  \n**TODO**  Merge Curve proposal / ‘CIP7’ once legal oks.\n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status \n\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram\n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n\n\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2020-10-06.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [October 06 2020 notes](#october-06-2020-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n      + [Extended Metadata](#Extended-Metadata)\n      + [Curve Pledge Benefit](#Curve-Pledge-Benefit)\n  * [Review](#review)\n      + [Wallet Checksums](#Wallet-Checksums)\n      + [Message Signing](#Message-Signing)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 10/6/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>\n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n\n\n## October 06 2020 notes\n\n\n**Attending**: (Duncan, Frederic, Matthias, Sebastien) + Jeremy (CF) + Shawn (PR Author) + Nick (Community) \n\n\n### Triage\nN/A\n\n### Last Check  \n\n#### Extended Metadata\n([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)   \n\n**Frederic** - “Extended Metadata” has been awaiting the result of conversations with major stakepool operators led by Markus, while Mike wanted to incorporate suggestions from Shawn. No activity since last meeting on the PR. Recommendation is to merge as a draft as discussed last meeting to start/enable the discussion.  \n**Sebastien** - Let’s wait another two weeks for the changes/comments that were expected in the PR to proceed.\n\n\n#### Curve Pledge Benefit\n([PR](https://github.com/cardano-foundation/CIPs/pull/12)  - potential CIP7) \n\n**Sebastien** - Still not sure if the proposal' incentives are fully sound but that’s for analysts to discuss.  \n**Matthias/Shawn** - Last CIP Editors meeting we agreed to merge it as a draft, pending some legal clarifications.  \n**Sebastien** - Can be merged as a draft. As formatting goes, ok to merge to advance the conversation.  \n**Frederic** - Still no word from legal, but Shawn agreed to remove copyright as Draft and amend the PR while unclear, ok to move as draft as-is and modify.\n\n### Review  \n\n\n\n\n\n\n\n\n\n\n\n\n#### Wallet Checksums  \n([PR](https://github.com/cardano-foundation/CIPs/pull/4) - potential CIP4) \n\n**Sebastien** - Yoroi extension and Yoroi wallet have already implemented a Wallet Checksum. Maps public keys to a picture and text block: People have often entered the wrong recovery phase numerous times, so the checksum means we receive less complaints (for user errors). This is ready to merge as draft I think. \n\n\n#### Message Signing  \n([PR](https://github.com/cardano-foundation/CIPs/pull/27) - potential CIP8) \n\n**Sebastien** - When you send a transaction you functionally prove you own the tokens via signing. You should therefore be able to prove any statement, not limited to tokens. \nThis is a specification of how to bundle together data (a message) and proof (signature) for a transaction. Agreed format for Yoroi and Daedalus, useful for off chain components. \nThe proposed format for how to structure the message is based on COSE, restricting/simplifying a bit the functionalities so it’s easier to use: COSE is a bit too complex for wallets to have a full implementation? The objective is to only support the algorithms that we are interested in using with Cardano. Here, you can submit headers as part of the message. In this specification many of the headers have been excluded. \nNeed to check if this approach can be used for Daedalus wallet.\n**Duncan** - May have internal IOHK auditors to review, 2-3 weeks needed for review. \n\n\n### Discussions \n**Shawn** - What is the process for items to be put on the CIP Editors meeting agenda?  \n**Duncan** - Any relevant items, depending on capacity - easiest way is reach out to the Editors or flag it in Github.  \n(Discussion re: Pool ranking .. needs to be improved)\n\n\n\n\n### Close\n \n**On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md)  \n“Curve proposal” (‘CIP7’) to be merged as ‘Draft’, legal tweaks to follow.  \n“Extended Metadata” (‘CIP6’) flagged for comments and updates next two week.  \n“Wallet Checksum” (‘CIP4’) to be merged as ‘Draft’ in 2 weeks. \n\n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status \n\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram\n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n\n\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2020-10-20.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [October 20 2020 notes](#october-20-2020-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n      + [Extended Metadata](#Extended-Metadata)\n      + [Wallet Checksums](#Wallet-Checksums)\n  * [Review](#review)\n      + [Message Signing](#Message-Signing)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 10/20/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>\n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n\n\n## October 20 2020 notes\n\n\n**Attending**: (Duncan, Frederic, Matthias, Sebastien) + Ben (IO)\n\n\n### Triage\nN/A\n\n### Last Check  \n\n#### Extended Metadata  \n([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)   \n\n**Frederic** “Extended Metadata” has there been updates? Appears this is still on hold -  let's wait another two weeks, authors were absent and outreach for info needed.  \n**Duncan** We should open it up to more people: maybe someone else might want to take it over?Let's not push it if there isn't interest.  \n**Sebastien** We're waiting for info on explorers.  \n**Duncan** As long as the authors are still engaged, that's fine.  \n**Sebastien** ADApools is the one who setup an extended metadata format (the format the CIP is based on): we wanted their feedback on this proposal.  \n**Frederic** Will Follow on. Ping them directly or invite them + authors.  \n=> **On Hold**  \n\n\n#### Wallet Checksum  \n([PR](https://github.com/cardano-foundation/CIPs/pull/4)  - potential CIP4)  \n\n**Frederic** all good to go - (no objections).   \n\n\n\n### Review  \n\n#### Message Signing  \n([PR](https://github.com/cardano-foundation/CIPs/pull/27) - potential CIP8)  \n**Duncan** Good feedback from IOG.   \n**Sebastien** Voltaire voting is coming up, I would like for it to be merged now (as it was discussed on the last call).  \n**Frederic** We're working in the context of \"CIPs are a set of tools that implementers can pick and choose as they want\" and it seems IOG might consider CIP to be canon for the main protocol.. CH brought up CRCs (\"Cardano Request for Comments\" - open discussion towards Cardano standards) - we touched to those in the past and at the time we agreed on proceeding with CIPs being non-restrictive.  \n**Duncan** All things being equal, it's preferable to have one general guideline rather than three because of interoperability. Mild preference for a single standard for message signing. We lightly discussed merging this now last meeting, let's proceed.  \n=> **MERGING** now\n\n\n\n\n### Discussions \n\n**Duncan** Suggest we move CIP5 into \"Proposed\" state, and require details of the plan while it's in \"Proposed\" state?  \n**Frederic** \"Proposed\" must have defined metrics of acceptance/plan to Active.  \n**Frederic**  Propose we keep every 10 meetings as small (agreement). Propose we try out Crowdcast for next meeting. Need a Pr to fix numbering issues and links.   \n**Duncan** We also need a better chart or table at top-level: a readme would be helpful...  \n**Frederic** the (CIP auto gen site) is being managed by IOG; slow to get issues fixed unfortunately \n\n\n\n\n### Close\n \n**On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md)  \n**ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup  \n**ON Hold** [“Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (potential ‘CIP6’) re: comments and updates  \n=> Merge **NOW**: [“Wallet Checksum”](https://github.com/cardano-foundation/CIPs/pull/4) to be merged as ‘Draft’ (‘CIP4’)  \n=> Merge **NOW**: [“Message Signing”](https://github.com/cardano-foundation/CIPs/pull/27)to be merged as ‘Draft’ (‘CIP8’)   \n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status \n\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram\n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n\n\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2020-11-03.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [November 3 2020 notes](#november-3-2020-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n  * [Review](#review)\n      + [Extended Metadata](#Extended-Metadata)\n      + [Wallet key generation](#Wallet-key-generation)\n      + [HD Wallet for Cardano](#HD-Wallet-for-Cardano)\n      + [Transaction Metadata Registry](#Transaction-Metadata-Registry)\n      + [Cardano URI Scheme](#Cardano-URI-Scheme)\n      + [ Treasury Fraction on actual distributed rewards](#Treasury-Fraction-on-actual-distributed-rewards)            \n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 11/3/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>\n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n\n\n## November 3 2020 notes  \n**Attending**: (Duncan, Frederic, Matthias, Sebastien) + Ben (IO) + Markus (community)\n\n### Triage  \nN/A\n\n### Last Check  \nN/A\n\n### Review  \n\n#### Extended Metadata  \n([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)   \n**F** - Last we looked at this CIP, the ask was for comments/feedback from major pools. Cardanians replied two weeks ago.   \n**S** - Some parts we're still unsure re: security model - the RSS feel might not have been fully thought through. I think issues might have been addressed since.  \n**M** - sorry was busy past month. I have some tech Q: what do we need to do with what is already existing from the CLI to generate an additional key? That key could be generated so the extended metadata can be verified, so Yoroi/Daedalus can accept the metadata.  \n**D** - Are you talking about a first level metadata contains a keyhash and a URL (to the secondary metadata level)?  \n**M** - Yes, to be more flexible for the 2nd level: no codekey to update the (2nd level) extended metadata but with some hash or verification mechanism. So that means another key should be generated (am against too many hashes onchain).  \n**D** - We extend the first/primary level metadata with two extra fields: One is the PubKeyhash (that will be used to sign the 2nd level metadata) and the URL of where to find the 2nd level MD. The 2nd level MD is found at URL, and there is some signature that accompanies it (signed/verifiable against 1st lvl keyhash). If that is the case, you can change the 2nd level metadata without re-registering the pool. And also update the 1st level metadata without having to change the key for the 2nd level metadata.  \n**M** - Right now we have a hash onchain of the prime metadata. I want to summarize fields so the proposal can start with \"the minimum metadata\". What I mean to summarize is that this CIP should contain a proposal for what \"future extended metadata should look like\" and I need your feedback on key types to use etc.  \n**D** - Ordinary ed25519 key is the simplest thing to do.  \n**M** - Need more time from Mike also - and need some feedback from other groups to weigh in - there wasn't much feedback unfortunately. This is a fairly easy and non-technical CIP.  \n**D** - Focus on the details of the mechanism, but also what the exact format of the witness/signature.  \n**M** - I'll try it out and seek your feedback in the PR through comments.  \n**Matthias** - For signature, go with simplest: if that's embedded, or on the side.. We don't want to complicate things.  \n**M** - From operative pt of view, if SPO wants to integrate, it should be straightforward.  \n**D** - Two files ok?   \n**M** - yes - because when ext-metadata file is updated then would need to do other file (signature).   \n**D** - The CLI would validate the json and generate the signature for you... But still two files you host.  \n**M** - Yes, some external tool / CMS whatever SPO has, can generate the new extended metadata file and you send it to the CLI, which creates the signature of the new extended metadata file. Probably need two URL fields in 1st level. Mike's feedback originally was that he didn't want to update base URL in .json.  \n**D** - ok maybe two URL.  \n=> On Hold, Markus to add comments to which Duncan will follow up in the PR regarding scheme.  \n\n#### Wallet key generation  \n([PR](https://github.com/cardano-foundation/CIPs/pull/3)  - potential CIP3)  \n**S** - Added test vectors and took comments on the PR. A Fairly small CIP, bulk of is the Test Vectors. I got them from Matthias and some independantly tested on the Yoroi codebase. No problems with Keygen.  \n**M** - I intended to review and approve last week, thanks for the TVs - no issues. This is an excerpt of a diff doc we reviewed as a team - used to be part of Adrestia userguide/docs. The masterkey gen was extracted from the docs into this CIP..   \n**S** - This comes from the Adrestia docs and Trezor documentation and I added extra about the passphrase feature... Also added the passphraze feature for Ledger which wasn't in the docs. When creating via Trezor and selecting the 24 word option it uses a diff alg that nobody knows of (Matthias: \"yet\").  \n**D** - Fine if you both approve this.  \n**M** - All the new wallets are using the Icarus version, the more prevalent standard - I propose we add that to this CIP that for new applications we recommend this version. (agreement).   \n=> Merge in two weeks  \n\n\n#### HD Wallet for Cardano  \n([PR](https://github.com/cardano-foundation/CIPs/pull/27) - potential CIP1852)  \n**S** - This one has a lot of history behind it - we had to represent that new staking key and needed it to be deterministic so Yoroi and Daedalus had to have the same staking key. The easiest way is to just derive it from the Master key so we added a new chain derivation. We added a chain derivation we added a 2-chain & called it \"Chimeric account\" which came from jormungandr (due to originally keys were the same). We could rename it for \"staking key chain\"...   \n**M** - We just started calling it \"Roles\". We also use it for the multisig key. I would push we publish this CIP very soon.  \n**D** - I think that's most sensible terminology..  \n**M** - Catalyst team decided to have complely different HD tree, so completely diff mnemonic - the rationale is that the voting wallet should be completely separate and independant from the voting wallet...  \n**S** - Bad idea likely but we can discuss some other time. I'll rewrite the CIP. Do you want every new role we add to be a separate CIP?  \n**M** - I would prefer one explaining the general naming, and then individual CIPs for new roles we add. But open to doing PR to that one CIP also for reference... Can do the same as we for Metadata Registry.  \n**S** - I'll split this CIP in two parts then (a CIP for allocating numbers and a separate CIP for the specific role itself)  \n=> ON hold, Sebastien to split into two  \n\n\n#### Transaction Metadata Registry  \n([PR](https://github.com/cardano-foundation/CIPs/pull/34) - potential CIP10)  \n**S** - Every Tx in Cardano contains Tx Metadata, stored as a map of unsigned numbers to CBOR. We can use this map as a namespace, but to have it be as an effective namespace we need some sort of registry where people can document what number they are using for what purposes, and/or define possibly reserved/specific ranges.  \n**S** - The SPOCRA ppl already started metadata and have 200-300 Tx on mainnet. They will probably be the first to allocate numbers...  \n**D** - Let's setup a private range now. Start with '0'. We should be explicit... ex 0-255: 'reserved'. We should have a small and large reserve range. Proposing we go with [0-15] - (agreement). Also [2^16 to 2^17 - 1] for private use, so that guaranteed not to clash with interoperable ones.  \n=> Merge **NOW** (as other CIPs will depend on this / need the draft).  \n\n#### Cardano URI Scheme  \n([PR](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP)  \n**S** - We will need to change and merge two CIPs together. Moving on.  \n\n#### Treasury Fraction on actual distributed rewards  \n([PR](https://github.com/cardano-foundation/CIPs/pull/35) - potential CIP)  \n**S** - This was on the agenda so we can get Duncan's take on who should be involved.  \n**D** - Lars Brunje. He'll direct through the right teams review and provide feedback.  \n\n\n\n### Discussions  \n**F** - Crowdcast issues. Will follow-up and attempt to resolve for next meeting.  \n\n\n\n### Close  \n**ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup  \n**ON Hold** [“Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (potential ‘CIP6’) - extend conversation in PR.  \n**ON Hold** [“HD Wallet for Cardano”](https://github.com/cardano-foundation/CIPs/pull/27) (potential ‘CIP1852’) - to be split into two PRs by Sebastien  \n**ON Hold** [“Treasury”](https://github.com/cardano-foundation/CIPs/pull/35) (potential CIP) - Requesting feedback and review from scientists  \n=> Merge in two weeks: [“Wallet key generation”](https://github.com/cardano-foundation/CIPs/pull/3) to be merged as ‘Draft’ (‘CIP3’)    \n=> Merge **NOW**: [“Metadata Registry”](https://github.com/cardano-foundation/CIPs/pull/34)to be merged as ‘Draft’ (‘CIP10’)   \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status  \n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |\n| 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2020-11-17.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [November 17 2020 notes](#november-17-2020-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n      + [Wallet key generation](#Wallet-key-generation)\n  * [Review](#review)\n      + [Treasury Fraction on actual distributed rewards](#Treasury-Fraction-on-actual-distributed-rewards)\n      + [Extended Metadata](#Extended-Metadata)\n      + [Staking Key Chain for HD Wallets](#Staking-Key-Chain-for-HD-Wallets)\n      + [HD Wallet for Cardano](#HD-Wallet-for-Cardano)\n      + [Cardano URI Scheme](#Cardano-URI-Scheme)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 11/17/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>\n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n\n## November 17 2020 notes  \n**Attending**: (Duncan, Frederic, Matthias, Sebastien) + Colin, Lars (IO) + Marek, Federico (community)\n\n### Triage  \nN/A\n\n### Last Check  \n#### Wallet key generation  \n([PR](https://github.com/cardano-foundation/CIPs/pull/3) - potential CIP3)  \n**S** - minor column changes being added. Merge Once reviewed by Matthias. \n=> Merge as soon as reviewed  \n\n### Review  \n\n#### Treasury Fraction on actual distributed rewards  \n([PR](https://github.com/cardano-foundation/CIPs/pull/35) - potential CIP)  \n**Lars** - A portion of the rewards pool is UNSPENT every epoch - very early, it was planned to go to the treasury (old scheme) - which reduced to about 50% going to the treasury, so now what is left goes to the reserves, which is good because Reserves last longer with Inflation. The CIP Author however highlighted that this however, means somehow a double taxation setup, where the same coins get taxed over and over. \nThe suggestion is to change \"when\" the 20% go to the treasury, the suggestion is that it not be taken from the pot but rather from the rewards.This was mentionned to Aggelos also who agreed it was a good idea. Might have to adjust the rate to account for the changes.  \n**Federico** - exactly - We're proposing that we apply the Tau param on the real distributed reward, not the reward pot itself. Our proposal is based on what we need to change in the specs to achieve that result - so instead of calculating the fractionning at the beginning of the process, we move Tau application on the distributed rewards. Shouldn't be too technically challenging to implement.  \n**Sebastien** - Do you specify a percentage in here?  \n**F** - No, this is simply a proposition so the conversation can take place. Now, we don't see the big difference we were seeing before. Ex: with the arrival of Binance the ammount of delegated ada went from from 50% to 65-66%. Still, we're experiencing real 30 - 35% Taxation rather than the 20% that is specified by Tau param.  \n**S** so next steps is to merge this PR then go to IOHK to look at percent\n**Colin** Q in terms of actual calculation: Right now the epoch expansion is kinda scaled by the participation rate. The rewards are as if all the stakes was pledged and received pledge reward. If we just divided through the Epoch reward by 1+a0 parameter... \n(Back and forth about Monetary expansion setup)  \n**F** - Tau levvy is applied on reward pot before calculating rewards (+Frederic +Lars)\n(Looking at [ledger specs](https://hydra.iohk.io/job/Cardano/cardano-ledger-specs/shelleyLedgerSpec/latest/download-by-type/doc-pdf/ledger-spec))  \n**L** - Page 62. Middle of the page. Jarod ideally the good person to ask (or Philipp).  \n**D** - Before the shelley release, we changed where unpaid ada went - to Reserves. It looks like there is a sentence off in there: \"The difference between the maximal amount and the actual amound received is added to the amount moved to the treasury\" it should say go to reserve, not treasury.  \n**D** - Probably correct in the mathematics but not the prose.  \n**L** - It says october 2019 which seems old?  \n**D** - You're looking at the right version - Delta T1, is the ammount that goes to the treasury. The change to the reserves is Delta R1 and Delta R2. The formal spec is correct, the text is off, should be ammended.  \n**F** - The discussion is about the unclaimed rewards, for varied reasons. We want to minimize the multi-treasury taxation. \n**S** - Two pts. double taxation. convo can happen offline. Changing Tau is not a HF event.  \n**D** - I agree taking the Treasury percentage at the end rather than the beginning is a reasonable thing, but would also need a HF. Let's get specific changes in the CIP itself and review then.   \n(=> To be followed up on structure-wise next meeting, pending added clarifications)\n\n\n\n#### Extended Metadata  \n([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)   \n**Frederic** - Some conversation happened in PR but missing answers/followup  \n**Matthias** - I don't think there is any edition problem. I would like to see this merged as a Draft and let the convo continue.  \n**F** - I'm with Matthias, would want to move this and let conversation continue as Draft.  \n**D** - It's distracting to have contingent conversations about content, easier to start with a detailed mechanism. Then we can add to it incrementally.\n**S** - Pushing out to next meeting.  \n=> Follow-up next meeting.  \n\n\n\n#### Staking Key Chain for HD Wallets  \n([PR](https://github.com/cardano-foundation/CIPs/pull/37) - potential CIP)  \n**S** - This is one of the two CIPs I split 1852 in. This one specifies the key/derivation path.  \n**M** - Haven't reviewed. will do until next meeting.  \n=> Merge in two weeks pending Matthias review  \n\n\n#### HD Wallet for Cardano  \n([PR](https://github.com/cardano-foundation/CIPs/pull/33) - potential CIP1852)   \n**S** - The other CIP from 1852. This one is intent as the registry of the different chains used in Cardano. It uses 0/1 for BIP44. For example, If we were to add staking keys, then those would be added here, so we can know which index means what.  \n=> Merge in two weeks pending Matthias review  \n\n\n#### Cardano URI Scheme  \n([PR](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP)   \n**S** - Could be merged ... but nobody has had time to review yet.  \n=> Move to next meeting  \n\n\n### Discussions  \n**F** - We tried Crowdcast and reverted to GMeet. Want to push [Crowdcast](https://www.crowdcast.io/cips-biweekly) going forward (=> did sync post-meeting: all seem sorted out).  \nHad a Github history mixup due to force Push: reminder to be careful, now CIP10 inception only in history from a side reference. Yet want to consider force-pushing meeting notes rather than awaiting reviews, as they keep taking longer.  \nConversation was setup with R. Moore's team to take over the [cips.cardano.org](cips.cardano.org) site for next week. Note that [PR #42](https://github.com/cardano-foundation/CIPs/pull/42) WILL break the site further, but it will functionally be better flowing due to minor tweaks.\n\n\n### Close  \n**ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup  \n**ON Hold** [“Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (potential ‘CIP6’) - another two week hold potentially merging depending on week convo/Duncan.  \n**ON Hold** [“Treasury”](https://github.com/cardano-foundation/CIPs/pull/35) (potential CIP) - no plan to merge but will reconsider  \n=> Merge in two weeks: [“HD Wallet for Cardano”](https://github.com/cardano-foundation/CIPs/pull/33) (potential ‘CIP1852’)  \n=> Merge in two weeks: [“Staking Key Chain for HD Wallets”](https://github.com/cardano-foundation/CIPs/pull/37) (potential ‘CIP’)  \n=> Merge **NOW**: [“Wallet key generation”](https://github.com/cardano-foundation/CIPs/pull/3) to be merged as ‘Draft’ (‘CIP3’)   \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status  \n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                | Draft   |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |\n| 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2020-12-08.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [December 8 2020 notes](#december-8-2020-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n      + [PR37 - Staking Key Chain for HD Wallets](#Staking-Key-Chain-for-HD-Wallets)\n      + [PR33 - HD Wallets for Cardano](#HD-Wallets-for-Cardano)\n  * [Review](#review)\n      + [PR30 - Cardano URI Scheme](#Cardano-URI-Scheme)\n      + [PR45 - Cardano Protocol Parameters](#Cardano-Protocol-Parameters)\n      + [PR44 - On-chain stake pool operator to delegates communication](#On-chain-stake-pool-operator-to-delegates-communication)\n      + [PR15 - Extended Metadata](#Extended-Metadata)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 12/08/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>\n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n\n## December 8 2020 notes \n**Attending Editors**: (Duncan, Frederic, Matthias, Sebastien). \n\n### Triage  \nN/A\n\n### Last Check  \n#### Staking Key Chain for HD Wallets  \n([PR37](https://github.com/cardano-foundation/CIPs/pull/37) - potential CIP-0011)  \n**Matthias** - Good to merge and proceed.  \n=> **MERGING** now  \n\n#### HD Wallets for Cardano  \n([PR33](https://github.com/cardano-foundation/CIPs/pull/33) - potential CIP-1852)  \n**M** - This one actually should be merged first since PR37 references it. It will function as a Hub for all the extensions going forward, such as staking keys, multi-sig wallet keys (using same purpose but different chain)..  \n=> **MERGING** now  \n\n### Review  \n\n#### Cardano URI Scheme  \n([PR30](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP)   \n**S** - The issue is there is another multipool wants to merge into this one and have not heard from them, so not sure if we want to merge this and then merge the multi-pool in after - ok with either option. PR25. They were intent on merging into this CIP. Could deal with it later.  \n**F** - Could we merge their PR rather than this?  \n**S** - This one is ready to go, would be fine as-is.    \n**M** - Going through it... There is no existing implementation of that is there..?  \n**S** - Yes there is, Yoroi/Extension - the code is opensource  \n**M** - Format is good, Grammar fine, we could add it in. Addresses are said to be base58 - we want to add Bech32 in there.  \n=> Merge in two weeks  \n\n#### Cardano Protocol Parameters  \n([PR45](https://github.com/cardano-foundation/CIPs/pull/45) - potential CIP)   \n**F** - Pushed by IOHK's Kevin Hammond, this is looking at the intial Protocol parameters as pushed in the genesis file.  \n**M** - For Mainnet.  \n**S** - Makes sense - concerned the actual OnChain version drifts from this CIP but could deal with that.  \n**M** - Would like to structure this by Era - which would be easier. It could be something that might be mentionned in the CIP expaining that Parameters can drift.  \n**S** - If we can auto-generate this, that would be ideal.  \n**M** - It doesn't exist yet as a service if we want to automate it. I like the idea of the CIP however as explanining things.  \n**S** - What next?  \n**M** - Would require changes: disclaimer, link to genesis file...  \n**F** - Doesn't the genesis file reflect the actual parameters as-is?  \n**M** - Only at genesis - the parameters themselves can be updated OnChain through a special kind of transaction. To figure out what the current actual parameters are, you basically have to go through the rest of the chain and cherry-pick the blocks that have those special transactions, iterate from genesis and apply changes.  \n**F** - Adding this in this PR sounds useful.  \n**M** - Could be, also to identify out of those parameters which are updateable, and which are not: for example, the epoch length and slot length are not updateable, but the transaction max size it.  \n**S** - I assumed this CIP was if people would want to propose parameters changes - if we want to make this we want to change.  \n**Marek** - for this particular CIP I see this as for the *intial* parameters, not sure if this deals with *changing* the parameters.  \n**Duncan** - Romain wanted this a a CIP to get feedback on the initial parameters, because they can be changed. While it's still centralized, changes could be made to IOHK through this CIP... I think we should decide amongst ourselves what the best method might be: this as a living CIP or rather people proposing follow-on CIPs. Whichever fits the CIP process better. While we still have centralized governance, give some decentralized input. We're transitioning towards decentralized control. While the OnChain gov is centralized, this mechanism can provide input for that.  \n**S** - Prefer this CIP be modified for each changes, and then when a new genesis block is added we flag it here.  \n**Markus** - I like to have this CIP for intial params. This should have happened before. If we do it for future changes, then it would be better as a *new* CIP. I agree with Matthias - should be made clear which can be tweaked and which require a HF for change.   \n**Matthias** - Do you mean one CIP per Hardfork?  \n**Markus** - At least for every HardFork, maybe for protocol updates.   \n**D** - This only contains updateable characters.  \n**Matthias** - We should add the non-updateable parameters then (of the genesis file)  \n**D** - Good idea.  \n**F** - I think it'd be easier if kept in one CIP. I think both can work, Markus' option should be explored.  \n**D** - Another CIP would enable a fleshed out rationale.  \n**Markus** - If we do through PRs for soft-changes and new CIP for Hardforks, then we should rename this one.  \n**D** - This CIP should highlight how future changes would be done.  \n**F** - This one as Standards might be better as Informational to support the state of things.  \n**D** - Advantages are that for \"at least this moment\" they are proposals, and not enactments. Always the point of CIPs, providing a filter for things that are sensible, so some things might get proposed but other competing ones might get implemented. Let's put in this CIP a Proposed way about proposing protocol changes.  \n**D** - Let's propose the changes rather than burden Kevin? Change to Informational & others.  \n**Marek** - will work on it.  \n=> Review in two weeks    \n\n#### On-chain stake pool operation to delegates communication  \n([PR44](https://github.com/cardano-foundation/CIPs/pull/44) - potential CIP)    \n**Marek** - When looking at the communication between SPOs and Delegates from the perspective of the chain, we have 3 main channels, such as Offchain, Metadata-based (ex:CIP6), and for cases where you want to be OnChain. Benefits and disadvantages, but this is verifyable, auditable. I think the format is not as important as to how we will send the metadata. Two ways to send, distinguished by label. I wanted to open it up for discussion, still working on change requested.  \n**D** - Why do this rather than a RSS feed... Why want it auditable?  \n**M** - We're seeing Phishing on behalf of SPOs for example, the usecase here is for direct communication. So SPOs can ask delegates gradually or with certain ammount of stake. This enables directed communication. Adapools.org does the communication offchain. Cost is a feature, for example wallets could have granular control... Another advantage is the history here.  \nNot sure how much this will be used in the future but wanted to cover that space.  \n**D** - Seems focused on folks that work on the Wallet frontends.  \n**Matthias** - I don't think Darko would have any problem with having multiple CIPs for this, the implementation would fall on my team.   \n**S** - I think this is nice to have. I'm not a fan of markdown as too much of a risk sent to wallet. I prefer simpler format.  \n**Marek** - I was reluctant to send link to delegators even.  \n**Matthias** - For security purpose shouldn't add links. If your delegators knows your pool, they should know where to get your official notfications. The msg pushed by the pool to delegator should be able to say \"I am your pool, I have this message, please go see on my official channel for more\".  \n**Marek** - Because this has a cost associated with it, it might be interested for wallet users also - it disincentivizes the spam from the pool too.    \n**D** - Reasonable proposal.  \n**S** - let's remove the link part, and merge.  \n**Marek** - will do changes now, can do now.  \n=> Merge in two weeks  \n\n#### Extended Metadata  \n([PR15](https://github.com/cardano-foundation/CIPs/pull/44) - potential CIP-0006)  \n**Markus** - I replied to Duncan's comment in the PR. I reworked the entire proposal and it now includes the basic principles of how to generate a signable verifyable extended metadata. I tried to do with the existing CLI but with ran into error with the existing TxSign. Using a standard json scheme, not existing. The Txfile requires an initial key name (?) type.. We either need to have the cardano type extended or design the scheme for the extended metadata. The second step is the calc. of the hash, tried with shelley stake pool metadata and raw json, error about filesize (>512b)   \n**D** - That can be changed.  \n**Markus** - Also, outside, I got asked why use this mechanism instead of the Tx metadata to push verification keys and signed Tx OnChain. It's feasible but would require fully sync'd chain and a dbsync instance. If one hasn't, then it's a trust matter.  \n**F** - Sounds like a separate CIP - here the title could be clarified. Want this to be merged.  \n**Markus** - Let's keep in mind: we need CLI support for this to be actually implemented.  \n**F** - Right - Inclusion to repo does not imply it will be imlemented, hopefully support in CLI comes.  \n**Markus** - Re: Focus on mechanism rather than content, if we don't include the most important fields for metadata, then pools will be using the existing, and not care. We should offer at least the most important ones.  \n**D** - It needs both to be implemented and be used. Let's not pack too much into a CIP, this can be extended once it's implemented.  \n=> Merge in two weeks (?)  \n\n\n### Discussions  \n- out of time - \n\n\n### Close  \n**ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup  \n**ON Hold** [PR35 - “Treasury”](https://github.com/cardano-foundation/CIPs/pull/35) (potential CIP) - no plan to merge but will reconsider   \n=> Last Check - Merge in two weeks pending approvals: [PR15 - “Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’)  \n=> Last Check - Merge in two weeks pending approvals: [PR44 - \"On-chain stake pool operator to delegates communication\"](https://github.com/cardano-foundation/CIPs/pull/44) (potential 'CIP-0012')  \n=> Last Check - Merge in two weeks pending approvals: [PR30 - Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/pull/30) (tentative 'CIP-00xx')  \n=> Merge **NOW**: [PR33 - HD Wallet for Cardano”](https://github.com/cardano-foundation/CIPs/pull/33) (‘CIP-1852’)  \n=> Merge **NOW**: [PR37 - “Staking Key Chain for HD Wallets”](https://github.com/cardano-foundation/CIPs/pull/37) (‘CIP-0011’)  \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                | Draft   |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |\n| 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-01-12.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [January 12 2021 notes](#january-12-2021-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n      + [PR15 - Extended Metadata](#Extended-Metadata)\n      + [PR44 - On-chain stake pool operator to delegates communication](#On-chain-stake-pool-operator-to-delegates-communication)\n      + [PR30 - Cardano URI Scheme](#Cardano-URI-Scheme)\n  * [Review](#review)\n      + [PR46 - Shelley Protocol Parameters](#Shelley-Protocol-Parameters)\n      + [PR56 - HD Stake pool cold keys](#HD-Stake-pool-cold-keys)\n      + [PR58 - Catalyst Registration transaction metadata format](#Catalyst-Registration-transaction-metadata-format)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 01/12/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n\n## January 12 2021 notes \n**Attending Editors**: Matthias, Sebastien, Duncan, Frederic.  \n\n### Triage  \nN/A\n\n### Last Check  \n#### Extended Metadata  \n([PR15](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP-0006)  \n**Frederic** - Some minor asks. It doesn't look like much has happened since last meeting.  \n**Duncan** - It's not something someone could implement unambiguously yet, because it's not described unambiguously.  \n**Sebastien** - There seem to be no rush to merge as-is. The asks in the comments are rather straightforward, recommend they be addressed prior to merge.  \n=> Ping @Gufmar to address final tweaks on Github.  \n\n#### On-chain stake pool operator to delegates communication  \n([PR44](https://github.com/cardano-foundation/CIPs/pull/44) - potential CIP-0012)  \n**S** - I feel the protocol described is fine to merge as-is from a tehnical perspective and fine as-is. There were some concerns regarding format, but my suggestion was to go for the simplest thing possible. I feel that's done, so happy. Only point unclear was about the uncoding for the data - the encoding used is UTF-8 - probably not the optimum way to pass long data - we could use CBOR to pass it on in a more optimized way.  \n**Duncan** - He's suggesting an array of text, each one at most 64 bytes... What would be the advantage of anything else (other than UTF-8)? I would keep it small.  \n**S** - Visually (UTF-8 encoded in Base64) would be smaller, but would be bigger at the byte level. I feel it adds complexity but no significant advantage.  \n**S** - Also I notice there is a conflict on the PR. They are modifying the master readme... Do we want to encourage authors editing the master readme file to add themselves? This wasn't part of CIP1...   \n**D** - I would say no. It will always cause more conflicts than it serves. (Fixed the conflict.)  \n=> **MERGING** now  \n\n\n#### Cardano URI Scheme  \n([PR30](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP-0013)  \n**S** - Matthias looked at this a while back - no objection I think  \n**Matthias** - I did then, it hasn't changed since December, is fine.  \n**S** - There was a request to add Bech32, that was done. I want to move and merge this, will add number now.  \n=> **MERGING** now  \n\n### Review  \n\n#### Shelley Protocol Parameters  \n([PR45](https://github.com/cardano-foundation/CIPs/pull/45) - potential CIP-xxxx)   \n**Kevin Hammond** - I updated this propsal and included ALL of the changes since Shelley into it. We now have a record for all param changes, appart maybe for 2.1 which may be mythical...  \n**D** - Did we establish (from Sam) re:one?  \n**K** - I can keep checking.  \n**Frederic** - Did we come to consensus wether this should be era-specific?  \n**K** - Up to Editors. What the Auditors wanted was a record of the initial settings, so the community can use that to base changes off, here was the rational for the choices for those params. What you're requesting is a chain tracking the changes. One thing you could do say the current params are the following,  Here's a trace of all of the changes since the inception of Shelley plus a rationale for all of the changes. Which might be useful from a historic perspective.   \n**D** - We did discuss last time. I think the conclusion we came to, is that proposals changes should be as standalone - fitting with the CIP context of proposals, not _definitive_. There is no commitment of any party to implementation, so really they have to be independant. I think it makes sense to update it when the changes happen on-chain. So proposals should be separate CIPs, well-reasoned proposals. And this should be updated here when it changes on-chain. But if people want to make proposals that should be as a separate CIP. I think we requested to provide a template to propose a param change.   \n**K** - seems right, it feels that it might be on the Editor's role to provide that template.  \n**S** - I'm ok with no template. Else I recall as Duncan, I agree changes should be standalone CIPs. I'm ok with merging meanwhile.  \n**K** - What we could do is say any changes to Parameters should be submitted as a CIP including the name of the Parameters.   \n**D** - this should be made clear in this CIP that the change proposals should be as separate CIPs, not as changes to this one.  \n=> Moved to Last Check  \n\n#### HD Stake pool cold keys   \n([PR56](https://github.com/cardano-foundation/CIPs/pull/56) - potential CIP-xxxx)   \n**Michal** - We can add Rafael for the technical explanations. This proposal was added yesterday, but what we propose here is deterministic derivation of stake pool cold keys. We propose a derivation path as seen. Time is critical because we are trying to push this ledger app by the end of January.  This approach will also enable to operate multiple stake pools from a single HW wallet.  \n**S** Is it feasible to derive a hardened key from a non-hardened parent?  \n**Rafael** not sure, maybe there are security considerations, thanks for avising.  \n**S** - I don't recall off the top of my head. I can look it up.  \n**M** - Tried looking on the BIP32 paper. We're going to have to spend more time into this to dispell concerns.  \n**R** - The non hardened Index was really for convenience but could be replaced by hardened for convenience. (see last paragraph in the PR).  \n**F** - the ask is to clarify the hardened feasiblity. Can we merge? Ok with numbering?  \n**R** - For number rationale it's in line with 1852 as a root index. The stakepools aren't logically related, it should make sense to add it as a distinct index.  \n**F** - As soon as we start diverging, it's opening the door to wild numberings for CIPs..  \n**Michal** - who will be responsible for validation on Hardened/non-hardened point?  \n**S** - I just looked it up now, in practice it's allowed but it means you'll only be able to derive the cold key index from a private key. So if you have a public key of the usecase then you won't be able to derive any child keys. Having usecase non-hardened is kinda pointless.   \n**R** - This was reserved for future cases. Someone may come up to proposal to derive non-hardened cold-key (for whatever reason).  \n**S** - Is that why the usecase field non-hardened?  \n**R** - Yes. In the rationale, we explain the non-hardened derivation usecase says that \"in the future\" it might be convienient to derive non-hardened cold keys. There could be future motivation for multiple non-hardened cases.   \n**S** - So in the future we might need a table for all the usecase values, are you suggesting all usecases be soft-derived rather than mixed (hard and soft)?  \n**R** - yeah  \n**S** - I can't see why we wouldn't have hard only for now, and future non-hardened spectrum  \n**R** - I can do that modification and point out that future usecases might take from the non-hardened cases (if it makes sense)  \n**Michal** - Can we agree you do not see any issue with this CIP and that there are no blockers on path as-is (beyond the hardened thing).  \n**F** - Even though there is a need to have this working from Ledger - there is no need to have CIP inclusion   \n**Michal** - There is no functional blocker, but if we implement it in some way but later change how the cold keys are derived then we could have multiple derivation paths.. We should work on a decision that is final.  \n**S** - Agree. I feel this is fine, including the numbering.   \n**F** - It would be merged on the 28th if we move this to lastcheck.  \n**D** - What does it mean when you have a level hardened and the sub-level non-hardened?  \n**R** - right now for the coldkey index being hardened there is no real point, but for the sake of future proofness. The premise was that other usecases for the coldkeys might arise in the future and those future usecases might find it suitable to have their childkeys non-hardened.  \n**D** - So 'some' usecase would have their (sub) cold keys non-hardened and some hardened. If 'usecase' is hardened then its hardened all the way own?  \n**R** - If you have a usecase hardened, then you cannot use the root key (purpose & cointype) & use that to derive the usecase and child keys because those are hardened. But if usecase is non-hardened, then you can derive those.  \n**D** - Is there a case in the future where you'd want to derive the 0th this as well as the 0th that?  \n**R** - Yes.   \n**M** - It sounds to me we are using 'usecase' as a different 'purpose'. It would be simpler without a 'usecase' and if you need a set of keys for a different Purpose then you pick a separate purpose...  \n**D** - ex: we have SPOs now, suppose in future we have a governance mechanism involving onchain voting through some indirect democracy, where you delegate to someone and they vote for you. To register as someone that folks delegate to, that would be much like registering as a SPO and we would want to manage the keys the same. Same pattern. If I want to register as many ppl they would all be different. I think Matthias is right. Keep usecase but only for things that are really the same. But otherwise, use a different purpose. so all the conditionals can be under a purpose.  \n**R** - Having the usecase hardened then?  \n**D** - Yes.  \n**R** - Agreed, and later (if somehow needed) we can still add non-hardened usecases.  \n=> Move to Last Check  \n\n#### Catalyst Registration transaction metadata format    \n([PR58](https://github.com/cardano-foundation/CIPs/pull/58) - potential CIP-xxxx)   \n- out of time -   \n\n### Discussions  \n- out of time -  \n\n\n### Close  \n**On Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup    \n**On Hold** [PR15 - “Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’) - expecting authors to review and incorporate feedback, thn will merge.  \n=> Merge in two weeks: [PR45 - \"Shelley Initial Parameters\"](https://github.com/cardano-foundation/CIPs/pull/45) (tentative 'CIP-00xx')   \n=> Merge in two weeks: [PR56 - \"HD stakepool cold keys\"](https://github.com/cardano-foundation/CIPs/pull/56) (tentative 'CIP-00xx')  \n=> Merge **NOW**: [PR44 - \"On-chain stake pool operator to delegates communication\"](https://github.com/cardano-foundation/CIPs/pull/44) (‘CIP-0012’)   \n=> Merge **NOW**: [PR30 - \"Cardano URI Scheme\"](https://github.com/cardano-foundation/CIPs/pull/30) (‘CIP-0013’)  \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                | Draft   |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |\n| 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |\n| 11                 | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)                | Draft   |\n| 12                 | [On-chain stake pool operator to delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012)                | Draft   |\n| 13                 | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013)                | Draft   |\n| 1852                 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852)                | Draft   |  \n\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-01-26.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [January 26 2021 notes](#january-26-2021-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n      + [PR15 - Extended Metadata](#Extended-Metadata)\n      + [PR45 - Shelley Initial Parameters](#Shelley-Initial-Parameters)\n      + [PR56 - HD Stake Pool Cold Keys](#HD-Stake-Pool-Cold-Keys)\n  * [Review](#review)\n      + [PR58 - Catalyst Registration transaction metadata format](#Catalyst-Registration-transaction-metadata-format)\n      + [PR61 - Update to CIP-0013](#Update-to-CIP-0013)\n      + [PR62 - Update to CIP-0010](#Update-to-CIP-0010)\n      + [PR57 - Key Serialization formats](#Key-Serialization-formats)   \n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 01/26/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n\n## January 26 2021 notes \n**Attending Editors**: ~Matthias~, Sebastien, Duncan, Frederic.  \n\n### Triage  \nN/A\n\n### Last Check  \n#### Extended Metadata  \n([PR15](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP-0006)    \n**Frederic** - No update from Markus - leaving as-is, reaching out to Markus.  \n=> Ping @Gufmar to address final tweaks on Github. Functionally on hold. \n\n#### Cardano Parameters   \n([PR45](https://github.com/cardano-foundation/CIPs/pull/45) - potential CIP-0009)   \n**Frederic** - Ready to go but missing some structure. Consensus was this is ready to be merged.   \n**Duncan** - If it's simply the header, we should add this in and merge it. You can see the template for it, he added and removed it.  \n**Sebastien** - Ok to merge by me.  \n**D** - Remind the Catalyst group that this is not the PR for \"proposing\" but the informational one for updating. New CIPs for proposing parameter changes must be separate CIPs - conflicting CIPs can exist, but this should be the informational one.  \n**F** - What about the case where a parameter change happens but this CIP does not get updated?  \n**D** - Anyone would be able to come and push a PR with the appropriate change to update this.  \n=> **MERGING** pending internal discussion re: status.    \n\n#### HD Stake Pool Cold Keys  \n([PR56](https://github.com/cardano-foundation/CIPs/pull/56) - potential CIP-1853)  \n**S** - We requested changes last time.   \n**D** - There is a patch since last comments that we added - Last meeting we were looking at Hardened vs. non-hardened. Our conclusion was that the usecase fields should all be hardened: Now they are all hardened.   \n**S** - Approving.   \n=> **MERGING** now  \n\n\n\n### Review  \n\n#### Catalyst Registration transaction metadata format   \n([PR58](https://github.com/cardano-foundation/CIPs/pull/58) - potential CIP-0014)   \n**S** - This one is missing a CIP number but it's already deployed on mainnet. If someone wants to change working, this is already deployed. No opposition on wording tweaks.  \n**D** - Did anyone else reviewed this and double checked the description corresponds to reality?  \n**S** - No. This is just documenting what the Fund2 used 'in practice'. There were some test vectors and ideas but no formal writeup.   \n**D** - Can we get someone from Catalyst to review the CIP?   \n**S** - I'll ping on the topic and see. I also posted it in the Catalyst Slack channel as well.  \n=> to Last Check (to be merged next meeting) \n\n#### Update to CIP-0013   \n([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013)   \n**Sebastien** - You may remember a while back we had that URI scheme and Robert wanted to add the support to create staking pool delegation through the URI scheme. We decided to setup what we had first, for the payment, but now this is adding another scheme. We want this so external websites can create URI links, that open accordingingly where they should. Since this is fairly related to the payment scheme, this should be bundled here, and might even later be expanded. This provides a source of truth that others can refer to.  \n**Robert** - The formal grammar was reworked, added another authority for doubleslash spent, (there was also a discussion for metadata, the URI could be further extended), we'd want the protocol to evolve, this PR is just for single pools to be added to the CIP itself.  \n**D** - Why is it that we want to custom URL schemes rather than a MIME type?  \n**S** - Yoroi is a browser extension. Whenever you select such a URL it'd open Yoroi (or Deadalus) appropriately..    \n**D** - Browsers have for decades been dealing with application associating with MIME types. This is my first time I see custom URI scheme - yet am not a web-dev. Presumably this works for mobile phones also. Is this common practive? \n**S** - It used to be more contractors like mailto: and so on. Back then we could embed skype links etc. But it got too complicated and they created a whitelist of URI prefixes and not being on the list is no bueno. The recommended approach is to use an existing prefix which is why the URI scheme starts with 'Web+Cardano'- they still let you do it but in the namespace. Bitcoin (because it was created a while ago) managed to make it to the whitelist because it was created a while ago.  \n**D** - They still encourage you to do this rather than file + MIME types?  \n**S** - As far as I know. Have never seen MIME types used rather than this anywhere.   \n**D** - The QR codes?   \n**R** - QR codes are just enconding of URLs   \n**S** - Chrome has poor support for this but Firefox had. Unfortunately Chrome is winning the browser war. The support for the APIs are the bare minimum for the browser extensions / functionality to work, while Firefox has better thought out support. The only people that recommend specific setups are mobile apps, such as registering directly with your App: Instead of using a URI scheme, they link to a specific page and you have that specific page register with your app to check if it is installed, and if installed open the app...  \n**D** - Thanks for the digging into things.   \n**R** - This was explored in the closed [PR25](https://github.com/cardano-foundation/CIPs/pull/61) - Sebastien had answered it there. I'm a webdev, I integrate with websites and whatnot. Some schemes are more popular than the community realizes because of torrents and others... At least knowing we can rely on URI consistently would give the SPOs and end users at least one consistent option that is well supported.  \n**D** - One more Q: Can you use a combination of MIME/URI?  \n**S** - You cannot. It's not possible.   \n**D** - Why do we allow pool tickers given they aren't unique rather than their IDs?  \n**S** - The rationale is to accomodate for pool operators that have multiple pools with a common prefix. So they may want to have a URI to the common prefix and the wallet would be in charge of managing it.  \n=> to Last Check (to be merged next meeting) \n\n#### Update to CIP-0010    \n([PR62](https://github.com/cardano-foundation/CIPs/pull/62) - Update to CIP-0010)    \n**F** - This is an update to the registry entry - not sure what this does.  \n**D** - It sounds like he wants CIP-0010 using a machine-readable format (on top of the existing human-readable format). He's given examples and a schema for how it should be added and implicitely the registry should fit that schema.  \n**S** - This seem to make sense in theory. Slightly concerned that these two (formats) will not sync up and we'll run into issues with one no longer matching the other? If we were to only pick one I would pick the machine-readable format and would avoid having both.  \n**D** - Avoiding duplication typically sensible.  \n=> Move to REVIEW for next meeting + reaching out to Author (Marek).  \n\n#### Key Serialization formats    \n([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP-xxxx)   \n**S** - Have not been able to review.  \n**D** - I've not properly reviewed yet. The intention here is to complement the prefixes CIP - this one here would be looking at the format of those keys for historical reference and documentation: This CIP is intent on describing what the FORMAT of keys is about - due to historical complexity and so no. That's from the 3 types of keys. Edd25519 keys, ordinary verification and signing keys, also the Jormagandr \"extended keys\" and later the \"BIP32\" keys. (One of those format should never have existed but Jormagandr added it anyways).  \n**S** - There is a good [Forum post](https://forum.cardano.org/t/message-signing-specification/41032/5) describing things, and it lists 4 formats.   \n**D** - We should be careful reviewing this, should flag to Matthias. The two recommended forms, and also for historical reasons the other ones still used by the older tools, intended to be never be used yet used as extended version by some tools... but not recommended to use. We should probably take this CIP over from here, this should be a good starting Draft.  \n=> Move to REVIEW for next meeting.  \n\n\n\n### Discussions  \n**D** - [PR55](https://github.com/cardano-foundation/CIPs/pull/55) looks like it's simple / ready to go and should be merged.  \n**S** - Let's merge it. (=> merging)  \n**F** - Mentions about using Tags in the repo if anyone has preference. Also regarding publicizing those meetings.  \n**D** - Also let's add [PR31](https://github.com/cardano-foundation/CIPs/pull/31) to next meeting. Looks ready to be merged even.  \n**R** - [PR61](https://github.com/cardano-foundation/CIPs/pull/61) has 2 reviews, but 1 of those isn't from an editor, are we awaiting for some other kind of review?  \n**D** - Correct, awaiting another Editor review. Will look into [PR61](https://github.com/cardano-foundation/CIPs/pull/61) and give it the green tick for next meeting.  \n\n\n### Close  \n**On Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup    \n**On Hold** [PR15 - “Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’) - expecting last tweaks.  \n=> Merge **NOW**: [PR45 - \"Initial Parameters\"](https://github.com/cardano-foundation/CIPs/pull/45) ('CIP-0009')   \n=> Merge **NOW**: [PR56 - \"HD stakepool cold keys\"](https://github.com/cardano-foundation/CIPs/pull/56) ('CIP-1853')  \n=> _Last Check,_ Merge in two weeks: [PR58 - \"Catalyst Registration transaction metadata format\"](https://github.com/cardano-foundation/CIPs/pull/58) (tentative ‘CIP-0014’)   \n=> _Last Check,_ Merge in two weeks: [PR61 - Update to CIP-0013, adding delegation URI scheme](https://github.com/cardano-foundation/CIPs/pull/61)\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                | Draft   |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |\n| 9                 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009)                | Draft   |\n| 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |\n| 11                 | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)                | Draft   |\n| 12                 | [On-chain stake pool operator to delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012)                | Draft   |\n| 13                 | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013)                | Draft   |\n| 1852                 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852)                | Draft   |  \n| 1853                 | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853)                | Draft   |  \n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-02-09.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [February 9 2021 notes](#february-9-2021-notes)\n  * [Triage](#triage)\n      + [PR15 - Extended Metadata](#Extended-Metadata)\n  * [Last Check](#last-check)\n      + [PR58 - Catalyst Registration transaction metadata format](#Catalyst-Registration-transaction-metadata-format)\n      + [PR61 - Update to CIP-0013](#Update-to-CIP-0013)\n  * [Review](#review)\n      + [PR62 - Update to CIP-0010](#Update-to-CIP-0010)\n      + [PR57 - Key Serialization formats](#Key-Serialization-formats)   \n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 2/9/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..\n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.\n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.\n\n## February 9 2021 notes \n**Attending Editors**: ~Matthias~, Sebastien, Duncan, Frederic.  \n\n### Triage  \n#### Extended Metadata  \n([PR15](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP-0006)    \n**Frederic** - Work (and new commit) has happened since the last time, specific to the points raised for the PR.  \n**Markus** - (PR Author) - It took a long time, but I tried to address all comments - I reduced the proposals to a min verision of the Json schema. Although it might not fit all expectations - it should give some initial extended metadata and I hope we can merge and bring it to an actual proposal.  \n**Duncan** - I looked at it two weeks ago, what has changed?  \n**M** - There was a request to make it clear that this was stakepool metadata not  on-chain metadata. I added explainer for the Cardano CLI used to generate signatures. What is missing here is what prefix should be used for the the extverification key: I don't thing we should define a special prefix just for this - Any thoughts? Should it be Bech32 format and if yes what prefix? I looked at other prefixes and didn't know if I should ppropose a specific/proper one for metadata or use ad-hoc..  \n**D** - I would follow the style of the CIP that logs all existing Bech32 prefixes... (CIP-0005)  \n**M** - I need a specific prefix for this one though.  \n**D** - What is the ExtV key, is it just an ordinary verifciation key?  \n**M** - Yea. I don't believe it should be anything special.  \n**D** - If you look at CIP 5 (which keeps track of the Bech32 prefixes), the style we use (to log all bech32 prefixes) is by purpose, not by format... pool operator verificationkey is a good example, ...  \n**M** - So you believe it's worth adding something like poolEVK or other  \n**D** - PoolMetada or PoolVK....  \n**M** - I'll try to add it to CIP 5.  \n**D** - just add it to your current PR, we can update CIP5 accordingly afterwards if that goes through.  \n**M** - I added the Json schema for this minimal version. What is missing is I want to change the PR Title, and since I am not the original Author...  \n**D** - I can change it right now, what to?  \n**M** - \"CIP-0006 Pool Operator Extended Metadata\".  \n**D** - Done.  \n**M** - Not sure if merged now it'll attract more people... Portals like PoolTool are able to implement it, and I hope SPOs start using this format. I addressed most comments, the only left was really the prefix thing. For me that should be it, but open to any questions or comments. There is also an example in there, in the interest of implementers, to see how it works. The Json schema is also pretty restricted, with min/max lengths, description of what fields should contain, logo as a URL to a file, with limit on File Size probably on the service-consuming application like PoolTool to decide how they want to handle a 30mb logo...   \n**D** - In the on-chain metadata, you got 'ExtVKey', did you intend that to be a 'raw verification key hash' or the actual verification key?  \n**M** - From the 3 new files, the public key for verification... The ExtVKey is what is generated with the new prefix... PoolMDVKey. It is put in the main metadata, a source of public information source so 3rd party applications can use it to link to verify. It's the actual key (not the hash). It's used to verify the signature that is in the main metadata file.  \n**D** - Do we describe anywhere what those verification steps are? It should be spelled out explicitely.  \n**M** - In the document, it says \"The Operator first has to extend a data Json file and a data signature created by this CLI commands, and how it has to be published and the ExtVkey as field in the main metadata file... This is what he has to do one time to setup the extended metadata for that pool, and from there he can do with the CLI from there.  \n**D** - Because this is security-sensitive, let's be explicit: it should be unambiguous how to verify the content of the extended metadata.\n\"What is the format of the ExtV key / what is its content?\" i.e. it's exactly a 32 byte ed25519 verification key. \"What's the data we expect to find at the end of the extSig URL?\" i.e. it is a 64 byte ed25519 signature. \"How do we verify one?\" through ordinary ed25519 verification using the known public key that's part of the normal metadata against (..) the data url we find at the end of the data signature url. What software implementing this specification needs to do.  \n**M** - I don't have the CLI command at the moment.  \n**D** - This isn't about the CLI but rather as to what needs to be done for the applications wanting to comply by this specification. Would have no problem merging once that is in.  \n=> to Last Check (to be merged next meeting)  \n\n### Last Check   \n#### Catalyst Registration transaction metadata format   \n([PR58](https://github.com/cardano-foundation/CIPs/pull/58) - potential CIP-0014)   \n**Sebastien** - I had the Catalyst team try and review this with the time they had, and got thumbs up emojis. Again that's not super indicative, but I got Samuel to review it and he said it was fine and added an extra part re: Fund3, as 3 will work slightly different from Fund2. There was one point still unresolved about the addition of a new key: \"61286\". It's still missing from this CIP, which is assumedly OK: it can be added at a later point. Tentatively reserved the number inside CIP10. Once we get a better format description of the reward payout (which is different from the registration payout anyways) we should be fine - this shouldn't block the merging of this CIP.  \n**F** - Minor comment re: the difference of the sidechain vs mainchain (..)   \n**S** - Agree to an extend, but good enough to merge as-is.  \n=> Merge **NOW**  \n\n#### Update to CIP-0013   \n([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013)     \n**F** - This is an update to CIP-0013  \n**S** - Nicolas made a competing separate PR (63?) to this one earlier today. PR61's author commented on Nico's PR, there hasn't been a clear resolution at this point, let's let both CIP authors agree on which standard to use from here.  \n=> To be reviewed the following meeting  \n\n### Review  \n#### Update to CIP-0010    \n([PR62](https://github.com/cardano-foundation/CIPs/pull/62) - Update to CIP-0010)    \n**Marek** - We are using the CIP10 in our scripts and were looking for a way to make it a bit easier for scripting, because parsing the markdown is challenging. This request here is to move it from human-readable to machine-readable. One suggestion from last meeting was to not keep two versions to prevent inconsistencies. I did that and moved everything to the json itself (except for the reserved values).   \n**S** - What we can do is merge the metadata registration CIP first, then rebase this one and add the missing parts to it (the metadata registration CIP modifies CIP10 as well.) I think this is fine to merge.  \n**D** - Approved this PR, also noted that we must figure out the order of the PR for the conversion.  \n=> Moved to Last Check (to be merged in two weeks)  \n\n#### Key Serialization Formats    \n([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP)   \n**F** - Luke was working on this, not sure if someone have been able to hop on this.  \n**D** - Others have been commenting and Luke has done some updates.. I haven't gotten around to looking at it recently.  \n**S** - Not familiar enough either.  \n=> Move to REVIEW for next meeting.  \n\n\n### Discussions  \n#### CIP7 - Curve Proposal parameter discussion  \n**Colin** - Hi all, I am following up on 'a0' from CIP7 - I have been speaking with Catalina and Shawn McMurdo. The actual spec was not one that research was comfortable with, they came back with a counter proposal that I talked Shawn through (and he was happy with that). Should this be an update to this CIP?  \n**D** - If it's more than a small tweak, it should be a separate CIP.  \n**C** - OK. It's a different approach: To use a flat curve pledge benefit entirely, removing the scaling.    \n**D** - It would be nice to include some of the supporting research, from you, Lars and the folks who have dug into this - good to include or reference if feasible.  \n**C** - Should be able to add in there.   \n\n####  PR64 - User-facing Asset Fingerprint - tentative CIP-0014  \n**D** - There's been lots of discussion happening on this PR already. This is one that Matthias is proposing but this is about the upcoming multiasset functionality and how we present assets to users. The basic suggestion is that despite the underlying solution that there is a policy hash, up to 32 bit hash for an asset per a single policy, Matthias suggestion here is - although the asset sub-identifier can in principle contain user element - we should make one opaque identifier and make it bech32. There are arguments wether it should be a hash or other: those identifers should be a non-readable blob. People in there are arguing about the details. This is related to the Metadata registry. This here is about how you display the information when you don't have the registry - Particularly good to get Sebastien to look into it.  \n**S** - I looked at the discussions and all pts I would have raised appear to have been raised...  \n\n\n### Close     \n**On Hold** ([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013)  \n=> Merge **NOW**: [PR58 - \"Catalyst Registration transaction metadata format\"](https://github.com/cardano-foundation/CIPs/pull/58) ('CIP-0015')  \n=> Review next meeting: [PR57 - \"Key Serialization Formats\"](https://github.com/cardano-foundation/CIPs/pull/57) (tentative ‘CIP-0016’)  \n=> _Last Check,_ Merge in two weeks: [PR62 - Update to CIP-0010](https://github.com/cardano-foundation/CIPs/pull/62) (Update to CIP-0010)  \n=> _Last Check,_ Merge in two weeks: [PR15 - \"Stake Pool Extended Metadata\"](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’)   \n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                | Draft   |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |\n| 9                 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009)                | Draft   |\n| 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |\n| 11                 | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)                | Draft   |\n| 12                 | [On-chain stake pool operator to delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012)                | Draft   |\n| 13                 | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013)                | Draft   |\n| 15                 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015)                | Draft   |\n| 1852                 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852)                | Draft   |  \n| 1853                 | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853)                | Draft   |  \n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-02-23.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [February 23 2021 notes](#february-23-2021-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n      + [PR15 - Extended Metadata](#Extended-Metadata)\n      + [PR62 - Update to CIP-0010](#Update-to-CIP-0010)\n  * [Review](#review)\n      + [PR61 - Update to CIP-0013](#Update-to-CIP-0013)\n      + [PR57 - Key Serialization formats](#Key-Serialization-formats)  \n      + [PR66 - Fair Min Fees](#Fair-Min-Fees)\n  * [Discussions](#discussions)\n      + [PR21 - Non-centralizing Rankings](#Non-Centralizing-Rankings)\n      + [PR64 - User-Facing Asset Fingerprint](#User-Facing-Asset-Fingerprint)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 2/23/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## February 23 2021 notes \n**Attending Editors**: Matthias, Sebastien, Duncan, Frederic\n\n### Triage  \nn/a  \n\n### Last Check   \n#### Extended Metadata   \n([PR15](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP-0006)  \n**Frederic** - I think this was good to go but there were some questions to be answered.  \n**Matthias** - We agreed to merge this as a draft, it being tweakable afterwards - fields and others can be on a separate PR or management...  \n**Sebastien** - Good to go.  \n=> Merge **NOW**  \n\n#### Update to CIP-0010   \n([PR62](https://github.com/cardano-foundation/CIPs/pull/62) - Update to CIP-0010)     \n**S** - The main thing with this one was dealing with the merge conflicts. I think that's done.  \n**F** - This needed to be rebased.  \n**S** - Good to be merged pending a rebase.  \n**M** - I skimmed through this but nothing major blocking.  \n=> Merging **NOW** / when rebased  \n\n### Review  \n#### Update to CIP-0013    \n([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013)    \n**F** - The separate competing [PR65](https://github.com/cardano-foundation/CIPs/pull/65)) is conflicting with this one.[PR61](https://github.com/cardano-foundation/CIPs/pull/61).  \n**Robert** - I was hoping that Nicolas would join us to discuss what he meant on how to resolve a conflict by using the stakepools as values rather than keys in a way that avoided an incompatibility between the UIR as he wanted to do it and expanding these links to multiple stake pools - he hasn't explained fully how it would work, and we're waiting to hear from him. Nicolas hasn't come back yet with a way to avoid that incompatibility. I do not believe there is a way of solving this imcompatibility. And really the best way to represent this all is a set of ordered pairs. And that's already the URIs with one value per discreet element: it makes sense for the pool names to be the keys and their portions to be the values. Since right now we have single pool links, none of them have values and there is only one of them, the suggestions he made weren't thinking about how it might expand for multiple pools. I was hoping the ideas could be simple enough to be explainable over github. This proposal was greenlighted a few weeks ago, and I would like to move this ahead if ok. This one is the most efficient representation that is least capacity for misinterpretation (and is easiest to parse and handle pathological cases). Not using ordered pairs would mean more complicated n-tuples.. you'd have a lot of complicated schemes. I feel Nico was trying to avoid headaches for the devs.   \n**S** - Nico cant join from time and due to load - but am sympathetic with his idea. Still I understand that tuples are a miss as well. Honestly either way is sub-par. The stakepool name as key does not make particular sense, but it's the easiest to implement as a shorthand. I know Nico feels reasonably strongly, I understand what he wants to do. For the 'stake' vs. 'delegate', I think Nico is right that we should use 'delegate' instead of 'stake'. It's only a few char diffs so 'delegate' is likley the most accurate.  \n**R** - So the way you would justify that for Stake pool links that aren't immediately used for delegation would be that you are \"considering\" delegating with them?   \n**S** - Yes.  \n**R** - What when Oracle pools come along? Won't people ask \"why are Oracle pools called Oracles but Stake pools will be called delegate?\" This might be another case where right now no convention might be ideal.  \n**S** - I don't see how Stake would be more accurate in either situation.  \n**M** - Isn't stakepool the most accurate?   \n**R** - That's what I have been saying, and is what I have been loading in the PR comments. I think the marketing ppl wants that their process suggest delegated POS - but we're talking about a different process here - this is a machine talking to another machine here.  \n**S** - I don't think that \"Stake\" is particularly accurate or representative. Rather Stake Pool...  \n**R** - I mainly feel strongly about the first discussion - switching value and pair. I'm happy to give way.  \n**F** - All for competing proposals - I feel this should be setup as last-check. The process of CIP review should be able to handle CIPs that some disagree with.   \n**S** - Fine with it - Just concerned about the commentorial explosion of \"variations\" of this... Although that might be unfortunate it might be unavoidable. We can deal with it then still.  \n**F** - This should probably be good to raise through the SPO Digest.  \n**R** - Great idea, but ba thing to wait for: the ammount of appathy for the relevance this has, has been astonishing. Let's not wait on feedback. As to PR65 - the [diff](https://github.com/nicarq/CIPs/commit/dd07c91017fec32700d94d65670565ffa076cd3a) is only a few lines and really not expanding.  \n**S** - If we merge both at the same time, there's a single URI scheme with tickername as the key - I am not sure it will matter as I don't think people are rushing to implement this anyways. Prpobably in the Yoroi extension mobile we will probably implement whatever Nicolas will be prefering. So the decision does not directly impact us. I say let's move both proposals in two weeks and we can adjust as needed. TLDR - mark both for merging.   \n=> Moved to Last Check (to be merged in two weeks) (+ PR65 to last check concurently).  \n\n#### Key Serialization Formats    \n([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP-0016)   \n**M** - This comes from discussions we had with Luke some time ago. We have basically many tools that operate on keys and they all have their own format of keys. Even more tools if you also consider Jormagandr at the time. I think it was just an attempt to come up with  an increment on how to serialize the various parts of keys. Basically 'private keys' are a bunch of bytes, but when you start using extended private keys for hierarchical derivations as we do in wallet, there are other parts to keys such as the chaincode, which explains how you should serialize these things together... So Chaincode and private key instead of just private key. This here is capturing what is currently done and putting it in a CIP so that other ppl can reference it or reuse it.  \n**S** - I read through and it is fine. There is however a long comment in there that hasn't been addressed.  \n**M** - That comment is mostly about CIP5 though a bit irrelevant to the proposal maybe.   \n**S** - If you could write down what you just said, it would be stisfactory. (**M** We should definately address it).   \n**D** - Is this about BECH32 prefix hould be those sort of physical things or they should be about roles?   \n=> Moved to Last Check (pending a comment reply by **M**)   \n\n\n#### Fair Min Fees   \n([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - potential CIP-0017)   \n**F** - This is about Minimum fixed pool fees.  \n**S** - I thing the same people that looked into the Curved pledge pool feel would be needed here since it changes profitability and so on... (Colin / Kevin)  \n**D** - This is a veery technical one and changing the fee changes some attacks on the system. There needs careful analysis by the right individual.   \n=> Flag to relevant individuals and align a review with their help  \n\n\n### Discussions  \n#### Non Centralizing Rankings    \n([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - potential CIP-0018)   \n**R** - I didn't want to see this die - as I understand it, and I am not the one who has compared and contrasted the ranking equations, this is incorporating an exponentially decaying average of pool results and with their potential as it already exists in the ranking algorithm, which would produce a mixture of Large and small pools at the top of the ranks. As someone whose pool has been struggling to survive, this could breakup the aggregation of stake within the longtime inertially saturated pools. Some people don't see it as a problem, some people conceived it as a nash equilibrium. I think the conception of a nash equilibrium might actually be working against Cardano rather than for it. I think I laid that out much in the comment, but this reflects the general apathy mentionned earlier: The pools, particularly the small pools, might feel there is a wall between the developers and the pools themnselves. And the smaller pools opinions should be included in those conversations. So maybe this would be a good proposal to bring up for SPO Digest.   \n**D** - My opinion is that often people make the request to the wrong place. I hear your complaints but the change needed is to the actual infrastructure. Not shooting the messengers, but rather requesting/campaigning for changing to the actual incentives of the system. This is what that CIP was actually doing. Shawn also wrote a separate CIP about actually changing the incentives (Curve Pledge) and it may make sense of reevaluating wether the ranking actually reflect the proper underlying incentives of the system. That's worth evaluating, but the bigger issues such as \"what is the value of k\" the complaints ought to be there... Specificlally on the ranking that is very relevant to consider that the expectation of k winners and we are not certain of who the winners will be - we shouldn't have a cliff edge at k, we should probably have a slopeoff. This CIP here tries to get rid of the assumption that there is k successfull pools. Which doesn't do anything to the underlying incentives. And the mathematics shows that this is what happens with the math setup. If we want 1000 SP then we need to set k as 1000. Suggest dirrecting the energy in the right place.   \n**R** - What I think we need is a smooth edge, not a cliff edge at k.   \n**D** - I agree with you. It would be perfectly reasonable to have one such CIP written. I was holding off on having conversations with Researchers... I haven't actually dug into the actual propopasals from thinking about removing the assumpitons. .. But yes, changing about which the k winners are and a smooth distribution in some grounded way..  \n**R** - It should derive from the system itself.  \n**D** - Can we check in with Shawn and see if he wants to retire it or continue it in this current form?  \n=> Flag to relevant individuals (Shawn, Researchers) add to review for next meeting.  \n\n#### User-Facing Asset Fingerprint \n([PR64](https://github.com/cardano-foundation/CIPs/pull/64) - potential CIP-0014)  \n**S** - This is already implemented in Cardano wallet and will be included in the March 1st HF. I would prefer this be merged sooner than later. I have read throuh and there doesn't seem to be strong opposition to it despite the one way nature of it. Looks like we will be implementing this in Deadalus and Yoroi also.  \n**M** - There are also a few SPOs waiting on that also.   \n**S** - The only concern was about using the Bech32 vs Bech32m - the newly modified bech32...  \n**M** - I think bech32 is just fine since we have been using it everywhere. And if we want to change it to bech32m it should be a more hollistic approach.   \n**D** - I agree if we can. What was the major change to that PR? The digest length down to 20?  \n**M** - Yes, and the fingerprint is not an input format, only meant for users, not machines. I tried to make it clear that for uniqueness you really want to use policyID. I also added test vectors - I feel this is a rather complete CIP as-is.   \n=> Moving to Last Check  \n\n\n\n### Close     \n=> Merge **NOW**: [PR15 - \"Stake Pool Extended Metadata\"](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’)   \n=> Merge **NOW**: [PR62 - Update to CIP-0010](https://github.com/cardano-foundation/CIPs/pull/62) Update to CIP-0010  \n=> Review next meeting: [PR57 - \"Key Serialization Formats\"](https://github.com/cardano-foundation/CIPs/pull/57) (tentative ‘CIP-0016’)  \n=> Review next meeting: [PR66 - \"Fair Min Fees\"](https://github.com/cardano-foundation/CIPs/pull/66) (tentative 'CIP-0017')  \n=> _Last Check,_ Merge in two weeks: [PR61 - Update to CIP-0013](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013  \n=> _Last Check,_ Merge in two weeks: [PR65 - Update to CIP-0013](https://github.com/cardano-foundation/CIPs/pull/65) - Update to CIP-0013  \n=> _Last Check,_ Merge in two weeks: [PR64 - User-facing asset fingerprint](https://github.com/cardano-foundation/CIPs/pull/64) - (tentative ‘CIP-0014')   \n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                | Draft   |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n| 6                 | [Stake Pool Extended Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0006)                | Draft   |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |\n| 9                 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009)                | Draft   |\n| 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |\n| 11                 | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)                | Draft   |\n| 12                 | [On-chain SPO-to-delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012)                | Draft   |\n| 13                 | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013)                | Draft   |\n| 15                 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015)                | Draft   |\n| 1852                 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852)                | Draft   |  \n| 1853                 | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853)                | Draft   |  \n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-03-16.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [March 16 2021 notes](#march-16-2021-notes)\n  * [Triage](#triage)\n      + [PR62 - Update to CIP-0010](#Update-to-CIP-0010)\n  * [Last Check](#last-check)\n      + [PR61 - Update to CIP-0013](#Update-to-CIP-0013)\n      + [PR65 - Update to CIP-0013](#Update-to-CIP-0013)\n      + [PR64 - User-facing Asset Fingerprint](#User-facing-Asset-Fingerprint) \n  * [Review](#review)\n      + [PR57 - Key Serialization formats](#Key-Serialization-formats)  \n      + [PR66 - Fair Min Fees](#Fair-Min-Fees)\n      + [PR21 - Non-centralizing Rankings](#Non-Centralizing-Rankings)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n## Summary\n\nRough writeup of 3/16/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)\n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## March 16 2021 notes \n**Attending Editors**: Matthias, Sebastien, Duncan, Frederic\n\n### Triage  \n#### Update to CIP-0010\n- ([PR62](https://github.com/cardano-foundation/CIPs/pull/62) - Update to CIP-0010)  \n**F** - I think I might have been getting the request for rebase wrong, is this correct/good to go here?  \n**M** - This PR wants to keep things separate = moving content to a different location, out of the readme file. This PR makes the registry easily parseable by tools, instead of having to manually parse a readme. The dynamic one you want to have in a structured format. Checking in as it was rebased last week... Looks good.  \n=> Merging **NOW**  \n\n### Last Check   \n\n#### Update to CIP-0013  \n([PR61](https://github.com/cardano-foundation/CIPs/pull/61) and [PR65](https://github.com/cardano-foundation/CIPs/pull/65)  - Updates to CIP-0013)  \n**Frederic** - Both 65 and 61 were setup as \"Last Check\". To be merged this week if feasible.   \n**Robert** - I don't know what PR65 woud actually do: There's really only been one technical description of how the SPO links would be added to the URI scheme. PR65 is incomplete. So CIP-0013 should be the one that has been outlined: PR61. Suggesting PR65 as a separate CIP would be logical.  \n**Duncan** - Can we go over the differences between PR61 and PR65?  \n**R** - The resistance that Nick had to using the StakePool names as keys also would prevent them from having values. So when the StakePool links would be accomodating the delegation portfolios and we have a problem with not being ablt to use pairs and have to use a complicated schemes with tuples in order to assign these stakepools a value in a haphazardous way... and that's been the question we have asked for PR65 / during the previous CIP Editors meeting. I think Nico wanted to note there were some things that were technically not attractive about using the highly variable stakepool names as keys instead of predicable ones but unfortunately that's the only way to make the representation scheme concise and resistant to errors.  \n**D** - And then the ones that has to do with the security issue is involved with names, they have to use local lists and so on, which pools they actually refer to.  \n**R** - That seems like it would be a challenge for BOTH approaches: You will always have to check the consistency of the stakepool name anways, the Question is weither they will be keys or values.  \n**F** - The two approaches should be fine if conflicting - Sebastien?  \n**Sebastien** - Just conflicting about which should get the \"CIP13\" name. Maybe make more sense as \"CIP13a + CIP13b\". However I am not sure we want to go down that road.  \n**D** - I think they should be standalone CIPs if they extend a specific CIP. If genuine disagreements that is, we just want to make sure what is proposed is a well formed technical proposal.  \n**S** - Originally there seemed to be only one path - I know that for Emurgo we will go with Nico's.  \n**R** - Hard for me since I can't see what the alternative URI would be.  \n**S** - It's been informally described, in github comments and such. 65 is not up to date.  \n**R** - PR65 says \"it's wrong to use the stakepool names as keys\" and wrong to use \"stake\" where we really should be using \"delegate\" for stakepools. But the question of what happens when the values themselves need to have values was never addressed, except perhaps privately as noted by Sebastien. So we've been really discussing the idea that the stakepool names actually can be keys, becaue they are expected someday to have values when we have delegation portfolios. It seems when the links have to refer to delegation portfolios and the stakepool keys need to have values this would cause problems.  \n**S** - It looks like PR65 is up to date.  \n**R** - But it doesn't address the question about when you have to associate a value or a proportion with a stakepool - so in that sense it is incomplete. This actually was a PR for an independant CIP on the 29th of September 2020. Sebastien suggested in October this be reintroduced as a change to CIP13. The Original CIP still had a more thought out plan.  \n**D** - Summarizing: The concern is we might be merging (in CIP13) something that might make future things more complicated for multipool delegation, and you want some consideration to take place to think about either is more useful down the line than the other..  \n**R** - Right, would be useful. We have all the info for 61 but not yet for 65..  \n**D** - Sebastien can we add more content in there? (for 65?)  \n**S** - Yes, on the todo list for 65. I don't mind waiting for merging this.  \n**R** - It looks like Emurgo has stakepool links for 2021.   \n**D** - All things equal, merging things quicker is better. But we want to make sure we have a design that isn't prematurely merged and can extend to multi delegation pool.  \n**S** - We are the only company that has implemented CIP13 and the extension for now as far as I know. So I don't mind waiting until Nico adds in the changes he wants to add.  \n**R** - We may not be rushing to implement it, but if this stakepool links scheme were available, then the SPO would be rushing to implementing it.   \n**S** - I don't think so as no wallet would be implementing it at that point..  \n**D** - If we do have a closeback that people are happy and agree on then it's much more likely to be implemented in Deadalus..  \n**R** - right, this is a lot easier to consider implementing on something that has been agreed on as a standard...  \n**D** - It sounds like we want to wait at least a little bit to see where things go... What would we be waiting for and who would be writing the extension from here?  \n**S** - I can have Nico add the missing parts for 65 within two weeks.  \n**F** - This might be for a separate group - the CIP platform is not intent on saying which is better. Looking too far freezes us.  \n**S** - I agree. And propose a/b options.   \n**D** - Happy to wait a reasonable ammont of time. Yes we don't want to block, but we could see if there is a consensus resolution that might make things easier. If we don't have to have competing CIPs, better. This isn't so urgent, no wallet yet implement it, if we can spend a little bit more time that everyone can agree on is worth it.  \n**R** - Let me know if there are unanswered technical questions and I will jump into it.  \n**D** - Will it be clear to Nicolas what we are interested in here?  \n**S** - Yes.  \n**R** - I would like to see things in the open so we can make sure it's not (in fact) a bureaucratic issue.  \n**F** - Tabling 61 and [PR65](https://github.com/cardano-foundation/CIPs/pull/65) - they were as \"Last-Check\" but now pushed to \"Review\" stage.  \n=> Moved [PR61](https://github.com/cardano-foundation/CIPs/pull/61) & [PR65](https://github.com/cardano-foundation/CIPs/pull/65) back to \"Review\" for next meeting.   \n\n\n#### User-facing Asset Fingerprint   \n([PR64](https://github.com/cardano-foundation/CIPs/pull/64) - User-facing Asset Fingerprint)     \n**S** - The main thing with this one was dealing with the merge conflicts. I think that's done.  \n**M** - Hasn't changed in a fwe weeks. I added in a typescript implementation from Sebastien.  \n**S** - Implemented by a few places, Daedalus, Yoroi, Adalite, Blockfrost... Good to merge.  \n**D** - adding my green tick as well.  \n=> Merging **NOW**  \n\n### Review  \n#### Key Serialization Formats    \n([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP-0016)   \n**F** - This is looking at the various keys using accross Cardano. Matthias did you go over this one last time?  \n**M** - Maybe \"Cryptographic key serialization\" format is a bit too generic, because we don't really touch to vrf or other types of keys: We could maybe rename this CIP.  \n**D** - I have not looked at this one recently and this is one of the ones that requires more brainpower. We have a new Cryptographer that just joined, this might be a good task to look into to review and check if the CIP here is comprehensive. The good thing about this CIP is that this is documenting - so this just needs to be accurate.   \n**M** - This implements exactly what we have in both Cardano Adrestia and Cardano CLI and was discussed in Slack historically to agree on forma... Really how we want to serialize things and how does it compare to existing implementation and before (basically Jormungandr). The new one is more on the compact and it does recomputes some things on the fly. I guess both are fine but we could ask cryptographers, and maybe there's a good reason to package the private and public key and not recompute it all the time. We could almost go one step further: This specifies the datapart of the Bech32 payload that we specified in [CIP-0005](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0005/README.md), but only for 4 of them. We have maybe 20 objects or so now in CIP5... so we could go for an expansion of CIP5, starting with the keys, but also going into payloads. I think we could document all of them. This very strongly seem to connect to CIP5, so maybe we should make that connection a bit more explicit.  \n**D** - Right, this is covering the greater compatibility issues. I feel someone should spend some time and brainpower on this. Because Matthias and I are rather busy..  \n**M** - agree.  \n**F** - Forward to Cryptographer at IOHK, Duncan to flag.  \n**D** - The new cryptographer just started (so two weeks too short).  \n=> Moved OUT to give time ...   \n\n\n#### Fair Min Fees   \n([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - potential CIP-0017)   \n**F** - This is about Minimum fixed pool fees. Flagged to Colin and Kevin who are taking it to the researchers.. We might not be able to look at it as-is.  \n**D** - Unless there is a strong push from authors or other we should wait for follow-on from researchers.   \n=> Moved OUT to give time (for research) ...   \n\n\n#### Non Centralizing Rankings    \n([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - potential CIP-0018)   \n**D** - This one makes sense to wait as we need to figure out how the order of the changes must align with the system - here changing the underlying assumption have to come first, then the utility function... Shawn understands, that's why this one is on how.  \n**F** - Can we look at the spec changes themselves?  \n**D** - This is referring to the [design document](https://hydra.iohk.io/build/5737201/download/1/delegation_design_spec.pdf). If needed the repo [Readme](https://github.com/input-output-hk/cardano-ledger-specs/blob/master/README.md) has links to all the docs.  \n**F** - What does non-myopic mean here?  \n**D** - Myopic is what happens \"immediately\", non-myopic is \"in the end\" / at equilibrium. So non-myopic is \"k pools saturated in the end. Shawn's proposal is that we not use the non-myopic and have all pools saturate. With my non-editor hat on, I don't agree with this proposal here. But that's why it's worth discussing with researchers. It's completely well written. On the technical grounds I happen to disagree with it, but isn't relevant as an editor, but we could see what comes out of that discussion.  \n**F** - Communication in the Github Thread has been very helpful to provide visibility - will flag to researcher and remind to update in the github thread themselves.  \n=> Moved OUT to give time (for research) ...   \n\n\n### Discussions  \nN/A  \n\n\n### Close      \n=> Merge **NOW**: [PR62 - Update to CIP-0010](https://github.com/cardano-foundation/CIPs/pull/62) Update to CIP-0010  \n=> Merge **NOW**: [PR64 - User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/pull/64) (‘CIP-0014’)  \n=> Moved OUT to give time (forwarded to cryptographer) [PR57 - \"Key Serialization Formats\"](https://github.com/cardano-foundation/CIPs/pull/57) (tentative ‘CIP-0016’)  \n=> Moved OUT to give time (for research) [PR66 - \"Fair Min Fees\"](https://github.com/cardano-foundation/CIPs/pull/66) (tentative 'CIP-0017')  \n=> Moved OUT to give time (for research) [PR21 - Non-centralizing Rankings](https://github.com/cardano-foundation/CIPs/pull/21) (tentative 'CIP-0018')  \n=> Moved OUT to give time (for contrasting with 65) [PR61 - Update to CIP-0013](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013  \n=> Moved OUT to give time (requesting extra details) [PR65 - Update to CIP-0013](https://github.com/cardano-foundation/CIPs/pull/65) - Update to CIP-0013  \n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                | Draft   |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n| 6                 | [Stake Pool Extended Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0006)                | Draft   |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |\n| 9                 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009)                | Draft   |\n| 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |\n| 11                 | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)                | Draft   |\n| 12                 | [On-chain SPO-to-delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012)                | Draft   |\n| 13                 | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013)                | Draft   |\n| 14                 | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014)                | Draft   |\n| 15                 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015)                | Draft   |\n| 1852                 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852)                | Draft   |  \n| 1853                 | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853)                | Draft   |  \n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-03-30.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [March 30 2021 notes](#march-30-2021-notes)\n  * [Triage](#triage)\n      + [PR71 - Update to CIP-0015](#Update-to-CIP-0015)\n  * [Last Check](#last-check)  \n      +  N/A\n  * [Review](#review)\n      + [PR57 - \"Key Serialisation Formats\"](#Key-Serialisation-Formats)\n      + [PR69 - \"Multi-signatures HD Wallets\"](#Multi-signatures-HD-Wallets)  \n      + [PR75 - Update to CIP-0015](#Update-to-CIP-0015-1)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 3/30/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## March 30 2021 notes \n\n**Attending Editors**: Matthias, Sebastien, Duncan, Frederic  \n\n\n### Triage  \n\n#### Update to CIP-0015\n([PR71](https://github.com/cardano-foundation/CIPs/pull/71) - Update to CIP-0015)  \n**Matthias** - Sebastien added test vectors in there. I feel that the whole Catalyst framework is moving faster than the CIP is progressing on the subject. We have a few PRs about this CIP-0015...  \n**Duncan** - Sam and Sebastien are reliable sources - should be good to go..  \n**Sebastien** - The test vectors work, but they only work for Fund3 - and there's a separate PR, there's two basically for Catalyst. One is for the test vectors and the other is for updating the Catalyst specifications for Fund4: Fund4 adds a new key and also changes the signing scheme: you no longer sign the full metadata payload but rather now sign the hash of the payload. This PR (which is adding test-vectors) will have to be updated because the vectors have changed. The other PR (which adjusts the specs for Fund4) is still innacurate I believe.  \n=> Moved out and adding comment in the PR to touch/Update  \n\n\n### Last Check   \n\nN/A - (PR61, see below)  \n\n\n### Review  \n\n#### Key Serialisation Formats    \n([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP-0016)   \n**Frederic** - This is looking at the various keys using accross Cardano.  \n**Matthias** - Inigo, a specialist cryptographer, has been reviewing this PR. The whole CIP is itself pretty straightforward, just putting down something that already exists and have a sanity check on it. And the feedback was positive. We knew it was designed by the previous cryptographer, and so now we have the ok from the new Cryptographer.  \n**Duncan** - So Inigo looked at PR57?  \n**M** - Yes. We had a chat and he wondered on the best way for feedback (if any) and I flagged that Github PR comment was the best way. He left a Review, although not part of the org. Review was OK. One note about endianness - and the question was about specifically wording it out... But since it's generalized in most places as big-endian, it would be fine to leave as-is.   \n**D** - It might be better form to simply note it as \"Like in most other places, this is big endian\"  \n**F** - Moving the status to \"Last-Check\" (to be merged in two weeks)  \n=> Moved to Last Check (to be merged in two weeks)   \n\n\n#### Multi-signatures HD Wallets   \n([PR69](https://github.com/cardano-foundation/CIPs/pull/69) - potential CIP-1854)   \n**M** - This is putting down what we've been designing for the multi-sig wallets. This adds new derivation paths to the 4th level of the HD tree like we did for the stake keys, but this one dedicated to multi-sig keys. This also describes how multisig wallets should work, discover addresses and communicate with each others using addresses and keys generated from this new HD subtree. There is an implementation on the Cardano Wallet as we speak that is already here. It hasn't been added to the PR yet but might be added later to link and show how this work.  \n**D** - Sebastien - Does Emurgo have any future supporting plans for multisig generally?  \n**S** - We had some concern about no multisig coordination server. There are a lot of projects where multisig would be useful.  \n**M** - The multisig coord server will happen, but separate from this CIP. We've left out any sharing of the multisig, or the partial Tx here. But later, we'll expand with the coordination server, expected to be a partial publish-subscribe broker (you subscribe to specific channels, send your partial Tx in, and every listener gets it and can reply to your channel). This would be done ideally behind the scene by wallet softwares. This CIP is really how to manage the wallet keys in the context of shared wallets (called \"shared\" over \"multisig\" because they can also be used in many context, for example Catalyst). The idea is to define a particular template for wallet: monetary scripts with placeholders as keys for each cosigners and every instance of that template simply instanciates all keys at a particular index. The same index is used for all cosigners, and if the same cosigner appears multiple time in the template, we also use the same keys index for a particular instance. For a particular script, all the keys are derived from the exact same part to the tree of all the different cosigners' wallets - which makes it easy for the wallet to keep track of what index to use for the next address, and discover their funds / to verify the addresses belonging to their cosigners.  \n**D** - It makes sense to break it down with the server as out-of-scope (intermediate Txs etc). Interested when we get to that.  \n**M** - We have a few drafts on that already  \n**D** - Let's discuss further as this touches Alonzo  \n**M** - This CIP in the end is pretty straigthforward: All cosigners have the same index, so it makes it easy to verify. When you see a particular address you just have to discover your own key inside it, and you know that all your cosigners have used the same key, and since you have your cosigners public keys and your index, you can derive their child keys. All is derived from the structure itself, but we're also going about it sequentially. Indexes are sequential, but also we're tracking with a gap, so standard practice. It's an extension of CIP-1852 (second extension)  \n**D** - Examples were using purpose as '1852', shouldn't they be using 1854?  \n**M** - No, the role is changing but the purpose is the same.   \n**D** - How is the script template setup?  \n**M** - We use the exact same as a script but not locked to a type, and instead of a keyhash we use a cosignerID. The template is just a script with cosignerIDs and when instanciated you replace all cosignerIDs with proper keyhashes. So it has the same representation internally and also externally in interfaces we typically use json. We have a way to represent as json and the same approach for template for the template with cosigners for keyhash. The mapping of the cosigners is defined on the side.  \n**D** - And you're welcoming any template?   \n**M** - Yes, the only constraint is that you cannot change the template. Using a different one would be using a different account on your wallet. To be able to recover, you need to know your key, the template and also your cosigners public keys.  \n**M** - For the setup phase, when you don't yet have your cosigners public key: cosignerID is just 'cosigner #1' for example. In a way because there is a one-to-one mapping it's the cosigners public key. We didn't want to include the sharing of the keys through the multisig server  because the MCS isn't going to be secured. For now at this stage the better way is to (directly) \"talk\" to your cosigner, through a (secure) side channel. Later on we might think of a protocol, but the implication is that the wallet needs to be created in two steps. 1) Create the shared wallet (get your credentials from that) 2) share your credentials with the cosigners (and collect theirs), finish the installation of the wallet.   \n**D** - All sounds very sensible so far.  \n**M** - This was also reviewed by the Vaccuum Labs team, who are also doing the HW Wallet impl. At this stage we know this work is 'ok': we've been able to do light multisig test locally...  \n=> Moved to Last Check (to be merged in two weeks)  \n\n\n#### Update to CIP-0015    \n([PR75](https://github.com/cardano-foundation/CIPs/pull/75) - Update to CIP-0015: \"Catalyst Registration Transaction\")   \n**S** - Let's move this one to two weeks, still significant conversation and open comments there.  \n=> Send to 'Review' for next meeting \n\n\n#### Update to CIP-0013    \n([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013: \"Cardano URI Scheme\")   \n**S** - I spoke with Nico about this and we're not going to make a proposal in the foreseable future that deviates. This one is approved as-is. Considering this as \"Last Check' as this was discussed multiple times.  \n=> Merging NOW.  \n\n\n### Discussions  \n\n#### \"Cardano Addresses\"\n[PR78](https://github.com/cardano-foundation/CIPs/pull/78) - \"Cardano  Addresses\"  \n**M** - New PR for a \"Cardano Addresses\" - it's not final yet but I want to put it on the radar as I have been getting many questions on the subject - it specifies things that already exist but I've been getting a lot of questions so this is a good place to collect information. In the Shelley specs the Byron parts are mostly opaque... Here this goes a bit more in detail if you have to handle Byron addresses - not pressing, but good to document.  \n**D** - Sensible to include. Good Unicode art!  \n=> Moved to 'Review' for next meeting  \n\n\n\n### Close      \n\n=> Merge **NOW**: [PR61 - Update to CIP-0013: \"Cardano URI Scheme\"](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013   \n=> Last Check: [PR57 - \"Key Serialization Formats\"](https://github.com/cardano-foundation/CIPs/pull/57) (tentative ‘CIP-0016’)   \n=> Last Check: [PR69 - \"Multi-signatures HD Wallets\"](https://github.com/cardano-foundation/CIPs/pull/69) (tentative 'CIP-1854')   \n=> Review/Triage next meeting: [PR71 - Update to CIP-0015: \"Catalyst Registration Transaction\"](https://github.com/cardano-foundation/CIPs/pull/71)- Update to CIP-0015  \n=> Review next meeting: [PR78 - \"Cardano Addresses\"](https://github.com/cardano-foundation/CIPs/pull/71) (tentative ‘CIP-xxxx’)  \n=> Review next meeting: [PR75 - Update to CIP-0015: \"Catalyst Registration Transaction\"](https://github.com/cardano-foundation/CIPs/pull/75) - Update to CIP-0015  \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                | Draft   |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n| 6                 | [Stake Pool Extended Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0006)                | Draft   |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |\n| 9                 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009)                | Draft   |\n| 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |\n| 11                 | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)                | Draft   |\n| 12                 | [On-chain SPO-to-delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012)                | Draft   |\n| 13                 | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013)                | Draft   |\n| 14                 | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014)                | Draft   |\n| 15                 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015)                | Draft   |\n| 1852                 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852)                | Draft   |  \n| 1853                 | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853)                | Draft   |  \n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-04-13.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [April 13 2021 notes](#april-13-2021-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)  \n      + [PR57 - \"Key Serialization Formats\"](#Key-Serialization-Formats)\n      + [PR69 - \"Multi-signatures HD Wallets\"](#Multi-signatures-HD-Wallets)\n  * [Review](#review)\n      + [PR71 / Update to CIP-0015: \"Catalyst Registration Transaction\"](#Update-to-CIP-0015)\n      + [PR79 / Update to CIP-0015: \"Catalyst Registration Transaction\"](#Update-to-CIP-0015-1)\n      + [PR78 - \"Cardano Addresses\"](#Cardano-Addresses)\n  * [Discussions](#discussions)\n      + [PR76 - \"Key Serialization Formats\"](#Update-to-CIP-0003)\n      + [Static website and advertising the CIP platform](#Static-Website)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 4/13/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## April 13 2021 notes \n\n**Attending Editors**: Matthias, Sebastien, Duncan, Frederic  \n\n\n### Triage  \n\n\n### Last Check   \n\n#### Key Serialization Formats\n([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP-0016) \n**Duncan & Matthias** - All good / ready to go.   \n=> Merging NOW.    \n\n#### Multi-signatures HD Wallets\n([PR69](https://github.com/cardano-foundation/CIPs/pull/69) - potential CIP-1854)\n**Matthias** - This should benefit from Sebastien's review. Which is a fari point and really argues about the design - I touched to it earlier today.   \n**Sebastien** - What I put out in my comment isreally the privacy, but if folks are not worried then that's not a big issue. Meanwhile also the scaleability, for example if we start having multiple derivation. Because Any change to one of those would have an impact on  the other which bundles/combines them generally. If you're ok with leaving everything under 1852 and conveying to the user the implications, then I'm ok with that. I think your proposed solution of generating more accounts to handle this does not work well inerlight (?) already supports multi-accounts for wallet, so if they derive account 1, 2 3 ... They might run into a multisig account, which would be undefined as to how to handle..  \n**D** - Can I get the concern summarized?  \n**M** - The idea of this proposal is to extend the 4th role/level of the HD derivation scheme so have two new derivation paths, '3' and '4', which would identify multisig key or keys used in a multisig context. That level is normally internal address, external address or stake key. These are WITHIN an account. And so if you want to share your keys with your cosigner you have either to share your account's public key, which by soft derivation they can derive both your multiderivation key or stake key, OR you have to share two keys: The key at level 3 and the key at level 4 so they can both be sub-chain derived. If you have to share your account key, it means you also allow your cosigner to derive your payment keys. Only the public ones, yes, but you give away some privacy. In principle if you want to use Multisig, then you would use a dedicated account for that, only containing multisig keys. If you have the multisig keys in an account, they might get discovered and it could get messy...  \n**D** - I think it's inevitable that different account are going to be for different purposes - and it's not going to be feasible to have the wallet generically treat all. This one for multisig, this one for contracts...   \n**S** - Wether we want multisig to be handled by different accounts or do we want multisig to be handled by different \"purpose\" and so whenever you restore a wallet in Deadalus or Yoroi, you'd pick at the beginning of the restore if you'd be restauring a multisig wallet.  \n**D** - The Downside is that every new kind of thing you want to use it for is a different set of accounts...  \n**M** - This goes against the principle laid out in the CIP for 1852, where we give the general structure, and the 4th level is used as a hole (where we have 0,1,2)...  \n**S** - For Catalyst, we have a voting key - and it would simpler if we had a voting key chain. If we said Role 3 is a voting key chain (**M** - Why not) the voting key could be deterministically derived by incrementing the index. so (0,1,2,3) would be (external, internal, staking, voting key) and multisig would effectively be (4, 5, 6 and 7)... and every time we'd want to add a standard, we'd have to look at this and the multisig path equivalent and it might get messy.  \n**M** - I get your point: you want to reflect the existing strucure also on the multisig. It's always going to have the same set of roles...  \n**S** - Yes, and so if we change the derivation path / purpose type, I feel it's not a big deal. The wallet keep track of your root private key so the key stays the same and you need the password to derive a new account just like you'd need the password for a new purpose so it feels like not much work and would keep things tidier..  \n**D** - So in my wallet, I want to have a bunch of accounts, some will be for some purpose while others will be for different purposes: voting multisig or other. The question I presume if how do we reflect this in the HD structure itself  \n**S** - That's the reason why 'purpose exists' in BIP44 specs. We can use it that way if we want to, but we do not have to. I think it's slightly cleaner if we do that way. If we keep 1852 and generate new rules, I would at least argue to make them non-sequencial such as 100, 101, 102 as a namespace so that if things get added inthe future we have room. Changing the purpose I feel would be slightly cleaner.   \n**D** - What about cointype, is this used?   \n**M** - It's not used but it would likely do more harm than good to remove it.  \n**D** - What about to use it? If we're trying to say there are different kinds of account, or roles, it seems fair that it should live above the account rather than below.   \n**M** - You mean having a non-hardened path before the acount?   \n**S** - It's mostly to prevent collisions or clashes with other cryptocurrencies.   \n**D** - So even though cointype is the second level, in some sense it's the top level.  \n**M** - Yes, has to do with how things where specified: In BIP44 the 'purpose' gives you the rest of the structure: It tells you there is an account type. Conceptually it's below in term of hierarchy.   \n**D** - So cointype has to be registered with HW wallets and such but purpose can be changed, it makes sense to have accounts with different roles.  Wherever we already have staking keys within an account, then it makes sense to have these - these are things within an account. But when it touches to roles within an account it makes sense to move that higher in the derivation tree.   \n**S** - Purpose is my preferred choice as well  \n**M** - It's also relatively easy to change.  \n**D** - What was the tradeof you were initially thinking of?  \n**M** - The main reason to try to have this as the same account is that it felt a bit unnatural for sharing: People already know how to share account public key - and if I wanted to share my account with someone else, like cosigners or such - having this as an extension within the account would make sense. The same account used for a different purpose would mean sharing account (with a different purpose) not the entire wallet itself.  \n**D** - But in some sense, if we were to do it this way, it would still not be the entire wallet, rather all accounts within the wallet.   \n**M** - We're very much account-centric in all the wallets that we have. Using 'A' particular account and then addresses within that account.  \n**D** - I think that's ok logically for the user: \"there is a set of accounts\". Instead of having ONE heterogenous-style account, then you have several Homogeneous accounts characterized by the role/purpose first.  \n**M** - For the purpose also, the natural thing then would be to change the purpose, but also piggyback on the structure of the 1852 wallet - but I really don't like this internal chain for which we have no use of for any wallet - inherited from the BIP44 design: To have different derivation paths for the internal addresses and external addresses is useless and only adds up to the complexity. That's also the rationale to have only two path: payment and stake keys, period. No Internal/external payments.   \n**D** - You could also use the external one always - and ignore the other.  \n**M** - That would be a bit weird but maybe more consistent, because we could say \"look at this overall spec for the rest of the path\" or \"we have a new purpose and define the new path in CIP xxx\"...  \n**S** - I would specify the same thing and state that \"internal is unused\"  \n**D** - This should probably be added to 1852: \"as we add more kinds of accounts, we will add new purpose, but yet outllining we keep the cointype\".   \n**M** - I will update 1852 as part of this PR  \n**S** - I'm fine with it. If we want to modify 1853 to mention it or leave as is, either works.  \n**D** - I think we should capture it somewhere so the next person that comes along and wants to do it for new things... and make it consistent.  \n**D** - => 1852 defines the pattern of extension. i.e. \"when you want to extend this with a new kind of account (..)\" Perhaps we might need some other type of accounts in the future, which should be done by keeping the same cointype but adding a new purpose.  \n**D** - CIP-1854 would therefore be its own CIP as it is now. We've sortof made two decisions here - the right pattern of extension is (local), but the GENERAL pattern of extension should also be documented as part of CIP-1852.  \n**M** - I will ammend this CIP. And also ammend CIP-1852 to clarify that for future use. It's really for different kinds of accounts. For things like the voting key, the \"role\" is still a better fit: you want it to be part of your normal account but also have it shareable as an extension of the role makes sense, so you can have it as part of the normal account or the multisig account. Having that as an extension of the role makes sense. Just change the purpose if you want to have a multisig-shared voting key OR have it fully owned by yourself. Maybe we can change the naming within the HD tree to clarify the (1st) one should be the account purpose, and the (4th) role as the key purpose WITHIN an account.   \n**D** - So for 1854 you would go back to using just 0 an 2, and 1 would be unused. Ok. If Matthias is fine to do changes, it would be good as Last check again.  \n=> Moved to Last Check (to be merged in two weeks)  \n\n### Review  \n\n#### Update to CIP-0015    \n([PR71](https://github.com/cardano-foundation/CIPs/pull/71) - Update to CIP-0015: \"Catalyst Registration Transaction\")   \n**S** - Test vectors have been updated and validated so this PR is ready to merge. In Fund4 the structure changed slightlyy. I spoke with the Catalyst folks about the changes and adjusted the difference in the test vectors by the dryruns - and Samuel helped review too. I am fairly confidient in those changes.  \n**M** - In the first sentence, isn't this the \"Hash\" of the CBOR encoded metadata? I know that that was changed recently - it used to be the cbor, but then was changed to the hash for space.  \n**S** - Probably right - we need to updte this PR to not touch CIP-0015 as all.  \n**M** - Ok - [PR71](https://github.com/cardano-foundation/CIPs/pull/71) is adding test vectors, while the other (([PR79](https://github.com/cardano-foundation/CIPs/pull/79)) will modify CIP-0015 directly.  \n=> Moved to Last Check (to be merged in two weeks)   \n\n\n#### Update to CIP-0015-1  \n([PR79](https://github.com/cardano-foundation/CIPs/pull/79) - Update to CIP-0015: \"Catalyst Registration Transaction\")   \n**M** - (Summarizing) This was reviewed by the Vaccuum Labs team, who are also doing the HW Wallet impl. At this stage we know this work is 'ok': we've been able to do light multisig test locally...  \n**M** - This one touches to the changes themselves  \n**S** - They closed the old PR and created this new one - I haven't had time to look at it yet. I think that Vacuum Lab comments is very fair and we need to have a look at that conversation. I think that defining the nonce as the slot number makes a lot of sense  \n**D** - That's not a nounce, that's a counter. A nounce is Entropy.  \n**S** - This should be changed to min slot number. Once that's done, everyone will be happy.   \n**F** - Does it make sense to rename it?   \n**M** - Quite many things to look at.   \n**S** - I think we can move it to 'Last Check' because the last unknown is this field / nounce thing. Let's move to Last Check, will resolve this for next meeting.  \n=> Moved to Last Check (to be merged in two weeks)  \n\n\n#### Cardano Addresses    \n([PR78](https://github.com/cardano-foundation/CIPs/pull/78) - Potential CIP-0019:\"Cardano Addresses\")   \n(**M** - HOPING INTO 76 - see below in Discussion)  \n**M** - This is documenting what exists and giving more details on the Byron parts, with some test vectors for ppl to use. Some of it deals with the address space and some of it looks at the behind the scenes.   \n=> Moved to Last Check (to be merged in two weeks)  \n\n### Discussions  \n\n#### Update to CIP-0003 \n([PR76](https://github.com/cardano-foundation/CIPs/pull/76) - Update to CIP-0003)   \n**M** - This isn't an actual CIP but a clarification on an actual CIP that we reviewed with Sebastien - Why Trezor is using a different derivation format from the seed to the master key with the 24-word mnemonics.. Vaccuum Labs just heard back from Trezor and this was basically due to an earlier bug that eventually had to be kept for continued compatibility.   \n**S** - OK with merging it, good to go.    \n=> Merge Now. \n\n\n#### Static Website   \n**M** - Do we want to advertise the [static website](https://cips.cardano.org/) a bit more? What is blocking here? It's a bit easier to digest than the github site itself.  \n**F** - The meetings, the platform are not getting the engagement it probably deserves - Do we WANT to advertise it?   \n**M** - I think we do, I think developers.cardano.org should link to it.   \n=> Added to a the retro for discussion. \n\n\n### Close      \n\n=> Merge **NOW**: [PR57: \"Key Serialization Formats\"](https://github.com/cardano-foundation/CIPs/pull/57) - CIP-0016    \n=> Merge **NOW**: [PR76 - Update to CIP-0003](https://github.com/cardano-foundation/CIPs/pull/76)   \n=> Last Check: [PR71 - Update to CIP-0015: \"Catalyst Registration Transaction\"](https://github.com/cardano-foundation/CIPs/pull/71)- Update to CIP-0015  \n=> Last Check: [PR78 - \"Cardano Addresses\"](https://github.com/cardano-foundation/CIPs/pull/78) (tentative ‘CIP-0019’)  \n=> Last Check: [PR75 - Update to CIP-0015: \"Catalyst Registration Transaction\"](https://github.com/cardano-foundation/CIPs/pull/75) - Update to CIP-0015  \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n|#              |Title            | Status               |\n| ----------------- |:----------------|:-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |\n| 2                 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |\n| 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                | Draft   |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |\n| 6                 | [Stake Pool Extended Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0006)                | Draft   |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |\n| 9                 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009)                | Draft   |\n| 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |\n| 11                 | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)                | Draft   |\n| 12                 | [On-chain SPO-to-delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012)                | Draft   |\n| 13                 | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013)                | Draft   |\n| 14                 | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014)                | Draft   |\n| 15                 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015)                | Draft   |\n| 16                 | [Cryptographic Key Serialisation Formats](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0016)                | Draft   |\n| 1852                 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852)                | Draft   |  \n| 1853                 | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853)                | Draft   |  \n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-04-27.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [April 27 2021 notes](#april-27-2021-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n      + [PR71 / Update to CIP-0015: \"Catalyst Registration Transaction\"](#Update-to-CIP-0015)\n      + [PR79 / Update to CIP-0015: \"Catalyst Registration Transaction\"](#Update-to-CIP-0015-1)\n      + [PR78 - \"Cardano Addresses\"](#Cardano-Addresses)\n      + [PR69 - \"Multi-signatures HD Wallets\"](#Multi-signatures-HD-Wallets)\n  * [Review](#review)\n      + [PR85 - \"NFT Metadata Standard\"](#NFT)\n      + [PR82 - \"Cardano Delegation Portfolio\"](#Cardano-Delegation-Portfolio)\n      + [PR86 / Update to CIP-0013: \"Cardano URI Scheme\"](#Cardano-URI-Scheme)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 4/27/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## April 27 2021 notes \n\n**Attending Editors**: Matthias, Sebastien, Duncan, Frederic  \n\n\n### Triage  \n\n N/A\n\n### Last Check   \n\n\n#### Update to CIP-0015  \n([PR71](https://github.com/cardano-foundation/CIPs/pull/71) - Update to CIP-0015: \"Catalyst Registration Transaction\")   \n**S** - I had forgotten to update the PR - Will do that right now, but otherwise good to go. (This PR now strictly adds the test vectors and nothing else).  \n=> Merge now  \n\n#### Update to CIP-0015-1  \n([PR79](https://github.com/cardano-foundation/CIPs/pull/79) - Update to CIP-0015: \"Catalyst Registration Transaction\")   \n**F** - Prior Editors conversation went over the review from Vaccuum Labs team and suggested that authors change the 'Nonce' field to \"slot number\" as it functions as a counter...  \n**D** - We put a comment to that effect and they came back with this being used elsewhere and generally preferring \"Nounce\".  \n(Conversation around wether the naming should use \"slot number\" rather than \"nonce\". As evidenced from other uses and checking definitions, \"Nonce\" is fine)   \n**D** - This is really a naming issue, withdrawing request as they pointed to prior use with naming.   \n**M** - OK.   \n=> Merge now   \n\n#### Cardano Addresses    \n([PR78](https://github.com/cardano-foundation/CIPs/pull/78) - Potential CIP-0019: \"Cardano Addresses\")    \n**M** - The past conversation was that this was good to go - there is some conflict in the readme likely from a separate merge. Resolving.  \n=> Merge now   \n\n#### Multi-signatures HD Wallets  \n([PR69](https://github.com/cardano-foundation/CIPs/pull/69) - potential CIP-1854: \"Multi-signatures HD Wallets\")  \n**F** - This is the one we had a lengthy conversation last time (1854).    \n**M** - The changes from last time were to change the purpose instead of adding a new role - we will use a new purpose (1854) to distinguish multisg wallet from standard wallets and will keep the same coin type.  And we will keep a structure similar to the structure defined in 1852 and as a summary I recapped all that in a small table, but leaving the 'role=1' out, which is reserved for the internal adddresses in the standard wallets but will remain unused in the multisignature wallets so we will only use '0' for the payment keys and '2' for the stake keys after that the structure is the same. One account which is hardened and an index not hardened. This prevent mixing up a standard wallet and a shared wallet and also makes it possible to share the cosigners the account key without exposing your other normal payment keys to your cosigners - and makes it easier to extend both proposals, such as adding new roles for 1852 and piggyback on the same structure for 1854. For example the voting key could be added as a new role here (ex role=3) that could be added. Re: user-facing encoding we have defined new prefixes for the bech32 encoding so there isn't a shared prefix for all the keys coming from this particular proposal. I made the update to [CIP-0005](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0005/README.md) directly, and it setups parallel for every key - [CIP-1852](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852/README.md) and [CIP-1854](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1854/README.md) have their own formats. I added a bit to CIP-1852 to explain the rationale - if intent simply to extend the existing roles with a completely different semantic then it's fine to add a new role. The part about discovering the template does not change.   \n**D** - Nice. I think that's good.   \n**S** - LGTM too - I approved it.   \n=> Merge now   \n\n\n### Review  \n\n#### NFT  \n([PR85](https://github.com/cardano-foundation/CIPs/pull/85) - potential CIP: \"NFT Metadata Standard\")  \n**D** - A lot of conversation about the NFT CIP PR...  \n**M** - This is one of those for which I wanted to do a summary - there has been a lof of conversation on that and people also seem to disagree on the goal of that CIP...  \n**F** - Oftentimes people seem to not grasp \"NFT\"  \n**D** - Why does one need a standard here? you can already create them. What's the standard for?  \n**M** - This standard is mostly about associating metadata (or more exactly content) with the token encountered onchain (NFT) - this proposal is mostly about linking the association of data with the minting. But this proposal is mostly about \"images\". So there is some will to also associate NFTs with anything you can link (video / anything that has URL/MIME type) - but here some seem to be arguing as this being solely about images rather than a wide-reaching NFT standard. I think it makes sense overall but we would need to include content hashing - but they should also rename the proposal accordingly to not have some overly generic format.  \n**D** - That makes sense - So really it's \"metadata to be associated with an NFT\" to say what it is, rather.  \n**F** - This goes back to NFTs \"as experienced\" on Ethereum, such as smart-contracts complying with a standard (ERC721). We don't have those standards yeton Cardano, this might be a first step for images here. We have one registry run by the CF, but not pushed as a standard - which has a set of metadata attributes that it can associate. I feel it's rushing a little bit until we have a distributed setup (smart-contracts).  \n**M** - I think the rationale was here trying to document how \"Spacebudz\" as an application setup their NFTs - So they wanted to write down the approach those guys took onchain so other applications can reuse it similarly (for images NFTs). \"General\" NFT conversation might be better to put somewhere else, such as a future CIP that would be MORE generic..  \n**F** - So this sounds like the CIP is perfectly fine, if reframed a bit?  \n**M** - Yes - modulo  a few corrections. I wouldn't put anything about the MIME type in there for example. Really should be images only so future CIPs can be more generic for NFTs. This has values in itself, such as \"My app supports CIP-122 (madeup) for images\" while another conflicting image standard might defines a different approach that some other app took. We don't have to choose which is the better one, just that it makes sense.  \n**S** - I think that's a good summary - I haven't had time to go through it, but maybe it's settled down for now?  \n**M** - I don't mind making a summary of the conversation so far and opening it for next meeting.  \n**F** - Will add to the thread so people are notified.  \n**M** - I'll add something at the end of the github conversation, summarizing what I just proposed - add content hashing, and making the focus on image.   \n=> Add comment in thread (**M**) + Moved to Review for next meeting.  \n\n\n\n#### Cardano Delegation Portfolio  \n([PR82](https://github.com/cardano-foundation/CIPs/pull/82) - potential CIP-0017: \"Cardano Delegation Portfolio\")  \n**M** - [PR86](https://github.com/cardano-foundation/CIPs/pull/86) came out as an offshoot of [PR82](https://github.com/cardano-foundation/CIPs/pull/82) - so they are linked. There was an extensive comment from Robert on 82, suggesting to use URLs to transport the portfolios information rather than using an external json file - more cumbersome to generate and pass along -  while a link is easier to modify as just text... I don't think these two cancel eachothers, but are complementary. It would be good to get someone like that on both URI and JSON schemes.  \n**M** - Robert makes a good point on the framing of the CIP, the motivation for it: there is a monetary incentive to split your delegation into multiple stakepool, especially for users that have a lot of money or stake. I do agree with the comment on motivation - As soon as a user reaches a certain ammount of stake (enough to over-saturate a pool) there is a motivation for you to split your ada into multiple pools. Then there is the question of allowing decimals (which I am strongly against in that proposal): This proposal uses plain integers as weights, exactly to cope with problems that come with floating arithmetic especially with json and javascript kindof world where this is often causing issues. The illusion of precision that you get with decimals in the end is unecessary for this particular proposal because there is no way you can achieve that level of precision anyways with a wallet - the \"best effort target\" for the wallet. That's really what it is. A wallet is defined in several UTXOs and you can only associate A particular UTXO to A particular stakepool which means that in a way you have the granularity that your UTXOs give you. If you have 2 UTXOs in  your wallet there is no way you can delegate to 3 stakepools at the same time (you'd need to break down your utxos and whatnot). Having the illusion of \"precision\" with decimal numbers doesn't make sense for that because you will not be able to achieve it anyway with a wallet. That's why we went for a \"weight\", a sort of indicator that your wallet is supposed to \"try\" to achieve delegation according to the weight, and is fine - maybe it could be called \"best effort\" or be highlighted more in the description, although I thought I did.  \n=> (Tentative) Moved to Review for next meeting.\n\n\n#### Cardano URI Scheme  \n([PR86](https://github.com/cardano-foundation/CIPs/pull/86) / Update to CIP-0013: \"Cardano URI Scheme\")  \n**M** - This is using decimals as proportions which we probably do not want as explaind earlier, and I will comment in this PR itself. And it would be good to get alignment between the portfolio as json and the portfolio as URL. With which we would actually redefine this [CIP-0013](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/README.md) and provide a more general structure and have something a bit more like what was done for the metadata label registry ([CIP-0010](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010/README.md)). (For the metadata it was essentially imposed by the blockchain format really) and say this is how it works and this is a registry for the various actions that can be recognized.  \n**S** - My main Q for the portfolio stuff is still if we can get it implemented in the actual Cardano nodes themselves: The single stake key, with the multi-pool delegation... We were previously told \"possibly in the future\"... With the Alonzo integration into the node wrapping up maybe more bandwidth would enable that?   \n**M** - The last info I have on that is basically that \"no\" we aren't going to bring this into the node (at least immediately) because of all the complications it brings. I am not aware of any long range target. It could be that we have this notion of portfolios for now, but it might be deprecated in the future if there is the capability.  \n**S** - It feels we're moving the complexity from one place to another. But the PR is fine as is, I have no issue approving it and merging it.  \n=> (Tentative) Moved to Review for next meeting.  \n\n\n### Discussions  \n\n\n### Close      \n\n=> Merge **NOW**: [PR71 / Update to CIP-0015: \"Catalyst Registration Transaction\"](https://github.com/cardano-foundation/CIPs/pull/71)- Update to CIP-0015  \n=> Merge **NOW**: [PR79 / Update to CIP-0015: \"Catalyst Registration Transaction\"](https://github.com/cardano-foundation/CIPs/pull/79) - Update to CIP-0015  \n=> Merge **NOW**: [PR78 - \"Cardano Addresses\"](https://github.com/cardano-foundation/CIPs/pull/78) (‘CIP-0019’)  \n=> Merge **NOW**: [PR69 - \"Multi-signatures HD Wallets\"](https://github.com/cardano-foundation/CIPs/pull/69) (‘CIP-1854’)  \n=> Review next meeting: [PR85 - \"NFT Metadata Standard\"](https://github.com/cardano-foundation/CIPs/pull/85) (tentative ‘CIP-0020’)  \n=> Review next meeting: [PR82 - \"Cardano Delegation Portfolio\"](https://github.com/cardano-foundation/CIPs/pull/82) (tentative ‘CIP-0017’)  \n=> Review next meeting: [PR86 / Update to CIP-0013: \"Cardano URI Scheme\"](https://github.com/cardano-foundation/CIPs/pull/86) - Update to CIP-0013  \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)                                                                | Active                |\n| 2                 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002)                                                  | Draft                 |\n| 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                                                      | Draft                 |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                                                            | Draft                 |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                                                     | Draft                 |\n| 6                 | [Stake Pool Extended Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0006)                                               | Draft                 |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                                                       | Draft                 |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                                                            | Draft                 |\n| 9                 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009)                                                         | Draft                 |\n| 10                | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                                        | Draft                 |\n| 11                | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)                                           | Draft                 |\n| 12                | [On-chain stake pool operator to delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012)                    | Draft                 |\n| 13                | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013)                                                         | Draft                 |\n| 14                | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014)                                              | Draft                 |\n| 15                | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015)                                          | Draft                 |\n| 16                | [Cryptographic Key Serialisation Formats](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0016)                                    | Draft                 |\n| 19                | [Cardano Addresses](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0019)                                                          | Draft                 |\n| 1852              | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852)                                                     | Draft                 |\n| 1853              | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853)                                                    | Draft                 |\n| 1854              | [Multi-signatures HD Wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1854)                                                | Draft                 |\n\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-05-11.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [May 11 2021 notes](#may-11-2021-notes)\n  * [Triage](#triage)\n      + [PR66 / \"Fair Min Fees\"](#Followups)\n      + [PR21 / \"Non-Centralizing Rankings\"](#Followups)\n  * [Last Check](#last-check)\n  * [Review](#review)\n      + [PR85 - \"NFT Metadata Standard\"](#NFT)\n      + [PR82 - \"Cardano Delegation Portfolio\"](#Cardano-Delegation-Portfolio)\n      + [PR86 / Update to CIP-0013: \"Cardano URI Scheme\"](#Cardano-URI-Scheme)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 5/11/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## May 11 2021 notes \n\n**Attending Editors**: Matthias, Sebastien, ~Duncan~, Frederic. Research Guest: Roman Oliynykov (IOHK).  \n\n\n### Triage  \n\n#### Followups\n([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - \"Fair Min Fees\")  \n([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - \"Non-Centralizing Rankings\")  \n**Frederic** - Roman (from IOHK Research) was looking at these as well as Colin - however the timezone might be an issue to get updates. There were inquiries from the community to see if we could get a better insight from IO research, do we have any updates regarding either of those.  \n**Roman** - It's a side of my research right now and being brought up to the next Chief Scientist meeting next wednesday. There is deep theoretical research on game theory and equilibrium towards a given number of stakepools - I also agree with this approach. I also agree that tasks raised in these CIPs are essential and need to be researched more. It's a side of my research and will be discussed more with (IOHK Chief Scientist) Aggelos. I looked at both of those and will provide details regarding those to him for discussion.  \n\n#### Minor PRs\n**Matthias** - Three major PRs are currently ready to be merged and we can push those through quickly:  \n1 - A bot dependancy fix. nothing to see, let's merge unless someone is against it.  \n2 - A Minor one about some linkfixes.  \n3 - A PR from Mikhail to separate data into its own file so it can be parsed seaprately and whatnot. I think this is something we could encourage when writing CIPs, When people have separate files, they should try to aim to put them outside of the CIP itself and keep the CIP itself in prose while the data can be as its own file.  \n**Sebastien** - I approved all those.  \n=> merge NOW.  \n\n### Last Check   \n\n### Review  \n\n#### NFT  \n([PR85](https://github.com/cardano-foundation/CIPs/pull/85) - potential CIP: \"NFT Metadata Standard\")  \n**F** - It felt we had a good overview the prior meeting, but we might do a recap for recording viewers or such...  \n**S** - I've read through this PR. I think there's been a lot of good points (that I agree with) but it looks like some of those conversations are still ongoing.  \n**M** - Apotential thing we should be careful with, is using the blockchain as a datastore. For instance, this here is suggesting we put the entire metadata on the blockchain itself, then for each token there's a set of fields / metadata which needs to be encoded and use space: it (the blockchain) is not an ideal tool for that. The blockchain is good to ensure that content has not been tampered with... it's a Ledger, not a Database. Rather we should probably encourage a hash (of the metadata) onchain with a URL pointing to the (hosted) metadata offchain in a separate server. Like we did for stakepools and various other things. Not completely settled on having everything in there, even though it would be conveniently small and accessible (onchain), without needing a server to host the whole things. Plus it has also already been done a few times. I'm not sure how we can prevent people from doing it directly still.  \n**S** - I have to agree. The problem I have with this standard is in this standard, we have a name, a description, but I can imagine multiple standards that (also) have multiple names and descriptions conflicting (for example if a token is trying to follow multiple standards)  \n**M** - And it is also more readily expandable in a way   \n**S** - I feel requiring people to put an IPFS link and a hash would not be a big issue as users are already uploading images and linking them through IPFS (so this would be something they would be familiar with)  \n**M** - It seems they have considered the offchain approach in the [forum post](https://forum.cardano.org/t/cip-nft-metadata-standard/45687) but not in this CIP(PR) itself. The offchain approach would still miss a hash because you wouldn't be able to trust any content you get...  \n**F** - Isn't IPFS linked to Ethereum?  \n**S** - No. It's 'used' by Ethereum but not linked in any way. It is somewhat linked to a project called filecoin (a blockchain) the group behind IPFS. Consensys does work with Filecoin on some projects and so they have some unoficial partnerships and things like that.  \n**M** - I think we can suggest what we said last time still. This CIP seem to be more clearly focused on images and so while most NFTs seem to be images at the moment, this CIP is accordingly skewed towards images right now. It could be that this '721' label is reserved for image NFTs and so putting a link to an image on the IPFS network could be sufficient (provided there is a hash). Different story if it's a IPFS client ID or similar. I don't think we need any of the outside fields... Which actually posits multiple issues because it's not only about the image: they also want to have a name and other fields, which means the IPFS links should probably NOT be an image but the actual metadata. Hm.  \n**S** - That's what we want: We want the description to also be offchain, they could be pretty long for some.  \n**M** - For me that's why we'd probably want these files (fields) removed from this PR here and limit ourselves to images only. We don't need files or mime type, you can simply assume an image enforces png for example as format..  \n**S** - I think this is still open for discussion so far. People have not been convinced either way.    \n**M** - Which leaves the name and description.  \n**S** - I feel this (name and description) is something we should have had from the start when we launched multiassets.  \n**M** - You mean upon minting Tokens?  \n**S** - Yes, it would not have been perfect, but having this as separate field would have made it easier for adding support in wallet or expanding. And standards such as 721 would not have to fight or multiply-define \"name\" or \"description\" multiple times. If we want to double down on the Token registry to act as the place for names and descriptions (rather than have it onchain) then we should remove these from 721. Else if we want to have metadata onchain then we should extract it from here (721) and put it in a separate namespace so it can be used by other standards as well. So I feel we have to pick one or the other.  \n**M** - You're right, but I am still not convinced by the onchain approach on that, especially with all the NFTs that are being minted everyday nowadays. The Blockchain is currently 8GB for Cardano, 5 of which were just generated since the Allegra era, so yea, the transactional volume has increased but also the size of the transactions that were submitted. We could probably measure the impact of all the metadata being submitted onchain at the moment and I also agree that we already have an offchain solution for that: we should probably push that a bit more. The name and description are already covered by the Cardano Registry. Adding a new wellknown property as an img that is a link to an IPFS link should be trivial...  \n**F** - Any way to multipurpose the Logo field for that?  \n**M** - I would still keep them separated. The Logo was intended for actual currencies, having a different field might make more sense.  \n**F** - Regarding the Cardano Token Registry (an instance of a Metadata Registry) from the Foundation side that was intently meant to handle coin-like token - I think the more functionalities get grafted on it the more you will see some pushback on the new functionalities beign added. Unless if you're talking about the more general server code that IO is making available.  \n**M** - The server in itself is a centralized solution, but the metadata format itself is not, and so it can be transported to a different server if desired. There is nothing the server provide that cannot be transfered to another instance. There is only one hosted by the CF right now, but in that sense it's only semi-centralized: You don't really have to trust the server itself as the data itself is authenticated and self-contained. Having said that, it's true that the format is very much tailored towards 'currencies'. If you were to do that for 100 NFTs you'd need 100 different files, all with different subjects, which is not practical.  \n**F** - The CF registry as a solution might not be ready for that kind of setup..  \n**M** - Having things in one single file would not really change much - you wouldn't have to repeat some of the field but you'd still need all the other ones. And still minting 10K entities might be a bit too much but also a reason to not put that onchain (which would be large for no reason).  \n**F** - Maybe the NFT conversation regarding images might be more focused on the format: something we could either add onchain or offchain on a registry. I'm hearing your point as the offchain solution being really 'semi-centralized', the same way as the CIP platform more or less.  \n**M** - My recommendation here is: \"Have the lightweight metadata onchain if indeed it is limited to a name and a description. For any more elaborate metadata, we need an offchain solution.\" But that is still not satisfactory I think..  \n**F** - For this PR - let's add a comment in the PR with the caveat that this is a 'recommendation' - also noting that this PR is still going to be reviewed again next meeting, with the understand that we aren't trying to find a perfect solution - it sounds as the lead recomendation has been to refocus on image NFT for this PR leaving the greater NFT conversations out for continued discussions.  \n**M** - Definately one of the points we want to communicate - also really want to emphasize the Blockchain is not meant as a database - and should not be used to store content, which should probably favorize offchain solutions. This is a good conversation to extend with the Author of course. I don't think there is a clear case for the storing of items on the chain, besides the readily availability of metadata as you synchronize the blockchains, and you wouldn't have to fetch that from a different ressource or server - but you already have to fetch the image from a different server, and since that cost is there, then we might as well build on such kind of solution. I can understand that the current Cardano Token Registry (an instance of a Metadata server) is maybe too centralized for that, but then we need a better (more decentralized) solution that doesn't require storing things on chain.  \n=> Adding a note in the PR + leaving in Review for next meeting.  \n\n\n\n#### Cardano Delegation Portfolio  \n([PR82](https://github.com/cardano-foundation/CIPs/pull/82) - potential CIP-0017: \"Cardano Delegation Portfolio\")  \n**M** - There was a last remark from Robert as we were discussing the 'Decimals' on other proposals - which is sortof related - to extend the URI scheme for delegation portfolio as well. I added a response here in the PR (which was also discussed in our last meeting), saying that we want to avoid using floating arithmatic as much as possible and that's why we use plain integers as weights and ratios, so they can be represented as fractions and more importantly those ratios do not need to be precise because there is no way in the end to achieve that precision in the end for the wallets (it will always be an approximation), and so they are rather a \"direction\" for the wallet to know how to balance its utxo accross pools rather than a perfect target. (going over the PR comments)  \n**M** - Several points in the latest comments - the first one is about the protocol change for having multi stakepools and ratios between stakepool delegations as it was done basically for jormungandr at the time (for the ITN). This is a completely different topic and I don't see this happening any time soon in the actual Haskell implementation (for various reasons). I agree with Robert and Sebastien here that it would be cleaner and a lot easier for many of the consumers downstream but it isn't really doable at this stage from the latest feedback we got from the core team: that's why we went for a pure wallet solution regarding the multidelegation. That also doesn't prevent us from deprecating a CIP later on if this gets implemented. In the eventuality where it will be implemented we might already want to have a CIP that is compatible with that (although we have no idea if the core team would use pure floating points or use ratio like the Jormungandr team did at the time)...  \n**M** - The second point is that we cannot say that we want to use Integers (and not decimals) because we don't need the precision brought by the decimals. One might want to actually have a very precise representation of your portfolio despite the wallet not being able to enforce it, because there might be other consumers of that representation (third-party services). Taking the point of view of the wallet is a bit bias.  \n**M** - The final argument states that it would be easier to use decimals in here here because the interface will most likely display decimals to users - and most users prefer to deal with percentage or things like that rather than plainweights - Still, should the UX also impact the underlying format we want to enforce? I don't see a strong justification for one or the other in the end, it seems more like a preference matter. I'd argue for integers but I can also understand Robert's arguments. These are different approaches. I would prefer to have consistence betweek the Link approach and the JSON approach. But I don't see any strong arguments for the Decimals or the Integers really. I might be bias coming from a wallet perspective - there having integers (as plain weights) would be easier to manipulate rather than with decimals. And since it's not going to be a precise measure anyways, we don't care for floating arithmetic precision in here: it will never be exactly matching the portfolio weights anyway so being off by a few decimals doesn't really change anything to your wallet distribution. Plain decimals might be more transparent for people, especially if we require decimals to have a fixed number of places, and the scope may be between 'this' and 'this', to represent actual precentage. The annoying thing (with decimals) is that we likely want them to sum up to 1. It would make no sense to have a portfolio delegating '150%'. Integers as weights would solve this from context.   \n**S** - I still need to reflect on the comments, but have commented loosely a few times. I will get back to this.  \n=> leaving in review for next meeting + Flag to Robert.  \n\n\n#### Cardano URI Scheme  \n([PR86](https://github.com/cardano-foundation/CIPs/pull/86) / Update to CIP-0013: \"Cardano URI Scheme\")  \n**M** - A similar conversation, this time from the Link perspective - the idea here is to define the portfolios as a set of stakepools but also with proportions (the equivalent of the weights in the earlier proposal). With the proportion as a decimal number, any number of digits and any number of decimals as well. Not sure how much more can be said beyond what was earlier discussed for [PR82](https://github.com/cardano-foundation/CIPs/pull/82).. (reading in the PR) This is the same meaning as the integer weights, it simply defines fractions of decimals, the proportion itself is still to be interpreted in the context as integer proportion - what I said previously (about having to sum up to 1) doesn't really apply here. Putting aside the integer/decimal question, there should be ONLY ONE WAY to specify proportions. Here it suggests a lot of different default cases (\"if there is no proportion\", \"if there is only one\"...) If no proportion is given, it should be an invalid proposal IMO (in the same way that weights should always be required in the other proposal). If a stakepool is mentionned multiple time it should also be invalid. (adding a commment in the PR)  \n\n\n### Discussions  \n\nN/A \n\n### Close      \n\n=> Review next meeting: [PR85 - \"NFT Metadata Standard\"](https://github.com/cardano-foundation/CIPs/pull/85) (tentative ‘CIP-0020’)  \n=> Review next meeting: [PR82 - \"Cardano Delegation Portfolio\"](https://github.com/cardano-foundation/CIPs/pull/82) (tentative ‘CIP-0017’)  \n=> Review next meeting: [PR86 / Update to CIP-0013: \"Cardano URI Scheme\"](https://github.com/cardano-foundation/CIPs/pull/86) - Update to CIP-0013  \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)                                                                | Active                |\n| 2                 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002)                                                  | Draft                 |\n| 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                                                      | Draft                 |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                                                            | Draft                 |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                                                     | Draft                 |\n| 6                 | [Stake Pool Extended Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0006)                                               | Draft                 |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                                                       | Draft                 |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                                                            | Draft                 |\n| 9                 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009)                                                         | Draft                 |\n| 10                | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                                        | Draft                 |\n| 11                | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)                                           | Draft                 |\n| 12                | [On-chain stake pool operator to delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012)                    | Draft                 |\n| 13                | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013)                                                         | Draft                 |\n| 14                | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014)                                              | Draft                 |\n| 15                | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015)                                          | Draft                 |\n| 16                | [Cryptographic Key Serialisation Formats](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0016)                                    | Draft                 |\n| 19                | [Cardano Addresses](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0019)                                                          | Draft                 |\n| 1852              | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852)                                                     | Draft                 |\n| 1853              | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853)                                                    | Draft                 |\n| 1854              | [Multi-signatures HD Wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1854)                                                | Draft                 |\n\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-05-25.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [May 25 2021 notes](#may-25-2021-notes)\n  * [Triage](#triage)\n      + [PR66 / \"Fair Min Fees\"](#Followups)\n      + [PR21 / \"Non-Centralizing Rankings\"](#Followups)\n  * [Last Check](#last-check)\n  * [Review](#review)\n      + [PR85 - \"NFT Metadata Standard\"](#NFT)\n      + [PR82 - \"Cardano Delegation Portfolio\"](#Cardano-Delegation-Portfolio)\n      + [PR86 / Update to CIP-0013: \"Cardano URI Scheme\"](#Cardano-URI-Scheme)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 5/25/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## May 25 2021 notes \n\n**Attending Editors**: Matthias, Sebastien, Duncan, Frederic. Editorial Guest: Robert Phair.  \n\n\n### Triage  \n\n#### Followups\n([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - \"Fair Min Fees\")  \n([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - \"Non-Centralizing Rankings\")  \n**Frederic** - There have been some updates yet both PR are still with IOG Research. An update from Colin: he believes the mechanisms described in both CIPs to be \"fit for purpose\" and that these are now with the research team at IOG for review. Roman himself reviewed and reached out to Chief Scientist Aggelos, and is awaiting replies due to everyone pretty busy with Alonzo and other releases right now.  \n**Duncan** - I know the research group has been pretty busy with getting the A0-related things ready. I want to add that it isn't necessary to wait: we have always said that it is OK to publish technically self-coherent sufficient proposals: they don't have to be agreed or approved by IOHK research or other - really the choice should be with the original Author of that CIP, if they choose to wait for review or push for publishing. Reseach or review does not have to be a blocker for publication.  \n**Sebastien** - I feel bad that we're leaving this open but I am not sure that there is a better option really.  \n**F** - I would be more inclined to try to merge this (due to community feedback).  \n**D** - Just as long as we make it clear that the publishing has no implication/expectation for the implementation.  \n=> Loop back with authors re: publishing and update.  \n\n\n### Last Check   \n\n### Review  \n\n#### Cardano Delegation Portfolio  \n([PR82](https://github.com/cardano-foundation/CIPs/pull/82) - potential CIP-0017: \"Cardano Delegation Portfolio\")  \nJoint conversation with 86 - see below.       \n#### Cardano URI Scheme   \n([PR86](https://github.com/cardano-foundation/CIPs/pull/86) / Update to CIP-0013: \"Cardano URI Scheme\")   \n**Robert** - (re: [PR86](https://github.com/cardano-foundation/CIPs/pull/86)) The gist of the conversation is already present in the separate threads really: We're not looking at competing proposals: we want to find out how portfolio links are made, so they can define delegation to more than one pool (here as a json file), we want to make sure Standards are as simple and consistent as possible. I personally think people will want to use decimals to define delegation proportions. Then there's the question of precision also. It's a matter of user expectation/preference. In the long term it might be more difficult to have a more confining standard (that users would want to use with more variety). (This should be documented in the conversation github threads themselves rather than in meeting notes, or at least in BOTH places). I've observed with how people try to use these features in the internet landscape and they try to use it very flexibly - so unless there is a very specific reason to restrict these things from the beginning (ex: something would fail if not), I suggest making the standard as open and flexible as possible. I kinda split my comments into what would be more needed in a linking scenario ([PR86](https://github.com/cardano-foundation/CIPs/pull/86)) while the feedback on decimals is more in Mathias' [PR82](https://github.com/cardano-foundation/CIPs/pull/82). Some of the way that this was framed was due to uncertainty about precise staking ratios if at all achievable. As Matthias noted, that is a separate issue, but as it hasn't been decided one way or another it would be good to keep the standard more flexible to allow for have it not be confining later.  \n**D** - To your last point, do you mean \"specify the ratio any way we like\" and the implementer is to handle it as they choose/approximately?  \n**R** - That is what I was trying to get in my comment. Another thing I picked up is the need to have more engagement from the community. Both Matthias and I have our sides of how we feel pretty comprehensively detailed in the threads themselves - so we really need to have more engagement from the community directly - maybe IOG could raise the issue with SPOs since they would be the ones managing delegation portfolios? (Maybe it might be serving a private interest of sort re: \"not discussing it\" yet..) I think that dev channels or SPO digest should ask \"If you could link to your stakepool, how would you like to do it?\" (could link to the forum posts or github threads?) this would gather community feedback including the impact on members, how they think delegators would be affected due to the imprecise nature of delegation due to the UTXO model... all to get some more consensus on those items.  \n**D** - If what you are suggesting is \"more feedback from SPOs\", let's get in touch with Ben O'Hanlon and get him to help us with getting it as a topic in the next SPO group meeting: This will be useful to collect the feedback/opiniong from SPOs.  \n**R** - I think Ben became SPO community manager around October of last year, that's when I put out the original standalone CIP I had before it was merged with Sebastien's - I was unable to attend those \"townhalls\", I find them a bit overmanaged, where SPO can interjects to their own comments - they feel a bit one-directional.  \n**D** - That is certainly true for the events, community discussion is more for forums or telegram groups. I will speak with Ben next week.  \n**R** - That kind of visibility (where I could keep it semi-technical) for the audience would help with engagement.  \n**D** - The current schedule I see a SPO comm scheduled for next week - so will try to push for it.   \n**M** - My 2c on that conversation - the whole portfolio-decimal-thing - I think it escalated a bit more than the proposal itself: The proposal initially was covering existing capabilities of the Cardano Blockchain, not making any assumption of what might end up in the ledger or in the protocol in the future, but really how wallets TODAY can represent multi-delegation portfolios, assuming that this multi-delegation is entirely done on the wallet side (no protocol change required to do that) it's really just a way to represent having  multiple stakepools, which is achieved by having multiple stake keys in the walley and delegating to multiple pools. So the entire discussion about \"what should happen if it ever gets supported by the node\" is like a completely different conversation... and at that hypothetical time I think it would be ok to obsolete this CIP and move to a separate solution using native multistaking (if there is even such a thing).  \n**D** - I missed the conversation about fractions - Was that the \"weights as integers or decimal numbers\"? (and really they are equivalent as you could use integer ratios)  \n**M** - My pt is that Integer is simpler, while decimals provide a false sense of precision. Really the precision is absent from this entire proposal setup UNLESS we have that native support at the protocol level - But currently from the way wallets will implement that it will be imprecise (so having just integers is simpler..)   \n**R** - For cases where users might still prefer to conceptualize using decimals anyways, I documented my comments in the [Github thread](https://github.com/cardano-foundation/CIPs/pull/86#issuecomment-838550989) - looking at the marketing rather than the technical rationale, including how an architect or implementer might choose to consider it.  \n**D** - I think the nice thing about Weights is that they don't have to add up to 1.  \n**R** - Right and if I were to want to have my pool to get a 50% boost I could just set it to 1.5 if all weights were at 1. But you need a decimal for that. I'm happy to continue conversation where required.   \n**D** - I'll go over this with Ben next week and will plug you into the SPO meet for feedback.  \n=> Duncan to follow on this with Ben, Robert to possibly open the conversation with SPOs.  \n\n\n#### NFT  \n([PR85](https://github.com/cardano-foundation/CIPs/pull/85) - potential CIP: \"NFT Metadata Standard\")  \n**M** - The \"NFT metadata standard\" we've already discussed a few times - There have been some more discussions since last time we discussed. To summarize, this is a standard to summarize some metadata for NFT, at the moment of \"minting\" the NFT. The initial proposal was suggesting to put all the necessary metadata INSIDE the trasaction metadata (minting the various tokens) according to some given format. The conversation happened around \"what\" metadata should be included and what the format might be. The initial proposal was more tailored towards image NFT but tentatively opening up to more general kinds of medias. Eventually it was also suggested that storing metadata on chain was a poor move - the Blockchain being better at storing hashes (and storing the content elsewhere). Some conversation followed around using the IPFS network for storing the actual content and using the transaction metadata to link to the content itself. The idea was to store the JSON structure of the NFT metadata on the IPFS network (name, description, mediatype.. ) while on the Cardano blockchain would be a \"link\" to that location. Since then, some responses have occured (going over onscreen). A lot of good things noted, converging towards \"offloading the actual metadata content to other (different) networks\". Right now this CIP hints at IPFS - but really this CIP might not require IPFS specifcially and be open to use other storage network. The good thing is IPFS is addressable and verifiyable at the same time. The structure itself could be \"free\" or specified in a different CIP than this one. This one then would be about \"how to get metadata\" but then we would have other (possibly competing) CIPs focused on specific types of netadata, ex: NFT audio file or NFT image, or NFT Legal contract... Allowing for various different formats and it would be up to the applications consuming these formats according to the format they align with/by. This would be very much how \"mediatype\" works on the web - where you fetch a particular ressource, obtain the mediatype, which then lets you interpret the bytestream from whatever server you're fetching that resource (ex: a PNG image). Here you'd get \"some\" metadata from the link, anf the link itself tells you what type of metadata that is, and if your client can interpret/consume that type they are free to manage it as desired (or report an error if unable to or other).  \n**F** - The last comment seemed about spliting it in two (CIPs) - this one about \"obtaining\" the metadata and the other about identiying the varied types/structures. Without updates from the CIP Author since, this might be tabled despite the conversation..    \n**R** - If the scope of this \"NFT standard\" was as broad as some of the participants would want it to be, schema.org tags could be used. Not sure where the best place for that vocabulary would be though - just that the vocabulary might be used/useable at some future time if the CIP remains general.   \n**Roberto** - Completely agree with Robert, I have been pushing the conversations towards schema.org way of representing assets/events - not just about NFT metadatas but so that any metadata stored onchain becomes a bit more explicitly defined - so that it becomes \"web-semantic friendly\". These metadata standards would be good if we pushed metadata to be stored externally and explicitely call metadata URL/URI so it's clear we don't expect a json object on that key. (+ agreeing re:metadata Schema URLs comment)   \n**M** - Really scoping this CIP has been a URI to a particular metadata file and probably rely on Schema.org and provided schemas here to describe varied media contents types. This should already be quite complete to cover a lot of usecases. But also quite large in a way: some projects might want to restrict the space, but should be fine.. (ALSO a good example of why \"storing this onchain\" is a a weak idea - there can be a LOT of metadata later on).  \n**Clark** - the problem with most metadat ais that offsite requires a caching layer and multiple http requests to display   \n**M** - But what's the cost a of a http request compared to making the chain 10 times bigger? We won't really get rid of the cost of fetching data.   \n**F** - How to proceed re this CIP then? It has been in the background for some time. Alexandro commented in there that he'd be willing to split it or rework it..   \n**M** - Currently writing a few suggestions to move this forward and check in with Author to see if he agrees on the varied pts.. Let's wait for updates before setting it back to \"review\" for the follow meeting.   \n=> Adding a note in the PR - moving things out   \n\n\n\n### Discussions  \n\nN/A \n\n### Close      \n\n=> Updating PRs with conversation, will reach for SPO feedback on the matter (Robert) re:[PR82](https://github.com/cardano-foundation/CIPs/pull/82)/[PR86](https://github.com/cardano-foundation/CIPs/pull/86)  \n=> (Matthias) Adding conversation and outreach in [PR85](https://github.com/cardano-foundation/CIPs/pull/85) \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)                                                                | Active                |\n| 2                 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002)                                                  | Draft                 |\n| 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                                                      | Draft                 |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                                                            | Draft                 |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                                                     | Draft                 |\n| 6                 | [Stake Pool Extended Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0006)                                               | Draft                 |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                                                       | Draft                 |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                                                            | Draft                 |\n| 9                 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009)                                                         | Draft                 |\n| 10                | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                                        | Draft                 |\n| 11                | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)                                           | Draft                 |\n| 12                | [On-chain stake pool operator to delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012)                    | Draft                 |\n| 13                | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013)                                                         | Draft                 |\n| 14                | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014)                                              | Draft                 |\n| 15                | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015)                                          | Draft                 |\n| 16                | [Cryptographic Key Serialisation Formats](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0016)                                    | Draft                 |\n| 19                | [Cardano Addresses](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0019)                                                          | Draft                 |\n| 1852              | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852)                                                     | Draft                 |\n| 1853              | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853)                                                    | Draft                 |\n| 1854              | [Multi-signatures HD Wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1854)                                                | Draft                 |\n\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-06-08.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [June 8 2021 notes](#june-8-2021-notes)\n  * [Triage](#triage)\n      + [PR66 / \"Fair Min Fees\"](#Followups)\n      + [PR21 / \"Non-Centralizing Rankings\"](#Followups)\n      + [PR85 / \"NFT Metadata Standard\"](#NFT)\n      + [PR82 / \"Cardano Delegation Portfolio\"](#Delegation)\n      + [PR86 / Update to CIP-0013](#Delegation)\n      + [PR89 / Update to CIP-0015](#CIP0015)\n      + [PR97 / Update to Autogen script](#Update-Script)\n      + [PR88 / \"Cardano dApp-Wallet Web Bridge\"](#dApp-Connector)\n  * [Last Check](#last-check)\n  * [Review](#review)\n      + [PR96 / \"Forging policy keys for HD Wallets\"](#Forging-keys)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 6/8/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## June 8 2021 notes \n\n**Attending Editors**: ~Matthias~, Sebastien, Duncan, Frederic. Editorial Guest: Robert Phair. Kevin Hammon (IO Research).  \n\n\n### Triage  \n\n#### Followups\n([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - \"Fair Min Fees\")  \n([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - \"Non-Centralizing Rankings\")  \n**Frederic** - Both of those are effectively tabled until we hear back from CSO Aggelos or if the author is fine with moving forward we can merge appropriately.  \n**Kevin** - Re: PR66 / \"Fair Min Fees\" - IOG is considering this and there is a blog post Aggelos has put together relating to the fee structure that should be pushed around now.  \n**K** - All fee-related parameters, how they work, are set and the levels. Also min/max settings. Expect an encompassing blog post.   \n**D** - So it may or may not address this ([PR66](https://github.com/cardano-foundation/CIPs/pull/66))...   \n**F** - Any update on [PR21](https://github.com/cardano-foundation/CIPs/pull/21)?   \n**D** - I think the same point applies, which is that the researcher have just about completed and are about to provide internal feedback on the pledge benefit curve ([CIP-0007](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0007/README.md)) proposal. It doesn't directly address this PR but it addresses in some sense what comes before that: incentives leading to ranking. So one might want to rethink/adjust \"ranking\" post incentive tweaking.... I think the situation is basically as it was before and Shawn should be in his right to push for the publishing of these proposals: The researchers at IOHK will get to those proposals in time. Not everything has to be what everyone agrees with and what gets implemented might be a gradient of those.  \n**K** - Expecting good news on that is the near future..   \n**D** - Shawn might want to revisit the proposal pending changes.  \n**K** - The blog is in the final stages, might be out already.   \n**F** - Any other update from IO Research?  \n**D** - The big one is the one just mentionned, the pledge curve, touching to A0.  \n**K** - What we are expecting to see there is a revised pledge-related reward formula: The researchers have been measuring the effects under Myopic and non-Myopic situations. The model proposed by Shawn in his CIP unfortunately had some issues: it works under some situation but not under ALL situations that we would like. The change rationale/rework will likely have the effects Shawn was intending but would not be the same exact same formula.   \n**D** - Yes. It does have implications on rankings, as part of looking at the pledge curve they also looked at wether it's okay to look at Myopic vs non-myopic views adn part ofthe question was wether it's more interesting to look at the long term vs. short term. Again, it's very clear that he has a reasonable proposal and it would be fine to publish as is.  \n=> Moved to (Last Check) post-email follow-up  \n\n#### Delegation\n([PR82](https://github.com/cardano-foundation/CIPs/pull/82) - potential CIP-0017: \"Cardano Delegation Portfolio\")  \n([PR86](https://github.com/cardano-foundation/CIPs/pull/86) / Update to CIP-0013: \"Cardano URI Scheme\")   \n**F** - Any update on the current outreach to the community?  \n**Robert** - I have been in touch with (IOHK) Lenna Onto regarding joining the upcoming \"SPO community call\" this Thursday (June 10th) where I will introduce the stakepool links and confirmed there would be a more general CIP/SPO meeting in two weeks (June 24th). We only have space to introduce the PRs, some links to the discussions and talk about what is coming up in the future + how that would enable the delegation options (json, ++ ). The point of this intro is to start getting feedback from SPOs, maybe get some timeline, expectations of precision and what else might have come out and/or suggestions, pushing users towards posting in the forum or github threads, and remind that the merging/inclusion in the CIP repo does not imply implementation (Governance process being separate and also needing their voice). Trying to get that in 5 minutes and opening up to a question is the aim for that meeting, with the follow-on meeting as a way to onboard SPOs further in the CIP conversation.  \n**F** - So the follow-on SPO community meeting on the 24th is specifically the \"delegation\" meeting? Or should it be a more broader look at the CIP framework?  \n**R** - Up to Ben's team. I've made myself available to jump in to educate as much as feasible. I think the focus is going to be JUST about CIPs.  \n\n#### NFT\n([PR85](https://github.com/cardano-foundation/CIPs/pull/85) - potential CIP: \"NFT Metadata Standard\")  \n**F** - [PR85](https://github.com/cardano-foundation/CIPs/pull/85) (NFT metadata standard) was discussed at the last meeting - there was a new comment in there from Matthias...   \n**Sebastien** - I read through last comments and I think it makes sense, but the conversation seem to have died afterwards. We have to figure out how we define when the PR/CIP is good enough to be merged.  \n**F** - The past back-and-forth here (on this PR) appeared to be consolidating towards a Schema.org-style of disintermediating, using some kind of subspace of ... NFT space thing?   \n**S** - Alessandro (PR author) has the last comment rather open - as Editors we might have to step in to figure out the path to proceed - ex: there is no discussion, do we close, merge, etc... we should do something.  \n**F** - Without Matthias present (as the closest to this PR) we are lacking maybe closer educated opinion.  \n**D** - Clearly a topic with a lot of interest and we should probably be guided by \"has the state of discussion died down enough to..\"  \n**S** - Alessandro not providing clear steps, folks already having implemented this standard, Alessandro currently working on building his own wallet: there seem to be grounds for merging - some standard is emerging.  \n**D** - \"Existing Implementation\" is a good step toward considering something as becoming standard: competing standards are perfectly OK.  \n**S** - IOHK has a wallet, Emurgo has a wallet and everybody who has a wallet is interested in joint NFTs in some way shape or form: it would be nice if we could coordinate and wrap this up so it doesn't cause issues later.  \n**D** - Have you checked if this is \"more\" about images? (or if it should be exclusive to images or other..)  \n**S** - That is what Matthias' last comment is about (trying to use a schema) but there's no clear path forward after this. At this point up in the air, previous discussions were about spliting it up (i.e. for Images and other kinds) but I don't know of anyone who actually put in the work for doing that.  \n**F** - We are at a standstill - I propose we move this for Review for next meeting and invite Alessandro to the follow on meeting. (**S** - He's very active on social, let's reach out).  \n=> [PR85](https://github.com/cardano-foundation/CIPs/pull/85) - \"NFT Metadata Standard\" moved to next meeting's Review + Author (Alessandro) invited to next meeting  \n\n#### CIP0015\n**S** - [PR89](https://github.com/cardano-foundation/CIPs/pull/89)/Update to CIP-0015, should be good to merge NOW, it's just updating the test vectors (matching what has already been implemented): For Round4 (Catalyst Fund4) they decided that the address specified in the metadata would not be the receiving address for rewards and rather the rewards would be handed out via mirror certificate again.  \n**F** - Do we need Matthias to review?   \n**D** - Happy to merge this one as-is.  \n=> Merge NOW   \n\n#### Update Scripts\n**S** - [PR97](https://github.com/cardano-foundation/CIPs/pull/97) \"Script to update ...\" is not something that should be processed through the actual editorial grooup, not a CIP itself  \n**F** - I'm assuming it is touching to the auto-generated site located at [cips.cardano.org](https://cips.cardano.org/) helps people browse CIPs themselves.  \n => Move to merge as soon as we have CF FrontEnd review.   \n\n#### dApp connector\n**F** - the next one is [PR88](https://github.com/cardano-foundation/CIPs/pull/88) - \"Cardano dApp-Wallet Web Bridge\". Did you get to look at it?  \n**S** - Not worth talking about today: they are still tweaking a lot of things in there.  \n**K** - Work on the dApp connector is being done within IOG...  \n**S** - They (IOG) are welcome to add comments in this PR then: Yoroi ppl are implementing it now, and others in the community are also implementing this as-is. So there is a more involved conversation happening as usecases are still emerging. This will change over time and that's why I feel it's not worth digging into it, folks are adding comments in the threads.  \n=> Tabling PR88 for FUTURE meeting conversation   \n\n\n#### Other\n**F** - [PR80](https://github.com/cardano-foundation/CIPs/pull/80) seem ready to merge. It adds to CIP-0010 (registry namespacing)  \n**S** - Is this related to SPOCRA? It's been some time and things are a bit stale: If they are actually using this and there are transactions on chain that use it, I don't mind merging it. (I don't know if they ever did anything with it as there are no comments)\n=> add to the thread and ask for example of use  \n**F** - [PR83](https://github.com/cardano-foundation/CIPs/pull/83) - any reason why this is on hold. (**S** - No comments in there so on hold)  \n=> do nothing.   \n\n\n\n### Last Check   \n\n\n### Review  \n\n\n#### Forging keys\n**F** - [PR96](https://github.com/cardano-foundation/CIPs/pull/96) (potential CIP-1855: \"Forging policy keys for HD Wallets\") - that's Derivation path for forging Tokens.  \n**S** - No rush to do anything, PR is kindal stalled. Not much to go over. I think it's fine as-is and wouldn't mind merging it. It isn't anything too significant, just that we need a set of keys for forging tokens, unrelated to the wallet itself (not like you're forging from your wallet). They needed some key to forge, this is the same thing they did for Catalyst registration - and so created a derivation path for it. Same template, just change the path.  \n=> move to Last Check for next meeting + add Matthias for review.   \n\n\n### Discussions  \n\n**F** - (thoughts about proactively trying to advance the CIP statuses as most remain as \"Draft\") + (Discussion)  \n**R** - There's been only a couple of ppl interested in pursuing the SPO links (publicized in the forums late september and a few other places) - see links. Because of the way things delvelopped, nobody know about it and we will have to wait until thursday to get some feedback. This information about the potential of SP links, we tried to get it in the forefront about 8 months ago before folks here pushed to discuss.  \n**K** these are the links to known stakepools right? (**R** - yes). I've seen SPO discuss this on TG and they weren't aware of this somehow pulled. The SPO that we pulled were picked rather than nominated.  \n**R** - Glad that we're getting it out in the open  \n**K** - This is on a private TG channel. If you want to get something in front of the SPO community then Ben is the right guy to contact for that. We have channels we use to inform SPOs..  \n**R** - I subscribed to that list yet I thought it was already made clear (that the CIP was there and what it would do, including marketing potential for SPOs) a few months ago. I thought that that meant that the issue wouldn't be covered in his channel. People were talking about publishing videos and other.  And so many people might be linking to their stakepool...   \n**K** - you need to ask Ben there.  \n\n\n### Close      \n\n\n=> Move to **Last Check** - [PR21 - \"Non-Centralizing Rankings”](https://github.com/cardano-foundation/CIPs/pull/21) - potential 'CIP-0018’)  \n=> Move to **Last Check** - [PR66 - “Fair Min Fees”](https://github.com/cardano-foundation/CIPs/pull/66) - potential 'CIP-0017’)  \n=> Move to **Last Check** - [PR96 - \"Forging policy keys for HD Wallets\"](https://github.com/cardano-foundation/CIPs/pull/96) - potential 'CIP-1855’)  \n=> Move to **Discussion** - [PR82 & PR86 - stakepool delegation PRs](https://github.com/cardano-foundation/CIPs/pull/82)  \n=> Move to **Review** - [PR85 - “NFT Metadata Standard”](https://github.com/cardano-foundation/CIPs/pull/85) - potential 'CIP-0020’)  \n=> Merge **NOW** - [PR89 / Update to CIP-0015](https://github.com/cardano-foundation/CIPs/pull/89)  \n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)                                                                | Active                |\n| 2                 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002)                                                  | Draft                 |\n| 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                                                      | Draft                 |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                                                            | Draft                 |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                                                     | Draft                 |\n| 6                 | [Stake Pool Extended Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0006)                                               | Draft                 |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                                                       | Draft                 |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                                                            | Draft                 |\n| 9                 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009)                                                         | Draft                 |\n| 10                | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                                        | Draft                 |\n| 11                | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)                                           | Draft                 |\n| 12                | [On-chain stake pool operator to delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012)                    | Draft                 |\n| 13                | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013)                                                         | Draft                 |\n| 14                | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014)                                              | Draft                 |\n| 15                | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015)                                          | Draft                 |\n| 16                | [Cryptographic Key Serialisation Formats](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0016)                                    | Draft                 |\n| 19                | [Cardano Addresses](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0019)                                                          | Draft                 |\n| 1852              | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852)                                                     | Draft                 |\n| 1853              | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853)                                                    | Draft                 |\n| 1854              | [Multi-signatures HD Wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1854)                                                | Draft                 |\n\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-06-29.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [June 29 2021 notes](#june-29-2021-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n      + [PR66 / \"Fair Min Fees\"](#Followups)\n      + [PR21 / \"Non-Centralizing Rankings\"](#Followups)\n      + [PR96 / \"Forging policy keys for HD Wallets\"](#Forging-keys)\n  * [Review](#review)\n      + [PR85 / \"NFT Metadata Standard\"](#NFT)\n      + [PR83 / \"Multi-Stake-Keys Wallets\"](#MSK-Wallets)\n  * [Discussions](#discussions)\n      + [PR82 / \"Cardano Delegation Portfolios\"](#Delegation)\n      + [PR86 / Update to CIP-0013: \"Cardano URI Scheme\"](#Delegation)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 6/29/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## June 29 2021 notes \n\n**Attending Editors**: Matthias Benkort, Sebastien Guillemot, ~Duncan Coutts~, Frederic Johnson. Editorial Guest: Robert Phair, Alessandro Konrad.  \n\n\n### Triage  \n\n### Last Check   \n\n#### Followups\n([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - \"Fair Min Fees\")  \n**Frederic** - Fair ammount of conversation occured. Shawn (PR author) has confirmed by email that he would like to push for this merged. A lot of the conversation about this has occured, including some from IO Research in comments (See Colin's comments) as well as a Blogpost by IOHK but some of the feedback.   \n**Robert** - Colin's comment clarifies a lot of things for everyone: It's hard to argue against a minimum fixed fee if we can wait until a min variable fee comes on, because then that prevents the combination of people feeling compelled to have 0 minimum fixed fee as well as 0 minimum variable fees. I think that's what some of the SPOs were worried about, as a kind of \"race to 0\"/bottom. With the min variable fee requiring a change to the protocol, whereas the min fixed fee can be done any time but would be too early without also imposing a min variable fee.  \n**Matthias** - Reminder: we can merge a CIP without it meaning it will be implemented. Merging a PR means it has been reviewed and is technically valid, but might still not get implemented.  \n=> Merge NOW as a CIP-0023  \n\n([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - \"Non-Centralizing Rankings\")  \n**M** - The main problem that people have with the current ranking system (which is also its main point in a way) is that it is not fair for pools \"beyond\" the **k** limit (the system is trying to establish homeostasis around k, fixed by the protocol -currently 500- and pools that are beyond k appear unprofiteable - this is by design as the system is trying to achieve \"k\" pools) Pools beyond k are punished quite severly in the rankings, such as appearing unprofiteable. What this proposal here is doing is smoothing a bit the transition beyond K so that there is no more hardcut, but it is smoother... If you are close to k, then you get less punished than if you are severly further out. It makes the transition a bit smoother.  \n**R** - Happy to move this forward. Meanwhile (I don't know if it's within the scope of this PR but) if \"ranking\" is always showing for every pool, then it will have a centralizing effect. Ex: for pools outside of k=500, will users get flags about the \"beyond k\" pools? (even from following an external delegation link ala [cip 13](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/README.md)) there might be red flags and warning signs from the current discrimination, which would effectively centralize stakepools, and I want to go on record about this.  \n**M** - Not sure the title aligns with the CIP though / this should be about \"non-centralizing\"... If you limit the number of stakepool then you are acting against decentralization. But we can adjust K if the goal is not acceptable, ex: from 500 to 2000 and such as needed - that was a bit the rationale about that. We have to find the sweet spot where you make most of the people happy and still achieve good decentralization?  \n**R** - You might say something like \"less abruptly centralizating rankings\"? hard to put that into few works.  \n**M** - It will not prevent having flags/warnings and still having a lot of incentives for having \"less\" than k pools because the entire system is designed around that... So if you really want to have \"non-centralized rankings\" then we probably need to rework the entire ranking system and not have that designed around k. And that's a totally different endeavor. I would agree with **R** and propose \"less punitive rankings\" as a better title. I would push for merging this as draft and then notify the author about the cosmetic changes.  \n=> Merge NOW as CIP-0018  \n\n#### Forging keys\n([PR96](https://github.com/cardano-foundation/CIPs/pull/96) - \"Forging policy keys for HD Wallets\")  \n**M** - The PR is straightforward - it's based on another proposal we've done around derivation paths. Here it's about agreeing on a specific HD path in the wallet to derive a set of keys, reserved for forging policies. People have so far been using arbitrary keys (generated on the fly, not attached to any wallets), or payment keys associated with their wallets, which is not necessarily good (You typically want to separate the activities such as 'payment' and 'forging policies' so that the security can be granularily adjusted). It's getting quite common to use 'purpose' for a new purpose. Only remark I had in there was a path in the file, which seem to be a copy/paste leftover. Beyond that, good PR.  \n**S** - Last I looked, conceptually fine.  \n=> Merge NOW as CIP-1855\n\n\n### Review  \n\n\n#### NFT\n([PR85](https://github.com/cardano-foundation/CIPs/pull/85) - potential CIP: \"NFT Metadata Standard\")  \n**Alessandro** - (PR Author) The Metadata Standard is meant not solely for images but any kind of mediafile. I made an update in the conversation about how I would propose to adjust it. (Looking at [conversation nested in a comment](https://github.com/cardano-foundation/CIPs/pull/85#discussion_r629120254)). There is this files\" property, that is where you could specify any kind of mediatype you want. The basic idea about having \"image\" (field) separate is that nfts are 99% images already and the \"image\" field can double-function as a thumbnail. There are mediafiles like video or 3d models that you could have as nfts, yet most wallets would likely not display those properly. Here an \"image\" would enable a better UX for representation. SO two functionalities - it could either be a thumbnail, or the actual Image. The 'files' property meanwhile is an array where you might even put multiple files in there. That's the general idea. My issue with schema.org is that I'm not sure how to put that in because this is not only one type of medium: there are multiple mediums in there...  \n**M** - You mention that you want types beyond images: [schema.org](https://schema.org/) actually provides json schemas for a lot of different media contents, not only images. And for each of those schema types - I think they have all the possible fields you could imagine on such a schema - The idea is not to require all those fields, but (if you have a list of files) you must have at least as the first type, the **type of object** that you are going to use, and then the rest of the schema will fall from the definition on schema.org, which gives you a broad level of extensibility. For example if the object type is image, then you know that any of the other fields might be present. And maybe we could specify some 'fields' to be mandatory and have applications relying on that, for example the exact mediatype for the iamge - jpeg, png, whatever... That was my past suggestion: let's rely on something that is battle-tested and has been proved to work as json schemas, but maybe for a few handpicked mediatypes require some fields to be mandatory. For example image, \"at least X,Y,Z,..\"  \n**A** - The issue is that there are already nonstandard NFT projects out there, such as with a not-very-normal mediatype where the image is created out of a piece of code and the code is embedded in the metadata. I don't think (that for something like this) there is something on Schema.org... So we probably would have to support both cases.  \n**M** - I wouldn't be so formal, there are lots of different types. Creative content/Code might fit in some of the existing categories.  \n**R** - Schema.org would also provide / an already agreed-upon framework for representing ownership, as well as objects that may not be pieces of data, representing real-world objects (people, events, other). There are many usecases for NFTs beyond digital.  \n**M** - There is actually a  \"software sourcecode\" datatype... Plus also as Robert mentions,  all the other (extra) properties that come on other schemas.  \n**A** - There are already a lot of projects following this standard/CIP: If we want to add schema.org style, maybe we could move that towards a v2.0 so we can support both still?  \n**M** - That would work. About the 'image' field with the double functionality: for a Standard you might expect everything to have (only) one purpose, that's why I propose to move it to 'thumbnail', so that has one singular purpose (and use 'files' to store the actual image data).  \n**A** - It's not only for thumbnails though. If you want to make a very simple NFT (an image), you can just use the name and the actual image and THAT is the actual NFT.  \n**M** - You could use the name and under 'files' have the actual image NFT itself. From an application standpoint everything is then more consistent, You only have a single way to process NFTs there (otherwise you always need to have a special case for 'images')  \n**A** - So you would add the same file under 'files' as well as under 'image'?  \n**M** - Yes: I would rather put the NFT content under 'files' because that's where the actual NFT goes. If the specification says \"your NFT file goes in the 'files' property\" then there shouldn't be a special case for image. If you want to have a thumbnail for the image it can still be created. Any application reading this can treat it in a consistent and singular manner to consume/handle. It eases the consumption/processing of that NFT. It doesn't make it much more complicated, but it makes it easier for the application consumers.  \n**A** - For the end-user it might be a bit weird to have to put the same object twice.  \n**M** - That's a UI problem, not a end-user problem. The user doesn't really care about the NFT format. The format here is meant to be digested by machines, not by humans. If it is not really appealing to humans that's not really a big deal so long as it is easy to process by a program.  \n**A** - This could work. I think that sounds fine as a tentative future v2.0  (schema.org, thumbnail...)  \n**M** - If everyone is already aligned with the current v1.0 as-is, no point changing yet. But it sounds good as a v2.0.  \n**A** - Another question around the mediatype/MIMEtype. Is that something that needs to be added?  \n**M** - No - I would rather go with the actual object name itself (on schema.org). A bunch of specific types are listed on the main page - either name of the type or just a link to the schema.org page that contains all the propoerties of that type. Maybe feasible to even have it directly to a json schema (link), so you might even download the schema and validate against it if you have to (for an application).  \n**F** - Regarding PR85 - prior point was that usecase that it is starting to establish some kind of standard, should we merge or continue to review?  \n**M** - Suggest merging it as-is, it's being used (plus Alessandro might open a new PR towards a v2.0).  \n**A** - I still need to merge in the latest comments.  \n**R** - Can you possibly include also a roadmap to 2.0 to hear what you're thinking about (users might want to select wether to stay with v1.0 or x.0 ..)?  \n**A** - Can add.  \n=> Alessandro to add changes, Moving to 'Last-Check' for the next meeting.  \n\n\n#### MSK Wallets\n([PR83](https://github.com/cardano-foundation/CIPs/pull/83) - potential CIP: \"Multi-Stake-Keys Wallets\")  \n**M** - There has been a lot of interest around the ideas of multi-delegation, portfolio stuff and such. This PR is actually the CIP introducing multidelegation and its stakekeys (not the portfolio one that focuses on the format itself of the protfolio). I was thinking with Johannes about how we could do multidelegation on the wallet in a safe manner. Because that isn't actually a trivial problem and is why multidelegation has taken quite a long to come for Cardano - it isn't something that can be implemented at the protocol level currently, it has to a burden handled at the client/wallet level. For wallets to maintain multiple stakekeys can be cumbersome because the keys have to be managed independantly, and you have this whole mess of key registration/ delegation/deregistration etc... So once you have created an address and you put a stake key inside the address, that is fixed: that stake key will be in that address forever. The only way you can change the stake rights of the funds associated to that address is by changing the delegation settings of the stake key. But you can only delegate to a singular pool per stake key, and you cannot put multiple stake keys in an address, which means the wallet must do some form of key management, of rebalancing of its UTXOs (Cardano being a UTXO-based blockchain, we don't have the freedom accounts-based chains have, picking arbitrary ammounts and buckets of Txs). Here we have to select a particular number of UTXOs that have particular values and assign them to different pools. You can't arbitrarily fragment or defragment your UTXOs to adjust accordingly, but that's all work that goes on through wallets, and when you do that you also have this problem of the blockchain being a completely decentralized system. Many people today have more than one wallet, using Yoroi + Deadalus or Apple lite... there are many entry points to the system, doing modifications concurrently, and chain forks (especially in Ouroboros Praos), every 4 or 5 blocks there are forks with leaders getting elected on the same block which means (from a wallet standpoint) if you send a Tx, your Tx might get rolled back after a few blocks. It might get further inserted in the ledger and later disappear. If you are not too careful about your registration, and you want to be able to fully recover the state of your wallet from the blockchain state, you have to be very careful on how you activate chains of deregistration, because any of them might actually disappear because there would be a rollback on the chain fork. The true immutability is quite long on Praos at the moment - around 36 hours, beyond which you can be sure there won't be a rollback: the maximum length of the fork is fixed by the protocol. One of the first proposals touching multisig stakekeys proposed to wait 36 hours between each key registration, and was a poor UX of sorts. Even though you're not creating new keys constantly, you might want to do this a few times in short span when managing:  delegating to a pool, changing your mind, switching to a different pool or other - waiting 36 hours between changes was poor experience.Because we already have a mechanism that makes sure that everything is sequentialized and cannot end up in a corrupt state: The UTXO model itself. So here one of the pain point can therefore become an advantage and guarantee ordering - The idea is to attach a particular UTXO to every stake key registration (or deregistration) so that there is ever only one UTXO that is consumed every time and passes from one registration to the next. It would contain only 1 ada, have no value except the minimum and is consumed by every registration such that if any (previous) registration gets rolled back, then each subsequent registrations are automatically invalidated as consuming a UTXO that no longer exist. Like that you enforce that what you see on the chain is really reflecting the state of your wallets. And there is no more risk on the (?)external or anything. If have two wallets at the same time doing key management or registration and submiting conflicting Txs, in the end the ledger itself will make sure that only one of the transactions goes through as only one UTXO can be consumed. For creating that special UTXO, we have also chosen a custom derivation path that isn't confliction with other payment keys of the wallet, such that the UTXO cannot be consumed inadvertently by the wallet during its normal operation, and for wallets that don't implement THAT CIP and meanwhile implement CIP-1852 (like most wallets today), then it's completely transparent and this won't interfere with the wallet activity. If the wallet then chooses to implement multi-stakekey delegation then they can implement that and use the special UTXO. This is this CIP - there were some questions in there already from Marcel Clamer which made me think that we might be able to clarify some things in the CIP itself, such as \"Why\" / \"Why use a UTXO like that\" I thought this was clear but apparently not enough - I will loop back and  update on the PR and clarify some points, plus also translate the diagram Johannes is pointing to into something a bit more acceptable for the CIP. We have a first implementation going on in the wallet, which has so far been successfully tested on a harnet prototype. This is being finalized and also comforts us in the sense that this is indeed doable and works as we expect. There has been quite some extensive testing done on that with various scenarios - creating concurrent requests ... and we are now pretty sure this resolves the problems we might have with concurrency and a decentralized system.  \n**S** - Everything said makes logical sense.  \n**M** - I want to get some of the insights from Marcel's comments in there, such as making the intent clear and capturing some of the reasons in the body of the content. I would maybe prefer to review it again next time.  \n**F** - we're getting a bit crowded on the review space. Would move to 'Last Check' to leave room for other CIPs to be reviewed.  \n=> Moved to 'Last Check'  \n\n\n\n### Discussions  \n\n\n#### Delegation\n([PR82](https://github.com/cardano-foundation/CIPs/pull/82) - potential CIP-0017: \"Cardano Delegation Portfolio\")  \n([PR86](https://github.com/cardano-foundation/CIPs/pull/86) / Update to CIP-0013: \"Cardano URI Scheme\")   \n**R** - (About the Delegation conversation and Robert's outreach to the SPOs). Everyone knows about the conversations, there were 3 meetings - the first meeting (with SPOs) was on the 10th, then Frederic came on to the following meeting (two weeks later) mentioning the PRs, and I also met with SPOCRA (grouping of the large pools). The people who actually might need this CIP the most might not be in the SPOCRA meeting I attended then, so not a representative sampling of the pools. But longtime members were supportive of the process, the threads, that they know they can contribute on, also in github conversations. I think they are very practical-oriented people, and so are looking more at CIPs to align with a timeline, with some expectation of accountability. Which doesn't seem to sit well with the current iteration of what the CIP framework is for (more towards a standards body). Here's a link of how the SPOs are currently discussing it in their own forums, so any member of the community or orgs, anyone is welcome to join and follow how the issues are currently being presented to the SPO community (I have agreed to give them an update every few weeks on CIP and governance). Meanwhile IOHK's Daniel Ribar posted about \"Catalyst Circle\" while SPOCRA told me that IOHK brought this to a governance agency that came up with the plan for Catalyst Circle. It is a little bit toned down from what they initially recomended. From that same quarter they have issued some statement about this and Catalyst Circle being the first governance process within Cardano, there might be questions why they skipped the CIP process - I think it looks like two standards group emerging, see Daniel Ribar's post on the cardano forum. As these things evolve, we have links in both direction and all the people that we have mentioned in all those forums feel comfortable coming observe and discuss.  \n**F** - Any preference or news about the PR conversation?  \n**R** - All the people I spoke with say they would welcome both proposals merged in. On the surface they feel both are valid and would need to be there.  \n**F** - The consensus we're looking for is that we're ok merging these concurently...  \n**M** - Moving to Last Check would be fine.  \n=> Moved Both to 'Last Check'   \n\n\n\n### Close      \n\n=> Merge (**ASAP**) as CIP-0023 (Draft) - [PR66 - \"Fair Min Fees\"](https://github.com/cardano-foundation/CIPs/pull/66)  \n=> Merge (**ASAP**) as CIP-0024 (Draft) - [PR21 - \"Non-Centralizing Rankings\"](https://github.com/cardano-foundation/CIPs/pull/21)  \n=> Merge (**ASAP**) as CIP-1855 (Draft) - [PR96 - \"Forging policy keys for HD Wallets\"](https://github.com/cardano-foundation/CIPs/pull/96)  \n=> Move to **Last Check** - [PR85 - “NFT Metadata Standard”](https://github.com/cardano-foundation/CIPs/pull/85) - potential 'CIP-0020’)  \n=> Move to **Last Check** - [PR83 - “Multi Stake Keys Wallets”](https://github.com/cardano-foundation/CIPs/pull/83) - potential 'CIP-0018’)  \n=> Move to **Last Check** - [PR82 & PR86 - stakepool delegation PRs](https://github.com/cardano-foundation/CIPs/pull/82)  \n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)                                                                | Active                |\n| 2                 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002)                                                  | Draft                 |\n| 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                                                      | Draft                 |\n| 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                                                            | Draft                 |\n| 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                                                     | Draft                 |\n| 6                 | [Stake Pool Extended Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0006)                                               | Draft                 |\n| 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                                                       | Draft                 |\n| 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                                                            | Draft                 |\n| 9                 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009)                                                         | Draft                 |\n| 10                | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                                        | Draft                 |\n| 11                | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)                                           | Draft                 |\n| 12                | [On-chain stake pool operator to delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012)                    | Draft                 |\n| 13                | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013)                                                         | Draft                 |\n| 14                | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014)                                              | Draft                 |\n| 15                | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015)                                          | Draft                 |\n| 16                | [Cryptographic Key Serialisation Formats](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0016)                                    | Draft                 |\n| 19                | [Cardano Addresses](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0019)                                                          | Draft                 |\n| 1852              | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852)                                                     | Draft                 |\n| 1853              | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853)                                                    | Draft                 |\n| 1854              | [Multi-signatures HD Wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1854)                                                | Draft                 |\n\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-07-20.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [July 20 2021 notes](#july-20-2021-notes)\n  * [Triage](#triage)\n      + [PR66 / \"Fair Min Fees\"](#Followups)\n      + [PR21 / \"Non-Centralizing Rankings\"](#Followups)\n      + [PR96 / \"Forging policy keys for HD Wallets\"](#Forging-keys)\n  * [Last Check](#last-check)\n      + [PR82 / \"Cardano Delegation Portfolios\"](#Delegation)\n      + [PR86 / Update to CIP-0013: \"Cardano URI Scheme\"](#Delegation)\n      + [PR85 / \"NFT Metadata Standard\"](#NFT)\n      + [PR83 / \"Multi-Stake-Keys Wallets\"](#MSK-Wallets)\n  * [Review](#review)\n      + [PR88 / \"DApp connector\"](#DApp)\n      + [PR104 / \"Collateral Key derivation\"](#Collateral)    \n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 7/20/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## July 20 2021 notes \n\n**Attending Editors**: Matthias Benkort, Sebastien Guillemot, Duncan Coutts, Frederic Johnson. Editorial Guest: Robert Phair.\n\n\n### Triage  \n\n#### Followups\n([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - \"Fair Min Fees\")  \n**Frederic** - Process-wise we want to make sure that 3 out of 4 of the main editors have transparently approved the request. In this case you can see there are 3 already and is good to go as-is.  \n=> Merged as CIP-0023  \n\n([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - \"Non-Centralizing Rankings\")   \n**F** - The CI checks were throwing errors - Clark (CF) helped push a PR to try addressing - how would you want to proceed? I propose we can push this through and adjust later as Draft.   \n**M** - Unless Shawn has blocked it we can do a rebase of his branch by default. Will look into it.  \n=> Merged (CI Resolved)  \n\n#### Forging keys\n([PR96](https://github.com/cardano-foundation/CIPs/pull/96) - \"Forging policy keys for HD Wallets\")  \n**M** - (checks gathered, good to merge)  \n=> Merged as CIP-1855  \n\n\n### Last Check   \n\n#### Delegation  \n([PR82](https://github.com/cardano-foundation/CIPs/pull/82) - potential CIP-0017: \"Cardano Delegation Portfolio\")   \n([PR86](https://github.com/cardano-foundation/CIPs/pull/86) / Update to CIP-0013: \"Cardano URI Scheme\")   \n**F** - This has about delegation portfolio, can someone update on the state of this PR?  \n**Matthias** - It hasn't changed for a month or two. That's mainly describing a JSON format for representing portfolios that can then be shared with wallets or application dealing with delegation such as SPOs. There were some divergence of opinions between Robert and I regarding what sort of structure we should try to go with for portfolios - try to offer decimals or units. Robert has a proposal that would have the SPOs represented in-URL, transporting some information in that medium, allowing decimals for weights - Not sure if we have really settled the discussion there or not Robert because there are arguments in both directions but I still don't really see why allowing decimals in weight would be useful since we can represent any number with a matter of integer fractions (multiplying the fractions by some numbers..)  \n**Robert** - We have one or two pathological cases that came up when looking at how people would practically use them if the fractions / decimals are not allowed, like the case where Stakepool weights will default to 1. If we want a long list of reducded delegation then we can't use a number less than 1 to indicate a fraction. And there were two or three cases like that we reviewed in the prior meetings, also documented in the PRs. If anyone has specific ideas regarding if those cases are problems or not. We could try to add to the PRs and have them confirmed there? All of them would be about similar kinds of boundary conditions. Some of them didn't emerge until we considered how stakepool links could be made more concise, which is why the advantages of using fractions never really came up when the json portfolios were being considered, where you basically have an arbitrary ammount of precision in files that can have any size. But then the problem needs to be considered differently if you're trying to constraint the delegation portfolio within the space of a URI (PAUSE). It may be that \"weither the decimals are appropriate for the json or not\" is actually a separate question, of weither they are appropriate for the stakepool URIS. That's why I don't feel the differences HAVE to be resolved. It could just be that the datatype for the stakepool weighta would be more sensibly integers for the json file and would be decimals for the URI. I think we could go ahead with the plan to merge as they are, rather than try to reconcile a conflict that isn't really there.  \n**Duncan** - Makes sense. No space constraint in the json and there is in the URI.  \n**F** - [PR86](https://github.com/cardano-foundation/CIPs/pull/86) changes an existing CIP - [CIP-0013](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/README.md) while [PR82](https://github.com/cardano-foundation/CIPs/pull/82) would be a brand new CIP - Does it seem fine in that way?  \n**M** - Yes, this is just an addition to an existing CIP, it doesn't invalidate what exists, just adds new primitives.  \n=> Merge ASAP  \n\n#### NFT\n([PR85](https://github.com/cardano-foundation/CIPs/pull/85) - potential CIP: \"NFT Metadata Standard\")  \n**M** - Did Alessandro get time to update as requested last time - or update to the latest format? The idea was to merge \"as-is\" since it is being used by a lot of people. Did work begin on the next version / possibly a JSON schema version?  \n**Sebastien** - I have not had the time to manually compare the JSON to see if it really matches: Can someone confirm that the commit that got added (since we last spoke about it) made it match with existing wallets and explorers? That was the only real concern with this - that the readme might not actually match what was implemented..  \n**Clark** (in chat) - \"What will happen to the minted NFTs already by the way?\"  \n**S** - The NFTs on mainnet use this specification or a variant as mentioned in comments on the PR (instead of the actual Readme) - that was the main open question and it looks like there was a commit since then to match the spec. I was hoping if someobody in this meeting might be able to clarify that this looks good here (but looks like there is nobody... ) I'll approve this PR, under the assumption that the commit fixes what was expected to be fixed.  \n**D** - Add that comment in your PR review and then we can proceed. This is not for last check is it?  \n**F** - It is.  \n**M** - There are a lot of good ideas on how to improve this one but that CIP has already been implemented by quite a few tools. One idea is to produce a new CIP version of this one, including all we discussed about format and structure so far, deprecating this one afterwards. Propose we merge [PR85](https://github.com/cardano-foundation/CIPs/pull/85), then modify it later through a new PR/version.  \n**D** - Right.  \n**F** - Should we move back to Last Check?  \n**M** - Good to merge, as soon as we get the go ahead from Alessandro that he added what was needed.  \n=> Merged ASAP once ok'd by Alessandro  \n\n\n#### MSK Wallets\n([PR83](https://github.com/cardano-foundation/CIPs/pull/83) - potential CIP: \"Multi-Stake-Keys Wallets\")  \n**F** - This is setup as a 'Last Check'. Going through prior meeting notes, everything should be fine re:merging.  \n**M** - Yes, all good. I will double check with Yohanes on the side because ihe has been working on an implementation to confirm that the CIP is actually sound. We will make an update to [CIP-0010](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010/) to point to a first implementation of it (for reference) but it's not necessary right now.  \n**D** - So is it an extension of the existing CIP that states you use index [0] and you have to folllow the derivation index?  \n**M** - It's a bit more than that: we use a **special UTXO**, crafted from a stake key so that we can actually track which is the last stake key that is **registered** on the blockchain and this way, restoring the wallet on different machines/platforms and be totally resillient to the decentralized aspect of all this.  \n**D** - So you look at it by checking at what is registered on the chain?   \n**M** - Yes, we have one UTXO that gets consumed and produced for every Stake key registratiom, which makes sure that all stake key registrations are actually sequentialized. You cannot double spend your UTXO so cannot double register a key concurrently, and if any Registrations get rollback, then you get the whole chain is rolled back because of the UTXO chaining. We have outlined a number of problem, a lot of that using some good property testing - up until the point we arrived at this idea here to propose solving all of that. It's rather cheap and transparent for the user and so is the best compromise between UX and usability we found, which still lets us completely manage the multi stake key wallets without requiring any offchain information.  \n**D** - Does that chain of UTXOs mean that all the stakekeys can be grouped together?   \n**M** - \"Grouped together?\"  \n**D** - That they are related to eachothers: Does the privacy disappear again?  \n**M** - No. Or Maybe.. You could identify probably that 'a' particular registration is linked to another registration because if you know the previous stakekey, it will... registration certificate for a new stakekey and you could link it to the previous one. It doesn't completely solve the privacy issue because you could still rollback the registrations on the chain and get it back. I don't know if we could solve it really because you would always have a link to your previous stakekey or known stakekey, unless if we only use stakekeys that are only used for registration.  \n**D** - The Privacy is not really a requirement.  \n**M** - Privacy makes things better than the current situation because it is a bit more involved, but it would still be trivial to write a script to crawls the chain and unroll / get all registrations of prior keys (unless if using UTXOs only for registration..)  \n**F** - Did you get answers regarding Marcel's comment? Should this be merged?  \n**M** - Yes. We were wondering about maybe adding a diagram to the proposal to maybe make things clearer but we have not yet come with a clear enough diagram, so that might be a future edit. Good to merge I think. Enough information in it already to work out an implementation and we will add a link to a reference implementation in Haskell when ready.  \n=>(asking for approvals for merge from Duncan/Sebastien, Matthias checking in)  \n\n\n### Review\n\n#### DApp\n([PR88](https://github.com/cardano-foundation/CIPs/pull/88) - \"DApp connector\")  \n**Rob** - (PR Author) - This PR here is similarly to something we've implemented for ERGO. It's similar to what Metamask does - it does some code injection to expose a bunch of endpoints for user wallets for DApps and it's trying to standardize this so that we can have one standard that all DApps and wallets can use (instead of having separate competing things). The conversation is ongoing on the PR already, much has been about changing the signing endpoint so far (still need to be decided), newer conversation around how to handle what happens when multiple wallets implement the same spec (how should it be handled?). Also how we want the API - as a free floating function or entirely contained within the cardano instance: be returned from that said fn() as opposed to be injected (in a two phase injection).  \n**M** - What do you mean \"what happen when multiple wallets implement...\"  \n**R** - How the spec work right now is kinda like a two phase code injection: The first phase injects a free floating function, that DApps can use to request access to user's wallet, and then the DApp can call that and the user sees a confirmation box in their wallet, and if they accept, then the rest of the API gets injected (getUTXO(), getBalance() ... etc). But what happens if there are two separate wallets? if Yoroi implements it, and Adalite implements it - that is they would both be injecting the same code...  \n**M** - but you wouldn't be using both at the same time...  \n**R** - You'd still want to choose which wallet gets open. Right now if Yoroi injects first, Adalite override the fns that the API that Yoroi would have already injected. We're going to have to figure out a way around that. I posted some into the PR, have possible suggestions.  \n**M** - My strawman suggestion is to go with namespaces: Register a particular ID for your wallet app - we can have that registry somewhere on the CIP. Then Yoroi, Adalite can have identifiers / be listed. New wallets can pick new ones. If you have many wallets that start injecting random Javascript in your page it might start becoming heavy. I don't think many people will use many wallets anyways.  \n**R** - It's an edge case, just something to consider.  \n**M** - There's also the case of other applications trying to inject things (instead of a wallet).  \n**R** - That's why we don't have super-generic names for the most part.  \n**M** - My only real worry is on the security aspect of it - all of that happens in the client/browser in a way and is very much hidden from the users. As a User you get prompted some things and you type in your passphrase or something like that .. and it's very easy for an evil DApp to inject itself and harvest your data. I am not sure how Metamask handles that problem.   \n**R** - Do you mean the code impersonating the DApp or the wallet or both?  \n**M** - The wallet  \n**R** - It could do that and could return whatever it wants to and possibly cause the DApp to do something you don't want to. Assuming that's the worry you had?   \n**M** - The DApp itself could be malicious - it could harvest passphrase or other. For example asking for a signature, where the wallet would require a passphrase to decrypt your key - which is typically handled by the wallet.  \n**R** - For the signing we are implementing a different CIP - I think CIP-0008 the messaging spec. Are you talking about a keylogger?   \n**S** - The concern is that you're using a DApp, and you click \"sign\" and it pops up a FAKE Yoroi... (**M** and basically anyone can inject javascript in the page)  \n**R** - I see - that's significant.  \n**M** - I've seen DApps impersonating Metamask - and they look like it but they are actually cataloging information on your behalf - they might not have access to your wallet but if you are using the same passphrase multiple places then you might be opening yourself to vulnerabilities.  \n**R** - Do you know how Metamask handles that?  \n**M** - I think a blogpost warning users to be careful?  \n**S** - Banks solve this at account creation and picking a picture out of a few different options and every time you go and access the bank it displays that picture (and if not your picture then you are accessing a fake version of the bank). We could do some version of this but you know, it would be 'an extra page' the user has to confirm and I am not sure how people would understand the system (or why it exists => it might not help that much)  \n**M** - We need some way, not only to authenticate the DApp onto the wallet but also the DApp on the wallet. The user needs to check that he/she is dealing with the wallet he expects to be dealing with and not some other fake app. Beyond all the UX and API we've made so far, I think there is a big big question around the security aspect of that one.  \n**R** - Would that be in scope for this? It would make sense to have a security section in there, but not sure about \"mandating\" things.  \n**M** - I worry about wallets going on and implementing this without looking at the security concern. If we just push it out as a \"wallet concern\", that's taking the risk that all the wallets will get it wrong.   \n**R** - There are several areas for security where the wallets will have to be cogniscent so that it should be \"provably secure\" rather than \"making it work\". Do you think we should have some standardized \"wallet authentication system\"?  \n**M** - Yoroi has the little 'visual checksum' when you access your wallet, that only you know in principle (unless you share screenshots). It could be that every popup has that checksum in place and you could control that you are acessing your wallet. this might be a sane way to make sure you are actually dealing with your Yoroi wallet. We could suggest that implementation push for a proof that the user is dealing with the wallet (they are expecting to deal with).  \n**R** - And on the flipside: can you think of concrete example/attack where the DApp is being impersonated (rather than the wallet)?  \n**M** - In the PR comment I gave one example around the signing function: If you are actually signing anything, do not sign an arbitrary message, and make sure you only return the witnesses and not the fully serialized transaction. As a DApp you only want to get the signature produced, you don't necessarily trust the wallet to have returned you the right thing. You want to reconstruct the tx body YOU have constructed - you want to get signatures for that and THEN do the combination yourself. You don't want to blindly trust the wallet for a serialized thing. If you blindly trust whatever you get serialized from the wallet without actually checking that this is what you passed in the first place, then that's bad.  \n**R** - There was also some discussion around partial signing as well for more complicated usecases..  \n**M** - A tx is not by default valid after a signature: could be  multiple signers required, or other arbitrary reqs.. I think that should just be the default of the API actually: you pass a particular body and you ask for a signature from one of the wallet keys, and as a DApp you have constructed the transaction so you know what to expect (e.g. if multisig you know you will require a sig from the other user)  \n**R** - When you say we were trying to sign from one key, are you specifying which key to the wallet somehow or..?  \n**M** - The idea is to point that to a particular input although in practice not only inputs require signatures: That's fine for payments but if we go a bit deeper down the Alonzo path, you can sign pretty much anything. Consider 'certificates' even - that's not even pointing at an input, that's pointing to a stakekey, or at a certificate. The signature should have a way to point to anything in the tx as \"I need a signature for that particular certificate\" -> the wallet should know which key corresponds to that and produce the appropriate signatures (after approval by the user) OR you request a public key (and the wallet can product a signature matched to that key). Might be public key hash rather than public key. I don't need a way to point to what element needs signed really, it could be many things. Or you give out the keyhash you expect a signature from.  \n**R** - Are there possibilities where the keyhash might be a bad idea?  \n**F** - short on time, let's move this back to follow-on meeting for discussion.  \n=>Discussion in the PR itself - To be Reviewed again next meeting   \n\n\n#### Collateral\n([PR104](https://github.com/cardano-foundation/CIPs/pull/104) - \"Collateral key derivation\")  \n**S** - Background here - as of Alonzo, all txs that call smart contracts will require collateral inputs. That collateral input has a few restricitions: it cannot contain any tokens and cannot be locked by any script. It has to be just ada. You can reuse your regular inputs as collateral inputs, they don't have to be separate, but there's no guarantee that the wallet has valid collateral input. On top of this, there is a minimal collateral you have to put up, to cover the tx fee for the smart contract yet nothing is stoping you from overcollateralizing. This isn't too dangerous because txs calling smart-contracts should never fail if all goes as planned. Yet some Qs remain such as how to handle HW wallets. Historically the HW wallet prompt you for every field in the Tx, so should we show the user of the HW wallet how much collateral they are putting up? This might be concerning for the HW wallet users calling a smartcontract, they might be confused by a prompt asking if they are \"OK with a collateral of xxxx ada\" but this might be the right way to go about to protect against a hostile app. That's the kind of consideration taking place. My main concern is about input selection: all wallets have to select which inputs to use for a tx, and because of this collateral system, the wallet has to make sure that there are always inputs 'suitable' as collateral input, so some UTXO with no tokens on it that isn't blocked by a script. If you don't have UTXOs matching those requirements, the wallet will have to prompt you \"You have no UTXOs that fit these requirements, you need to rearrange the UTXOs to be able to use this contract\": Imagine on Ethereum if you were trying to quickly call some uniswap smart contract while trying to make a swap and your wallet prompts for a UTXO swap... wait for a few minutes for the Tx to be confirmed before you can actually call the contract (by which time someone else might actually have called the swap) ... This is a really poor UX, where the reorg has to be confirmed and so we want to minimize the number of time you have to do that rearrangement because it's such a UX hit. The easiest way IMO we can reduce the number of times we have that happening is by speciying a **new derivation path**: I added a new derivation path at index [3]: So we have External Chain at [0], internal Chain at [1], staking key at [2] and collateral key account at [3]. Any ada put into this will be a flag to the wallet, basically \"don't spend ada from this address unless you have to\". That way if you ever have to rearrange your UTXOs for a DApp, then it knows to use this as collateral. This makes sure that all wallets in the ecosystem are not actually stepping over eachothers and spending their collateral inputs. This should minimize the ammount of time that users have to do any rearrangements. There is a problem with this specification, it increases what the user has to know - here that there is this new derivation path for collateral. We can make it very explicit for the user i.e. \"You have this collateral address, here's how much collateral you have\". Or we could make it implicit (as an implementation detail): there's that colleteral account and we don't tell the user it exists (and we let the wallet manage it for you). I prefer being explicit about it, I think this is up to the wallets themselves. I feel having this derivation path is the right thing to do because it will minimize the number of rearranges required.  \n**M** - This makes sense to me although I haven't followed the discussion in the PR - I saw 60 messages and felt there were already enough people  discussing.  \n**S** - Most of the messages I feel are going down a different path maybe, focusing on weither or not some contract could fail or the implications of failing (which I feel are valid considerations). IMO the more important thread is about trying to minimize the rearrangement, but it being a more subtle topic, folks tend to go to the more flashy aspects.  \n=> Moving to Review  \n\n\n### Discussions  \n\nN/A\n\n\n### Close      \n\n=> **Merged** as CIP-0023 (Draft) - [PR66 - \"Fair Min Fees\"](https://github.com/cardano-foundation/CIPs/pull/66)  \n=> **Merged** as CIP-0024 (Draft) - [PR21 - \"Non-Centralizing Rankings\"](https://github.com/cardano-foundation/CIPs/pull/21)  \n=> **Merged** as CIP-1855 (Draft) - [PR96 - \"Forging policy keys for HD Wallets\"](https://github.com/cardano-foundation/CIPs/pull/96)  \n=> **Merged** as CIP-0025 (Draft) - [PR85 - “NFT Metadata Standard”](https://github.com/cardano-foundation/CIPs/pull/85)  \n=> **Merged** as CIP-0017 (Draft) - [PR82  stakepool delegation PRs](https://github.com/cardano-foundation/CIPs/pull/82)  \n=> **Merged**  [PR86 / Update to CIP-0013 \"Cardano URI Scheme\"](https://github.com/cardano-foundation/CIPs/pull/86)  \n=> **Merge** pending (Internal checks pending) - [PR83 - “Multi Stake Keys Wallets”](https://github.com/cardano-foundation/CIPs/pull/83) - potential 'CIP-0018’)   \n=> Moved to **REVIEW** [PR88 - \"DApp connector\"](https://github.com/cardano-foundation/CIPs/pull/88)  \n=> Moved to **REVIEW** [PR104 - \"Collateral key derivation\"](https://github.com/cardano-foundation/CIPs/pull/104)  \n=> Moved to **REVIEW** [PR100 - \"Transaction message/Command metadata\"](https://github.com/cardano-foundation/CIPs/pull/100)  \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/README.md) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/README.md) | Draft |\n| 3 | [Wallet key generation](../CIP-0003/README.md) | Draft |\n| 4 | [Wallet Checksums](../CIP-0004/README.md) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/README.md) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/README.md) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/README.md) | Draft |\n| 8 | [Message Signing](../CIP-0008/README.md) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/README.md) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/README.md) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/README.md) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/README.md) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/README.md) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/README.md) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/README.md) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/README.md) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/README.md) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/README.md) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/README.md) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/README.md) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/README.md) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/README.md) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/README.md) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/README.md) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/README.md) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](../CIP-0001/README.md).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-08-03.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [August 3 2021 notes](#august-3-2021-notes)\n  * [Triage](#triage)\n      + [PR83 / \"Multi-Stake-Keys Wallets\"](#MSK-Wallets)\n  * [Last Check](#last-check)\n  * [Review](#review)\n      + [PR104 / \"Collateral Key derivation\"](#Collateral)    \n      + [PR88 / \"DApp connector\"](#DApp)\n      + [PR100 / \"Transaction Message\"](#Message)  \n      + [PR102 / \"Pool Operator Verification\"](#Pool)  \n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 8/3/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## August 3 2021 notes \n\n**Attending Editors**: Matthias Benkort, Sebastien Guillemot, Duncan Coutts, Frederic Johnson. Editorial Guest: Robert Phair.\n\n\n### Triage  \n\n#### MSK Wallets\n([PR83](https://github.com/cardano-foundation/CIPs/pull/83) - potential CIP: \"Multi-Stake-Keys Wallets\")  \n**Frederic** - This was already a last check and was approved last meeting - it is now a matter of gathering the formal number of approvals in github.  \n=> Merged as [CIP-0018](../CIP-0018/README.md)  \n\n\n### Last Check   \n\n\n### Review\n\n\n#### Collateral\n([PR104](https://github.com/cardano-foundation/CIPs/pull/104) - \"Collateral key derivation\")  \n**Sebastien** - The point of this CIP is mostly to solve two problems: one is the fact that to have collateral readily available for transactions, we need to make sure that the way the wallets pick inputs and outputs is done in a smart way, and we also want that in the case where the user has to rearrange the utxo set, it is done in a way that is understandable to the user - Obviously we prefer them not worry about the internal workings, sometimes there is no choice and we have to make it as understandable as feasible. I feel the easiest way to do this is similar to what we did with internal addresses: create an alternate derivation chain, this time as the collateral address derivation chain. We would make sure that wallets when creating Txs put (have) ada in the collateral address and then whenever they are doing regular Txs, you never touch the collateral address unless if needed (ex: if the user were to send all his ada). This way when wallets need to do Tx - such as with smart contracts - it doesn't require any fancy logic such as having enough collateral etc... In most case it should be readily availlable and that should minimize the number of times where users needs to rearrange Txs. In the case it is needed, it becomes easier to explain why and how: we prompt about the collateral address and user will understand. That's the main motivation. The side motivation prevents/avoid putting a million ada for collateral especially for HW wallets. Probably the HW wallets should tell the users how much collateral they are putting up for Txs. And so we should make sure the collateral is not some absurd ammount (even though that's probably safe). This specification covers this as well as it would enable for wallets to mointor the collateral address and make sure it doesn't have abusrd ammounts in it.   \n**Matthias** - Without even talking about risks or mitigating, the conception, it might be good to have a dedicated namespace to put this sort of keys in. Just for the sake of doing the coin selection on the wallet, and also from the user perspective, to be able to report exactly how many ada is available as collateral.   \n**Duncan** - With my 'technical architect' hat on, I've already shared my opinion on the ticket - I don't like it and have explained reasons why in the comments. With my editor hat on: it's a proposal, it makes sense, it's self-consistent... it's just that my architect recomendation would be to not do this, not implement this bridge.  \n**M** - What are your main arguments against?  \n**D** - Summarized in the comments - I don't think we need to create this new concept for users, it's not something they have to understand or ever know about.  \n**M** - Sortof: If it is a request for a Txs and it fails because they don't have enough to put up for collateral, what does the wallet say? it's not a fee, it's not a deposit..  \n**D** - We already have this situation already, where you may need to do rearrangement within the wallet to spend certain ammonts. This is another situation where the same is needed... it would be unusual. The vast majority of the time users wouldn't encounter this. But occasionaly they might, just like if they wanted to spend something like 99.9% of a wallet and you don't have the UTXOs properly arranged. I don't think it's beyond our wits to figure out some sort of wording to explain that we need to rearrange the coins within the wallets.   \n**S** - The case for this happening is really a user wanting to send some ada to somebody yet having NFTs tied to some of the UTXOs. This is already happening (and isn't that rare) and is clearly something we want to minimize. The easiest way to do that is to have this kind of namespace. I think trying to shove this into the coin selection algorithm complicates all the code and does not even give that great results. It's best to avoid rearrangements entirely just through the namespace.  \n**M** - Even from a user's perspective actually, it makes sense: in terms of user flow, we first ask for a small deposit as a collateral, that is reserved under this specific space under the key derivation scheme (used by the wallet just for that) and there is no reason why this would ever be consumed if the wallet is doing its job correctly. So it's really like a traditional deposit, like as you'd do for when you rent a place. Except that here it's deposited with the assumption the wallet does its job correctly.   \n**S** - The way this proposal is written now does not have the wallet ever automatically add collateral for the user. It is done through an EXPLICIT process, which doesn't have to be the case: there is nothing stopping the wallet from proactively putting some amount in the collateral, because at the end of the day, it's not like it's lost: it's on the side and only spent if there is need. This might be better for the user even.  \n**M** - This is even more important for Native Assets, that there is a tendancy to group Native Assets together in a single UTXO. So the number of UTXOs that only contains ada tends to be reduced over time. For users who tend to transact with NFTs and Native Assets they end up with very very dense UTXOs...  \n**S** - If we don't have this kind of CIP, this concept of rearrangement would not be a rare occurence but would be more frequent / every other transaction kindof.   \n**D** - Over the long term, as you do series of transactions - if we want to make sure we consolidate tokens and have enough UTXOs only containing ada - that's a thing we can do as part of the coin sleection. We don't need to make it a hard and fast rule, but rather something that the coin selection does. Doesn't mean it should be in a separate bucket.  \n**M** - There are multiple wallets doing multiple coin selection in their own ways, so having a standard like this would help.  \n**D** - The standard could say \"you need to make sure you keep things in a specal place\"... I think the danger of making it separate is that it's NOT available to the coin selection, and having to  explain that \"it's not really in your wallet or really available\". Yes, you need to have coin-selection (of different wallets) help to avoid having too many of those rearrangement transactions, but it doesn't mean you should go all the way and introduce new concepts to end users.  \n**M** - I disagree - I think users need to know at some point. This is a case here, in the same way we had to mention the stakekees. People were getting confused about the \"2 ada fee\" despite it being a deposit that you get back. Most users are not aware of how it works. That's normal, you get to learn about it later on. It doens't have to be in your face when you start a contract. If the user tries to spend their ENTIRE wallet without enough collateral, the wallet could prompt them with a message saying \"Are you sure you want to do that?\" or \"This would impact your ability to run scripts/smartcontracts (unless rearrangement)\"  \n**D** - Soft rearrangement is fine. This would mean you'd have to adjust the available balance. It's always in your face rather than an occasional \"corner case\".   \n**M** - Nothing wrong with breaking down available total.  \n**D** - I think that creates more problems / is unnecessary.  \n**S** - The question of how to present to the user depends on a lot of things. We could have said that we deal with Internal/External ada balances when we had two derivations then, but everybody chose to consider internal/external as the same for purpose of balances and we can do the same thing here..   \n**D** - Because we're trying to create an extraction fee. Users don't want to have to do UTXO managmeent. \n**S** - There is no reason we can't do that here as well (not show the collateral explicitely). The User doesn't have to know about this unless they are in this kind of case.  \n**D** - But in once case, it is availlable, and in the other it ISN'T.  \n**S** - And in this CIP we would not make it available unless needed.  \n**D** - But then that means it IS available. Which means you no longer need separate addresses for it, which is quite different than what this CIP is proposing (and a lot better in my mind) and you wouldn't even need separate addresses: rather a policy for coin selection that typicially maintains enough collateral (if wallets are using it).  \n**M** - That's similar to how rewards work: they are in your wallet but are not really available  \n**D** - We tried to maintain a simple user abstraction that you have a set ammount of money in your wallet without all this notion of reward.  \n**M** -  The same thing could be done for the collateral - because it is located on a separate derivation chain, doesn't mean the wallet can't select that for coin selection.   \n**D** - If it is (available), then the need for putting it on a separate address is much much less! If it's completely an internal thing (not what is proposed here) - that is different. It would then seem a bit more unecessary, as if we've introduced a possible inncompatibility (where wallets now have to be aware of this to report totals and balances, where diferent wallets report differently etc..). Making this a policy of coin selection would not change the fundamental compatibility, but deals with the problem more elegantly.  \n**S** - Wallets will have to update for Alonzo the same they had to upgrade for Shelley when we added reward addresses.  \n**D** - There is no new special address here though.  \n**S** - For the new derivation path. In Shelley we had to have all wallets upgrade so as to know about the reward address and its derivation path.  \n**D** - But there's nothing like that in Alonzo.   \n**S** - From the wallet perpsective it might need if they want to do scripts.  \n**D** - I can't think of anything that would require to change the schemes.   \n**M** - As soon as the wallet want to spin Plutus Scripts then they would have to acknowledge for the Plutus stuff  \n**D** - But then the same wallet would still be restorable in a different wallet just not supporting Plutus Txs. There is nothing that we would need to do that would be incompatible (just adding the ability for ordinary wallets to fund script transations: where the scripts are not in the cell with addressses part of the wallet). It's more like please fund this script for me, and keep things in your wallet. There is no incompatible changes: You need to add functionality in the wallet, but if you were to restore that very wallet, you would get the same exact balance in any (other / non-script / non-plutus) wallet. If different wallets report different balances it would scare people. (Yet, with my CIP Editor hat on:) I think it's self-consistent, clearly explained, makes sense. I should probably not argue too much about it.  \n**S** - I think the steps forward from here is I will change the wording on the PR based on my discussion with Matthias, to allow for different wallets to either explicitly show the information to the user and also explicitly show based on the wallet preference.  \n**D** - I encourage to think through the possibility of a design where it was just done such as an ateration to Coin Selection as a CIP...   \n**S** - The Cardano wallet team has already looked at it and have as an internal document.  \n**D** - But if it's something where multiple wallets would benefit on this rather than stepping on eachothers toes, then it would be better as a CIP.   \n**S** - Would need to speak with Jonathan on that. Would prefer merging this sooner than later given the Hardfork is only a month away. Given that we don't have that many meetings left before.   \n**M** - I want to discuss this offline a bit further due to technical decisions.   \n=> Moved to \"Last Check\" tentatively (might be merged earlier depending on conversation) \n\n\n\n#### DApp\n([PR88](https://github.com/cardano-foundation/CIPs/pull/88) - \"DApp connector\")  \n**Rob** - This is mostly the continuation of what was discussed two weeks ago (see notes). The main things we didn't really cover in the last meeting were issues pertaining to what happens if there were multiple versions of the spec and if later some changes came in, how exactly DApps would be requesting which version of the spec they require and also what happens if there are multiple wallets implementing this specs. I was looking into that and there doesn't seem to be a good solution on Ethereum (besides \"don't have multiple wallets\"). I posted two possible solutions to that in this PR.  \n**M** - We mentioned namespaces last time as a possible solution..   \n**R** - By \"namespace\": do you mean a Cardano object and you would inject multiple properties for the wallets that implement that?  \n**M** - Yes, part of the CIP probably, a registry of sorts where wallets can register their own IDs such that they would only inject in that specific namespace ID. Which is maybe a bit harder for DApps to choose a wallet but makes it for better UX. If you have two wallets injected, as DApp you can ask the user which to use and how to request.  \n**R** - Yet if the DApp is not aware there are changes to the registry, would it still be able to see all the wallet it can interact with?  \n**M** - You can always inspect the Cardano object for Registry key(s). The registry on the CIP would just be for wallet so they don't have conflicting IDs: Just for that sole purpose.   \n**R** - That sounds like a reasonbable approach. One of the approaches I considered was to just be injecting the list as an object property, but this works as well.  \n**M** - We could also specify for wallets to use UUID v.4 so that there is no conflict possible and no need for a registry. You stick to it for your half-life cycle. That would however mean that we would need some kind of metadata attached here - a schema that identifies a wallet maybe - something with name, version, implementers / whatnot.  \n**R** - I guess if someone ever needs some nice UI for choosing a wallet, then someone can create a library that analizes the version numbers and only show the ones that are relevant to DApps or something like that.  \n**S** - If we go the registry route, we could even inline the registry with this CIP like we did for [CIP-0010](../CIP-0010/README.md) . And just expose it as an  object with a set of keys.   \n**R** - That sounds quite simple, I didn't know if that should just be injected or external..  \n**M** - There could be a reference implementation in this CIP, and I would even encourage people to follow the specification rather than doing things their own way. Doesn't mean it should be done by you or right now, but this would be a nice track to develop. There are 3 methods to get addresses here: getUsedAddresses(), getUnusedAddresses() and getChangeAddress(). But there is actually no method to get any public key from teh wallet, which I think would be quite useful, to be able to query for any public key at any path, which might actually be more useful than addresses probably, because it's pretty easy to construct from a set of public keys. Knowing which address is in use is useful, being able to generate a change address a bit less: you can do that from a public key so long as you can pick a right key. I would lower down the abstraction layer and instead of working with addresses work with keys directly. So that we can get DApps to generate corresponding addresses. That way, if they want to add a stake part to the address or script they can. They can really construct that how they want.   \n**R** - Would your proposed change just be a litteral switch between addresses instead to public keys then?  \n**M** - Pretty much, and instead reduce that to only one function  - getVerificationKey(). Working out of the path, enabling that corresponding key.  \n**S** - If you do it this way, there needs to have other information on what kind of key it is. There is no guarantee the key you're getting is a [CIP-1852](../CIP-1852/README.md)  key. You could pass in the path to the key or something like that.   \n**M** - It's a bit closer to how hardware wallets opperate: they don't really make any assumptions regarding what scheme is used (although they use BIP32 as a route for defining the hierarchy) but what path is used (within that hierarchy) is up to the client. Although they provide extra checks to make sure you don't do anything bonkers. That's a bit more flexible but that adds more complexity to the DApp itself, and then the DApp has to know what kind of path it is looking for. So perhaps there are usecases for both: (1) The ability of getting an address and letting the wallet decide what a valid address is. But also have the flexibility (2) to get a verification key for that/DApp (which is maybe more advanced) and know exactly what you are doing with keys.  \n**R** - Would it be useful to have an API that (given an address) could return a verification key?   \n**M** - Unfortunately not possible - because in an address is a hash of a verification key.. Or do you mean as a the wallet and do a reverse lookup? The wallets keep track of a certain number of keys, so that they can reverse-lookup back an address to a particular key. But that means you cannot ask for an arbitrary address: if the wallet doesn't know of that address there is no way it could tell you about a key associated with the address.   \n**R** - I am talking about a wallet-controlled adresses... Because what other addresses would you be returning?   \n**S** - I feel there is a usecase for exploring the Public Key. There is also a usecase for providing the endpoints as userfriendly. There will be a need when we get to Alonzo for something like GetCollateralAddress(), depending on how much ada you need it would return to you some  UTXOs with enough collateral ... I'd rather not every role have to implement that kind of thing itself by looking at the account key and figuring out what to do. We may even run in this thing where some alts have varied set of addresses and preferably abstract that through DApps if possible.   \n**M** - The conversation should continue, notably on the PR - there are things to say we don't have time to cover. Will add after the call.   \n=> Moved to \"Review\" in two weeks. Rob to adjust PR towards a registry-like solution. Matthias to add comments.\n\n\n#### Pool\n([PR102](https://github.com/cardano-foundation/CIPs/pull/102) - \"Pool Operator Verification\")  \n**M** - This describes a protocol to authenticate stake pool operators on various websites. There are different tools and platforms today like adapool, adatools you name it, which shows stakepools and will also occasionaly provide some aditional interface for stakepool operators. But there is no clear way (yet) to aunthenticate yourself (as an SPO) and prove that you are indeed the actual owner of a particular pool. This is the problem this PR/CIP is trying to solve, by providing a flow that can be implemented by both an SPO trying to get validation and a validating server. This is a very well-known approach: You have a challenge sent by the server and you have to sign it with your SPO secret key, such that the server can then verify it against your public key, and if you are the owner of that private/public key, you can provide the signature. We made some edits on the protocol to make sure that the server cannot really fool the SPO into signing something else (than a challenge) and there is enough randomness to prevent replayability.   \n**F** - Isn't that CA-like or ..?  \n**M** - You would have many validating servers if you want - such that PoolTool.io might choose to implement that protocol. The same thing couuld be implemented by other services.  \n**F** - So SPOCRA might run one such server, as an external entity?  \n**M** - Yes, but this is really describing A flow, not who is doing it... There is also a reference implementation for both the client and the server - and as far as I know this has already been implemented in the CNCLI community tool.  \n**S** - I think this is good. Still this is yet another way of signing or representing stuff - I would prefer if we could combined this with the message signing spec (CIP?) in some way. But maybe the message signing spec is more for UTXOs or keytypes and I don't really find it to be super different.  \n**Robert** - I think it is good and ready to go. The idea SPOCRA or other party to be involved might be good.   \n=> Moved to \"Last Check\" \n\n\n#### issue\n([Issue109](https://github.com/cardano-foundation/CIPs/issues/109) - issues with the autogen site)  \n**F** - (issue not a PR) - it seems the autogenerated site is not getting the attention it deserves.  \n**Robert** - It might be graphic but it touches to text documents - here [CIP-0003](../CIP-0003/README.md)  has a lot of documents in the PR but they are stripped through the auto-gen site - and this was not seen after it was merge - we saw it after the Public website was built. I see we have some other supporting files in [CIP-1852](../CIP-1852/README.md)  that we were looking at and they all have relative pathnames to it, and some of them that were added were not detected while the other from the [CIP-0011](../CIP-0011/README.md)  was always invalid. This was probably never noticed before the issue was raised. This is affecting more than one post in the CIPs.  \n**M** - I don't think the CIP relative links should afftect the CIP but it could be that the website doesn't properly export the files (and only exports the readme). There is also the option of just getting rid of the exported website and sticking to the github website for browsing the CIPs.  \n**R** - If that's acceptable for the CF, I think that would be good. In fact I think it even gives them a barrier, and the perspective that things are read only. But seeing things on Github projects that they can get involved, even after they have been pushed.  \n**M** - And the benefit we get is that it's all markdown - we get maybe a slightly nicer interface. Would even propose we rename all the CIP files as \"Readme\" by default - which WOULD break the existing system and the site export. If we get rid of that it would make Github the default UI for navigating the CIP in a quite friendly way.   \n**F** - Maybe pushing this out to the later roadmap for the CIP program we're fleshing out - creating a Jira ticket for this. Renaming might be an issue. Getting a community site auto-pulling from the current repo would potentially be good. Up in the air on this one.   \n=> ading a Jira ticket and potential Roadmap\n\n#### Message\n([PR100](https://github.com/cardano-foundation/CIPs/pull/100) - \"Transaction Message\")  \n**S** - The spec is simple, nothing technically wrong with what they did, people wanted it: I don't see a reason not to merge it.  \n**M** - Fine by me. Seem sensible and already being used.     \n=> Moving to \"Last Check\" (correct and in use) \n\n\n### Discussions  \n\n**M** - Hoping to move the Wallet DApp connector PR. It would be good to settle on a design so that when Plutus lands we have wallets ready to cooperate. Yet the DApp PR only covers very basic wallet stuff, and with Alonzo coming there are new things coming in and we'd want to get done by a DApp connector likely like script validation and collateral allocation and this sort of things. It's a good start but will not be sufficient and should be updated for Alonzo.   \n\n### Close      \n\n=> **Merged** as CIP-0018 (Draft) - [PR83 - \"Multi-Stake-Keys Wallets\"](https://github.com/cardano-foundation/CIPs/pull/83)  \n=> Moved to \"Last Check\" (Internal checks might hurry merge) - [PR104 - “Collateral key derivation”](https://github.com/cardano-foundation/CIPs/pull/104) - potential 'CIP-0027’)   \n=> Moved to \"Last Check\" - [PR102 - “Pool Operator Verification”](https://github.com/cardano-foundation/CIPs/pull/102) - potential 'CIP-0022’)   \n=> Moved to \"Last Check\" - [PR100 - “Transaction Message”](https://github.com/cardano-foundation/CIPs/pull/100) - potential 'CIP-0020’)  \n=> Moved to **REVIEW** - [PR88 - \"DApp connector\"](https://github.com/cardano-foundation/CIPs/pull/88)   \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/README.md) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/README.md) | Draft |\n| 3 | [Wallet key generation](../CIP-0003/README.md) | Draft |\n| 4 | [Wallet Checksums](../CIP-0004/README.md) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/README.md) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/README.md) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/README.md) | Draft |\n| 8 | [Message Signing](../CIP-0008/README.md) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/README.md) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/README.md) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/README.md) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/README.md) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/README.md) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/README.md) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/README.md) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/README.md) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/README.md) | Draft |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/README.md) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/README.md) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/README.md) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/README.md) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/README.md) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/README.md) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/README.md) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/README.md) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/README.md) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-08-17.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [August 17 2021 notes](#august-17-2021-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n      + [PR104 / \"Collateral Key derivation\"](#Collateral-Key-derivation)    \n      + [PR102 / \"Pool Operator Verification\"](#Pool-Operator-Verification)  \n      + [PR100 / \"Transaction Message\"](#Transaction-Message)  \n  * [Review](#review)\n      + [PR88 / \"DApp connector\"](#Dapp-connector)  \n      + [PR107 / \"Restriction on transactions signed by hardware wallets\"](#HW-Wallet-signatures)  \n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 8/17/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## August 17 2021 notes \n\n**Attending Editors**: Matthias Benkort, Duncan Coutts, Sebastien Guillemot, Frederic Johnson. Community guest: Gabriel ([PR107](https://github.com/cardano-foundation/CIPs/pull/107) author).\n\n\n### Triage  \n\n\n### Last Check   \n\n#### Collateral Key Derivation\n([PR104](https://github.com/cardano-foundation/CIPs/pull/104) - \"Collateral key derivation\")  \n**Sebastien** - Based on discussion, it looks like one of the ways we could avoid making too many reorganization Txs, is to allow tokens to be included inside collateral inputs - which means that there would also be a need to specify collateral outputs... This would make it that much easier to include transaction in the collateral, but I am not sure that anyone is actually working on those ledger changes for this because the HF is so soon.  \n**Duncan** - It certainly will not be included in the next HF. The point of that discussion was that if it there was consensus (that it was a good solution) it could make it in the next HF (Babbage) but that consensus has not been reached from my point of view. When I did bring it up internally, the folks from the Daedalus wallet / wallet backend team did not think they would particularly benefit from it. I proposed that idea as an alternative to this and if you think it is a good idea, perhaps you can help make a bit more noise about it / clarify or argue that we should add it to Babbage. But there is certainly no time for the Alonzo HF.  \n**S** - For this specific idea, I have mixed feelings: it's slightly hacky, doesn't solve all cases but alleviates some of them (so it's not a \"Bad idea\"). I feel that if we were to go down that route it would have made more sense to create some equivalent to the rewards account that could optionally be used as collateral if wanted, so a collateral address could be a utxo address or account-style address, and then account-style address could have tokens in some way shape or forms. But that seem like way too much work to solve the problem..  \n**D** - Also it wouldn't work in general because you need at least ONE UTXO per Tx that gets consumed (for replay protection). We don't really want to go down the acccount-route style for a full hybrid thing... No particular demand for that.  \n**S** - I don't think there is particularly a path forward for this CIP/PR, we could mark it as 'Rejected' and move on, leave it up for others to dig into it?   \n**D** - I think we wouldn't want it rejected as it is a perfectly self-contained well formed proposal. I guess you might choose to withdraw it as a better solution rather than rejecting it. We don't reject it as editors. I suggest you continue this discussion with IOHK's Wallet backend team: if you can come to consensus that there is agreement on, then it becomes easier to argue for.  \n**S** - Vaccuum labs said that one of the benefits from this approach would be for HW wallets, because we'd like HW wallets to be able to validate how much collateral is being inputted into their transaction. But they mention they see no good way to do that, because transaction endpoint don't contain the inputs explicitly..  \n**D** - That's not a solution right? If that's a problem  HW wallet have in general (because it's not just for collateral), then they can't verify the input for anything - and if they really want to be able to do that, they can say \"we want an extension where any input (collateral or otherwise) can specify an assertion on how much is being spent there\"  \n**S** - The problem is that to do this you need to add a lot of logic and the ledger app doesn't have enough memory for that. So they wouldn't be able to provide any protection wether or not this CIP is added regardless (because of the memory limitations and the complexity involved).  \n**D** - You wouldn't be able to tell how much money is in, even if it's in a 'specially-derived' address.  \n**S** - For this PR: This issue will continue to come up so will need to be addressed at some point (Not necessarily through this CIP). If we have to wait for the next HF anyways, we can have more in-depth conversations after we see more onchain activity and see what happens...  \n**D** - Just on timing, if you think you want to get something added to a HF which is not completely trivial, any such decision should happen early in the cycle, since the changes going into a HF on the Ledger have to be ready at the beginning, not at the end, due to the need to be formalized etc.  \n\n=> Issue / conversation to continue, this PR tabled  \n\n#### Pool Operator Verification\n([PR102](https://github.com/cardano-foundation/CIPs/pull/102) - \"Pool Operator Verification\")  \n**Sebastien** - This is already implemented. I don't think there are any objections.  \n**Matthias** - Everyone approved, looks good. Andrew did the change touching to the CIP number, so all good.   \n**D** - Did anyone get a cryptographer to look at the VRF? There is a proposal here about using VRF Crypto, which is not completely obvious to me, which seem exactly the kind of thing where we would benefit from having a Cryptographer looking into it.. I would suggest to get Inigo to give a review from a cryptographist POV.  \n**M** - Makes sense, I will reach out to Inigo. We already had a couple of rounds, making sure that people were not signing things that they shouldn't. It should be good but it's good to get a second set of eyes.  \n**D** - I am always aware that we aren't expert cryptographers despite likely fair intuition.  \n**M** - Agreed, we have a good intuition but that doesn't automatically translate into expertise: Let's make sure that the crypto side is safe and doesn't risk things through the VRF and unforeseen security consequenses.  \n\n=> Requesting IOG cryptographer for review, left as 'Last Check' with merging pending review.    \n\n#### Transaction Message\n([PR100](https://github.com/cardano-foundation/CIPs/pull/100) - \"Transaction Message\")  \n**M** - Same for this PR good to go. It adds a new entry to CIP-0010 plus an accompanying CIP that explains for that purpose/how to use it. It's clear, we run it through a few review already.  \n\n=> Merge now  \n\n\n### Review\n\n#### DApp connector\n([PR88](https://github.com/cardano-foundation/CIPs/pull/88) - \"DApp connector\")  \n**F** - The last conversation that we had (last meeting) requested further conversation take place in the PR as per Matthias.  \n**M** - This long-running CIP aims to standardize the way we can have a plugin or addon for wallets - very much like MetaMask for Cardano -  that would provide some basic wallet functionalities accross the ecosystem for various DApps. The idea is to get some little core plugin that can provide and hold user credentials and provide dappps with UTXOs addresses and preipheral things like signatures on transactions, prompting the user when necessary. This is quite an important piece in a way and something we are trying to get right, and is also concurrently being implemented in the Nami wallet which is a bit taking the place of a guinea pig in a sense and experiencing first with this particular addon and making improvements as they see need. The last thing in there was actually events to know when the network changes or when you disconnect the addon or things like that - to have events that dapps can register and react to (ex: to adjust UI or other)... That was the last thing discussed. I think the goal for that one is really to come up with an initial foundation that can then be extended. Yt is very much Alonzo-agnostic right now (not touching redeemers, collateral focusing instead on things like Mary wallets, address management and utxos). We've gone through a few iterations already and it is getting into shape, but the discussion is still going on in the PR so not worth discussing here until we have come up with a final draft of sorts: let's first reach a solid draft, ideally before the Alonzo HF, to have a foundation for that and then iterating for the Alonzo features.  \n**D** - Given that this is being done as a collaboration between people involved with two wallets, it is likely a good basis for the proposal.  \n\n=> Tabled for now / until it is ready to be reviewed. (Looking for a more finalized draft)  \n\n#### HW Wallet signatures\n([PR107](https://github.com/cardano-foundation/CIPs/pull/107) - \"Restriction on transactions signed by hardware wallets\")  \n**Gabriel** - The main purpose of this CIP is to have some specification regarding what is supported by the HW wallet. It was brought up that the Cardano CLI serializes the transactions in a way which isn't really supported by the HW wallets which can result in different hashes (by the HW wallets) and thus leading to invalid signatures. This CIP mainly specifies restrictions on the translation body elements and some other restrictions to be considered **if a transaction is to be signed by a HW wallet**. I'm not sure if there is more to add, open to questions..  \n**M** - I added some as comments in the PR, more general remarks or concerns, nothing really against this CIP itself because it is mainly highlighting what is currently implemented in the various devices. Just \"should something be planned ot be worked on in the future?\" This is the current situation, but it might not be the one we want to reach in the end. We should continue discussing in the PR - nothing really against merging this as it's capturing the current limitations. But as a followup I feel we could rework some of them.  \n**G** - The point is to actually reflect the current state, and so as HW wallets are updated we also update the CIP. As noted in some of the responses, such as update to transaction body, as far as I know it was never meant to be supported by HW wallets, and if it ever is required to be supported it can be added + the CIP can be updated (and the same goes for auxilliary scripts) - we have not really dug into Alonzo yet as HW wallet developers - but if it is required to support it then it can be added to HW wallet and this CIP can also be updated. You asked about the number of witnesses that is limited depending on the TX Body or the number of elements in the TX Body. This is already being changed in the multisig or the script update coming to HW wallet.  \n**M** - I think the only points before merging would be the number of Tx elements: it's listed like another similar Tx elements. I think we should make the list completely explicit so there is no ambiguity (even if we have to update it for every era).  \n**G** - Yes, I will do that.  \n**S** - Is there a library where you can give it a Tx and it tells you if it matches those requirements?  \n**G** - We are planning to add this to the Cardanowallet CLI tool. We were thinking of adding an option to transform the Tx in a compatible format, but yes, we can also add an option to just validate the Tx according to the CIP, it would make sense.  \n**S** - Transform would make sense also. Probably folks are adding it in javascript or C ... we probably would want this in a Rust library as well - it would be good if there were some implementations to look at as references.  \n**G** - We will be adding it in Javascript - I'm a bit confused can you explain?  \n**S** - Right now, most wallets use the cardanoserializationlib as part of the rust library. That's what most wallets are using. It would be good if there was a reference implementation so that it can be added to the rust library codebase.   \n**G** - Ok can arrange. Or would the Js implementation be enough?  \n**S** - That would be enough and can be used as reference, webasembly also could but that might not be an option depending on what you folks are trying to do.  \n**D** - Overall this is sensible, enthusiastic about this going into a CIP - it started off about canonical CBOR and is now becoming about interoperability between HW wallets and such - I added a few comments in the PR.  \n\n=> Moved to \"Last Check\" in two weeks.  \n\n### Discussions  \n\n### Close      \n\n=> **Merged** as CIP-0020 (Draft) - [PR100 - \"Transaction Message\"](https://github.com/cardano-foundation/CIPs/pull/100)  \n=> \"Last Check\" - [PR107 - “Collateral key derivation”](https://github.com/cardano-foundation/CIPs/pull/107) - potential 'CIP-0021’    \n=> \"Last Check\" - [PR102 - “Pool Operator”](https://github.com/cardano-foundation/CIPs/pull/102) - potential 'CIP-0022' (merge pending cryptographer feedback)   \n\n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/CIP-0001.md) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/CIP-0002.md) | Draft |\n| 3 | [Wallet key generation](../CIP-0003/CIP-0003.md) | Draft |\n| 4 | [Wallet Checksums](../CIP-0004/CIP-0004.md) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/CIP-0005.md) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/CIP-0006.md) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/CIP-0007.md) | Draft |\n| 8 | [Message Signing](../CIP-0008/CIP-0008.md) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/CIP-0009.md) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/CIP-0010.md) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/CIP-0011.md) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/CIP-0012.md) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/CIP-0013.md) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/CIP-0014.md) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/CIP-0015.md) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/CIP-0016.md) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/CIP-0017.md) | Draft |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/CIP-0018.md) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/CIP-0019.md) | Active |\n| 20 | [Transaction message/comment metadata](../CIP-0020/CIP-0020.md) | Draft |\n| 23 | [Fair Min Fees](../CIP-0023/CIP-0023.md) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/CIP-0024.md) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/CIP-0025.md) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/CIP-1852.md) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/CIP-1853.md) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/CIP-1854.md) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/CIP-1855.md) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-09-07.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [September 7 2021 notes](#september-7-2021-notes)\n  * [Triage](#triage)\n     + [PR102 - “Pool Operator Verification”](#Pool-Operator-Verification)  \n     + [PR123 - meeting note naming convention](#Meeting-Notes)  \n  * [Last Check](#last-check)\n     + [PR107 / \"Restriction on transactions signed by hardware wallets\"](#HW-Wallet-signatures)  \n  * [Review](#review)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 9/7/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## September 7 2021 notes \n\n**Attending Editors**: Matthias Benkort, Duncan Coutts, Sebastien Guillemot, Frederic Johnson. Community Editor Robert Phair.\n\n\n### Triage  \n#### Pool Operator Verification  \n[PR102](https://github.com/cardano-foundation/CIPs/pull/102) - “Pool Operator Verification”  \n**Frederic** - There was a request for cryptographer review and Inigo jumped in.  \n**Duncan** - I agree with Matthias - Inigo seem happy to proceed, will add my tick to this.  \n**Matthias** -  I suggested to merge PR102 as 'Active'.  \n**D** - Do you know if the solution that is proposed here notes that the VRF keys can be updated (that they can be updated whenever users re-register)  \n**M** - That's technically a new pool isn't it? So I mean, from the perspective of the CIP, it'll need a new \"registration\". Updating the VRF would require to go through the \"verification process\" again.  \n**D** - Not, it's not a change of identity, the hash of your cold key is your identity . The VRF is one of the hot keys. I'll approve but will add a comment in there to clarify.  \n**F** - Do we want to set it up as active as per the comment request?  \n**M** - 102 could be merged as _Active_  \n**D** - Fine with it as active, if it reflects the reality that's fine by me.  \n**Robert** - Active works.  \n=> Merge ASAP  \n\n#### Meeting Notes  \n[PR123](https://github.com/cardano-foundation/CIPs/pull/123) - changing meeting notes naming convention  \n**D** - Adding green tick.  \n=> Merged  \n\n\n### Last Check   \n#### HW Wallet signatures  \n([PR107](https://github.com/cardano-foundation/CIPs/pull/107) - \"Restriction on transactions signed by hardware wallets\")   \n**D** - Overall this is sensible, enthusiastic about this going into a CIP - it started off about canonical CBOR and is now becoming about interoperability between HW wallets and such - I added a few comments in the PR.   \n=> Merge ASAP  \n\n\n### Review  \n\n\n### Discussions  \n#### Informing devs  \n**Robert** - when CIP items are done, we should aim to quickly call attention to it in the \"CIP Corner\" in the IOG Marketing newsletter (if people haven't seen it before).  \n**F** - I am working with Lenna Onto from IOG to get a stronger presence in that email wrapup, point taken.  \n\n#### CIP Statuses\n**F** - The greater conversation has been about the process for CIPs, for when we bring them onboard the repository,as we bring them as 'Draft' and functionally there should be steps to progress them from 'Draft' to 'Proposed' and onward (you can see the steps in detail in CIP1. From side conversations that have occured with Matthias, he suggests that it might be helpful to rework how the flow currently happens so that the merging in the repository implies some acceptance. I believe Matthias is proposing we leave the PR setup as 'Draft' in itself, (so skip the 'Draft' Status) and rather redefine the merging as an implicit 'Active' or 'Proposed' Status. My personal opinion on this is that this will lead to issues down the line. I see the CIP platform as a place for individuals to jump in and agree/disagree but also harder to do if we were to leave PRs as 'Draft' (and implicitly establishing the merging as 'Active') is that when people discuss they would then be discussing PRs themselves as opposed to CIPs themselves. I feel this would make the conversation more obscure or obtuse. I do feel the Formalism right now might be overkill, but might be very much required down the line. Yes, it would be easier to move everything to 'Active' now but would probably become a hindrance later.  \n**D** - I do not have a strong view on this 'Active' or 'Draft' conversation. Happy to move along either way.  \n**F** - I feel these are important conversations that will come back in the future and that we might be taking shortcuts moving too quickly towards 'Active' for CIPs. On the other hand, there were vocal complaints about the CIP process being too slow. Still the risk (in setting too quickly to 'Active') is that people would be frustrated at observed \"non-implementation\" (on IO's part). The CIP is an ANCILARY process setup for visibility, not a DECIDING process. I feel that disconnect is there no matter what. And the 'Draft' status emphasizes that distinction. So (when we have a MERGED CIP with a 'Draft' status) we can point at it and tell people that \"it is a 'Draft' proposal => it has not been implemented yet and there is no expectation of that happening\". Meanwhile an 'Active' status CIP: it should have a colllection of specific adoption criterias that have been observed => Objectively verifiable. And then we can say \"ok, it was proposed with those acceptance criteria, we observed them and it should be moved to 'Active'\". For a Standard such as the CIP-0025 (\"NFT Metadata Standard\") maybe the proposed \"observable criterias\" could be that 'X implementations' follow that format. It's an extra hoop for people to jump through but the formalism might be useful: I feel we need something in-between ('Draft' and 'Active' statuses). I don't know if we have a clear (way) to make this (distinct) enough, so people understand that 'Active means one thing' and that we also have criterias that are objectively verifiyable.  \n**D** - If we don't have consensus on these kinds of process changes, we should probably hold off on those.  \n**R** - I think both views are fine with arguments either way. My Q is \"Are the people outside of standards commitees going to have any input regarding the decision for shifting a proposal (from a Draft Status) towards 'Active'?\" -> What is the process regarding determining which proposal makes it to active assuming all criterias have been met?   \n**F** - Entirely up to IO - the 'implementer' really (whoever is implementing the proposal) - If we were talking about a wallet standard, then it might be according to whatever wallet implementers might decide. For Example a Wallet Standard CIP could be considered 'Active' if there were 10 wallets that enable it... Or something like that.  \n**R** - So that intiative doesn't go in the CIP process - It applies to the party that is implementing that Standard.  \n**F** - CIPs are not Standards by default, they are formalized suggestions for people to align on. Some of them might be Standards (some others might become standards 'down the line'). There are no Standards commitee, Editors are simply trying to clean things out and curate so the community can have the conversation and decide how they choose to proceed. I feel it would be fair of Matthias to push a PR change, so we can discuss further changes for CIP-0001. I think modifications are needed, but generally speaking there is a significant disconnect between the community's **understanding** of the transition from the conversation phase to the onchain implementation and the actual implementation.  \n\n\n### Close      \n\n=> **Merged** as CIP-0021 (Draft) - [PR107 - “Transaction requirements for interoperability with hardware wallets”](https://github.com/cardano-foundation/CIPs/pull/107)     \n=> **Merged** as CIP-0022 (Active) - [PR102 - “Pool operator verification”](https://github.com/cardano-foundation/CIPs/pull/102)  \n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/CIP-0001.md) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/CIP-0002.md) | Draft |\n| 3 | [Wallet key generation](../CIP-0003/CIP-0003.md) | Draft |\n| 4 | [Wallet Checksums](../CIP-0004/CIP-0004.md) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/CIP-0005.md) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/CIP-0006.md) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/CIP-0007.md) | Draft |\n| 8 | [Message Signing](../CIP-0008/CIP-0008.md) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/CIP-0009.md) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/CIP-0010.md) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/CIP-0011.md) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/CIP-0012.md) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/CIP-0013.md) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/CIP-0014.md) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/CIP-0015.md) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/CIP-0016.md) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/CIP-0017.md) | Draft |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/CIP-0018.md) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/CIP-0019.md) | Active |\n| 20 | [Transaction message/comment metadata](../CIP-0020/CIP-0020.md) | Active |\n| 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/CIP-0021.md) | Draft |\n| 22 | [Pool operator verification](../CIP-0022/CIP-0022.md) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/CIP-0023.md) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/CIP-0024.md) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/CIP-0025.md) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/CIP-1852.md) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/CIP-1853.md) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/CIP-1854.md) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/CIP-1855.md) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-09-21.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [September 21 2021 notes](#september-21-2021-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n  * [Review](#review)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 9/21/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## September 21 2021 notes \n\n**Attending Editors**: ~Matthias Benkort~, Duncan Coutts, Sebastien Guillemot, Frederic Johnson. Community Editor Robert Phair.\n\n\n### Triage  \n\n**Frederic** - No major items on agenda besides continuing PR88's discussion from last meeting if stable enough. Any items we should look in?  \n**Duncan** - One minor item just filled at the beginning of this meeting ([PR131](https://github.com/cardano-foundation/CIPs/pull/131)), could be added to triage...  \n**Robert** - A discussion that probably should be discussed is that we have had another justification for possibly altering the Cardano URI scheme (CIP 13), and change to a more general URI framework with separate CIPs for separate URI scopes doing particular things. Vicente suggested this back in April and I and others thought it was a good idea then, but had so much with the stakepool and payment links at this time that it was suggested to go with this. As now people are making suggestions for different URI frameworks, I think it might be a good idea to reconsider that suggestion (to break up the URI scheme and pass on one kind of framework document, with this specific documents for the applications)  \n**D** - If there is to be an update to CIP 13, then we should make sure we manage this the right way..  \n**R** - I haven't conferred with Vicente since, but might have time next month to draft a proposal. (to change CIP 13 and cleans it up and or maybe post a new CIP to the framework itself - whatever makes more sense).  \n**F** - Maybe add this to Discussion as specific PRs.. Any other PRs to discuss? By the way added labels as requested previously by Matthias, hoping that this is helpful, see if changes are needed (Currently Types and stage only). Doesn't seem we have discussion items that should be brought up to 'Triage' or 'Last Check'. [PR131](https://github.com/cardano-foundation/CIPs/pull/131) is adding two metadata labels, 88 and 87, for the Milkomeda chain. Are we fine moving this along?  \n**Sebastien** - Can approve this.  \n=> Merged [PR131](https://github.com/cardano-foundation/CIPs/pull/131)  \n\n### Last Check   \n\n### Review  \n\n### Discussions  \n\n#### DApp connector \n[PR88](https://github.com/cardano-foundation/CIPs/pull/88) - “DApp connector”  \n**F** - The conversation is currently at 120+ comments, who can summarize the conversation?  \n**S** - I think Rob wrote a summary in the PR conversation... There are so many opinions on this, it is hard to keep track of the parallel discussions, and also hard to keep track of the different opinions on this. I think somebody will have to write a summary of everything, there's just too much going on at this point. We do need to merge this at some point sooner than later, so we can modify these specs for Alonzo functionality. If you try to add Alonzo-specific to this PR, it would never end. This is kinda the problem I think.  \n**F** - Who should do this?  \n**S** - It's hard, nobody has the time.  \n**F** - Everyone seem to agree that this is one of the critical/structural points that can really fulcrum the ecosystem integrations.\n**S** - Yes. I can say I'll do it but if I do it, but it would be next week at the earliest.  \n**D** - If it's important maybe someone on the IOHK wallet team could be tasked with this.  \n**S** - We need more than just reading and putting comments at this point, more like a project manager to review and setup the clear next steps for this CIP to be locked and merged. If the wallet team can spare a PM..  \n**D** - If it's important and needs to be done, then it should get done, you shouldn't have to take on the burden all to yourself.  \n**S** - I'll bring it up to Alex (have a meeting tomorrow).  \n**F** - It sounds like I could be involved in there as well, so feel free to involve me.  \n**S** - If you feel you have the time to get involved into this, we could have a developer get into this but it's not necessary as it's mostly summarizing.  \n**F** - I could get involved but it would be for next meeting, not next week, would that be too late?  \n**S** - We'll find someone who can do it right away, there is just so much going on for everybody.  \n**D** - This is an enormous thing.  \n**S** - Non-trivial effort for sure.  \n**D** - On the other hand, it looks like this is so obviously in the interest of the wallet team to implement..  \n**S** - Will bring it up, and depends how it goes, will try to get it done by next week to have a clear path for this CIP.  \n=> Sebastien to speak with IO to get summary/consensus  \n\n#### Statuses\n**F** - looking at meeting 29 notes, the last discussion was about CIP statuses and how we progress CIPs through their various statuses. Currently merging a new CIP in the repo, it functionally goes in as 'Draft' but the proposal from Matthias was that the merging could constitute some kind of endorsement of the CIP and it should be merged as 'Active' directly. And so proposed we change the structure a bit. The counter-argument to that is that if we proceed and do that it makes it harder for users to Discuss CIPs themselves, ex: '[the CIP Metadata standard](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0025/CIP-0025.md)' was not a CIP until it was technically merged.. Duncan you last mentioned that you preferred holding back unless active concern about the general process, Sebastien no strong opinion. Functionally waiting on a PR from Matthias if we want to change CIP 1 process.  \n\n#### Labels\n**F** - We have added labels in the PR panes, you can now distinguish between the updates themselves and the new tentative CIPs, and the associated types(Standards, Informational, Process) as well as 'likely deprecated' (comment: liking the new CIP naming convention that is surfacing in the PRs). There is also the possibility of adding milestones for things, maybe where we might extend and add the statuses of CIPs themselves.  \n**D** - That wouldn't work as well, The milestone feature in Github only covers the code.  \n\n#### pre-merge CIP conversation\n**F** - As soon as we merge a new CIP we typically lose the conversation that happened on it outside of the PR itself. For example, [CIP 25](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0025/CIP-0025.md) does not appear to have a direct link to the extended PR conversations. What I propose is that the History header element be updated directly with the PR conversation direct link. so [PR85](https://github.com/cardano-foundation/CIPs/pull/85) (where much conversation took place) can be directly referenced in the CIP itself, so that readers can regress to the conversation easily.  \n**D** - I agree with this, it's sensible to be able to refer to the direct PR or conversation (or see how users got to their ideas while drafting)  \n**S** - If you want to share the link to the PR (conversation), it's like the PR itself. That's also fine (to keep the conversation).  \n\n#### Update to CIP 13\n**R** - I agreed I will work on this in the first time of next month. It should be done one or two ways ( I think logically only two ways) either change [CIP 13](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/CIP-0013.md) and dumb it down to a framework, and then add two separate CIPs for stakepools and payment links, creating space as well for the URL scope and the metadata and all the other stuff that has been requested. I however think it would make more sense to deprecate CIP 13 after creating a new CIP for the framework - which Vicente has offered to do, I could do this with him or instead, anyway preferred. And then both the URI payment scheme (that Sebastien and Vicente originally wrote) and the stakepool link scheme need to come along as new CIPs, and should be pretty much rubber-stamped (as copies of CIP 13 content). So basically, create a supplanting 'framework' CIP (deprecating 13), and write two new CIPs (URIs for payment links, URIs for stakepools) which would enable future CIPs for metadata or other extensions down the line.   \n**D** - Can you elaborate as to why we would benefit or the downside?  \n**R** - RIght now you can't suggest any application of a URI in Cardano without modifying CIP 13. So we have a bottleneck.   \n**D** - That would still be true if we were to just split it now.. You would just be extending CIP 13 vs. Adding new CIPs.  \n**R** - It sounds like we might be arguing for the same thing. Very simple framework CIP..  \n**D** - I mean what do you see as the advantages of doing it the way you're proposing. Trying to get some clarity of what the advantage it.  \n**R** - I think there will be dozens of protocol extensions..  \n**D** - Supposed we add 'extensions' directly in CIP 13 directly? (as opposed to have them be independent CIPs..)  \n**R** - (my proposition) bypasses the bureaucracy of process (for that one CIP) every time that someone changes anything. It would allow for a very general framework CIP to be mostly untouched, acting as standard that everybody can recognize, while new changes would be submitted as new CIPs (rather than modify the original CIP). We'd end up with dozens of CIPs applying to it, and dozen of authors. Everyone writing a little bit for that protocol, (see [PR130](https://github.com/cardano-foundation/CIPs/pull/130)). There then are questions about accountability and such. I think it makes more sense to have one untouched framework document that stays there and collects some dust while the new protocol changes would come as new CIPs.  \n**D** - It makes sense for Authorship, but it's not clear it's worth it for the number of PRs that would have to be reviewed. Unless we're discussing conflict resolution.  \n**R** - Authorship and the accountability that goes along with it.  \n**D** - OK.  \n**R** - If everyone is in agreement, thanks for flagging. I am looking at [PR130](https://github.com/cardano-foundation/CIPs/pull/130), and there's a thread in the Forums back in April, if there is any suggestion for how, else I will work on this in October and turn to the original PR authors of the Payments URI CIP to see how they want to go.  \n**D** - Seem like a worthwhile pursuit.  \n\n\n#### Deprecating PRs\n**S** - The CKD CIP probably won't happen, wouldn't mind closing the PR.  \n**F** - Crypto 2099 and Tweag.io PRs should probably be closed. Also [PR104](https://github.com/cardano-foundation/CIPs/pull/104). Close or Deprecate.  \n**D** - Deprecated is fine as tag. Maybe closing. The ledger team is thinking about changing the ledger specs for the next HF, and changing how some of those things work - and so to bring back this at some point would have to take into account the new ledger spec etc.. I feel this is pretty much deprecated at this point.  \n\n\n\n### Close      \n\nMinor merges  \nDiscussions around [PR88](https://github.com/cardano-foundation/CIPs/pull/88) - “DApp connector”: Summary desired for next meeting (IO/CF)   \nDiscussions around URI scheme / CIP-0013 and approaches from here (Robert to look more into October)  \n\n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/CIP-0001.md) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/CIP-0002.md) | Draft |\n| 3 | [Wallet key generation](../CIP-0003/CIP-0003.md) | Draft |\n| 4 | [Wallet Checksums](../CIP-0004/CIP-0004.md) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/CIP-0005.md) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/CIP-0006.md) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/CIP-0007.md) | Draft |\n| 8 | [Message Signing](../CIP-0008/CIP-0008.md) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/CIP-0009.md) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/CIP-0010.md) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/CIP-0011.md) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/CIP-0012.md) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/CIP-0013.md) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/CIP-0014.md) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/CIP-0015.md) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/CIP-0016.md) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/CIP-0017.md) | Draft |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/CIP-0018.md) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/CIP-0019.md) | Active |\n| 20 | [Transaction message/comment metadata](../CIP-0020/CIP-0020.md) | Active |\n| 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/CIP-0021.md) | Draft |\n| 22 | [Pool operator verification](../CIP-0022/CIP-0022.md) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/CIP-0023.md) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/CIP-0024.md) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/CIP-0025.md) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/CIP-1852.md) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/CIP-1853.md) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/CIP-1854.md) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/CIP-1855.md) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-10-05.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [October 5 2021 notes](#october-5-2021-notes)\n  * [Triage](#triage)\n      + [PR136 - UPDATE /  adding js usage for CIP-0014](#CIP-14-update)\n      + [PR132 - CORRECTION - adjusting CIP-0003 text](#CIP-3-update)\n  * [Last Check](#last-check)\n  * [Review](#review)\n      + [PR88 - \"DApp Connector\"](#DApp-Connector)\n      + [PR116 - \"Royalty Standard\"](#Royalty-Standard)\n      + [PR117 - \"Monetary Scripts Serialization format\"](#Monetary-Scripts)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 10/5/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## October 5 2021 notes \n\n**Attending Editors**: Matthias Benkort, Duncan Coutts, Sebastien Guillemot, Frederic Johnson. Community Editor Robert Phair.\n\n\n### Triage  \n\n#### CIP 14 update  \n[PR136 - UPDATE /  adding js impl. for CIP-0014](https://github.com/cardano-foundation/CIPs/pull/136)  \n**Frederic** - This is a minor update to an existing CIP ([CIP-0014 - \"Asset fingerprinting\"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0014/CIP-0014.md)) that provides a javascript implementation. Describing how to do asset fingerprinting in Js.  \n**Matthias** - Approved. Also good to move towards Active when feasible (but separate conversation).  \n**Duncan** - Where is this located?  \n**M** - NPM link through the NPM site.  \n**Sebstien** - Some background: We originally wrote this reference implementation between me (representing Yoroi) and Ishish (?) from CardanoScan. That is why Yoroi and CardanoScan implement this but most other wallets do not at this point.  \n**D** - OK   \n=> Merged [PR136](https://github.com/cardano-foundation/CIPs/pull/136)  \n\n#### CIP 3 update  \n[PR132 - CORRECTION - adjusting CIP-0003 text](https://github.com/cardano-foundation/CIPs/pull/132)  \n**S** - I think the two changes in this PR are independant: The first is a typo. The second change I have to double check, need to double check the work. It could be indeed correct and needs to be verified.   \n**F** - Tabling this, added to 'Triage' for next meeting, Sebastien or Matthias to look at this to confirm.  \n=> Tabled, to 'Triage' (if it gets correctness confirm) [PR132](https://github.com/cardano-foundation/CIPs/pull/132)  \n\n### Last Check   \nN/A\n\n### Review  \n\n#### DApp Connector\n[PR88 - \"DApp Connector\"](https://github.com/cardano-foundation/CIPs/pull/88)  \n**F** - This was discussed at the last Editors meeting (#30). Discussion can be reviewed in the [notes](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-09-21.md) from last meeting. This is the 130+ comments conversation - there was an ask about who might be able to summarize the conversation and how we might be able to move this forward. Has there been some support from IO? Should we go over this PR more carefully right now?  \n**M** - Partly. Most of this CIP has been implemented by the [NAMI wallet](https://namiwallet.io/) I think and the CC wallet is also working on it. As far as I am concerned, it might not be finished/perfect and there might be more changes to this CIP, but I also don't see any reason why we couldn't merge it in as a 'Draft' right now while not finalized. It is mainly about the pre-Alonzo era, and now that Alonzo is here and there are more things with the scripts, those updates will come. I don't feel we need to reach them before this gets merged. Rather I think we should have new conversations about such modifications (in new PRs).   \n**F** - Agree - I think this is a good example of the (Process) conversation we have had previously regarding statuses of CIPs (and here a good use of the 'Draft' Status). PArticularly with the background of a DApp connector concept that would benefit the greater ecosystem when out.  \n**D** - Who is currently implementing this?  \n**M** - At least NANI and CC wallets - so the two lightwallets out there. There is also plan within IO such as with the wallet announced at the summit to also integrate with that CIP and make it sort of ecosystem out of that.  \n**D** - Do those two groups broadly agree with eachothers?  \n**M** - On things that have already been implemented in this CIP, Yes. The discussions ongoing really are about addition of new features or elements, such as event APIs, or to react to a changing network or to a disconnected wallet. Maybe therefore the structure of the CIP could be split a bit and have a core part as the API and extensions that could be supported by this event API, the Alonzo Update... A bit like we did for CIP-1854 with one common foundation and extensions on top, which can be discussed independantly.   \n**D** - If the people who have the current implementations of this agree on it, then it would be fair to set it as a 'Draft' standard.  \n**M** - Maybe we can bring it to the spotlight again, and if people are happy with the current state, then merge and have the conversation on the event API on a separate PR.   \n**D** - Yes, drawing a line would help. Let's add some comments to that effect in this PR.  \n**M** - On it, need to ping the right parties involved, will look into the varied Github handles. I will draft a comment - just gathering the github handles.  \n**S** - I think it's fine.  \n=> Moved to 'Last Check' [PR88](https://github.com/cardano-foundation/CIPs/pull/88)  \n\n#### Royalty Standard\n[PR116 - \"Royalty Standard\"](https://github.com/cardano-foundation/CIPs/pull/116)  \n**F** - This tentative CIP looks at establishing a standard for Royalties. This is also an active conversation, and can also be flagged early as an item for the next meeting.  \n**D** - I am unclear as to wether this is a ledger change or if that is built on top of the existing one and is built as a convention.  \n**S** - Convention - Just using Transaction metadata to let people know that \"if you are operating an NFT marketplace, please reserve some of this sale to the author of the NFT\"  \n**D** - so purely Opt-In? I see.   \n**S** - I think the CIP is fine as-is. There was one comment where I mention that the address is saved and reserved but they could decide to use binary address to save space (in the metadata itself). They were not sure wether or not to do this and haven't responded either way. There is another issue where the percentage field is a decimal value so 0.2 is 20% and I am not sure wether or not 0.2 should be 0.2%. They are suggesting renaming it.  \n**D** - Probably should not be called percent  \n**S** - Suggestion is to rename to make it clear. These are the two issues I see in here. Neither of those have been addressed yet. My understanding is that people have already implemented this. Unless they modify the CIP or respond to the comments soon, we should just merge it because it is already implemented and if they want to change things they can add to the backwards-compatibility. By the same logic we could just merge now and if they want to change the points brought up, can be done post-merge.  \n=> Moved to 'Last Check' [PR116](https://github.com/cardano-foundation/CIPs/pull/116)  \n\n#### Monetary Script\n[PR117 - \"CIP-0029 | Monetary Scripts Serialization format\"](https://github.com/cardano-foundation/CIPs/pull/117)  \n**M** - This is intent to put in the same place the CBOR serialization format that is used by Scripts. Phase 1 scripts are the ones that were introduced in the Shelley Era and later extended in Allegra. The binary format is already kinda fixed and documented in the ledger spec repository in a CDDL but there was no documentation of the JSON format. The idea was to document that, but also to make a recap of the rest, and locate in a singular place the CDDL for the binary format. There was an ongoing discussion with Duncan on one of the naming conventions.. I replied to the comment in there: there are visibly two different conventions used between the Cardano API and the ledger specs. I stick with the Cardano API as the most user-facing and what people will likely see, and also used for the JSON format. So i changed (retroactively) the CDDL. It really depends on how you look at the script - Either invalid or valid after (Semantically equivalent)  \n**D** - I would suggest getting the CDDL changes upstream.  \n**M** - Yeah, also, in the repo.. I did double-check the sourcecode and compared... It is a bit confusing in the end.  \n**S** - We want to implement this. We have an implementation already, it just isn't public. We'd like to know if this might be the final piece before we push anything.  \n**M** - The thing is this is one of those PRs that is specifying something that already exists. In retrospect. Something that could have been a CIP first, but now requires synchronization / a coordination spot for the varied implementations out there. It doesn't really change things, it's really a matter of putting on paper what is. It might be the Cardano API has also changed on those regards - I don't think so but maybe it has. Something we could do before merging if we want to move forward. Or actually merge it and do the changes in the Cardano API and bring it back to what they were.. I wrote that PR some months ago, I don't know if the Cardano API has changed in the meantime, I have seen a lot of work being done on the JSON format recently but I think it was mostly on the other parts (UTXOS..)  \n**D** - I don't think it touched the scripts at all.  \n**M** - It would be good to control if this is still the same.  \n**D** - Ask Jordan to Review to make sure it is accurate - I am not aware of any changes in the JSON format. The other stuff cannot change because it is onchain (CBOR, hashing, ..)  \n**M** - If this is fine for everyone I would prefer to move this to 'Last-Check' for next meeting, if it is still capturing the current state of things (will check with Jordan)  \n**D** - Fine with it.  \n=> Moved to 'Last Check' [PR117](https://github.com/cardano-foundation/CIPs/pull/117) \n\n### Discussions  \n\n#### PR118\n**M** - Actually dependant on PR112. If [PR112](https://github.com/cardano-foundation/CIPs/pull/112) (tentative CIP 26) doesn't make it there isn't much ground for [PR118](https://github.com/cardano-foundation/CIPs/pull/118) (tentative CIP 28)..   \n\n#### PR112\n**M** - This was touched to in some previous discussion CIP 26 is for finding a way to have offchain metadata that can be verifiable and can have some form of ownership attached to them and still be midly decentralized or not fully centralized. The idea is to have metadata that contains information themselves that makes them verifiable provided the user has some knowledge of some existing keys. Metadata in this context is just an object, which maps fields to values and all values are signed independantly with a set of signature by a set of public keys. The keys by themselves have no particular meaning. So there is a need for another mechanism to identify the owner of the metadata with those keys. This could be an offband communication mechanism (ex: advertizing your keys through your twitter or other, just as ppl do for GPG keys). There are also other mechanisms proposed such as CIP 28 which explains how to link keys and owners: through an onchain publishing which can then be discovered automatically. CIP 26 doesn't go that far, it stops at having metadata assigned by keys (where the keys come from is off-topic). It therefore decribes the structure and signing process: how to generate the signatures, hashes and how to verify. Also to give recommendations on how clients could be consuming this data and how servers could also be implementing this offchain. The idea is not to have one central server but rather **multiple** registries that could be maintained by the community to share all that metadata. One server does not actually provide any authority on the metadata, they are simply access points for the registries, which can then be replicated on any of the other registries in some way. So arguably more decentralized so. It is derived from an original abandoned CIP draft that was written by Michael and Polina some time ago. We made quite a lot of edits along the way as we actually started to implement that and that is the final version that we feel is currently quite complete and also implemented in the Cardano Foundation Registry at the moment.  \n**D** - This is currently accurate with respect to the current [Cardano Token Registry](https://github.com/cardano-foundation/cardano-token-registry)?  \n**M** - Yes, and it covers both the phase 1 monetary script approach that we used before, where the keys used for verification were actually the keys from the policy, which isn't the case for plutus scripts as you don't have the same. For the Plutus scripts, the association between the scripts and the keys needs to happen via some other mechanisms. This CIP puts out some ideas of how that might be achieved, while [PR118 / tentative CIP 28](https://github.com/cardano-foundation/CIPs/pull/118) shows a concrete approach of one such usecase. (Publishing onchain this mapping as part of the minting transaction, which is really just for mentary policy scripts, it doesn't cover a wide variety of Plutus scripts, rather just for the ones that would be minting policies..). I also asked Michael and Polina to have a look at that some time ago: they were happy with the results but only commented on Slack. I will ask them to weigh in directly on the repo to have a record of that.  \n**D** - Sounds good. How long has it been hanging around for / have others had a chance to comment much?  \n**M** - A bit - it was advertised on some platforms. We also discussed it in the Summit actually, with people asking about that and how we would do Plutus metadata. General reactions and comments were mostly emojis.  \n**D** - \"so non-controversial\"   \n**M** - More hearts, therefore positive.  \n**D** - Let's get more technical architects to comment on this.  \n=> Requesting public reviews from MPJ/Polina - moving [PR112](https://github.com/cardano-foundation/CIPs/pull/112)  to 'Review'   \n\n#### CRC\n**F** - There have been discussions about possibly bringing in 'CRC' (Cardano Requests for Comments) as a category, do you feel this would be worth discussing, do you feel strongly about this? It was previously lightly discussed at the beginning of the CIP Process and at the time dismissed as non-urgent & non-necessary (as CIP as Standard is more or less what people mean by 'CRC'). Ethereum has that system of improvement proposals and request for comments - the most famous being the ERC-20 standard. This is an aspect of the general Cardano Ecosystem that we have put off as non-essential. We have standards, but nothing yet specified as \"Cardano REquest for Comments.  \n**S** - This came up many times in the past and confuses folks. Especially now that we have Plutus, people want to standardize their Plutus Smart contracts. This is a possible excuse for this. This is was folks do with Ethereum and ERCs, they standardize smart contracts interfaces.  \n**D** - How is that different from a CIP?  \n**S** - Basically there is no real difference, it's just a different track.  \n**M** - I think it makes sense.  \n**D** - What makes it require a different track, what qualitatively makes it 'needed' rather than having even more new tracks for things like wallets, or ... (Just want to elaborate). WHy should we treat it differently?   \n**S** - The main benefit would be that if you are a Plutus developer you have a specific track to look at, and so when we are reviewing a CIP, you know that you can focus on that area. I think that is the main reason, because the expertise to look at it is different.  \n**M** - It's not that we have been using tracks differently, we don't have a separate process for them. To me they are more like tags or categories. It makes sense for filtering and it makes sense to have another category for this one if we anticipate it to be the home of many future CIPs. I think that in itself justifies the creation of a new track.  \n**D** - But if in practice all that is reflected in / has a different tag and one entry in the metadata and the PR it has a tag on github so you can filter..?  \n**M** - In that sense then we could have one singular track and have varied tags as tracks.  \n**D** - I understand it as a Tag. Searching by what's in flight, is good through Github Tags - I think I am agreeing with you that it's good to have in multiple places.  \n**F** - There will be other meetings to discuss bringing it on this platform, This was lightly touched so people are aware the consideration is taking place, and likely added to next meeting's agenda.  \n\n\n### Close      \n\n([PR136](https://github.com/cardano-foundation/CIPs/pull/136) **merged**)  \n[PR132](https://github.com/cardano-foundation/CIPs/pull/132) to 'Triage' (correctness to be reviewed and merged next meeting if adequate)  \n  \n=> \"Last Check\" - [PR88 - “DApp Connector”](https://github.com/cardano-foundation/CIPs/pull/88) - potential 'CIP-0030’  - reasoning is that it is better to have it merged as 'Draft', and have newer conversations from there rather than rtying to summarize from here  \n=> \"Last Check\" - [PR116 - “Royalty Standard”](https://github.com/cardano-foundation/CIPs/pull/116) - potential 'CIP-0027’ - There are format issues to be addressed in the PR   \n=> \"Last Check\" - [PR117 - “Phase-1 Monetary Scripts Serialization”](https://github.com/cardano-foundation/CIPs/pull/117)  \n=> \"Review\" - [PR112 - “Cardano Off-Chain Metadata”](https://github.com/cardano-foundation/CIPs/pull/112) - potential 'CIP-0026’ - to be discussed with Polina and Michael.    \n\n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/CIP-0001.md) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/CIP-0002.md) | Draft |\n| 3 | [Wallet key generation](../CIP-0003/CIP-0003.md) | Draft |\n| 4 | [Wallet Checksums](../CIP-0004/CIP-0004.md) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/CIP-0005.md) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/CIP-0006.md) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/CIP-0007.md) | Draft |\n| 8 | [Message Signing](../CIP-0008/CIP-0008.md) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/CIP-0009.md) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/CIP-0010.md) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/CIP-0011.md) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/CIP-0012.md) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/CIP-0013.md) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/CIP-0014.md) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/CIP-0015.md) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/CIP-0016.md) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/CIP-0017.md) | Draft |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/CIP-0018.md) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/CIP-0019.md) | Active |\n| 20 | [Transaction message/comment metadata](../CIP-0020/CIP-0020.md) | Active |\n| 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/CIP-0021.md) | Draft |\n| 22 | [Pool operator verification](../CIP-0022/CIP-0022.md) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/CIP-0023.md) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/CIP-0024.md) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/CIP-0025.md) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/CIP-1852.md) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/CIP-1853.md) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/CIP-1854.md) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/CIP-1855.md) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-10-19.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [October 19 2021 notes](#october-19-2021-notes)\n  * [Triage](#triage)\n  * [Last Check](#last-check)\n      + [PR88 - \"DApp Connector\"](#DApp-Connector)\n      + [PR116 - \"Royalty Standard\"](#Royalty-Standard)\n      + [PR117 - \"Monetary Scripts Serialization format\"](#Monetary-Scripts)\n  * [Review](#review)\n      + [PR112 - \"Offchain Metadata\"](#offchain-metadata)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 10/19/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## October 19 2021 notes \n\n**Attending Editors**: Matthias Benkort, Duncan Coutts, Sebastien Guillemot, Frederic Johnson. ~Community Editor Robert Phair.~ guest: HuthS0lo. \n\n\n### Triage  \n\nN/A  \n\n### Last Check   \n\n#### DApp Connector\n[PR88 - \"DApp Connector\"](https://github.com/cardano-foundation/CIPs/pull/88)  \n**Frederic** - This was discussed at length during Editors meeting [#30](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-09-21.md) and [#31](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-10-05.md). It has a lengthy 130+ comments conversation - but we felt it was good enough to merge in, have there been further updates since?    \n**Matthias** - I think we suggested to remove the section about 'events' that was introduced recently with discussion, for the sake of merging what has been discussed and have the conversation about events be brought up in a separate PR/CIP.  \n**Duncan** - I agree - let's merge the bits that are stable and carry on ongoing discussions in their own threads.  \n**F** - About steering: Do we want to override authors in PRs or do we leave it up to the Author?  \n**D** - In the first instance the author aught to decide - but Matthias Recommendation is very sensible: \"Guys, get the main part in there, it's fine, and separate off that other piece and we can declare the main part cannon..\"  \n**M** - The author is very active/responsive. This was my last message in there because he asked precisely that.   \n**F** - In that case, is this still another 'Last Check', awaiting Rooooob, the PR author to move that section out?   \n**M** - It's on Rooooob indeed, we can make it a bit clearer, but he had a Q about that.  \n**F** - So flagged as 'Last Check' or actually 'Triage', ready to be merged once removal of section, if Rooooob is ok with it merged. Would it be wrong/inappropriate if merged with Events section in however?  \n**M** - No, given that it is a draft, but it would need a disclaimer that it (event bit) hasn't been fully discussed as much as core ideas maybe.  \n**S** - I can ask Roooob to change that section so we can get it merged. If that's all people have problems with we can even have people approve the PR now so that when Rooooob makes his changes I can merge sooner...  \n**D** - Were there any other major changes or things or was this all about the events API?  \n**S** - I don't think so  \n**M** - There was one change that was proposed recently but it was very minor, which can go through a different PR. It was more an additive change. Beyond that, no, pretty stable.  \n\n=> Moved [PR88](https://github.com/cardano-foundation/CIPs/pull/88) to 'Triage'  \n\n#### Royalty Standard\n[PR116 - \"Standardization of Royalties\"](https://github.com/cardano-foundation/CIPs/pull/116)  \n**F** - This tentative CIP is by [HuthS0lo](https://github.com/huths0lo)  \n**HuthS0lo** - 45 days ago, there was a meeting with several community leaders, folks in the CNFT space and the goal was to create a community standard for royalties because the challenges with smartcontracts, they really didn't seem an effective method of creating royalties for the resale of NFTs. We all met and agreed on a standard, which is straightforward, with the goal to make it so that people cannot change out their royalty structure down the line. So we request that their very first token created of of a policy essentially identifies the royalty they are expecting from any asset created out of the same policy - that is functionally it.  \n**D** - For clarity, what can you express in these policies: are they fixed, relative... and they are only 'voluntarily enforced' things by actors correct?  \n**H** - Correct, this is not enforced at the blockchain level, and really meant to be enforced by the various marketplaces like cnft.io, token.io, artano ... Anyone who is active in that space. We expect they will align with the standard. As far as what goes in a policy is really two key things: the percentage expected from a resale and the address it should be sent out to. One of the things that was decided was that we only wanted one single address to prevent undue burden on the marketplaces. ALso there is a minimum ADA per Tx, so subvdivision and such was inconvenient.   \n**D** - So it works as metadata and has to be attached to the very first minting with that policyID...  \n**H** - Correct, your very first mint has to be this token. And the reason for that is so that people can't change it down the road. If we make sure they make it on the very first transaction, then it is very much identifiyable for any transaction that comes after that - plus it's not a major rist on creators: If they mess up their initial minting, then they can just do a brand new mint.  \n**S** - This feels like there is overlap with Matthias's CIP proposed (CIP-0028)  \n**H** - I have to look at it  \n**S** - Besically a way to add to the metadata associated with a mint. They are associating an arbitrary keys so that you can refer to it in the future. My train of thought is that you could use this instead of tying the royalty information to the first mint, you could tie the royalty information to any transaction associated with a specific key...  \n**D** - But the purpose here is to NOT have it modifiyable over time  \n**H** - Correct, there were multiple proposals - the meeting held was by users influential in the CNFT space. One proposal wanted to setup an offnet repository and you could have a metadata tag pointing to that, like a SPO putting his pool info up in the cloud. But that was exactly it, we didn't want ANYBODY to have the ability to change it. You could bad actors that might sell at 0 royalty and later change to 100%... The goal was to protect buyers on the same token and create the ability to have royalties without requiring the extra layer of a smart contract. As long as there is a standard that any marketplace can enforce.  \n**F** - The state of the conversation as understood is as a 'Last Check' are there requested changes?  \n**D** - The extra metadata label as '777' has to be registered with CIP-0010's registry.json and should be done in this PR.  \n**H** - I think someone had asked previously, but I can do that.  \n**M** - We typically bundle those changes together so it is also reflected rightaway in CIP-0010. You had it as a separate PR, this should be in a singular PR.  \n**D** - Change the existing PR so that instead of touching one file it changes multiple files: just add another commit that changes that registry file (CIP-0010)  \n**F** - Also, the file should be in its own subdirectory, and the header is missing from the main markdown file itself, where number/type and such are defined.  \n**H** - Happy to add header + move and touch the other file as needed.  \n**M** - There is a template in the repo you can refer to (or existing CIP)  \n  \n=> Moved [PR116](https://github.com/cardano-foundation/CIPs/pull/116) to 'Triage' for next meeting  \n\n\n#### Monetary Script\n[PR117 - \"CIP-0029 | Monetary Scripts Serialization format\"](https://github.com/cardano-foundation/CIPs/pull/117)  \n**F** - That was setup as a 'Last Check' and was ready to go.  \n**S** - Good to go.  \n**M** - Hasn't changed in a while, good to go. Maybe one thing we could change is the status from 'Draft' and maybe to 'Active'? It's capturing what exist. I don't mind making a second PR but we could also merge it directly (as Active).   \n**F** - Partial to it but it might be worthwhile to have the status transition as a separate conversation.   \n**D** - We have that general issue that we want to move a lot of the 'Draft' ones, so it might be better to deal with that all in one go.  \n\n=> Merge NOW [PR117](https://github.com/cardano-foundation/CIPs/pull/117) \n\n### Review  \n\n#### Offchain Metadata \n[PR112 - \"Cardano Offchain Metadata\"](https://github.com/cardano-foundation/CIPs/pull/112)  \n**M** - I had an extensive chat with Michael, he cowrote most of this CIP and we mostly discussed the changes and additions. I made a couple of edits this morning based on his feedback and this was all discussed with Polina. But not much different from her on the PR. Generally it's pretty much in a state that is ready for 'Last Check': It's completed. I added this morning another 'Well Known' Property  (the preimage) which is a very common usecase for the metadata, removed some sections that weren't relevant to that CIP and some rewording. It's a pretty large CIP. \n\n=> Moved to 'Last Check' [PR112](https://github.com/cardano-foundation/CIPs/pull/112)  \n\n### Discussions  \n\n**F** - Other items that we might want to cover - some CRC conversations, and the advancing of the CIP statuses.  \n**M** - Let's go over the CIPs statuses: It's a question we could solve rapidly.   \n**F** - I'm inclined to take more time to go through them, maybe we can see how far we can go  \n**M** - What was said last time was we could go over a few of the propposals and see if we could advance them - maybe it is faster than anticipated and we can do them all.  \n**M** - OK. [CIP-0002](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0002/CIP-0002.md) the coin selection - this one is implemented at least in the cardano wallet and the NAMI wallet. As far as I've seen they have provided their code opensource which is a javascript implementation of that one and the Cardano wallet has a Haskell implementation of it. It would deserve to be extended with the multiasset concerns which was introduced with Mary. Coin selection approach is very much the same but had to be tweaked a bit because there is no strategy for how to handle the multiassets. At least for the spirit of it (the self-organizing approach) still very much applicable. I think it could be set to 'Active' - I will chat with Jonathan, and maybe see if it is worth doing another new CIP making this one obsolete - it would cover multiassets additionally. I think this would be a good usecase for that - move this one as 'Obsolete' and have a new one that takes over. But in the meantime, it should be 'Active'.   \n**S** - Agree. 'Active' is fine.   \n**F** - Will reach out to Jonathan - Next is CIP-0003.   \n**M** - [CIP-0003 - \"Wallet key generation\"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0003/CIP-0003.md) is definately active - the CIP was done retroactively and so is exactly what all wallets use today on Cardano to generate keys from recovery phrases and that includes Trezor, Ledger,Yoroi, Cardano wallet, NAMI, daedalus, probably CC wallet, Exodus ... every possible wallet is following that. 100% 'Active'.  \n**F** - While all those changes are proposed directly to the statuses of those CIP it might be worthwhile to have that 2 week lag so folks can weigh in on the change to 'Active' - Pending any objection, 0003 is 'Active'  \n**M** - What do you think about a PR changing the Status to 'Active' and pinging the respective Authors to react/aggree/give feedback? I think that's fair.  \n**S** - That sounds like the faster option.  \n**F** - There will be a PR to change the status, notifying the Author. I'll bundle something when I make the notes and go from that unless someone wants to jump in and change that.   \n**S** - [CIP-0004 - \"Wallet Checksums\"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0004/CIP-0004.md). For the Wallet checksums, it is active. It's used by Yoroi, CC wallet, and also Flynt.  \n**M** - 'Active'  \n**S** - [CIP-0005 - \"Common Bech32 Prefixes\"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0005/CIP-0005.md). It's used by everybody.  \n**M** - And is geting extended from time to time with new prefixes and units. Used by CLI and APIs as reference if only for the address prefix.  \n**F** - [CIP-0006 - \"Stake pool extended metadata\"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0006/CIP-0006.md).  \n**M** - I think it is used?  \n**S** - Adapools uses it.  \n**M** - I think it was at the time of the ITN and people wanted to have this ITN special 'tag' - I think it's still in use, have seen the pools using extra metadata that isn't part of the initial set? It would be good to confirm with the author maybe - unless 100% sure Sebastien?  \n**S** - I know adapools is using a share model to modify things internally - I don't know if others explorers are using this still. I would assume that pooltool is using it since they contributed to this spec as well. Not sure.   \n**F** - [CIP-0007 - \"Curve Pledge Benefit'](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0007/CIP-0007.md) was setup as a 'Draft' to discuss, there has been no change I assume on IO's part.   \n**M** - I think it should be 'Proposed' and not 'Draft'  \n**F** - What is the path towards active for this PR?  \n**M** - I get your point and I don't expect much will happen (to try defining a \"path to active\"), mostly because this deals with the Core team on the Ledger  \n**F** - Can we suggest to the Author to add to the PR with the proposed path to Active \"to have the Core team's implementation\"?  \n**M** - But he has no control over the core implementation. It's fair enough to propose it. Maybe a good time to change the status if other things have changed?   \n**S** - [CIP-0008 - \"Message Signing\"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0008/CIP-0008.md) - it's implemented by NAMI and Flint. There are quite a few dApps and users using this. Good to change to 'Active'  \n**F** - [CIP-0009 - \"Protocol parameters\"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0009/CIP-0009.md) this is the initial Shelley Parameters changes and the changes since. I don't know if this was updated since.  \n**M** - There is one PR updating it with the Alonzo parameters and the new parameters introduced in Alonzo genesis. I don't think the parameters are updated that often: There is the d parameter that gets updated each epochs. Kevin is updating and keepingthis up to date aas far as I know.  \n**F** - I thought there would be a CIP for Shelley, one for Alonzo, has this changed since or will we have one giant CIP with all the parameters  \n**M** - I think we said we would have one per era (if relevant). There haven't been new parameters in Mary or Allegra so there was no need for new CIPs. At the same time it's good to have everything in one place, we should look back in the meeting notes.   \n**F** - I believe the PR from Kevin is only for the Alonzo parameters, and last I checked with Keving there were 160+..  \n**M** - The thing about the Alonzo parameters, you have a dozen main ones or so and then you have the cost models params for Plutus. You could see them as one giant param, as values for individual parameters for each operation, so that takes some space, you don't have the give an extensive description for all of them, they refere to specific machine operations.  \n**F** - Maybe reach back to Kevin on this one wether this should be setup or updated.  \n**M** - For the Shelley one, it's definately 'Active'. Then we have to see what we do with the other PR.  \n**F** - Maybe we should request the Title be properly bounded (and change the title to \"Shelley Parameters\"). \n**M** - But then it would be a bit confusing to have two CIPs describing the same thing on different Eras, but at the same time it would be clear. Ideally they would push a CIP BEFORE the HF to discuss the values upfront.. So yea, this one renamed as \"Shelley Protocol Parameters\" and for the next one have a third CIP.  \n**S** - I agree with the title change but I think the content is fine.  \n**F** - What about the status?  \n**S** - I think Active is fine, as was mentioned, the next CIP would be a new CIP, so fine to leave this one active.   \n\n\n### Close      \n \n=> [PR88 / CIP30 - \"Cardano dApp-Wallet Web Bridge\"](https://github.com/cardano-foundation/CIPs/pull/88) to 'Triage'  \n=> [PR116 / CIP27 - \"CNFT Community Royalties Standard\"](https://github.com/cardano-foundation/CIPs/pull/116) to 'Triage'  \n=> [PR112 / CIP26 - \"Cardano Off-Chain Metadata\"](https://github.com/cardano-foundation/CIPs/pull/116) to 'Last Check'  \n=> **Merged** as CIP-0029 (Draft) - [PR117 - \"Phase-1 Monetary Scripts Serialization Formats\"](https://github.com/cardano-foundation/CIPs/pull/117)  \n\n+ We went over the 9 first CIPs to review and advance status, will out to Authors regarding to changing the status to either 'Proposed' or 'Active' (If agreed)    \n   \n\n\n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/CIP-0001.md) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/CIP-0002.md) | Draft |\n| 3 | [Wallet key generation](../CIP-0003/CIP-0003.md) | Draft |\n| 4 | [Wallet Checksums](../CIP-0004/CIP-0004.md) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/CIP-0005.md) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/CIP-0006.md) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/CIP-0007.md) | Draft |\n| 8 | [Message Signing](../CIP-0008/CIP-0008.md) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/CIP-0009.md) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/CIP-0010.md) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/CIP-0011.md) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/CIP-0012.md) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/CIP-0013.md) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/CIP-0014.md) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/CIP-0015.md) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/CIP-0016.md) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/CIP-0017.md) | Draft |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/CIP-0018.md) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/CIP-0019.md) | Active |\n| 20 | [Transaction message/comment metadata](../CIP-0020/CIP-0020.md) | Active |\n| 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/CIP-0021.md) | Draft |\n| 22 | [Pool operator verification](../CIP-0022/CIP-0022.md) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/CIP-0023.md) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/CIP-0024.md) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/CIP-0025.md) | Draft |\n| 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/CIP-0029.md) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/CIP-1852.md) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/CIP-1853.md) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/CIP-1854.md) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/CIP-1855.md) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-11-09.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [November 9 2021 notes](#november-9-2021-notes)\n  * [Triage](#triage)\n      + [PR88 - \"DApp Connector\"](#DApp-Connector)\n      + [PR116 - \"Royalty Standard\"](#Royalty-Standard)\n  * [Last Check](#last-check)\n      + [PR112 - \"Offchain Metadata\"](#offchain-metadata)\n  * [Review](#review)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 11/09/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## November 9 2021 notes \n\n**Attending Editors**: Matthias Benkort, Duncan Coutts, Sebastien Guillemot, Frederic Johnson, Robert Phair. + guests.\n\n\n### Triage  \n\n#### Royalty Standard\n[PR116 - \"Standardization of Royalties\"](https://github.com/cardano-foundation/CIPs/pull/116)  \n**Frederic** - This tentative CIP is by [HuthS0lo](https://github.com/huths0lo)  \n**HuthS0lo** - This is a community-based standard based on a conversation started a couple months back prior to the implementation of smart-contracts. We worked together, pooled ideas and met as a group to take decisions on what might be the best implementation for the community and once that got solidified, the PR was finalized. If you look in the PR history, you can see it has changed a lot compared to where it is today - and a lot of that has to do with protecting people around NFTs, and essentially now the marketplaces will only honor the royalties defined in the first transaction - the reason for that is that we don't want people to be swindled at a later time (by changing royalties). By doing that we ensure that people cannot modify the royalties. A lot of significant individuals were involved in those conversations - CNFT.io, Artano... That's how we got to now, happy to discuss specifics, but this should be straightforward: we defined the specific metadata we would be looking for, and again it would be on the very first mint for a policy.   \n**F** - We previously set this as a 'Triage' item, there were minor tweaks requested, but otherwise is it in need of verification?  \n**Matthias** - I noticed something around the address in the metadata - I don't see any reason to add the address in Bech32 encoding since it's something that will end up on the blockchain anyway: it is causing issues because it goes over the 64 bytes length for the address, so I am suggesting here instead to encode the address as plain bytes (since it can be at most 59 bytes and would therefore always fit). That would also get rid of potential problems of having two representations for the metadata..  \n**H** - I don't have a problem with that per se, but a lot of that is based on the assumption that we wanted this to be simple for people to implement - I don't think the average person will be able to do that (the average person creating a NFT), plus this adds complication for marketplaces who'd have to extrapolate what the address should be. We're looking for simplicity, this is kinda going against the design the group was going for.  \n**Mateja** - Why do we have 'rate' and 'address' as a string and not 'address:percentage'? What is the necessity to have rate and address as strings when we know that they would be key-values pairs / the actual value of the rate?  \n**H** - This is what Clark was talking about - the original design is just two things, the address and the rate, nothing more.  \n**M** - That is what I am saying, put the address on the left side, put the rate on the right side. That's just a suggestion.  \n**M** - That would make sense but then you still have 'too long an address' issue on the key and you would have to account for that.  \n**H** - In the proposal you could do an array if you have an address that extend beyond 64 bytes..  \n**Matthias** - Looking from the human perspective we want to look at the json and understand, but jspon is meant for machines. People writing metadata will use tooling and libraries to do so. And libraries will do the convertion between Bech32 and Hex and whatever is needed here / whatever is needed. I don't think this makes it much more complicated, however having to worry about two potential different formats for the metadata will add complexity, to check if a string, to recompose the address correctly: There is something wrong with that.  \n**H** - We can't make everybody happy, we've had a lot of people that had oppositions and requests... We meant this to be something that is community driven and voted upon and it is ALREADY being used, there has already been 1000s of tokens.  \n**Mateja** - The standard has not been approved though. Maybe we can touch to why it might be a problem right now:\nHere, you have to mint a new token as soon as there is a new policy  \n**H** - But that is what you want to do..  \n**Mateja** - Let's say you want to donate to charity X, then charity Y, and collaborate with Z, then you have multiple policies. Imagine thousands of policies being created on Cardano. Then all the marketplace have to validate all those policies. That they don't know..   \n**H** - I understand what you are saying but you aren't offering any better solution on the table.  \n**F** - This is a singular proposal and there is room for other proposals with different kind of implementations - any merging does not imply acceptance or endorsement by IO, CF or Emurgo. Is this PR good structure good to go, or are there strong opposition to this being moved along (as it has been discussed multiple times)   \n**Mateja** - There are strong oppositions from Artano and others in the space...  \n**Matthias** - There are no technical problems with using the string here, I don't think it's the right decision to make, because the alternative would simplify a lot of things for tools and applications.   \n**F** - This would only be merging the CIP as a 'Draft' - the conversation can continue then.  \n**M** - There was also a bit about the changelog at the end which I don't think is necessary, could use GIT rather. This is why we use version control and have a lot of the comments in the repo. Maybe rather use better commit messages in the changelog, could use better standardized messages rather than the H2 titles, which would look off in the auto-gen site.  \n**F** - We can continue the conversation once merged, but worth moving this one along as it has been approved by Duncan and Sebastien already. Proceeding.  \n  \n=> Merge NOW [PR116](https://github.com/cardano-foundation/CIPs/pull/116)  \n\n\n#### DApp Connector\n[PR88 - \"DApp Connector\"](https://github.com/cardano-foundation/CIPs/pull/88)  \n**Frederic** - This was discussed at length during prior Editors meeting [#30](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-09-21.md), [#31](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-10-05.md) and [#32](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-10-19.md).  \n**Rooooooob** - I've recently removed the event API because we figured it was better to do that as a separate change later on. The only outstanding issue is the datasign endpoint. Alessandro and I had a discussion in the PR but have not seen other opinions. Currently in the specs the datasign endpoint is very vague, so we are thinking of making it a lot simpler, where it would use the CIP-0008 message signing spec but would use it in a very simplified way: the wallet would take the payload and construct cost-compliant objects from that. It seems Alessandro and I are on the same page, if no opposing opinions would assume that it would be fine to merge it in.  \n**F** - Might be better in a separate PR?  \n**R** - What is currently in the PR is not well defined for endpoint. Since no one else has had an opinion in the conv. & Alessandro and I are on the same page about it (and came up with a well defined change about it) would you recommend we take out the endpoint bit as a separate PR?  \n**F** - I think we could merge this PR as 'Draft' and have a separate PR for signdata endpoint.  \n**Matthias** - As a suggestion, just before merging leave a note in the endpoint section stating that \"this section is currently being worked on (and should be updated in an upcoming PR)\" and bring the conversation in that PR. I am still catching up to this conversations but it doesn't preclude this PR being merged as it is.  \n**Sebastien** - I would like to merge this sooner than later, because there are changes we will have to make for Alonzo, for the events (ex NAMI supports events) but that should be its own discussion. We still have to discuss how to allow websites to ask the user Which DApp connector they want to use... We did some of it where we added the name and logo inside the injected data, but this isn't in the injected data, which doesn't help much the website get all the logos and names.  \n**R** - Don't they already have acccess to the information they need? Sure you could add some library on top of that that the DApp could use.. But couldn't they just inject the cardano object (and have the list of all names and data..)?  \n**S** - No because every wallet will override the entire cardano object. Right now NAMI override the Cardano Object.  \n**R** - I thought they would just insert a field?  \n**M** - There was the question of namespacing it at some point...  \n**R** - But that's already namespaced in the Spec, it's been in there for quite a while, this change was done months ago.   \n**S** - I don't know people implementing this, but I can try to force people to move to this.  \n**R** - The current Yoroi implementation has moved to this at the very least, I am not sure about any other implementation like NAMI or other, I'll have to take a look at that.   \n**S** - I can tell you for a fact that they (NAMI?) are just overriding.  \n**M** - I see, it's mentionned in the initial API Intro that states that the wallet has to use their wallet name as a namespace, but then the API is given as wallet.enable, wallet.whatever.. Which is not really clear that this has to be the wallet name and not the **word** wallet.. Perhaps we could use curly braces around the word to show that it's templated?  \n**S** - Point being is that we should have these other discussions in separate PRs, and would prefer this be merged today.  \n**F** - Thanks for adjusting the dir structure, and adding checks in the PR to move this forward. Once we have the 3 signoffs this should be good to go, and conversations can reference this PR if needs be (notably for the discussion in the PR itself)  \n\n=> Merge NOW [PR88](https://github.com/cardano-foundation/CIPs/pull/88) \n\n### Last Check   \n  \n#### Offchain Metadata \n[PR112 - \"Cardano Offchain Metadata\"](https://github.com/cardano-foundation/CIPs/pull/112)  \n**M** - Nothing has changed since last few weeks and it was discussed with Michael (Peyton-Jones). We had a few iterations and removed some sections that were redundant. It hasn't changed in a month or so.  \n**F** - Any objection to merging, else this will be merged.  \n\n=> Merge ASAP [PR112](https://github.com/cardano-foundation/CIPs/pull/112)  \n\n\n### Review  \n\n### Discussions  \n\n#### Alternate CNFT Royalty format\n**F** - Mateja can you elaborate on the disconnect or distinction with the prior [PR116 - \"Standardization of Royalties\"](https://github.com/cardano-foundation/CIPs/pull/116)?  \n**Mateja** - What our problem is right now is that the space is sortof skewed towards big (NFT) collections, the \"10k's\" and similar. What that doesn't account for is the '1-of-1' artists, who want to make unique pieces. For example we have artists who are going to sell for 10s of thousands of dollars one piece, and they don't want to have to scroll through 100000s policies just to find the right royalty they want to put on this NFT. There's a signature for the artist and a royalty policy dealing with funding. We want to find a way to decouple the artist signature and the royalties/policyID somehow. It's also burning the approval process, so if you have more policyIDs just for the sake of creating royalties, you will have more problems with marketplaces like CNFT.io: they need the policyID in order to prove specific projects.. So if you have more '1-of-1's which Artano will bring for sure (we have already 200+ NFTs in one collection, with 70 artists and each artist wants their own policy, which isn't a problem, but likely doesn't scale, and THAT is our problem. I understand that there is a skew towards not burning, the UTXO issues, and having the least text attached to the NFT itself... There might be better way to solve this but right now as we see it, the current prior PR linked is an overkill, and favors having one policy for many NFTs, which is not necessarily desireable for every creator.  \n**Sandeep** - Let me add: the current CIP since the address is specified in the policy level, it makes it difficult to use skipaddress, our smart contracst, because the first token that we mint on that policy already requires the address which means we don't have flexibility to have more. The issue is with the smart-contract: we need to have a script address or a smart-contract address **before** we mint any of the NFTs, because according to this (CIP) standard, the first one that is minted is the royalty token, which needs an address, and all tokens minted afterwards and keys, will all use that royalty address. That means the tokens that are minted afterwards, we don't have any flexibility to have this logic incorporated in the smart contract specified in the policy itself. Because the smart-contract for the royalties has to be already created, at least we would need the script hash to obtain an address. It does not give up the flexibility to define the royalty logic for (individual) NFTs which is not good when you are doing collaborations, like in our case in ARTano. Let's say we are doing a collection with  10 artists. For each artists, we'd want to transfer different NFTs, so royalties for different policies. Whoever is the owner of that particular NFT.  \nWe could create different royalty policies for each individually, but I think it would be cumbersome / not flexible. What would be a common ground? We could specify the same metadata that is specified in the royalty token. We could put that also in the NFT yourself and give precedent to the royalty that is present in the NFT over the policy. It could be something like \"If there is metadata present in the NFT, then it takes precedent - else it defaults to the policy metadata\" - it could also work regarding smart-contract because we don't have to know, we don't have to define the logic for the royalty smart-contract before we mint any token. To me that doesn't make sense.  \nRegarding updating metadata, this is NFT the one you want, we don't mint it anymore. I don't understand the part about overriding the metadata. That was one of the arguments in the previous CIP in a previous meeting, when we were talking about the royalties, we were noting the metadata could be overwritten as NFT. And because everything is in the blockchain we could always check what it was at that time. In short, we would prefer having individual level granularity control rather than covering groups, so that when you see the policy in the blockchain, you can see all the NFTs associated with that artist, which makes more sense in our view rather than have a growing number of policies.   \n**F** - Thanks for the explanation, it sounds as though you have a valid (new) proposal emerging. Any other opinions that should be surfaced?  \n**Duncan** - I don't have a strong opinion, but if people have different usecases and different solutions, it is perfectly fine to have different CIPs with different purposes, one optimized for people doing large NFT collections, and a different approach for smaller collections. I don't see issues with that.   \n**F** - Is there a PR being in the works for this Sandeep? I saw a forum post linked...  \n**Sandeep** - We don't have a PR yet, can create one and discuss more publicly.   \n**F** - Unless if you prefer to engage more in the forum or elsewhere if wanting to engage with CNFT actors and preferences directly.  \n\n#### CIP Directory format tweaks\n**Matthias** - I was pointing at PR125, which is not a CIP per say but a restructuring of the repository per say, which has a few merge conflicts but could be updated if relevant. The idea was to move all the CIP files naming and to update at the same time for the autogen site, which is functionally similar to the github UI and a readme rendering. If we want to proceed, I think we should move this sooner rather than later as the CIP repo is getting more and more traction, people are getting into it. Most folks land on the Github repo page which is fine. If you hit a deadlink you should still find you way back to the CIP github. I can also update the PR to touch all the CIPs that were merged since.  \n**F** - Agreeing in spirit - but I was surprised that more than expected users were actually using cips.cardano.org. The breaking of the site might be something to prevent, but yes it would be in our interest to move the structure of the repo in that way.  \n**M** - What might be a bit tricky is the linking to the prior files that would be renamed (the site should be easy). One way to do would be to preserve the old CIPs and duplicate as readme. And enforce the new format from then on. Then all the new CIPs would be in the new structure.   \n**F** - Want to move this forward for better UX if we can translate that with the site this should be good.  \n**M** - Not afraid of the website, it's more about the linking directly into github.   \n**F** - Do you mean people referencing the markdown file in Github? As opposed to what?   \n**M** - Right, then you can just link directly to the repository subdir rather than the file itself. and the markdown would render still. This (minor PR) is the kind of PR that is difficult to maintain because it changes as soon as someone pushes a new PR, so if we're ok to proceed, I will update and we should try to merge it ASAP and if not ok I can close and we stay with current structure.  \n**D** - I think the idea is fine, breaking links is not a major issue either way.   \n\n#### Looking for Community involvement\n**F** - Also wanted to flag that we are looking for people from the community to join and participate in the CIP Editorial process - Come join, promote, help curate and help surface transparency, facilitate conversation on forums etc... We do not yet have an onboarding process to editorship, but this effort is intently neutral, and your stepping up is very much welcome.  \n**D** - On that note, I will be stepping down for a few months (from CIP Editorship), so this meeting will be my last meeting for a while. I will ask for individuals from IOHK to step up - yet the general point is quite true.   \n\n#### CNFT and royalties\n**Clark** - I (and people that I have been talking to) want to express some concerns regarding the current CIP here (27) where they say it's a bit inflexible and one of the things that it is inflexible about is that under the same PolicyID the artist can configure different settings of their royalties for each token for example by just that alone and forcing to mint a new policyID where some artist has some opinion that a single PolicyID acts as signature, that's why some projects choose to collaborate and just stick to one, and also keep up single policyID open to mint more of their art - In summary, this current CIP does not support those usecases at all.   \n**F** - a new proposed standard might be a good path to cater to those usecases.   \n**HuthS0lo** - To your guys point it's by design, it's meant to be inflexible / to protect the buyer - a buyer has the right to know what they are getting into when they buy a NFT - with apps implementing CIP-0027, buyers are protected from changing policies post-purchase. It's meant to be inflexible and immutabe. It's not going to make everybody happy.   \n**C** - I agree with the immutability and the not screwing ppl over but I think that NFT projects have this concept.. for example some artist leaves the policyID unlocked meaning that users buying this NFT trust this Artist to not duplicate their work or other weird stuff. If that's valid then why bring it up to the user of the NFT?  \n**H** - We can allow it for one person but not for multiple ppl that migth use it for nefarious uses, that is the whole point. We did not have royalties prior to this.   \n**C** - If someone changes their royalty from 1% to the 100%, the user can see the change and (that user) was duped..   \n**H** - I'm confused, not sure what you want.   \n**F** - (Suggest the forum be used to elaborate and go into its own proposal).   \n\n\n\n\n### Close    \n\n=> **Merged** as CIP-0030 (Draft) - [PR88 / CIP30 - \"Cardano dApp-Wallet Web Bridge\"](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030)  \n=> **Merged** as CIP-0027 (Draft) - [PR116 / CIP27 - \"CNFT Community Royalties Standard\"](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0027)  \n=>  Merge ASAP (needs 1 more editor approval on PR) [PR112 / CIP26 - \"Cardano Off-Chain Metadata\"](https://github.com/cardano-foundation/CIPs/pull/112)   \n\n   \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Draft |\n| 3 | [Wallet key generation](../CIP-0003/) | Draft |\n| 4 | [Wallet Checksums](../CIP-0004/) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/) | Draft |\n| 8 | [Message Signing](../CIP-0008/) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Draft |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/) | Active |\n| 20 | [Transaction message/comment metadata](../CIP-0020/) | Active |\n| 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft |\n| 22 | [Pool operator verification](../CIP-0022/) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/) | Draft |\n| 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft |\n| 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft |\n| 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-11-23.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [November 23 2021 notes](#november-23-2021-notes)\n  * [Triage](#triage)\n    + [PR147 - adding metadata labels (to CIP-0010)](#labels)\n    + [PR152 - moving CIP 7 to 'Proposed'](#cip7) \n    + [PR112 - CIP-0026 | \"Cardano Offchain Metadata\"](#cip26)\n  * [Last Check](#last-check)\n  * [Review](#review)\n    + [PR137 - \"On-Chain Token Metadata Standard\" (tentative CIP-0031)](#cip31)\n    + [PR148 - Update to CIP 30 (signData API)](#cip30)\n    + [PR150 - modification to CIP 19](#cip19)\n  * [Discussions](#discussions)\n    + [PR130 - Updates to CIP 13](#cip13)\n    + [PR140 - \"Protocol Parameters (Alonzo)\"](#alonzo-parameters)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 11/23/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## November 23 2021 notes \n\n**Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, Frederic Johnson, ~Robert Phair~.\n\n\n### Triage  \n\n#### Labels\n[PR147 - adding metadata labels (to CIP-0010)](https://github.com/cardano-foundation/CIPs/pull/147)  \n**Frederic** - It seems we gathered all the green ticks (approvals) for this to be merged  \n**Matthias** - This raised an internal consideration here - should we be requiring more information from people adding labels to this? Because a lot of those are modifying this registry, but giving no actual justification or rationale for it. While at the moment there is no abuse, everyone appears to have an actual project behind the request, but should we start thinking of something a bit more standardized, asking what the project, background or reasoning, including some way of verifying they are indeed related to a particular project and so on.  \n**F** - I think this is an issue we have with the Cardano Foundation's Token Registry, where there is leniency but likely a need for enhanced verification. A Registree registring with a Registror (in this case the CIP repo) has an expectation that there is some criteria of acceptance/validation that was passed: a modicum of validation?  \n**M** - Yes. Not asking for a KYC or extended thing - but maybe ask the Author to provide some background behind that specific label and why it is being added, to filter out a bit.... So far no abuse so not a big deal \n**F** - Defining a threshold of Validation: Checking that the site exists or something like that?  \n**M** - Yes, that's what I did for CardanoHub, Looked around, checked the Github and the user account seems legit. A weak verification still?  \n**F** - As long as it gathers the approval of 3 editors this should be fine: we serve as the filtering mechanism. Hopefully flags get raised for dubious projects.  \n**M** - OK  \n=> Merge NOW [PR147](https://github.com/cardano-foundation/CIPs/pull/147)  \n\n#### CIP7\n[PR152 - moving CIP 7 to 'Proposed']  \n**F** - This was proposed by Shawn as a CIP and he has pushed to move it to 'Proposed'. This prompted a concurrent conversation, the need for a \"Path to Proposed\" to be added in CIP 1. I would be inclined to merge this one as-is. We've had a conversation with Shawn and he agreed that a way towards active would be to have IOHK or whatever implemented have this, still in the current setup it would formally be better if there was a defined section in there as \"Path to Active\".  \n**M** - I agree. It might also be a good time to do a second round of calls within IOG asking people to look again at this CIP and maybe give a clear answer on wether or not this will be implemented. It's fine to merge. That's part of the conversations we had a few meetings ago. I do think any CIP merged in the repository should have a status 'Proposed' (rather than 'Draft') as that's close to what the merge is conveying in a way, as \"accepted by the editors\". Maybe not in a final state. But it should have a \"Path to Active\" that clearly describes how that CIP would be considered active. There might be some exceptions such as CIP 30, where there are still points under discussion in new PRs, which would still have it be a 'Draft', because there are additions and people know they still want to make modifications. Short story: I agree to move this one to 'Proposed'.   \n=> Merge NOW [PR152](https://github.com/cardano-foundation/CIPs/pull/152)   \n\n#### CIP26\n[PR112 - \"Cardano Offchain Metadata\"](https://github.com/cardano-foundation/CIPs/pull/112)   \n**F** - Needs one more review for this to be merged.  \n**M** - Duncan has approved, we set it up to two mandatory so we could go ahead as I am the author.  \n=> Merge NOW [PR112](https://github.com/cardano-foundation/CIPs/pull/112)  \n\n### Last Check   \n\n### Review  \n\n#### CIP31\n[PR137 - \"On-Chain Token Metadata Standard\"](https://github.com/cardano-foundation/CIPs/pull/137)   \n**M** - This is a follow on from the prior meetings discussions, by Matt Ho from SundaeSwap.  \n**F** - Seems we're all new to this.  \n**Sebastien** - I think it's fairly straightforward, it's just the registry but onchain instead. The core concept is nothing difficult.   \n**M** - It's more almost a philosophical concept at this point: \"Should you put metadata onchain or not?\" We discussed it previously, the pros is that it's readily accessible if you're monitoring the chain, and the dev experience is a bit easier. The cons is that you make the whole blockchain bigger for storing data that in the end has no reason to be there (The blockchain making for a very poor database) So instead of storing the metadata onchain, it might be considered better to push a hash of the metadata onchain to precisely avoid putting metadata onchain. At the same time we don't prevent people from doing it - and if they really want to do that - at least it's good that they have comments turned off for doing it. It's also very similar to that other proposal for NFT - CIP-0025. And this one looks like an interation on top of that one, which makes it slightly more generic, to expand beyond NFTs, for broader metadata and at the same time still covering things like names, image, url... etc.  \n**S** - This is also similar to the pool, which also had. This CIP tries to referate a website for authentication, making an effort to tie the metadata to the person that authored it.   \n**F**  - Regarding the Structure of this CIP, do you see anything wrong - should we push it out to next meeting to review?   \n**M** - One thing that is actually missing is the rationale, which is esssential. Why is this a good idea and why would you do that? I can understand it and imagine, but maybe I would like to have a rebuttal for the cons (why it's ok to put all this data onchain.. etc)  \n**F** - The motivation can serve as rationale if you look at it that way, It's similar.  \n**M** - Similar but not the same thing. Motivation is why you write the CIP and the rationale is why the way that it is solved is ok (and why the decisions make sense in here). It could also be worth discussing CIP-0025 since they come ater, should it be reconciliated as one, coexist..?  \n**F** - CIP-0025 is the NFT Standard they weren't aligned with a few meetings ago.  \n**M** - And we've more or less already had that discussion about the on-chain or not conversation. If we take back the last comments from the CIP-0025 we can see all the suggestions we made at that time that are still likely applicable for this new PR. We had quite a few remarks on how to structure things, WHy putting things onchain was good or bad, and some suggestions such as \"as for the schema\" maybe use something more standard like a json schema (as could be found on schema.org) and how this references many things as schema, such as if you were an organization, here are all the fields and or references or semantics, types... Everything we said in there still applies to this one as well. If this is going to become a thing to have metadata onchain, let's try to have a very general approach and say \"you have to pick one of the schemas that is in there\" and have clear rules on what should and shouldn't be onchain. At the same time, you can also just hash it, put the hash onchain and a URL to that Hash and that's it... Then you avoid having to store onchain all of that data and you can still have the benefits. More complicated to update it, but that was the same problem with stakepool metadata. That was the spirit.Maybe someone else can comment.   \n**F** - I see your point about not trying to store things on the chain but I feel it might be fine to have those as concurrent (yet opposed) CIPs and have that conversation on wether to merge or distinguish them at a later time: Enable people to see that there are different options and maybe speak up about that discussion.  \n**S** - Personally I am in favor of making it easier of using Cardano as a Data Dump, and not have to jump through hoops to dump data on Cardano. And therefore am in favor of this CIP. I would prefer if we had an easier way to do this rather than Tx metadata, but it's what we have.   \n**M** - For this PR, I'll comment in there asking for a clear rationale, I don't mind per say if this is merged, just \"slightly\" opposed. If folks are going to dump data on the blockchain let's make it in an organized way. Still I want a clear note that people have acknowledged the problems (and it mentionned in this CIP) that this is maybe not the best way to approach it and have it compered or noted that it differentiates itself from CIP-0025 and that we also will likely need to have this as a separate json schema that can be referenced and used.   \n**S** - Makes sense.   \n**F** - Moving this to Last Check and should be merged next meeting hopefully.   \n=> To 'Last Check' [PR137](https://github.com/cardano-foundation/CIPs/pull/137)  \n\n\n#### CIP30\n[PR148 - CIP-30 signData API](https://github.com/cardano-foundation/CIPs/pull/148)   \n**F** - This is the continuation of CIP-0030 focusing on the specific section around the signData API, to help focus the comments without having to regress through the 100+ ones on the prior PR. Is this ready for review?  \n**S** - This is kind of a tough one, there are many ways we could go about this. It depends on what people/authors prefer. It kindof runs into some issues with the rust lib as well. Created an issue to address this on the rust side as well. I would not merge this yet, and get people who are using the message signing spec and give feedback on the library and the implememtation and what they think should be changed.   \n**F** - Looks like there has been an extended convo between Rob and Alex. If someone can step in the conversation to give perspective otherwise it will be part of the notes for this meeting and will be tableed towards a review next meeting.  \n=> To 'Review' [PR148](https://github.com/cardano-foundation/CIPs/pull/148)  \n\n#### CIP19\n[PR150 - CIP-0019 readability update](https://github.com/cardano-foundation/CIPs/pull/150)   \n**M** - I had a small discussion with Heinrich and he said he would make a few updates on CIP-0019 to clarify the distinction that exists between human-readable addresses and the binary representations of addresses that are one and one thing but two different views of the same thing which wasn't clear from a potential newcomer perspective. ALl those are actually encoding of a binary representation that is simply described by this CIP. He moved one section, the user-facing encoding and clarified a bit that addresses can be encoded by bech32 or base58 depending if they are Shelley or Byron addresses , and that this represents a binary format behind the scene that is described by this CIP. I reviewed the changes and it's good to go for me.   \n**S** - I'm okay with it too.  \n\n=> Merged **NOW** [PR150](https://github.com/cardano-foundation/CIPs/pull/150) \n\n### Discussions  \n\n#### CIP13\n[PR130 - Updates to CIP 13](https://github.com/cardano-foundation/CIPs/pull/130)  \n**F** - Robert who has been vocal about this has raised some considerations in this PR regarding the approach. He was pushing a URI framework CIP, unclear if he has pushed it yet, but the conversation has kept going regarding why we need Deadalus-specific approach.  \n**M** - I think this draft is pretty old now, so we shouldn't spend too much time on this one and I know the team (including myself) are working on a new version for this one that isn't Deadalus-specific that basically extends the URL scheme with some new capabilities which would allow services like Deadalus to work with the PAB and for example partially pass Txs with payloads accross services to another services. I know the update is for \"soon\" so at this stage, this PR can probably be disregarded until that happens.   \n**F** - This is two months old, and isn't a CIP by itself, just an update to CIP 13?  \n**M** - Yes, but it adds a completely new capability to the link format. Still two months not that old but still old. It's being worked on weekly if not daily, and the team is also working on making it sure and usable within Daedalus. Maybe I can ask Nicolas to comment on the latest update on this one? But this PR is more or less outdated in that respect. I don't know if they will try a new PR or update this one but it will be significantly different.  \n=> Likely deprecated in its current form  \n\n#### Alonzo Parameters\n[PR140 - Alonzo Protocol Parameters](https://github.com/cardano-foundation/CIPs/pull/140)  \n**F** - CIP 9 was specifically the Shelley Protocol Parameters and that was the conversation of changing this to \"Shelley Protocol Parameters\" and effectively have a separate CIP for \"Alonzo Protocol Parameters\".   \n**M** - Name it won't work and it might be worth it as having it as CIP32 (or 28).  \n**F** - Might be worthwhile to reference it in CIP-0009.   \n**M** - Definately cross-reference them.   \n**F** - I think specifically we should make a separate CIP for the protocol parameters for the NetworkIds? We don't have that yet for the specific deployment places for Cardano, it would be good to have that kind of registry available.   \n**M** - a few minor edits to do - change folder, add number, rename as readme... could just push changes on top really (Kevin has given go ahead).  \n=> Moved to 'Last Check' for next meeting (pending Edits)  \n\n#### CIP statuses\n**F** - CIP-0010  \n**M** - Should be moved to Active, the registry speaks for itself.   \n**S** - Fine to move to 'Active'   \n**F** - CIP-0011  \n**S** - Fine to move to 'Active'  \n**M** - Definately, being used by most of the tools.  \n**F** - CIP-0012  \n**S** - I think this was added by blockfrost and I believe Emurgo also added this   \n**F** - can setup as a Triage item for next meeting   \n=> Moved to 'Triage' for next meeting  \n**F** - CIP-0013 - 'Active'?   \n**M** - I would say yes, because some of those links are used I've seem that being used in Yoroi as well for sure  \n**F** - when we were discussed the Proposed status, it might be worth setting it as 'Proposed' with a \"path to Active\" of (a few services implementing the proposal)  \n**M** - Agree, we are doing that post-fact really  \n=> Tabling for now, to triage or 'Last Check' for next meeting  \n**S** - Active is fine, depends on what the Daedalus team thinks.  \n\n### Close    \n\n=> Minor Merges (such as [PR147](https://github.com/cardano-foundation/CIPs/pull/147), [PR150](https://github.com/cardano-foundation/CIPs/pull/150) )  \n=> **Merged** as CIP-0026 (Draft) - [PR112 / CIP 26 - \"Cardano Offchain Metadata\"](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0026)  \n=> [PR137 - tentative CIP 31 - \"On-Chain Token Metadata Standard\"](https://github.com/cardano-foundation/CIPs/pull/137) to 'Last Check' (should be merged in two weeks pending it receives appropriate approvals and structure reworked)  \n=> [PR148 / Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148) to 'Review' (will be discussed more intently next meeting)  \n=> [PR140 - tentative CIP 28 - Alonzo Protocol Parameters](https://github.com/cardano-foundation/CIPs/pull/140) to 'Last Check' (should be merged in two weeks pending it receives appropriate approvals and structure reworked)  \n\nCIP Statuses changes:  \nCIP-0007 'Draft' -> 'Proposed' [PR152](https://github.com/cardano-foundation/CIPs/pull/152) \n& trying to advance existing CIP statuses  \n   \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active |\n| 3 | [Wallet key generation](../CIP-0003/) | Active |\n| 4 | [Wallet Checksums](../CIP-0004/) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed |\n| 8 | [Message Signing](../CIP-0008/) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/) | Active |\n| 20 | [Transaction message/comment metadata](../CIP-0020/) | Active |\n| 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft |\n| 22 | [Pool operator verification](../CIP-0022/) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/) | Draft |\n| 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft |\n| 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft |\n| 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft |\n| 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-12-07.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [December 7 2021 notes](#december-7-2021-notes)\n  * [Triage](#triage)\n    + [PR156 - cosmetic edits and JSON rework (CIP 6)](#cip6)\n    + [PR166 - advancing CIP 9, 10 & 11 Status to 'Active'](#statuses)\n  * [Last Check](#last-check)\n    + [PR137 - tentative CIP 31: \"On-Chain Token Metadata Standard\"](#metadata) \n    + [PR140 - tentative CIP 28: \"Protocol Parameters (Alonzo)\"](#alonzo)\n  * [Review](#review)\n    + [PR148 - Update to CIP 30 (signData API)](#cip30)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 12/7/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## December 7 2021 notes \n\n**Attending Editors**: ~Matthias Benkort~, ~Duncan Coutts~, Sebastien Guillemot, Frederic Johnson, ~Robert Phair~. + guest Michael Peyton-Jones(IOG), Mateja (Artano).\n\n\n### Triage  \n\n#### 007\n**Mateja** - I wanted to reference the [forum post](https://forum.cardano.org/t/cip-007-for-intellectual-property-licensing-legal-documents-inside-nft-metadata/86116) on 007 standard for basically licensing and IPs documents inside of NFTs.  \n**M** - It's just a forum post, it hasn't been written on Github or other - I just wanted to propose a standardization of IPs, basically how we handle art and Licensing.  \n**Frederic** - (Looking at the forum post) - this would propose two options to add, the properly generated json or in the [CIP 25](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025) field. Do you feel this could be its own CIP or could it be tacked on to [CIP 25](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025)?   \n**M** - Good Q. It could be linked to [CIP 25](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025). That's also somewhat my question here, if it should be linked.  \n**F** - It matters wether you are the author of [CIP 25](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025) or ...   \n**M** - I am not, I beleive Berry (alessandro) is - I can reach out to them and ask.  \n**Sebastien** - I didn't know this blogpost existed until just now.  \n**F** - Let's move this to Triage for the next meeting.  \n=> Moved to 'Triage' for upcoming editor meeting 36  \n\n#### CIP6\n[PR156 - cosmetic edits and JSON rework (CIP 6)](https://github.com/cardano-foundation/CIPs/pull/156)   \n**S** - I think this one was approved by everybody - so we just need to merge it then.  \n=> Merged [PR156](https://github.com/cardano-foundation/CIPs/pull/156)   \n\n#### Statuses\n[PR166 - advancing CIP 9, 10 & 11 Status to 'Active'](https://github.com/cardano-foundation/CIPs/pull/166)    \n**F** - This is still lacking one approval but should be merged as soon as we get one more Editor approval.  \n=> Merged [PR166](https://github.com/cardano-foundation/CIPs/pull/166)   \n\n\n### Last Check   \n\n#### Metadata\n[PR137 - tentative CIP 31: \"On-Chain Token Metadata Standard\"](https://github.com/cardano-foundation/CIPs/pull/137)  \n**F** - There were some questions regarding the security of this PR.  \n**MPJ** - I was looking at this and linked it to [PR118](https://github.com/cardano-foundation/CIPs/pull/118) which has some similarities with ?[137](https://github.com/cardano-foundation/CIPs/pull/137) (Matt Ho's? Matthias?) which share similar issues. In particular if we make the assumption that it only works if we mint a token follow a particular pattern: It's fine for those, but then anything that doesn't follow that pattern is effectively attackable, which is pretty problematic. It would likely be very bad to promote something like that if it doesn't work for ALL tokens, because then, for the ones it doesn't work for, we're actually encouraging people to do something insecure. Maybe I should write out my concern in the PR more detailled.  \n**F** - Can you elaborate on the concern?  \n**MPJ** - All of these schemes rely on associating a particular transaction with a particular token, usually the one that minted it or the first one that minted token of that currency or something. But not all tokens have a single minting transaction, certainly it's not the case that all tokens are minted by the party that organized them - there are quite a lot of interesting usecase where they might be created/forged by third-party,the issue is not that it be the norm or not, but rather if we make this here a standard, then for the ones that don't follow this pattern, it might be that someone else might spoof the metadata or tools might get confused (tools having no way to check that this is a \"well-behaved version\" ...) And the thing that is really lacking is a Discussion around that to begin with: we should think about this hard. It would be bad if we just said \"oh btw, no one should ever do something that isn't standard because it might mean your metadata might get spoofed and your users might get attacked\"  \n**F** - In the CIP context, could we merge this as 'Draft' and have the conversation continue in the PR thread? (distinguishing between 'Draft' and 'Active')  \n**Sebastien** - I don't think so.  \n**MPJ** - Maybe if it had a security section such as \"this proposal requires a security analysis\" so that anyone reading it might understand that it comes without proper analysis. Merging this in without it is a bit too suggestive.   \n**S** - It's a strong point. Without addressing it more substantially I don't feel the proposal is complete. So I don't feel merging it (even as 'Draft') is the right option for now.   \n**F** - Should we get Inigo from IO to have a look at it?  \n**MPJ** - The proposer should figure out what they are trying to achieve: I feel what they are proposing is fundamentally unfeasible. The proposer must do some work to explain how they see this working (without it being problematic for the ecosystem)  \n**S** - I agree also that this is not fully solveable, but it should be more explicit about how to handle it, despite the fact it cannot be fully solved, as MPJ notes, it still handles some cases and it's not bad to have a proposal that fits \"most\" usecases (rather than all). There should be some section covering those aspects, the out-of-band assets that don't match the described creation pattern.  \n**MPJ** - will try to add a longer comment outlining the problem discussed in the PR.   \n=> On Hold / Tabled [PR137 - tentative CIP 31: \"On-Chain Token Metadata Standard\"](https://github.com/cardano-foundation/CIPs/pull/137) until further careful consideration take place  \n\n\n\n#### Alonzo\n[PR140 - tentative CIP 28: \"Protocol Parameters (Alonzo)\"](https://github.com/cardano-foundation/CIPs/pull/140)  \n**F** - this is the Alonzo protocol parameters from IO, an upgrade continuing on [CIP 9](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009) (Shelley Protocol Parameters). This should be good to merge, with two approvals.. Any opposition regarding merging this?  \n**S** - One of the problems with this one is that it is no longer accurate (as of last week) because the parameters were changed again - not sure who wants to handle this as it was changed in the middle of Alonzo (Block size increase). I don't know if we want to modify this here, or merge this and submit another CIP that mentions the size increase.   \n**F** - From speaking with Kevin he was intent on the \"Protocol Parameters CIPs\" being about the initial potocol parameters, as in the parameters at the beginning of the fork itself, which sounds to me as though this one would be fine to merge as-is: I don't want to have to be chasing for the current parameters continuously afterwards. I would prefer merging it and/or seeing how Matthias feels about it.  \n**S** - I don't think this is a technical decision, more like a \"how do we want to structure these CIPs for Protocol Parameters that happen by epoch\". Probably in an idea world, we should have merged this earlier and made a change to update it, and in this spirit would merge this as-is.. And then remind ourselves to do a follow-up CIP to this.  \n**F** - Why do we need an update/upgrade CIP?  \n**S** - Because the protocol parameter already changed.  \n**F** - I don't see us as having to keep up with the parameters themselves, just a snapshot of the parameters at the time of the fork.  \n**S** - I disagree, I think the protocol change parameters should have a CIP at least to discuss why changing the protocol parameter makes sense  \n**MPJ** - I think this is a broader conversation (i.e. \"Should protocol parameters changes go through a CIP or not?\").   \n=> On Hold / tabled for now, will continue conversation offband. (Likely merge and add a new CIP re:change)  \n\n### Review  \n\n#### CIP30\n[PR148 - Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148)   \n**F** - The singData API update is a continuation of the conversation regarding the signData API for CIP30 which was tabled and doesn't seem to be evolving much. Thoughts? This seemed to be built out by Rob on his own and it seems to have leveled off a few weeks ago.  \n**S** - I need to review this one but haven't had the time. I'm not sure if that will be feasible for next meeting either. For later.  \n=> On Hold / Tabled (for next meeting?) [PR148](https://github.com/cardano-foundation/CIPs/pull/148)   \n\n### Discussions  \n\n#### Updates\n(Looking at the [meeting 34 notes and the discussions](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-11-23.md) there)  \n**S** - Haven't been able to follow up regarding moving [CIP 12](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012) to 'Active' - Blockfrost ppl should be the ones to try to champion this.  \n**F** - About [CIP 13](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013) and the conversation..  \n**S** - Daedalus wanted to make a big change to it and we didn't know about moving to 'Active' in the middle of somebody making a large change..  \n**F** - Looking at the newer CIPs and the major discussions ongoing then. Potential CIP 31([PR159](https://github.com/cardano-foundation/CIPs/pull/159)) & 32([PR160](https://github.com/cardano-foundation/CIPs/pull/160)) & 33 ([PR161](https://github.com/cardano-foundation/CIPs/pull/161))?   \n**MPJ** - Those three are series of CIPs that build on top of eachothers based on the design work happening. We hope they will alleviate the way some things are currently.  \n**F** - What is the state of the conversation, any salient points?  \n**MPJ** - A bit early - the PRs have been only out for a week, let's see what people say about these. In particular I would like to get the CDDL proposed / pinned down before we merge them   \n**F** - Is that something you're working on through IO?  \n**MPJ** - Yeah, with the Ledger team - I'm not a CDDL expert. I just want to make sure that it looks like for the Tx CDDL to look at.  \n**S** - I commented on that point. The only thing you have to worry abotu the CDDL is that this is run through codegen tools and there's codegen tooling in Go and JS and both are not complete - but people have attempted to make them work. So any complex features would make it harder for the codegen tools to run, and if you don't provide name for fields, they get lost through the codegen process. It's a kind of art to write CDDL that codegens could code but at the end of the day (for the rust codebase) although we use the codegen process without having to work the kinks and end up having to manually fix issues because CDDL is a really bad language for codegen, it's not anything used so not a big deal.  \n**MPJ** - It's not my favorite thing either.   \n**S** - I wanted to talk about (tentative) CIP31/[PR159](https://github.com/cardano-foundation/CIPs/pull/159) the reference input CIP. One thing, the section on Hydra (it would be good to have Matthias sign off on that part - he's the expert here)  \n**MPJ** - There was internal discussion about that, because Hydra makes a bunch of assumption such as the Tx set being a graph, but now it is  bit weird, it can be looked at multiple times, what happens when you have conflicts... Certainly before this is implemented I have asked Manuel to talk to the researchers and make sure that the algorithm in charge of resolving double spend inputs would also work for reference spend inputs. I think if we get an ok with that, then it's fine - but we have to be careful about so that we don't accidentally screw up Hydra.   \n**S** - And for the ability to log reference: who we can use reference inputs? Is this something you've seen other people try to do or want to do or is that a thought?  \n**MPJ** - Obviously, you have to be able to lock them to control who spends them. To control who references them, we'd need another script field probably, because you don't want it to be the same one for spending, it's possible in principle, I am a little hazy on clear usecases (and it can be added later), because it would be changes to the change of outputs, in some way othogonal to this, the main usecase I have seen is \"someone who wants to have an oracle for people to pay if they look at the data\"... I think there is something a little dubious about this because all the info on the blockchain is public in some way and you'd be in some way charging for this and or looking at the authenticity of the data.. I don't know. An earlier draft of this design had some variants of that, where you could reference input, such as a \"check\" input that would look at if you can spend but without having to spend it. It could be a version of that. The design here is a bit open - a few options in the design space and so am keen to gather more usecases and think about ways we could go there. I think something like that would be rather incompatible with what we have here. I don't think we are blocking ourselves from any approach we take to solve that.   \n**S** - That's an interesting idea, to prove one can spend but won't spend... I can think of a usecase for that if you want to build a sidechain embedded into Cardano: one of the problems we had with that concept is you can't do a rollback because the UTXO is not spent and so we had an idea of building a virtual chain with data inputs and then people can come in and unvirtualize the team after a timeout period to turn it into a real chain if that makes sense.  \n**MPJ** - Sounds quite complicated. For simpler cases, it also lets you prove that you own something. Suppose you have a token and don't need to actually spend it. For example an authorization token, which would let you authenticate, without spending, a minor efficiency saving. A bit like reference inputs in some ways, which lets you avoid churning lots of utxos but appart from that doesn't add that much utility.   \n**S** - It would be useful for the virtual subchain embedded into Cardano because you would then be able to move the subchain states by proving you have the ability to do that but with a rollback it still exists, so you could build a fork.. I'll have to think about wether or not this is actually something worth thinking into.   \n**MPJ** - yeah.   \n**S** - In general for these kinds of \"Plutus-related CIPs\", do we want to tie these CIPs to changes in the Plutus core specifications, do we want to merge these CIPs and make the spec changes later? I felt for the ledger changes we were somewhat embbedding it into the CIP process.   \n**MPJ** - I was mostly viewing this as a pre-specification document because then there wouldn't be a spec. I don't know. We could broacast a process for that. If you want anyone outside of IOG to make proposed changes to the ledger that's a very high bar, and then it would be reasonable to say you do the full specification set later. In essence since the changes to Plutus are really only in the interface to the ledger, the changes would appear in the ledger specs rather than in the Plutus specifcations. I am considering making a CIP that is a bit like the protocol parameters CIPs that contains the conditions for changes to Plutus and maybe a list of (for ex) a list of all the builtins that are in the current version or so on, to provide a clearer way for those changes to be made... future work.  \n**S** - That would be great. And for the Reference script PR (158), haven't had time to read that one unfortunately.   \n**S** - We should be able to make a decision on the only design points needed for this one (reference spec? PR158?). The problem we have right now is that we are trying to bridge between networks: i.e. Cardano and other chains. And when building bridges you need to build testnet version of the bridges  and so need to have some kind of protocol magic to be able to distinguish to which network this is bridging to and we have no standard to represent these protocol magic, so a standard way to represent these would be good to have so it can be embedded in packages and libraries and everything else. Some of the bridging software libraries on the ethereum all seem to reimplement KEIP2 that is linked in the PR and their standard prefixes the improvement proposal for your specific change as a way to do namespacing. In order to have the namespace for Cardano, we need to have an improvement proposal for Cardano that describes the format.  \n**MPJ** - I guess the comment here is: would it be useful to have one CIP for the format and talk about a registry separately? as that would be a semi-centralized registry for this thing. The main thing even just to get started would be to describe that this is the format and how it could start  \n**S** - We had the same discussion for other registries: a few exist in the CIP repo, there's the network registry, there's the chainID registry... I think there's another one and we've not been consistent for the chain registry we use json, for the other ones we embedded into the same CIP...  \n**MPJ** - I guess it's up to you, the format part is likely less controversial.   \n**S** - I'm ok with either options. I think for SLIPs they are all embedded into the CIP as well. I suppose the separate CIPs. Wether we want to cater to colon separators or something else. It's the minor trivial point but something we get to decide and be happy with. If anyone has strong preference in any direction, please make your voice heard. I am leaning toward not using BECH32 and just using a dash (as mentionned in the CIP in its current form). BECH32 feels good, but the checksum is a mistake in my opinion. The other point someone might disagree on would be the inclusion of the Genesis hash, as it was reset some two years ago and might not even matter if it ever happens again.   \n**F** - Send that to next meeting - will add CIP number - 34 should be fine.   \n\n\n\n### Close    \n\n=> Minor Merges (such as [PR156](https://github.com/cardano-foundation/CIPs/pull/156), [PR166](https://github.com/cardano-foundation/CIPs/pull/166) )  \n=> Extending conversation on [PR140 - tentative CIP 28: \"Protocol Parameters (Alonzo)\"](https://github.com/cardano-foundation/CIPs/pull/140)  \n=> Extending conversation on [PR137 - tentative CIP 31: \"On-Chain Token Metadata Standard\"](https://github.com/cardano-foundation/CIPs/pull/137) to explore security concerns   \n\n   \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active |\n| 3 | [Wallet key generation](../CIP-0003/) | Active |\n| 4 | [Wallet Checksums](../CIP-0004/) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed |\n| 8 | [Message Signing](../CIP-0008/) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/) | Active |\n| 20 | [Transaction message/comment metadata](../CIP-0020/) | Active |\n| 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft |\n| 22 | [Pool operator verification](../CIP-0022/) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/) | Draft |\n| 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft |\n| 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft |\n| 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft |\n| 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2021-12-21.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [December 21 2021 notes](#december-21-2021-notes)\n  * [Triage](#triage)\n    + [007 forum post on licensing and IP](#licensing)\n    + [PR140 - tentative CIP 28: \"Protocol Parameters (Alonzo)\"](#alonzo)\n  * [Last Check](#last-check)\n  * [Review](#review)\n    + [PR148 - Update to CIP 30 (signData API)](#cip30)\n    + [PR159 - tentative CIP 31: \"Reference Inputs\"](#159)    \n    + [PR160 - tentative CIP 32: \"Inline Datums\"](#160)   \n    + [PR161 - tentative CIP 33: \"Reference scripts\"](#161)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 12/21/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## December 21 2021 notes \n\n**Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, Frederic Johnson, ~Robert Phair~. \n\n\n### Triage  \n\n#### Licensing\n**Frederic** - This [forum post](https://forum.cardano.org/t/cip-007-for-intellectual-property-licensing-legal-documents-inside-nft-metadata/86116) was brought up last meeting as a topic surrounding IP licensing and ppossible approaches, such as tweaking CIP 25 (NFT Metadata Standard) or adding fields - There have been other conversations, this is a reminder to engage preferably on the Forum for now (as there are no PR threads yet). I recall some were concerned on possible vulnerabilities.  \n**Matthias** - I think the idea makes sense generally. But if we are putting documents (or links towards documents) on-chain, then we should also remind people to add that document's hash on-chain next to it - this wouldn't allow updating the license afterwards (unless we think it through various schemes..) but for the purpose here might be sufficient.  \n**F** - Reminder, this is Forum/post level, no PR out yet => weigh-in over there for interest or to support.  \n\n=> no action needed  \n\n#### Alonzo\n[PR140 - tentative CIP 28: \"Protocol Parameters (Alonzo)\"](https://github.com/cardano-foundation/CIPs/pull/140)  \n**F** - This is the Alonzo protocol parameters from IOG/Kevin, an upgrade continuing on [CIP 9](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009) (Shelley Protocol Parameters). Last meeting conversation centered around wether this should be merged or not. The PR has the appropriate number of approvals, but the discussion/holdout was about the parameters themselves having changed since initial Alonzo deploy (ex: increase in BlockSize). Question was should it be merge as-is or changed? My understanding is that this CIP is intent as the \"initial\" snapshot, and that updates should be pushed as separate CIPs/PRs..  \n**M** - A few things here, notably echo'd by Mark in the PR, asking if that CIP should be a Standard instead of Informational. The thing is this CIP is currently Informational in the sense that it gives a description of what was chosen for the genesis of Alonzo. If it had come ahead of Alonzo and been discussed, then it should probably have been a Standards track. And this goes with how we want to move the process for parameters, which effectively means defining how things go from discussion to implementation. Which is started with the new Plutus Core changes. For this one, as it is just describing the upgradeable parameters in the Genesis, I don't think we should actually mention the Block parameter update/change. If we do, it could be at a later stage, with maybe a section of all the updates, noting what/when.  \n**F** - It describes \"changes that have occured since CIP 9 (Shelley)\" but remains vague  \n**M** - Similarly, we updated the parameters for Shelley 'post CIP-0009 publication' and I don't believe we updated that one either. Perhaps we could clarify the message in both CIPs to make it clear values provided might not necessarily reflect the values for the protocol (for both CIPs) i.e. not sure we want to keep track of all the updates in the CIPs themselves - it would be cumbersome to manage over time, rather we have ways to query the parameters and that should be sufficient I imagine. To me the added value of these two CIPs are about providing descriptions and semantics for the parameters themselves: the values (from the CIPs) might be interesting (to get a general idea of magnitude) but should anyway not be used directly in any application. If you write an APP relying on protocol parameters you should properly query them directly from the network, so the CIP here is really 'Informational' in that sense.  \n**Sebastien** - It's not like we should change anything now - it's really the order we pick things for now, so we migth as well stay with informational and maybe in the future switch the order up to properly reflect network params.  \n**F** - This has been a 'Last Check' for 3 or 4 meetings, are we fine merging as-is?  \n**S** - Fine with it.   \n**M** - Same, we can always setup a PR after that to adjust the wording a bit.  \n\n=> Merging NOW [PR140](https://github.com/cardano-foundation/CIPs/pull/140) as CIP-0028  \n\n### Last Check   \n\nN/A\n\n### Review  \n\n#### CIP30\n[PR148 - Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148)   \n**F** - The PR is a continuation of the conversation regarding adding the signData API to [CIP-0030](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030). There were some conversations ongoing in this specific PR  \n**S** - The conversation is still active  \n**M** - I think the discussion is mainly regarding the format we want to use for the interface: the approach + the functions everyone is mostly ok with such as the intent, using COSE as a signing envelope. The question so far were more along the line of \"what sort of format do we take for address, payload, response?\"  \n**F** - Can you expand on what COSE is?  \n**M** - There are two distinct things in CIP-0030 really. For signing you have one thing, which is what wallets do. It was specified in the past and is clear. This PR is more about signing arbitrary payload (not necessarily a TX) it could be about proving your identity with your wallet: some server or app might send you a challenge and if you can prove that you own the private key by signing the challenge in a way that doesn't expose your keys or make your app vulnerable. For example you wouldn't want to accept any random string so you don't accidentally sign an adversarial Tx. So we need a protocol to define how it should be modeled and so we can have a result that is portable, and contains all the information that is needed for the application to verify how it was done, with what key etc.. This PR here is just about the signData endpoint which was left as a Work in Progress when we merged the [CIP-0030]((https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030)) before.   \n**S** - (looking at the PR comments) I think this discussion is still too early to talk about merging here, a lot still in the air.  \n  \n=> On Hold / Tabled (depends on activity, check-in next meeting) [PR148](https://github.com/cardano-foundation/CIPs/pull/148)   \n\n\n\n#### 159\n[PR159 / potential CIP 31: \"Reference Inputs\"](https://github.com/cardano-foundation/CIPs/pull/159)   \n**S** - For reference inputs, one of the problems we have is that it's really open how far we want to go on this, and we need inputs from companies and people that might want to actually use this, to get their feedback on how far we should go (re: inputs). There are a huge spectrum in this CIP here and scope for inputs. So I am not sure how far that is coming along. On my side I still need to spend more time thinking about different usecases we might want to make sure we consider, what level of functionality. We should get this out in front of people as quickly as possible so they can push out their opinions in the public space/PR.   \n**F** - Conversation is ongoing and still seems to be going on from where it was two weeks ago. MPJ was with us last Editors meeting ([35](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-12-07.md)) and we touched to it then. This is another one that will likely get carried into the following meeting with the accompanying (potential CIPs) [PR160](https://github.com/cardano-foundation/CIPs/pull/160) & [PR161](https://github.com/cardano-foundation/CIPs/pull/161).  \n**M** - I haven't followed the conversation close enough here - I am familiar with the ideas but not the conversations. Let's move it further out.  \n\n=> On Hold / Tabled (depends on activity, check-in next meeting)  \n\n#### 160\n[PR160 / potential CIP 32: \"Inline Datums\"](https://github.com/cardano-foundation/CIPs/pull/160)  \n**M** - (Knowing that this CIP really only make sense on top of the previous one) it is \"a\" way to embed some actual information in the UTXO. At the moment one can't really encode into the hash, because the hash, requires some data that will reduce to that hash. With the idea of reference inputs, you can now think of those Datums as  way to embed some level of information. Specially, the datums that you would want to put in that place are much smaller than an actual hash, and so more practical. An example usecase would be oracles: publishing some data onchain, so that it can be refered to by other scripts to leverage the oracle (whatever it might provide, such as price conversion, source of randomness... etc)   \n**F** - Wondering, why aren't those \"bundled\" CIPs not one major CIP?  \n**M** - That's something that was discussed with MPJ when they first wrote all those CIPs, but since they were quite isolated pieces of change in the end, we thought it made more sense to divide them into 3 different CIPs. The first two are definately related, and 32 requires 31. But CIP 33 is a a CIP on its own: it could exist without the other two, but it's part of the same batch because they are all related, the approaches are similar for 33 and 31 for example.   \n\n=> On Hold / Tabled (depends on activity, check-in next meeting)  \n\n#### 161\n[PR 161 / potential CIP 33: \"Reference scripts\"](https://github.com/cardano-foundation/CIPs/pull/161)  \n**M** - This PR as (potential) CIP 33 is really to have a way to \"import\" some code, other validators in your validator: it's a way to reference existing scripts off the blockchain within your script, and that allows you to reduce drastically the size of a transaction because you no longer need to repeat a script every time you want to use it (currently done by embedding it in all TXs it is used). With this proposal, you would put in a reference to a script, so instead of having the full code, you'd have the hash plus some identifier (ex: TxID or other): A pointer to a script basically. This would be one of the most important addition to Plutus and the greater framework for Cardano in my opinion and would be something to pursue.   \n**F** - The direct reference to CIP 31 and 32 is the relying on the reference inputs and the datum for script reference?  \n**M** - No, it's rather a construct on top of that: it's sort of the opposite way of going about it. Similar but opposed to CIP 31 approach: CIP 31 gives you a way to reference inputs, this one here gives you a way to reference outputs (similar train of thoughts)  \n**F** - Still ongoing conversation, please refer to the PR threads to participate. As it kinda functions as a bundle with 31 & 32, will roll this into the following meetings.   \n\n=> On Hold / Tabled (depends on activity, check-in next meeting)  \n\n### Discussions  \n\n#### Network Registry\n**S** - [PR158 - tentative CIP 34: \"Network Registry\"](https://github.com/cardano-foundation/CIPs/pull/158) has been open for a month or so and nobody had any objections to the format as it stands it seems. This here describes a standardized way of representing a network in Cardano, such as when saying \"My product supports the testnet\" => Which testnet? There are multiple.. Currently people refer to them by name or some ad-hoc way of representing it, such as chainID, networkID or a human-readable format, and what we really need is some format that simplifies/lists all the network in Cardano and how specific networks might align with this format. Something that lets you understand the format. Other chains have that kind of registry for their testnets and such, Cardano hadn't needed it due to mostly using only two networks, but over time we are expecting different kinds of networks evolving, so we want to establish some standardized way of referring to Network. Here one of them is a longform json, which includes information, and the other one is kind of a key, so you can use it as a lookup in a registry. This CIP here defines both of those standards, which makes it come with a registry.json, to store future information, and the different networks of Cardano (right now with the two main ones). It also defines a standard for shortform notation, which is CIP34:networkID-networkmagic and this format follows the chain-agnostic improvement proposal that other chains are also following (everyone has essentially aligned to that format).  \n**M** - Makes sense.  \n**S** - There was one alternative where we could have used bech32, but it wouldn't make it readable: no real benefit to it, so I just kept things simple. I also created a json implementation of this CIP as well (that you can find in the CIP itself in the reference implementation section). If no particular objections, I would like to move this to 'Last Check'.  \n**F** - Fine here: a reserve I have is the over-reliance on the CIP repo with all the varied registries being setup.  \n**S** - We probably shouldn't have these registries in the CIP repo, but the other options were awkward (ex: dcSpark maintaining a registry..) This is an endless problem really: nobody wants to be legally responsible for registries (due to exposure and risks)  \n\n=> Moving [PR158](https://github.com/cardano-foundation/CIPs/pull/158) to 'Last Check' for next meeting  \n\n\n#### Statuses\n**F** - Last discussed was [CIP-0012](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012), as 'Draft'. Reminder: it is up to the implementer to champion the drive to advance a CIP status.  \n**F** - [CIP-0013: \"Cardano URI Scheme\"](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013) is currently as 'Draft' -> should it be advanced?   \n**M** - This has been fairly used in a few applications online and if I recall correctly even Yoroi supports it.  \n**S** - Yes.  \n**F** - Sebastien (as co-author for this one) are you fine moving this to 'Active'?  \n**S** - The reason we are waiting on this is that the Daedalus team was about to make changes, and it hasn't happened yet.  \n**M** - It's incoming - but I have no idea when.. There is an internal document, I don't know when the team is planning on making it public but it doesn't really change the core of the CIP, more like adding new constructors for covering DApp-related ULR sharing... A way to leverage the PAB as a URL, or as a partial transaction as URL so that it can be signed in an arbitrary wallet. You could also imagine using that in all the other wallets - for interacting with the PAB. But the other wallets have to be integrated with [CIP-0030](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030) .. but that's irrelevant - I might ping Nicolas again.  \n**F** - Fine to leave as 'Draft' for now  \n\n\n### Close    \n\n=> **Merged** as CIP-0028 (Draft) - [PR140 - CIP 28: \"Protocol Parameters (Alonzo)\"](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0028)  \n=> Hold on [PR148 - Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148) as still active conversation  \n=> Continuing discussions for [PR159](https://github.com/cardano-foundation/CIPs/pull/159), [PR160](https://github.com/cardano-foundation/CIPs/pull/160) and [PR161](https://github.com/cardano-foundation/CIPs/pull/161) (\"Reference Inputs\", \"Inline Datums\" and \"Reference Scripts\")   \n=> Moving [PR158 / tentative CIP 34: \"Network Registry\"](https://github.com/cardano-foundation/CIPs/pull/158) to 'Last Check'  \n\n   \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active |\n| 3 | [Wallet key generation](../CIP-0003/) | Active |\n| 4 | [Wallet Checksums](../CIP-0004/) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed |\n| 8 | [Message Signing](../CIP-0008/) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/) | Active |\n| 20 | [Transaction message/comment metadata](../CIP-0020/) | Active |\n| 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft |\n| 22 | [Pool operator verification](../CIP-0022/) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/) | Draft |\n| 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft |\n| 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft |\n| 28 | [Protocol Parameters (Alonzo)](../CIP-0028/) | Draft |\n| 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft |\n| 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2022-01-11.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [January 11 2022 notes](#january-11-2022-notes)\n  * [Triage](#triage)\n    + [PR186 - link rework for cips.cardano.org](#autogensite)\n    + [PR148 - Update to CIP 30 (signData API)](#cip30)\n  * [Last Check](#last-check)\n    + [PR158 - tentative CIP 34: \"Network Registry\"](#network-registry)  \n  * [Review](#review)\n    + [PR159 - tentative CIP 31: \"Reference Inputs\"](#159)    \n    + [PR160 - tentative CIP 32: \"Inline Datums\"](#160)   \n    + [PR161 - tentative CIP 33: \"Reference Scripts\"](#161)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 01/11/22 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## January 11 2022 notes \n\n**Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, Frederic Johnson, ~Robert Phair~. + guests\n\n\n### Triage  \n\n#### AutoGenSite\n[PR186 - Tweaks for autogen site](https://github.com/cardano-foundation/CIPs/pull/186)  \n**Frederic** - There isn't much to do in there and there is enough approvals already, we should be good to merge pending objections  \n  \n=> **Merge** NOW   \n\n#### CIP30 \n[PR148 - Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148)  \n**F** - This is ongoing (and has been discussed the prior meetings): has there been any major updates since the last time it was discussed.  \n**Matthias** - Not for a few days. We are waiting for Rob to update, likely due to the Christmas lull - Hopefully Rob or Alessandro can follow up: the last point in the discusion was really about the format of the address in this interface, bech32 vs base16 and I see Alessandro commented in favor of bech32 but then we also would need to update the previous CIPs for consistency.. I will comment on that and try to restart/move the discussion forward.  \n**F** - CIP 30 was looking at interactions between dApps and the Chain.. (And this PR here is just the addition of the signData API). (Asking community:) If you agree on one path versus another, add your feedback so the PR author can adjust the proposal (still, can be as new CIPs if others prefer different ways)   \n  \n=> On Hold for now  \n\n### Last Check   \n\n#### Network Registry\n\n**F** - [PR158](https://github.com/cardano-foundation/CIPs/pull/158) - Tentative CIP 34: \"Network Registry\"  \n**Sebastien** - This here is because Cardano only has up to 16 values for the networkID which is not enough to represents all possible (Cardano) testnets/ChainIDs of the future (for example, Ethereum has hundreds of testnets/chainIDs). So we need to expand the number of networkID that Cardano supports. We already have a mechanisms that supports it: the protocol magic. Combining both of those into a single value/object that libraries could pass as an object around would benefit everyone (as a machine format item).   \n**F** - Any reasons to delay or open this conversation or could this be merged? (Requiring green ticks..)  \n**M** - Approved. Note that this is the second or third \"registry-like\" CIP that we setup in this repository. It might be worth highlighting some aspects of Governance in the (registry-like) CIP itself so users know how/when/why things get merged or added to that specific registry. Other questions are around the role of Editors in regard to said \"registry-like\" CIPs... For this one it is rather unambiguous, but it is not as clear-cut for future ones: What if you are planning to build a network, and you aren't there yet... More of a greater consideration: Who decides what goes into (a) registry?   \n**S** - Good point, but this is likely a higher level discussions regarding the Registries and the CIP repository itself. I wouldn't block this PR itself about it, but it could be a discussion to have 'soon', maybe modifying CIP 1 in some way to highlight how we'd want to handle registries directly.  \n**M** - Either that or explicitly mention it in the CIP itself, it could define and decide how items could be merged or not merged and what the conditions should be - But it has to come from the author of the CIP him/herself, because otherwise we're making our own arguments. It would be better if it is explicitly stated in those CIPs. For future ones, Conditions for inclusion should be explicitly stated in the CIP.  \n  \n=> Merge NOW [PR158](https://github.com/cardano-foundation/CIPs/pull/158) as CIP 34  \n\n### Review  \n\n#### 159\n[PR159 / potential CIP 31: \"Reference Inputs\"](https://github.com/cardano-foundation/CIPs/pull/159)    \n**M** - \"Reference Inputs\" are an extension of the Ledger so we can actually put inputs in a transaction that do not get consumed at the end, and are solely available in the context of scripts. This is useful in multiple scenarios, especially in conjunction with the other two associated PRs (160 & 161) because it can pave the way for 'importing scripts' or additional data without making it unavailable for other scripts: It can make concurrency a bit easier that way because we can share data on the chain and we can turn UTXO as a data source and not just a transfer of value. This here gives all the details on how to do that, what the changes would look like, how a transaction would be modified, what the rationale behind that change is. As I said, I haven't plugged into the discussion and what aspects were focused on lately. I saw MPJ did a poll at the end about one of the features/aspects.. (if we could remove that or not) and people have been weighing in.   \n**F** -  Feedback seems to be that \"Reference inputs without control is useful but also would be good to have control\".  \n**M** - \"I don't need it, but I want it\" - The question that will follow from that result would be \"Can this be done in two steps?\" i.e. \"Not having control referencing\" is easier, can it be introduced afterwards? In a way that could be a separate CIP, or an extension of that one..  \n**M** - \"Controlled referencing\" is explained in a later paragraph in that CIP about it (MPJ explains it better). For example an Oracle might want to only allow a transaction to refer to a particular output if some other contract gets paid.. As explained, you make some data available, you might not want to do it for free: you still want to enable some cost, because it cost you something to make that data available. I suspect any Oracle is strongly in favor of that here. Maybe Andre (Knispel) could chip in? If it's feasible as a two step, or other Q.  \n**Maksymilian** - WRT to Oracles being \"dead in the water\" it is partially true because controlled referencing essentially allows Oracles to work in a similar way that ChainLink does, where you pay for the use of the Oracle and the data is assumed to be correct and up-to-date. Without Controlled referencing (but with Reference inputs) it is possible to have a business model, but then people would be paying to \"refresh\" the Oracle instead of using it, which I suspect would be cutting into the profits significantly, unless you do some manipulating around - but who knows. In my opinion, this is the most important CIP in context of architectural aspects.  \n**Matthias** - I prefer CIP 33.  \n**Andre** - It is possible to have controlled referencing even with only this proposal, where if you control the script that would use the reference, then you can add a built-in mechanism that would at least control fit us right. Of course anyone can reference an input, but let's say I run some kind of service and I provide the script for interacting with this service, and I also provide the Oracle. Then - in my script - I can require some kind of token that proves that I have access to this input. For some usecases, we don't even need this controlled referencing, to have this kind of usecase supported.   \n**M** - Is it relatively easier/feasible to have that done in two steps? I can definately see a usecase of CIP 31 \"without controlled referencing\", and that being introduced at a later stage.  \n**A** - The problem with Controlled Referencing is that there are still many questions, notably around what it even means: If I want some kind of control over the referencing, how would I even get it? What would I do? Where would I put the conditions to referencing? We could maybe add a new kind of address, not a spending address but a reference address or something like that, and check if we can reference from that address in the UTXO. Maybe we could do something like that, but then this would be a pretty big change to how we do the things normally. In principle, it's feasible but it's not clear how we would do it and how exactly it should be possible to control the referencing. There is no reason why this couldn't be done in two steps, this CIP isn't super restrictive for future propositions.  \n**S** - One thing to consider is timeline: We have the Babbage Hardfork coming up, but right now I am not sure if it would include reference scripts to an extend. If simplifying this could help include this in Babbage (rather than further out in June), I would be in favor of including this so.   \n**A** - The plan is to include all of it in Babbage and we are pretty much on track. Of course if someone really really wants controlled referenced inputs then I don't know if that can actually be done.   \n**Maksymilian** - I want to say that even if Oracles, like Charli3, want controlled reference inputs, even without control it is still worth it, because the oracles can maintain it themselves, even if it is a static piece of data changed every epoch or something, without neding payment for that because they themselves maintain it..  \n**F** - CIP 31 is part of the conversation with 32 and 33, should this be rolled into the follow-on meeting as a review item?   \n**Benjamin Hart** - If this were to be accepted with the Controlled References, is it necessarily required that a single release implement the entire proposal? or could it be implemented in phases?   \n**M** - That's what we are discussing: Merging the whole proposal doesn't mean it has to be implemented in one block, especially because in the proposal it is actually already divided in multiple parts. I think it might be better to split it in two proposals - CIP 31a & 31b maybe?  So that you can release it and say we have implemented that and not that yet. For a few proposals this already happened, and we've seen that phased rollout, with a later add. If you know that this is going to be implemented in mulitple steps then you could already split the proposal more outwardly. Proposal does not imply any kind of target or future implementation really.   \n  \n=> On Hold / tabled (depends on activity, check-in next meeting)    \n\n#### 160\n[PR160 / potential CIP 32: \"Inline Datums\"](https://github.com/cardano-foundation/CIPs/pull/160)    \n**M** - This one is probably the least controversial of the grouping, and is about the ability to embed directly a datum (that isn't a hash) in the UTXOut. This can be useful with CIP 31 because you can then use the datum part to embed information in a UTXO that you can then cross-reference in a different script, which can then be used in some other flow. The hash is currently 32 bytes long, so it gives you 32 bytes of space available, it wouldn't make the UTXO bigger with that, and the proposal is limiting to that size at this stage, so the idea is not to enable arbitrary size for the datum but rather set it as 32 bytes, so what if you were to put only 2 bytes in there, not hash it, and make it available? You can already do that with padding in some sort - putting 0s in front of that, but the side effect is that you cannot spend that datum afterwards because it would mean you'd have to reveal (..) guess the preimage of that hash. \nIt's useful, but the least discussed of the 3 proposals because it is not controversial and also relatively straightforward to implement compared to the other ones. Without CIP 31, CIP 32 is a lot less useable, or the usecase is less on the table.   \n**S** - For \"Inline Datums\" I don't mind if it's merged as-is. There is some discussion on the CIP, but none of the proposals require actual change of the file, there is just a small TODO that could be removed, but nothing stops us from merging this PR.   \n**M** - I think it is pretty clear, moving to 'Last Check' is definately fine.   \n  \n=> Moved to 'Last Check' \n\n#### 161\n[PR 161 / potential CIP 33: \"Reference scripts\"](https://github.com/cardano-foundation/CIPs/pull/161)    \n**M** -  I am surprised this one is not more discussed compared to CIP 31. To me, this is **THE** CIP that will make it possible to scale the Plutus Ecosystem in a way. It makes it possible to have a sort of 'module' or 'mechanism' OnChain, as you can import a script, and reference a script from your script.. that reduces the size of your transaction as well, and you can start splitting your scripts or validators into multiple smaller ones, and have more mobility in a way. It makes Plutus more extensible without having to go through hardforks to modify the built-ins and without having to embed your entire codebase in every validator. From a useability or developer experience perspective: this is VERY useful. From a pure capability perspective, it's true that it doesn't give any new capability to the chain (except maybe run bigger scripts than before) and that might be why it's hardly discussed. It's part of the things that will not revolutionize things, but it will make the dev experience much much better.   \n**Andre** - This does (not?) let the scripts reference other scripts directly, it only lets transactions mention scripts that don't have to be included in the Tx but are mentionned in the UTXO via the reference.   \n**M** - And then your validator can insure this particular script gets executed...   \n**Andre** - By doing some extra work it is possible you make these scripts do something.. But it's not like I put some scripts on the chain and then simply call functions..  \n**M** - Right, It's not Automagic, yet it makes it easier.   \n**F** - Do we need the other ones before moving this one to 'Last Check'?  \n**M** - It's independant, and could have been implemented by reference inputs, but the proposal is not doing that, it is introducing a new component to every transaction output, it's fairly independant. We can move it to 'Last Check'.  \n**Andre** - It's technically independant, but to be useful it needs some kind of referencing mechanism.  \n**S** - I think this is fine for 'Last Check'  \n**Las Safin** - I can tell you about 33 but I have already outlined my thoughts in the chat - this seem to be dependant on 31, but is not quite obvious, in the text it mentions refences inputs. You could implement it without, but it might not make sense: you would have an output and you would consume it. And you could use that script to consume another output that uses that script: It would be very weird, but you could make it independant, although it kinda is dependant.   \n**M** - Eventually we understand you'd use it in conjunction with CIP 31. It doesn't really give you anything in there. You could say that this gets implemented first, then CIP 31 gets implemented later. And that's all this is, we can implement without, despite its use really meant to be used in conjunction with the others.   \n**L** - You want the 3 of them to get the whole power. Can we merge 32 and 33 before 31? Both have no discussion ongoing it seems.   \n**M** - reminder: \"Merging something in the Repo\" has no implication for implemetation or roadmap or endorsement by implementers! Therefore how these things are implemented, is out of scope of the CIP program. The CIPs are more like a collection of solutions to some problems, they aren't authoritative. We merge proposals that seem fine - If changes need to happen, that can still happen when in 'Draft'.  \n**L** - So how do we reach consensus, for example to implement CIP 32 (as a non-controversial CIP)?  \n**M** - Right now that is up to the Core team. Having a CIP here makes it clear that \"This is a Proposed change\" and people have time to voice their concerns or support of, then the core team can proceed accordingly (Likely going along the CIP as proposed). As of now the proposal looks legit/feasible. From here should be moved to 'Last Check'..   \n**M** - If you take a CIP that refers to 'Wallets' for example, users can externally align on varied standards as they desire. For the nodes, right now there is only one implementer (IOG), but there might be other implementers down the line, for example if all parts of the nodes are captured by a set CIPs, then someone wanting to implement a node might look at that collection of CIPs. This  is how a new addition to the node, is planned, and IOG wants to open it up and align with the community and have people open on it, such as the feedback on CIP 31, which also allows the team to adjust the scope and the implementation, ahead of the implementation (rather than post-fact). Now we are having the discussion upfront, which is better.   \n**L** - I also want to touch to 33 and it seems there isn't anything to discuss there either: basically things are settling.  \n**S** - re:CIP 33, (just to make sure I get the usecase for combining with reference inputs) If you wanted to combined a shared module, you would create a UTXO entry that is possibly unspendable output, that contains the scripts for your output and then you get people to reference it and that's the main usecase right?  \n**M** - Yes  \n**S** - Fine to merge then, I have approved it and we can move it to 'Last Check'  \n  \n=> Moved to 'Last Check'   \n\n### Discussions  \n\n\n#### Royalties\nre: [CIP 27 / on NFT royalty](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0027/README.md)   \n**Maksymilian** - This proposal is just a consensus and yes, if a participant is not a malicious actor then it works.  \n**Matthias** - This might be a misunderstanding of the CIP process itself: Someone made a proposal that was merged and it leaves the room open for someone else to come and make a proposal that supplants or deprecates CIP-0027. For my mind if there is a clear disagreement between what this CIP would do? There is room for a different CIP that explains the roles and explains the two different perspectives?   \n**Maksymilian** - That is a good idea. Essentially we / I are creating an NFT platform that wants to ensure that Royalties are \"every single time followed.\" I have designed it, and it is compatible with CIP-0027, it just adds a single field..    \n**M** - As an editor, I would suggest you push it with the rationale as another proposal, then it would be fine to merge as well (as a separate CIP)  \n**Maksymilian** - I don't fully agree that this solves it - malicious users might still avoid the royalties, and if we as a community come together (if not the solution that I am proposing) then I'd love that. I should make this as a CIP.  \n**M** - Encouraged: highlight the flows and then push a proposal. You might also obsolete or get in touch with the Author of CIP-0027 to figure if worth or desired to add in the changes (rather than have a competing CIP). Over time, it's up to implementers, and the market can decide.   \n\n\n#### PR188\n[PR188 / Update to CIP-0015, re: Multi-Delegation](https://github.com/cardano-foundation/CIPs/pull/188)  \n**S** - Currently you only have a choice of delegating to a single person to vote. This here is adding the ability to spread your delegation to multiple addresses. The idea being that being that you might want to delegate to a set of people.. I think the change is not that big and I feel the way they changed the CDDL may be off - but other than that I believe this is what the Catalyst team is already implementing and presumably the reason it is done like this, is due to it being the same format that Jormungandr (Rust-based chain, which powers Catalyst) supports.    \n**F** - I was pushing back on this one re:naming, feedback from the community would be great. Can we move this to 'Review' for next meeting?  \n**S** - I am not sure of the timeline for this one but I wouldn't mind moving this ahead... I don't think the change is that big.   \n\n=> Moved to 'Review' for next meeting    \n\n\n### Close    \n\n=> **Merged** as CIP-0034 (Draft) - [PR158 - CIP 34: \"Chain ID Registry\"](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0034)    \n=> Hold on [PR148 - Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148)   \n=> Hold on [PR159 - tentative CIP 31: \"Reference Inputs\"](https://github.com/cardano-foundation/CIPs/pull/159) as conversation continues  \n=> To 'Last Check': [PR160 - tentative CIP 32: \"Inline Datums\"](https://github.com/cardano-foundation/CIPs/pull/160)   \n=> To 'Last Check': [PR161 - tentatice CIP 33: \"Reference Scripts\"](https://github.com/cardano-foundation/CIPs/pull/161)  \n\n\n   \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active |\n| 3 | [Wallet key generation](../CIP-0003/) | Active |\n| 4 | [Wallet Checksums](../CIP-0004/) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed |\n| 8 | [Message Signing](../CIP-0008/) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/) | Active |\n| 20 | [Transaction message/comment metadata](../CIP-0020/) | Active |\n| 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft |\n| 22 | [Pool operator verification](../CIP-0022/) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/) | Draft |\n| 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft |\n| 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft |\n| 28 | [Protocol Parameters (Alonzo)](../CIP-0028/) | Draft |\n| 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft |\n| 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft |\n| 34 | [Chain ID Registry](../CIP-0034/) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2022-01-25.md",
    "content": " **Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [January 25 2022 notes](#january-25-2022-notes)\n  * [Triage](#triage)\n    + [PR148 - Update to CIP 30 (signData API)](#cip30)\n    + [PR159 - tentative CIP 31: \"Reference Inputs\"](#pr159)\n  * [Last Check](#last-check)\n    + [PR160 - tentative CIP 32: \"Inline Datums\"](#pr160)  \n    + [PR161 - tentative CIP 33: \"Reference Scripts\"](#pr161) \n  * [Review](#review)    \n    + [PR188 - Update to CIP-0015, Multi-Delegation](#Multi-Delegation) \n    + [PR183 - Update to CIP30 - Experimental tag](#experimental)\n  * [Discussions](#discussions)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 01/25/22 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## January 25 2022 notes \n\n**Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, Frederic Johnson, ~Robert Phair~. + guests (MPJ, Mark Stopka)\n\n\n### Triage  \n \n**Matthias** - (On Process) Michael Peyton-Jones (MPJ) is saying CIP 32 requires attention, but it's already on the agenda. Mark is also suggesting we discuss “delegated voting” instead of particular PR with that. And also the onboarding of new editors… (answering to MPJ chat ask) “Proposed” if there is a ‘past to active’, which is clearly outlined. It should be the case in this.  \n**Michael Peyton-Jones** - So, in that case I should put them as ‘Proposed’? Not clear on what is needed, what to do in terms of the process.. The changes we  think we need to CIP 30, 32 are sort of details (how are we going to represent it on the ledger etc… )? My understanding is that you merge things(CIPs) and then add edits to them? I am not really sure what the process is, happy to leave it open…  \n**M** - If you still anticipate few (substantial) updates, probably best to merge it as ‘Draft’ to indicate that it's still being worked on. If rather updates are anticipated to only be simple rewords, merge it as ‘Proposed’.  \n**MPJ** - For 32, Hopefully we can address the comments that came out just straight out. The other two, I think are fine. I'll do a last pass today.  \n**M** In principle once it is ‘Proposed’ you do not really anticipate changes to it, the final design before ‘Active’.Why you are implementing it, you discover new things and then from propose to active there are still changes.  \n**MPJ** - That is basically what's happening. So it's just a question of how we want to represent the current state.  \n\n#### CIP30 \n[PR148 - Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148)  \n**Frederic** - Jumping into the triage items: First one is PR148, the signData() API. Has that conversation continued?   \n**M** - A bit, Yeah, I saw a few updates and Alessandro also commented on the issue… but it's also now in a state where it needs to be updated. Not much more than last weekend. In terms of progresses. So, the discussion made some progress, but not the CIP per se.  \n**F** - Um, Yeah. PR148 adding signData() API to CPI 30, i.e. “how a DApp would connect to the chain”. If you have strong opinions on this, please do weigh-in on PR148 directly.  \n**M** - Yeah. There was also a discovery by Alesandro last week. I think, regarding the codes assigned to one of the signing methods, they were not matching, between the stake and the library. I think he opened a PR.. Not completely related to CIPs but …  \n**Sebastien** - Yes, We are aware and are looking into this, the repo belongs to Emurgo FYI.  \n\n=> [PR148](https://github.com/cardano-foundation/CIPs/pull/148) being looked into and to be followed on for next meeting (should it be moved to 'Last Check')  \n\n#### PR159\n[PR159 - tentative CIP 31 - \"Reference inputs\"](https://github.com/cardano-foundation/CIPs/pull/159)    \n**F** - Do we want to extend this? Is the conversation still going on?  \n**MPJ** - I didn't even spend much in the way of substantial additional conversation. Recently. There's one point of contention: The scope of this could be expanded to include an additional feature (which it doesn't currently include). I made some attempt to check community sentiment on that. I think it is something that people care about, but I don't think it's feasible to do the design work and implementation in the timeframe that we'd like to do this in. So I decided to revisit that in future. I don't think there's actually been any discussion that changed the substance of the proposal in a while: fairly settled now.  \n\n=> [PR159](https://github.com/cardano-foundation/CIPs/pull/159) On hold for now, revisit later\n\n#### peripherals\n**M** - (now that we are over with Triage) some peripheral CIP bookkeeping: There were just minor changes and corrections to the existing CIPs: PR195 is adding another reference implementation for the CIP 3 (the master key generation algorithm) from seed to wallet BitBox02 key format. Which also uses this format that is specific to ledger. if we added it to the CIP which is very much welcomed. So we both approved Sebastien, I guess we can merge that. Small update to CIP 30. It's pretty minor change. Also PR193 re: CIP 25 (on NFT metadata): a precision by the author about the asset naming, coding which has to be UTF-8 which does not make me happy yet is approved, because it reflects what it is. I think we can merge this as well. Additionally, we did discuss another small one two meetings ago requesting a clearer “path to active” section in PRs, so we know what the author has planned in order to move their CIPs ‘Active’. (also relevant to MPJ’s earlier Q).  \n**F** - Again, the CIP’s “Proposed”  state is intent for when the author (or authors) deem the CIP PR complete and there is a community-verifiable explicit (Editor-approved) path to “Active”: This could be a working implementation (where applicable), or a set of observable metrics on the network, but it should be clearly worded out in the CIP as its own section for all to refer to.   \n**M** - PR182 could be merged also, it is fixing links.  \n\n\n### Last Check   \n\n#### PR160\n[PR160 - tentative CIP 32: \"Inline Datums\"](https://github.com/cardano-foundation/CIPs/pull/160)  \n**MPJ** - That is the one we discussed earlier. We need to see a bit more activity: it just needs a bit of attention, but I think that's resolvable. Inline Datum is about allowing you to put datums directly in outputs instead of datum hashes. A lot of things are fairly uncontroversial, the only question at the moment, is about how this is represented in the script. So I think there's fairly good reasons to make this distinction visible to scripts because then scripts can assert inline datums to be used. But then the questions become “How exactly do we do that?” in the representation, which is really a detail, and “What do we do for Plutus V1?”. We could do a sort of “backwards-compatible thing” where we pretend that it is in the witness map (which I'm somewhat partial to) or (what we really shouldn't do) just “Omit the information”. To just silently drop the information would be a bad approach. A realistic option would be to effectively ban transactions which contain inline datums. We just do on-script. This wouldn't be so bad, except we create a new way you might make things unspendable, by creating an output via Plutus V1 script and inline datum, because you wouldn't be able to reference that output to itself.. There are  already a lot of ways to make things unspendable, better not to add more…  \n**M** - This is something the ledger would catch very easily right?  \n**MPJ** - Not really, you can not catch that. When you create an output, you only have a hash, which does not tell you a version, or a language tag: At output-creation we do not know those.. I think Alex summarized most of that pretty clearly in the PR comments. It's not clear what the best resolution is from here.  \n**M** - Would it be out of the question to introduce new address types for that?  \n**MPJ** - If we are going to change the address types, adding an address type that generically included a language tag, would be reasonable. But I don't really know how much work that would be. It's also somewhat orthogonal to this: We could in principle do that separately. I think you're probably more likely to know the answer to how difficult that might be.  \n**M** - It wouldn't be too complicated probably.  \n**MPJ** - Okay. He doesn't think that solves the problem. The ledger  forbids your transaction and transaction creation time. So you wouldn't make a spendable output.  \n**M** - It doesn't completely solve the problem in the sense that you would still have the old addresses available to use. You could migrate to this new addresses and recommend deprecating the old ones into new ones…  \n**MPJ** - I suspect this won't be a problem, but feel bad about introducing a new way to make things unspendable. Not the end of the world, but a better option would be nice.  \n**F** - Ok, that’s setup as a ‘Last Check’ item, tabled for now TBA until the conversation evolves from there. CIP 32 /  PR160 moved off from ‘Last Check’ and back on hold depending on the state of conversation. a Triage item for next meeting, depending on the state of conversation.  \n**M** - Let’s not put PR160 on the agenda until we have an update (from MPJ). The discussion might take time, So we can just put that PR on hold and put it back on the agenda when there is an update.  \n\n=> [PR160](https://github.com/cardano-foundation/CIPs/pull/160) Moved off the agenda (and off from 'Last Check') until we have update from MPJ on the conversation (check in on it in a few meetings)\n\n#### PR161\n\n[PR161 - tentative CIP 33: \"Reference Scripts\"](https://github.com/cardano-foundation/CIPs/pull/161)  \n\n**MPJ** - That's the one we were just talking about. Shouldn’t have substantial changes  \n**M** - Let's merge that one. I suggest moving its status to ‘Proposed’ as soon as we have fleshed out the CDDL (and surfaced the details / path to ‘Active’)  \n**MPJ** - I think for some  of these, we could merge them as ‘Proposed’. Stuff like the CDDL, will ultimately come out of the real implementation. I will defer to the Ledger team on what is the right way to do this CDDL..   \n\n=> Merge NOW ([PR161 as CIP 33: \"Reference Scripts\"](https://github.com/cardano-foundation/CIPs/pull/161)) \n\n### Review  \n\n#### Multi-Delegation \n[PR188 - Update to CIP 15 / Multi-Delegation](https://github.com/cardano-foundation/CIPs/pull/188)  \n**S** - Last time I talked about this was mostly around backwards compatibility. I haven’t had the chance to check their edits for this yet. There is also a question whether if people are actually going to implement this? Because we're modifying an existing CIP -  So we need to know who actually wants to implement this thing. This is something that the Catalyst team is supporting: If nobody wants to support this, it might not be worth changing the CIP. So far, I haven't heard of anybody that wants this change. I  think that the voting purpose it's fine. It is not a backwards-compatible change any wallet needs to take care of. Again, It can be used by random folks.. But a change to allow delegating your vote  would also be something that should be taken care of, but not sure there are any wallets that signaled that they want this. Maybe someone from the community wants this. Nobody from IOHK will submit this proposal. We need to figure out if they really want this feature. This is my main concern. Obviously from the CIP perspective, It's a valid CIP and it can be varied from that. But the fact that is modifying an existing CIP, it makes it slightly different from merging a new CIP.  \n**M** - Perhaps it's really better to be a separate CIP. Because indeed it seems like a fair extension of an existing one. But it modifies it quite substantially, which could fit better as a separate one.. And it would make it clearer for wallets (or clients) who could then implements CIP 15 “and CIP X”  \n**Mark Stopka** - As far as CIP 15 / Multidelegation goes, I think it is a long awaited feature. If it's going to be a separate CIP or the same CIP, I don't care. The community has been calling for the ability to get Cardano whales who are too lazy to download/vote in the app via Catalyst for quite some time. It is critical. And we would like to have it asap. Maybe by Fund eight (about three months from now). I know it’s suboptimal. When thinking about governance and delegation we've been expecting something completely different…  I don't know if there is a plan to use this as a temporary solution, and later implement something more cryptographically sound and less traceable - using some zero snarks, or zero-knowledge proofs or something…  \n**M** - The idea here would be to let people register the set of keys they are delegating their votes to.  \n**Mark** - I have friends that have about 10 million ADA, none of them votes, except for me. So they would be happy to give me their voting power and let me decide, and I buy them yours and I will have much more voting influence to support technical proposals that make sense as opposed to some that don't for example.  \n**S** - From a technical perspective, I have no opposition to the CIP after the modifications. After I read over it, I think it's fine. Still, I think he is probably right. I believe it's better if this is a separate CIP, because it requires explicit support from wallets and backwards compatibility. Make this as a separate CIP and then wallets can choose to support this change.  \n**Mark** - Happy to propose a new CIP. I will setup a CIP to complement this one, add authors, and submit it by the next editor's meeting so we can push it through.  \n**M** - Yeah, that would be better. As for delegation currently, It also changes: there are like two changes in one. Before that there was a single delegation / a single vote. Now it is a list. So in terms of tooling - or for the Catalyst process by itself...  \n**Mark** - Not sure how IO does it, but if I were doing it, I would just scan the chain for all the voting registration certificates. Then make a new genesis for the Jormagandr sidechain that would reflect the respective voting power.  \n**M** - That is exactly what happens. There is a snapshot on a given date that takes all the registrations..   \n**Mark** - So in this case, you would look for the registration certificates that has multiple staking keys and you would pull those together. That would be a temporary solution. As we roll out Voltaire, I think there would be lots of changes to such a CIP overtime  \n**M** - That sounds fair. Given that Jormagandr supports “multi delegation” in the first place. There is also something to be done there.  \n**Mark** - Multidelegation has been thrown around for about a year: Is it something that is actually coming? As a community we sort of develop the work around with enabling wallets so we'll have multiple accounts. People who want to multi delegate currently split their wallet into multiple accounts and allocates each to different pool…  \n**M** - I don't think there is any plan right now to support that “natively” in the protocol. There is a clear willingness to have (delegated) voting supported by more clients on the line: that's exactly the way this has been done. I think there are at least two other CIPs that are also approaching this question..  \n**Mark** - I don't think that there are bad intentions, just limited available resources or  prioritization, with things like script preferences or other more important things.  \n**M** - Also about complexity: there are features that would add so much complexity as to make the feature itself undesired. Here, the consensus has been that the complexity compared to what it gives, is best handled in the wallet rather than the node.  \n**Mark** - In the ledger rules in the repository. The guys started to update the foremost pack. I think they are expecting this CIP to be approved soon so they can roll on to the chain quite soon. There is a difference between LaTex specs, executable specs and actual code in the HASKELL node but I think that they are at least expecting an early merge…  \n**S** - We are getting off topic right now. We're trying to finalize what to do about updating CIP 15.  \n**Mark** - We agreed that I would submit a new CIP, which would be more specific... I will do it today, tomorrow, and we can then merge it. I will copy the CIP 15, removing what doesn't make sense and refocusing on multi delegation. That way wallets can signal support, for  CIP 15 it itself or “15 plus (new one)”. Also I've been hearing from colleagues in American time zones they feel it is difficult for them to participate. So what I was thinking since we have CIP meetings at the every two weeks, what we could do is that we could have one that we'll be better suited for Asia. And one that will be better suited for America. And both of them will be suited for Europe.  \n**F** - Let’s add to the discussion section: We have one more item first though.  \n\n=> Re: [PR188 - Update to CIP 15 / Multi-Delegation](https://github.com/cardano-foundation/CIPs/pull/188) requesting a resubmit **as its own CIP** (rather than modifying existing one) - to review as appropriate \n\n#### Experimental\n[PR183 - Update to CIP30 - Experimental tag](https://github.com/cardano-foundation/CIPs/pull/183)  \n**S** - Right now there are multiple wallets implementing CIP 30: Flint, CCVault, Nami, and others. Now that multiple wallets try to implement this CIP, they are trying to stay aligned on a standard. It makes it hard for DApp authors to know what is supported by “all the wallets” and what is something that's supported by single wallets. At dcSpark, we want to create a website that explicitly lists what can be used for browsers, and which wallets supports what. To effectively do this, we want to be able to mark APIs as “experimental”. That would allow devs to know an API is “experimental”, and devs writing code could focus as needed. We could have a set of stable  functions and then the experimental flavors: this PR basically just explicitly adds this experimental field inside the CIP30 data structure.  \n**M** - The difference between the global and the per-wallet namespaces would be exact ‘X’. For features that are “experimental” but agreed upon globally, they would go under “experimental” but  a feature for a particular wallet would go under the wallet namespace.  \n**S** - The global and the wallet namespaces are for different reasons: for registration purposes. One of the goals of the dApp connector, was to prevent monopolies ala metamask - basically nobody can compete with metamask because metamask overrides everything: There's no way to specify which wallet you want to connect, It is a mess. So we want to make it easy for wallets to list themselves as supporting CIP 30. The Cardano object at the start has no functions in it, only a list of wallets. Then whenever you use a dApp, if you call ‘enable()’ on a specific wallet, then it injects it into the space. These are two valid separate things. The wallet namespace being experimental is just for meta-information about the wallets. And then the global namespace is for actual functions...  \n**M** - This could be the next version or the extensions of CIP 30, for instance, that are still being worked on as CIPs? (S - “yes”)   \n**F** - So, could this be a standalone CIP, or what is the reason for riding this on top of Rob’s CIP 30?  \n**S** - This is fully backwards-compatible and is currently experimental. It's currently supported by CCvault, Nami and Flint.  \n**F** - Should Rob (PR Author) be pushing this? Is he on board with those changes already?  \n**S** - I will ask him. (Rob works for dcSpark)  \n**M** - It sounds good to me. I've approved. Alessandro seems to be positive about it.  \n**F** - Considering PR183 as ‘Last Check’. Rob is working on this, for experimental APIs.  \n\n=> [PR183](https://github.com/cardano-foundation/CIPs/pull/183) moved to 'Last Check' \n\n### Discussions  \n\n#### CIP Editors meeting time\n**F** - Next discussion item is as per Mark: “can we move this meeting so US-based folks can attend more?”  \n**Mark** - We keep seeing bigger and bigger changes coming in: In order to facilitate a global community, as well as enable a bandwidth enabling the amount of changes coming in, and have a proper debate over all of it, I propose that instead of having the (CIP Editor) meeting every two weeks, we have it every week and one be catered more towards Europe and America. And the other one towards Asia and Europe. (Let's set up a mailing list + onboard more editors too..)  \n**M** - The current problem with doing that is that we as editors would have no bandwidth to do it. Scaling the number of editors and people  would definitely make the communication harder. Sometimes synchronizing things takes much longer. Re: mailing list, we already have the notes published after each meeting and the actual recorded meetings. Maybe it's more about advertising the notes more than we do?  \n**Mark** - There is a magazine called ADA pools.io... I'm going to try running a monthly retrospective of the CIP process:  that would help drive community engagement that way. As far as the coordination for the actual CIP editors, I feel Github is too messy unless we make like one issue where we can have a discussion, I think Github supports discussions, right? So we could move it into the discussion part or in a Wiki part, or somewhere where we can have threads, which won't be cluttered with both technical stuff and the process operational stuff.  \n**M** - That's something we mentioned in the past, indeed.  I would really like to give a try to github discussions. I think they are well suited for the CIPs. Especially for discussions that are not necessarily technical, but more like political debates or changing the process, or onboarding new people etc. We discussed that in the past. About onboarding of new people. We have Robert now, but he's also US-based so often halfway to join meetings. Um, but we still haven't defined the formal process for candidating for the editors (currently a majority vote)  \n**Mark** - I see several gaps around the process and I think we should update/review it. The process we currently has just three tracks for the CIPs.  \n**F** - We are very aware that many process areas could be improved.. Can we focus on the timeframe for the meetings (Conversations will get lost a bit otherwise)  \n**M** - Probably why we’d want to have this “GitHub discussion” open. We also have been in the past meetings where we had á list of ideas of things we wanted to change probably in this API. I mean, the process. So one we discussed today was this little thing “path-to-active”. It's still minor thing but something we want to change for others. We don't have enough time in a crowdcast meeting to discuss all, so might be better to have proper discussions written down to discuss and bring them into an actual synchronized conversation.  \n**F** - Every 10 meetings there is an actual retrospective that happens behind the scene. For the sake of making sure that we go through these discussion items as put out in the agenda during regular meetings, it is very condensed. But for the sake of conversation, regarding potential US meetings. It is more a problem of time availability. Matthias and Sebastien have been pulling most of the editorial work. Finding a time that works for Mathias (FR), Sebastien(JP) and myself (TW)  with US is really hard..  \n**Mark** - The question is how big of a quorum do we need to make decisions on CIP meetings? Matthias is in France, so he can cater to US as well. I am in Europe, so I think I can cater to US. And then you have one more person, you mentioned one more who is  the new CIP editor based out in the US. So that makes three people.  \n**M** - I don't mind alternating. We can do two things. The thing I just want to confirm is if we want to double the amount of CIP meetings..  \n**S** - If we want to double the CIP meetings it does not seem reasonable to me at this point of time  \n**M** - And although we do not need to double them. Lets do one meeting in Asia, US and. Europe time zone We can alternate them.. One was a meeting in the US and Europe. And we'd have two meeting amounts. So that means  once a month, um, every, everyone goes at least able to speak in a friendly time zone… Otherwise they got to wake up early or wake up late. I think that's a good step in the right direction maybe.  \n**F** - For the sake of consistency, prefer to have the meetings at the same time. It's difficult to juggle.  \n**M** - In a way that would be “at the same time every month”. Maybe we can run a poll to see, and have proposed times, then take the time that  has the most votes? And if we see there is clearly a pattern of “two times”, adjust new times..    \n**S** - I am not sure a mailing lists adds more value, in terms of enabling email notifications from github and considering we are low on resources for managing CIP stuff. I would rather not add what we can not manage.   \n**Mark** - We can tap into the catalyst resources I believe: they have an entire team dedicated to admin stuffcalled QADAO:we should use them. We pay them, we should use them. They have all sorts of different fancy names for doing different stuff… I can reach out to them and we can ask them to provide us with that for doing meeting minutes for example. They already do meeting minutes for the catalyst circle. Circle. Things that are recorded and so on and so forth, so we should be able to tap into these resources. And they already have some automated AI based tools for transcription.  \n**M** - I would actually do nothing more than publication of weekly notes. If someone wants to build a mailing list on top of the CIPs, or adding things to ADAPools as you suggested, that would bel welcome, but adding this to our  busy schedule is too much.  \n\n#### growing editor panel\n**F** - At this point, we're also looking at adding more people to the editorial board. If you are interested please reach out to either Sebastien, myself or Matthias via email or social media.\n\n\n\n\n### Close    \n\n=> **Merged** as CIP-0033 (Draft) - [PR161 - CIP 33: \"Reference Scripts\"](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0033)    \n=> Merged minor changes to CIP 15 - [PR183 - Updates to CIP 15 / Experimental Tag](https://github.com/cardano-foundation/CIPs/pull/183)   \n=> Hold on [PR159 - tentative CIP 31: \"Reference Inputs\"](https://github.com/cardano-foundation/CIPs/pull/159) as conversation continues  \n=> Hold on [PR160 - Potential CIP 32: \"Inline Datums\"](https://github.com/cardano-foundation/CIPs/pull/160) - will be revisited as needed   \n=> Hold on [PR148 - update to CIP 30 / api.signData()](https://github.com/cardano-foundation/CIPs/pull/148) (to Triage again!)  \n\n   \n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active |\n| 3 | [Wallet key generation](../CIP-0003/) | Active |\n| 4 | [Wallet Checksums](../CIP-0004/) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed |\n| 8 | [Message Signing](../CIP-0008/) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/) | Active |\n| 20 | [Transaction message/comment metadata](../CIP-0020/) | Active |\n| 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft |\n| 22 | [Pool operator verification](../CIP-0022/) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/) | Draft |\n| 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft |\n| 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft |\n| 28 | [Protocol Parameters (Alonzo)](../CIP-0028/) | Draft |\n| 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft |\n| 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft |\n| 33 | [Reference Scripts](../CIP-0033/) | Draft |\n| 34 | [Chain ID Registry](../CIP-0034/) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2022-02-15.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [February 15 2022 notes](#february-15-2022-notes)\n  * [Triage](#triage)\n    + [PR136 - metadata onchain standard ](#pr136)\n    + [PR153 - moving CIP 23 status to 'Proposed'](#pr153)\n    + [PR157](#pr157)\n  * [Last Check](#last-check)\n    + [PR148 - Update to CIP 30 (signData API)](#pr148)\n     \n  * [Review](#review)    \n    + [PR159 - tentative CIP 31: \"Reference Inputs\"](#pr159)  \n    + [PR160 - tentative CIP 32: \"Inline Datums\"](#pr160)\n    + [PR163 - Tentative CIP: \"Dynamic Saturation based on Pledge\"](#pr163) \n  * [Discussions](#discussions)\n    + [Pr151 - CIP30 event API](#pr151)\n  * [Close](#close)\n- [Extra](#extra)\n  * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)\n  * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)\n  * [Understanding CIPs further](#understanding-cips-further)\n\n## Summary\n\nRough writeup of 02/15/22 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Notes might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/e/cip-editors-meeting-39) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n- [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n- [x] **Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n- [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n- [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n- [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n## February 15 2022 notes \n\n**Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, Frederic Johnson, ~Robert Phair~. + guest (MPJ)\n\n\n### Triage \n\n#### PR136\n[PR136 - metadata onchain standard ](https://github.com/cardano-foundation/CIPs/pull/137) \n\n**Matthias** - Before I begin also, I would like to present Maria who is with us today from the Cardano Foundation. She will be taking over Frederic Johnson on the project management for CIP Editors sessions. We will jump right in to the first PR on the Triage list, which is PR137 - metadata onchain standard, which has been approved for a while. As I recall, we left to comment on that back in November. Regarding a few points in this pull request. The general idea here is the proposal about defining a standard for using the Cardanol blockchain as a data store. When it comes to specific data related to transactions or DApps. And it comes obviously as an alternative to storing metadata off chain. And it's currently proposing a few other CIPs. The main concern on the onchain metadata is that the blockchain is probably not really suited for that kind of storage. So that's what I started to outline back in November. There are also some security concerns with that, because if you start adopting the standard and then not everyone is following that standard,, there is a good chance that there will be some misinterpretation of this data. This  was actually outlined by Michael PJ also back in November in another CIP. So there is a comment linking to that. There have also been some recent comments, which I haven't got time to go through. Sebastien, did you have time to look at this PR, because it's pretty old?\n\n**Sebastien** - Yes, I remember we looked at this a while back. We had some concerns about the ability of these and then also backboarding existing tokens. These were two concerns. I'm not sure what to do about this one because although it's not perfect some people are really early using it. At the same time some other people are not using it, and they're using the 7.21 proposal. Even though they're not making NFTs. It is just because wallets are currently implementing this 7.21 version. Wallets are now stuck having to look at a token and see if it is saying 7.21 token. Then based on the supply of these tokens then decide if it is NFT or not, instead of just policy or standard. We can either double down on these routes or just cancel the CIP in a sense, and then double down on CIP-0025 which is this 7.21 version and extend it for tokens.  This is how we stay backwards compatible with those people who took that route, or we just acknowledge that this standard is not perfect, but it is something and move to merge it. \n\n**Matthias** - There is no perfect solution, and that is a potential liability for some projects and the risk that it may include. I mean, it seems we've already reviewed that proposal, a while back, and most of the comments we made haven't been addressed. I would just ping Matt on that and see if they can provide any updates. I guess  they made a proposal at a point where  it made sense to them as well, but they reverted the decision later on. I don't know. We definitely need some updates from the author here. I guess there is something to do regarding onchain metadata. I don't think that proposal is it. I hope there is someone that can rework if possible. I am just too afraid to have two standards that are not completely compatible. But they can also cover different use cases, that's fine. Michael pointing out, actually these comments we had before. And this is the same. Yes it is poofing, as outlined in the previous proposal. So, I guess we can simply go back to this one. In the meantime, contact the author Matt and see if he can provide any additional feedback on what we already provided or maybe reviewed. That will make more sense.\n\n**Frederic** - Would we put it back for Triage in the next meeting?  \n\n**Matthias** - No, I would wait for another update. I will write a message on the pool request asking for updates. Then we can reconsider it for Triage when there is an update. Otherwise it will just be there.\n\n=> [PR136](https://github.com/cardano-foundation/CIPs/pull/137)  Moved off the agenda (and off from 'Triage') until Matthias have update from Matt and see if he can provide any additional feedback (check in on it in a few meetings)\n\n#### PR153 \n[PR153 - moving CIP 23 status to 'Proposed'](https://github.com/cardano-foundation/CIPs/pull/153)\n\n**Matthias** -  CIP 23 - Moving to status proposed, which is PR153. It should be draft to proposed. I have approved this one while back, there has not been a recent date. I don't have any rejection regarding moving it to proposed, since it was actually proposed a while back. I was reaching out to research this morning on a few CIPs including that one. To get back on while trying to review this. A few of those CIPs which involve core changes.  Most of them are actually regarding stake pools, pledge mechanisms, rewards or ranking. As this last comment highlights, there are concerns and secret reasons why some of these CIPs may not be implementable. Stil, I would like to get very clear answers from the research team on that. Just to be able to label those CIPs as  not doable or obsolete. If they are not doable, or if they are not then try to see how we can start a process to get them implemented in the core part of the code base. Any comments on Sebastien, Frederic or Maria in terms of moving this from draft to proposed?  It was merged as a draft almost a year ago. \n\n**Frederic** - I approve it would be good to merge this or to move it to the last check. I do not know which is more appropriate. I think that it'd be fine to merge it as it is. How do you feel about giving it like two weeks to review it? \n\n**Matthias** - No. I mean this is a pretty old CIP and it should be merged as proposed already. Still, we won't be merging it as easily. Because the pool request is quite weird. There are five commits there which are unrelated. Only the last one is changing status.  I'll do a bit of github cleanup before merging that. So we can just get one status change and not have a heavy weird history out of it. \n \n\n=> [PR153](https://github.com/cardano-foundation/CIPs/pull/153) being looked into and to be followed on of next meeting (should it be moved to 'Last Check')  \n\n#### PR157\n[PR157 - Adding multisig changes to CIP-0021](https://github.com/cardano-foundation/CIPs/pull/157)   \n\n**Matthias** - This PR is adding multisig changes to CIP-0021 which describe all the requirements for the hardware integrations, what the hardware supports and what are the capabilities. Back when this was written, there was no support for multisig native scripts and phase 1 monitor in scripts. I think that's what this is referring to. Which has now been implemented by the hardware team. It is quite a minor update.\n\n**Frederic** - Maria can you scroll up and click on the file changes, to show the changes?\n\n**Matthias** - Yes, it will just give us a summary of what's being changed. So it is stating that many things which were not supported back in the days, and now it is supported correctly. I think there are still limitations on the hardware devices. Obviously. The VacuumLabs team has been updating this CIP regularly with their progress. It is a dynamic change log of what the hardware devices can do. Which include both tresor and ledger, as I recall. I guess we can merge this one then. \n\n**Maria** - Shall we move this one to last reviewed?\n\n**Matthias** - Well, given that this one is a small update on an existing CIP, there is no need to do like the last review, last cheek, for this kind of minor update. We can just proceed with merging that one. I see Sebastian has already agreed.\n\n**Maria** - We have both approvals.\n\n**Matthias** - I will just ping Robert on that. Now we can move into the last check items.\n\n\n=> Merge NOW ([PR157 - Adding multisig changes to CIP-0021](https://github.com/cardano-foundation/CIPs/pull/157))\n\n\n### Last Check   \n\n#### PR148\n[PR148 - Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148)  \n\n**Matthias** - So we had PR148 - Update to CIP 30 (signData API), which we already reviewed last week. And before that even it comes with few changes, and I guess the remaining one was this format for the addresses in the API. Which was here “It was merely hex-encoded bytes of the signature or what.”\nWe decided it would be better to actually favor take through encoded addresses. This is how we manipulate the addresses and facing interfaces. I don't think Rob has done anything. Yes, he was probably busy with other stuff. Because last time we pointed that out it was back in January. I think there is not any progress on that one. I would just ping Rob and see if we can move that one to the Last check on the next CIP meeting. Is that fine for everyone?\n\n**Maria** - We are moving this one to Last Check for the next meeting? \n\n**Matthias** - Yes, I am pinging him on github, and we can move this one for the Last check for next week. To check if there are any updates.\n  \n\n=> [PR148](https://github.com/cardano-foundation/CIPs/pull/148) moved to 'Last Check' for next week\n\n### Review \n\n#### PR159\n[PR159 - tentative CIP 31: \"Reference Inputs\"](https://github.com/cardano-foundation/CIPs/pull/159)  \n\n**Matthias** -  Next one is CIP 31, which we've already reviewed quite a bit. There has been a recent update from Michaele. Here in the chat, we can also invite him onboard. I think the update was mainly about forbidding the usage of these new features for old scripts. Plutus V.1 script that is already ongoing on-chain. That racional for doing that is actually quite good, because you do not want to silently be failing, and silently be deconstructing the transactions that already look different from what they are. That could lead to very interesting but bad behaviors\n\n**MPJ** - Not really, the discussion was mostly around the same topic of old scripts. \n\n**Matthias** - From my perspective, this one's ready to go as a draft at least? While the implementation is also going on, there might be still a few changes. Maybe a few things got discovered, forbidding it for the old scripts. I actually approved that a while back. What is your state of mind on that, Sebastian?\n\n**Sebastien** - Yeah, I think it was also good to go.\n\n**Matthias** - Okay. So Michael is saying, “summary: the ledger would like to maintain the principle of \"constructing the transaction context is as injective as possible\", i.e. we don't throw away information silently. That's what's guiding the changes to all of CIP-31 to 33.” Okay, that's good. And I guess maybe that's a bit off record, but while we're at it, for the Plutus V2, we might also consider the case of biome addresses, by silently omitting stuff that would be maybe good or maybe completely remove biome from the ledger at some point.\n\n**Sebastien** - Well, I have a question about the banning of old scripts. Is the definition of old scripts Plutus V1, or is the definition of old scripts native scripts?\n\n**Matthias** - No, Plutus V1 here. So that would be really the Plutus V1 that doesn't support or not yet aware of these capabilities. So the idea is to say, \" If you want to use these new features, that would be a reference input, that would be a reference outputs and inland datums, all those things, you would have to use the V2 version of Plutus. And if you try to construct a transaction that contains a Plutus V1 script that is making use of those new features, that should be a ledger of failure and your transaction should be rejected in phase one. Right, Michael? That's the goal? Okay. Phase one failure. So that's good. That's really contextualizing the transaction correctly before you start validating it and running the validators.\nSo I guess we can move into last check for next week, unless there is any major changes that should just be kept in Ripple as draft until the implementation is sorted out, and then we can move it to propose or active. So Les is saying, \"Should it be treated phase one?\" It has to be a phase one. \"Yes, I do agree with that.\"\" It is sad that Michael doesn't have any microphone so that would be nice to bring Les and Michael on the voice. But maybe then if that's actually not quite clear, Michael, could you add a justification of why this should be added as a phase one validation failure? What would be the rationale for that? So that it is clear from the proposal. \n  \n\n=> [PR159 - tentative CIP 31: \"Reference Inputs\"](https://github.com/cardano-foundation/CIPs/pull/159) moved to 'Last Check' \n\n \n\n#### PR160\n[PR160 - tentative CIP 32: \"Inline Datums\"](https://github.com/cardano-foundation/CIPs/pull/160)  \n\n**Matthias** - Good. So next one on the agenda is CIP 32, inline datums, which is also quite simple. I thought we merged that one already last meeting. CIP 33, right? So CIP 32 is about using this datum field that we currently have on output, which currently can only contain the data hash to use it, to contains actually non hash data, which would be suitable for small datums, actually, and really transform the EUTXO as a ... really give it the ability to carry a bit more data than what it currently] does. That's particularly useful for [inaudible 00:20:57], for instance, and a few other use cases that needs to just publish some very short data onchain. This one has been through far less comments than the others, but there were a few comments from Sebastian back in December. So I'm not sure if you want to continue and take that one on, Sebastian. I haven't watched following in the discussion on this one. So I will be glad if you can give us a summary.\n\n**S** - No, I think everything we've answered already. \n\n**Matthias** - We'll move to Last check. I would give it a proper read also again for the next meeting, especially all the conversation that has been going on. I had looked at the CIP a while back, but there has been quite a few comments. Okay, if Michael have any comments to say, otherwise, we can move to the next meeting as last check.\n\n=> [PR160 - tentative CIP 32: \"Inline Datums\"](https://github.com/cardano-foundation/CIPs/pull/160) moved to 'Last Check'\n\n#### PR163\n[PR163 - Tentative CIP: \"Dynamic Saturation based on Pledge\"](https://github.com/cardano-foundation/CIPs/pull/163)\n\n**Matthias** - The PR 163, which is CIP not yet assigned.  So that's also one of the CIPs I've written to the research team's attention this morning, as I would like them to chip in a bit on how this would impact our current reward mechanism and other assumptions. So the core-ID here is to limit the amount of the pledge cap that is currently fixed to in away proportion of the total stake divided by K, K being the protocol parameters, currently fixed to 500. So instead of limiting the saturation by the whole stake of a K, we want to limit it by a proportion of this amount based on the amount of pledge such that pools with lower pledges have also lower saturation cap.\nAnd the goal is actually to sort of favor state pool operators to use bigger pledge instead of duplicating or splitting small pledges into more pools. And the goal of that CIP is to avoid the multiple construction that's currently happening on Cardano and try to favor a bit more single pools. On the comments on that CIP, there was actually a good remark from Jerry, asking for what are the thresholds and what are the expectations for the thresholds? Currently, the threshold is 500K ADA, you got to 100% of the K saturation level. For 250K ADA, you 50% of that, and so on. The thresholds currently are a bit arbitrary, although they have been, I guess, calculated from what's currently observable from the main chain.\nThere may be a good argument for saying that the threshold could be a protocol parameter, in the very same way that K is a protocol parameter, so those things could be adjusted dynamically to react to market changes or what's happening on chain. Anyone has any comment on that one? Sebastian, Frederic or Mario? I guess that's no. So from now, I would like someone from the research team to chip in on that. From my own perspective, I find the proposal interesting. It should be also relatively simple to implement as a first maybe step in that direction if this is also something that is wanted by the community. Which brings us to another question regarding CIPs like that, and that are quite opinionated, is how can we tell whether or not some changes are actively wanted by the community or granted by the majority of the people on the network.\nSo that's maybe a good topic for discussion to get a few people from a panel and see how we can approach these kinds of changes, because there are many CIPs like that, that would be sound and fair and good ideas for many, and that would be terrible ideas for others. So yeah, I would very much question that, how we can get consensus on this sort of thing.  I see Kevin saying “I'll point the research team at it”\n\nI did it this morning, Kevin, so hopefully we should get someone to review that and to get some feedback. And I would like to sort of have a more streamlined way of doing that, generally speaking, with the CIPs, because there are at least, I think, six or seven ones that have prompted me to research this morning, which I would like to get research inputs. And once we have actual research input, we can bring the discussions into engineering to see the feasibility of implementation. And then there is this other political aspect, which is deciding on whether or not a CIP, a proposal, should be implemented. I don't have the answer yet on that. So something to be discussed within the community.\n\n**Maria** - So right now, we are going to leave this PR on hold, until we get the input from the research team. Right? And start thinking next steps if we want to bring the store conversation within the community, right?\n\n**Matthias** - Yeah, but that's a bit out of scope of the CIP process here, but more of a general work on organizing changes around Cardano. So as a CIP editors here, and as part of this process, our goal is really to tell whether or not proposal is sound, secure and holistic as an implementation proposal, but it doesn't give any form of authority on whether or not a proposal would be implemented. And that step is still a bit missing. So because we insist this proposal is sound and we want to get it merged, that doesn't mean it will immediately be implemented as part of a whole major change. And I know that a lot of people have been frustrated, but that's the second step because there are many things involved. And as I said, some proposals which are sound from a technical perspective, that will please some people, some other will disagree with. And this is where we need to find how to reach consensus on that. But this is also not our role as editors. So that is just what I wanted to point out.\n\n=> [PR163](https://github.com/cardano-foundation/CIPs/pull/163) Moved off the agenda (and off from 'Last Check') and put on hold until we have update from research team and from community (check in on it in a few meetings)\n\n\n#### CIP 35 - Plutus Core Evolutions\n**Frederic** - Also, just to flag for this meeting, we have 25 minutes left. We're getting to the discussion section of the meeting, but maybe there's still pull requests that should be brought up that we didn't get on the agenda?\n\n**Michael** - So yes, there are a few small ones that we can actually resolve probably synchronously. There have been a few ones, actually. There is one I would like to talk about because it's also root PR or root CIP that would give birth to other things which is tentatively the CIP 35, which is called Plutus Core Evolutions. Since we have Michael here, that would be a good opportunity to talk about that. So that CIP's proposing a process for proposing changes into produce and actually getting them implemented. Right. So it's sort of a way to ensure that this can actually happen and have a process for that, which involve also the ledger team so that people can start making proposals to Plutus. There have been quite a lot of comments on the CIP and conversations going on. So maybe Michael, not sure if you have sorted out your microphone issues, you can give us a small update. Yeah, not about implementation, but still it gives a process for reaching out to implementers, right.\n\n**MPJ** - The actual reflection, probably it's not time for the editors to look at this because there have been some comments and hasn't been opened for very long. So probably we should wait for more people to weigh in.\n\n**Michael** - I'm not asking for review now, I'm just wanting to bring it to the lights so that people can actually go and see comments.\n\n**MPJ** - So a couple things that would be useful to have comments and things on, one is this is a process CIP.  I'm actually not sure if there have been any other process CIPs?\n \n**Michael** -  It has been.\n\n**MPJ** - There have been? But in particular it's proposing tweaks to CIP process, not necessarily to some other process. I'm not sure whether the form is ideal. You know, I'm basically saying you should propose these changes in CIP themselves, and also you should do the following things. I'm saying, \"Well, it's up to the editors to make sure that it happens\", stuff like that. I'm not sure whether it is totally appropriate.\nThe thing about implementation has proven a bit contentious. So there was some good comments from calls, but who was really very interested in and who would really like to pin down the contribution process. And in some ways this would be a more useful document if it said, \"Well, in order to get your change merged, you need to have good testing and have blah, blah, blah, blah, blah\". But as far I can tell, that's just really out of scope for the CIP person. It's about the design.\nThis says what you have to do to get the design document approved. And then in order for it to be active, you have to get that implemented and how you do that is really not covered.\nAnd we have to improve our documentation about what is required for actual contributions elsewhere. This just says what you have to achieve, which is still useful to people because they can see what they have to achieve one way or another.\nPart of the point of this is to make people sort of take a step back and think, \"Hmm, can I do all this? Do I have a good argument that people want this? Do I have a good implementation? Do I know how this thing would be costed?\", whatever. Otherwise people just open issues on the Plutus core. Which is not a bad thing. But I think we can say, \"Look, if you really think this is a good idea, show it.\"\n\n**Michael** - Regarding the implementation, we already have quite extensive contribution guidelines on the Plutus repository. Which maybe could be extended also to cover a bit more of this process.\n\n**MPJ** - It's also going to be context dependent. Right. So, for example, there's this thing the club has been working on, their new cryptography that they wanted into Cardano base. So we could use it from there and then it's contributed in a clear place. And then it has to pass whatever gate keepers that are on that repository to make sure that's acceptable before then it can get to Plutus.. You still need to work out where to make the changes and then get people to accept them.\nI think probably we will then write something like this, a guide, for implementers of built-ins in the Plutus repository, which hopefully will provide a complement to this.\n\n**Matthias** - Yep. And that sounds like a good step in the right direction for open sourcing this whole thing really. \n\n**MPJ** - It's certainly about making it public, but also giving people ways to implement things in it, to work with it. The guidelines currently are already pretty extensive and you can definitely extend that to include a few more steps.\n\n**Matthias** - But as you said, it's always been dependent on the context and on the features, right? You don't look at the same things, depending on what you're trying to modify.\nBut at least the CIP, I think, already gives some steps and some things to think about before actually considering making a change to produce, which is good. As you said, there is a cost model taking to into account our hard fork, there are Plutus version changes and all those things, right?\nOnce you have carefully considered all of that and you still think your CIPs or your proposal makes sense, then you can move it to the next step, which is implementation and proposing that to the Plutus core team, following the Plutus guidelines.\nOr maybe we'll just do it because you convince us it's a good idea and we schedule it or something. So, I think some people are like, \"You're saying, we're just like going to just say your problem. You sort everything out.\"\nThat's not necessarily true. The process of implementation might be that the person who wrote the CIP does all the work because they're really on it. Or it might be, they persuade IOG that it's a super great idea and we schedule the work to do it, or whatever, or we help them, you know?\n\n**MPJ** - I don't think that belongs in the CIP.\n\n**Matthias** - Exactly. And that's what I was raising before. There is another step after CIP, which is getting the work implemented.\nOr you can, as you said, get, IOG convinced that this is a great idea that should be implemented.\n\n**Matthias** - I don't think this is really in scope of the CIP team per se, but I still want to have this conversation. Not necessarily be part of it, but at least have that conversation set up somewhere between relevant people.\n\n**MPJ** - But I think that if we made that clearer...For example, you could have a mandatory section in the CIP for implementers. And then you say, \"Look, this is where you edit this, when you find someone who's going to implement it. And if it's blank, you don't have anyone to implement it.\"\n\n**Matthias** - That's sort of what the past two active, currently is in the CIPs. It should highlight clear steps that can bring the CIP from proposed to active. And that includes an implementation for the CIP, that algorithms, some are not related to code necessarily, right?\nBut yeah, some step might be get that implemented in Plutus by X or Z. And then you have either to have already reached out to the Plutos team for that.\nIf you can reach the Plutus team for instance, and they clearly tell you, \"No, we won't implement that proposal, even if it's technically sound because this and this and that,\" then you can go back to the CIP and make it obsolete, right? Or duplicate it because the past to active is actually not...You cannot act, but you did it. You cannot realize it, right?\nIf there is no way for you to implement it and to get into the active position, then you might as well not give your CIP as proposed forever, which is you turn it off.\n\n**MJP** - Okay. In my opinion, this isn't totally easy to understand from  CIP-001.\n\n**Frederic** - So let me step in on this one. By past to active, really what we mean is observable criteria that we agree as a group reflect the active status of that CIP.\nSo whether those criteria are observed, it should be something that someone external to the editorial panel can go and verify.\nSo it's something that people will push into the body of the pool request or the CIP, and say, \"I want to see five implementations of this to consider it active\". And the past to active agreement on the PR by the editors is effectively saying, \"Yes, we agree. Those criterias will be observable\". And if they're observable, it should effectively mean that it's active.\n\n**MJP** - Sounds like the editors should get together to decide what path to active means.\n\n**Matthias** - I hope I didn't imply anything else, but yeah, that's what we stated in the CIP-001, actually.\n\n**MJP** - In that case, maybe just elaboration that adds, for example, that might mean naming an implementer, but that doesn't even fit there, right?\nI think there's a useful thing to be able to say, which is to say this CIP either has someone who's agreed to do the work or it doesn't. And at the moment, the path to active, as I understand it, might say something like \"Here's a checkbox saying there is an implementation\" or something.\nBut I think that, as someone looking at the CIP or considering its status, it'd be quite helpful. If you just see an empty check box saying \"implementation\", it's not complete. That doesn't tell you very much.\nBut if you see an empty section where it says \"implementer blank\", then you're like, \"Okay, no one has even agreed to do this\", right?\nAnd it's meaningfully different to see there is an implementer, but they haven't done the implementation. Okay. That tells them something else.\n\n**Matthias** - Yeah. So Kevin is also saying in the chat maybe that we could add an extra status to the CIPs. For those that are relevant like the Plutus core changes, or the ledger changes, right? After the proposed date and before the active state, we have the state that is accepted or adopted, meaning the identified implementer has accepted to implement the CIP, and will work on implementation.\nThat's similar to this past to active is, or it's maybe the step before the past to active, right?\nPast to active would be: reach out to those people and then have actually the implementation done that you can review and see.\n\n**Maria** - So what do you want to do with this CIP 35, do you want to still discuss it at the next meeting or?\n\n**Matthias** - Yeah, we can move it for review for the next meetings maybe. I mean, we'll see when we create the agenda. I would also like to leave a bit more time for that one. I mean, the next things will be in two weeks, but maybe we want to have it in the next meeting, but in a month from now.\n\n\n=> [CIP 35 - Plutus Core Evolutions](https://github.com/cardano-foundation/CIPs/pull/215) put on hold and wait for more comments\n\n\n\n\n### Discussions  \n\n#### Pr151\n[Pr151 - CIP30 event API](https://github.com/cardano-foundation/CIPs/pull/151)\n\n**F** - We have PR 151, Is this worth reviving to CIP30 event API, or should we move this in? \n\n**Matthias** - I revived it some time ago, I think. That wasn't that one, actually. The event API, yes, it doesn't seem to have gotten a lot of changes recently.\n\n#### PR 211 - Add reference implementation CIP15\n\n**Sebastien** -- Can we look at 211? Add reference implementation for CIP15. A simple change.\nSo basically, I was looking into how to get catalyst support for Flint, which is our new wallet, and I noticed there's no library for this, so I created a reference implantation. This is based off the same core idea we had for [inaudible 00:44:01] originally, so it is used in production networks, although this library is not used by [inaudible 00:44:06], so it's not the same.\n\n**Matthias** - That's your reference implementation by the author, right? You also want that CIP back, so I guess that's fine.\nOkay, well, let's also ping Robert about that, I guess, but yeah, we can take that off. It's fine by me, and since it's a quite minor change, we can also merge it synchronously. Any questions in the chat? No, no questions asked either on the platform.\n\n**Sebastien** -  We also merged 207. Seven updates came, you take care, Max said.\nBut what I'm saying, this has already influenced it, and they're just updating the CIP.\n\n**Mathias** - Well, yeah, I kind of disagree with that one, but I see that four of you agreed. I mean, I don't disagree with increasing things in particular, right, or changing, but hear it sounds more like an implementation detail of the implementation rather than CIP. \n\n**Sebastien** - Yeah. I mean the other changes we could have removed this line from CIP.\n\n**Matthias** - Yeah, and that actually implemented ... Several implementing that decides on where they want to draw the cost out, and at the same time, if the implementation is based on that, right, that's also breaking change per se, so, yeah. Anything else from your side, Sebastian?\n\n\n=> [PR 211 - Add reference implementation CIP15](https://github.com/cardano-foundation/CIPs/pull/211) put on hold and wait for more comments\n\n\n**** Collateral CIPs\n\n**Sebastien** - If there's nothing else, I'd like to talk about the collateral CIPs, so we have three collateral CIPs, collateral key, collateral output, and collateral reward. Collateral key is an old one. We can close it. Collateral reward is a new one. We can close it as well. I'm not going to push for this, but we can leave it up for now, and close it at a dedicated time, so it might be good. \nCollateral output, so I'm gonna give you some backgrounds, final stuff. So basically, for the past hard fork, last time there was no hard fork, for Alonzo, we introduced the concept of collateral. I was not happy with the way it was implemented, so I talked to the IOG team about how I think it should have worked instead. As this was happening, the IOG people also took my feedback into account, talked to other people, like Beck Labs, took their feedback into account, and brought the specification for it, and I in the parallel wrote the CIP part. So there is still four months-ish, until a hard fork, so I guess I'm good changing, so there's no rush to merge it, but just the background on this collateral output specification is just the write up of what we discussed internally.\n\n I mean, this is before the hard fork happened, like leading up to the hard fork, and I don't remember who was involved because there's a lot of people involved in this. I could go back in my slack history. I put Jared because he's the one managing the spec, and myself, so I put the CIP which I had like three months to do this spec. I don't particularly mind removing myself, as I'm just the person who is capturing the discussion right on Slack, and just only having Jared as the author because he's still managing the spec change, but it's how it's set up.\n\nThe collateral reward was purely included for ... Yeah, I did update it to match the spec by the way.\nAndre, I believe that your discussion with the feedback from the Harvard Law guys was after I brought this discussion up to Jer, and I told him this won't work with a Harvard wallet, so you're gonna have to go talk to Beckley Labs about how to get this; and that discussion was included in the collateral key discussion, so basically, collateral key was the old CIP. One of the problems I laid out in the collateral key was that we need this approach because the current approach doesn't work with Harvard wallet. That's how that discussion started. So collateral reward is purely included for your completionist purposes in different ways we could have it.\nAnd this is basically saying, instead of saying the collateral output to a new address, the collateral output instead gets sent to the reward account. Now, obviously, this is not doable in current implementation of Cardano, I mean, it's doable, but I would not suggest it as a good idea for many reasons. I mostly brought this up because one, it is technically speaking doable, but also two, because there's been some discussion about primary ledgers, and how primary ledgers could affect stuff like drip drops, SPOs. And I was just mostly writing this up to say, hey, if we bring back primary ledgers, they would affect these SPO cases, and could be a way we could do collateral output and so on. I don't think anybody would've push for this.\n\n**Matthias** - So if the intent is actually to show that this was a path that was discussed, but sort of rejected, there is always the option of merging it as a rejected CIP or obsolete CIP. So that it can really show that, yeah, this was discussed and this was really rejected for these and those reasons.\n\n**Maria** - Could you make a quick summary? I think you said there's three collateral PRs, but I've only been able to locate two of them..\n\n**Matthias** - I think the first, or third one should be, or will be closed anyway by Sebastian. Yeah. It's the PR 104, which is now labeled as likely deprecated, and then, so Sebastian, since you also the author of that one, I guess you can move forward and close it.\n\n**Sebastien** - This is from before the hard fork, before we discussed collateral output and collateral output\n**Matthias** - I remember that. There was also the case of merging that one as a rejected obsolete CIP. Just to keep the discussion recorded.\n**Maria** - Okay, so we have this collateral key that is going to be closed or marked as obsolete?\nThen we have a collateral reward that is going to be closed, but we have time to do that?\nAnd then there's the collateral output, that it needs to be done before the hard fork, so there's no rush, but ... Shall we put them on review?\n\n**Matthias** - We could probably put that on review for next week or next month, at least, to also give you a bit of time. It seems like the spec is being worked on by the ledger team in parallel, so that already gives a more streamlined path to implementation, possibly. It is quite observable from past to be active. I'm not sure if they will be done in two weeks from now, but yeah, maybe we can have it as review for the next meeting, and if it's still being cooked, we can look at it back. Yeah, more weeks for the next one. I think we'll just stop it here, and thank you everyone for joining, coming, and commenting. It's good actually, to see more and more people joining these meetings, and see you in two weeks.\n\n=> [CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104) moved to Triage for next meeting\n=> [Collateral reward #217](https://github.com/cardano-foundation/CIPs/pull/217) moved to Triage for next meeting\n=> [Collateral output #216](https://github.com/cardano-foundation/CIPs/pull/216) moved to review\n\n\n\n\n### Close    \n\n=> Merged minor changes to CIP-0021 - [PR157 - Adding multisig changes to CIP-0021](https://github.com/cardano-foundation/CIPs/pull/157)    \n=> Hold on [PR136](https://github.com/cardano-foundation/CIPs/pull/137)  Moved off the agenda (and off from 'Triage') until update or any additional feedback\n=> Hold on [PR153](https://github.com/cardano-foundation/CIPs/pull/153) being looked into and to be followed on of next meeting (moved to 'Last Check')\n=> Hold on [PR148](https://github.com/cardano-foundation/CIPs/pull/148) moved to 'Last Check' for next week \n=> Hold on [PR159 - tentative CIP 31: \"Reference Inputs\"](https://github.com/cardano-foundation/CIPs/pull/159) moved to 'Last Check'\n=> Hold on [PR160 - tentative CIP 32: \"Inline Datums\"](https://github.com/cardano-foundation/CIPs/pull/160) moved to 'Last Check' \n=> Hold on [PR163](https://github.com/cardano-foundation/CIPs/pull/163) as conversation continues  \n=> Hold on [CIP 35 - Plutus Core Evolutions](https://github.com/cardano-foundation/CIPs/pull/215) put on hold and wait for more comments\n=> Hold on [PR 211 - Add reference implementation CIP15](https://github.com/cardano-foundation/CIPs/pull/211) put on hold and wait for more comments\n=> Hold on [CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104) moved to Triage for next meeting\n=> Hold on [Collateral reward #217](https://github.com/cardano-foundation/CIPs/pull/217) moved to Triage for next meeting\n=> Hold on [Collateral output #216](https://github.com/cardano-foundation/CIPs/pull/216) moved to review\n\n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active |\n| 3 | [Wallet key generation](../CIP-0003/) | Active |\n| 4 | [Wallet Checksums](../CIP-0004/) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed |\n| 8 | [Message Signing](../CIP-0008/) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/) | Active |\n| 20 | [Transaction message/comment metadata](../CIP-0020/) | Active |\n| 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft |\n| 22 | [Pool operator verification](../CIP-0022/) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/) | Draft |\n| 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft |\n| 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft |\n| 28 | [Protocol Parameters (Alonzo)](../CIP-0028/) | Draft |\n| 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft |\n| 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft |\n| 33 | [Reference Scripts](../CIP-0033/) | Draft |\n| 34 | [Chain ID Registry](../CIP-0034/) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n\n\n\n"
  },
  {
    "path": "BiweeklyMeetings/2022-03-01.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [March 1 2022 Transcript](#march-1-2022-transcript )\n  * [Triage](#triage)\n    + [PR211 - Add reference implementation for CIP15](#pr211)\n    + [PR104 - CIP-1856 | Collateral Key derivation](#pr104)\n    + [PR217- Collateral reward](#pr217)\n  * [Last Check](#last-check)\n    + [PR153 - Fair min fees](#pr153)\n    + [PR159 - CIP-31: Reference inputs](#pr159) \n    + [PR160 - CIP-32: Inline datums](#pr160)  \n  * [Review](#review)\n    + [PR148 - CIP-0030: update to api.signData() ](#pr148)    \n    + [PR216 - Collateral output](#pr216)   \n  * [Discussions](#discussions)\n    + [Add support for Catalyst multi-delegation](#pr200)\n    + [PR208 - CIP-0030 Adding getCollateral function to the connector API](pr208)\n    + [PR209 - CIP-0030 Adding optional networkId parameter to .enable](#pr209)\n    + [Moving meeting 41 to US time zone](Moving-Editors-Call-Meeting-41-to-US-time-zone)\n  * [Close](#close)\n\n## Summary\n\nRough transcript of 01/03/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Transcript might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/e/cip-editors-meeting-40) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n**Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n\n**Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n\n**New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \n\nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n**Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n\n**Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n\n## March 1 2022 Transcript \n**Attending Editors**: Matthias Benkort, ~Duncan Coutts~, ~Sebastien Guillemot~, Frederic Johnson, ~Robert Phair~. + guests(Kevin Hammond)\n\n### Triage \n\n#### PR211\n [PR211 - Add reference implementation for CIP15](https://github.com/cardano-foundation/CIPs/pull/211)\n\n**Maria** - Welcome, everybody, to the CIP editors meeting number 40. My name is Maria Jover and I am a project manager of the Cardano Foundation and I am here to facilitate this meeting. At the top left, you can find the agenda for the meeting today and please feel free to use the chat or the ask question in order to engage with the conversation. It's my pleasure today to introduce you our editors, Matthias Benkort and Frederic Johnson. So you want to make an announcement or a request, right, Matthias?\n\n**Matthias** - Yeah. So we've been discussing in the past a bit getting the CIP into a more US friendly time zones so I've been discussing that a bit with the other editors and we would like to try to have meetings more often in these time zones. So what we're going to do is to move maybe to a weekly cadence, where half of the meeting will be still at the current time, so in the Europe based, at this daily hour, on the same day, and the other half of the time, it will be on the same day also, but later, or more around six, seven from European perspective, but then it'll be a more convenient time for the US people to join in and chip in. And also, it will double basically the frequency of meetings. So hopefully we'll get to move a bit faster on the triage and the discussions on some of the CIPs.\nThat doesn't mean that the process per se will be faster per CIP, because we still want to allow time to discussions and time for people to actually chip in. But at least we'll be able to cover, I hope, much more items faster. The CIP has gained traction over the past months. A lot of people are using it. And yeah, so we have to keep up basically with all the request proposals and changes that are going on.\n\n**M. Àngels Jover**  - Good. So shall we start with our items on triage? PR211: Add reference implementation for CIP15\n\n**Frederic Johnson** - Maria, one second. So first, when we check in, is also if there's any long-lasting items that needs to be followed up on, that needs to be added to the agenda. I don't believe there is, but just want to make sure that we look into this, Matthias, if you have anything you want to bring up outside of the announcement. No CIPs?\n\n**Matthias Benkort**  - No. Or maybe yes. There is a small Pull Request I did some days ago, which is just clarifying a bit the README on the CIP, because I saw a lot of people getting confused in the community about CIP31, CIP32, CIP33, and their adoption in Cardano. So I wanted to clarify a few things. That's for request number 227. It's mostly for editors to chip in here and Robert has already checked that. Not sure about Sebastian, but it's clarifying a bit the wording, clarifying the intent by explaining really what is CIP all about, and in particular, that it's not a process that is blocking implementations or that is mandatory for an implementation.\n\nAnd it's actually going often at the same time that you do an implementation and you propose also kind of the rationale for that implementation as a CIP. And they are both helping each other because as you implement, you discover new things. And as you discuss with people, you might adjust also your implementation. And I also added on the CIP on the README, a table with all the CIPs currently under discussions, that are still in pull requests, just to ease a bit the navigation so that it's easier to find. And to keep in mind that this README is also part of the website, the cips.cardano.org website that's the front page is actually our project README. And a lot of people are actually going through that website as an entry point for the CIPs, and many were surprised not to find the CIP32 or CIP33, which were still in pull request and not merged in the repo.\n\nSo of course, since they are not merged, they are not in the audit table, which contains all the CIPS that we have discussed and reviewed. But I think it's still worthwhile to have them under README just to have to a link to them and to be able to easily jump on the conversations. So that's the change.\n\n**M. Àngels Jover**  - Perfect. So now we have PR211: Add reference implementation for CIP15. This one, we had a conversation last meeting, and according to my last notes this was going to be merged asynchronously, but it hasn't been done, I guess.\n\n**Matthias Benkort**  - Yeah. We were waiting for review from Robert. It came two weeks ago, but we then kind of forgot to merge it. So this is just a small update on CIP15, adding a reference implementation, which I've also reviewed. So this one is fine to go. Now it has two check marks from a editors so I would just proceed and merge that one. Good.\n\n=> Merged as CIP15 (draft) [PR211 - Add reference implementation for CIP15](https://github.com/cardano-foundation/CIPs/pull/211) waiting for Rob answering 211 in order to identify phase one\n\n\n#### PR104\n\n[PR104 - CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104)\n\n**M. Àngels Jover**  - PR105 Collaterall Key Derivation\n\n**Matthias Benkort**  - I would like to maybe postpone a bit this one, because it's a proposal from Sebastian, who is not there today. So there has been a lot of discussions on top of it. And I haven't been following quite closely that one. So I would very much like Sebastian to walk us through a bit the discussions and the outcome. So the general idea here is really to have a ... it is proposing a dedicated key for making the management of collectables easier and hopefully remove that version from the end users, which currently has sort of to define a collectable in their wallets to make sure that they can execute scripts. And it's a bit cumbersome at this stage. So yeah, I see the proposal has been discussed by the people from the Ledger teams. So it's interesting. But yeah, let's see when Sebastian is back to walk us through that change.\n\n=> [PR104 - CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104) put on hold and waiting for Sebastien to discuss it\n\n#### PR217\n\n[PR217- Collateral reward](https://github.com/cardano-foundation/CIPs/pull/217)\n\n**M. Àngels Jover**  - Good. So it will happen the same with PR217 and PR216, right?\n\n**Matthias Benkort**  - Yeah, one of them is actually duplicated. I think that's PR217. Sebastian said last week he wanted to remove that one, I think.\n\n**M. Àngels Jover**  - The previous one was pretty old, I think.\n\n**Matthias Benkort**  - Yeah, I think what he said last week was that this one wasn't really useful. He just did it for the sake of reporting what had been discussed with the Ledger team in the past. I think he wanted to duplicate it. So we'll also wait on that, maybe ping him back on the pull requests. I've dropped in the comments. \n\n=> [PR217- Collateral reward](https://github.com/cardano-foundation/CIPs/pull/217) put on hold and waiting for Sebastien to discuss it, possibly removed as duplicate\n\n\n\n### Last check\n\n\n\n#### PR153\n\n[PR153 - Fair min fees](https://github.com/cardano-foundation/CIPs/pull/153)\n\n**Matthias Benkort**So moving to fair min fees, maybe. The PR153. So this one is actually just exchange of statuses, right? If I recall correctly or not.\n\n**M. Àngels Jover**  - Yes. What was talked last meeting is that you want to do some with github cleanup on it.\n\n**Matthias Benkort**  - I don't think so.\n\n**Frederic Johnson** Yeah. The merged ... The comment history just has some weird back and forth and you wanted to-\n\n**Matthias Benkort**  - Ah, yeah, yeah, you're right. You're right. Indeed. It has more comments than it deserves with only one word change. So indeed, hasn't happened. So my bad. So okay. Still ready to go. Will merge it then. But I will make a note for myself to do it at the end of this call. So yeah, to adjust the git history, just to make sure we have only the last comments in there because the other ones are from a wrong rebate or something, it seems. Yeah, I guess it's been there for a while and that's probably what happened.\n\nAt the same time, also, I was going back through the CIP1 process and in particular, what it means to be proposed for a CIP, and currently, in the condition for semantic, for propose, we are saying that there is a clear path to active, which brings the question of the core CIPs, like this one, that are actually changing Ledger roles, or really addressing changes in the Ledger. What's a proper path to active. What does it mean? Because there is ... how do you get something to be active? There is no process formally defined criteria with the Ledger team for that, as the Plutus team is trying to push forward. They sort of outline the process for contributing to the Plutus code base, what it would take for a CIP to go from just a draft to an actual implemented and active CIP. But I guess we need to work something out with the Ledger team also for those kind of CIPs.\n\n**Matthias Benkort**  - It's a bit more ... well, tricky for a Ledger, obviously, because it touches the core part of Cardano, so you don't want to do anything wrong with that. But okay, I will also keep a note for that, but I will definitely need to bring the conversation with the Ledger team and IOG on that, to make sure we have an actual way for bringing the CIP up front. I reached out to the research last two weeks ago on various sort of topics. I haven't got a clear answer so far, so I will keep on chasing people. But yeah.\n\n**M. Àngels Jover**  - So we can put this on hold until you have an answer from the Ledger team, right?\n\n**Matthias Benkort**  - No, no. For this one, it's fine. We've already discussed this one a few times. It's also been reviewed by the Ledger team back in the days, but there is still this question of, even if you're moving to propose, that doesn't mean it will ... There isn't currently a item on the roadmap of the Ledger team to address that particular proposal. I'm not sure that's shown as also the willingness or capability to implement the change in the Ledger code base itself. So it has proposed already an implementation, but more like a separated one. So yeah. I will bring that back again to the attention of the Ledger team to see what's up and if they have indeed no plan to implement that and it's a few unknown because these and these reasons. I don't know. Then we'll report back and maybe make the CIP obsolete. But for now, we can move it to proposed, and I will just modify the git history to have a clean history of commits with the Ledgers after the meeting, since it's a fairly small thing to do.\n\n=> [PR153 - Fair min fees](https://github.com/cardano-foundation/CIPs/pull/153)  this PR has a weird git commit history so Matthias will clean up the history to keep only the last commit that is actually the change proposed by the PR (moving it to proposed) and proceed with merging it \n\n\n\n#### PR159\n\n[PR159 - CIP-31: Reference inputs](https://github.com/cardano-foundation/CIPs/pull/159)\n\n**M. Àngels Jover**  - We have PR159: Reference Inputs. And for this one, we comment in last meeting that it was good to go, but we asked Michael to add a justification for phase one. And I don't think that that has been added.\n\n**Matthias Benkort**  - So yeah, it was a small thing, right? That he added recently an extra check, again that was on the forbidding usage of referenceinputs with old scripts with the V1 versions. And I guess there's someone in the chats was discussing why was this done in the phase one but additions of phase two? But I guess we answered that in the last meeting already. Michael didn't report it back on the CIP. Yeah, just drop a line in there. I see it has also the insert, so we can maybe just clarify with him. I will just drop a comment on the pull request. And once we have that, this one would be ready to go and get merged as we discussed last time.\n\n**M. Àngels Jover**  - Perfect.\n\n**Matthias Benkort**  - So we'll just merge it with just the conditions as we add this little rationale, just one small line change. And I will state we can get that done today as well.\n\n=> [PR159 - CIP-31: Reference inputs](https://github.com/cardano-foundation/CIPs/pull/159) moved from draft to proposed\n\n#### PR160\n\n[PR160 - CIP-32: Inline datums](https://github.com/cardano-foundation/CIPs/pull/160)  \n\n**M. Àngels Jover**  - We have PR160: Inline Datums\n\n**Matthias Benkort**  - Yeah, this one is pretty much. Also it was in the last check, it was under last check... No, it was just ready for review.\n\n**M. Àngels Jover**  - Yeah. I think that we have a comment here. It's not in this one. This was for the last check.\n\n**Matthias Benkort**  - Yeah. And that was a bit with some spirits. Yeah, this one is also fine. It should go as a draft towards the implementation. It happening also concomitantly.\n\n**M. Àngels Jover**  - We have all the approvals here, I am going to check. We miss one approval, right? In order to merge it?\n\n**Matthias Benkort**  - Yeah. So, Sebastian, Robert or Fred maybe later when they are up. I will just CC them. Okay.\n\n=> Merged [PR160 - CIP-32: Inline datums](https://github.com/cardano-foundation/CIPs/pull/160)\n\n\n### Review\n\n#### PR148\n\n[PR148 - CIP-0030: update to api.signData()](https://github.com/cardano-foundation/CIPs/pull/148) \n\n**M. Àngels Jover**  - Cool. So we will go into the review items. We're going to start PR 148, because the other one, we will wait for Sebastian\n\n**Matthias Benkort**  - Yeah. So, 148. Yeah, I asked last meeting to have an update from Rob. He said: “I think it's read for review now. I just updated the spec to use an Address string type which can be either the old hex bytes or bech32. I think that's is it for comments on this besides out-of-scope large changes like not using cbor anywhere mentioned above.\n\nI changed the Address format in other endpoints for consistency, but we can do that in another PR if we feel it is necessary. There's also the issue of the API version. Should we be incrementing this by a major version here or do we only want to start doing that once CIP-30 moves out of draft status?” That's a good point.- There's one comment from Martynas: “How about adding a \"content type\" argument? Wallets could try to display the message being signed to the user” \nNot sure to get it.\n\n**Frederic Johnson** - So we will get changes that occurred since Rob actually pushed that comment, or show right before he post that comment? So, my issue goes to-\n\n**Matthias Benkort**  - Yeah, that is what he said. We were discussing in the past, to change the API, to accept not the address as a hexacoded string, but actually as bech32 strings, which is the way it actually displays in most interfases. That's the way wallets manipulate them, and it's a bit more coherent with the entire presenter API. So, what we discussed was to do that for the same data, of course, but then reflect that on the entire API or to keep consistency. But since that would be in principle a breaking change, the idea was to support both formats. It has wallets that actually accepts either hex or Bech32 encoded strings, and let them figure out basically which one it is, which is pretty straightforward to do for a wallet implementer.\nSo, as it is for now, at least from my perspective, the proposal is fine. This was not a proposal per se but just an addendum on an existing one, for the CIP 30. So we can probably move this to the last check for the next meeting, and see if people still want to comment on it or not. So, there is actually one comment, which is asking about something I don't quite get. So we can try to divert that with that person in the next two weeks and see where it goes.\n\n**M. Àngels Jover**  - Okay. So, this was what we have from the agenda. Let me check if there's any questions in the chat.\n\n=> [PR148 - CIP-0030: update to api.signData()](https://github.com/cardano-foundation/CIPs/pull/148) moved to Last check for the next meeting\n\n\n#### PR216\n\n[PR216 - Collateral output](https://github.com/cardano-foundation/CIPs/pull/216) \n\n** Matthias ** - I would like to maybe postpone a bit this one, because it's a proposal from Sebastien, who is not there today.\n\n=> [PR216 - Collateral output](https://github.com/cardano-foundation/CIPs/pull/216) put on hold and waiting for Sebastien to discuss it\n\n### Discussions\n\n#### PR200\n\n[PR200 - Add support for Catalyst multi-delegation](https://github.com/cardano-foundation/CIPs/pull/200)\n\n**Matthias Benkort**  - Kevin wanted to bring up the votes delegation CIP, which I think was proposed by Mark some time ago. That was initially proposed as an extension to Catalyst to the CIP 15 proposal I think. But then we decided that it was better to move it as a separate proposal, in form of like an extension of CIP 15, instead of modifying CIP 15, which is already complex enough, and it has undergone a lot of changes.\n\n**Matthias Benkort**  - So, the idea was to say, \"Okay, we want to have this extension to a line which you have multiple... or just do multiple keys for the Catalyst proposal, such that on the side chain can be multi-delegated to different pools, and therefore enables more like a split routine in the real.\n\n**Matthias Benkort**  - We have Kevin around, so maybe we can bring Kevin on the voice chat, and he can give us a walkthrough. I think Kevin you've been discussing that with Mark a bit.\n\n**Frederic Johnson** - If I recall correctly, I think Mark was adamant on pushing his own pull request or own CIP. And I think Kevin did his own CIP, and I think there were two competing CIPs doing the same thing.\n\n**Matthias Benkort**  - Okay. But I didn't see the CIP from Kevin actually. There was an original request which was changing CIP 15, which is still actually open as a pull request.\n** Frederic Johnson** - But the decision on that specific PR was that we'd scrub that PR, effectively closing it, and instead request a standalone CIP just for simplicity, as opposed to trying to modify the old one.\n\n**Matthias Benkort**  - Yeah. Because it was modifying quite substantially the old one, effectively making it a completely different proposal. So we asked Mark... Actually, we asked to create a number of PR, and Mark volunteered to do so, but haven't still closed the old one. I'm not sure actually who opened the old one in the first place. Do we have Kevin online? Oh no, Kevin is not here anymore. So let's actually go through the comments ourselves then. Oh, Kevin is there.\n\n**Kevin Hammond** - I lost the window. Happy for this to be a separate CIP if that’s what you want to progress. What we do need is a dedicated CIP number that we can just refer to this internally during the developing process. We're trying to use CIP 36. I understand that number that Mark assigned to it, there is path for confusion developing.  On terms of content the we've been commenting the new PR that Mark had put in.\n\n**Matthias Benkort**  - Yeah, okay. So that's [crosstalk 00:23:13].\n\n**Kevin Hammond** - What else now needs to be done?\n\n**Matthias Benkort**  - Well, discussing, obviously, right? Making sure people agree. I think that's fairly the case on that one. The number assignation, that's part of why I did this little change in the read-me I was mentioning earlier. One of the reason why I wanted to move also the current PR under discussions to the read-me, was to pre-allocate them a number already, to avoid these clashes. And this one is in this number 36, so there is a good chance that it will stay exactly like that, unless it gets not merging in the end and ends obsolete. But I don't think this will happen, so we'll probably proceed with that. Move it to the last check as well for the next meeting; it's been reviewed already quite a bit. And yeah, I take it from there basically. So those two discussions... No, I think let's check with maybe too soon, we haven't properly given time to discuss it in any little meeting. We can move it to the next meeting for review.\n\n**Kevin Hammond** - Okay.\n\n**M. Àngels Jover**  - Is this one PR 188 we're talking about right now?\n\n**Matthias Benkort**  - No. This one is the old one. That's the one modifying CIP 15 that we asked to split as a separate pull request.\n\n**M. Àngels Jover**  - So which one is the one that we're going to add to review in the next meeting?\n\n**Matthias Benkort**  - PR number 200, right? Yeah, the 200 one by Mark, which we'll have a full complete review of that one.\n\n**Kevin Hammond** - That's slightly go over authorship it should be attributed Giacomo to who wrote the original proposal rather than Mark. I don't know if there's a way to [crosstalk 00:25:22].\n\n**Matthias Benkort**  - Yeah, it's not attributed to Mark, right? It currently has one, two, three, four, five authors. You're actually one of them, by the way, apparently. Giacomo is also one of them. I guess Mark just wrote the PR, and he didn't even credit himself as an author. He just credited the original. It's just that he did open the pull request. \n\n**Kevin Hammond** - I'm actually trying to get some attribution. So, if Mark created the PR, he'll be attributed with creating this.\n\n**Matthias Benkort**  - No, no, no. If you look at the author of the CIP, they are actually listed here, right? ? So it's Sebastian Reno, Mikhail, Giacomo and you Kevin. Github is always referring to the person who has created the PR as being [crosstalk 00:26:17].\n\n**Matthias Benkort**  - I see what you mean. So maybe what we can do is tweak a bit the GitHub history so that this full request is made as a change on top of Giacomo one.\nSo that in the history we can see that one. This first thing it was reverted, and then this new commit was created. I can do something like that to have the above authors actually be contributors to the repository.\n\n**Kevin Hammond** - Exactly. That will keep the history straight and fair.\n\n**Matthias Benkort**  -Yeah. Fair enough.\n\n**Kevin Hammond** - Like proper credit.\n\n**Matthias Benkort**  - Yeah.\n\n**M. Àngels Jover**  - So Matthias, you will be able to do that yourself or...\n\n**Matthias Benkort**  - Yeah. I will just push on the branch only if Mark actually have authorized people to push on his branch. If not, I will see with him if we can just do that updates. Right? So the ideas is really not to change anything to the current result, but change the history. Right? So that it better reflects what happened, that there was a first change by Giacomo, and then it was on top of that extracted by marking a separate PR. Right?\n\n**Kevin Hammond** -Okay.\n\n**Matthias Benkort**  - So in the history we keep the right history of how things happened.\n\n**Kevin Hammond** -Exactly. Yeah. I think it's important to make sure the history is recorded properly, right Matthias?\n\n**Matthias Benkort**  -Yeah. I mean, in the end, that's why we have this metadata on top of CIPs. It's also, you have the list of authors here, and if you want to refer to one of those people, should be someone from the list. It doesn't quite matter who made the change on unbeatable when you think. But I mean, for some people, it does matter so I can get that.\n\n**Kevin Hammond** - It matters. It matters to some people.\n\n**Matthias Benkort**  -Mm-hmm (affirmative).\n\n**Kevin Hammond** - Great. And in terms of status, we're working on this, we are taking into account any comments that have been made. If people like to make further comments, happy to respond. And not seen any major issues coming up through the commenting process.\n\n**Matthias Benkort**  - Yeah.\n\n**Kevin Hammond** - If anyone would like to add anything to that, very happy to do so.\n\n**Matthias Benkort**  - Okay, good.\n\n**Kevin Hammond** -That you.\n\n=> [PR200 - Add support for Catalyst multi-delegation](https://github.com/cardano-foundation/CIPs/pull/200) moved to next meeting for review\n\n### PR208\n\n[PR208 - CIP-0030 Adding getCollateral function to the connector API](https://github.com/cardano-foundation/CIPs/pull/208)\n\n**Matthias Benkort**  - Let's see, maybe if we have other call request we could bring up to discussions here. If there's anyone in the chat that has a suggestion, otherwise we'll just pick one from the existing ones. I see there is another update on, or two other updates actually, on CIP 30, which we could maybe quickly go through. One is for request 208 and one 209.\nSo one of them is Adding getCollateral function to the connector API: getCollateral given an amount, it gives back a UXTO to spend as collateral.\nThe value to use for collateral? Because... yeah, okay. There is an amounts to be passed, but in principle, this amounts depends on the transaction script execution units.\nOkay. I guess that's an interesting one. We should also bring maybe for review for the next meeting. There is quite a fair, rational extension here. \n\n=> [PR208 - CIP-0030 Adding getCollateral function to the connector API](https://github.com/cardano-foundation/CIPs/pull/208) moved to next meeting for review\n\n\n### PR209\n\n[PR209 - CIP-0030 Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209)\nThen on top of that, there is also the CIP... Sorry, the pull request 209, which is Adding optional networkId parameter to .enable:  a DApp for test net or main net future networks. \nOkay, interesting too. \nAnd it probably echoes... Yeah, CIP 34 from Sebastian, which was about providing a chain identifier. So maybe there is something to do here. Have the network ID be provided as non-chain identifier. Yeah. Providing it as zero or one. Feels a bit untied, or not really user friendly from a developer perspective. So Sebastian had already a good proposal for identifying networks using a proper string of characters, I think codes the network ID and genesis. So we could go for that. So I would be happy also if we maybe this for review, for request 209.\nCIP 30 seems to be creating some discussion with IO... Of course. some additional functionality being needed. Yeah. So I guess the whole point of CIP 30... I mean the whole issue with the CIP in a way, is that it was created pre Alonzo, so there was a lot of things in there that didn't account for scripts and Plutus. Although it is now mainly used by wallets that provides that functionalities. And therefore, yeah, it needs a couple of extensions in that regard.\nSo I guess the collateral is one of them that's get us in the right direction. The network ID is definitely also a cool one to be able to support multiples networks and have also... Well, I test wallets. Test CIP 30 capable wallets for testnets.\nIf there is any other one, Kevin, if you can get the people in IO to make a proposal with those changes, that will be good. And the sooner better, right? Because we can start the discussion earlier then.\nAnother CIP maybe, that I would like to bring to review our discussions next week, is the Plutus Core built-in of... Sorry, the Plutus Core changes CIP. Plutus Core evolution. So PR number 215, which gives a framework for actually proposing changes to Plutus and getting them through the entire process also including implementation with the team and all that. I think that's a very nice initiative for Michael to really lay that down and have a clear process for proposing Plutus changes.\nThere have already been a couple of proposals on top of that one, following that exact process. So it would be nice if we could get this one approved, or at least discussed. I've already been reviewed by me, already reviewed it, because I already made a proposal on top of that one. And I definitely see the value of this one. So I would very much like to have it as an active CIP as soon as possible to be able to then move on and have proposals on Plutus.\nExactly. That follows this standard. So they can bring it for reviews also next week and then last check. Hopefully we can get it into the repro quite fast. Since there is no implementation for that one even, we can probably move it almost directly to active. Because the sole fact that there are already two or three proposals on top of it, well, qualifies it as an active CIP. \n\n**M. Àngels Jover**  - Okay. Anything else that you want to discuss Matthias?\n\n**Matthias Benkort**  - I'm not sure. Keep getting the same stuff in the chat. Yes, I'll try to get people to comment on that. It seems to be some divergence on this. Of course, that's why we want to have a CIP. Because then discussions can happen on the CIPs publicly, and people can share different implementations and different wallets. Yeah.\n\n**Kevin Hammond** - That's right. So we need to get some standardization, I think, on this Matthias. And as I've said in the chat, I think there's some additional functionality which isn't original CIP proposal, which we'll need for the vote delegation. So we need witnessing capabilities as well as signing capabilities.\n\n**Matthias Benkort**  - What do you mean witnessing capabilities?\n\n**Kevin Hammond** - I mean, we'll need to... Because the way the CIP 36 is to find, there are two distinct keys involved. One of them to provide a witness from a voting key... Sorry, from the stake key, and the other to sign and submit a transaction using a payment key. So we need sort out the different elements of witnessing using stake key, versus signing and submitting using payment key.\n\n**Matthias Benkort**  - Yeah. I'm mean, okay. But in both cases that remains, it's still a signature. But it's just a signature from not a human key, but a staking key, right?\n\n**Kevin** - Yes\n\n**Matthias Benkort**  - Because I thought you were referring to witness as in being able to add full scripts or datums or redeemers, or whatever's going for [inaudible 00:36:42] that. But that can already be done by a DApp in principle. They don't need the wallet for that.\nSo how is actually currently... Well, I need to refresh my mind now. On CIP 30, how does the signing works currently? What does it provide? Sign TX, does the wallet determines automatically what the key test to use? Yes.\nAh, yeah. Okay. Yeah. The sign, we give it the TX and the wallet figure out the transaction, witness it. Wallet should be able to figure out it's the staking key, right? But surely the staking key comes from the wallet?\n\n**Kevin** - As long as it knows it needs to sign with staking key, Matthias.\n\n**Matthias Benkort**  - Yeah. So, okay. I mean, maybe we could use an API that is a bit more explicit, like the Ledger or Tresor devices works, right? For signing to device you give them the transaction body, but also the derivation path of the signing key you expect. And then they produce the signatures cross going to do his path.\n\n**Kevin Hammond** - Yes.\n\n**Matthias Benkort**  - So I guess the API here could be extended in that direction to say... Well, you take also a list of derivation path and you make sure that you can produce a signature for them. If you don't provide that list, then it's up to the wallet to figure out those keys needed for a single transaction.\n\n**Kevin Hammond** - Yeah. And then the question is, how does the Dapp knows the derivation path that it needs to have enough information [crosstalk 00:38:12] of it.\n\n**Matthias Benkort**  - Not necessarily. But yeah, okay. Because it's internal details of the wallet in here.\n\n**Kevin Hammond** - Exactly. Yes, don't want to [crosstalk 00:38:24].\n\n**Matthias Benkort**  - But ideally, wallet can probably figure out the signature already.\n\n**Kevin Hammond** - Sorry?\n\n**Matthias Benkort**  - I mean, if you need to sign by a staking key, then surely there is something in the transactions that identified as staking key, right? It has to be in the required signature of the transaction.\n\n**Kevin Hammond** -  Yeah. That's right. I can identify what I have is information about the public. I have the public stake key hash. I won't have the stake key itself, I think.\n\n**Matthias Benkort**  -Yeah, yeah, of course, of course.\n\n**Kevin Hammond** - So I'll need [crosstalk 00:38:57].\n\n**Matthias Benkort**  - But, so a wallet that's receiving this transaction for signing through this CIP 30 API, right?\n\n**Kevin Hammond** - Yes, correct.\n\n**Matthias Benkort**  - It's received the whole transactions and there is some point in a transaction, something that says you need a signature from that key hash. And that key hash is known of the wallet because it's a state key.\n\n**Kevin Hammond** - Yeah. Correct. So as long as I identify the fact that I need a signature from that key hash, as long as the wallet can then determine the derivation path from that, then that would work fine, I think.\n\n**Matthias Benkort**  - I think the current API is fine. What we maybe need to enhance that CIP is a list of test vectors with a specific test case, where you can actually provide a transaction that has a staking key as a required key hash signature, and the resulting signature contains witnesses for that stake key.\n\n**Kevin Hammond** - Right.\n\n**Matthias Benkort**  - And as we make sure that wallets that implement that CIP would have also to satisfy the test vectors and that's it.\n\n**Kevin Hammond** - So I propose is why don't you and I take this offline materials with the IO, we can discuss this with other people and why io wallet team, and then make sure that we have something concrete to this committee.\n\n**Matthias Benkort**  - Yeah. And then make a proposal out of it. That will be fair.\n\n**Kevin Hammond** - Yeah. That seems to be the correct presence.\n\n**Matthias Benkort**  - Okay.\n\n**Kevin Hammond** - Thank you.\n\n**Matthias Benkort**  -Fair enough.\n\n=> [PR209 - CIP-0030 Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209) moved to Review\n\n\n#### Moving Editors Call Meeting 41 to US time zone\n\n**Frederic Johnson** - Do you not consider maybe the rest of the time for discussion regarding moving to a US time zone for the meeting or to try something like that?\n\n**Matthias Benkort**  - Yeah. Maybe, to be a bit more on the process. There is also one thing I would like us to give a thoughts, maybe not in this current meeting, but that is for you, Fred also, and other editors I will reach out, but we have 12 issues open on the repo. So it seems that people are using issues to discuss things. And it's something we are actually, we haven't included the part of the process currently. Right. So we had issues and no one is really taking care of them at the moment. I actually just noticed last week that had so many issues because I was so far focused on the pull request when it comes to the  CIPs, but there is a fair amount of discussions happening in issues, which is interesting. Right. We never really stated that as part of the process, but it just happened organically, I guess. And maybe we should start also, including issues, issue triage as part of the editors meeting or spend some time offline to go through them.\n\n**Frederic Johnson** Yeah. I agree. I've seen those grow and I think that it's good that we're actually paying attention right now as they've pretty much propped up functionally like the past few month. And it's a matter of just keeping on top of it, the same with the labeling of the issues right now. So I think this is all project management really, Maria is going to be able to cover a lot of that ground. I think that's like a new added step. I don't want to overextend a little bit into committing to too many things, like too many meetings and covering issues and adding too many PRs, just because a lot of that is functionally being offloaded mostly to Maria. And I'm just thinking that if we're doubling the meetings, it might be something, have you also coupled with other people that are involved in transcribing the meeting notes and everything like that.\n\n**Matthias Benkort**  - Yeah. Sorry. I was not actually implying that. We shouldn’t double the workload for Maria as well on these US based time zones that I'm actually thinking that the US crew could be possibly different from the European crew. I don't mind bridging the two crew for now, but for sure for the US base, we would Robert onboard and maybe we can also have someone that help with notes and whatnot. Or I can take that. I can take that part maybe on me and let Robert conduct the meetings for the US based one. And there was also the question of recruiting more editors, getting more people on board. So maybe we could start discussing an actual approach to that. How do we get people who join us and help us with that task? Maybe that would be interesting.\n\n**Frederic Johnson** - I agree. I think we have a meeting like that coming up with Maria on the side of the retrospective, every 10 meetings we have that, I think that's totally a good place to have that. If you want to try something regarding US time zones, what our propose is that we do something at 10:00 a.m. PST, which equates to, I think like 7:00 PM your time. So Maria and yourself, I think both of you are in the same time zone. If you're able to do a 7:00 PM meeting, that might be an option. But I don't know if we want to do that for the next one or for like 42 or something like that.\n\n**Matthias Benkort**  - I would like to try for the next one. Definitely. So next week have that up. That will work for me if it works for you also Maria, or I can try to take some notes on that.\n\n**Frederic Johnson** - Can we try the next biweekly one? So in two weeks, rather than one week.\n\n**Matthias Benkort**  - Oh, so you mean to move the next biweekly as a US based?\n\n**Frederic Johnson** - Yes. Just the next CIP meeting because those meetings are biweekly. So every two weeks, so the 40th right now is up on Tuesday. The next 41 will be in two weeks and it will be happening functionally at a US time zone slot.\n\n**Matthias Benkort**  - Yeah. Okay. Okay. I guess it's also maybe fine for even European time to be at 7:00, because I imagine if people are also not joining because they just have work to do at 10:00 AM and maybe it's more convenient to join at 7:00.\n\n**M. Àngels Jover**  - Maybe that's right.\n\n**Matthias Benkort**  - So maybe it's also all better for even European time zones.\n\n**Frederic Johnson** - Yeah. The only \n\n**M. Àngels Jover**  - Maybe we can test it and see how it goes.\n\n**Matthias Benkort**  - Yeah. Yeah. Test for a couple of weeks. So last time I asked on Twitter actually, a bunch of people, it was pretty much 60%, 40% that there was a lot of people I wanted to have meetings in the US time zone. So I was out of like 400 people. That's still a fair amount of four segments to join. I imagine I'm not sure how about the actually distribution. It's all the people that answer \"yes, we're actually in the US', or even if there were some European that were interested to have meetings at the US base time zones. But yeah, maybe let's try it, let's have the next one in, at 6:00 UTC. Right. And I don't know the time zone, like the UTC to be franc, but it much easier for me  to think just in UTC time. And that that would be...\n\n**M. Àngels Jover**  - The 15. Right?\n\n**Matthias Benkort**  - Yes.\n\n**Matthias Benkort**  - 6:00 pm UTC.\n\n**M. Àngels Jover**  - Do you want to do a wrap up of what we have for next meeting?\nSo we have PR 153 that you are going to do Matthias some github clean up and it will be ready to go and can be merged before next meeting. PR 160 also is ready to go and can be merged. Then for next meeting, we will have PR 148 for last check. And then we have a pretty busy review section. We will have PR 215, 208, and 200. And we are waiting for Rob answering 211 in order to identify phase one. If this is done, you are going to merge it asynchronously, right?\n\n**Matthias Benkort**  - Yep.\n\n**M. Àngels Jover**  - And we have on hold, all the collateral PRs that we want Sebastian to be commenting on them.\n\n**Matthias Benkort**  - Yeah. Work us through the changes. Correct. Okay. Thank you.\n\n**M. Àngels Jover**  - Perfect. Thank you very much.\n\n**Frederic Johnson** - All right. Thank you everyone.\n\n### Close\n\n\n => Merged as CIP15 (draft) [PR211 - Add reference implementation for CIP15](https://github.com/cardano-foundation/CIPs/pull/211) waiting for Rob answering 211 in order to identify phase one\n\n => Hold on [PR104 - CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104) put on hold and waiting for Sebastien to discuss it\n\n => Hold on [PR217- Collateral reward](https://github.com/cardano-foundation/CIPs/pull/217) put on hold and waiting for Sebastien to discuss it, possibly removed as duplicate\n\n => Merging it [PR153 - Fair min fees](https://github.com/cardano-foundation/CIPs/pull/153)  this PR has a weird git commit history so Matthias will clean up the history to keep only the last commit that is actually the change proposed by the PR (moving it to proposed) and proceed with merging it \n\n => Hold on [PR159 - CIP-31: Reference inputs](https://github.com/cardano-foundation/CIPs/pull/159) moved from draft to proposed\n\n => Merged [PR160 - CIP-32: Inline datums](https://github.com/cardano-foundation/CIPs/pull/160)\n\n => Hold on [PR148 - CIP-0030: update to api.signData()](https://github.com/cardano-foundation/CIPs/pull/148) moved to Last check for the next meeting\n\n => Hold on [PR216 - Collateral output](https://github.com/cardano-foundation/CIPs/pull/216) put on hold and waiting for Sebastien to discuss it\n\n => Hold on [PR200 - Add support for Catalyst multi-delegation](https://github.com/cardano-foundation/CIPs/pull/200) moved to next meeting for review\n\n=> Hold on [PR208 - CIP-0030 Adding getCollateral function to the connector API](https://github.com/cardano-foundation/CIPs/pull/208) moved to next meeting for review\n\n\n=> Hold on [PR209 - CIP-0030 Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209) moved to Review\n\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active |\n| 3 | [Wallet key generation](../CIP-0003/) | Active |\n| 4 | [Wallet Checksums](../CIP-0004/) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed |\n| 8 | [Message Signing](../CIP-0008/) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/) | Active |\n| 20 | [Transaction message/comment metadata](../CIP-0020/) | Active |\n| 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft |\n| 22 | [Pool operator verification](../CIP-0022/) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/) | Draft |\n| 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft |\n| 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft |\n| 28 | [Protocol Parameters (Alonzo)](../CIP-0028/) | Draft |\n| 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft |\n| 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft |\n| 33 | [Reference Scripts](../CIP-0033/) | Draft |\n| 34 | [Chain ID Registry](../CIP-0034/) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n"
  },
  {
    "path": "BiweeklyMeetings/2022-03-15.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [March 15 2022 Transcript](#march-15-2022-transcript )\n  * [Triage](#triage)\n    + [PR160 - PR160 - CIP-32: Inline datums](#pr160)\n  * [Last Check](#last-check)\n    + [PR148 - CIP-0030: update to api.signData() ](#pr148)    \n  * [Review](#review)\n    + [PR200 - Add support for Catalyst multi-delegation](#pr200)  \n    + [PR208- [CIP-0030] Adding getCollateral function to the connector API](#pr208)\n    + [PR209 - [CIP-0030] Adding optional networkId parameter to .enable](#pr209) \n    + [PR215 - CIP-35: Plutus Core Evolution](#pr215)    \n  * [Discussions](#discussions)\n    + [PR218 - CIP-42? | New plutus builtin: serialiseBuiltinData](#pr218)\n    + [PR222 - CIP-42? | New Plutus Core built-in dataHash](#pr222)\n    + [PR220 - CIP-43? | Plutus support for pairings over curve Bls12-381](#pr220)\n    + [CIP-45? | Decentralization: Using Pledge as a Bidding Param](#pr229) \n  * [Close](#close)\n\n## Summary\n\nRough transcript of 15/03/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Transcript might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/e/cip-editors-meeting-40) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n**Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n\n**Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n\n**New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \n\nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n**Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n\n**Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n\n## March 15 2022 Transcript \n**Attending Editors**: Matthias Benkort, ~Duncan Coutts~, ~Sebastien Guillemot~, Frederic Johnson, Robert Phair. \n\n### Triage \n\n#### PR211\n [PR211 - Add reference implementation for CIP15](https://github.com/cardano-foundation/CIPs/pull/211)\n\n**M. Àngels** - Hello. Welcome everyone to the CIP Editors meeting number 41. This is the first one that we are holding in the United State time zones. The idea is to hold those meetings bi-weekly, and we will do one in United States time zone, which is today. And in two weeks we are going to do it in European time, and we are going to alternate those meetings since now on. And well, my name is M. Àngels Jover and I work as project manager at the Cardano Foundation, and I am here to facilitate this meeting. At the top left, you can find the agenda for the meeting today, which I will share with you now. And today I have the pleasure to introduce you to our editors, which is Matthias Benkort, **Robert Phair** - and Frederic Johnson. Well, first of all, I would like to check with you editors, if there is any long lasting item that needs to be follow up and it's not on the agenda.\n\n**Robert Phair** - Checking now. Okay. You said the agenda is in the upper left?\n\nThe \"I\" button. I see. Yeah, there's an \"I\" by the main title. I just had a question, if there's a process for dealing with issues that get submitted against the CIP repository? Because I've never really known how to jump in with those.\n\n**Matthias** - Yeah, so. That's something we mentioned in the last meeting actually.\n\n\n**Robert Phair** - Right.\n\n**Matthias** - I was just noticing also that there are, quite many issues being created by people. So as for your question, no. We don't have any process with dues, so to speak. So, I think we should start including them on the CIP editors review maybe, or just, yeah. Start going through them asynchronously and try to resolve them.\n\n**Robert Phair** - Yeah.\n\n**Matthias** - So, some issues can be resolved pretty fast, right? Because they are about the updates on existing CIP or minor adjustments, and some are actually discussions. Proper discussions of people at thoughts, or seems to want to push up the CIP, but they not know necessarily in all the details yet so they stop with an issue, which I think is also fine. Some people do that on the forum as well. Not sure if we should favor one or the other way. But, let's maybe just start going through those we can address immediately and keep the other one for the CIP Editors Meetings.\n\n**Robert Phair** - Sure.\n\n**Robert Phair** - And I know that Kevin also posted a suggestion that they not use the next CIP number. I noticed a couple of them actually came in with the CIP as a flat file, rather than in a sub directory. So there were other types of naming conventions, not just for the files, but for the directories themselves. So, I was thinking that maybe a paragraph about that format could be added to the CIP one, or maybe the read me of the CIP repo itself. Just to tell people to put in a directory, to tell people to satisfy the naming convention of the CIP number in whatever way that we agree upon, but maybe another could be added to settle on those questions.\n\n**Matthias** - Yeah. I think we could even do with a small continuous integration check with that. If you submit a full request, it's got checked by editor scripts that make sure you've got the right format, but yeah. Adding it to the CIP one, definitely. We have also  CIP templates, which may be up to date, because it's also at the root of the repository. So, maybe having an example folder, which shows how CIP should be structured.\n\n**Robert Phair** - Okay.\n\n**Matthias** - I did some addition to the read me also last time. I got to discuss that a bit with Sebastian, but we didn't come up with an agreement so far. But this, I think should be more on the safety one, right. It really about a process itself and the CIP. \n\n**Robert Phair** - Mm-hmm (affirmative).\n\n**Matthias** - Mm-hmm (affirmative).\n\n**Robert Phair** - Sometimes the CIP drafts come in on the Cardinal forum first. So, it would be nice to be able to link to the section of that document, and just post it in the forum, so that people can go over the material, and edit it before they submit it as a PR.\n\n**Matthias** - Yeah. Yeah. So we can get a section easily if we just put a title. Then with the link we can refer to.\n\n**Robert Phair** - That would be perfect, yeah.\n\n**Matthias** - So also a quick reminder for anyone in the chat. If you have specific questions, also you want to ask, there is this ask question feature on chrome cast. Don't hesitate to use that. So, at the end or somewhere during the meeting, we can go over the questions that were asked. But, it's sometimes hard to see all the questions in the chats. So, exactly. Okay. \n\n### Last Check  \n\n#### PR160\n [PR160 - PR160 - CIP-32: Inline datums](https://github.com/cardano-foundation/CIPs/pull/160)\n\n**Matthias** - Should we start with the first item on the agenda CIP 32, tentatively? I think it is... It was just a last check, right? This one. Because we did review it last time and it was just making sure that there was no final questions on this one. It's also on... Yeah, Implementation I think has started, and has been planned for that one. So we should be able to move it to the other stages later on. But as a draft, it's also fine. Been discussed, reviewed, been through a few changes already. We're good to go. Yeah. Robert also commented already weeks ago, so they just merge it.\n\n#### PR148\n [PR148 - CIP-0030: update to api.signData() ](https://github.com/cardano-foundation/CIPs/pull/148)\n\n**M. Àngels** - Nice. So, in last set we have PR 148, an update to API signdata().\n\n**Matthias** - Yeah. So what's the latest status on that one? I did ask for Robert to update...\n\n**Frederic** - I think at the bottom of this one, there was a request to... never mind I'm actually looking into the 200 and 148. I think 148 was good to \ngo. The conversation has died down between Sebastian and one of the other editors on there.\n\n**Matthias** - Yeah. I cannot load it somehow. Okay, now it's good. It was a change of the address signed data. Yeah. Yeah. And there was also a bug discovered in the email edition that was fixed. So, I think that one is good to go for last check. There is a last comment from someone, but I actually don't get it. He's talking about adding a content type, arguments, or I could try to display the message being signed to the user. Generally speaking to display messages, to sign for users, it's a bit more complicated. Plus you need to have some comprehension of what the app is actually doing, the kind of scene. Which is probably something better left to wallet implementers and not put in the CIP itself, not putting the interface. If a wallet wants to show SundaeSwap or ADAhandle, or whatever that they're injecting with some specific details because they understand the problem, and how that is working, that's up to them. Probably a good marketing argument for wallets. So yeah, I would say we can move this one to last check from next round. There is no issue. It's already last check actually.\n\n**M. Àngels** - Yeah.\n\n**Matthias** - So that's why we already did that discussion last week, 2 weeks ago. So, okay, then what's the problem? There is CI failure. Because probably the headers is wrongly formatted or something like that. But did Rob changed actually? It didn't change the headers, so. But if I say what build fail, blah, blah, blah, cannot fit properly much of undefined. Ah, yeah. Okay. That's one of the thing we fixed two weeks ago, but the pull request hasn't changed since then. So, we need to revise it on later on the master and it should work. Okay. So, I can just do that and we can merge that one on the go, unless objections. Part, you follow these stories a bit or not much on your side maybe?\n\n**Matthias** - Robert, you still here? If you speak, you're muted.\n\n**Robert Phair** - Sorry. I was muted. OK.\n\n**Robert Phair** - I was wondering why nobody... I knew you were looking for something from me. Okay. Yeah, so following the stories on those... the technical issues are fine for me. I just...\n\n**Matthias** - Yeah.\n\n**Robert Phair** - Which one in particular were you talking about? Just so I'm sure.\n\n**Matthias** - Yeah. Just the CIP 30 addition for sign data. There was a few changes to the existing CIP 30, to make sure that you could sign arbitrary data, and that change also included a change on the address format, that you provide to the CIP 30. It used to be basically HEX encoded addresses in simple format. But now we just pass a vector 32 strings, which is more consistent with how addresses are usually manipulated on Cardano \n\n**Robert Phair** - I've been reading the comments, but they've been above my level. So, that's not my place to make any objections about it. That sounds good to me.\n\n**Matthias** - Okay. And then we'll just have maybe Sebastian to vote on that. But, I think he was also on the same page. Okay. So we'll just re base the pro request under most recent changes, which should fix the CI failures, have the checked class, and yeah. Keep going.\n\n**M. Àngels** - Good. So shall we move to the next one?\n\n**Robert Phair** - Yeah.\n\n### Review\n\n#### PR200\n [PR200 - Add support for Catalyst multi-delegation](https://github.com/cardano-foundation/CIPs/pull/200)\n\n**M. Àngels** - Okay. We have a pretty busy review section. So, first one is PR 200 Add support for Catalyst multi-delegation. I would like to ask you, before we deep dive in the details, if you could do a brief summary of what this PR is about.\n\n**Matthias** - Yeah, of course we can do that, as we often do. So yeah. This one, which is PR 200, it came after another report request, right, which was PR188. And so, 188 was updating and existing CIP, CIP 15 to add support for registering multiple keys, as part of the catalyst voting process. When discussing this first update, we thought that it would be better to have it as a separate CIP, which is an extension of the existing one. Because it was quite substantially modifying the existing CIP, which makes it basically a completely different one. That was more appropriate to make a separate, which Mark did. And yeah. So the spirit is really to say, enable people to register multiple CIP's, with their catalyst registration votes, such that behind the scene, that can enable multi delegation, and therefore multi votes within the catalyst process. Right. I think we have also Kevin here on chat. So you could definitely...\n\n**Frederic** - And at the same time, Robert just posted the notes for the meeting 40 that were merged. That was two weeks ago where we discussed this one briefly.\n\n**Matthias** - Yeah.\n\n**Frederic** - So, this pool request, I think has reached equilibrium. It just needs some extra derivation path that Kevin pushed in the comments. But, I think that Mark stop had the initial lot of this PR and is currently away. So, it's really a matter of either we merge this in without the path as draft for right now, or we wait for Mark to come back, and adjust it, and then we move it back to review. I don't know how you want to proceed on this.\n\n**Matthias** - Yeah, we can probably also do the change, and add the change to it. Ask Mark for a review agreement. I think there was also a question of mentioning the original author of the PA, the update. Not sure if it was done, but I remember that from our last discussion, to just give credit to the original submitter, who was, who? Yang. Yeah. So, that there is no conflict. That everyone gets credited for their work, in this little other addition. And then, yeah. So, we could maybe do that. Flag maybe Mark for a second review, and then get it merged as a draft.\n\nI've understood that this is being also worked on in parallel, in terms of implementation. Yeah, of course, Kevin. That's what I'm saying. There was this... Yeah. Rewriting the history to include Giacomo commit. I still have it on my tool to do here. It's a suggestion [inaudible 00:15:30] want team? Yes, indeed. And in terms of implementation, was anything I started on that could also help us move the CIP into maybe proposed at some point, there is a clear implementation path? The question for Kevin.\n\n**M. Àngels** - Do you want me to bring him on stage so you can have a conversation?\n\n**Matthias** - No, maybe not. I think we've said it all. I'm just giving you one to come and say something.\n\n**M. Àngels** - Okay. So to summarize it, we are going to flag Mark for him to review, and if it's okay for him, it is going to get merged, right?\n\n**Matthias** - Yeah, we'll put it as Last Check for next time. And yeah, next time merge it if there is indeed nothing also surfacing.\n\n**M. Àngels** - Good.\n\n**Matthias** - Yeah. So I will add the change actually to the CIP itself, these little comments, and then ping Mark about it to make sure that he is also in agreement with that change, which is more of an addition than an actual modification. It shouldn't be any problem.\n\n**M. Àngels** - Good. So if Mark agrees, I can put this on last check next meeting?\n\n**Matthias** - Yeah, definitely.\n\n#### PR208\n [PR208- CIP-0030 Adding getCollateral function to the connector API](https://github.com/cardano-foundation/CIPs/pull/208)\n\n**M. Àngels** - Good. So let's go to PR208- [CIP-0030] Adding getCollateral function to the connector API. Would you explain us, Matthias, what is this about?\n\n**Matthias** - This is another extension of the CIP30, which is the adapt connector that is providing this interface between wallets and DApps. And this is about adding a function to get, or ask the wallet for a collaterall. Collateral is something that was introduced with the Alonzo Hardfork, which is necessary every time you want a transaction to execute a script. So the collateral has some special hold, right? It's an input of the transaction that is only spent and consumed if the transaction is failing during the script execution, which normally doesn't happen because you have plenty of ways to find if the transaction is correct before submitting it. But still, you have to put a collateral on that. And that collaterall is a special input because it must not be a script input, it must be ADA only. So that means for that it's quite practical to have way to just ask the wallet for such an input.\n\nSay \"Don't give me any EUTXO, but give me a EUTXO that satisfies all the collaterall preconditions.\" So yeah, that's extending the CIP30 in that way. Which, the CIP30 was treated before Alonzo. So it doesn't contain a lot of the details or the function necessary for actual DApps integration. And this is one of the few one that we'll get in. With a simple addition, semi-function, you get it as it's shown here in the mounts. And once you get back, it there is a EUTXO it's a satisfying condition. Or nothing there is no EUTXO that will satisfy this condition.\n\n**Frederic** - So if you check the conversation on this one, you can see that this is actually the one that I was discussing earlier when we had that conversation with Sebastian, and they seem to have [inaudible 00:19:13] that agreement on the work on this. So it seems as though it's ready to move forward.\n\n**Matthias** - Yeah, there is also a good comment from came in on the chats. CIP30 is at the center of many, many things at the moment, many, many decisions and changes. There is this notion of versioning on CIP30. So in principle, every new changes should come up with a new version number change, so that DAPP's and wallets can properly negotiate between each other which version of that CIP they already are using. And not quite enforcing that at the total level yet. Maybe we should start doing that a bit more, doing that structure a bit during the evolution of the CIP.\n[crosstalk 00:20:04] with addition of other things, of course, addendum to existing CIP. It's a bit like we've done for the wallet things.\n\n**Frederic** - So functionally, or structurally it makes sense to move this into a new CIP as a whole. Like for example, CIP37 and then have that one supplant CIP30.\n\n**Matthias** - That's not really supplanting, right? Because it's just an addition. So everything in CIP30 will still apply, but then you have this extension that you may or not support as a wallet. But from the usability perspective, if you are a DAPP integrating your wallets, you don't necessarily want to have a list of all the things either wallet supports, but more like a version number. Actually, a list may also be relevant because a wallet might support this and this as features, but not these wallet features. And a version number would suggest a kind of sequentiality of CIPs, which may not be the case. So yeah, all that to say, perhaps better move to support CIP, have that as an addendum that refers to CIP30 and... Have the wallet then, let's be that integrating what kind of CIP's they support as extensions. That in itself would be a change to CIP30 also. I'd like to propose that.\n\n**Frederic** - So the changes you propose is that we move this one as a standalone CIP being an addendum referring? I'd be okay with moving this into Last Check as is.\n\n**Matthias** - Yeah, moving it as a last check, but also making it a separate CIP indeed. Just try not to overload too much the CIP30, but start \nintegrating new changes to that CIP as new CIP's, the same way we sort of removed at the time this [Evant API 00:22:05] and put it out of scope on the CIP13's, and we move that to a separate proposal. Do the same thing here for that one, and I think also having a new function as part of the CIP30 interface, for wallets to return all the CIP they do support, like all the extension they do support. So for DAPP integrating with the wallets, they can just ask the wallet for that information and know if this or this feature is available. Although I guess it's also part of the wallet documentation maybe. If you're integrating with this or this wallet, you should know if they support the feature. But it makes it a bit more automated in that sense, so... Yeah.\n\n**M. Àngels** - So the idea is to move this to Last Check for the next meeting, but as a new separate thing, as an addendum to CIP30. Is that right?\n\n**Matthias** - Correct, correct. Next one-\n\n**Robert Phair** - I think this also, just before we move onto the next one please, I think this also resolves a longstanding question we had about CIP13, where there were one or two suggestions to add something to the Cardano URI scheme last year. That just kind of lost some momentum because the people who submitted those PR's didn't drive them. But ?? and I were talking about how to handle a document that might actually get a lot of additions to it. So in the future, maybe if those issues come up again, I would suggest that they be dealt with in the same way. If someone wants to add something new to the URI scheme for instance, they could submit a new CIP rather than a modification to CIP13. If that's okay with everyone.\n\n**Matthias** - Yeah definitely. Yeah, I agree with the original idea.\n\n**Robert Phair** - Sure.\n\n**M. Àngels** - And how, maybe that's a stupid question, but how we can let the creators of the PR know that they need to create a new CIP instead?\n\n**Matthias** - We'll comment-\n\n**Matthias** - We'll comment on the workplace. And in that case, the creator is Sebastian. We'll just ping him directly.\n\n#### PR209\n [PR209 - [CIP-0030] Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209)\n\n**M. Àngels** - Yup. Okay, PR209 - [CIP-0030] Adding optional networkId parameter to .enable\n\n**Matthias** - So that's also modification to the CIP, but this one is an actual modification which could go as an update as CIP30. It's small enough and it's modifying one of the existing functions. Okay, so this is about inquiring to enable only a specific network. Through the wallets? I would be curious to know the rationale behind that. It allows the DAPP to specify which network it operates on, so the wallet forces the user to only connect to wallet accounts on that network. Example, that [inaudible 00:25:18]. If not specified, the user is free to select any network, and the DAP must be able to handle it then. Okay. That kind of makes sense as it is, with this. Sebastian says \"I would prefer if we instead used CIP-34 instead of just passing in a network ID otherwise this will cause issues if Cardano ever has >16 network IDs reserved (which is entirely possible in the future). Probably that should be done in parallel to deprecating the getNetworkId and replacing it with something that returns the CIP34 string\" Yeah.\n\nCIP34 was a CIP proposed by Sebastian to have a uniform chain ID that is uniform across block chains. So there is a standout which is used on Bitcoin, Ethereum, I think Solana as well, which specifies a certain format that identify a network across over to the possible blockchains. So Sebastian, \"We're applying to one that would work for Cardano, which envelops both the network ID, the genesis hash, network advantage, and that could be used instead of just zero, one, two, three and blinds integers as a means to specify the network.\" Which I do agree. That makes also a lot of sense. So... Yeah. I will comment on the progress exactly with that. And then we can go back to reviewing it again next week, if we have any update from the others from last time.\n\n**M. Àngels** - So we are going to review it again next week and get feedback.\n\n#### PR215\n [PR215 - CIP-35: Plutus Core Evolution](https://github.com/cardano-foundation/CIPs/pull/215)\n\n**Matthias** - Yeah. That's the one proposed by Michael about... Giving a [inaudible 00:27:33] process to, yeah, propose changes to Plutus. Right? So it's a bit of like a process on top of the CIP's, which specify all the different steps people will have to go through to get something implemented inside Plutus, which is a very interesting proposition by itself. It would be nice to come up with something like that for the ledger, or the consensus, or every part of Cardano, basically, and to have a clear path of how you can get an ID from a CIP in proposition, into actually being implemented into protocol by the team. So Michael gives a full process for that, which is very sensible in my opinion, that we have also been following in the proposal already, but having two proposals on top of that. On top of that, currently under discussion process. But the general idea is to say, well, you make a CIP, that explains good rationale, explains what you are going to change, and I've come also with proof in a way that what you are doing is correct. So they don't necessarily ask for people for doing the implementation, but at least you have a rationale and an idea of what will be the impact on Plutus.\n\nFor instance, if you claim you want to add a new built-in, then you should come up with a cost model of that built-in and explain why it works, or what would be the impact on the loan implementation and so forth. So that way the team doesn't have to do all that work, and can basically just verify that and then go on with the discussion right away. So it has also divided the different changes in multiple categories, explaining whether the changes would require a new Plutus version, a version of the language, or a hardfork, or if the changes can just be done in a fast forward way because they are just backward compatible. So it's pretty complete in terms of information, I think. So, yeah.\n\n**M. Àngels** - So do we want to do it with this one?\n\n**Matthias** - That's a good question. I mean, it's been already used kind of, by at least two other CIP's as a baseline for proposing changes. There hasn't been any comment on that one, which suggests that no one was in disagreement with the process. I think it's fairly well explained. So yeah, I will be all for moving into Last Check next time. But as far as I'm concerned, the process is clear. The CIP check all the boxes. And yeah, it is not a CIP that would require an implementation, because it's just describing a process. So I would even actually move it as active right away; the rationale being that it's pushed by one of the co-member of the Plutus team. And therefore, we have the implicit agreement that the team is also already okay with that CIP as a process for driving the Plutus implementation. What do you think about that, Fred? \n\n**Frederic** - I think moving it to Last Check and the push to active is fair. I mean, there being the but it sounds like if Michael's behind the PR, it kind of invites it, pretty much.\n\n**Matthias** - Yeah, exactly.\n\n**Frederic** - And Last Check for next meeting. So then Sebastian is going to be able to jump in and do a certain look-through.\n\n**Matthias** - Yeah.\n\n**M. Àngels** - Good. So that was what we had in our agenda.\n\n**Frederic** - Uh, going back on this one is a minor conflict regarding CIP numbering but that might be... Which is that we have some conflict going on with the numbering. But 35 has been taken over and a few people are complaining that the allocation of number directly to the next available number is difficult so I suggest we just move this one as steady and request the other one which has whichever next number that is [inaudible 00:32:33].\n\n**M. Àngels** - I don't know the other people but Fred I just lost the half of what you were talking, So, I understood the conflict with... To move and the number 35 and then you wanted to push another PR to another number. And this is what I didn't get.\n\n**Frederic** - Yeah.\n\n**Frederic** - You should go in the conversation for CIP 35 pull request 215, and scroll down to the bottom. There should be a link that CIP identifier is crashing with PR 137.\n\n**Frederic** - And yeah, Michael just commented on this and, editors are responsible for taking numbers. In this case we have to move the other one.\n\n**Matthias** - Which goes back to pull requests I was mentioning this week. Well, I have taken a read me and try to guess basically the, a table of proposals under review. Follow the read me, with preallocation of those CIP numbers. Which should give us a bit of organizational. That means we would have to maintain that table, which I think is fine. We don't have to maintain it more often than once every two weeks. So every meeting we could go over this. Proposals under review, make a little update so that we meet you... To get them.\n\n**Matthias** - Side benefits we also get from that is, that table becomes part of the read me, which is the front page of the CIP site. Which means that it gets easier for people to browse through a distant CIP without having to go through the pages of full requests. It's a bit more comprehensible so review CIPs under discussions and get maybe more people to contribute.\n\n**Matthias** - And in that case, the  Plutus  core  evolution, I've already pre-located that one the number 45. And I think other one, request number 15, I moved it as another unused number. So...\n\n**M. Àngels** - So, it should be good right?\n\n**Matthias** - Be good. Yeah.\n\n**Frederic** - On that, I do think that this adds significant overhead but I don't know if it's really necessary but it sounds as though this deal it is. So, very open to that conversation.\n\n**Matthias** - It does have a bit over our heads. And that's also Sebastian's concern when I discussed the PR within. I don't mind maintaining that list. And as I said, I don't think it has to be more often than every two weeks. It's not as... It's not a big cost overhead anyway. It is PR number 227, which I put in the chats. Right, so Robert already chipped on it. Think we're also in agreements.\n\n**Matthias** - [Foreign language] changes. Sorry for my French. And feel free Robert to push any of these if you want.\n\n**Matthias** -You should have the right access on this pull request I haven’ t forbidden people to add comments on top.\n\n**Matthias** - So yeah, if you can look at the file changes this so you can have it on... Maybe.\n\n**M. Àngels** - Where?\n\n**Matthias** - Just a small, small explanation of what exactly the CIP process is, otherwise we will have confusions. And so put this little table proposals on reviews, which clearly explains that these proposals are being discussed but they are also for pre allocating the numbers. And I also added the editor lists from that file because I got the question several times from people who wanted to reach out to the author and they did not easily know that they had to look into CIP 1 to find the lists. So, I put it back in. It should be... So now, yeah. With that, we should have all this information regularly available on the website front page.\n\n**Robert Phair** - I have just one question about the naming issue. Sorry if this is already covered in one of the meetings I wasn't at but... Because I did try to read all of this stuff. Is there a reason why people need to choose CIP numbers when they submit their original PR or could they just have CIP dash some name that's their content for CIP.\n\n**Matthias** - No, no, that's the point. They shouldn't have to pick a number and the editor should do it.\n\n**Robert Phair** - Okay. Okay.\n\n**Matthias** - And that is just a way for us to get organized with that. And just advertise it, on the front page.\n\n**Robert Phair** - Right. So the naming collision is only then because people thought they had to pick a number? Even though they were never told to-\n\n**Matthias** - .. Yeah.\n\n**Robert Phair** - ... [inaudible 00:37:44] page. Got it.\n\n**Matthias** - So that could be a probably little addition to CIP 1, where I mentioned earlier. We also explain the process of submitting the CIP so you don't have to pick a number you just put XX or dash dash. The offer will put something, the editor will come up with something.\n\n**Robert Phair** - Yeah, that's just what I was hoping for, thanks.\n\n**Matthias** - [00:38:10] Okay. So Fred if you are okay also with that little change, we can get a little bit more organized on the number allocation, which also answers Kevin's concerns from earlier. I hope Kevin. And so yeah, CIP 35 currently, the Plutus core changes, I think it can stay as CIP 35 and as we say move to last check for next rounds and move everything to active. It's proposed by the co-team so there is no reason to, yeah. Just put it as draft proposals.\n\n**M. Àngels** - Okay we are talking about PR 215 Plutus Core Evolution, right? To move it directly to active.\n\n**Matthias** - Yeah, yeah. You can tell Michael to put this little change or just push it ourselves. And move it to last check meeting so that we have the ability to just have Sebastian also chip on it and tell us if he's against or voice concerns but I don't think that would be the case. And good. And then we can only encourage the other teams to do the same. So that we can move forward with other co-changes as well.\n\n### Discussions\n\n**M. Àngels** - So this was all for today that was planned? Do you want to review some specific PR? Maybe some, all of them?\n\n**Matthias** -  No. I haven't got a lot of time to look at the PR recently. There a few new ones but... Not something we will do right now probably. Unless someone someone has something to bring in as well. Or, sell as built in data said Sebastian. So, yeah, that's one of the PR 215 which is based on the Plutus Core  changes proposal. I would maybe keep it for next time, this one. In the next meeting, so that once we have the Plutus Core Changes validated we can start looking at the proposals on top. And we can get quick review as well from, for it right now. Yeah, if you want to bring it on screen.\n\n**Matthias** -Probably PR218.\n\n**M. Àngels** -[00:40:52] Fred, you were saying that you need to drop?\n\n**Frederic** - Oh, no I thought that you wanted to bring in Sebastian on screen and was proposing to drop. But, if you really don't recommend about them.\n\n**M. Àngels** -[crosstalk 00:41:07] Is here?\n\n**Frederic** - Sebastian Michael.\n\n**M. Àngels** - Oh, okay.\n\n**Matthias** - If [inaudible 00:41:15] speak.\n\n**M. Àngels** - So, Sebastian do you want to speak?\n\n\n#### PR218\n [PR218 - CIP-42? | New plutus builtin: serialiseBuiltinData](https://github.com/cardano-foundation/CIPs/pull/218)\n\n**Matthias** - Not sure, just showing. So I can also cover this CIP, we co-wrote this with Sebastian, pretty much no worries about that. ll basically, speed up a few things we have as part of the Hydra development. If you built any functions that we can use from within and on on-chain scripts and the goal of A is to be able to sell some data into some binary digests so that you can use that as a pre-image for hashing on-chain. We currently only have on-chain built in for hashing stuff but I suppose you can produce some binary data that you can hash and this process is exactly about that. It's adding a built-in to produce some serialization of any data type in plutus. We've been discussing that with the team as well. The implementation actually has already started on this [inaudible 00:42:34] so we should know quite soon if it's actually working okay in terms of performances and what will be the cost model for that addition.\n\nAnd yeah, so the proposal was based on this CIP 35 following the different Plutus steps. And yeah, that's about it. So I guess depending on the outcome of the implementation of what's going on, on the Plutus call, we can probably also move that CIP right into active. Because if it's already getting implemented it gets done, it gets validated then there is... We will have proof it has been active. According to CIP 35 again.\n\n**M. Àngels** - So... in order to move it to active right now we have... I mean there's a lot of discussion even though this is new.\n\n**Matthias** - Yeah, I'm not moving to active right now. But depending on the outcome of the Plutus Implementation which is still ongoing. So for now, I'm simply moving it to review for the next meeting.\n\n**M. Àngels** - Okay.\n\n\n#### PR222\n [PR222 - CIP-42? | New Plutus Core built-in dataHash](https://github.com/cardano-foundation/CIPs/pull/222)\n \n\n**Matthias** - And at that time we will reassess what's the status. I just wanted to give a little status update on that one. Knowing that there is a conflicting proposal in a few months that was opened also right after. I think, yeah, which is PR 222. Which is also adding a new built in. But this one instead of providing a built-in to seriesalize any data, it's a built-in to directly compute the hash of any data. So it's all bundled together, the sale-ization and the hashing with the rationale that in most cases that's what people want to do. If you want to sale-ize on chain, this is for computing the hash, which is where I think we disagree.\n\n**Matthias** -  That means, both proposals can also live side by side and it will be up to the Plutus team I guess, to decide on which one that gets implemented eventually, if any of the two gets implemented.\n\n**M. Àngels** - Because it's one... That they are conflicting within each other.\n\n**Matthias** - They are competing with each other because they are targeting, overlapping in terms of the features they provide. One is a bit more generic to the previous one, and this one is really tailored to a particular use case of computing the hash on-chain right away, which according to the author is arguably what's treat will always want to do. So yeah, there is slight disagreement I guess on this always. And yeah, so they will be competing in the sense that they can both be proposed as two Plutus core -evolutions and then following the process describing CIP 45, one will get implemented into Plutus, the other one probably not. But there is no problem having two overlapping built-in as part of the language, so I think the team will just choose one of them. And then we will be able to just either make one of the CIPs obsolete or if things happen before that just deprecate the complete CIP and not even propose it as draft.\n\nSo we can move it to review for next meeting I think so that we have both and can compare and reassess the situation. And since we will also be in European time zone we will probably have Michael, someone from the Plutus team to chip in.\n\n**M. Àngels** - I think that makes sense to always review these two PR's together.\n\n**Matthias** - Yeah, definitely.\n\n#### PR220\n [CIP-43? | Plutus support for pairings over curve Bls12-381](https://github.com/cardano-foundation/CIPs/pull/220)\n\n**Matthias** -\nAnd since we are in CIP and Plutus changes, we could also look at CIP, what's the number? Sorry, PR 220, which is also about extending Plutus our co-changes. But this one with a new cryptographic primitives. This one was submitted by Migo, who is a cryptographer working at Input-Output, and he is proposing a new pairing mechanism on-chain, which is a full request for which we don't require some cryptographic expertise, which I don't think we have amongst editors. So we would have to find the right people for that one. So what had been discussed today it's... with people from [inaudible 00:47:39] I believe?\n\nAnd Michael I also see end dates. So, I think what makes sense to have this one for next meeting as well as the review. And make sure we have someone with the big cryptographic expertise that can go through the changes although Iñigo is already probably that person.\n\n**M. Àngels** - Are you going to reach them, Matthias, or do you want me to try to reach someone?\n\n**Matthias** - I'll try to see if we can find someone from DCSpark who might have people there that can help, just to have at least two cryptographers discussing on this matter. That would be interesting.\n\n**M. Àngels** - Okay. So let's move this to review for the next meeting, and maybe I will chat with you if you have the necessary expertise, or then we can wait until we have those expertise in order to review it. We have 10 minutes left.\n\n**Matthias** - Anyone from the chat? We had a question already which I answered on the fly.\n\n#### PR229\n [CIP-45? | Decentralization: Using Pledge as a Bidding Param](https://github.com/cardano-foundation/CIPs/pull/229)\n\n\n**Robert Phair** - I have one thing regarding the question of whether a CIP affects a mathematical or protocol design issue. We had another PR, 229 decentralization using pledge as a bidding form. This is a walk in from a mathematically oriented fellow. There's a CIP with a lot of equations. And honestly, I don't know if any of the editors would be able to address this. Is there a way to officially request that we get someone else to look at the CIP based on merit, or is this beyond the scope of what we're trying to do? Just lodge the CIP and then have it represent some kind of a standard that's independent of a mathematical evaluation. \n\n**Matthias** - So on these matters we try to get experts to chip in. Exactly what I was saying also with the cryptographic proposal, when we don't have \nthe expertise within ourselves at editors, we fetch for help and people that can help us. That's been the case of few other CIPs in the past. First thing I can think of is CIP seven for the [inaudible 00:50:36] benefits proposal, where we reach out for researchers to have actually buy in the CIP or to be able to chip in on that. There is no formal process with that. This is something we've been discussing internally at Input Output, really trying to get this into a formal process. It's sometimes a bit hard to move the researchers also from what they are doing to this. But it usually requires to load back a lot of context regarding global laws and the game theory and all that.\n\nSo the researchers are aware. From what I've understood, they have also started to work a bit on some of the CIPs. They don't have yet the time to put up a formal answer to a lot of them. Hope it'll come soon. And really I'm trying to get things in there to get things moving a bit. It takes time, but we'll eventually get there, I hope.\n\nAnd comment also with the process, that's what I was saying earlier. I wish maybe more teams would engage the same way the Plutus team has engaged with the CIP process, defining their own process to drive those changes. For other things, for instance, at Plutus, we don't have also the expertise necessarily to know whether a change is sound or not. If you are changing a part of the compiler or something that really involves deep language theory, there is no way we can review that fully as editors. So we'll always have to get back to the Plutus team and reach out to them and have their expertise on the matter, which is why Michael came up with this process. That's a way for them to explain how we can reach out. I want to have the same thing for basically every single part of Cardano, have that for the consensus, have that for the ledger, have that networking. That's something that takes a bit of time to set up. Hopefully we will get there.\n\n**Robert Phair** - What I did in this last case is invite the presenter to attend the meeting and see if he could say a bit about it and help us understand what it is he's getting at. And then maybe we can determine whether his ideas are presented properly enough to be evaluated at some future time.\n\n**Matthias** - As a editors, that's pretty much all we can do when we lack the expertise necessary to judge the actual content, but we can at least see if there are proper rational motivations, steps that explains what's happening, which is for instance, the case for Iñigo's proposal. From an editors perspective, it looks okay, but I'm not able to judge whether there is a sufficient amount of details that will allow another cryptographers to review it. Sean is saying it would be great to have a feedback process for parameter changes CIP.\n\n We're getting to the hour almost.\n\n**M. Àngels** - Would you like to do a quick wrap up of what you have reviewed, or do you want to…\n\n### Close\n\n**Matthias** - Indeed, we did this last week and people appreciated that. We should do it more often. So we went through a few proposals this week. First one was in line. That one we agreed on and actually merged, so it's finally merged in the repo as a draft CIP. The implementation is ongoing, so we should be able eventually to move it to active.\n\n**Matthias** - Then we went through the CIP 30 addition, which is design data that was there already as a draft. And the CIP was adding a few specificities to it. It was clarifying a bit of documentation. We agreed also that it was fine, but the pull request was made a long time ago, and the repository checks are failing. So we first need to update this pull request to the latest changes, and it should be able also to be merged, which I will do after the call. \n\nThen we reviewed a few CIPs. So the first one was the PR 200, which adds the multi delegation support to catalyst, which should then allow to better split the voting on the Catalyst process. The limitation is also going on in parallel. The CIP has mostly settled. We agreed to move it to last check for the next meeting.\n\nThen we went through CIP 30 addition, adding a collateral function to the connector API to allow that to update itself. But we said to move it as a separate safety and to do that for pretty much any new addition to the CIP 30 to avoid loading too much to the CIP. So we'll go back and ask the author to do that. We should be able to move it to last check for the next meeting.\n\nThen we had another little update on CIP 30, which is proposing to add an optional argument to one of the existing functions. This one will also go back to the author to change perhaps the interface that is being chosen to avoid just using integers, have something a bit more structured and typed if they can. And finally the last one, we went and reviewed CIP 35 about defining a process for proposing changes to Plutus Core, which has been proposed by the Plutus team. Process has been already out for two weeks. There are already three CIPs that are based on these processes. So we agreed to move it to also last check for the next meeting and have it as an...\n\n**M. Àngels** - For review we are moving and the 218 and 222 that are on top of this review, right by that.\n\n**Matthias** - So all the changes based on this one will be moved to review for next week, but CIP 30 will have it as last check and merge as active right away since it's defining the process, and it's already backed by the core team, which makes it a good proof for activity. And we also discussed modifying the ReadMe, to get a list of pending CIP under review on the front page of the website also, and I have pre-allocated numbers to all existing CIP so we can get better organized within the number location. And that's the last, or did I forget something?\n\n**M. Àngels** - PR 220, which we will need cryptographer expertise that we are going to try to get.\n\n**Matthias** - So that's part of the Plutus score changes we'll review next week. And we'll try to get the help of a cryptographer on that one. I think Iñiigo, we would definitely be able to ask him if he can already join, maybe to work us through the proposal and have maybe someone, if not in the meeting itself, to at least be able to comment on the proposal itself.\n\n**M. Àngels** - Next meeting is going to be in the Europe time. So I was wondering if we should bring to the agenda all those collateral PRs that we were waiting for Sebastian to review.\n\n**Matthias** - That's a good idea.\n\n**M. Àngels** - So if you don't have anything else to add, it's the time already. Thank you very much everyone.\n\n**Matthias** - Thank you.\n\n**M. Àngels** - It's been lovely meeting, and we'll see you in two weeks in European time 10:30 a.m. CET. Thank you very much, and have a nice week.\n\n---\n## Extra\n\n### Current CIPs in the CIP repository and their status\n\n| #                 | Title                                                                                                                                         | Status                |\n| ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |\n| 1 | [CIP process](../CIP-0001/) | Active |\n| 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active |\n| 3 | [Wallet key generation](../CIP-0003/) | Active |\n| 4 | [Wallet Checksums](../CIP-0004/) | Draft |\n| 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft |\n| 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft |\n| 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed |\n| 8 | [Message Signing](../CIP-0008/) | Draft |\n| 9 | [Protocol Parameters](../CIP-0009/) | Draft |\n| 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft |\n| 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft |\n| 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft |\n| 13 | [Cardano URI Scheme](../CIP-0013/) | Draft |\n| 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft |\n| 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft |\n| 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft |\n| 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active |\n| 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft |\n| 19 | [Cardano Addresses](../CIP-0019/) | Active |\n| 20 | [Transaction message/comment metadata](../CIP-0020/) | Active |\n| 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft |\n| 22 | [Pool operator verification](../CIP-0022/) | Active |\n| 23 | [Fair Min Fees](../CIP-0023/) | Draft |\n| 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft |\n| 25 | [NFT Metadata Standard](../CIP-0025/) | Draft |\n| 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft |\n| 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft |\n| 28 | [Protocol Parameters (Alonzo)](../CIP-0028/) | Draft |\n| 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft |\n| 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft |\n| 33 | [Reference Scripts](../CIP-0033/) | Draft |\n| 34 | [Chain ID Registry](../CIP-0034/) | Draft |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft |\n| 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft |\n| 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | Draft |\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n"
  },
  {
    "path": "BiweeklyMeetings/2022-04-05.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n\n- [Editors Meeting Flow](#editors-meeting-flow)\n\n- [April 05 2022 Transcript](#april-05-2022-transcript )\n\n  * [Triage](#triage)\n\n    + [PR217- Collateral reward](#pr217)\n\n    + [PR104 - CIP-1856 | Collateral Key derivation](#pr217)\n\n  * [Last Check](#last-check)\n\n    + [PR200 - Add support for Catalyst multi-delegation](#pr200)  \n\n    + [PR208- [CIP-0030] Adding getCollateral function to the connector API](#pr208)\n\n    + [PR215 - CIP-35: Plutus Core Evolution](#pr215)       \n\n  * [Review](#review)\n\n    + [PR209 - [CIP-0030] Adding optional networkId parameter to .enable](#pr209)\n\n    + [PR218 - CIP-42? | New plutus builtin: serialiseBuiltinData](#pr218)\n\n    + [PR222 - CIP-42? | New Plutus Core built-in dataHash](#pr222)\n\n    + [PR220 - CIP-43? | Plutus support for pairings over curve Bls12-381](#pr220) \n\n    + [PR216 - CIP-40? | Collateral output](#pr216)    \n\n  * [Discussions](#discussions)\n\n    + [CIP-47? | Proposal for open Daedalus or desktop wallet via URL](#pr234)\n\n  * [Close](#close)\n\n\n\n\n## Summary\n\n\n\n\nRough transcript of 05/04/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n\n<sub>_Transcript might contain errors or miss pieces - call out issues as needed_\n\n</sub>  \n\nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/e/cip-editors-meeting-42/3) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n\n\n\n\n\n## Editors Meeting Flow\n\n\n\n\n**Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n\n\n\n\n**Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n\n\n\n\n**New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \n\n\n\n\nPR -> ‘Draft’: Needs format + approval.  \n\n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n\n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n\n**Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n\n\n\n\n**Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n\n\n\n\n\n\n## April 05 2022 Transcript \n\n**Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, ~Frederic Johnson~, ~Robert Phair~. \n\n\n\n\nPR209 - [CIP-0030] Adding optional networkId parameter to .enable.\n\n\n\n\n**Sebastian Guillemot** - PR209 - [CIP-0030] Adding optional networkId parameter to .enable. function for the DApp connector specification. I disagree with the way the CIP is done. I don't think it's a good idea and Matthias agrees with me and there's been no response. So I feel like we're stuck on this waiting for a response.\n\n\n\n\n**Sebastian Guillemot** - Next is... Does anybody have any comments about CIP-30 before we move on? Because I think we're just blocked on a response for this one.\n\n\n\n\n### PR234\n\n[CIP-47? | Proposal for open Daedalus or desktop wallet via URL](https://github.com/cardano-foundation/CIPs/pull/234)\n\n\n\n\n**Sebastian Guillemot** - All right, hearing none, moving on. CIP-47? | Proposal for open Daedalus or desktop wallet via URL Triage is to basically add DApp connector to Daedalus by taking advantage of the URI scheme. To be honest, I'm not super convinced this even needs to be a CIP because the way they want to do it is very much Daedalus-specific and I'm not sure there's a way for them to not do Daedalus-specific, which is my main concern. The reason why is because for the web Cardano stuff, this works, they can use this, but Daedalus only supports a single network per installation Daedalus, and so they want to introduce a new web Cardano test net, and then they have multiple implementations of Daedalus. They want to have like a web Cardano flight for test modes. So this is kind of awkward because this won't really work with other wallets well, and it won't work with DApps well either.\n\n\n\n\n**Matthias Benkort** - It's kind of weird to have a Daedalus-specific CIP in a way.\n\n\n\n\n**Sebastian Guillemot** - Yeah.\n\n\n\n\n**Matthias Benkort** - The point of having a CIP would be to, well, have cost compatibility or interop between wallets. So if it is something Daedalus-specific, then [crosstalk 00:01:56].\n\n\n\n\n**Sebastian Guillemot** - What they can standardize is this extension to the web Cardano stuff.\n\n\n\n\n**Matthias Benkort** - Yeah.\n\n\n\n\n**Sebastian Guillemot** - And then as a side note, they can say, \"Oh, and by the way, Daedalus has this Daedalus-specific stuff in case you care.\" The CIP as is feels like it doesn't add any functionality. It just specifies some Daedalus-specific considerations, which doesn't need to be done as a CIP.\n\n\n\n\n**Matthias Benkort** - Yeah.\n\n\n\n\n**Sebastian Guillemot** - So this is my main concern [crosstalk 00:02:26].\n\n\n\n\n**Matthias Benkort** - I haven't been through comments, but maybe this is something you've already suggested, or we can make it clearer maybe to suggest as a top-level comments. That the idea in itself of extending the URI scheme to include other parts makes sense, and maybe that's something that could go as a CIP, explaining how to extend it and why would be the extension. But then that's... Well, documenting the Daedalus-specific extension is probably not the right place to do it here, unless this is done in the form of a sort of global registry that also can be used by other wallets for other stuff. But yeah, if it's Daedalus-specific, that doesn't make much sense.\n\n\n\n\n**Sebastian Guillemot** - Yeah. I've had some discussion with this and we're kind of at an impasse on this one. I'm not sure what they want do about it. I'll try and summarize my comments again and try and move on this.\n\n\n\n\n**Matthias Benkort** - Okay. We had this one on the agenda anyway, so we can maybe put it as triage for next time or simply comment on it and…\n\n\n\n\n**Sebastian Guillemot** - Anybody else here have comments on this? I'm not sure if anybody from the Daedalus team is here.\n\n\n\n\n**Matthias Benkort** - I think Daniel is here, who is the author of the CIP. I'm not sure if he's listening or hearing anything. \n\n\n\n\n**Sebastian Guillemot** - Yes. He is. He's here.\n\n\n\n\n**Matthias Benkort** - People had problems with sound.\n\n\n\n\n**Sebastian Guillemot** - How do you invite people up to speak?\n\n\n\n\n**Matthias Benkort** - We cannot. Only the host can.\n\n\n\n\n**Sebastian Guillemot** - Yeah, you're right.\n\n\n\n\n**M. Àngels Jover** - Do you want me to invite anyone to speak?\n\n\n\n\n**Matthias Benkort** - Maybe Daniel, yeah. Since he's here.\n\n\n\n\n**M. Àngels Jover** - Okay.\n\n\n\n\n**Matthias Benkort** - Thank you, Maria. If Daniel is up to it.\n\n\n\n\n**M. Àngels Jover** - I don't see any username with Daniel. Maybe it's under another nickname?\n\n\n\n\n**Matthias Benkort** - It's Daniel Main. He is in the chat.\n\n\n\n\n**M. Àngels Jover** - I don't see him live right now.\n\n\n\n\n**Matthias Benkort** - Oh, weird. Okay. So maybe he's not they're anymore and our chat is lagging behind. Yeah, I can see too.\n\n\n\n\n**M. Àngels Jover** - Wow. What's happening today?\n\n\n\n\n**Matthias Benkort** - Daniel, are you around?\n\n\n\n\n**Sebastian Guillemot** - So...\n\n\n\n\n**Matthias Benkort** - He shows in the guest list.\n\n\n\n\n**Sebastian Guillemot** - Yeah.\n\n\n\n\n**Matthias Benkort** - I bet if he was there, he would've commented maybe on the chat already.\n\n\n\n\n**M. Àngels Jover** - I mean, he is in registered, but it's not live. Maybe I am the only one that can see the live.\n\n\n\n\n**Matthias Benkort** - Yeah. Yeah. We don't see that information. Indeed.\n\n\n\n\n**Sebastian Guillemot** - Ah, you're right. The chat does not show people who are actually here. It just shows people who have registered.\n\n\n\n\n**Matthias Benkort** - Yeah.\n\n\n\n\n**M. Àngels Jover** - That's the second tab.\n\n\n\n\n**Sebastian Guillemot** - I see. I see.\n\n\n\n\n**Matthias Benkort** - Okay. Well, then we'll just comment on the pull request itself.\n\n\n\n\n**M. Àngels Jover** - It's PR 234, this one? To put it [crosstalk 00:05:38].\n\n\n\n\n**Sebastian Guillemot** - It's 034.\n\n\n\n\n**Matthias Benkort** - Oh yeah. Not even in [crosstalk 00:05:41].\n\n\n\n\n**Sebastian Guillemot** - Oh. Yeah, no. Yes.\n\n\n\n\n**Matthias Benkort** - We first need to address the points that we just raised and then we can maybe reconsider it for CIP triage.\n\n\n\n\n**M. Àngels Jover** - Okay.\n\n\n\n\n**Matthias Benkort** - So I will just go on that.\n\n\n\n\n### Triage \n\n\n\n\n#### PR217\n\n [PR217- Collateral reward](https://github.com/cardano-foundation/CIPs/pull/217)\n\n#### PR104\n\n [PR104 - CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104)\n\n\n\n\n**Matthias Benkort** - Okay. Maybe we can go through the PR 217 and PR 104. Sebastian? Just for triage to see what we can do with that. If you think they are still relevant or not. We had them in the pipeline for a while.\n\n\n\n\n**Sebastian Guillemot** - Yeah. Yeah. Both these can just be deprecated and closed.\n\n\n\n\n**Matthias Benkort** - Okay. Both of them?\n\n\n\n\n**Sebastian Guillemot** - Sorry. Collateral output is the one that stays and should be merged at some point, but reward and key can both be marked as deprecated, or rejected, whichever, and closed.\n\n\n\n\n**Matthias Benkort** - Okay. Then I will let you do that. Yeah, we'll go through the collateral output after that.\n\n\n\n\n### Last Check     \n\n\n\n\n#### PR200\n\n [PR200 - Add support for Catalyst multi-delegation](https://github.com/cardano-foundation/CIPs/pull/200)\n\n\n\n\n**Matthias Benkort** - So the next one is CIP-36. The Catalyst multi-delegation support which we have been discussing for a bit.\n\n\n\n\n**Sebastian Guillemot** - Yeah.\n\n\n\n\n**Matthias Benkort** - It needed an update, but Mark has been unwell for a few weeks.\n\n\n\n\n**Sebastian Guillemot** - Yeah. I think there's still some comments that need to be resolved.\n\n\n\n\n**Matthias Benkort** - Okay.\n\n\n\n\n**Sebastian Guillemot** - Yeah. From two weeks ago. These are mostly just to do with mostly documentation changes and wording. Not so much about functionality-wise. I did add a comment a few days ago, I guess a week ago, saying that the current delegation CIP only supports staking public keys, like vkeys and not script keys. So there's two kinds of scripts, right? Native scripts and Plutus scripts. So, trying to register Plutus scripts for voting on Catalyst may be kind of tricky, but I feel like native scripts should be doable. This would be nice because there's a few different projects that are using native scripts now for multisig and it means that for multisig, any amount of data you store in your multisig can build for Catalyst. Notably I was interested about this because for Milkomeda we have the Milkomeda DAO, which stores the funds for the Milkomeda DAO, and obviously the Milkomeda DAO wants to also vote on Catalyst so this specific proposal mix that any amounts that the DAO earns cannot be used for voting on Catalyst, which is kind of unfortunate.\n\n\n\n\n**Matthias Benkort** - Okay. I'm just reading through your comments also. Probably... Yeah.\n\n\n\n\n**Sebastian Guillemot** - I think extending this CIP to extend to not just public keys, not just vkeys, but also native scripts is probably not too hard, and the hard part [crosstalk 00:09:21].\n\n\n\n\n**Matthias Benkort** - Shouldn't it be just a hash in the end?\n\n\n\n\n**Sebastian Guillemot** - Yeah. [crosstalk 00:09:26].\n\n\n\n\n**Matthias Benkort** - You don't care much what's the pre images about so long as it's a valid credential. Maybe a Plutus script, native script or a vkey.\n\n\n\n\n**Sebastian Guillemot** - Yeah. So I think from the actual CDDL specification from the CIP perspective, this is not a hard change. Someone just needs to make it like some sort of or with a tag. The question is just whether or not they want to make that change now or later. I suggest we at least make it now so we have backwards compatibility, and then I'll see this is something for wallets to add support and something for the Catalyst team as well to add support when they scan the chain.\n\n\n\n\n**Matthias Benkort** - Yeah, that's the field number two in the CDDL, right? In the key registration record.\n\n\n\n\n**Sebastian Guillemot** - Yeah.\n\n\n\n\n**Matthias Benkort** - Which currently is staking pub key.\n\n\n\n\n**Sebastian Guillemot** - Yeah.\n\n\n\n\n**Matthias Benkort** - Which should really be... For Jörmungandr if I call correctly, Jörmungandr doesn't use hashes. Right? It uses plain keys. So there might be-\n\n\n\n\n**Sebastian Guillemot** - It shouldn't matter for Jörmungandr because this is not who you're delegating to. This is just who is delegating. So from Jörmungandr's perspective, it's still just voting keys. Do you see what I mean?\n\n\n\n\n**Matthias Benkort** - Yeah. But if we put hashes instead of keys, don't we have a [crosstalk 00:10:47] there with [crosstalk 00:10:48]?\n\n\n\n\n**Sebastian Guillemot** - These hashes are not the voting key. These hashes are just who's delegating. Remember with Catalyst, you delegate to a voting key, right? So I'm saying we should allow delegating from a native script to a voting key, but the voting key still stays the same.\n\n\n\n\n**Matthias Benkort** - Yeah. Okay. Okay. Yeah. The voting key on the Jörmungandr side stays.\n\n\n\n\n**Sebastian Guillemot** - Yeah. That's why I think the change is probably not too hard, but at the very least, if you don't have time just make a tag-\n\n\n\n\n**Matthias Benkort** - This is just to determine this snapshot, right? That snapshot that goes, and how many funds is allocated to every voting key at the beginning of the voting round.\n\n\n\n\n**Sebastian Guillemot** - Can we add Kevin to speak?\n\n\n\n\n**Matthias Benkort** - Yep. I think so.\n\n\n\n\n**M. Àngels Jover** - Sure.\n\n\n\n\n**Matthias Benkort** - Oh. I'm right back. Got a call.\n\n\n\n\n**M. Àngels Jover** - We can only have four people on screen, so we are three now plus the screen share. Maybe Sebastian you can not screen share so we can talk to Kevin and have it... Okay.\n\n\n\n\n**Kevin Hammond** - Hi. Hi, everyone. You hearing me?\n\n\n\n\n**M. Àngels Jover** - Yeah. Clear and loud.\n\n\n\n\n**Kevin Hammond** - Hi, good. Yeah. Sebastian, we've been looking at this. It's an interesting idea. We have two issues with it. One of them is to do with how it changes the voting. We need to think about that quite carefully, so we don't want to rush into this. The second is we would need to add logic into the tooling to essentially replicate the script actions. That would include replicating the context for the script. We don't have any capability to do that at the moment. We would also, if we included native scripts, need to think about how time locks will work. So we can't simply add multiscript, multisig scripts without also having a think about how the Allegra time locking will work. So, what I would propose to do here would be to set up CIP so that it is upwards-compatible to allow script hashes, but not to do it in the immediate future.\n\n\n\n\n**Sebastian Guillemot** - Yeah. I think if we just change the stake pub key to instead just be a structure with a tag that's like zero is pub key and that's it, and then later we can add one as native script and later two as Plutus script, something like that.\n\n\n\n\n**Kevin Hammond** - Exactly. So we make it a union type and it's only got one network element, which is [inaudible 00:14:02]. We're happy to do that. Then we can think properly about all these different types of scripts. As I was saying, I don't think it's ever going to be possible to use a Plutus script, or at least it would be quite hard because you would need to bring in all the script context and you would need to execute that from within the... They call it the snapshot tool. So I think you would need to be basically running a node within the snapshot tool to be able to set up the context and execute the Plutus script. That looks very difficult. It might also cause some issues over how the votes were actually set up. So from a semantic perspective, that's quite a, potentially a big change.\n\n\n\n\n**Matthias Benkort** - I'm not sure to get the point though, because here it's really about the staking, right? So-\n\n\n\n\n**Kevin Hammond** - It's to do with how we translate the stake into the voting rights at the snapshot times.\n\n\n\n\n**Matthias Benkort** - So all you need to do at the snapshot times is to make sure that some staking credentials is attributed to some stake, but that's already what the ledger does. Right? If you've already delegated your stake using a Plutus script, that means you have published this delegation certificate on chain. It has been checked by the ledger already and your stake is active under that credential. So just specifying the credentials at the moment of your voting arbitration doesn't really add any complexity. Right?\n\n\n\n\n**Kevin Hammond** - Okay. Let's think about that. What I'm proposing is we discuss it properly rather than-\n\n\n\n\n**Matthias Benkort** - Yeah. Okay. I'm fully on board with that. We can have as you said, a forward-compatible format.\n\n\n\n\n**Kevin Hammond** - Exactly.\n\n\n\n\n**Matthias Benkort** - And see what are the consequences. But I do think there is no really consequences, so we can bring the discussion to another time. Yeah.\n\n\n\n\n**Kevin Hammond** - Well, the consequence concerned about are, they're more to do with the semantics of who can vote, how you control the vote. So we want to think about that, Sebastian.\n\n\n\n\n**Sebastian Guillemot** - Okay. Well, let's change this to this union type with a tag, merge to the CIP, then we can open another CIP that adds the native script, and then we can discuss from there for another voting round.\n\n\n\n\n\n\n\n**Kevin Hammond** - We've got a technical problem in that we can't seem to do anything with this PR because Mark owns it, and also the history, of course as you said before, has got a bit confused.\n\n\n\n\n**Matthias Benkort** - I thought it would be able to do that, so maybe I can try. Yeah, you don't have the rights on the CIP repo, so maybe you cannot push on mark PR.\n\n\n\n\n**Kevin Hammond** - Yeah. I don't think so. I think...\n\n\n\n\n**Matthias Benkort** - I think I can. The two things we need to add here as the... The derivation path, right? That was discussed a while ago already for the voting key, and this [inaudible 00:17:24] forward-compatible, changing the CDDL.\n\n\n\n\n**Kevin Hammond** - Yeah. But if you could give us write access. So [crosstalk 00:17:30]-\n\n\n\n\n**Matthias Benkort** - No.\n\n\n\n\n**Sebastian Guillemot** - The other option is just to close this one.\n\n\n\n\n**Matthias Benkort** - Yeah. Again-\n\n\n\n\n**Sebastian Guillemot** - Go back to this one and just do whatever. Or close both of them and open a new PR is another option.\n\n\n\n\n**Matthias Benkort** - Yeah. With all the history. But, okay. I mean, those are the two changes we want to get in, right? That the duration path for the voting key and the change of the CDDL. With that, we're good for merging this proposal as draft.\n\n\n\n\n**Kevin Hammond** - Yeah. I think Jack, he wanted to tidy things up to make sure we properly responded to all of the comments as well. We'd like to do that. If we can close these down, take a... I guess it's probably a... Is it a forked PR and then progress that as the set, that would be great.\n\n\n\n\n**Matthias Benkort** - Yep. Okay.\n\n\n\n\n**Kevin Hammond** - Good.\n\n\n\n\n**Matthias Benkort** - Okay. We can do that and maybe do the validation offline and get it merged. I don't think we need to wait yet again for the next meeting for the review. Although the next meeting is only in a week, so we can also do a last check for the next meeting with all the changes in a new PR and the comments addressed. Does that work for everyone?\n\n\n\n\n**Kevin Hammond** - Yep. That should be good.\n\n\n\n\n**Matthias Benkort** - Okay.\n\n\n\n\n**Kevin Hammond** - Great. So we'll progress that. I'll progress that with you, Matthias. Is that right?\n\n\n\n\n**Matthias Benkort** - Yeah. Yeah. Let's take it offline. I think we've been discussing this one for a while. We're pretty aligned on the next steps so we don't necessarily need to discuss it online again.\n\n\n\n\n**Kevin Hammond** - Yeah. We're actually talking to various wallet implementers about supporting this at the moment.\n\n\n\n\n**Matthias Benkort** - Yeah.\n\n\n\n\n**Kevin Hammond** - This one is [inaudible 00:19:37].\n\n\n\n\n**Matthias Benkort** - Okay. Taking a few notes and I will comment at the end of the call.\n\n\n\n\n**M. Àngels Jover** - So I understand that you are going to take the conversation offline and we are going to either merge it or change it in a new PR. Right?\n\n\n\n\n**Matthias Benkort** - Yeah. And probably merge the new PR also right away since it's already been discussed.\n\n\n\n\n**M. Àngels Jover** - Okay. So we can-\n\n\n\n\n**Matthias Benkort** - The new PR is just the technical issues because the author is not responding on this one, so.\n\n\n\n\n**M. Àngels Jover** - So we can take it off of the agenda. Right? next meeting? Perfect.\n\n\n\n\n**Matthias Benkort** - No. Or if we really have to we'll put it as last check for next week, but I don't think we'll have to. We can handle that offline.\n\n\n\n\n**M. Àngels Jover** - Okay.\n\n\n\n\n**Kevin Hammond** - Thanks, everyone.\n\n\n\n\n**M. Àngels Jover** - Thank you, Kevin.\n\n\n\n\n**Kevin Hammond** - So...\n\n\n\n\n**M. Àngels Jover** - Sorry. Sorry, Kevin. I just removed him while he was talking.\n\n\n\n\n**Matthias Benkort** - Kevin is gone.\n\n\n\n\n**M. Àngels Jover** - My apologies, Kevin. You were talking.\n\n\n\n\n**Sebastian Guillemot** - We have to move on to ...\n\n\n\n\n**Kevin Hammond** - I was going to say...\n\n\n\n\n**Sebastian Guillemot** - Oh, go for it.\n\n\n\n\n**Kevin Hammond** - I was going to say, Sebastian, we'll set up a call with you and others discuss this probably in about two months' time.\n\n\n\n\n**Matthias Benkort** - Yeah. You mean the extension with the multisig.\n\n\n\n\n**Kevin Hammond** - The extension with the multisig.\n\n\n\n\n**Matthias Benkort** - Okay.\n\n\n\n\n**Kevin Hammond** - Brilliant. Okay. I can drop now.\n\n\n\n\n**Matthias Benkort** - Bye.\n\n\n\n\n**M. Àngels Jover** - Thank you very much, Kevin.\n\n\n\n\n#### PR208\n\n [PR208- [CIP-0030] Adding getCollateral function to the connector API](https://github.com/cardano-foundation/CIPs/pull/208)\n\n\n\n\n**Matthias Benkort** - So, [CIP-0030] Adding getCollateral function to the connector API We discussed this one last time already. All right. It makes sense.\n\n\n\n\n**Sebastian Guillemot** - Yeah. I think this implementation made sense to me.\n\n\n\n\n**Matthias Benkort** - It made sense also to have it as an extension of the CIP-30, this one. I think the only thing we were maybe discussing was whether or not we want to add it to the existing CIP-30, or to have that as another CIP which is extending the API.\n\n\n\n\n**Sebastian Guillemot** - I would just merge it I think to CIP-30.\n\n\n\n\n**Matthias Benkort** - Yeah. I mean, it's quite small enough, this one, and it's really core to the API itself. But then there is this question of versioning of this CIP connector. When do you suppose [crosstalk 00:22:29]?\n\n\n\n\n**Sebastian Guillemot** - Yeah, so the way we're handling versioning, at least the way I envision it is that in the CIP-30, we have two sets of functions. Experimental functions and non-experimental functions. Any new CIP should add stuff to the experimental section. And then whenever enough wallets implement, they would move from experimental to main and then bump their version number is the way I envisioned it. That way people can still make changes without bumping the version number and everything is in the experimental [inaudible 00:23:02] space.\n\n\n\n\n**Matthias Benkort** - Yeah, but the experimental was also a CIP [inaudible 00:23:06] discussion. Right?\n\n\n\n\n**Sebastian Guillemot** - Yeah, but I think that was merged already.\n\n\n\n\n**Matthias Benkort** - I don't see it on the CIP-30. Experimental... Or was it maybe merged. Yeah, it's in still open PR. That was the experimental API version. Okay. That's another thing.\n\n\n\n\n**Matthias Benkort** - I'm pretty sure we discussed that experimental approach a while back, but it's definitely not merged in the CIP. Oh yeah, it is, actually. Sorry. At the bottom. My bad.\n\n\n\n\n**Sebastian Guillemot** - Yeah, it was merged back in February.\n\n\n\n\n**Matthias Benkort** - Okay.\n\n\n\n\n**Sebastian Guillemot** - That's the way to manage the version number I think that makes the most sense. The get collateral one is the only one that's kind of awkward because we're changing an API that everybody already supports. We're just documenting it.\n\n\n\n\n**Matthias Benkort** - Okay.\n\n\n\n\n**Sebastian Guillemot** - That was especially a case of an awkward thing where we already [crosstalk 00:24:27] one, so there's no point going from the experimental first.\n\n\n\n\n**Matthias Benkort** - Yeah. Then the awkward thing is how and when you decide to move from experimental to non-experimental. It's once multiple wallets implement it, but it's a bit vague, right? How many wallets and...\n\n\n\n\n**Sebastian Guillemot** - Yeah. Probably what we need to do is make this more formal, add it, change the CIP-30 that adds to the governance of CIP-30 that says governance of the CIP is that it should only be merged if X wallets, blah, blah, blah. Include the functionality, something like that.\n\n\n\n\n**Matthias Benkort** - Yeah. Maybe having explicit versioning in the CIP. I mean, for every single function that there is, like this one should be supported if you are in version 1.0. If you are in version 1.1, you should also support that function and that function. And then from that, it's very clear. You can ask the wallet version and depending on the version number, you know exactly which version they support, which API they have available.\n\n\n\n\n**Sebastian Guillemot** - Yeah.\n\n\n\n\n**Matthias Benkort** - Or an alternative, and that's why I was maybe advocating having another CIP for that, would be instead of a version number, you get the list of CIPs that your connector supports. Would be CIP-30, CIP I don't know, 46, for instance. And 46 is the one that introduces the get collateral API. So you know from that list exactly which feature are supported. That allows also wallet implementers to implement features that are important to them. Not necessarily in sequential order, but just say, \"We support this set of features. You have the list here,\" but maybe we don't support this one that was introduced in between these two other features because we don't care about it. And we don't make it mandatory to implement every API as you upgrade versions of your wallets. See what I mean?\n\n\n\n\n**Sebastian Guillemot** - Yeah. That's definitely another approach. We could even do both at the same time because I don't think they conflict each other either.\n\n\n\n\n**Matthias Benkort** - Okay. I don't want to be too much on that one for this particular one so I think this one is fine to merge as is, but maybe I will actually make a proposal for handling new versions of our additions to CIP-30 in the form of-\n\n\n\n\n**Sebastian Guillemot** - Yeah. We definitely need some PR that just adds some governance to this document. So I bring those [crosstalk 00:27:08]. Yeah.\n\n\n\n\n**Matthias Benkort** - Yeah. Governance and structure. A bit more on how to update, because as a wallet implementer, this sounds not like fun right now to maintain all the different versions of the CIP-30.\n\n\n\n\n**Sebastian Guillemot** - Okay. Yeah. It's kind of tough. We'll have issues with people not wanting to support the message signing, but message signing was not a separate CIP. It was introduced in the original CIP, blah, blah, blah. Somebody will need to sit down and figure that out at some point.\n\n\n\n\n**Matthias Benkort** - Right now it's still draft so what I would suggest would be to say, move this one to actually active. Merge that pull request, making the API collateral something part of the core CIP-30. Move it as active and sort of settle in stone a bit the primary API, and then define updates through another CIP and define how we would implement updates and extensions on the CIP-30 in the future, because there will also be extension. But at least settle that first part in stone now that it's become pretty stable or discussed for quite a while, and it's implemented now by most wallet provider anyway. So we have also the proof of activity, in that sense. Do you agree?\n\n\n\n\n**Sebastian Guillemot** - Yeah. Makes sense to me.\n\n\n\n\n**Matthias Benkort** - Thank you. I will discuss that with Robert as well.\n\n\n\n\n**Sebastian Guillemot** - In the meantime, I've approved this PR.\n\n\n\n\n**Matthias Benkort** - Yeah. Just, approving comment. Let's move this one.\n\n\n\n\n**Matthias Benkort** - Okay.\n\n\n\n\n**M. Àngels Jover** - There's still one missing approval. Matthias, are you going to approve it later?\n\n\n\n\n**Matthias Benkort** - No, I just did. I was just commenting at the same time, so it took a bit of time and we can go for it.\n\n\n\n\n#### PR215\n\n [PR215 - CIP-35: Plutus Core Evolution](https://github.com/cardano-foundation/CIPs/pull/215)\n\n\n\n\n**M. Àngels Jover** - Shall we move to the next item? PR 215, Plutus core evolution.\n\n\n\n\n**Matthias Benkort** - Yeah.\n\n\n\n\n**Sebastian Guillemot** - I just noticed we have two tentative CIP-35s. This conflicts with the Daedalus one.\n\n\n\n\n**Matthias Benkort** - Yeah, I will tweak the numbers. I think we've made it clear last time, and on the read me also. Well, people are not supposed to be allocating numbers themselves. They might try, but we'll just modify it at the same time.\n\n\n\n\n**Matthias Benkort** - Michael is saying it's confusing. Yes, but it's been clarified last time now, so we have tentative numbers on the front page. Yeah, I told you pick a number and that was fine. We keep track of the numbers on the front page. As you can see, the tentative number for the Plutus core evolution is 35. So, you are not the one conflicting here and it's fine. But mind you, we have all the rights to modify the PR if we need to adjust the numbers. We will do so upon merging if needed. But that's not the case for Plutus evolution, which is already the candidate for number 35. So that's fine.\n\n\n\n\n**Matthias Benkort** - Okay. The Plutus core evolution, that was also reviewed last time, and we are mainly in last check, right? If there was any last comments on this one, but I think there was none.\n\n\n\n\n**M. Àngels Jover** - No. Last comments are from February 14.\n\n\n\n\n**Matthias Benkort** - Yeah. So we're good with that. There has been already two, at least. Even three now I think. Proposals already following this process, people seem to be happy with it. Yeah. You never know if people are really happy though.\n\n\n\n\n**M. Àngels Jover** - Weeks ago, there was commented that maybe it would be good to add an extra status call at adopted between proposed and active, but we haven't.\n\n\n\n\n**Matthias Benkort** - That's also Michael's question in the chat and that was what I was suggesting last week. Since this one is a process, it should be I think merged as active. Mainly because, well, there has been already three CIPs following this process which shows already activity, and it's not like we're wait for an implementation or some actual code or platforms to adopt it. It's really more of a process and we deem it now ready, active. It's supported by the core team, the core Plutus team, which mean that we don't even need to check with them if it's okay because the process actually comes from them. So, yeah. I've just approved. Maybe just before merging, we will change the status to active, if that's fine for everyone.\n\n\n\n\n**M. Àngels Jover** - Looks it is. Shall we move to the next item?\n\n\n\n\n**Matthias Benkort** - Okay. Michael, if you want to push the change to move it to active, feel free. Otherwise I will just do it at the end of the call. Well, just this one approval though, I think, because I was the only one that approved. So Seba, unless you disagree, voice yourself, but otherwise...\n\n\n\n\n**M. Àngels Jover** - Now we have both approvals.\n\n\n\n\n**Matthias Benkort** - Okay, good. So yeah, just the active status and we can merge.\n\n\n\n\n### Review\n\n\n\n\n#### PR209\n\n [PR209 - [CIP-0030] Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209)\n\n\n\n\n**Matthias Benkort** - Now, more to the review, which was the next item was the... Yeah. Optional network ID parameters. Yeah. What Sebastian was discussing at the beginning. We're saying yeah, this one we disagree and the author has been quite inactive since then so we can simply park it on the site and wait for updates from the author.\n\n\n\n\n**Matthias Benkort** - Can we talk about the other builds in CIP? Yeah. We're just coming to it. So, CIP-32 and CIP-32. Those one have the same numbers precisely because they are conflicting, also in the sense. So I don't think it makes sense to merge both of them because they are attacking the same problem and if one of them is actually adopted, the other one should be deprecated or rendered obsolete. I think it's the one we wrote with Sebastian on the CRS built-in data that has been adopted in the Plutus code base. Maybe you can invite Michael on chat before he leaves.\n\n\n\n\n**M. Àngels Jover** - Sure.\n\n\n\n\n**Matthias Benkort** - Yeah. It's the one we are implementing these days. That means we can probably deprecate the second one, unless it makes sense to also have the second one. I don't know. And have the two ways. This one's redundant to me to have both ways, but I don't know. Michael?\n\n\n\n\n**Matthias Benkort** - I don't think so. Yes, it's-\n\n\n\n\n**M. Àngels Jover** - I need to remove my screen sharing before invite him. Ah, no.\n\n\n\n\n**M. Àngels Jover** - Now you have Michael on the screen.\n\n\n\n\n**Michael** - Can you hear me?\n\n\n\n\n**Matthias Benkort** - Yeah. We can hear you.\n\n\n\n\n**Michael** - Okay, good. Yeah. So, it's redundant I think.\n\n\n\n\n#### PR218\n\n [PR218 - CIP-42? | New plutus builtin: serialiseBuiltinData](https://github.com/cardano-foundation/CIPs/pull/218)\n\n\n\n\n#### PR222\n\n [PR222 - CIP-42? | New Plutus Core built-in dataHash](https://github.com/cardano-foundation/CIPs/pull/222)\n\n\n\n\n**Matthias Benkort** - Okay. Talking about PR number 218. One thing we would have to add before merging it as proposed or active will be the cost model I believe, that was left out initially.\n\n\n\n\n**Michael** - Yeah. I think the Plutus... Wait. Can you hear me?\n\n\n\n\n**Matthias Benkort** - Yeah.\n\n\n\n\n**Michael** - Okay, good. I think that Kenneth has been working on that so I think we could probably put something up there with the Plutus team. I think this is maybe something that I should clarify in the evolution one maybe as a follow up, but I think it would be fine to merge it as draft with a high-level description of what the serialization function is. So, say something like based on the work in this pull request, we believe that it is basically linear in the size of the thing. Exact parameters will be determined empirically or something. That I think is sufficient.\n\n\n\n\n**Matthias Benkort** - Okay.\n\n\n\n\n**Michael** - Yeah. I think that's fine. It doesn't have to be 100% precise, I think.\n\n\n\n\n**Matthias Benkort** - Okay. Okay. So we can add that and then move the CIP as proposed since there is a clear path to active now, and move it to active as soon as this becomes available in the Plutus built in, which should be part of the Babbage hard fork as far as I understood. Or Vasil hard fork? I don't remember what's the name anymore.\n\n\n\n\n**Michael** - Yeah. That sounds right.\n\n\n\n\n**Matthias Benkort** - Okay. About the second one, the PR 222, you were saying this won't be implemented because it's redundant.\n\n\n\n\n**Michael** - Yes.\n\n\n\n\n**Matthias Benkort** - Do we have the last here? It was in the chat, but I'm not sure if it is active or not. It is Vasil, thanks. So, because Las is the author of the second one, which was basically trying to solve the same problem, but in a more straight way, I would say. In a more direct way. So not having this extra serialization step, but just going for the hash straight away. So there was a bunch of discussions on it, but it's been pretty evolved since then.\n\n\n\n\n**Matthias Benkort** - Okay. He doesn't seem to be here. Maria, do you see him as live or? Las Safin.\n\n\n\n\n**M. Àngels Jover** - No.\n\n\n\n\n**Matthias Benkort** - Okay. He just registered, but probably didn't join either, so okay. We'll comment then on PR number 222 and move that CIP. Probably merge it as deprecated or obsolete.\n\n\n\n\n**M. Àngels Jover** - Yeah. You mentioned, Matthias, Mlabs? Who do you mention that you want to ?\n\n\n\n\n**Matthias Benkort** - Las. Las Safin. He's from MLabs.\n\n\n\n\n**M. Àngels Jover** - Ah, Las. No, he's not. He is registered but not live.\n\n\n\n\n**Matthias Benkort** - Okay. Okay. So there is still room for CIPs that are rejected, and I think it makes sense to still record it as a rejected CIP, this one, to show that there has been discussions between two alternatives and we went for a first one that is a bit more composable, in my opinion. Okay. We'll comment on that one.\n\n\n\n\n**Matthias Benkort** - Maybe Michael also, if you have a rationale for why you went for PR 218 instead of 222, that would be also helpful maybe as a closing comment. I am a bit biased in the story since I'm the co-author of one of them, so obviously I think mine is better, but that's biased.\n\n\n\n\n**Matthias Benkort** - I'm not sure. Okay. Sure. Okay. So yeah, feel free to comment on the pull request then. I will also add some top after the meeting.\n\n\n\n\n**M. Àngels Jover** - Just a quick question. PR 218, are you going to merge it?\n\n\n\n\n**Matthias Benkort** - Yeah. Once we've done these little additions I was mentioning about the choice of cost model, as Michael was explaining.\n\n\n\n\n**M. Àngels Jover** - Okay.\n\n\n\n\n**Matthias Benkort** - The cost model is still to be determined empirically, but it should be somewhat linear in the size of the built-in data based on what we've been observing so far. That's good enough for now to have it as proposed CIP and once the implementation is finalized and available, we will update it as active.\n\n\n\n\n**M. Àngels Jover** - What do you want me to do with this? To put it on hold and discuss it in a few meetings or? In the agenda, I mean.\n\n\n\n\n**Matthias Benkort** - Hmm? Sorry.\n\n\n\n\n**M. Àngels Jover** - What do you want me to do? To put it on hold until the change is made and we can then discuss it later or?\n\n\n\n\n**Matthias Benkort** - Yeah, I think we can put it as last check for next week.\n\n\n\n\n**M. Àngels Jover** - Okay.\n\n\n\n\n**Matthias Benkort** - I will do the change somewhere between now and next week and we'll be able to do our last review and see if it's okay.\n\n\n\n\n**M. Àngels Jover** - Perfect.\n\n\n\n\n**Matthias Benkort** - So we had the last one, I think, on the list.\n\n\n\n\n\n\n\n#### PR220\n\n [PR220 - CIP-43? | Plutus support for pairings over curve Bls12-381](https://github.com/cardano-foundation/CIPs/pull/220)\n\n\n\n\n**M. Àngels Jover** - Yeah. PR 220.\n\n\n\n\n**Matthias Benkort** - Yeah. Plutus support for pairings over curve BLS12-381, which was the one for which we wanted to have some help of cryptographers, which I haven't been able to get so far. So, we'll keep looking, actually. But yeah, this one is hard to progress for us as Editors because we are missing the expertise here that is necessary to judge. Yeah. That's the idea. I mean, I trust in Iñigo, the current author, what he's writing and specifying, but it's good to have conversation with people that can actually contribute to the conversation. So yeah, I will just keep that on my list to try to find someone.\n\n\n\n\n**M. Àngels Jover** - I will ask you in a couple of weeks if you find someone. Okay?\n\n\n\n\n**Matthias Benkort** - Yeah. We can park it for now and see if there is anyone either in IOG or within the research cycle. Someone that can share some time on that.\n\n\n\n\n#### PR216\n\n [PR216 - CIP-40? | Collateral output](https://github.com/cardano-foundation/CIPs/pull/216)\n\n\n\n\n**M. Àngels Jover** - Good. The last item that we have was PR 216, the collateral output. I know that you had a discussion at the beginning of the meeting, but I don't know if we just left that for now to discuss in the...\n\n\n\n\n**Matthias Benkort** - I don't know. Sebastian, what do you think?\n\n\n\n\n**Sebastian Guillemot** - One more time? Sorry.\n\n\n\n\n**Matthias Benkort** - The collateral output. Do you want to discuss it now or keep it for later?\n\n\n\n\n**Sebastian Guillemot** - No. You can discuss if you want, but this has already been decided. This is already part of the CDDL, already implemented in the ledger spec\n\n\n\n\n**Matthias Benkort** - Okay. So it's in a good way to actually becoming active.\n\n\n\n\n**Sebastian Guillemot** - We can have a discussion about if you want, but I don't think any discussion we'll have would actually be reflected into the protocol.\n\n\n\n\n**M. Àngels Jover** - So this is going to be merged?\n\n\n\n\n**Sebastian Guillemot** - Yeah, I would merge it unless somebody has any objection.\n\n\n\n\n**Matthias Benkort** - Yeah. It's been around for a while already. You've been discussing it with Jared and Andre, I imagine.\n\n\n\n\n**Sebastian Guillemot** - Yep.\n\n\n\n\n**Matthias Benkort** - Okay. So we can have it as proposed, also following the same paths, and moving to active as soon as it's becoming really available in the ledger. So, moving it to last check for next week. Or we'll change the status, assign the right CIP number and move forward with that.\n\n\n\n\n**Sebastian Guillemot** - Yeah. Sounds good to me.\n\n\n\n\n**M. Àngels Jover** - Okay.\n\n\n\n\n### Close\n\n\n\n\n**M. Àngels Jover** - We have five minutes left. Do you want to do a recap, Matthias?\n\n\n\n\n**Matthias Benkort** - Yeah. I think people appreciated that last time. Just Kevin has a question on the chats. I'm not sure if still have the context. Are you talking about the search for a cryptographer, Kevin?\n\n\n\n\n**Matthias Benkort** - Maybe Kevin is gone, so okay. We'll take it off band. That's fine. Okay. Let's recap.\n\n\n\n\n**Matthias Benkort** - We went through the collateral reward collateral key derivation CIPs, which are going to be marked as deprecated and likely closed. We could also merge them as rejected CIPs just for the record and keeping the history.\n\n\n\n\n**Matthias Benkort** - Oh, wait a minute.\n\n\n\n\n**M. Àngels Jover** - I took some notes so I can do the recap on behalf of Matthias. We are going to have a PR 200 for last check in the next meeting. PR 208, adding collateral function to the connector API has been merged. Also PR 215, Plutus score evolution has been merged. PR 222 is going to be rejected. This one is the PR that was competing with PR 218 that finally is going to be implemented. Here it would be good to have a rationale why PR 218 has been chosen over to PR 222. And we have PR 218 for last check in our next meeting.\n\n\n\n\n**M. Àngels Jover** - Also, PR 216, collateral output. This is going to be merged. Right, Sebastian? I am not 100% sure of this last one.\n\n\n\n\n**Sebastian Guillemot** - Yeah.\n\n\n\n\n**M. Àngels Jover** - Okay. So that's it for today. Just remember you all that next meeting is going to be next Tuesday. It will be in the United States time zone. This means that it's going to be held at seven UTC. Well, with you all there and the ones you cannot make it, as always we are going to record the session. Thank you very much and have a lovely day and week. Bye-bye!\n\n\n\n\n---\n\n## Extra\n\n\n\n\n### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md)\n\n\n\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n\n\n\n\n\n### CIP creation process as a Sequence Diagram  \n\n\n\n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n\n\n\n### Understanding CIPs further\n\n\n\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n"
  },
  {
    "path": "BiweeklyMeetings/2022-04-12.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [April 12 2022 Transcript](#april-12-2022-transcript)\n  * [Triage](#triage)\n    + [PR216 - CIP-40? | Collateral output](#pr216)    \n    + [PR163 - CIP-37? | Dynamic Saturation based on Pledge](#pr163)\n    + [PR137 - CIP-0038? | On-Chain Token Metadata Standard](#pr137)    \n    + [PR151 - CIP30: Events API](#pr151)\n  * [Last Check](#last-check)\n    + [PR218 - CIP-42? | New plutus builtin: serialiseBuiltinData](#pr218)        \n  * [Review](#review)\n  * [Discussions](#discussions)\n    + [CIP-0050? | Shelleys Voltaire decentralization update](#pr242)\n    + [PR224 - Add Proof of Existence record label to registry.json](#pr224)\n    + [PR241 - CIP-0989? | ISPO KYC_CDD](#pr241)\n    + [PR188 - CIP-36? | Update CIP-15 to support multi-delegation](#pr188)\n\n  * [Close](#close)\n\n## Summary\n\nRough transcript of 12/04/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Transcript might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/e/cip-editors-meeting-43) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n**Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n\n**Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n\n**New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \n\nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n**Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n\n**Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.  \n\n\n## April 12 2022 Transcript\n**Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, Frederic Johnson, Robert Phair. \n**Guests**: Michael, Giacomo\n\n**M. Àngels Jover**-: Hello, everyone. Welcome to the CIP editors meeting number 43. My name is Maria Angels Jover, and I work as a project manager at the Cardano Foundation. And I am here to facilitate this meeting for you. At the top left, here you see... I am not sharing my screen. Sorry. Right now, you should be able to see my screen. At the top here, on this I letter, you can click and you can check the agenda. Then you have the chat box where you can leave any questions that you have. Also at the bottom, you have this bottom Ask a Question, you can use this because it's easier for us to answer from here and not from the chat. And well, it's my pleasure today to introduce you to all our editors today, which are Matthias Benkort, Frederick Johnson, and Robert Phair. First of all, I would like to check with you editors, is there anything that you want to review that is not in the agenda? Hey, Sebastian is here. Hi, Sebastian. I'm sorry, I didn't see you. And you have Sebastian Guillemot as an editor too.\n\n**Matthias Benkort**-:  Well, there has been a recent pull request on CIP, but I sure CIP 50, that will be maybe nice to get a nice one, especially because it's similar to a previous CIP we've had, and maybe also overlapping with CIP number 37. I haven't looked in details into it because it's quite wide CIP, and we won't do the review today likely, but at least get a first acknowledgement, first dive into it, and see what would be needed then, maybe, to move it forward. I've already forwarded that CIP, by the way, to the core team internally for people to have a look. Yeah, we can expect some activity and comments in the upcoming future. And maybe I'll have [crosstalk].\n\n**M. Àngels Jover**-: What PR is it Matthias?\n\n**Matthias Benkort**-:  Sorry. It's PR 242.\n\n**M. Àngels Jover**-: Okay. I'm just going to share it with you.\n\n**Robert Phair**-: : Okay. And there was also one issue that I think should be discussed, some of the CIP PRs are being discussed. Said it's about one of the first CIPs that came along as an issue 232. That is right now being hashed out, the discussion is being hashed out in that issue, but it might be good to track that the same way we're tracking some of the PRs, because there's been a lot of discussion about whether one of the original CIPs should be modified or a new CIP should be created. It would be good to observe that for a little bit.\n\n**Matthias Benkort**-:  Yeah, yeah. Good point. Issue number 242, right, on CIP number two, the coin selection.\n\n**Robert Phair**-: : Yeah.\n\n**Matthias Benkort**-:  This one, yeah. This one has got a bit of a [inaudible].\n\n**Matthias Benkort**-:  (Silence).\n\n### Triage \n\n#### PR216\n [PR216 - Collateral output](https://github.com/cardano-foundation/CIPs/pull/216)\n\n\n**Matthias Benkort**-:  Okay. Shall we start with the collateral outputs?\n\n**M. Àngels Jover**-: Yes. This one was agreed last week to merge it, but I have added it to triage as I haven't seen it merged yet.\n\n**Matthias Benkort**-:  Yeah. Right, right, right. I wanted to go through it, which I actually did yesterday. Yeah, you just need a number. That's why we haven't still merged it. But it's tentatively CIP 40, so it's just a matter now of moving the file to the right folder, putting CIP 40 as a number, and getting it merged, indeed. That we discussed, but we also haven't proved it explicitly. Yeah, I will approve and reduce conditions of those terms. I'm not sure, Robert, if you had time to go or to look at this one, but the status quo of what we discussed last week was that this has been made and written in combination with the ledger team, and it's actually already being adopted in the ledger as an implementation and should be part of the Vasil Hard Fork coming in June, so it's a bit fast tracked in that sense.\n\n**Robert Phair**-: : Yeah. That's all I got from it is that it seems to be in progress anyway, and I certainly don't have any disagreement with it, the way it's being treated.\n\n**Matthias Benkort**-:  Yeah, it was more like an ad-hoc conversation that got documented as a CIP, but by the time the CIP arrived, the decision had already been made with the ledger team about the direction to take. It's more an informational CIP in that sense.\n\n**Robert Phair**-: : It's fait accompli, yeah.\n\n**Matthias Benkort**-:  And therefore, we could also maybe address the status already, because at least as proposed. Yeah, can you confirm we expect this to be included in the Vasil Hard Fork? I would say we could merge it as proposed and move it to active as soon as it's observable after the Hard Fork. Let's document that under pull request review change status to propose.\n\n**Matthias Benkort**-:  Okay, sorry. That's commented directly on the ticket.\n\n**M. Àngels Jover**-: Here, we have the update. Perfect. We are missing one approval right here, right now, to merge it.\n\n**Matthias Benkort**-:  Yeah, but we don't want to merge it also right away, as I said. We still need a few bullet points to be tackled, so either Sebastian can do it or any of the editor can tackle that later on. We should be able to push on the branch, at least.\n\n\n#### PR163\n [PR163 - CIP-37? | Dynamic Saturation based on Pledge](https://github.com/cardano-foundation/CIPs/pull/163)\n\n**M. Àngels Jover**-: Okay. I just added a few things to the agenda that were... This one, for example, 163 was on hold, and you comment that Matthias said was sitting with the engineering team. I was wondering if you had any update on this.\n\n**Matthias Benkort**-:  Yeah. Unfortunately, no. This one is a bit the same as the curve pledge benefits CIP seven, or another CIP, which I don't remember the... Yeah, 24th non-centralized ranking which are affecting the protocol and the rewards mechanism of the protocol or the way pools get rewards and get organized. And therefore, this is affecting the game theory behind the scene, and that's CIPs for which we wanted to have inputs from the researchers. From what I got so far is that the research team has no bandwidth to provide an actual detailed answer, but that they are not quite in favor of these new CIPs because they put some... Well, they reduced the Nakamoto coefficient or they put some security issues, but they have been quite vague so far on the reasons and the rationales behind, so I'm really trying to get a formal answer or some more detailed answer on those matters. But yeah, so no substantial updates from my side, unfortunately.\n\n**M. Àngels Jover**-: Perfect. What I will do is to leave it on hold and maybe we can just talk in a month or a month and a half. Maybe I can ask you offline if you have any update.\n\n**Matthias Benkort**-:  Well, if I have any anyway, I will put them on the PR and comments on the respective CIPs. I'm really checking every week on those ones, mainly because if they are unsuitable because of some reasons, I would just like to put those CIPs and mark them as obsolete or rejected and be able to move on with that.\n\n**M. Àngels Jover**-: Okay, okay.\n\n**Matthias Benkort**-:  Okay, so Kevin is saying the research team has a blog in progress about pledge, so that might be resolved soon. And that's also why I wanted to look at the the potential CIP 50 that has been published recently because it comes along with, actually, a lot of data, graphs, and argumentation in favor of the CIP, which then makes it for a good style of discussion, or actually, that definitely shows that there has been research done also on that particular topic, and maybe makes it easier for the research team to assess whether or not the work is legit, or what I mean is it doesn't put security issues within the whole project.\n\n**Matthias Benkort**-:  Yeah, Michael is here, I see. Yeah, well, near the end lately, after we've done the current agenda, we'll touch a bit about CIP 50, so that's good. Thank you, Michael, for joining. Yeah, beside that, I think we reviewed the CIP 37 already in the past. It looks sensible from a technical perspective as it is. The question is, does it play actually well with the game theory or not, and will it have the outcome that is explaining in the motivation. That's more a question for the game theories behind, so it's a bit hard to tell. Maybe there will be also something to do with testnets on those two slants. Many of those changes rely on the game theory, and the game theory is theory also, a lot. It doesn't necessarily play like that on the whole scenario, so I'm wondering maybe if we could also just pin up testnets to try out those features sometimes and see how it goes, how people organize, even though testnet is also not mainnet. You've got free money, so you don't behave the same way you would behave on the actual minutes. I don't know, sorry. Just a parentheses.\n\n**M. Àngels Jover**-: Okay. Do you want to move forward to the next one?\n\n**Matthias Benkort**-:  Yes, unless someone has something to discuss on that one.\n\n#### PR137\n [PR137 - CIP-0038? | On-Chain Token Metadata Standard](https://github.com/cardano-foundation/CIPs/pull/137)\n\n**M. Àngels Jover**-: Okay. I brought to the agenda also PR 137 because we were waiting for the author, and this was one that I have on hold too, but I see that has been commented seven hours ago, so that's good.\n\n**Matthias Benkort**-:  Yeah, there has been some activities, but not from the author, unfortunately. Maybe we can ping, actually, Matt, the author, directly to see. People are arguing on the formats, and mainly, so they want to have something more compatible with the NFT standard that exists, but as we've outlined already in the past, the current NFT standard has several flaws that we want to fix. If going for new standards, we shouldn't repeat the same mistakes as before, which is exactly what the last comment answers or explains. As for this proposal itself, it still has the issues we've exposed a while ago, which is that you cannot really use the minting transaction of tokens to attach metadata to them, and therefore... Well, that's still an unsolved problem, and that's why we were waiting for the author to react on that. Maybe they have been discontinuing the whole proposal, so it would be good to clarify that with them.\n\n**M. Àngels Jover**-: I can ping again, request him to comment on February 28th, maybe. Well, I will just do it again and ping him again.\n\n**Matthias Benkort**-:  We're already pinging, or-\n\n**M. Àngels Jover**-: Yeah, yeah, yeah. I will do so.\n\n**Matthias Benkort**-:  Okay. I will just reach out to him on Discord maybe, that would be more efficient. Oh, not sure if he's monitoring the report or not.\n\n**M. Àngels Jover**-: It's Savasky, right?\n\n**Matthias Benkort**-:  Yeah, who is actually Matt, the CTO of SundaySwap\n\n**M. Àngels Jover**-: I'll do it later. \n\n#### PR151\n [PR151 - CIP30: Events API](https://github.com/cardano-foundation/CIPs/pull/151)\n\n**M. Àngels Jover**-: We have 151 events API. I brought this to the agenda because it was an old one.\n\n**Matthias Benkort**-:  The Event API. Didn't we merge that one already, or was it still in flux?\n\n**Matthias Benkort**-:  (Silence).\n\n**M. Àngels Jover**-: Matthias? I don't know if you are talking. Oh, he disconnected. Hi, Matthias.\n\n**Matthias Benkort**-:  Hey, sorry.\n\n**M. Àngels Jover**-: You disconnected, right?\n\n**Matthias Benkort**-:  Yeah. I clicked the link.\n\n**Robert Phair**-: : Thank God. I saw the drop there too, yeah.\n\n**Matthias Benkort**-:  Took me out. Am I back?\n\n**M. Àngels Jover**-: Yes, you are.\n\n**Matthias Benkort**-:  Okay. Yeah, so this one has got no activity since February 4th, so we're basically waiting on the author on that. This was part of the original CIP 30, and it was moved out of the CIP when we merged the CIP 30 as a draft, because it was quite a side concern, and we thought it would be better to bring it as an update or an external CIP completely. It was more like a grooming around what could an event API look like for the CIP 30. I'm not sure if the effort is being discontinued or not, but yeah, I guess this one still needs more discussions from within the community before we actually can do anything as editors.\n\n**M. Àngels Jover**-: We just leave it on hold, right?\n\n**Matthias Benkort**-:  Yeah. It's still a draft, and it's very under discussion, so I think you just open a PR to have the discussion live, happening on GitHub, but there is no particular need or urgency to get anything done at the moment with that CIP.\n\n**M. Àngels Jover**-: Okay. I'll take notes.\n\n**M. Àngels Jover**-: (Silence).\n\n### Last Check  \n\n#### PR218\n [PR218 - CIP-42? | New plutus builtin: serialiseBuiltinData](https://github.com/cardano-foundation/CIPs/pull/218)\n\n**M. Àngels Jover**-: Next step I added to, this is the same one, here at 163. We can go directly to last check with the 218, new CIP-42? New plutus builtin: serialiseBuiltinData within this one. I think it was supposed to be merged.\n\n**Matthias Benkort**-:  Yeah, provided that we did the necessary updates on this one, and I'm guilty as one of the co-authors. I was just busy with other stuff and didn't do the time to do anything with that one. But yeah, so it's another implementation on the Plutus site, or actually it's even been implemented already, but only available on the latest master branch, so not yet in the nodes. But yeah, we wanted to clarify the cost model and what the cost model looked like with this proposal, that was one of the open points we left when we made the proposal, and it's been clarified since then. Before merging, we should just report in the proposal what it is. Just waiting for the author on that one.\n\n**M. Àngels Jover**-: Okay. I'm going to label it.\n\n**Matthias Benkort**-:  Maybe I will just comment on it so that it's also clear.\n\n**M. Àngels Jover**-: Okay. That was what I added to the agenda because we were moving forward little from our last meeting. Do you want to do a review on other PRs, because maybe you know better what it's worth?\n\n### Review \n\n### Discussions\n\n#### PR242\n [PR242 - CIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242)\n\n**Matthias Benkort**-:  Well, since we have Michael here, we can definitely look at potential CIP 50, at least to get a round of introduction and a high level overview of it before we actually dive into redoing it in the next sessions, or more in between sessions.\n\n**M. Àngels Jover**-: We are in 242?\n\n**Matthias Benkort**-:  That was 242, right?\n\n**M. Àngels Jover**-: Okay, so I will bring Michael on stage. And Robert, I am going to need to change you for Michael.\n\n**Matthias Benkort**-:  Yeah, or I can drop as well. Oh, okay. That already dropped.\n\n**M. Àngels Jover**-: Michael Liesenfelt, right?\n\n**Matthias Benkort**-:  Yeah.\n\n**M. Àngels Jover**-: Connecting. Hello, Michael.\n\n**Michael**-:  [crosstalk] your audio?\n\n**Matthias Benkort**-:  We hear you. A bit low, but we hear you.\n\n**Michael**-:  Excellent.\n\n**Matthias Benkort**-:  Okay.\n\n**Michael**-:  Right, should I launch into a brief introduction?\n\n**Matthias Benkort**-:  Yeah, more like describing what's the intent behind, and maybe if hardly also aware of the other CIP that exists, and let's also try to address similar issues, so maybe the key inferences with that.\n\n**Michael**-:  Sure. There are many prior CIPs, I've referenced them much later in the document, but this grew from looking at the Cardano Network as a whole and realizing that there was a disconnect between the game theory and the game reality. And then upon a paper review, I realized that the RSS paper considered multi-pooling as a Sybil behavior, and we just won't simulate our players in the models with the capability of spooling up more than one pool per player, which, if I was the reviewer of the paper at the time, I would've kicked it back and said, \"Each player can delegate to somebody else, make one pool, or make more than one pools.\" That oversight in the game theory has led to the proliferation of multi-pools in defiance of any hope of changing the K parameter.\n\n**Michael**-:  Instead of complaining about it, I decided to start investigating and looking at the historical background of who's had thoughts on this issue, what could be a potential solution forward, and there were plenty of forum posts, other CIPs, that have each taken a little bit different edge. I'm not the first to mention pledge leverage. There are concepts of crafting a leverage parameter. Many of the prior equations included higher order relationships, included higher order curves, included due factors, included greater complexity. And I decided I was going to be a little crazy and instead, simplify it so there was nothing to hide anywhere in the equation, anywhere in the field of outcomes. The relevant document's probably the readme.md, and that contains the long narrative.\n\n**Matthias Benkort**-:  Okay. Thank you.\n\n**Michael**-:  And it may be good to view it. Yeah, there we go. From a prior CIP editors meeting here, I learned that with certain technically deep topics, we'll need to come up with and propose external reviewers. That's probably one of the first steps is find out a great list of peer reviewers that are relevant and engaged and have done prior work that could add value to a review. I've started that list. I would definitely love any additional names to go on that list. That's probably one of the first starting points.\n\n**Matthias Benkort**-:  Yeah, indeed. I've already forwarded your documents, by the way, to all the engineering crew at IOG, I at least the ledger one, or exactly, people work on the ledger and [inaudible] words. Also brought that to the attention of the research team. We are expecting some feedback on that and the discussion to start. I think we can remove Tim from the list, too, although he would love that. I'm not sure Tim would be the best person to review any of the technical stuff we have.\n\n**Michael**-:  All right. I purposely didn't put you on the list either because I considered you as an editor and maybe not as a reviewer.\n\n**Matthias Benkort**-:  Yeah. We're going to review from a editor perspective, the whole proposal. It makes sense whether it respects or not the holes and whatnot. And I can definitely review it with my engineer hat, but I'm definitely not the best person to review that. Kevin say, \"Yeah, the ledger team is interested in this indeed.\" We've got pretty good feedback so far, so I will chase a bit people to see if we can get at least one person to get the conversation started from the IOG engineering, maybe also one person from the research side. I think we have Sean here as well, who maybe has also an interest in participating in a conversation. Tobias also, I recall he made an extended post on the Cardano forum on this topic. I think he even made a CIP or not yet submitted, but he had the plan to, at least. Yeah, definitely also good. I'm not sure if Colin has seen the proposal, but we can also ping him.\n\n**Michael**-:  His initial Cardano forum thread is what spurred me to decide to write the CIP, especially when he said, \"We at IOG here, we could be more aggressive with how we game rewards and financing from our current stake.\" And I'm like, it's exactly what we need to prevent one actor deciding that they need to be able to take a more aggressive stance against the rest of the community.\n\n**Matthias Benkort**-:  Yeah, yeah. That's one, it's definitely something we want to discuss, but I'm not sure we will just discuss it on the next weekly meeting just because the discussion on this one will take likely a bit of time. This is one of the CIPs that might stay open for a bit. It would be good maybe to really see if we can have a more structured way of reviewing this one, because it's quite deep in the game theory. And in the protocol changes, we might want to have review sessions with a bunch of people that are listed in that CIP.\n\n**Michael**-:  At a high level, I've crafted the name specifically, I started out realizing that decentralization is a Shelly-era concept, but I am not expecting this to be done immediately or soon or fast. And that's why Voltaire is in the name because this may actually take more community review and community governance, and might get implemented next era rather than now. That's why it's actually named the way it is.\n\n**Matthias Benkort**-:  Yeah, definitely. And right now, I'm just thinking about first having good conversation on whether or not it makes sense and whether or not it is sound. And then there will be a second round of discussion on when does this get implemented and how, or by whom. Here's that thread on... Yeah, maybe we can put those threads on the CIP itself, comment it on the pull request to keep track record of those other discussions.\n\n**Michael**-:  There's a conversation already starting that is getting robust.\n\n**Matthias Benkort**-:  Good, good. Yeah, the one on the-\n\n**Michael**-:  Also, question, as we move to Voltaire and pull in more community support and more community input, where should the official place for community support and non-technical support or oppose come in? I started collecting them on the Wiki page of my submission, but is that the right place? Is that the best place? Obviously, the Wiki is disabled for the main repository. Or a better place.\n\n**Matthias Benkort**-:  Yeah. That's a good question, and unfortunately, not something I can answer. That's something we keep on repeating on the CIP meetings, but the CIPs are often interpreted as a governance mechanism, but the CIP have no governance absolutely on the protocol. They are about collecting solutions to problems and agreeing on the technical soundness on solutions. The thing is, they are not authoritative of anything. They won't tell you that these things will happen or that this is the roadmap or anything. It's more like the collections of possible solutions. And if we even need to solve a particular problem, we can pick among that collection. And it's also a good way to collaborate on standards across different platforms and wallets. But then, gathering the community sentiment, more like the community votes on a particular decisions, that's something more for catalysts, really, and you could very much see that both works together.\n\n**Matthias Benkort**-:  How have a first CIP that is technically reviewed, it's been peer reviewed, approved, and then move to the catalyst land, say, \"Well, that proposal is about implementing CIP XXX,\" and there is where you can actually get community voting and chipping in on, yes or no, I want this, I think this is a good thing. And the nice way of going that way is that, from the community perspective and the non-technical people, they can trust in the CIP process to have done already the technical review and the technical soundness of something. If it's been approved, it's been reviewed by both editors and the community and experts, then you can say, \"Okay, it's already a pretty strong catalyst proposal itself, and now it's about implementing it.\" Only thing we need to look at is whether or not the budget maybe makes sense and if the team that is proposing to implement it also sounds capable of doing it, basically. Yeah, I hope this is a good answer for you.\n\n**Matthias Benkort**-:  Okay, for this particular one, we'll just keep it in the loop for now. I really think it's one of those CIPs that should deserve proper review meetings with a bunch of parties. I will see if I can make that happen, or if not, I will try to find someone that can make that happen. I see the conversation anyways already going on the community forum. Now, it's more a matter of digesting also the conversations and bringing those updates to the CIPs. I'm not sure how available also you are to make those updates and work on it, but I guess that's something we can figure out along the way.\n\n**Michael**-:  I have been making additions and revisions and changes, and will continue to do so. Maybe not every day, but maybe every few days.\n\n**Matthias Benkort**-:  Yeah, that's good. Yeah, if you can only work on that, for instance, once every two months, that will be a bit longer to iterate. \"Talk to me, Matthias, if you need IOG involvement.\" Of course, Kevin, talking to you every day. Or not every day, okay. And yeah, we can definitely try to follow that up, Kevin. Thanks. What else do we have? I'm pretty sure we had also a similar proposal from Tobias, actually. I've seen it on the forum, but I'm not sure if you opened the pull request or not already.\n\n**Michael**-:  Not yet. We've been in communication about it. There are some structural differences between our [inaudible] the R over one plus alpha term end, and define an extra perimeter L, whereas I decided to take out the one over one plus alpha term and recast alpha entirely.\n\n**Matthias Benkort**-:  Okay. We might actually end up with only one proposal maybe, or are you just still, do you know if he's still thinking of making a competing proposal and maybe [crosstalk]?\n\n**Michael**-:  I'm not sure. I want to make he's got the opportunity to submit it and submit a pull request, if he wants to, and anybody else, and any other prior formula change, equation change, because in review, all of these different variations should be tested together as a pool with the same methodology, including the old equation at a couple of different parameters. And I included a section of my CIP on how we should change the paradigm of how we analyze these proposals going forth.\n\n**Matthias Benkort**-:  Yeah. Okay, okay.\n\n**Michael**-:  It should be an inclusive process.\n\n**Matthias Benkort**-:  Yeah, definitely. But the challenge actually is really to, as you just said, to find maybe a common way of assessing them and judging them according to some common criteria as to then make a decision. Yeah, and maybe there is not one good answer. Maybe there are multiple ones. And then, at some point, there will be a choice to be made. And that's exactly why we have catalysts also, so the community can choose eventually.\n\n**Michael**-:  I'm also fully aware that, as we analyze this and peer review this, there could be a hybridization of ideas that would occur, a cross-pollination between different CIPs, and the form of the reward equation could change to something new that hasn't even been considered yet. It's not impossible.\n\n**Matthias Benkort**-:  Yeah, yeah. And it's not impossible so that all those CIPs end up merging into one common proposal that has one common structure, which will be from the ultimate goal. And it will make the choice wager for the community as well, if you have only a choice to vote between one thing and one thing that's easier. But yeah, so we'll see. Okay. What else do we have on the table? Maybe tech, tech, tech. \n\n#### PR224\n [PR224 - Add Proof of Existence record label to registry.json](https://github.com/cardano-foundation/CIPs/pull/224)\n\n**Matthias Benkort**-: I see there is a small pull request, 224, which is adding a new label to CIP 10. That's something Robert has already comment in them. Yeah, okay. That was good comment. Are you still there, Maria, by the way?\n\n**M. Àngels Jover**-: Yes, I am here. Don't you see my screen?\n\n**Matthias Benkort**-:  Nope. We don't anymore. We see Michael.\n\n**M. Àngels Jover**-: Oh. I didn't realize. It's this one, right?\n\n**Matthias Benkort**-:  Yeah, so a small addition to the registry for which we typically ask for also a justification for that. It's a proof of existing claims.\n\n**Matthias Benkort**-:  I'm not quite sure to understand the goal of it, but at the same time, it's no particular... It's just an addition to the registry which needs to be public and extended. Nothing against it, not sure what Robert and Sebastian thinks of it, if they have also got time to look into that, but it's small one enough.\n\n**M. Àngels Jover**-: Rob or Sebastian, any of you on to the common stage? Robert says, \"I am okay endorsing it if it's a label people can understand and use or are already using.\" And Sebastian says there's nothing on his side.\n\n**Matthias Benkort**-:  Yeah. Okay, so it also boils down to a conversation we had in the past on CIP 10. Maybe having a slightly clearer process of what it means to add stuff to that CIP 10, or if there is new conditions to it, we typically just ask people to justify the hashing on behind their label and why it would be useful, but that's beyond that.\n\n**M. Àngels Jover**-: You have approved it, right and it is going to be merged.\n\n**Matthias Benkort**-:  Yeah, this is really a minor update on that CIP 10, so no particular issue.\n\n**M. Àngels Jover**-: You have both approvals, already.\n\n#### PR241\n [PR241 - CIP-0989? | ISPO KYC_CDD](https://github.com/cardano-foundation/CIPs/pull/241)\n\n**Matthias Benkort**-:  Yeah. We put the label, CIP 10, new entry. Okay. Then we have a CIP, so PR number 241, which is a CIP from John Woods, so IOG Director of Cardano Architecture, he's proposing new primitives or... This one is interesting because it seems to be about providing some form of identity authentication mechanism for tools, but I'm not sure if the motivation really came from SPO or not. Would be interesting maybe to bring it to the next SPO call that often happen on Discord and see when we have SPO commenting on that, since this is something directly affecting them or providing a benefit to them.\n\n**Matthias Benkort**-:  Yeah, I'm not sure if anyone knows, or maybe Kevin, you know, when is the next SPO call planned? Yeah, I mean he's Robert, that's why I'm wondering. And I think that will be a good first step before doing anything with that proposal first, show it to the SPO and see what people think of it and if they actually also see a use case or benefits in this approach. Yeah, okay. Thanks, Robert. That would be nice. Otherwise, we can probably share it with a bunch of SPOs already that we know and try to get some community sentiment. I will ask John, or we can ask John also to share it on the forum, or I think there is still some activity also there, and people are looking to the forum a bit more than the report, I think.\n\n**Matthias Benkort**-:  (Silence).\n\n**Matthias Benkort**-:  Okay, so I'm just telling John to maybe, so what you just said, commenting on the pull request to see if we can bring it to the next SPO call on Discord, and also share the link and the CIP on the Cardano forum to get some extra attention there. That would be interesting.\n\n**Matthias Benkort**-:  No confirm date for the next meeting. We are on roughly four week cycle, that's okay. The last one was last week, so this one could take a bit of time before we revisit it. We can maybe put it on triage for review for, not the next be biweekly, but the one after that.\n\n**M. Àngels Jover**-: In a month, right?\n\n**Matthias Benkort**-:  In a month. Yeah, in a month from now, and have the conversation going with the SPOs in the meantime.\n\n**Matthias Benkort**-:  (Silence).\n\n**M. Àngels Jover**-: Would we have time to review anything else?\n\n**Matthias Benkort**-:  Maybe, but the question is more what is left to review from what we had. We could definitely... Oh, maybe not today, but start including also the issues in the reviews because as we said last time, there is not 15 issues that have been opened on the repository, and it's not really something we anticipated in the first place. We're mainly thinking about pull requests and how people would just submit CIPs as pull requests, but there are also discussions or side discussions happening in issues which are similar to what's the kind of conversation happening on the Cardano forum.\n\n#### PR188\n [PR188 - CIP-36? | Update CIP-15 to support multi-delegation](https://github.com/cardano-foundation/CIPs/pull/188)\n\n**Matthias Benkort**-:  Oh yeah, right. It took Giacomo suggesting to look at CIP 36, that we discussed last week. There was a bunch of updates to make to that one. It was the initial extension of the meta delegations that was then extracted as a separate CIP, but the author, Mark, got unavailable, so we brought it back to the original author. What we discussed last week was that we'll move it back, get a few updates to it which make the CDDL format forward compatible and have also the derivation path specified in the proposal. I did add the derivation path, and I think Giacomo, you've been working on the CDDL a bit. Yep, so then I think it's good to go.\n\n**M. Àngels Jover**-: Which PR is this one I don't know which on it is\n\n**Matthias Benkort**-:  188. It's a pretty old one. It's been over multiple bumps, this one.\n\n**M. Àngels Jover**-: This one right here, right?\n\n**Matthias Benkort**-:  What is the new CDDL nowadays?\n\n**Matthias Benkort**-:  (Silence).\n\n**Matthias Benkort**-:  Maybe we can bring also Giacomo on the screen just to walk us through the updates.\n\n**M. Àngels Jover**-: Sure.\n\n**M. Àngels Jover**-: (Silence).\n\n**M. Àngels Jover**-: Inviting Giacomo.\n\n**M. Àngels Jover**-: (Silence).\n\n**M. Àngels Jover**-: Hey, Giacomo, you are on screen.\n\n**Matthias Benkort**-:  Can you hear me?\n\n**Giacomo**-:     Yeah.\n\n**Robert Phair**-: : Yes.\n\n**Giacomo**-:     Yeah. I've looked at the consideration that were posted on the CIP at... I've select the amended, the wording, but CDDL is still the same as before, because I believe we can make that forward compatible by requiring all new credential to have a tag associated with them, but keep the stake key unpacked so that it's compatible with all CIP 15, that would allow us not to require everyone to register again, which is a concern on our side.\n\n**Matthias Benkort**-:  Okay, because at the moment, any registration maybe in the past is valid for any subsequent round.\n\n**Giacomo**-:     Yep, exactly. It would be a bit expensive if we plan multiple voting rounds to have everyone to register for each one of them.\n\n**Matthias Benkort**-:  Yeah, and that would be more expensive. That would just be per UX, in a way. Okay, so that's a good point, but yeah, it's also possible to support both formats and have the backward compatibility while also making room for the next steps.\n\n**Giacomo**-:     What would be the advantage?\n\n**Matthias Benkort**-:  Well, you just said avoid re-registering, right?\n\n**Giacomo**-:     No, I mean in supporting both formats, what about we just say, there's this untagged version, there is just the default, and it's the-\n\n**Matthias Benkort**-:  Yeah, exactly.\n\n**Giacomo**-:     For about everything else, CIP 36 is already compatible with CIP 15, or there are defaults, sensible defaults, which makes it compatible.\n\n**Matthias Benkort**-:  Yeah, okay. I guess it would just be a question for another CIP or an update later on, on how do we introduce a broader variety of credentials without actually also breaking compatibility with existing registration? And we won't probably get away from still supporting the untagged version for forever, just for the sake of backward compatibility. Yes, I can. I think Sebastian also had a few comments on that last week, so I'm happy to prove it on my side. I'm not sure, since it was mostly also Sebastian's concerns, whether or not he is fine with the current proposal.\n\n**M. Àngels Jover**-: Maybe we can leave a last check for next week, next meeting?\n\n**Matthias Benkort**-:  Oh, it was already last check for today, I think. We want to talk to Sebastian in June. Well, I will approve it on my end. We can see offline if also Sebastian is fine with it, and then merged it to move forward with it or not, depending on the outcome. Sebastian said, \"Yeah, as long as made the forward compatible changes to the tech type, and good.\" Well, that's kind of the point of the discussion right now, that the forward compatible changes won't be made in that moment yet because they all also break compatibility or backward compatibility.\n\n**Giacomo**-:     All new changes have attacked, then I think they're good to go. This is forward compatible. We will just have one untagged variant in this type, which will be the stake key.\n\n**Matthias Benkort**-:  Yeah, we can introduce new ones as tagged.\n\n**Giacomo**-:     There's no ambiguity in that.\n\n### Close \n\n**Matthias Benkort**-:  Okay, it's been an hour, so maybe we can wrap up and do a quick recap. We've been through the collateral output proposal, which was already in the last check state, but this one needed to have a right number allocated to it put in a corresponding folder on the CIP and then be merged as a proposal. CIP 37 are mostly waiting on the feedback from the research team. CIP 38, waiting for the author. The author has been pinged again. I've also got an answer from the Discord that they are still championing it, and they will be providing an update soon. Good. The CIP 30 event API, still also on hold, probably abandoned or not really going under all of discussions at the moment, so there is no need to pressure that on our side.\n\n**Matthias Benkort**-:  CIP 42, I'm waiting also for the authors to adjust the status and justify the cost model before being emerged as a proposed CIP, also waiting for the implementation to be available on Plutus. We've also got an introduction on CIP 50 for which we'll want to follow up with our focus group, basically, involving various parties from research, from IOG engineering, from the community also, and they are getting to more discussions on the visibility of this CIP, also comparing it with other similar CIPs and see maybe if we can either convert to one solutions or have multiple solutions that can then be proposed through Catalyst for implementation.\n\n**Matthias Benkort**-:  We also just went through CIP 36, which adds a multi-delegation support for the voting mechanism on chain, or more exactly, the voting registration on chain, so that we can have the catalyst voting happening. Agreed on merging that one as it is, and think about the introducing multi key support or scripts credentials later on. And I think we also added a new entry in the CIP 10 registry. And that is it. Thank you all for joining and see you in a month at this time, or in two weeks on your time zone.\n\n**M. Àngels Jover**-: It will be in two weeks at 9:30 AM UTC. At 8:30 AM, sorry.\n\n**Matthias Benkort**-:  Yeah, correct. No, at 9:30, right?\n\n**M. Àngels Jover**-: I think it's two hours now, UTC, like [inaudible].\n\n**Matthias Benkort**-:  Oh, yeah, yeah, yeah, yeah. This [crosstalk]. Okay, right.\n\n**M. Àngels Jover**-: Thank you very much to all and see you in two weeks or in a month, and have a Happy Easter, those who celebrate it.\n\n**Matthias Benkort**-:  Yeah. Cheers. Bye-bye.\n\n**M. Àngels Jover**-: Bye-bye.\n\n\n---\n## Extra\n\n### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md)\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n"
  },
  {
    "path": "BiweeklyMeetings/2022-05-10.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [May 10 2022 Transcript](#may-10-2022-transcript)\n  * [Triage](#triage)\n    + [PR177 CIP-0005 | Add prefixes for output datum hash and script data hash](#pr177)    \n    + [PR181 CIP30: getUtxos null instead of undefined](#pr181)\n    + [PR182 CIP-1852: fix broken CIP links](#pr182)    \n  * [Last Check](#last-check)        \n  * [Review](#review)\n  * [Discussions](#discussions)\n    + [CIP-0050? | Shelleys Voltaire decentralization update](#pr242)\n    + [CIP-0052? | Cardano audit best practice guidelines](#pr252)\n  * [Issues](#issues)\n    + [PR109 CIP-0003: Broken links on the website](#pr109)\n    + [PR167 A public collateral and tx broadcast service](#pr167)\n    + [PR168 CIP-0027: Covering existing policy locked assets](#pr168)\n    + [PR169 CIP-0030: provide unique wallet identification](#pr169)\n  * [Close](#close)\n\n## Summary\n\nRough transcript of 10/05/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Transcript might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/e/cip-editors-meeting-44) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n**Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n\n**Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n\n**New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \n\nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n**Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n\n**Issues**: Review of the open Issues on the CIP GitHub \n\n**Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  \n\n\n## May 10 2022 Transcript\n**Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, ~Frederic Johnson~, ~Robert Phair~. \n**Guests**: Michael Liesenfelt\n\n\n**M. Àngels**-: Hello everyone. Welcome to the CIP meeting number 44. My name is Marie Àngels, and I work at the Cardano Foundation, and I am here to facilitate this meeting. Today we have Sebastien Guillemot and Matthias Benkort that will lead this meeting as editors of the CIP process. We have here in this \"i\" button the agenda that you can follow. It has direct links to the PRs that we are going to comment. And at the bottom, you have the ask questions button over here that you can use to ask any questions, or you can also add your questions in the chat box. So Matthias tell us, do you want to add anything else to the agenda that was not expected?\n\n**Matthias**-: Yeah, on my side, I would like to add PR 252. Reason being that this is a topic that will be discussed in the next workshop that is organized by IOG in Barcelona. So it was brought to my attention and this is a fairly straightforward CIP in a way, because it just describes best practices. But yeah, that's something we could just maybe have on the topic, discuss and see if people can comment already before the workshop so that the workshop can be a bit more productive.\n\n**M. Àngels**-: Okay. Do you want to add it to the discussion section, or do you want us to start with PR 252?\n\n**Matthias**-:Oh no, we don't have to start with it. We can discuss first the items on the agenda, I think.\n\n### Triage \n\n#### PR177\n [PR177 CIP-0005 | Add prefixes for output datum hash and script data hash](https://github.com/cardano-foundation/CIPs/pull/177)\n\n**M. Àngels**-: Okay. So, shall we start with triage?\n\n**Matthias**-: Yeah, let's go.\n\n**M. Àngels**-: PR177 CIP-0005 | Add prefixes for output datum hash and script data hash. Can you give, Matthias, a brief summary of this PR?\n\n**Matthias**-: Yeah. So we have CIP 5, which has been there for a while, which defines a bunch of prefixes that we commonly use for Bech32 encoding, which is used mainly for short binary data, and to have a way to distinguish them in human readable interfaces. Like that's the encoding we use for address, for instance. And that's why we have this ADDR in front of all addresses, but we use it in command lines for all the things, actually. So tool, IDs, scripts, V-Key hashes, et cetera. And this PR adds a new one, which is for datum and redeemers or more exactly datum hash and redeemer hash, which is used by the, how do you call that again? Hardware devices, right? So ledger and tresor to show on screen, when you have to validate your transactions, the PR is made by Gabriel from Vacuum Labs who are working on the hardware integrations. So I think, yeah, we approved that a while back already. So it's quite an old one. And that's about it.\n\n**M. Àngels**-: So shall be merged this one today?\n\n**Matthias**-: I would say so. I see it has now conflict apparently, so we cannot merge it. So we'll just have to resolve the conflict because there are probably been some concurrent dates on the CIP 5. So not a big deal, but yeah, we'll just merge it. If not during the meeting right after once the conflicts have been resolved.\n\n**Sebastien**-: Can somebody share their screen, just so...\n\n**M. Àngels**-: I am not sharing my screen?\n\n**Matthias**-: Nope. It's a bit black.\n\n**M. Àngels**-: Sorry. Thank you very much for raising that. Shall we move to the next PR?\n\n**Matthias**-:\nYeah, unless there is any objection on that one, but it's been there for yeah, a few months we just forgot about it.\n\n**Sebastien**-:\nYeah. So for CIP 5, if I can just briefly add, so we also have a separate PR related to CIP 5, which adds a reference implementation to it. It'd be good if we get that merged as well. Considering that... Validation is just re-parsing every single file.\n\n**Matthias**-:\nSo PR 251, right?\n\n**Sebastien**-:\nYeah.\n\n**Matthias**-:\nWhich is a reference implementation of what exactly? Of all the prefixes right? Made a package for, an NPM package.\n\n**Sebastien**-:\nYeah. Yeah. It just gives you an adjacent object of just key and value and then it adds comments for you that describes the different keys.\n\n**Matthias**-:\nOkay. No, I mean, that's interesting to have, I guess. Do you automatically sync it from the repo or is it something manual?\n\n**Sebastien**-:\nYes and no. So it generates JavaScript code from what we have in the repo, but what we have in the repo is not exactly machine readable. So you need to like convert from human readable to machine readable and then... [inaudible 00:06:06]\n\n**Matthias**-:\nCould it actually, maybe be also something we could do on the CIP 5 instead of this, this markdown table have a, just a big JSON file actually?\n\n**Sebastien**-:\nYeah. I considered up-streaming this change, let me send the link in chat. So if you open the link in the chat.\n\n**Matthias**-:\nYeah. I'm already on it actually.\n\n**Sebastien**-:\nOkay. Yeah. This is my human readable version of the markdown table.\n\n**Matthias**-:\nYeah. The the machine readable.\n\n**Sebastien**-:\nYeah. And then basically this reference validation takes the JSON file and then generates JavaScript code from it.\n\n**Matthias**-:\nYeah. So yeah. Okay. No issue with adding that as a reference implementation indeed, but I would maybe consider also moving it upstream, the JSON part, like we've done for CIP 10, right. So that we've got something which is machine readable and then with tooling on top.\n\n**Sebastien**-:\nYeah. Considers that the markdown file is easier to read for it to give context.\n\n**Matthias**-:\nYeah.\n\n**Sebastien**-:\nSo I'm not sure if we want to like generate a markdown from the JSON as well, but I'm not sure if we had like a good system for automatically... Generating markdown files. I remember we had this problem previously of like automatically generating files.\n\n**Matthias**-:\nYeah. I'm betting markdown files like that, as it, sorry... JSON files like that as a markdown table could be nice, but yeah, definitely if we want to do generation, that's easier in this direction from JSON to markdown than from markdown to JSON. Okay.\n\n**Sebastien**-:\nYeah. But mostly I would want to check, we don't have any CI resources to generate the markdown from JSON. If we remove the mark down and replace with JSON OEM and generate the markdown automatically.\n\n**Matthias**-:\nOkay. I mean, fine like that, but just, or just comment on that. Okay. So yeah, I think we can just proceed with these two. I will do it after the call. Okay. What do we have next?\n\n #### PR181\n[PR181 CIP30: getUtxos null instead of undefined](https://github.com/cardano-foundation/CIPs/pull/181)\n\n**Sebastien**-:\nYeah, this is a bug in the current CIP 30 spec. Basically we right now specify that the function returns undefined in some cases, but undefined is not a valid JSON value. You can only use null. So basically changes.\n\n**Matthias**-:\nOh. And you can only serialize to JSON, right? Through the web browser API.\n\n**Sebastien**-:\nYes.\n\n**Matthias**-:\nDoh.\n\n**Sebastien**-:\nSo if you pass undefined, it gets silently converted to null. So just to avoid people making bugs just to change this back, please.\n\n**Matthias**-:\nOkay. I can't find it though. It's what number again? It's sorry. It should be the agenda. Yes. But why can I not access it? Ah.\n\n**M. Àngels**-:\nYou can not access the agenda?\n\n**Matthias**-:\nNo, it was me. I was putting an extra S in the URL. Yes. Well, I wish we had proper sum-types, but I guess we won't.\n\n**Sebastien**-:\nYeah. I think this API is kind of ugly anyway, but you know, we can fix it in a separate PR, at this point we can just...\n\n**Matthias**-:\nYeah. Yeah. And there has been discussion recently as well with this wallet connect API, right. This recent and NFT launch of Instagram which uses it slightly...\n\n**Sebastien**-:\nYeah. But that will work very differently from CIP 30.\n\n**Matthias**-:\nYeah. It's a bit of the same spirit though. Oh, except you have this extra bridge in the middle and the way things work on Cardano are a bit different, but maybe there is also room for alignment a bit. I'm not sure if you would simplify anything for external people to integrate. I think CIP 30 is mostly fine as it is, except maybe the versioning part that we mentioned last time, which I'm still willing to make a pull request for.\n\n**Sebastien**-:\nYeah. But in the meantime, I think we can merge this PR because it's just a small fix.\n\n#### PR182\n[PR182 CIP-1852: fix broken CIP links](https://github.com/cardano-foundation/CIPs/pull/182)\n\n**Matthias**-:\nYeah. It's fixing a inconsistency. So next one, PR 182. No, what is it? Yeah. 182. Which is fixing some broken links yeah. Was approved a while back and we could just go for it. So the issue is that some of the CIPs reference other CIPs sometimes using relative links, which works on GitHub, but don't necessarily work on the website. So it's slightly better to use absolute URLs to make sure that, you know, things works on all platforms. We discussed that briefly on the issue and it's only about one of the CIPs anyway, but that's something we should be a bit careful with when merging new CIPs as well. So we've approved it. So unless someone has anything to say, also I'll just go ahead and merge it. Okay. All good then.\n\n**M. Àngels**-:\nNow I have added to the agenda, some issues. Do you want to review this or do you want to leave them for after the discussion point, which are the CIP 50 and the one you brought at the beginning?\n\n**Matthias**-:\nYeah. Let's first talk about CIP 50 and the audit guidelines first so that we have time. And then if time is left, we can go for issues, which are a bit more minor points.\n\n**M. Àngels**-:\nOkay.\n\n**Matthias**-:\nDo we have Kevin today or not? No...\n\n**M. Àngels**-:\nWe have Michael but not Kevin.\n\n### Last Check \n\n### Review \n\n### Discussions \n\n#### PR242\n [PR242 CIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242)\n\n\n**Matthias**-:\nYeah. So maybe Michael knows, actually. So there was this discussion a few weeks ago to start a study group on CIP 50 with people from IOG and this was something Kevin picked up and was sorting. I'm not sure if it has happened yet or no. It hasn't happened yet Michael, okay. So that's something we'd need to follow up with. I know Kevin did reach out to a few people and it was acting behind the scene to get it done, but yeah, I will just reach out to him. Yes, definitely. Vasil has brought some attention already. But yeah, there are people I think we can, from whom we can pick their brain to just start thinking about that who are not directly involved in Vasil. Okay. I will just reach out to Kevin and ask him if he has any update on that regarding this study group. Maybe you can bring Michael on screen, if just for a short time, maybe you have had also some discussions on the side already or got any feedback that you want to share?\n\n**Michael**-:\nAll right, here we go. There's always many discussions on the side about this particular CIP, the very important CIP in many ways. So this will be continued to be [inaudible 00:16:12] feedback of individuals including yourself.\n\n**Matthias**-:\nYeah. Okay. So I guess this is also one of the CIPs where it would be worth maybe giving some summary of discussions every week. So I haven't gone through the whole discussion thread I admit yet, but I will try to yeah... Post summaries a bit like we did for the... Oh, what was it? The NFT standards. And CIP 30 actually, back in the days. So we get some yeah, regular point of synchronization where we can move the discussions a bit forwards.\n\n**Michael**-:\nThat seems reasonable. And when we want to schedule any kind of meetings or debate or review on the scope of the CIP. I know at a prior meeting, you mentioned doing that in a side channel, in a different format, as long as it's public and anybody can join, that would probably be a benefit.\n\n**Matthias**-:\nYeah. So that's the study group I was mentioning and that's something that could actually be done publicly. I was thinking more initially that this could be a closed study group just to have it review and post actually the notes and the outcome of the meetings on the CIP but being public will also make sense. As a kind of discussion forum, which is just managed by the fixed bunch of individuals. I'm just writing to Kevin and okay. If we don't have anything more for this week, maybe on this one, we can leave it there and yeah. Move to the next item.\n\n\n\n#### PR252\n [CIP-0052? | Cardano audit best practice guidelines](https://github.com/cardano-foundation/CIPs/pull/252)\n\n**M. Àngels**-:\n. So next item, I would say that this is the PR 252 that you wanted to comment, Matthias.\n\n**Matthias**-:\nYes. Oh, more than commenting. Just bring to the attention of the CIP enthusiasts. The audit best practice guidelines. So this was a document that was written mostly by Simon here, in discussion with the various auditing parties that are currently involved on Cardano. And the main idea is to give some general guidelines for DApp developers who wants to have their apps audited by those auditors, such that there can be some form of common format for sharing information on what your DApp is doing. What's the expected outcome while your contract high level interface and sort of make the whole audit process more streamlined. So that means most of what's written in the CIP currently has been reviewed by the auditing parties. And now it's more question of getting that reviewed a bit more by the community, as you know, because this is a two sided discussions. And as I was saying, there will be a workshop organized by IOG in Barcelona next week, actually.\n\n**Matthias**-:\nAnd this CIP would be one of the topics during that workshop. So that's why Simon wanted to get some attention on it. I've already done a first round of review getting some feedback, I think in particular, that there is one part which could be extracted as another CIP even, which is this whole idea of a specification language for the contract interface, a bit like open API, but for on chain scripts, right. Where you can clearly specify or state what's your datum, what's your redeemer, what's your transaction structure invariance and stuff like that, which is touched a bit in these CIPs, but more as a side topic. And that could be an interesting standout in itself to have. And that's all I have to say about it. So we will leave it there for commenting and maybe have it in the next biweekly for a proper review. And then yeah. See how it goes.\n\n**M. Àngels**-:\nOkay. So we are going to move this for review for the next meeting. And I guess there, you will have information gathered in this workshop that you are having next week, right?\n\n**Matthias**-:\nYeah. So hopefully there will be also, yeah. Another batch of update after the workshop. And yeah, since there are mostly guidelines, there isn't much to discuss really on the technical side of it. So I've made a few suggestions just on the editorial aspect, moving some sections round and maybe renaming a few things. But apart from that, it's pretty straightforward. And it's really coming from all the auditing parties. So if anyone wants their DApps audited they'd rather just follow the guidelines.\n\n**M. Àngels**-:\nNice. Very useful and very interesting. So anyone want to comment on this PR?\n\n**Sebastien**-:\nNo, I think it makes sense. I wanted to check, so did she want to merge this before the event or after. The main part of the event is just discussing this document right?\n\n**Matthias**-:\nWell, that's what I told Simon basically, we won't probably get it merged before the event, just because of the whole process happening. And I want to let people have a chance to discuss it, because maybe there are some of the guidelines that don't make sense from a DApp developer perspective. So far it's been mostly reviewed and written with the auditing parties, so I want to give enough time to discuss it. And since this was submitted only a few days ago, I don't think we have... It left enough time until the workshop. So if we have it already, in good shape for the workshop and kind of ready for review that's good enough. Okay. So maybe we can move to a few of the issues, or we have something in the chat, someone who was employed in order to look at your smart contract and review it and add any comments. Thank you very much.\n\n### Issues \n\n#### PR109\n [PR109 CIP-0003: Broken links on the website](https://github.com/cardano-foundation/CIPs/pull/109)\n\n**M. Àngels**-:\nSo if you want, we can move to the issues. We can go to PR 109, just a quick recap. The issues are located here and... Please Matthias correct me if I am wrong, it weren't intended to be used, but as are being used organically.\n\n**Matthias**-:\nYeah, exactly. We didn't really thought of what to do with issue initially. And there are nothing in the CIP process that mentions opening issues, but yeah, just happened. And now we have a bunch of issues to go through, which is also a nice medium of discussions in a way for people that just want to yeah. Be part of a discussions on the CIP and yeah, don't have anything to put in a pull request because that's also something right now we want to see CIP is merged. You don't have much way to comment on it, except if you do another pull request, but sometimes if it's just questions or general discussions, maybe an issue is better suited for that. So I guess we just need to get issues as part of the triage that we do, and make sure that we pick relevant issues every week as well. Or every two weeks. So this one's broken links on CIP 3. What is CIP 3 again? The wallet key generation, the history table.\n\n**Matthias**-:\nYes. I guess this is the same problem as we were stating before that it's probably using relative URLs and here on the website, it doesn't work. So let's check that. Yes, exactly. So we can fix that by using absolute links. And I think this is maybe what Robert is suggesting. Yes. Require absolute path name in the CIPs. So I will maybe add to the to do here, fix broken link. Okay. So we can fix it the same way that was done for CIP 1,851 previously by changing the relative links to absolute links. And we're good.\n\n#### PR167\n [PR167 A public collateral and tx broadcast service](https://github.com/cardano-foundation/CIPs/pull/167)\n\n**Matthias**-:\nNext one. PR167 A public collateral and tx broadcast service\n\n**M. Àngels**-:\nI think that this one Robert commented that there wasn't enough information and there's not been follow up from the author.\n\n**Matthias**-:\nYeah. I guess it was intended to be a draft CIP maybe. But it's very tiny draft and yeah, okay, guess I get the spirit, which is mostly now covered by the extensions that are added to CIP 30, right? The was recently, this discussion around adding this, get collateral functions to this, the CIP 30 interface, which is kind of exactly answering that topic, except it does it locally from the installed wallet than through a remote service. So I think it would just add a label waiting for author. Any comments also on this get quality role? Okay.\n\n#### PR168\n [PR168 CIP-0027: Covering existing policy locked assets](https://github.com/cardano-foundation/CIPs/pull/168)\n\n**M. Àngels**-:\nShall we move? The next one. Okay. PR168 CIP-0027: Covering existing policy locked assets, so what is this one about?\n\n**M. Àngels**-:\nIs there discussion in this one? It's...\n\n**Matthias**-:\nSo it's again about royalties on NFTs that are using the phase one monitoring script. So this is indeed a whole discussions about how to enforce royalties on NFTs. And the idea would be to lock existing assets that have been minted previously into a contract, but with scripts that would make sure that the royalties are enforced correctly on every transactions and exchanged. Then there is whole thread of comments, mostly with a solo I see who was, if I remember correctly, the author of the CIP 27. Or if not just contributing to discussions back in the days, at least.\n\n**Sebastien**-:\nDo we want keep going over these issues? I feel like a lot of them feel like just drafts and I [inaudible 00:31:43].\n\n**Matthias**-:\nYeah. Many of them are draft or just starts of discussions. And maybe they are fine to just leave us as discussions until they make it as a pull request. But then we still need to do some form of issue managements at least to close the old discussions and, do a bit of house cleaning. I don't think we will go through the whole thread of discussions on that one just here. And it hasn't got any updates for about six months also so I'm not sure if the discussion has settled or not in the end. That's one we need to go through and read, and see what's up, but right now it just seems like an idea that sounds to have been abandoned, but I'm not sure.\n\n**M. Àngels**-:\nShall we ping the author and...\n\n**Matthias**-:\nWell, we should read, read the conversation thread first and then see if it's... I would say we have two outcome already, either we ping the other to see if it's still relevant based on what we've read in the thread, or we just close the thread completely, close the issue from being, resolved and installed. And if they ever want to come back to it, they're free to reopen the issue and... Or make a pull request actually acting on it. But first I would like to get a sense of what's being said in the thread.\n\n**M. Àngels**-:\nDo you want to add to the agenda in two weeks to check if you have time to read it or to go and read it, or do you want to it a month?\n\n**Matthias**-:\nI would say for now we don't add it to the agenda. I will read it. And if it's something that we want to add to the agenda in the sense that the discussion hasn't been settled, then yeah. We'll just add it. If not, then I will close the issue with a comment explaining exactly that.\n\n**M. Àngels**-:\nOkay.\n\n**Matthias**-:\nYes, indeed. And as is saying in the chat, there is a lot of controversy over whether you should be able to add royalties to a project which did not need them within the original policy. And this is indeed a topic that's been discussed in the past here. So I think this is part of what the thread will be about. People disagreeing about whether or not a CIP makes sense in itself, but it's also two separate concerns in a way. That a CIP in the end is just a proposal always. And whether or not these proposals end up being adopted by marketplaces and projects, that's a different topic. So if the proposal makes sense from a technical standpoint and it's something that could indeed be implemented and not lead to security issues or stuff like that, that makes for valid proposal. And you may still disagree with the proposal and not implement it, that doesn't discard the proposal from being proposed. But if there is indeed no proposals, then we can just close it. Maybe for just a discussions, like have an idea. What do you think? Bad idea. Okay. Close it.\n\n**M. Àngels**-:\nDo you make any comment on what Matthias just commented or shall we move forward?\n\n**Sebastien**-:\nOnly to agree. \n\n#### PR169\n [PR169 CIP-0030: provide unique wallet identification](https://github.com/cardano-foundation/CIPs/pull/169)\n\n**Matthias**-:\nNext one is PR169 CIP-0030: provide unique wallet identification\nWhen trying to integrate light wallets with the Plutus application backend, I came across the issue where I need to, I need the wallet ID before activating the contract. Yes. And currently the PAB, I guess, uses the wallet ID from Cardano wallet, which is a hash of the verification, the hold verification key of the wallet. And that is indeed not something which is remotely specified anywhere. So, okay. I will maybe just comment on that.\n\n**Sebastien**-:\nOne thing is that we do have a CIP for like a wallet checksum. Which is kind of similar in concepts, right? So obviously it does the same thing, which is a hash of the wallet's public key. And so they can request for a CIP 30 feature that exposes this checksum. Or implement something similar. But I'm not sure if this is enough that could fit the standard requirement for a wallet ID or do they want something more like a key exchange, ephemeral key as an ID?\n\n**Matthias**-:\nWell, from what I read here, I guess the strategy is really just to have an identifier for the wallet, which is unique enough for wallet. So probably the checksum would also be sufficient, but maybe what form would it take to checksum? The question is, the checksum is meant to be represented as image right, but you can also just represent it as a sequence of bytes.\n\n**Sebastien**-:\nYeah. There's an image format and there's also a text format. The text format is like a characters line, I think. So it obviously has a lot of quotients that should be enough.\n\n**Matthias**-:\nSo I guess that there is really two questions in one, in a way, there is what exactly is the ID format and specific used by EV and Cardano wallet currently. And the second question is, what kind of ID do we want to use more generally speaking for wallets? And that's something which could be, for instance, part of CIP 30, indeed. You ask for wallet identifier, and you get something which is in the same format. That could be the checksum specified by CIP 4, or that could be indeed the wallet, the ID used by the Cardano wallet at the moment, the advantage of using the CIP 4 one is that it's already specified. So we've already got it out there. So we can just point to this one. And if we want to use the same as Cardano wallet, then there is a small CIP to write.\n\n**Matthias**-:\nOr at least this part of the specifications to write. It's not much right. It's basically just, what I've written as a comment here. So I'm not sure it's worth a whole CIP but it could be part of the CIP 30 to say that's, but this suppose also that a wallet is using a hierarchical scheme, or at least some key that is following the key generation from CIP 3, which I think must wallets do, if not all. I know Nami is a bit special in that regard, but I think they still follow the same derivation tree. Right. They just happen to use only one key of that tree.\n\n**Sebastien**-:\nYeah.\n\n**Matthias**-:\nSo in that sense, yeah. They, they could all be using the wallet ID from the Cardano wallet. I'd like the checksum in a way, especially because it also come with this image part. And then you can think of all sort of flows where upon validating or signing a transaction, for instance, you can display again, the checksum just as an anti...\n\n**Sebastien**-:\nOne idea we had for [inaudible 00:41:24] in the past is that we had this checksum, right?\n\n**Matthias**-:\nYeah.\n\n**Sebastien**-:\nBut we also, at some point we're considering some sort of way to connect your transaction metadata to Dropbox or something similar. So you could have off chain transaction metadata that's local due to you. But to do this, you wouldn't want to upload the unencrypted data, you want to encrypt first, but we don't want to encrypt it with your account key because then to approve the encryption, you would need to provide the account public key.\n\n**Sebastien**-:\nSo we had this idea of coming with a new derivation path with a different purpose. So if you have the root recovery phrase, then you could generate a different key path, which would be like a utility key path. With the utility key path, you could have the wallet checksum key used for the wall identifier and then a wallet encryption key use for off chain, transaction information, and so on. And so make it slightly easier for people to cope with standards in non complicated ways, instead of always relying on the master public key.\n\n**Matthias**-:\nIn CIP 4, what key is used here to compute the checksum? Is it directly coming from...\n\n**Sebastien**-:\nThe public key.\n\n**Matthias**-:\nThe root public key as well?\n\n**Sebastien**-:\nNot the root public keys, it's the account public key.\n\n**Matthias**-:\nOkay. The account public key. Okay. So you have one checksum and per account, not per wallet in the end.\n\n**Sebastien**-:\nYep. Because the main reason that was created was to make sure that users are restoring the right wallet. [inaudible 00:43:15] the account they were restoring is correct.\n\n**Matthias**-:\nYeah. But CIP 30 operates at the level of wallets.\n\n**Sebastien**-:\nNo, it's still account based.\n\n**Matthias**-:\nStill account based?\n\n**Sebastien**-:\nYou're getting addresses for an account. You sign with an account.\n\n**Matthias**-:\nAnd okay. Then it's up to the wallet to decide which account I guess, because there is nothing in API that's that lets you select the account.\n\n**Sebastien**-:\nYeah. It's when you enable CIP 30 the wallet will show you a dropdown asking you which account you want.\n\n**Matthias**-:\nOkay. So it could still work for that then.\n\n**Sebastien**-:\nYeah.\n\n**Matthias**-:\nOkay. The idea is clear, but there is the question of making it a proper extension to CIP 30. At the same time, last time we said, we might want to sort of freeze the CIP 30 as it is now and have new extensions come as new CIPs just for the sake of having one core, which is fixed, but this thing feels also quite core in the end. So it could be just added before we freeze everything. Yeah. Okay. So from me, at least I would be quite in favor of extending the CIP 30 with a `getWalletId` or `getWalletChecksum` functions that would implement CIP 4, and have that as a the wallet ID, if it's ever needed by a DApp for any form of identification. Hmm. It's interesting 204, but we cannot actually do that with add to 5519. We can do it to convert to 5519. So we need to convert or translate the key, which is not unfeasible, but it was not quite recommended back in the days.\n\n**Matthias**-:\nAnyway. Okay. So I guess that's about it for these issues. The author also hasn't been quite responding for a few months, so I guess we can just put it as waiting for author for now and see if... Yeah. Maybe make a pull request to extend CIP 30 and add this checksum to it.\n\n**Matthias**-:\nOn a side topic or coming back to the CIP 50 topic. Kevin just told me basically has pinged a bunch of people, has got in touch, but for now indeed all the bandwidth is taken for the Vasil hard fork. And therefore there is not much people available from IOG to review that. So we might as well just start a study group without IO and get various people from the community. I think it's already started anyway on the issue itself on the pull request itself.\n\n**Michael**-:\nAre you suggesting a Crowdcast fork in some way?\n\n**Matthias**-:\nNo, but that's actually a nice segway to one thing we need to announce as well. We want to move away from Crowdcast to Discord. We have set up a Discord server for the CIP. And in there, so there will be voice channels available and we could definitely use one of them to discuss the CIP 50. So yeah, as a kind of fork of the current biweekly, or more as a yeah... Side meetings that could be done there. Maybe we can already share the link to the Discord.\n\n**M. Àngels**-:\nYes.\n\n**Matthias**-:\nBecause the next biweekly, and ones after would be held on Discord, at least for starter, we have also things in place to record them and they will be published on a YouTube channels. And will have also then the proper chats on this call as well to discuss. And we'll be able to have more people onto on the speaker side, if needed, as we've been a bit struggling with that in the past where people had to jump on and off the voice spots on the broadcast.\n\n**M. Àngels**-:\nI am getting the invite to share.\n\n**Matthias**-:\nI will also share it then on Twitter later on, and we possibly have a list of all the people that are registered to the Crowdcast meetings currently. I'm not sure if we can reach out to them through some kind of mailing or something, but we should also put it on the readme, I think, of the CIP repository so that it's available in place.\n\n**M. Àngels**-:\nThis is the channel, and here you have the invite. And as Matthias said, we are going to share this in Twitter, right, and identify all the attendants.\n\n**Matthias**-:\nYeah. So try to reach as much people as possible with this because the next biweekly will be done on this...\n\n**M. Àngels**-:\nWhat I was thinking is that maybe we can create an event in Crowdcast because we are going to maintain the subscription while we are testing Discord. And in the event... At the invite link and said that it's going to be held on Discord.\n\n**Matthias**-:\nThat's a good idea. And at least maybe just jump on the Crowdcast for the first, like two minutes and tell it to people who have missed the announce, at least for a few weeks. That could be, yeah. Good idea.\n\n### Close \n\n**M. Àngels**-:\nPerfect. Matthias, do you want to wrap up the session with a summary of what we have talked about today?\n\n**Matthias**-:\nYeah. So let me go back through the links. So we had CIP, a new prefix for reading redeemers and datum to CIP 5. We agreed on merging. That pull request currently has conflicts, so we just need to resolve the conflicts first. Then there is a small bug fix in the specification of CIP 30, where we have to use null of undefined, because ultimately it needs to be JSON compatible. A bunch of broken links also that were fixed for CIP 1852 and also for CIP 3. So not fixed, but mentioned, and we will fix them along the way.\n\n**Matthias**-:\nWe discussed a bit CIP 50. So there has been quite a lot of discussions happening on the pull requests, which we would need to go through. There is not much movement on the study group from IOG and research on this area, mostly because of the upcoming hard forks are taking all the bandwidth. I'm in touch still with Kevin on that to get this happening. Otherwise we can already get started on the new Discord with this. What else we discussed, went through a few issues. Most of them were quite old actually. So we haven't got news from authors for a bit. There is one in particular that we want to go through and read because there is a quite whole thread regarding NFT royalties, which is a quite controversial topic, indeed.\n\n**Matthias**-:\nThere is one other, which was quite interesting about providing a wallet identification mechanism and adding that to the current CIP 30 API. So we discussed maybe using the checksum specification that come from CIP 4 and have that required as one of the functions available in the API of CIP 30. And finally, I think we discussed pull request 252, which is the Cardano audit best practices guidelines, regarding... So guidelines for people that want to get their DApps audited. There will be an upcoming workshop with pretty much all the auditors, I think in Barcelona organized by IO and the CIP will also be discussed there. So if there is any feedback to provide, that would be good to do it before that. And that's it I think.\n\n**M. Àngels**-:\nYes. Next meeting is going to be in two weeks and it's going to be in the US time zone. It's going to be at four UTC and it will be held on, let me check the day, the exact date, May 24th, 4:00 PM UTC.\n\n**Matthias**-:\nYeah, on Discord. But still maintain the Crowdcast invitation links, at least for a few biweekly meetings still.\n\n**M. Àngels**-:\nThank you everyone to join us today and have a nice day and week, bye bye.\n\n---\n## Extra\n\n### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md)\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n"
  },
  {
    "path": "BiweeklyMeetings/2022-05-24.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [May 24 2022 Transcript](#may-24-2022-transcript)\n  * [Triage](#triage)\n    + [PR241 CIP-0989? | ISPO KYC_CDD](#pr241)    \n    + [CIP-0044? | Additional factors for NFT market verification](#pr226)\n    + [CIP-0037? | Dynamic Saturation based on Pledge](#pr163)    \n    + [CIP-0039? | Smart Contract Software Licenses](#pr185)\n    + [CIP-0046? | Prepay Min Fixed Fee](#pr190)    \n  * [Last Check](#last-check)        \n  * [Review](#review)\n    + [CIP-0050? | Shelleys Voltaire decentralization update](#pr242)\n    + [CIP-0052? | Cardano audit best practice guidelines](#pr252)\n  * [Discussions](#discussions)\n    + [CIP-0014, CIP-0015, CIP-0016, CIP-0025, CIP-0028, CIP-0029, CIP-1852, CIP-1853, CIP-1855 status updates. ](#pr256)\n    + [Bootstrap first draft of the Plutus contract blueprint](#pr258)\n  * [Issues](#issues)\n  * [Close](#close)\n\n## Summary\n\nRough transcript of 24/05/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Transcript might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n**Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n\n**Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n\n**New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \n\nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n**Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n\n**Issues**: Review of the open Issues on the CIP GitHub \n\n**Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  \n\n\n## May 24 2022 Transcript\n**Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, ~Frederic Johnson~, Robert Phair. \n**Guests**: \n\n**M. Àngels Jover**:  Can you give me a few minutes? I will connect with Sebastien, Robert, and Matthias.\n\n**M. Àngels Jover**:  Hi, sorry. I thought that by default you weren't on mute.\n\n**Robert Phair**: Oh. Can anybody [inaudible 00:02:51] ? My mute button that away. Can anybody hear my voice?\n\n**M. Àngels Jover**:  Yes, Robert.\n\n**Robert Phair**: Okay, thank you.\n\n**M. Àngels Jover**:  We hear a lot of background noise. Maybe we can do something. Let me...\n\n**Robert Phair**: I have just one question; how do we send text messages while we are looking at each other's faces here?\n\n**M. Àngels Jover**:  I would use the general channel to ask questions.\n\n**Robert Phair**: Okay. To open a separate window, yeah. Okay. I'll have to duplicate this tab and then... Okay, I'm using the web-based Discord. Okay. Yeah, I'll see if I can get that to work. Okay, I'm muting my mic when I'm not talking, because I can't suppress this noise. Okay, thanks.\n\n**M. Àngels Jover**:  This is going to be a test. This is the very first time that we are doing the CIP meetings on Discord, so please bear with us if everything is not going as smooth as we expect to go in a few weeks. So welcome everyone. This is CIP meeting number 45. I am going to share the agenda with all of you. It is in the event...\n\n**M. Àngels Jover**:  Oh God, so many new things today. Well... I'm sorry.\n\n**M. Àngels Jover**:  Yeah.\n\n**M. Àngels Jover**:  Well, I have the agenda in another place, so don't worry. We are going to rapidly sort this out. We have today with us, Sebastien Guillemot, Matthias Benkort, and Robert Phair as editors. In the agenda today we have in triage PR241 CIP-0989? | ISPO KYC_CDD. So I'm going to share this and maybe some of the editors want to make... A brief summary on it. Matthias, Sebastien, I haven't heard you, but I have unmuted you. Can you speak? Are you able to speak?\n\n**M. Àngels Jover**:  Sebastien is typing.\n\n**Matthias Benkort**: Oh actually, yes, maybe.\n\n**M. Àngels Jover**:  Good.\n\n**M. Àngels Jover**:  I don't think it's my mic. Okay. So do you want to start with this first item on triage?\n\n### Triage\n\n#### PR241\n[PR241 CIP-0989? | ISPO KYC_CDD](https://github.com/cardano-foundation/CIPs/pull/241)\n\n**Sebastien Guillemot**:  Yeah. So, whatever, back to getting stuff set up. Yeah, this was proposed by IT, as a way for basically people who participate in ISPOs to KYC themselves, I did not see anything particularly wrong with the proposal itself, other than the fact that it uses LaTeX inside Markdown. But I think that will actually coincidentally support this very soon, if not already... Maybe it's already set. I think the main thing for this is that we probably need to Stake Pool input on this one, because they're the main people that will be leveraging this. And so far, there hasn't been any Stake Pool that has... Commented on this. I know that Robert, you reached out to SPOCRA to see if they had any input on this. Did you hear back from them yet?\n\n**Robert Phair**: Yeah. It's mainly to just see if they had any objection. And there were probably one or two Stake Pool, if I know, that would've had... If there were objections for privacy implications, they probably would've raised their voice about it. I think like you said, it's just a friendly for voluntary participation. So it is in the KYC which can be... For us, it will be mandated for projects anyway, and they just want a reasonable way of doing it. But I think the fact that there were no objections, it sort of implied consent. I haven't been able to take anything, not farther than that.\n\n**M. Àngels Jover**:  I think that communication is going to be challenging today, because there's a lot of noise Robert from your side.\n\n**Sebastien Guillemot**:  Yeah Robert, can you try getting the native Discord application instead of the browser version? It will probably help improve the audio quality.\n\n**Sebastien Guillemot**:  Okay. So what do we want to do with this CIP then? Do we want to wait until we get more feedback? I mean, I personally do not find issue with it. So if there isn't any feedback from everybody else, I don't mind... Moving along. It'd be good to get some feedback from more than just one person on this though. I do know that has some cryptography as well. Personally, I did not see an issue with the cryptography being used; I think it's fairly standard. But I'm also not a cryptographer either, but we've done stuff similar to this in other CIPs in the past. So I don't think this is an issue.\n\n**M. Àngels Jover**:  So shall we leave a little bit more time to get more comments and maybe discuss it in a few weeks Sebastien?\n\n**Sebastien Guillemot**:  Yeah, it could be good to get least one person who's not... Who is with Stake Pool to comment on this, it would be my preference. You could possibly ping IOG to have them more explicitly get feedback on this. Because usually people post their CIPs in the Cardano forums or some other location if they haven't done any of this. So we also can't really blame people for not engaging with the CIP.\n\n**M. Àngels Jover**:  So what would be the next steps? Reaching someone of at IOG and try to get them involved with this one?\n\n**Sebastien Guillemot**:  So this proposal is by IOG. They're the ones who wrote this proposal. So it would be asking IOG to more practically reach out to Stake Pool for comment to see what they think this.\n\n##### Discord discussion on the PR\n\n**rphair [COSD]**: That sounds good to me & I'll send another (second) call to SPOCRA but I agree it would be good to ask Ben O'Hanlon to PUT IT IN THE SPO NEWSLETTER\n@ IOG\nBen is usually responsible about getting ahead of these issues\n\n#### PR226\n [PR226, CIP-0044? | Additional factors for NFT market verification](https://github.com/cardano-foundation/CIPs/pull/226)\n\n**M. Àngels Jover**:  Okay. So I have taken note of that. This was opened by John, so maybe comment that with him. So if you are okay, we can move to the second item on the agenda, which is PR226, CIP-0044? | Additional factors for NFT market verification. We can see this here. Maybe Sebastien, can you make a little summary of this one? This was requested by Matthias to have this PR commented in this session today.\n\n**Sebastien Guillemot**:  What did he recommend?\n\n**M. Àngels Jover**:  He pinged me and said that it would be good to review this one. Here we have the comment. Let's maybe have this one on the agenda for the next CIP meeting. I feel it kind of missed to include it earlier. I don't know if Matthias is having issues with his mic.\n\n**M. Àngels Jover**:  Maybe I haven't unmute him.\n\n**M. Àngels Jover**:  I don't know why I can't unmute him. Oh, I mean real-time issues, right? We can always go back to Crowddcast if this is still happening. Hi Matthias. Now I can hear you. Or almost.\n\n**Matthias Benkort**: This almost works actually.\n\n**M. Àngels Jover**:  Yeah, yeah. Clear and loud, yeah.\n\n**Matthias Benkort**: Okay. Okay, good. So yeah, I just said that at the time to bring attention to the CIP, just because yeah, it was hanging there, but we sort of missed it completely. So I don't think of necessarily doing a complete review of it, or a need to take any actions on it just yet. But it's more to... Yeah, to track this and bring it to the light.\n\n**Sebastien Guillemot**:  Yeah. So this CIP will not run into the same discussion we had for CIP 25, the NFT standard and the same discussion we had for... I forget the number of the one for the fungible token standard, which is to say that some tokens are already minted, but want to add this data after the fact.\n\n**Sebastien Guillemot**:  So the problem with this proposal is that, they're basically saying, \"Oh yeah, you'll use the same policy for... And you made it a 808.\" This doesn't help existing projects, and doesn't describe what happens if somebody overrides their existing media in the future. But this is more of a Cardano issue than an issue with a specific proposal. And I'm not sure if there's anything that they can do with this.\n\n**Sebastien Guillemot**:  Since this proposal is isolated to a new metadata tag, a new label, it's not overlapping with anybody else's proposals. So I don't think frankly speaking, there's a reason to reject it, given that it... There's no kind of overlap with other people that have, so this isn't stop people from making competing standards. I think the proposal itself could be refined a bit. Right now it's kind of unnecessarily long for Twitter links and some other stuff that probably should not go into the CIP itself. So we are going to do this kind of material cleanups.\n\n**Sebastien Guillemot**:  It'd be good to know if anybody intends to actually implement this specific standard. So we could just say, okay, well, there's nothing wrong with this standard, headway speaking. And it's a fairly simple one too. So we could merge it, but it'd be good to know if there's at least one marketplace that actually is interested in this idea and to see what they think, or if this is just a one-time standard. Do you know if any marketplace has commented on this issue? I don't think so. I think all these links are just people who think it would be a good idea to have something like this.\n\n**M. Àngels Jover**:  I mean, we have comments from Matthias, Robert.\n\n**Matthias Benkort**: No, it has been showing a few tweets. I'm not quite sure. I haven't checked, so I'm not sure what marketplaces think of it. But yeah, generally speaking, I do agree with Sebastien, that there is no particular conflict in merging that as a proposed CIP, as long as maybe we have a clear path to active, that is perhaps one marketplace or at least one actor, which is interested in adopting it, and something that can be then reflected upon.\n\n**M. Àngels Jover**:  And are we going to reach out the marketplace in order to review this, or how do you want to proceed?\n\n**Matthias Benkort**: So, we could put it as a last check for next time maybe, and comment in the meantime to make sure that the author adds a clear path to active section mentioning... Yeah, so there is probably one marketplace that is going on with that CIP. And also just to have a... Two weeks period of last check and potentially hear from people that if we have it brought to the light.\n\n##### Discord discussion on the PR\n\n**kieransimkin** - I can't see any reason to reject it\nMy mic's not working. \nI will comment I like the general idea but i think the CIP needs a bit of editorial tidying\n@KtorZ We'd definitely look at implementing it at Artifct\n\n**KtorZ**:\n👌  thanks for pointing out\n\n**rphair [COSD]** — 24/05/2022\nThat also sounds best to ask the author to ask for feedback from their own community... even if they support competing proposals usually they have a good dialogue 🙂\n(NFTs)\n\n**kieransimkin— 24/05/2022**:\nI'm always happy to engage on these things if they're brought to my attention 😉\n\n**havealoha — 24/05/2022**:\nNone of the markets seemed interested in CIP-0044, I'm not inclined to further refine a proposal that wouldn't be adopted.\nThank you all for reviewing it.\n\n**kieransimkin — 24/05/2022**:\nWe'd look at it, but it'd be very low down the priorities list, since we already have a process for verifying projects that works fine(ish)\n\n**havealoha — 24/05/2022**:\nFeel free to take it how it is and modify as necessary. My inspiration was based on how difficult it was to get a project verified on cnft.io. however jpg.store was relatively painless.\n\n\n#### PR163\n [PR163 CIP-0037? | Dynamic Saturation based on Pledge](https://github.com/cardano-foundation/CIPs/pull/163)\n\n**M. Àngels Jover**:  Okay. So just let's move this to, let's and ping the author. So if we move to the next PR. This is PR163, and is dynamic saturation based on pledge. And the internet is not going super fast today.\n\n**Sebastien Guillemot**:  Yeah, I think on this one, was this one of the local PRs where the IOG researchers said they would comment... I mean were kind of looking for that?\n\n**M. Àngels Jover**:  It's this one over here.\n\n**Sebastien Guillemot**:  Right. Last time we talked about it, we got some response from IOG on the topic. They said they would maybe look into it in more detail, but I'm not sure if anything has come out of any of these discussions And it's the main block or anything related to Stake Pool parameters switching.\n\n**Matthias Benkort**: Yeah. So the latest update I had on the topic, and it's something I just commented on CIP 50, which is that the research team is actually working on a new simulation engine to run these sort of models into it, and see how they behaves with different actors, different behaviors. Which they just published a abstract introduction. I'm sharing the link on the chat. The engine is not yet available publicly. I understood that this is something they have planned to do, although there is no timeframe yet. And the idea would then be to have this engine to use to search this space for possible solutions and for... Well, exploring all those ideas that there is, and compare them to the current system to see whether or not those various ideas improves part of the system in the right direction.\n\n**M. Àngels Jover**:  So, shall we wait for this one until we have more information?\n\n**Sebastien Guillemot**:  Yeah, because we've discussed this proposal in the past. So we can re-have the discussion if people really want to. But at the same time, I think we're going to be blocked on the same point, which is we'll have discussion and say... If someone influence this, it's going to have to be IOG, and then blocked on the same point.\n\n**M. Àngels Jover**:  So the next steps with this one is maybe here we will... If there is some kind of activity on it, and be reactive, or do you want to actively reach out to IOG on this one, accept the comments?\n\n**Matthias Benkort**: We have reached out to IOG many times already, and they are aware of the proposals. It's just the research team currently has no bandwidth to talk to them in more details and to formulate an answer. So what I would actually suggest for this proposal, CIP 50 and other in the like, to be merged as-is as soon as they have reached a good enough level of discussions and iterations, which is the case, I think for CIP 37, we can just proceed merging them as proposed CIPs with the assumptions that... Yeah, they need to be assessed by the engineering and the research team from IOG in order to move forward to active or reject it. But there is not much we can do. I think beyond that as part of the CIP process.\n\n#### PR185\n [CIP-0039? | Smart Contract Software Licenses](https://github.com/cardano-foundation/CIPs/pull/185)\n\n\n**M. Àngels Jover**:  Okay. I am taking notes. Okay. So next one that we have in triage, and let me open it... Is CIP 185, a smart contract software licenses. I don't see there has been activity.\n\n**Sebastien Guillemot**:  Yeah. So this one has been implemented in SundaySwap if I remember correctly. So those who were going to be implementing it, I'm not sure if anybody else ended up implementing it. I remember when we talked about it in the past, there was some discussion about whether this is actually legally meaningful, a question which I am not qualified to answer. That being said, the proposal itself had no issues, it's implemented in SundaySwap, which is a project with real users. So, I don't see a reason not to approve this and merge it\n\n**Matthias Benkort**: Well, Michael made a quite meaningful comment that is, there is a lack of rationale section for each other proposal that sort of justify the choices made in the proposal. So that's something which I think should be added before we merge it. And yeah, we'll have to tweak it with the number, because there has been a few proposals merged in between.\n\n**Sebastien Guillemot**:  Yeah. But I think Michael's comment basically Cardano's done the same discussion. I think we had were... Be based off the fact that... You can submit whatever. Is this actually legally meaningful to do this as a transaction level, which I'm not convinced to be the case. I'm not really a legal expert on this.\n\n**Matthias Benkort**: I imagine the rationale at the moment is that it's kind of first come, first serve. So the first one to publish the license takes effectively, because there is no signature whatsoever in the current design scheme. So that's why the rationale section could be interesting.\n\n**Matthias Benkort**: Something that we think would also be valuable on that proposal would be an actual binary specification of the formats by the CDDL spec. We just mentioned that for CIP 25, but as soon as you have an on-chain format like that with different structure type. I think it's good to just have this... A little piece of CDDL that explains without any ambiguity what the format is. And since it's also using a label, we probably want to register that label in the CIP 10... Just for the sake of centralizing all the labels in one place. So that would be the few edits I would request before merging anything.\n\n**Sebastien Guillemot**:  Yeah, the CDDL comment is a good one. Historically we haven't made the CDDL specification requirement. We were getting CIPs that add a new transaction, maybe get a format approved. But maybe it\n\n**Matthias Benkort**: Should be,\n\n**Sebastien Guillemot**:  We should had a lot of cases. Yeah. It just leaves things way too unspecified. It might be it's\n\n**Matthias Benkort**: We want to make them a lot easier to process. Yeah. As a separate file, we started doing it at least for JSON scheme more and more, but it also makes sense for CDDL stuff.\n\n**Sebastien Guillemot**:  Yeah.\n\n**Matthias Benkort**: Especially when it's quite succinct like that, it's not much to write. 10 lines of CDDLs to... Write down the format.\n\n**M. Àngels Jover**:  So you want to move to the next one?\n\n**Matthias Benkort**: Yeah. And I will comment on the PR request with those items, discuss if I can agree that is... And then reassess next meeting.\n\n**M. Àngels Jover**:  Shall we add it to next meeting agenda as part of the triage or review?\n\n**Matthias Benkort**: Yeah, for review or last check depending on the state.\n\n**M. Àngels Jover**:  Okay.\n\n**Matthias Benkort**: Because I mean the proposal itself, I don't think there is any big issue with it. It's more those little sections that we need to be completed. But yeah, I think review next time would be...\n\n#### PR190\n [PR190 CIP-0046? | Prepay Min Fixed Fee](https://github.com/cardano-foundation/CIPs/pull/190)\n\n**M. Àngels Jover**:  Okay. So next it item on the agenda is PR190 CIP-0046? | Prepay Min Fixed Fee.\n\n**Sebastien Guillemot**:  To be honest, I don't remember discussing on this one, because it's been quite a long time. Maybe we could look of the meeting notes to see what we discussed on this?\n\n**M. Àngels Jover**:  The meeting--\n\n**Sebastien Guillemot**:  [inaudible 00:27:02].\n\n**M. Àngels Jover**:  Do you want me to go to any place specifically?\n\n**Sebastien Guillemot**:  Yeah, I remember reading the proposal thinking that this is not a technically sound proposal. I remember the author disagreed with me on this, but I don't remember what the conclusion of that discussion was.\n\n**M. Àngels Jover**:  So maybe we--\n\n**Sebastien Guillemot**:  At the end of the day, this API also depends on the same blocker that the other... CIPs that need IOG's reports have. Because this also changes the way that delegation rewards are paid out to try and help with the same issues that the other CIPs mentioned. So this all ends up being kind of bundled with the same thing?\n\n**M. Àngels Jover**:  So shall we leave it in standby until IOG has more capacity to take on those?\n\n**Sebastien Guillemot**:  Yeah.\n\n**Matthias Benkort**: I would proceed the same way as CIP 37, which is, have them merge as proposed and add a first item on the path to active would be to get a clear assessment from IOG/ the research team at IOG, possibly using this new simulation engine. But yeah, there is not much we can do beyond that.\n\n**M. Àngels Jover**:  So yeah, I-\n\n**Sebastien Guillemot**:  I remember I was not even convinced that this proposal was technically sound, because it makes it the optimal strategy for managing Stake Pool is just to have a bunch of Stake Pools all creating a very small number of blocks, and you'll get more rewards doing this than creating one Stake Pool that creates many blocks, versus the opposite incentive that we want to have. So I was not convinced by whether or not this is actually even something that fits the requirements that we, as a protocol have.\n\n**M. Àngels Jover**:  So, I see the two opposite positions here between you Sebastien, that you might think that it's not sound enough, and you Matthias that wouldn't mind to merge it as proposed?\n\n**Matthias Benkort**: Well, the thing is it's the same for all those proposals. It's hard to say or assess how serious they are before doing any extensive kind of stimulation of the holding theory around the proposal. So from a technical standpoint looking at it, I would say it sounds fair to me. But at the same time, I haven't run any read of the whole position or game really behind that. So I haven't pushed much the... Consequences of that proposal on different system. It is very hard to assess.\n\n**M. Àngels Jover**:  I have a question related on the process, as you suggested to merge it as proposed. But before going to active, I just wanted to make sure that I understood. Before to making active, that needs to be on a step before, which is an assessment from IOG, right?\n\n**Matthias Benkort**: Yeah, an assessment from the research team, possibly using this new framework we have been developing for running this kind of simulation.\n\n**M. Àngels Jover**:  Okay. Okay. So this is something that we would add as a comment or as a step before changing the path to active?\n\n**Matthias Benkort**: Yes, I think both what you said.\n\n**M. Àngels Jover**:  Okay. Now I wanted to know how you do that. I guess that is like... As you are in control to changing the proposals from proposed to active. So this would be like a kind of requirement before moving it to active. And this would be in a standby until we have this simulation.\n\n**Matthias Benkort**: Yeah, indeed active, to active or rejected depending on the outcome of the results.\n\n**M. Àngels Jover**:  Okay. [inaudible 00:32:04].\n\n**Matthias Benkort**: If the simulation clearly shows that the proposal isn't sound, that it would make the situation worse, then we just don't want to make... Move it as active, but just as rejected.\n\n### Last Check \n\n### Review \n\n#### PR242\n [PR242 CIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242)\n\n**M. Àngels Jover**:  Okay. So, that were the items we had in triage. And now in review, we have PR242, which is CIP 50 regarding Shelleys Voltaire Decentralization Update. I think that we are going to do a weekly summary on this, if I am correct?\n\n**Matthias Benkort**: Yes. So I actually spent the whole day looking at the proposal and going through the thread of comments. I try to provide a summary at the bottom. There has been many, many things been said, but it's mostly also a debate around whether or not the proposal improves the situations in terms of, does it benefit decentralization, and does it benefit actually every users of the ecosystem and not just the big players?\n\n**Matthias Benkort**: So the discussion hasn't really settled on that. And again, this is the kind of proposal where we need more evidence or stronger arguments in favor or disfavor of the proposal, and something, hopefully this new simulator from the research team could help with. The research team is also aware of that proposal. I've had a discussion with Aggelos also on this one. He also mentioned that it was quite close to how incentives works on Tezos currently, upon which Cardano has improved.\n\n**Matthias Benkort**: They had analyzed in the past, and that they had rejected or iterated upon in the current design that is used in Cardano. He pointed out a blog post he wrote two years ago on the topic, which goes over the different designs that you can use for incentive and rewards, and why this proposed design has issues and works actually worse than the current mechanism. Which is also one point being made during... By other people in this whole thread of comments, which is that it's also not clearly established that the current mechanism is worse than the proposal here. And that possibly with a different set of parameters, we could also alleviate some of the issues that are being brought out or motivating this proposal. So that's a bit from the summary of the discussions on that.\n\n**Matthias Benkort**: I also think that there are many topics in discuss itself within this... In that proposal, and that perhaps it could be worse to split it in multiple smaller proposals. There is one which is the change of the reworked formula, which in itself is I think the main proposal. But then there are also other topics like the change or reduction of the value of K. There is a... This k-effective measure that is describing the effectiveness of the proposal. It has an interpretation that has also a definition that is being debated. So just for the sake of making the debate a bit more fluid or debate maybe in different rooms, if you want, I would be in favor of splitting this proposal into smaller ones.\n\n**Matthias Benkort**: Yeah. So that's a bit for the summary, which is also then posted on the CIP at the moment. And I will try to keep up with the discussions coming for... Next weeks.\n\n**M. Àngels Jover**:  And for splitting the proposal, this is something that Michael should be doing?\n\n**Matthias Benkort**: Ideally, yes. And that's also very much up to discussions, because maybe he doesn't have a time or willingness to do it. It could also be someone else, right? Everything is in the end open here. So if someone sees something that has value and it should be made today, proposal by itself. I made a few suggestions on the... On my comments, but there's maybe some odd few other things that are worth keeping out of the proposal, even though it is agreed with the rest of the proposal.\n\n**M. Àngels Jover**:  So you would suggest Matthias that we wait for some comments on your summary and suggestions, and see how the people react to this?\n\n**Matthias Benkort**: This, yes. And regardless of my comments actually, there are still ongoing discussions that have not yet settled on the proposal. So there is no point, in a way, moving it forward in any form at this stage, because it's still actively discussed. So I think it's good if we have regular updates on that one also, just to keep up with the state of the discussion. And eventually, once the discussion has settled and maybe people have agreed on the final draft, then we can proceed the same as CIP 37 and CIP 46, which is having it as a proposed CIP, and move the task then in IOG, IOP help and just have them do something.\n\n**M. Àngels Jover**:  To run the simulation, right, or to review it?\n\n**Matthias Benkort**: Yeah, or provide an answer on the feasibility, viability of the proposal.\n\n**M. Àngels Jover**:  Okay. So shall we leave... Save some spot... Some space in next meeting for review this or shall we do biweekly check-ins on this one or do you prefer to do monthly check-ins?\n\n**Matthias Benkort**: For this particular CIP?\n\n**M. Àngels Jover**:  Mh-hmm. Yes.\n\n**Matthias Benkort**: I think having it done on the next biweekly at least, and then we re-asses on every biweekly, depending on the activity?\n\n**M. Àngels Jover**:  Okay. Fair enough, because there's a lot of activity on this one. And maybe if we wait for a month, it's going to be too much to keep up. So let's go to the last item we had on the agenda, which is CIP 242, Cardano best practice guidelines. If I recall correctly--\n\n##### Discord discussion on the PR\n\n**KtorZ — 24/05/2022**:\n[Pool Splitting Behaviour and Equilibrium Properties in Cardano’s Re])https://blogs.ed.ac.uk/blockchain/2022/04/19/pool-splitting-behaviour-and-equilibrium-properties-in-cardano-rewards-scheme=\n\n**kieransimkin — 24/05/2022**:\nis this related to or superceded by CIP-0050? (not my expertise here)\n\n**KtorZ — 24/05/2022**:\nrelated to\n\n**kieransimkin — 24/05/2022**:\nyou have to know you're agreeing to a license for it to be valid, if it's embedded into a smart contract that you're signing when you interact with it, that's not legally enforceable afaik\nbut the metadata couold still be provided for information purpsoes\n\n**ccgarant — 24/05/2022**:\nHere for help with CIP-50 @KtorZ thanks for review. Took notes. Will relay to Mike L. Working on ranking equation for stake pools. Should have new pull by end of week.\n\n\n#### PR252\n [CIP-0052? | Cardano audit best practice guidelines](https://github.com/cardano-foundation/CIPs/pull/252)\n\n\n**Sebastien Guillemot**:  [inaudible 00:39:38] we agreed to approve this one, right?\n\n**M. Àngels Jover**:  My sense is that... You had this meeting here in Barcelona last week, and you were going to discuss this. I don't know if I am... Must correct my...\n\n**Sebastien Guillemot**:  Yes, you're right.\n\n**Matthias Benkort**: Yeah, which happened. It was presented during the workshop. It's been a bit discussed and... Yeah. So it actually created, or gave birth to another CIP that we are working on with a few other people, regarding the specification of an on-chain contract. But as for the audit guidelines, there is not much more to say. I think we were pretty much okay with that.\n\n**M. Àngels Jover**:  So, we will be able to merge it?\n\n**Sebastien Guillemot**:  [inaudible 00:40:37] as well, and if during the in-person meeting, nobody raised any issues, then given that there was a... If that was a room of experts as well, then I don't see a reason not to approve this CIP.\n\n**M. Àngels Jover**:  Okay. So this is all what we had in the agenda.\n\n**Sebastien Guillemot**:  So the CIP comes with this TX spec. So this is what we're extracting as a separate CIP, right? We want to remove it from the CIP?\n\n**M. Àngels Jover**:  From this one ore from...\n\n**Sebastien Guillemot**:  Yeah, so the CIP as part of it also has... I think maybe there's a merge issue actually when I look at it. Maybe they pushed stuff by accident, because there's the same file repeated twice. And then they added this--\n\n**Matthias Benkort**: Yes.\n\n**Sebastien Guillemot**:  TX Pack.\n\n**Matthias Benkort**: There's the CIP XXX which shouldn't be here, I think. And the TX spec one, it was originally in a Google Doc. And I actually asked Simon if we could put it on the report next to it. And this is precisely the TX spec stuff, what gave birth to another CIP currently under our discussion. So I think eventually, we will probably amend this CIP to just refer to the other one when it comes to the TX specification. And while I have no issue actually with the current CIP in terms of the guidelines, I don't find the TX spec very clear at the moment. So it's a bit of a side thing, but maybe it's just worth re-wording this. But the main state is okay, definitely.\n\n**Sebastien Guillemot**:  Yeah, but it feels kind of strange, because these are two related, I guess, but separate things. And then we also have the same document. Okay. So probably we just need to go and pick up this PR and then [inaudible 00:42:52].\n\n**Matthias Benkort**: Yeah. And I would suggest maybe to move the discussion of the TX spec to the other CIP that we're working on. And simply have a link from that one to this ongoing discussion. It's not essential for the guidelines anyway.\n\n**M. Àngels Jover**:  Are you going to do this offline?\n\n**Robert Phair**: Yeah, right.\n\n**Matthias Benkort**: Yeah, yeah, we'll comment on the PR. Maria also, are you going to link to Robert? [inaudible 00:43:27] this trouble like I was, to join back this Discord or I was doing something wrong?\n\n**M. Àngels Jover**:  Looks like it sounds better now, right? Or no?\n\n**Robert Phair**: Someone just did something. Someone just did something a few seconds ago, then it was... I've been clicking on my unmute button and I've been told... I've been suppressed ever since I reconnected. So I guess, whatever you did, fixed it. I've been trying like hell just to unsuppress myself and I couldn't. So thank you. Yeah, that's it.\n\n**Robert Phair**: All the comments that I wanted to make so far are in the chat. So I don't see Maria that... Even in the chat rooms. So that's where I've commented, is just in the chat. I don't know if I can be inserted into the minutes somehow, but there were a couple of things, but... What would the process be for in...\n\n**Robert Phair**: Just a comment, if there were relevant things in the chat to the discussion, are they ever inserted into the minutes or does it have to be spoken?\n\n**M. Àngels Jover**:  I had a little bit of trouble understanding.\n\n**Matthias Benkort**: [inaudible 00:44:48] to the chat. So Robert was asking, what do we do with the chat basically, regarding the minutes meeting? I think we should just include them in some form or another, because there has been relevant stuff being said in the chat, and we don't bring everyone on vocal anyway. So, that's important.\n\n**Robert Phair**: Okay. Well, you can edit what I've said, because a lot of it is, \"Help, I'm being suppressed.\" So you can turn that down a little bit. I did make some comments about two of the other proposals, but that's enough. We can keep moving on. Are you still hearing any noise that you were noticing through the web app?\n\n**M. Àngels Jover**:  It's still noisy and it's difficult to understand you, because it gets... I mean the words... Well, nevermind. It is difficult.\n\n**Robert Phair**: [inaudible 00:45:42]? Okay.\n\n**M. Àngels Jover**:  What I will do is check and see how we can include this, because I think that what you mentioned is really interesting. So I will check how to include the comments on the meeting notes.\n\n##### Discord discussion on the PR\n\n**kieransimkin — 24/05/2022**:\n@KtorZ I've had a good read of CIP52 - nothing to add, looks really good\n\n### Issues\n\n### Discussions\n\n#### PR256\n [PR256 CIP-0014, CIP-0015, CIP-0016, CIP-0025, CIP-0028, CIP-0029, CIP-1852, CIP-1853, CIP-1855 status updates.](https://github.com/cardano-foundation/CIPs/pull/256)\n\n**Matthias Benkort**: So I would like maybe to go quickly over a small PR I did last week, 256, which just turns a few CIPs as active. I was going through the list other day and thought to do... There are a few ones that we could definitely turn as active, because there are obvious and observable proof of activeness. So, there are old CIPs that have been there for a while. It doesn't mean that we cannot have a change of the CIP. But yeah, things like CIP 1852, which is the derivation scheme used in every single wallet currently. Or CIP 14, CIP 15.\n\n**Matthias Benkort**: There is a complete list with rationale as for why I think we should turn them into active. There was a few others that could be up to debate, which I didn't include. But I think generally speaking, we originally thought that the author would come and update their CIP as active as soon as they have reached a... Well, level of activity, or it turns out that I think we'll probably have to take upon that task, because... Yeah, outdoor is typically once they have proposal is active, they don't just come back at it. So it's just a variety of... The things.\n\n**Matthias Benkort**: So, there is no section... okay, so it actually used approved. There is now a conflict.\n\n**Sebastien Guillemot**:  Yeah, it makes sense. It makes sense. All these are very commonly used. So it's no [inaudible 00:48:43].\n\n**Matthias Benkort**: Yeah, I think I will make another PR soon to just turn a few others as proposed, because that's something also we haven't been quite careful with in the past. Some CIPs have... I think they have been merged as still... Are still draft. Like CIP 30, it's been drafted for a while and it was sort of on purpose. But quite a few of them are actually not draft anymore; they have been just proposed and they are just not yet active.\n\n**Matthias Benkort**: So yeah, but that will be for next meeting. Is there anything else maybe for today we could look at? Did we have any suggestion in the chat?\n\n\n\n#### PR258\n [PR258 - Bootstrap first draft of the Plutus contract blueprint.](https://github.com/cardano-foundation/CIPs/pull/258)\n\n**Sebastien Guillemot**:  And then, so the blueprints for Plutus one is still too early, right?\n\n**Matthias Benkort**: We could start have a look at it, if only for people to also jump in the conversation. But yes, it's very, very early draft at the moment. Actually, I mean the specification has not been written. We have just written examples at the moment of what we think it would look like in the end.\n\n**Matthias Benkort**: But yeah, we could have a quick look at that one, which people wants to jump on the conversation, at least to explain the motivation and the... What's behind. So happy to give a short introduction.\n\n**M. Àngels Jover**:  Which one Matthias?\n\n**Matthias Benkort**: So yeah, I'm going to put it in the chat as well. So PR280... Sorry, 58. You can think of it as an open API/Swagger format for on-chain contract. So a way to specify a contract interface in a machine-readable format. And by contract interface, we mean... Data redeemers, and if applicable, for instance, the different transitions that can be operated on a contract, if it's evolving around the stake machine.\n\n**Matthias Benkort**: And the goal is really to enable a whole sort of tools to be built upon that, including documentation, automated card generation, or simply wallet UI that can then show you the different progress of your contract. And can also better show you what's going on when you sign or view a transaction that involve a contract, because now they have actual content or ways to inspect data redeemers that are being bundled as part of a transaction, and they can then offer you better UI for interpreting this data.\n\n**Matthias Benkort**: So this is a CIP that aim at just specifying the language you can use to write this contract specification. It's quite simple. It's just a YAML/JSON schema-based language, because it's quite good for that. There are a lot of tooling around it that exists already, and it's quite common for web and DApp developer... To use this kind of technology or this kind of... Yeah, people language. So it's still early draft, but I invite people that feel maybe concerned by that to comment and see.\n\n**M. Àngels Jover**:  Okay.\n\n**Sebastien Guillemot**:  Yeah. So one of my concerns with this is how we plan to basically generate these from a hash code itself. It is a very good way to basically have people [inaudible 00:52:51] they're off-chain code generation as it generates its file permit, or is that nothing that is-\n\n**Matthias Benkort**: That's the other way around. I think you actually want to write the spec first, and then generate hash code for responding to the spec. And this way, you can [inaudible 00:53:12]-\n\n**Sebastien Guillemot**:  That would be ideal, yes.\n\n**Matthias Benkort**: To do code generation of either the on-chain part, or also the off-chain, which is in the whole diagram. And that tooling is also yet to be built obviously. But it's a start for good foundation for them, all of that. You could also use it for verification, for instance. Right, so have for validation, once you have created and generated a transaction as part of your whole... That pipeline, you could use that tool as a schema validation on the data and you will be able actually to make sure that your contract is actually doing whatever is specified in this file. And yes, exactly yes, someone said in the chat so automated unit test, yeah. Validation is based on the spec. So it's very close to the article representation of the data obviously, because...\n\n**Sebastien Guillemot**:  Do you know what they did for the Plutus simulator? I forget the name of the project; it's been so long. But I remember they had a website where you could generate your code, you could give them your code and they would generate these bit machines and set some web-based UI. Do you know what they used for that? Yeah, Plutus Playground. How did they generate the UI from this... Our contract? Did they come up with a standard for this?\n\n**Matthias Benkort**: No, that's a good question. I think it's solidly based on the hash code types. And behind the scene, I know it's built with pure script. So I would expect that they have some form of... Pure hash code to pure script generator to do a bunch of the heavy-lifting.\n\n**Sebastien Guillemot**:  Yes, they may have something that we can reuse either code wise or idea wise.\n\n**Matthias Benkort**: Yeah. And Michael has already commented on the proposals. He's aware that this is going on. He hasn't suggested anything in this direction though. But maybe you can ping him a bit more on this particular subject.\n\n**Sebastien Guillemot**:  Yeah, because I imagine the people who work on Plutus Playground probably thought about this, and probably this is also something they thought about for Marlowe. Marlowe is maybe a bit trickier, because they have the separate TSL, which also generates code that's not this kind of JSON schema, but maybe it... Some similarity, I'm not sure-\n\n**Matthias Benkort**: Yeah, what Simon tried to specify in this TX flow file from CIP 52.\n\n**Sebastien Guillemot**:  Right, yes.\n\n**Matthias Benkort**: Where I think the [inaudible 00:55:56] stems from Marlowe's and Marlowe's behavior. But it's really not obvious to me how exactly those things relate to the low level Plutus stuff in a way.\n\n**Matthias Benkort**: Oh, it seemed very... Too high level to be actually useful for code generation, automated test code verification.\n\n**Matthias Benkort**: So yeah, so far we are mostly focusing on the data redeemers kind of specification, but there is also maybe other information that are useful to add around that. Someone suggested, for instance, recently that we add also Plutus versions to the schema, because now we have... Well, soon we'll have two different Plutus versions. So it's nice to say your contract is this or that version. It's perhaps also a good way to actually have the compiled code of the contract and have it in some place so that you can refer to it later, which sometimes can be tricky because some contracts are parameterized at compilation time. So therefore, their code slightly changes depending on which parameter you choose. And it'll have a static address therefore. But there are maybe other components of... On-chain contracts that are interesting for that developer, which is exactly why the feedback is interesting here.\n\n**Sebastien Guillemot**:  Right. So this CIP tackles the data redeemers. But we already have kind of a standard for representing these in JSON, that's implemented by both... Cardano CLI and the rest, SDK CML. So did we want to standardize this representation as a separate CIP and then build on top of that for the stake machine, or did you want to have the 12 B one, the CIPs?\n\n**Matthias Benkort**: It's kind of different though, because here it's more like meta language, right? Or describing what the functions are and a JSON representation is not as capable as the on-chain representation. So there are stuff that you cannot represent in JSON that you can do on-chain. So they don't necessarily have to converge, I think, the presentations. Maybe the passive value if they do. But I see that as two separate things, actually. They don't really describe the same thing.\n\n**Matthias Benkort**: It's a bit of like a type versus value kind of...\n\n**Sebastien Guillemot**:  Yeah, okay.\n\n**Matthias Benkort**: Thing, right?\n\n**Sebastien Guillemot**:  Yeah.\n\n**Matthias Benkort**: Here, we are describing the type of [inaudible 00:58:45], whereas the JSON of the [inaudible 00:58:45] is really just materialization of that value.\n\n**Sebastien Guillemot**:  So in an ideal world, you could also generate this JSON through the schema that you're defining here?\n\n**Matthias Benkort**: Yes. I see someone is typing in chat.\n\n**Sebastien Guillemot**:  Okay. Yeah, I have no other questions about this CIP. I see it's not done yet, but so far it makes sense.\n\n**Matthias Benkort**: Thanks for sharing.\n\n**Sebastien Guillemot**:  How much time do we have left? Three minutes, so I guess we probably don't have... So there's a few other issues open or PRs open, but I think maybe with three minutes, we don't have really the time to get into them.\n\n**Matthias Benkort**: No.\n\n##### Discord discussion on the PR\n\n**kieransimkin — 24/05/2022**:\nSuper keen on this transaction spec @KtorZ - i also see it as a way for the plutus gurus to help simple C developer mortals like myself to understand how to actually interact with a smart contract 😉\nautomated unit tests could come from it too right?\n\n**PGWAD — 24/05/2022**:\nI am working on Coq proof assistant and this (Plutus contract blueprint) one will be very useful for that especially extraction part. I am writing an extended abstract and will update if i need anything more\n\n### Close \n\n**M. Àngels Jover**:  Shall we do a quick wrap up on the session?\n\n**Matthias Benkort**: Yeah. Who wants to... Sebastien, you're up for it?\n\n**Sebastien Guillemot**:  Just thank you everybody for coming. Hopefully you didn't think the technical issues were that bad. And this is our first attempt to do this over Discord. I think we had higher attendance than what we did when we got over Crowdcast. I think this is a good migration. We were originally unsure about doing Discord versus Twitter Space. We ended up picking Discord because you can screen-share on Discord, which is useful. And hopefully the screen-share functionality was useful for everybody.\n\n**Sebastien Guillemot**:  But one of the problems we have with CIP is we need to reach out to more people. So we need to go where people are instead of in an isolated platform. And so coming on Discord was part of that. And maybe in the future, we can try out broadcasting this to Twitter Space at the same, or some other kind of scheme to reach out to more people. But if you have any feedback for how we can improve these meetings in the future to make them more engaging, let us know.\n\n**Sebastien Guillemot**:  I did notice that nobody else spoke during this session, other than in the chat. Let us know if that was good enough for you. I think Discord has a way for people to raise their hands or request to speak. So we could try and come up with a system like that. In my experience, it slows down the meetings quite a lot. But obviously, depending on the CIP, if we have the CIP author come up, it can be important. So obviously, one of those balance things we have to try to find the right balance.\n\n**Sebastien Guillemot**:  So if you have any feedback about our first experience, just let us know what you think, and hopefully you'll be around for other CIP meetings in the future.\n\n**M. Àngels Jover**:  Well, next CIP meeting is going to be in two weeks. It's going to be at 8:30 AM UTC, and it's going to be on Tuesday. Let me check... The actual number. Tuesday, June the 7th, 8:30 AM UTC.\n\n**M. Àngels Jover**:  Thank you very much all for attending today. And well, have a nice evening or day. Bye-bye.\n\n**Matthias Benkort**: [foreign language 01:02:20], bye.\n\n\n---\n## Extra\n\n### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md)\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n© 2022 GitHub, Inc.\nTerms\nPrivacy\nSecurity\nStatus\nDocs\nContact GitHub\nPricing\nAPI\nTraining\nBlog\nAbout\n"
  },
  {
    "path": "BiweeklyMeetings/2022-06-07.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [June 07 2022 Transcript](#june-07-2022-transcript)\n  * [Triage](#triage)\n    + [CIP-0052? | Cardano audit best practice guidelines](#pr252)\n    + [CIP-0054? | Cardano Smart NFTs](#pr263)  \n  * [Last Check](#last-check)\n    + [CIP-0044? | Additional factors for NFT market verification](#pr226)\n    + [CIP-0037? | Dynamic Saturation based on Pledge](#pr163)    \n    + [CIP-0046? | Prepay Min Fixed Fee](#pr190)          \n  * [Review](#review)\n    + [CIP-0050? | Shelleys Voltaire decentralization update](#pr242)\n  * [Discussions](#discussions)\n    + [PR267 CIP-0025: Added version 2 and cddl](#pr267)\n    + [PR 271- CIP-0027? | Update Proposal: Multiple Royalty Addresses](#pr271)\n  * [Issues](#issues)\n  * [Close](#close)\n\n## Summary\n\nRough transcript of 07/06/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Transcript might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you.  \n\n\n## Editors Meeting Flow\n\n**Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n\n**Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n\n**New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \n\nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n**Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n\n**Issues**: Review of the open Issues on the CIP GitHub \n\n**Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  \n\n\n## June 07 2022 Transcript\n**Attending Editors**: Matthias Benkort, ~Sebastien Guillemot~, ~Frederic Johnson~, ~Robert Phair~. \n**Guests**: \n\n\n**M. Àngels** -:  Welcome, everyone. Welcome everyone to the CIP Editor's meeting number 46. My name is Maria Angels Jover, and I work as a project manager at the Cardano Foundation. And I am here to facilitate this meeting. Today is the second time that we are using Discord as a new platform, and it's the first time that we are doing this in the European zone time. We had some technical difficulties in our first meeting that we expect to be solved today.\n\n**M. Àngels** -:  Please, any feedback that you have on this new communication channel will be very much appreciated. To access the chat of the voice channel, you can hover here in open chat, and you will see that it will appear at the tab here with a chat where you can comment, ask questions, and participate in the conversation. You will see that I have added here, a link. This is link is a direct link to the meeting agenda, so you can access from your end and navigate to the links. The editors are able to bring you on stage, so you can ask to be on stage if you think that you have something that is worth to discuss live.\n\n**M. Àngels** -:  And it's my pleasure today to introduce you to our editor for this meeting, that is Matthias Benkort. Matthias, are you able to speak? You should be able to unmute yourself. I see that you have unmuted yourself, but I am not hearing you. Seems like we are running into some issues, let's wait for Matthias. We are not hearing you Matthias, if you are speaking. Maybe it's the microphone that you have enabled with Discord, that is not the correct one? Apologies on these technical issues that we are facing. I mean, this happens with live sessions, so please bear with us, and this will be solved in a few minutes. Thank you very much.\n\n**Matthias** -: Hello? Okay. [inaudible 00:06:26].\n\n**M. Àngels** -:  Yes, welcome, Matthias.\n\n**Matthias** -: [inaudible 00:06:28]. Yeah. I see Les asking, \"Why use Discord?\" And the truth is we have had mic issues with every single platform we've used so far, so I'm not sure any platform would actively serve that. And the reason we used Discord is because it allows us to have way more speakers on screen when we have to. It's more friendly. We have also a chat, and that's where the community are centralized around a few Discord channels. So it's quite handy to have things in one place. Okay. Having said that, shall we start?\n\n**M. Àngels** -:  Sure, yeah. On screen, you can see the agenda. Matthias, do you want to discuss anything that is not included in the agenda today?\n\n**Matthias** -: Let me see. [inaudible 00:08:00]. Yeah, maybe, we'll see at the end, but there has been a few Pull Requests recently, we'll just go through them quickly and see that.\n\n### Triage\n\n#### PR252\n[PR252 CIP-0052? | Cardano audit best practice guidelines](https://github.com/cardano-foundation/CIPs/pull/252)\n\n\n**M. Àngels** -:  Great, so we can start with triage right? So, in triage, we have CIP-0052? | Cardano audit best practice guidelines. Here we had some comments from the last meeting. It was suggested to move the discussion on the transaction spect to another CIP. This was supposed-\n\n**Matthias** -: Yeah. Which we started, but at the same time, as long as this [inaudible 00:08:54] CIP is not fully done, I think it's still fine to keep it in CIP 52 for now, and we'll just remove it later. Sorry. There were a few comments that have been retraced by Simon since then, and I saw he did also some recent edits. He added an auditor list at the end. It's fine now. Everything is re-read, was reviewed last time, so. Okay.\n\n**M. Àngels** -:  Are we going to Merge this one then Matthias?\n\n**Matthias** -: Yeah, I cannot approve it right now because I don't have access to my GitHub account from Windows, but in the future.\n\n**M. Àngels** -:  Okay. I'm going to take a note that this is going to be Merged online.\n\n**Matthias** -: Yeah.\n\n**M. Àngels** -:  Let's go to the second item on our list.\n\n#### PR263\n[PR263 CIP-0054? | Cardano Smart NFTs](https://github.com/cardano-foundation/CIPs/pull/263)\n\n**Matthias** -: So, PR 263 CIP-0054? | Cardano Smart NFTs\n\n**M. Àngels** -:  Can you do a brief summary regarding this PR, Matthias?\n\n**Matthias** -: Actually, I think we have Kieran with us, right? Who could actually give us some intellection? We could bring it on the-\n\n**M. Àngels** -:  Sure.\n\n**Matthias** -: Chat.\n\n**M. Àngels** -:  Hi, Kieran. Yes, perfect.\n\n**Kieran** -: So yeah, this CIP, it's about a JavaScript API to be provided to JavaScript NFTs. So it's a fairly niche thing, I suppose, but it does need to be standardized because there are people developing or needing implementations of something like this at the moment. There needs to be a global standard that everyone relies on, so that's what we're trying to build here.\n\n**Kieran** -: Yeah, basically it's about allowing NFTs to read data from the blockchain itself. [inaudible 00:11:11] token in your wallet in an NFT [inaudible 00:11:35].\n\n**Matthias** -: Okay so this is a sort of standard for a format on chain that allows wallets to query the informations about NFTs?\n\n**Kieran** -: Its to allow the NFT itself to query the blockchain, 'cause we have these JavaScript NFTs now, basically HTML pages with JavaScript in them. Currently they are some blocks so they call them [inaudible 00:12:02] which is causing people to commit a lot of data to the chain that doesn't need to be committed to the chain. So what this is about is allowing NFTs to create data directly from the chain without having to commit within that NFT itself so it's to reduce data duplication on chain data of the effects of this. It's also about allowing NFTs JavaScript to only [inaudible 00:12:30] the NFTs. It's allowing JavaScript NFTs to read arbitrary data from the chain and react how they see fit to that. It's things like, let's say you've got a chimp NFT and you buy it a hat, you can buy the hat as a single NFT and then the chimp NFT render the hat wallet, knowing you've got that hat NFT wallet inside the chip, does that make sense?\n\n**Matthias** -: Kind of. So the concept of JavaScript NFT doesn't make sense to me, what makes sense though is a JavaScript written DApps that interact with NFTs possibly, I think.\n\n**Kieran** -: JavaScript NFTs, this is something that is really happenning but an NFT is just a file attached to a token, right? And then that file could be an HTML file. And this is the thing that you could do, I don't know if you've seem mesmerized [inaudible 00:13:33] JavaScript NFT. And then there's a lot of people doing this now, this is a API for JavaScript.\n\n**Matthias** -: Okay, an API in the sense of an extension to CIP 30, current API, right? So that's something we implemented by wallets or simply all the plug-ins behind the scene, so.\n\n**Kieran** -: It would be implemented by the site rendering the NFT so it could be [inaudible 00:14:04], it could be JPEG store or it could be Artifact it be in the website that renders the-\n\n**Matthias** -: Yeah, okay, got it. Is there any working example of that already? Like is it something-\n\n**Kieran** -: I am working on it right now.\n\n**Matthias** -: Okay. That would be good to add on the path to active.\n\n**Kieran** -: Yeah.\n\n**Matthias** -: Once you have that or maybe already an idea of it. Okay. So the main thing I think we would have to view then is the API below. One thing I can already tell maybe would be to add versioning changes to the API, and that's something we tend to have forgotten on the previous API we have wrote, and that all came afterwards, like, \"Oh, fuck. Now we need to have changes, but now you don't know which version you need to implement.\" So chances that there will also be changes to add to this [inaudible 00:15:01]. I would suggest really having an API on this one, or just make it theory that this will be the final API, we call it CIP 54. And any extension or any addition would be done as a CIPs, and then it becomes a big theorem because it's at least the number of CIPs that we should pause.\n\n**Kieran** -: One thing adding versioning to this would be the way to go, because it refers to the 721 enterprise of [inaudible 00:15:19] version 1.1, 'cause we already have a version 1.0, would not be [inaudible 00:15:34].\n\n**Matthias** -: Yeah and there is 2.0 coming. Right.\n\n**Kieran** -: 2.0 coming is [inaudible 00:15:42]. So should I call this 1.1 for that?\n\n**Matthias** -: Um, I mean this one should probably follow a separate versioning.\n\n**Kieran** -: [inaudible 00:15:50].\n\n**Matthias** -: Yeah, its own versioning [inaudible 00:15:53] or you can just pick it to the versioning 71. I'm sorry.\n\n**Kieran** -: I'll have to think about that but I will update the version.\n\n**Matthias** -: Okay, so I haven't yet read the full CIP, only read the abstract so far, but yeah we need to dive a little more deep here. From the idea standpoint, I don't think there is any major problem. It's truly just we only can Cardano API.\n\n**Kieran** -: That's right. Yeah.\n\n**Matthias** -: Yeah. From a security standpoint, there is not much issue with that. So I would love to see also if you have a working [inaudible 00:16:38] maybe so that we can possibly already Merge it as active, as we do.\n\n**Matthias** -: I see there is also the follow up link of what has been the feedback so far from discussion of NFT.\n\n**Kieran** -: I've gotten multiple NFT creators who are really excited about being able to use this. There's a lot of feedback that's really come from there. This was actually a much simpler API to begin with. I've added quite a lot in response to feedback. I was actually trying to keep it simple because we wanted the implementation to be as light as possible, had quite a lot of feedback for some extra things people would like to add and I've started to bear the fine line of trying not to add too much stuff onto this extra version because I want it to be implemented easily.\n\n**Matthias** -: Okay.\n\n**Kieran** -: We're sort of balancing it, but there's definitely been a lot of feedback both on the forum and then spoken to me on Twitter, and working with Alexander from [inaudible 00:17:25]. So, yeah, I've got quite a few things to go.\n\n**Matthias** -: Okay. Would you mind maybe adding a rational section to the CIP, mentioning maybe some of the feedback you've been discussing and why things have [inaudible 00:18:00] the API?\n\n**Kieran** -: Yeah.\n\n**Matthias** -: Just for the report. Oh, yeah. Also the type. I've commented that last time. Standard is really reserved for core critical changes, like through to stuff or later holes secure. It would be more of a process, right?\n\n**Kieran** -: It's just changing metadata.\n\n**Matthias** -: Yeah. The type of the same process here. Or informational, but I think it's going to be more of a process, right? It describes these kind of protocols between those smartness and data provider, in that sense.\n\n**Kieran** -: Yeah. Sure.\n\n**Matthias** -: Okay. And I guess we can just move it to last check for next time, it's been already really quite extensively on the forum that I can see. We'll make a small rational section and we'll try also make maybe a summary of the comments, when commenting on it and send the next time. We can go back to check if there is already an implementation ready and it's been endorsed by some of the platforms out there. We can activate right away or just go with proposed until there are also proof of that.\n\n**Kieran** -: Okay. Great. I've got do list [inaudible 00:19:25].\n\n**Matthias** -: Good, thank you.\n\n**Kieran** -: Thanks.\n\n**M. Àngels** -:  Okay.\n\n**Matthias** -: Next.\n\n### Last Check \n\n#### PR226\n [PR226 CIP-0044? | Additional factors for NFT market verification](https://github.com/cardano-foundation/CIPs/pull/226)\n\n**M. Àngels** -:  We can move them on to the items on last check. The first item we have is PR226 CIP-0044? | Additional factors for NFT market verification\n\n**Matthias** -: Additional factor. Do we have Eric here?\n\n**M. Àngels** -:  I don't see anyone by the name of Eric.\n\n**Matthias** -: What was this one? Sorry. It was a busy week last week. Perhaps we can switch. Hadn't got to go through this piece as I wanted to. Okay. So there is somebody [inaudible 00:20:29] the header, but it's okay. Let's see that later. Simple summary, a community standout for the NFT policy ideas to facilitate market verification, utilizing a new number, name asset tag hate with one online on chain accounts bank utilize this proposal [inaudible 00:21:08] Okay. To it is a standards. Two include with metadata. So KYC metadata to, [inaudible 00:21:31].\n\n**Matthias** -: So what's the ID specifications, creating new tech creator makes a new current see and use one more existing online platform, social update. [inaudible 00:22:05] I'm not sure to fully understand exactly how would that work in practice. So the first question that would come to my mind is how do we exactly prove that whoever posted metadata are actually the NFT owners and not someone else since it allows to be original data, that means you can come later and also change those data.\n\n**Matthias** -: I mean, what elements ties you as the NFT owner or the owner of this metadata and why can't anyone [inaudible 00:23:23]. Is there also a community discussions happen? Yes, I see. So thank you.\n\n**M. Àngels** -:  Matthias, where are you seeing the comments, the activity?\n\n**Matthias** -: Sorry, she's going to share this link in this channel here. So the second version of the side written, because there are two files on the [inaudible 00:24:36]. One of them is I think the latest iteration and it has a comment stream on the top. You high with also a discussion thread, which I will need to go through and see what's up. So I see there has been quite a few feedback and is the latest version of the proposal things from that, I suppose.\n\n**Matthias** -: Okay. So I'm a bit worried on the security implication of that more, the spoofing kind of capability. People like this so I want to carefully get feedback straight on the forum before saying anything. Let's keep it for the next meeting and I'll make sure actually to go through the comments and also post this small summary on that CIP.\n\n**M. Àngels** -:  Do you want to add as under review section for next meeting?\n\n**Matthias** -: Yeah.\n\n**M. Àngels** -:  Okay.\n\n**Matthias** -: This one. Yeah. I think there will be another bunch of comments and we'll probably need a bit more engagement from well marketplaces and NFT of platforms, because this is really geared toward them, towards how to get NFT approval. So it would be nice to get also input from the existing marketplaces, maybe to see how they currently do it. And if that solves an actual problem in your site.\n\n**M. Àngels** -:  Okay. So you want to move to the next item on the agenda, Matthias?\n\n**Matthias** -: Mm-hmm.\n\n\n#### PR190\n [PR190 CIP-0046? | Prepay Min Fixed Fee](https://github.com/cardano-foundation/CIPs/pull/190)\n\n**M. Àngels** -:  CIP-0046? | Prepay Min Fixed Fee\n\n**M. Àngels** -:  I think that I added a few items on the agenda related to the... Oh, just let me look for it. There was like two CIP on the past meeting that you proposed to Merge it as proposed and listing the path to active. So these are the two following ones and I added them to suggest to Merge them online today, but I guess that you cannot Merge it, right, because you are on windows and you don't have rights.\n\n**Matthias** -: Yeah, exactly. And they're still lacking enough approvals anyway, from the leaders. For instance, the prepay meet fixed fees, the moment hasn't been approved at all. So, well also need to get Robert and Sebastian. Inputs on that, I think last time we pretty much treat and the spirit was to say, \"Let's have them Merged as proposed and make it clear in the past active that the goal is 90, well on the side of IOG to review that and give a clear answer from a research standpoint or signature standpoint, yes or no, to CIPs.\" Make sense or won't be implemented, but in network [inaudible 00:28:52] that's pretty much where we stop.\n\n\n#### PR163\n [PR163 CIP-0037? | Dynamic Saturation based on Pledge](https://github.com/cardano-foundation/CIPs/pull/163)\n\n**Matthias** -: On PR163 CIP-0037? | Dynamic Saturation based on Pledge . What about this one? We got approval things with the same situations. Yes. It's been commented a lot. So basically, no updates from this. And last week we also... I mean, we need the others to do the updates to proceed and for us to approve. So we can maybe just park them on the site for now until we have a activity from the young [inaudible 00:29:34].\n\n**M. Àngels** -:  Hey, shall we add a tag waiting for the author?\n\n**Matthias** -: Oh, yeah. Actually [inaudible 00:29:50].\n\n**M. Àngels** -:  Sure. Done. And what we are missing from the author is to add the path to active. Right?\n\n**Matthias** -: Yeah. And also just make sure that they acknowledge the current situation too.\n\n**M. Àngels** -:  Okay.\n\n**Matthias** -: Yeah.\n\n### Review \n\n#### PR242\n [PR242 CIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242)\n\n**M. Àngels** -:  Perfect. So next item on our agenda is PR242 CIP-0050? | Shelleys Voltaire decentralization update weekly update that we decided to make a biweekly update on the CIP that had a lot of activity.\n\n**Matthias** -: Yeah. So it has got a bit less of activity recently. So Michael responded to some of the things that we commented on and mainly there is still this discussions on basically whether or not the... How do you say that? It's actually just reads Michael comments. That would be not by paraphrasing anything. as he's saying. What was that? Sorry. Trying to find the right comments.\n\n**Matthias** -: Yeah. So as you say, ideally, IOG researchers would participate here, not in private, but afterwards, so that we could all collaboratively develop CIP 50 and I hope draft a new 2023 errors revised paper together. So in three months we have the discussion happening. As I said last time from what I got from the researchers, they are actually not willing to discuss it, or they don't have time at the moment for it. We try to set up this focus group, but we've got some pushback. So at this point it's a bit the same situation as to others. Either we need more community leverage or there is not much we can do to make the conversation move forward.\n\n**M. Àngels** -:  So, do you want to put it on hold for a few meetings and maybe after the hard fork before trying to move it again?\n\n**Matthias** -: Yeah. I mean, we'll need to poke basically IOG constantly, I guess, until we get a reaction. There was also this new simulation engine that was supposed to come out. So maybe that would be a good time to look again into the CIP once this simulation engine is out, although there is no clear timeline, so this could also very much be six months or a year from now, which I don't know.\n\n**Matthias** -: I see also there is a comment from last week that I missed from an SPO. Which is quite lengthy. So from the quick reads, it seems to be again, debating on whether or not the CIP makes things better regarding decentralization. Because there is also this question at this stage, and this is what was brought up by the researchers when they looked at CIPs, was that from a decentralization standpoint and again, theory standpoint, this was an approach that was discussed during the early days of Shelley's and that was rolled out because not good enough at maintaining decentralization. So multiples were also considered in designing the first place. Yeah.\n\n**Matthias** -: I mean, the situation we are in today was kind of already included. So there is probably better to do but whether CIP 50 is going in that direction, it's also good question and it's not clear right now. We don't have any quite clear proof that it is actually going in the right direction. So far it seems to be more of in sentiment than an actual well calculations or simulation of that new theory. Maybe that's something which would be worth trying on the site network. But importantly, we don't really have that.\n\n**Matthias** -: And the stake on the test net would be for instance, much more different because it's all free money and people don't have the same behavior, therefore. So, yeah, I don't know. We can try to bring IOG back again, see what's the answer and keep to have short update on that every week or every two weeks.\n\n**M. Àngels** -:  Okay. So we are going to keep it through for next meeting agenda?\n\n**Matthias** -: I would say for now, yes. And let's see, we probably won't get any update from Input Output before the Hard Fork. Because I guess all minds are focused on that, but we might a bit later.\n\n**M. Àngels** -:  Okay. So that was all that was in the agenda for today's meeting. So maybe, Matthias, you want to review those new CIP you commented at the beginning of the session?\n\n**Matthias** -: Yes. But I just have a small urgency to cope with, so I will be back in two minutes.\n\n**M. Àngels** -:  Okay.\n\n\n### Discussions\n\n#### PR267\n [PR267 CIP-0025: Added version 2 and cddl](https://github.com/cardano-foundation/CIPs/pull/267)\n\n**Matthias** -: But I would like to look at PR 267 CIP-0025: Added version 2 and cddl, at least. So maybe we can already print to screen.\n\n**M. Àngels** -:  Sure. Take your time, Matthias and I will leave it here for everybody to read it. I will share the link on the chat and also here. So let's wait a few minutes until Matthias is back.\n\n**Matthias** -: Okay. Sorry for that.\n\n**M. Àngels** -:  No problem. Do you want to make a brief summary of CIP 267?\n\n**Matthias** -: CIP-0025: Added version 2 and cddl #267\n\n**Matthias** -: No, sorry. Yeah. Pull Request 267. Yeah. So this is a iteration on CIP 25, right? Which was the NFT metadata standard we ha not exposed, but mentioned a few points that could be improved last time. And the idea was to make a version two that would address those points or this is basically it. Okay. What I see here. Yeah. I think one thing we discussed and that's also Sebastian maybe mentioning it, or. So it would be good to have the CGTL as a separate files as always, but at least now we've got a clear onchain CDDL specifications of the metadata for the CIP.\n\n**Matthias** -: I think it is mainly compatible version one in the sense that it embeds the same informations, but there is a slight difference in the way the asset names gets included. For instance, right now it used to be just playing UTF-8 text string, whereas this new one uses actually raw binary bytes through CBOR encoding. So since this is entry data any way, that makes much more sense.\n\n**Matthias** -: For the rest, I think what has changed the media type probably, the remains optional. Yeah. And it has also now version number two. Yeah. Overall it addresses the points we mentioned right back on that CIP. And therefore, I think we can move it to last check for next time. It'll be fine to have as is. And maybe it would be also a good opportunity to change the status of CIP 25 to active instead of draft. But beyond that, the rest makes sense. It's basically the same structure and it's just addressing the issues on the asset name plus explicit version name.\n\n**Matthias** -: I see there is a comment in the chat, not on that one, on the previous one. So in what channel do we discuss the IOG, which shows we don't have time. We are getting pushback. Yeah. Not on this call, actually this happens through private channels unfortunately also. So the whole point of making [inaudible 00:43:06]. Yeah, no, I mean, I think so. I think you're right. Although I don't think we keep the illusions, we are working on it. I mean, it's pretty clear that we are not working on it because we are blocked by IOG's feedback at this stage. And that's why I'm just proposing to keep just regular updates on those CIPs to have them Merge as proposed and simply make it clear in the past to active that the next steps now is to be done by IOG, to assess the CIPs and to give a clear answer on the feasibility. IOG, I also include the research side of things.\n\n**Matthias** -: And then it's just, I guess only up to the community to voice it enough that maybe it kind of forces IOGs end to actually allocate time to debts. But at the same time, what is more important between this or for instance, input endorsers, arguably the community should be deciding that's not IOG, generally. So if the community deems that this one is more interesting and more important, then that's probably how it should be framed. But there is also not much channel at this stage to kind of voice those concerns, right? So I'm not sure how to proceed, basically how to make the best out of it.\n\n**M. Àngels** -:  I see on my writing on the chat, may I bring him to the-\n\n**Matthias** -: Yeah, maybe actually having on the chats that would be easier than writing things. Although writing has nice.\n\n**M. Àngels** -:  Hi, Homer. You should be able to speak now.\n\n**Matthias** -: Sorry, he can't talk. Putting kids to bed, ah.\n\n**M. Àngels** -:  Okay.\n\n**Matthias** -: Well, we can have that conversation also off time. So I mean, on the channel later meetings as well and that would be a good feedback also to put to IOG. Maybe the right ways, I don't know, to write letter and make it clear that this is something the committee wants and something times could be allocated to. I don't mind pining Charles directly as well, if needs be. Just poking in and saying, \"Hey, look. This needs attention from the community, from IOG because the community wants it.\" And I mean, I guess if we make enough noise, then it might be okay. I'm not sure if you're trying to speak, Homer, but we hear some...\n\n**M. Àngels** -:  It might be me, I will mute at myself.\n\n#### PR271\n [PR 271- CIP-0027? | Update Proposal: Multiple Royalty Addresses](https://github.com/cardano-foundation/CIPs/pull/271)\n\n**Matthias** -: PR 271- CIP-0027? | Update Proposal: Multiple Royalty Addresses\n Ah. Okay, well let's see how we can do. I don't know, perhaps the Twitter or call seems like the community loves Twitter. What's the next thing that IOG should be implementing? Okay. That was it for CIP 25 update. What time is it right now? At 8:00 is left that. So there is a new CIP for [inaudible 00:47:12], but we won't go through that right now. That's quite length, although interesting. Treasury donations is a bit of the same, quite big overall. And so there is a small update I see on CIP 27 [inaudible 00:47:33] latest, where that was made to PR 271, which is what exactly as NFT projects become more extreme projects may need to handle multiple royalties addresses for team members.\n\n**Matthias** -: This PR is created to [inaudible 00:47:58] show implementation community. So multi [inaudible 00:48:10]. The feedback this class consider during short discussions surrounding royalties on chain. And there is multiple problem that arises when declare multiple priorities increases which research receive, which amounts quality [inaudible 00:48:25]. And what about using smart contract for that? Want to address, but specific holes on who can spend in minutes. That's perfect job for [inaudible] .\n\n**Matthias** -: So I guess I will just cut that add, because I see is the CIP defines a... I mean, this exemption seems to define a off chain [inaudible 00:49:12] in the royalties as for what should be the different distribution, [inaudible 00:49:22] royalties between different addresses. I think this is just accessory in the sense that this is something you can do completely with script company. So with a single address, you make it a script address. And while sending the royalties to that script address, it can then convert completely how the funds get distributed and deemed from that address later on. So that will be entirely up to whoever set the initial royalty.\n\n**Matthias** -: I mean, from a proposal standpoint, I guess proposal is fine. This is definitely something, guess it would be better handled by street addresses traces. So I can comment right now, but I will, once I get back on my lovely minutes.\n\n**Matthias** -: Yeah. I see someone is typing on the chats. I would also very much like to see incentive research team. Okay. So that's [inaudible 00:50:52]. So we'll get back to this, but okay. So on CIP 27, I will comment with what I just said. I mean, this is a substantial update on the CIP itself. So either the format will need to be made backward compatible. I would suggest another CIP and I will actually strongly suggest to use crypto address for that instead of changing anything because of the format and then see. Yeah. So give that as a feedback to the authors, unless we have the author right now with us. I don't think so. Okay. Let's maybe wrap up with the three minutes left.\n\n### Close \n\n**Matthias** -: All right. So CIP 52 agreed to proceed with reaching as active [inaudible 00:52:07] even. CIP 54, Cardano Smart NFTs. So discussion still going, mostly sounds fine so far from the... So face review needs a more in depth review for the API to see if we catch anything. And the author to add a rational section also summarizing the different feedback behind some of the decisions that were made but good to move as last check for next time.\n\n**Matthias** -: CIP 44, additional factor for NFT market verification, felt a bit unclear in terms of, security implications and or spoofing/hijacking this this approach also when led to get that feedback to the author and see, this is something they have thought of. Awesome.\n\n**Matthias** -: Prepaid means fee and dynamic saturation based on pledge, sort of in the same bucket as CIP 50, which looks fine from an editorial standpoint. The ideas make sense at least from a reduced standpoint, but there are debates as for whether or not they improve the situations. And we need clear updates from IOG regarding this. So from an editorial standpoint, there is not much we can do with these proposals anymore except mitigating the discussions, maybe. So we'll keep poking at IOG, keep making noise and maybe see how we can move them forward giving that feedback.\n\n**Matthias** -: We also went through an update on CIP 25, which is adding two, fixing some of the issues that we mentioned months ago, post one first in one. And we briefly looked at an update on CIP 27 which I think would be better addressed by script address and possibly otherwise be made as in other CIP as an extension of the existing one, if that's something the author still want to pursue. So that is it for today. Thanks for attending, everyone. And thanks for Kieran also coming. On vocal to explain everything that is nice. And let's try to follow up on that research involvement for the CIPs.\n\n**M. Àngels** -:  As Matthias said, thank you very much, everyone for attending. Next meeting is not going to be in two weeks, it's going to be in three weeks because we are in a business trip in two weeks, and it's going to be held on the United States time zone. This is 4:00 PM UTC. Thank you very much and have a lovely day. Bye-bye.\n\n\n---\n## Extra\n\n### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md)\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n© 2022 GitHub, Inc.\nTerms\nPrivacy\nSecurity\nStatus\nDocs\nContact GitHub\nPricing\nAPI\nTraining\nBlog\nAbout\n"
  },
  {
    "path": "BiweeklyMeetings/2022-06-28.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [June 28 2022 Transcript](#june-28-2022-transcript)\n  * [Triage](#triage)\n    + [PR 271- CIP-0027? | Update Proposal: Multiple Royalty Addresses](#pr271)\n  * [Last Check](#last-check)\n    + [CIP-0054? | Cardano Smart NFTs](#pr263)\n    + [PR267 CIP-0025: Added version 2 and cddl](#pr267)     \n  * [Review](#review)\n    + [CIP-0044? | Additional factors for NFT market verification](#pr226)\n    + [CIP-0381? | Plutus support for pairings over curve Bls12-381](#pr220)     \n    + [CIP-0050? | Shelleys Voltaire decentralization update](#pr242)\n  * [Discussions](#discussions)\n  * [Issues](#issues)\n  * [Close](#close)\n\n## Summary\n\nRough transcript of 28/06/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Transcript might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significance to you.  \n\n\n## Editors Meeting Flow\n\n**Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n\n**Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n\n**New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \n\nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n**Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n\n**Issues**: Review of the open Issues on the CIP GitHub \n\n**Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  \n\n\n## June 28 2022 Transcript\n**Attending Editors**: Matthias Benkort, Sebastien Guillemot, Frederic Johnson, Robert Phair. \n**Guests**: Morgan Thomas, Michael Liesenfelt\n\n### Triage\n\n#### PR271\n[PR271 CIP-0027? | Update Proposal: Multiple Royalty Addresses](https://github.com/cardano-foundation/CIPs/pull/271)\n\n**Matthias** -: CIP-0027? | Update Proposal: Multiple Royalty Addresses\n  And that current CIP is already active. It's been used by a few marketplaces. So it doesn't quite make sense to modify it as much. As for the proposal itself, I made already some remark last week. I think the author came back saying: \"Yes, true. But that would make for a worse UX. And therefore I would prefer the approach\". They have a good rationale in the proposal, which is fair enough, but I still maintain that it should be made as a separate proposal, as an extension of the existing one rather than modifying what exists and has been used in a while.\n\n**M. Àngels** -:  So I see you maintain a conversation. So from my understanding, Nicolas will need to make a separate, right?\n\n**Matthias** -: Yes, indeed.\n\n**M. Àngels** -:  So shall we add that we are waiting for the author?\n\n**Matthias** -: I think that's pretty much the case now because the proposal by itself...\n\n**Robert** -: [Issues with the audio: Robert cannot hear Matthias] I don't think based on what Matthias was saying before, which he'd probably be staying now, if he could. It sounds like that can only really go ahead as a separate CIP because of the existing implementations that it would be incompatible with.\n\n**M. Àngels** -:  And apologies on my lack of knowledge on this. So in this case, what \nis the next step.\n\n**Robert** -: As far as I know, we would say that this is waiting for author. And then \nif that is the agreement, then we would deprecate this one in favor of the new PR once the author submits it.\n\n**M. Àngels** -:  Okay.\n\n**Matthias** -: I think it can also be the same PR right, it can just modify it.\n\n**Robert** -: I can add that label now waiting for author, if that's okay with everybody else.\n\n**Matthias** -: Yeah, good.\n\n**M. Àngels** -:  I was doing it already, so don't worry about this.\n\n**Matthias** -: So the content itself, I mean, I already admitted my remark last week and I agree with the author. I think I've just asked him to put that as a rational because I would avoid having this discussion again. Should be fine, but just as a separate content.\n\n**M. Àngels** -:  Perfect.\n\n**Matthias** -: It is too different.\n\n### Last Check \n\n#### PR263\n[PR263 CIP-0054? | Cardano Smart NFTs](https://github.com/cardano-foundation/CIPs/pull/263)\n\nOkay. So we move to the items on last check. So we have PR 263, CIP 54, Cardano smart NFTs.\n\n**Matthias** -: Yes. So this one was on last check, I think because it was substantially discussed on the forum. And this is like the results of quite a few weeks of discussions. Had another go at it today, actually. So made a few small remarks. It's mainly on the editorial aspect. So just titles and sections to stick a bit more to the template.\n\n**Robert** -: [Issues with the audio; Robert still cannot hear Matthias] I was hoping again, that Matthias was going to be jumping in with his eloquent voice because he's already said everything. He's made some substantial comments on this issue so far. And I think what he wrote today on GitHub is self explanatory for the things that the author would have to respond to still. I guess this could remain in last check until we have responses about all of those. So I would suggest postponing this until the next meeting.\n\n**M. Àngels** -:  Okay.\n\n**Robert** -: Remaining in last check until we have responses from the author.\n\n**M. Àngels** -:  In this case, I'm going to add also the label waiting for the author.\n\n**Robert** -: Yeah.\n\n#### PR267\n [PR267 CIP-0025: Added version 2 and cddl](https://github.com/cardano-foundation/CIPs/pull/267)\n\n**M. Àngels** -: And let's keep this one for the next meeting. Perfect. Next item on the agenda is CIP 267, CIP 25, added version two and CDDL. Has two approvals, this one. What is missing from this one? Or it's ready to be merged?\n\n**Robert** -: It could be merged right now, it seems.\n\n**M. Àngels** -:  Okay. So I understand that Matthias cannot approve because it's on Windows. So I don't know if you Robert and Fred could merge or either of you do it online.\n\n**Robert** -: It's done.\n\n**M. Àngels** -:  Perfect.\n\n**Robert** -: I just wanted to give it a last call in case any last objections, but it's been approved all around.\n\n**Matthias** -: And I think the last objection was already the last meeting. As we said, it was approved, but we left it open for comment. There hasn't been any comment, so it's good to go.\n\n### Review \n\n#### PR226\n [PR226 CIP-0044? | Additional factors for NFT market verification](https://github.com/cardano-foundation/CIPs/pull/226)\n\n**M. Àngels** -:  Then we go to the items under the review section, you have PR226, additional factors for NFT market verification. According to my notes, we were expecting this week to have some advance on this. I don't know who are we talking about two weeks ago about an example, but maybe I am confused with another PR?\n\n**Robert** -: It's the author, Eric Nichols here in any form today? I guess he would be coming forward if so. From the last comments that Sebastian made, I think there needs to be a little bit filled out in the text of this CIP so maybe if there's no one ready to discuss it, I would suggest that we note in the GitHub that we'd like to discuss this with the author at the next meeting, if we can. And to note internally that we're waiting for comments about the last review.\n\n**M. Àngels** -:  I have asked for this PR and also PR 263, Cardano smart NFTs to the developers' newsletter and see if we can get feedback from developers if they would be interested. Because as far as I remember, I think that it was some concern... We wanted to get input from marketplaces and see if it actually was solving an actual problem from their side.\n\n**Matthias** -: We could maybe try to reach out to the marketplaces directly actually. I mean, there are not so many on Cardano yet, so I think it's still going [crosstalk 00:08:03].\n\n**Robert** -: I'm just going to note on GitHub that from the CIP meeting today, waiting for developer feedback from NFT marketplace.\n\n**Matthias** -: Yeah.\n\n**M. Àngels** -:  I am going to organize and see.\n\n**Matthias** -: If you can ping a few people.\n\n**M. Àngels** -:  I know that we have some telegram channels with marketplaces so we can reach to them.\n\n**Robert** -: So you pitched via private channels?\n\n**Matthias** -: No. Via GitHub I think. That should be enough or perhaps on Discord, I don't know.\n\n**M. Àngels** -:  Okay. We can discuss about how to approach them after the call, if you like to. And next one,\n\n#### PR220\n [PR220 CIP-0381? | Plutus support for pairings over curve Bls12-381](https://github.com/cardano-foundation/CIPs/pull/220) \n\n**Robert** -: This is beyond me technically as well. I can see that there's a good discussion about it, but it's above my level.\n\n**Matthias** -: Yeah. I think we have Las here.\n\n**Robert** -: All I can tell that there is...\n\n**Matthias** -: We could ask him [crosstalk 00:09:32] summary.\n\n**Robert** -: God, I can't even use my mouse button to get through the amount of discussion on this.\n\n**M. Àngels** -:  Hi, Las, do you want to give us a brief summary regarding this PR. I am not able to hear you.\n\n**Matthias** -: Me neither. I'm not sure if Las is speaking. He has un-muted himself too.\n\n**M. Àngels** -:  No, it was me that I am unmuted him.\n\n**Matthias** -: Ah, okay. And he's gone.\n\n**M. Àngels** -:  I think that it has to do with... There's some worse things with Discord and the audio. I need to unmute. Let's try again. Now.\n\n**Las** -:  I muted myself out of the system.\n\n**M. Àngels** -:  Now, we can hear you perfectly. So would you like to make a summary on this PR?\n\n**Las** -:  The data hash one?\n\n**Matthias** -: Nope. Not this one. The pairing over curve, BLS12-381. I think you've been putting many discussions on that one.\n\n**Las** -:  Yes. I have. I was doing something else. Okay. It looks stable to me. I don't think there are many remaining questions. I think there was one remaining question that Michael answered with regards to what to do about the missing operations. I don't actually remember what he answered. Let me see. I think I have the answer right here. I think it might be okay as is. I don't think that's implementation or anything.\n\n**Matthias** -: The implementation is up to the Plutu's team, I guess, at the end or is it something that will be back-ported into Plutus from some other places maybe.\n\n**Las** -:  I think the audio GZKP team or something, I don't remember what they called will work on it.\n\n**Matthias** -: Okay.\n\n**Las** -:  I'm not sure of the exact situation though.\n\n**Matthias** -: Okay. I see Michael was also part of the conversation. So I will assume Plutu's team is aware of what's coming.\n\n**Las** -:  Yeah, they're aware.\n\n**Matthias** -: Okay. So I think we can just reach out to Iñigo then maybe to see last message he posted was I've included your suggestions. I'm not totally convinced about this sub operation count. I removed that. Okay. So I think the author, Inigo is happy to go forward with that. And I did a few cosmetic remarks last time just to make it fit also with the templates. I would just love maybe to have confirmation from the Plutu's team before we merge that. But beyond this, it should be okay.\n\n**Las** -:  Actually, now that I think about it, there might be one thing that we might have to change. I just thought about this, but we have both serialization and de-sterilization and I think it was actually me who recommended that we have both. Now, that I think about that may not actually be a good solution because the exclusion is deterministic. You just need one of them. I don't think you need de-serielization actually, do you? You can't have it if you wanted to have it in data, you need de-serielization. I was thinking because with data, we don't have any de-serielization data function because you can just pass in data natively and they're same with other things. In this case though, we can, so we need de-serielization. I actually think it's fine as is. There is a missing operation, the pairing one, but other than that, it looks fine actually.\n\n**Matthias** -: Okay. Thank you.\n\n**M. Àngels** -:  So how would you like to proceed?\n\n**Matthias** -: I think we can move into last check from the next call and in between reach out to both Inigo and Michael to also have their confirmation on that. And then that will be merged as proposed, I believe until it's actually implemented and verified in the Plutu's primitives.\n\n**Las** -:  By the way, it seems that Morgan Thomas wants to speak.\n\n**M. Àngels** -:  Let's bring him on stage. Hello, Morgan. Looks like we are having a lot of issues with the audio today.\nNew Speaker:  [Audio issues]\n\n**Matthias** -: Okay. Could you detail a bit on that and would it be, you think, crucial for the CIP or would you see that more as an extension to it? Okay. So it's more like do it now because it might be useful later, but there's actually no current use-cases that requires it because I see the CIP considers side chains. The all knowledge [inaudible 00:16:14] basically.\n\n**M. Àngels** -:  I only listen to you Matthias, are you speaking by comments or by chat or it's me that I am not able to hear Morgan.\n\n**Matthias** -: No, Morgan is speaking actually. So I think you are not able to hear him.\n\n**M. Àngels** -:  Wow, weird.\n\n**Matthias** -: Okay. So is this something we've already discussed actually with Inigo or Michael? Because if not, maybe just bring that on the Pull Request comments and we can see how to proceed. Because that seems to me it's quite speculative at this stage that this might be useful later, which doesn't preclude including it depending on how much overhead also it adds on the implementation itself. I have absolutely no idea of what that entail on the implementation, but you probably have a better idea than me. Why Morgan is muted again?\n\n**M. Àngels** -:  I haven't been able to hear a word.\nNew Speaker:  [Audio Issues]\n\n**Matthias** -: He is speaking. Okay. And what about the making those proposal for another already curve support.\nNew Speaker:  [Audio issues]\n\n**Morgan** -: We're not going to use elliptic curves for Orbis V1 because the support is not there. And so whereas I don't have a specific use-case for elliptic curves on Cardano right now that's because the support is not currently there. If the support was already there, then there's a high chance we would be using them.\n\n**Matthias** -: Okay. It's a bit of chicken and egg situation, but I would definitely encourage you to propose that as a CIP. I Think the Plutu's team is fairly reactive on those proposals. So if you need that or not need, but if you would want that for part of Orbis, just go ahead and make a proposal with the Plutu's team, there is a good chance that this can actually be reacted upon and end up being useful for you.\n\n**Morgan** -: Okay. Thanks.\n\n**M. Àngels** -:  Matthias, would you be able to do a summary for the recording?\n\n**Matthias** -: Back to this one actually, that means we can, I think, move it to last check for the next one.\n\n**M. Àngels** -:  Matthias, would you please be able to do a summary of the conversation between you and Morgan because I don't know why I wasn't able to hear it and I am concerned that it's not recorded.\n\n**Matthias** -: Okay. So Morgan is suggesting, or was suggesting to possibly add a support for a new operation that is currently not mentioned in the CIP, which might turn useful if it is there. Although there is not yet any use-case backing it, but it's also because the operation is not there that people does not feel necessarily the urge to use it. And you would like to avoid heading through a entire CIP process later on when it becomes actually needed. But he was also discussing actually having a different supported inputs of different curves, to have a more wider set to pick from for a wider set of applications, which would be in a completely different CIP in that case. And I just encourage them to do that and propose this in addition to Plutu's because this is something they wouldn't explicitly need for Orbis, at least in the first version, but that would be possibly useful later on. So if they have it, that's even better. And I think that team would be fairly welcoming that sort of request.\n\n**Matthias** -: So back to this one, I don't think Morgan wants to add that particular operation in the end if I got you correctly because mostly for the hassle that it would create on discussing and justifying adding it. If you do, then please comment on the Pull Request. We still have quite a long time because it'll be in a proposed state for a while and until it gets implemented. So there is also rooms for modifications once in proposed. But at least we'll move it to last check for the next meeting so we can get it merged and have it as proposed in the repository.\n\n**M. Àngels** -:  Okay. Perfect.\n\n**Robert** -: Maria, one thing I noticed when I couldn't hear a handful of people's voices and I'm sorry if I talked over anyone without realizing it. Hitting Ctrl+R I think will refresh the audio part of Discord and that fixed everything for me.\n\n**M. Àngels** -:  Yeah. I open a new window and it fixed it. I realized that you were talking and it was like you couldn't hear Matthias.\n\n**Robert** -: I could not. I'm very sorry about that. It must have sounded ridiculous. And I hope it doesn't look that way in the minutes, but that's it. Ctrl+R will redraw the window. Sorry, everybody. Okay. But hopefully, that solution will help other people.\n\n**M. Àngels** -:  Yeah. Because it feels really strange because you can hear one person perfectly, but the other one is completely mute. So if this happens to any of you just open a new window and it will be sorted.\n\n**Matthias** -: And don't hesitate to use the chat also for that. So next one is CIP 50, I think.\n\n#### PR242\n [PR242 CIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242)\n\n**Matthias** -: Which always gives me nice afternoons.\n\n**Robert** -: Do we have Michael today?\n\n**Matthias** -: I think I saw him earlier.\n\n**Robert** -: He's joined, but he's still muted. Michael, if you're here, maybe he could unmute yourself.\n\n**M. Àngels** -:  I think I need to do it myself or any of you. The editors can do it too.\n\n**Matthias** -: Doesn't have it.\n\n**Robert** -: There he is.\n\n**Michael** -:  Audio check.\n\n**Matthias** -: Yes.\n\n**Robert** -: Here are you?\n\n**Matthias** -: Audio check. Received.\n\n**M. Àngels** -:  I think that I need to reset the screen sharing. Just give me a sec. Can you see my screen again?\n\n**Matthias** -: Let me check actually.\n\n**Robert** -: All I see are the cat heads.\n\n**Matthias** -: I see your screen, yes.\n\n**M. Àngels** -:  Perfect. Thank you very much, Fred, for the heads up.\n\n**Matthias** -: So CIP 50, I've tried to summarize the conversation that happened over Discord last week. And I try to structure a bit the summary so that it could be readable in a way. Generally speaking, I think we want to avoid having those conversation on Discord. As we said, when we set up the Discord, it was really not meant to discuss the proposals, but just to organize around the meetings. So the discussion would be better to have on more public and more persistent forums. Although I get also that's GitHub discussions and GitHub issues just that it tends to become quite long and how to follow as well.\n\n**Matthias** -: So I don't know, we can perhaps create a dedicated channel on the CIP server just to avoid people floating the general, and we can keep the general for normal conversations or organizing around the events more than discussing CIPS per se. So I'm not sure how people feel about that. We haven't really planned for this, but I think there is room for having a fast-paced kind of conversation channel for the CIP, which could be just on the server, but not on general.\n\n**M. Àngels** -:  As long as then we are mindful and transfer the important things to GitHub. And I think that is something that each one of us needs to be mindful of. Because if not, it's a lot of overhead for either you the editors or a single person.\n\n**Matthias** -: It is.\n\n**Robert** -: I think it's a great step forward to have a topic-specific channels on Discord. The problem usually is that everyone wants to present their own opinions as if they're consensus. But if you give people a little bit of time to vent their opinions in the more public forum, usually, the consensus emerges on its own. And then one of the participants can copy it back to GitHub at that point, like Matthias just did this morning.\n\n**M. Àngels** -:  I just would like to make sure that it's not always Matthias or any of you that needs to be doing this extra work.\n\n**Matthias** -: And it's also my own perspective what I got from the discussion. So it's obviously, skewed to both my understanding and my own biases. [crosstalk 00:29:09].\n\n**Robert** -: It can go the other way. Also, on the other way, I had been having a review of that thread privately with other correspondence and the author. And I actually should have been more public about posting my conclusions or my summaries, I suppose of the existing discussion back to GitHub. So when we do see common threads emerging, we should be willing to post them. And I think that would clear a lot of it up too.\n\n**Matthias** -: So what I see from the discussion and from the past discussion we had also, and I think I mentioned it already last time that there are multiple things being discussed as part of the CIP and it would be nice to maybe organize the conversation in multiple CIPs or multiple different forms of discussions. Like for instance, the protocol parameters, their value, and possibly changing K and things like that. That's orthogonal to the CIP and to just be discussed on the side.\n\n**Matthias** -: And more importantly, it seems that there is a clear divisions between the people who thinks that the CIP does not improve the current situation and the people that thinks it does. And at this stage, it seems to be both opinions and arguments would maybe lack of methodology or at least, an agreed upon methodology that people can use to judge whether or not this solution is better than the current one. The current solution, it has the advantage of being there. So being visibly effective or not in the while, but at least we can say, well, that current approach, we reach this minimum vector. We have reached this amount of stake pools. So it's visible.\n\n**Matthias** -: The new approach, it's very hard to say from just reading the proposal, what will be consequences. So there is really this need of a framework or clear methodology to both evaluate the solutions and according to some metrics and some outcomes that we try to maximize and say, this solution is objectively better than this one because this and this and that. And I think this is clearly missing on that proposal, which is why we have such a clear divisions between those who think it's not good. And those who think it's good, basically.\n\n**Michael** -:  I agree with that. As the author, I've incorporated the updates and revisions to adopting that rigor and methodology to the path to active. As Cardano transitions to an open source project, we're going to have to be very good about reaching consensuses in a non-hierarchy away. And that includes all of the input and research of the IOG team. So if they're not participating yet, consensus is not reached yet, but they have responsibilities and obligations to deliver Vasil and so that comes first. But then after that, there should reasonably be a deadline on sharing prior research or turning it over to the community if IOG can't lead that research anymore.\n\n**Matthias** -: I tend to agree with the sentiment. It's a bit odd at this stage that the main party needed for that conversation is actually not taking part into the conversation, which make it very hard to move forward. Though there has been someone, \"mkt\" on Discord, actually also here mentioning is from IOG, but also would be nice to have a clear point of contact. I do agree. So far it has been Kevin, but Kevin is also busy with Vasil and other stuff at this stage. So we are a bit missing this point of contact with the IOG research team in particular.\n\n**Michael** -:  There's no rush. It's more important to get it right. And not make, in my opinion, another peer review mistake.\n\n**Matthias** -: Yeah. So this is also why I've started to really poke our own researchers now at the Cardano Foundation, which is building also expertise on this, who agree on maybe trying to define an approach for evaluating the proposals and the solutions. So I've shared that as a last comment today, and I know that Reza also wants to join eventually the discussions. It was just not available today, but that would be also a step forward I think.\n\n**M. Àngels** -:  Next meeting is going to be next week, but it won't match Reza's schedule.\n\n**Matthias** -: Yeah. Reza is in Canada so it's also in this time zone.\n\n**M. Àngels** -:  So shall we put this on hold until Reza can jump into the meeting in three weeks?\n\n**Matthias** -: We can definitely continue the conversations on the side as it has been happening, but not on Discord channel, if possible. And get it back on, I guess, the CIP meeting, again in the US based time zone.\n\n**M. Àngels** -:  Okay.\n\n**Matthias** -: We can also have a quick catch-up on it next week just to see where we're at again.\n\n**M. Àngels** -:  Okay. And the thing that I would like to clarify because it is not clear to me is if we are going to do on specific channel on Discord or for the moment, it's still better to try to use GitHub as a more public reflected and official channel.\n\n**Matthias** -: I would prefer GitHub. If people strongly want a Discord channel for discussing this one, I think we can also go for that.\n\n**Robert** -: I think the only way we're going to see the improvement is if we create the Discord channel, I can't think of a better test case we will get for a topic specific discussions than this CIP we have right now. And at this panel, within a month or two, we could have similarly contended proposals. And we don't want anyone to have to do the work that Matthias just did in order to digest four weeks of discussions. So we can in the hopes of getting through it all on a single meeting.\n\n**Robert** -: So can we try to separate them and see if it works? See if we can rely upon the people to keep bringing it back into GitHub once some consensus or important points are made on Discord. And then if it seems like the balance is coming out wrong, if it seems like things are only being recorded in Discord, but not being taken back to GitHub, then we can maybe look at how that how we could make that process work. I just [crosstalk 00:36:49].\n\n**M. Àngels** -:  Can you explain it again, at least from my end, there was a little bit of background noise and I couldn't understand. I mean, I think that you were suggesting to keep the discussion on Discord, but make everyone owner of trespassing their comments.\n\n**Robert** -: I mean, a lot of the \"discord\" on Discord. A lot of the discussion on Discord was repetitive and we don't want that happening on GitHub. A lot of the repetitive discussion on Discord was opinionated. And we need a chance for the opinions to play out before they're recorded as actual point of view to be recorded in GitHub. So without having a forum for people to get through the preliminaries, we end up either recording too much on GitHub, which is the opinions and the bickering, or we end up recording too little because people forget to bring back the main point from the social networking channel to the developer's record on GitHub.\n\n**Robert** -: So I would say that we first try to create that channel to see how it works. And then we adjust the balance in both of those conversations to be sure that the less relevant stuff is confined to Discord and the most relevant stuff is recorded on GitHub. It will take practice, but I'm sure it can work. I do feel pretty strongly about that. And I'm willing to monitor it as well as do some of the digesting that Matthias just did, which I had intended also to do on my own at some point.\n\n**M. Àngels** -:  And can I suggest to ask each participant in this casual conversation, one, not an opinion, but a more reflected position on this to ask to add it to GitHub themselves and not do the summary, the editors.\n\n**Matthias** -: I think this can work if we discuss precise question on a Discord and then our goals, if we have precise goals, and then we bring back the results, the outcome of that discussion on the GitHub. For instance, one thing I would like to see people agree on is what would it means to be decentralized for Cardano, for this whole thing here. If people can agree on a definition of what decentralization is and would entail with something that is quantifiable and have that discussions because from the past discussion, it's not yet agreed between participant what it means.\n\n**Matthias** -: But once this is agreed that at least gives one criteria upon which we can start judging the CIP and the existing solution. And that will be one question. Then we move on to a different question or a different goal. And we try to structure the conversation on Discord around those goals. Anything that deviate from those goals, well, it should be self-disciplined: don't do it basically. So try to keep an eye on each other, but just say: \"no, this is not the topic. The current topic and discussion we try to solve is this particular thing\". So we break that big problem into smaller chunks and organize just discussions on one particular action on Discord up until we have done or tackle all of them.\n\n**M. Àngels** -:  We can give you a try. I mean, it's going to be a trial and error and we will need, as Robert said to learn from it. So let's give it a try if you agree.\n\n**Robert** -: Yes, it will be easier to do by setting up the discussion on that channel because the next time a contended issue comes along, it's going to blur the discussion. People may drop out or pay less focused attention. The framing questions that we might want to ask may get forgotten or push back farther in the discussions. I think that the only reason we've been able to focus on this particular issue is there aren't currently any ones like it that have attracted the same attention from the community. So we should move it off to a separate thread while we can do so easily before it gets mixed with other topics. So I would vote for creating that channel. Yes.\n\n**M. Àngels** -:  Yeah. Are the rest of editors agreeing to create a specific channel?\n\n**Matthias** -: Yeah. So long as it can be a bit structured. Yes. Give it to try and see.\n\n**M. Àngels** -:  Fred. I don't know if Sebastian is here too.\n\n**Fred** -: Yeah. All good here.\n\n**M. Àngels** -:  Thank you very much. And I don't know if Sebastian... I will ask him later. So what I will do is if you agree is instead of creating a new channel as almost all the conversation in the general channel is around this CIP. I am just going to rename the channel and create another general one. So we have all the conversation or I can copy/paste it, whatever you prefer.\n\n**Robert** -: I didn't think of that, but I think that's a good idea because about 95% of the comments in that general channel are CIP-specific, and then new general comments can go into a new general channel. We don't want have a CIP 50 discussion without most of the comments that have been made already so that would actually catch them all up. I think that's a good idea.\n\n**M. Àngels** -:  Okay.\n\n**Matthias** -: Fair points.\n\n**M. Àngels** -:  Perfect. I think that this was all that was on the agenda for today because on our discussion there's specific topic around creating a specific channel for the CIP. I don't know if there's anything else that you like to discuss.\n\n**Robert** -: Just to be sure we don't miss this last point that Nick had made about the default channel. When people arrive in the Discord, whoever does the moving and renaming, we'll have to take a look at that of just looking at the last comment in the meeting room chat. So we have to look at that after moving the thing to be sure they're not dropped in this CIP 50 channel by default.\n\n**M. Àngels** -:  So can you repeat, Rob because I thought I was understanding you and I got confused by the end.\n\n**Robert** -: Okay. Do you see the last comment that's made in the meeting, the CIP editors meeting room chat?\n\n**M. Àngels** -:  Okay. Yes. This over here. So this is around CIP 50, right?\n\n**Robert** -: Yes.\n\n**M. Àngels** -:  So I'll make sure to copy/paste and add this to the main conversation around CIP 50.\n\n**Robert** -: Yes. And if you're the one who creates the channel, just be sure that when new subscribers follow an invite link, they are not put-\n\n**M. Àngels** -:  In the CIP 50, but in the general one.\n\n**Robert** -: ... In the renamed channel, but in the new general channel, not the old general channel.\n\n**M. Àngels** -:  Sure. That's a very good point. Okay. So I suggest to do a wrap-up as we have only seven minutes left. So Matthias, would you like to do the wrap-up of the session?\n\n**Matthias** -: Yeah, let's go back. So am pulling out the Pull Request. So we looked at the royalty, the CIP about extending the royalty for NFT, to support multiple addresses, and we've asked the author to actually move that one as a separate CIP because it is essentially changing already established and active CIP. So a few comments, but those were addressed by the author. So they will be put as a rationale for the CIP.\n\n**Matthias** -: We looked into the Cardano smart NFTs on which there was also more recent comments. So we'll also have this one as last check next meeting, which is next week just to see if the author has addressed them or not. Overall, I mean, we do agree with merging the CIP as proposed, but there was a few comments first to address.\n\n**Matthias** -: CIP 25, it was already in last check in the previous call. There was so many comments done on it. And a few minor cosmetic changes we recorded last time were addressed. So we can merge that one actually. If someone can do, I think it has also didn't write number of approvals already.\n\n**M. Àngels** -:  It was merged online by Robert.\n\n**Matthias** -: Thanks, Robert, didn't notice that. Then review CIP 44, additional merger for NFT market verification. All the ID looks good. The CIP is okay, but we want to have buy in from the NFT marketplaces. So as action item for the editors, we're going to share that with the prominent marketplaces on Cardano and see if that's addressing something they are also facing.\n\n**Matthias** -: CIP 381, a lot of discussion has been going on that one. And so last confirmed, it has reached a relative consensus so far. There was a discussion whether or not it should add an extra primitive, but I think, Morgan took it back. If not, please comment on the Pull Request. We also want to have confirmation from the Plutu's team that this is in the state where it can be acted upon and move from proposed to eventually being active. So we can have it as last check for the next meeting. And if nothing is said, we'll just merge it as a proposed CIP.\n\n**Matthias** -: And finally CIP 50, so we had big discussion on Discord, which we're going a bit disorganized. So we are going to set up a proper channel for discussing that one, try to be diligent also in bringing back updates. Points that are being agreed on during that channel back to GitHub so that we can also have a review on GitHub, and give like a public track record on what's happening for the CIP. Overall, we also need more investment from IO on that CIP, more engagement from IO research. So we'll wait after the Vasil Hard Fork has happened. And after that definitely, put a bit more pressure. Let's put it nicely on IO to participate on that conversation. Otherwise, figure out how we can actually move that kind of conversation forward as Cardano becomes more and more open source indeed. So let's have dedicated channel for that one and see where the conversation goes for next week or the next meeting. And that's about it, I think.\n\n**M. Àngels** -:  Thank you very much all for attending to the session today. Next meeting is going to be held next week as we skip a week last week. So July the 5th at 8:30 AM UTC, I have added the next two meetings as events on Discord so you can plan in advance. The only thing is that the agenda will be added a week before each meeting. Thank you very much again. And I would like to ask to the editors if they can join me in the green room for two minutes, it's for the problem with one link that I would like to solve. So thank you very much and see you next week.\n\n\n---\n## Extra\n\n### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md)\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n© 2022 GitHub, Inc.\nTerms\nPrivacy\nSecurity\nStatus\nDocs\nContact GitHub\nPricing\nAPI\nTraining\nBlog\nAbout\n"
  },
  {
    "path": "BiweeklyMeetings/2022-07-05.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [July 05 2022 Transcript](#july-05-2022-transcript)\n  * [Triage](#triage)\n    + [CIP-0059? | Terminology Surrounding Core Features](#pr274)\n    + [CIP-0038? | On-Chain Token Metadata Standard](#pr137)\n    + [CIP-0030? | Events API](#pr151)\n    + [CIP-0037? | Dynamic Saturation based on Pledge](#pr163)\n  * [Last Check](#last-check)\n    + [CIP-0054? | Cardano Smart NFTs](#pr263)\n    + [CIP-0381? | Plutus support for pairings over curve Bls12-381](#pr220)     \n  * [Review](#review)\n    + [CIP-0044? | Additional factors for NFT market verification](#pr226)\n    + [CIP-0050? | Shelleys Voltaire decentralization update weekly update](#pr242)     \n  * [Discussions](#discussions)\n  * [Issues](#issues)\n  * [Close](#close)\n\n## Summary\n\nRough transcript of 05/07/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Transcript might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significance to you.  \n\n\n## Editors Meeting Flow\n\n**Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n\n**Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n\n**New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \n\nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n**Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n\n**Issues**: Review of the open Issues on the CIP GitHub \n\n**Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  \n\n\n## July 05 2022 Transcript\n**Attending Editors**: Matthias Benkort, Sebastien Guillemot, ~Frederic Johnson~, ~Robert Phair~. \n**Guests**:\n\n### Triage\n\n#### PR274\n[PR274 CIP-0059? | Terminology Surrounding Core Features](https://github.com/cardano-foundation/CIPs/pull/274)\n\n**Matthias** - :  Yeah, we can start already and go right in the first item, right, CIP 59, which was proposed by Jared, I think after a chat on a different CIP or different debates around Vasil versus Babbage, and what do names mean exactly in Cardano. A lot of people seem to have gotten confused by the names being employed. So he wrote a small, informational CIP, there is not really much to debate in a way except maybe if people disagree with it and want to change it, but since there is a track record already... It just explains where the name come from, what they are and the rationale behind is, why they were chosen like that. Like between era, and a phase, and a network and protocol. And he has also put up a nice table which summarizes all of that, which is nice, so it gives just a bit more clarity about naming.\n\n**Matthias** - :  And yeah, so I pointed to him last time a few things to do regarding the proposal of just the editorial stuff, putting a number, putting the readme in the correct folder. He did all of that and he already marked it as active as I suggested, just because as I said, it's an informational CIP explaining the terminology picked by the core team. It's from the core team itself and it's also recording or explaining things from the past six eras or so. So yeah, there is no point going to things like propose, and then active, and then whatever, unless someone disagree with that. Okay. \n\n**Sebastien** -, and your opinion maybe, if you are here.\n\n**Sebastien** -:  I joined probably through the conversation, so I'm missing the beginning.\n\n**Matthias** - :  Yeah. Okay, sorry. We are talking about CIP 59, the terminologies surrounding core features, which was proposed by Jared some time ago to clarify a bit of the terminology around the core features. And I was saying, this one could probably just go as active right away because it's just explaining what's in there.\n\n**Sebastien** -:  Yeah, I think so. I think that makes sense. I read through it and everything, and it made sense to me. So I don't mind both merging and marking it is actually the right away.\n\n**Matthias** - :  We have a question. Oh sorry, that's some other stuff. So yeah okay, let's do that. I think we have reviewed it. I would just add my review now, that's all the... Yeah, All change has been made. Happy to approve. Happy to merge. Okay. Next one, on chain token metadata standard which has been reviewed for a while. We had a few remark questions. A lot of people were debating stuff in particular. The security of that, I think Michael Peyton Jones is usually against anything that is put on chain and it is based on minting transactions because indeed it has security issues or implications.\n\n**Matthias** - :  If we start heavily relying on people providing the metadata being the same as people minting the tokens, which has been generally the case in Cardano, but it's not a given. So I think he has a fair point. But yeah, the proposal has been stalled ever since, I think. It hasn't really moved, we are waiting for the author to come back to it. But yeah, I'm not sure if there is much to say on this one. Yeah. No remark, no question. I guess we can just leave it there.\n\n**Sebastien** -:  Yeah. I have something on this topic, but I'm going to have to address it in maybe a minute, if you just give me a minute.\n\n**Matthias** - :  Yeah, okay, okay. So depending on what you see, we'll see what to do with that one. Maybe it can also be picked up by someone else for a different standard or maybe reformulate the ID in a slightly different way. Yeah. And I don't know if there is any prior work also on that, I bet there is. So people putting all kind of metadata on chain. Now that has been the case for NFT, and I don't know if it has been the case for tokens themself -- I mean fungible tokens, at least I don't recall any project doing that.\n\n**Sebastien** -:  Okay. Sorry, I'm back. Sorry, I had to step on the elevator really quickly. Yeah. So the problem with the CIP is just the metadata portion of it. And Michael Peyton Jones is correct that there is no partially good solution to this. And yeah, my understanding is that there's a lot of discussion, then we are waiting for the author. I was wondering if maybe we pick this up as part of the log standard that I talked to you about over DM. So to fill everybody in on this, basically in Plutus, you can log messages as a trace command. Apparently, this is ignored by everybody, but you... indexers that basically rerun the Plutus code, figure out what the log statements were for the execution and then make this available to indexers to do stuff on.\n\n**Sebastien** -:  So if we standardize this logging format with a topic, we could do minting transactions, can basically log out the metadata only once in the transaction and then get some agreed upon standardized topic for this. And then indexers would just need to be looking for additional places for contracts, they would just look for whatever minting transaction includes log statement that provides this information.\n\n**Matthias** - :  But you would also not be solving the problem that Michael was pointing at, right, which is that it's not necessarily the same person that is providing the metadata than the one doing the minting, it changes how you specify the metadata. So instead of having them as plain metadata, which is not verifiable in a way, you just have them as script logs. And I think I also agree with Les, and that's what I was telling to you in, well, private. It sounds to me like it would be very inefficient if every indexer has to run all the scripts in order to extract the metadata, although that could be worked out, I guess if we have a special maybe piece of metadata that identify those such transactions. So I don't know, a certain label if present, you know you have to execute script and extract the logs from it. So perhaps we can just bring it as a different CIP.\n\n**Sebastien** -:  Yeah. But I think it does tackle the issue because it makes other person writing the contract the same person that owns the token metadata, because it's no longer going to be in the transaction metadata field. So it couples the two together, is what you wanted to solve the issue, right?\n\n**Matthias** - :  So you mean that, ah, it's captured in the policy itself.\n\n**Sebastien** -:  Yeah. Exactly, yeah.\n\n**Matthias** - :  Yeah? Okay, okay. I guess then you could make the argument then.\n\n**Sebastien** -:  I think this would solve this issue. So I feel like we could revisit this if we just come up with the solution for the logging problem, which requires us to come up with a sip for how to come handle topics for log statements, which doesn't have right now. And then another sip for how we want Cardano to change to make this efficient in some way, shape or form.\n\n**Matthias** - :  Yeah, yeah, yeah. Because the logging, we have it at a stage, but you only have it, I think, if the script is failing. So when the script is happily successful, I'm not sure you can get any trace really out of it. But yeah, I guess the first good step is a CIP, which might requires another CIP, which would be a new Plutus built-in for doing this topic centric logging.\n\n**Sebastien** -:  Yeah. Which I think is the right solution because we could try matching a topic into the existing logging scheme, but it would be ugly. So probably it's better just come up with a new built in, come up with a solution to make it efficiently, and then we need some hassles [inaudible 00:10:52] developer to volunteer to do it, which is obviously the hardest part.\n\n**Matthias** - :  Yeah. I think you're going to get a lot of pushback on the logging idea because as I was saying, Plutus is just one big expression right now, there is no statement or imperative execution. So, when do you put a statement and where do you evaluate a statement is up to the interpreter at this stage, even though everything is strict and it's pretty much, well, intuitive. That's probably getting in the way of low-level optimizations and stuff like that. If you start requiring stuff to be done in sequence, and to be able to rely on that as a contract writer, that might be tricky. Perhaps actually, Las also has some inputs on that because from working with Pluto / Plutarch, that's maybe something you also thought of. I'm not sure if you want to.\n\n**Sebastien** -:  Yeah, it don't necessarily mean to hijack the CIP meeting to discuss this, but definitely Les, if you have some thoughts on this, or if you wanted to take this offline after this call and discuss this, I'd be really interested because this is something that we want for a few different projects on our side, and I'm sure this would unlock some other stack or other use cases like this token metadata on chain registry.\n\n**Matthias** - :  So sorry, I'm just writing on the chat. So yeah, let's just make a CIP offline discussions out of it for now and see. But yeah, I think my sentiment is that you would probably get some pushback from the Plutus core team because you're going to introduce side-effects.\n\n**Sebastien** -:  Yeah. Yeah. We get pushback on every feature, so it's just part of it.\n\n#### PR137\n[PR137 CIP-0038? | On-Chain Token Metadata Standard](https://github.com/cardano-foundation/CIPs/pull/137)\n\n**Matthias** - :  Yeah. It's part of the game, I guess. If you can argue it well enough, maybe, but yeah. Okay. So for this particular one, which was CIP 38, I think we can just park it for now on the side, meaning that we're still waiting for the author. And if the author is not willing to move it forward, we won't be doing it for him basically. So yeah, there has been a few things said already, it's all recorded on the pull request as comments. So yeah, next steps are up to the author, not us.\n\n#### PR151\n[PR151 CIP-0030? | Events API](https://github.com/cardano-foundation/CIPs/pull/151)\n\n**Matthias** - :  Which brings us to the next one, CIP 30, which is, I guess in a similar situation. I think we talked about that one several times in the past. Also, it was initially part of CIP 30, it was then extracted when CIP 30 was merged because there were still ongoing discussions and people were not sure whether or not they wanted it. I think there are a few wallets now that supports events as part of, not about CIP 30, but as part of this wallets extension work. And there is, I think, even a website put by this is part, right, with the state of what people support through the extension, right? Some things are labeled as experimental and I recall there was something related to events in there.\n\n**Sebastien** -:  Yeah. So we put the old event that Nami had on the initial release, which is slightly different than what's in the events API PR, because the events API PR takes what Nami had originally and adds just on top of it.\n\n**Matthias** - :  So I'm just trying to find, okay, the website. Here is there just for linking it in the chats for people who wonder, so this is what I was mentioning ( https://www.cardano-caniuse.io/ ).\n\n**Sebastien** -:  Yeah. And I still think we should have some event scheme. It just hasn't been a priority for a new one, which is why the CIP stalled. I do think it's important to have it.\n\n**Matthias** - :  Yeah, okay. So I guess when the need will arise again, that CIP will just be either resurrected or superseded by some other CIP. But at this stage, the proposal is pretty dormant and waiting for the author. So, also not much to talk about, I guess.\n\n#### PR163\n[PR163 CIP-0037? | Dynamic Saturation based on Pledge](https://github.com/cardano-foundation/CIPs/pull/163)\n\n**M. Àngels** -:  I added these few PRs to the agenda because we have been waiting for the author for several months. So I was wondering what to do in these kind of cases that the authors do not respond.\n\n**Matthias** - :  That's a good point. We could also close the PR after all, if there's some inactivity. People are still free to come back and ask to reopen them or comment on them saying, \"Hey, I'm here. I have changes,\" or make a new PR, but I think it's not a big deal. But if we do that, I would also first, maybe mark it as a change in our CIP process, so make an update on, CIP 1, just say, \"After X months of inactivity, we'll just close the Pull Request for keeping things tidy.\" That doesn't mean this proposal is rejected or anything, it just means it's inactive and we need to put some order on the repo.\n\n**M. Àngels** -:  Do you think it's worth it to make that change on CIP 1?\n\n**Matthias** - :  Yeah. I mean just making it in CIP 1 to be upfront saying, \"This is what the process is,\" and at least people can also disagree with process as we change it, right, it's important, I think, to leave also the conversation open for that. But yeah, I would definitely say after, I don't know, four to six months of inactivity, which is quite a lot, we just close the Pull Request and people are free to come back with a new Pull Request if they still want to promote or propose their changes.\n\n**M. Àngels** -:  I think it's good because in that way, we have a process and we don't need to revisit those proposals, and they are not waiting for the author forever.\n\n**Matthias** - :  Yeah. Yeah. And we avoid having too many Pull Requests stacking up, which are just waiting for author.\n\n**M. Àngels** -:  Mm-hmm.\n\n**Matthias** - :  Yeah.\n\n**M. Àngels** -:  Good. I think that might be another one in the same study, so we can just skip if...\n\n**Matthias** - :  Which is the CIP 37, right?\n\n**M. Àngels** -:  Yeah.\n\n**Matthias** - :  Yes. Yes. Yes. So I guess we'll just leave it there for now. I will propose the small change to CIP 1, and yeah, we can redo it next week, I guess, fast track it a bit if people really disagree with that, but I don't think it's any big deal. We'll move forward. \n\n### Last Check\n\n#### PR263\n[PR263 CIP-0054? | Cardano Smart NFTs](https://github.com/cardano-foundation/CIPs/pull/263)\n\n**Matthias** - :So next is, last check, Cardano Smart NFTs. Yes, indeed. I guess same situation here. The author was a lot more reactive, but yeah. It was a few comments last week and I think the author still haven't got time to go through them, so we can just keep it for this week and put it again to last check next week.\n\n**M. Àngels** -:  I have approached some marketplaces trying to get their input. So I think it's good as you mentioned to wait until the next meeting and see if we get feedback from them.\n\n**Matthias** - :  Okay. Do you think maybe we can mention it on the Pull Request, all the marketplaces you've approached just to have a track record on the PR itself?\n\n**M. Àngels** -:  Yeah. Do you want me to do it myself?\n\n**Matthias** - :  Yeah, since you know who you've contacted.\n\n**M. Àngels** -:  Okay, cool. So I'll do that. I will add a comment after the call and mentioning the marketplace that had been approached.\n\n**Matthias** - :  Yeah. And there was also a mention in the newsletter, I think Robert pointed that out on the PR. On IOG newsletter, there was a mention of two CIPs if I recall correctly, there was this one.\n\n**M. Àngels** -:  Yes. He added the link in a comment.\n\n\n**Matthias** - :  Yeah, added the link, exactly. CIP 44 and CIP 54 were mentioned, that are touching CIP marketplaces or NFTs. \n\n#### PR220\n[PR220 CCIP-0381? | Plutus support for pairings over curve Bls12-381](https://github.com/cardano-foundation/CIPs/pull/220)\n\nYeah, okay. Next one, the pairing support over BLS 381, which we discussed a bit last week. And yeah, it was discussed with the Plutus' team, reviewed, adjusted many times. So yeah. So maybe the only thing is to see if the status shouldn't be changed to propose perhaps, I think it has reached a maturing of stage to be proposed now. So I will ask Nigo if he can do that. Yeah, and it has also just renamed the file to readme. So okay, beside a few minority editorial work, this one should be ready to go. So I will just comment directly. Okay. And I think... Okay, any comment on that one? No? Yes. I think we discussed it extensively last week already. \n\n### Review \n\n#### PR226\n[PR226 CIP-0044? | Additional factors for NFT market verification](https://github.com/cardano-foundation/CIPs/pull/226)\n\n**Matthias** - :Okay. So CIP 44 is next, and is also one we are waiting for NFT marketplaces feedback. Well, at least it is the main one.\n\n**Sebastien** -:  Yeah. I think the message asking for feedback was sent out a day or two, right? So I think we're still waiting.\n\n**Matthias** - :  So there's probably not much to do today on this one. Yeah. As we said last week, the ID looks good overall, but we had the question on whether or not this is useful for NFT marketplaces or endorsed by NFT marketplaces because it has to in order to become active. So we better include them early on in the feedback loop before merging or yeah, going with the proposed CIP. \n\n\n#### PR242\n[PR242 CIP-0050? | Shelleys Voltaire decentralization update weekly update](https://github.com/cardano-foundation/CIPs/pull/242)\n\n**Matthias** - :So I guess we can just move to the next and last one on the agenda. Our favorite, CIP 50. I haven't got time to go through all the comments since last week, there has been a lot discussed. Again, there is a new member, I would say, in the discussions now, Robert, who is a mathematician working at Tesla, from what I got, who has got an interest in the CIP. So there has been quite a bunch of conversations between yeah, Rob and Michael, fortunately on GitHub this time, on the GitHub issue. We also have created a Discord channel for that one as we've been discussing last week, so a few more discussions have been going on here as well.\n\n**Matthias** - :  And I've also spoken to Kevin Hammond from IOG last Saturday actually, about again, trying to get back the researchers from IOG into the conversation. So Kevin was quite surprised actually that this didn't happen because, to quote him, \"Usually researchers are quite happy to provide feedback on their work if given the opportunity.\" So he's going to change that a bit and see if people can actually get into this study group that we've been trying to push up last time already, yeah, and get that moving. So I've put that in his hands so far. With the Vasil out of the way now, he has a bit more availability to pursue that on the IOG side, so yeah, fingers crossed and we'll see, I guess in the next biweekly, if this has lead to anything. I should also probably mention that on the CIP PR itself so that people who are currently discussing are also aware, and then maybe up to the author to see who he wants to include in the conversation from his side as well.\n\n**Matthias** - :  Yeah. So beyond that, I haven't gone through all the comments. We could go through the comments as part of this current biweekly as well, since we have a bit of time left, or we could leave that for another time and try to do again a summary of the conversation that had been happening. Any thoughts on that?\n\n**Sebastien** -:  Yeah. For this one, I feel like the summaries are nice, but I feel this one needs more than just a summary.\n\n**Matthias** - :  Of course. And as I said last time, I think this one can only move forward. At some point with regards the participation of IOG research. Without that, I'd say it's very difficult for that proposal to make concrete steps. And yeah, we have, I think two, yeah, Christopher and Colette. I think you are here both of you probably for the CIP 50, so maybe you have all sorts of stuff you want to discuss or say, please bring them up. Yeah, so I guess same situation for everyone. So I don't really have anything to add mainly in this call. We're talking about safety process in general, okay. And okay, so both of you. So is there any other items then we could discuss today before we wrap it up on maybe CIP 58? I don't think we have talked about that one yet. It was proposed and then proposed again in a new format, I think. So it's not from the same author, but it's from the same team as far as I understood, so it's superseding the previous proposal. So the first proposal was... Where it is? I'd lost it now.\n\n**Matthias** - :  Okay, it was PR number 268 and the second proposal was PR 283, which is a new Plutus set of built-ins about doing bitwise operations in Plutus. So manipulations on bits, which is quite common to do on low level stuff. It's been missing from Plutus so far, there is very no support from manipulating byte strings in general and doing bitwise operations in Plutus. Although it can be quite interesting because of the, well, performance aspect it can also bring in the picture. So it's a bit risky these things usually. So I haven't gone through the proposal yet, but I hope that it's introducing a somewhat safe API for doing bitwise operations and not allow people to shoot themselves in the foot with this stuff. I see it's proposed by the MLab's team and it has also been discussed with the Plutus team quite extensively, it seems. So this doesn't come out of the blue basically. So I think it'll be good to have it for review next time so that we get some good time to go through it, have a few comments and re-bring the spotlight to it on the next biweekly.\n\n**Sebastien** -:  Yeah. Makes sense to me.\n\n**Matthias** - :  And we can maybe do a bit of PR management at the same time and see if we can close the first one. I will just comment on this directly. It's marked as legacy deprecated already. Yeah. And Robert actually already commented on that. Okay, anything else? I see there is a small one, maybe PR number 275, sorry, which is just updating line numbers and this time, putting an actual permalink link in CIP 8, which I think is good. So initially, it was just updating line numbers, I think, but then Robert rightfully asked to just put a permalink link in there so that we don't get to update that line number every week. So \n\n**Sebastien** -, that's probably something also you would have a minor comment on. I'm not sure if you are still involved with the CSL anymore, or if you are fully switched to the multi-platform library.\n\n**Sebastien** -:  Yeah. I haven't touched CSL for a long time. Yeah, for the comment related to WebPull, I don't know of a good alternative website that allows you to run WebAssembly in the browser for free. WebPull is the one of the few that did it, but I feel like now that WebAssembly is more common, there might be other platforms that work better.\n\n**Matthias** - :  Because a rep needs to be paid by an owner?\n\n**Sebastien** -:  Yeah. So it used to be free and then they changed it to paid, which is why it all links up probably.\n\n**Matthias** - :  Okay. So at the same time, it's also filled to the current PR, so perhaps that's one good use of an issue. That's the other rep link, it doesn't work anymore, fine. But at least this PR fixes already a dead link, which is good in itself, which is comment to that actually. Okay. Nope, doesn't work. So I will open an issue following that. And where is actually the comment about rep link? Here. Rep link eight. So rep eight link doesn't work more. Okay. So this one is done. Do we have any small PR like that or should we just wrap it up for today? Or anything else people want to bring forward? Nope? Oh sorry, I've got a phone call. Okay, sorry about that. \n\n### Discussions\nN/A\n\n### Issues\nN/A\n\n### Close \n\nSo let's wrap it up, maybe?\n\n**Matthias** - :  So we went through CIP 59 today, the terminology that runs core features. We agreed to merge it as active, as it is informal CIP bringing clarity on naming and coming from the core team directly. Then we've looked at CIP 38, CIP 30, CIP 37, I think that's the only three ones, which are waiting for an update from their authors. We discussed that for those CIPs that have been idle and dormant for a few months, it might be good actually to just close the Pull Requests and well, let the authors come back with either a new Pull Request or an update if they do. But before doing that or in parallel of doing that, also specify that, \"In the CIP 1, as a small change or in the process,\" so that we are upfront with what's going to happen. And it'll help us keep the repository tidy.\n\n**Matthias** - :  Then we discussed CIP 54 and 44, which are two CIPs about, one is smart NFTs and the second one is additional factor of verification for NFT marketplaces. In both cases, we have reached out to the community and to marketplaces in Cardano to get their feedback on it. So we've reach out to the community through the IOG newsletters, and we've reached out directly to the marketplaces to see if we can get any buy-in from them. Discussed CIP 381. This one, mostly mature to be now merged as a proposed CIP. There was two minor editor changes to be done, first, just renaming a file as readme.md and changing the status to proposed. So we've pinged the author on GitHub, once done, we can move forward and merge that one. And the path to active will be the implementation in Plutus by the Plutus team and the delivery through probably another Hard Fork. I'm not sure if this one occurs at Hard Fork though, might not be, but anyway.\n\n**Matthias** - :  We discussed then also briefly CIP 50. There has been many comments done between last week and this week, and basically no one really had time to go through them, so we'll discuss it again. In the meantime, we've reached out again to our IOG research hoping that they will be joining the conversation so that we can move forward that whole conversation with them. Then we briefly touched on CIP 58 that we want to bring to review for the next biweekly meeting. It's also a subject to primitive for Bitwise manipulation and a bit more of binary manipulations on Plutus, and I think a few other minor things like broken links and yeah, small additions. That's about it, unless I forgot something.\n\n**M. Àngels** -:  I think it's everything.\n\n**Matthias** - :  Mm-hmm.\n\n**M. Àngels** -:  Thank you very much to all the attendance. Next meeting is going to be held in two weeks, July 19 at half past eight AM UTC. Here in this court, you have the events, this is the next event. And today I am going to upload the following one so you can plan in advance. Thank you very much and see you in the next meeting. Bye-bye.\n\n**Matthias** - :  Thank you.\n\n**Sebastien** -:  Bye guys.\n\n---\n## Extra\n\n### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md)\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n© 2022 GitHub, Inc.\nTerms\nPrivacy\nSecurity\nStatus\nDocs\nContact GitHub\nPricing\nAPI\nTraining\nBlog\nAbout\n\n"
  },
  {
    "path": "BiweeklyMeetings/2022-07-19.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [July 19 2022 Transcript](#july-19-2022-transcript)\n  * [Triage](#triage)\n    + [CIP-0058? | Bitwise primitives](#pr283)\n    + [CIP-0003? | Broken links on the website](#pr109)\n    + [CIP-0030? | deprecate signTx & add chain signing](#pr206)\n    + [CIP-0030? | Adding optional networkId parameter to .enable](#pr209)\n  * [Last Check](#last-check)\n    + [CIP-0054? | Cardano Smart NFTs](#pr263)     \n  * [Review](#review)\n    + [CIP-0044? | Additional factors for NFT market verification](#pr226)\n    + [CIP-0050? | Shelleys Voltaire decentralization update weekly update](#pr242)     \n  * [Discussions](#discussions)\n  * [Issues](#issues)\n  * [Close](#close)\n\n## Summary\n\nRough transcript of 19/07/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Transcript might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significance to you.  \n\n\n## Editors Meeting Flow\n\n**Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n\n**Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n\n**New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \n\nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n**Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n\n**Issues**: Review of the open Issues on the CIP GitHub \n\n**Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  \n\n\n## July 19 2022 Transcript\n**Attending Editors**:  ~Matthias Benkort~, Sebastien Guillemot, Frederic Johnson, Robert Phair. \n**Guests**: Kevin Hammond\n\n### Triage\n\n#### PR283\n[PR283 CIP-0058? | Bitwise primitives](https://github.com/cardano-foundation/CIPs/pull/283)\n\n**M. Àngels** -: Thank you, Fred. So we will start with the triage. The first item on the triage is Bitwise Primitives. So this is PR 283. So any of the editors want to give a brief explanation regarding this PR and the status?\n\n**Sebastien** -: So although not an editor, Michael Peyton Jones is the main one who was kind of fitting this. And I don't think he is on this call. He's usually in these meetings. We may have to skip this one, here.\n\n**M. Àngels** -: So shall we wait until Michael joins the meeting? So he will give an overview of the PR?\n\n**Sebastien** -: Yeah. Ideally that, or somebody from mLab, the [inaudible 00:08:34] lab is here that wants to talk about this. Even though Michael Peyton Jones isn't here, who's the main person who not only is reading it, but the [inaudible 00:08:46]. That's something we can do.\n\n#### PR109\n[PR109 CIP-0003: Broken links on the website](https://github.com/cardano-foundation/CIPs/pull/109)\n\n**M. Àngels** -: Okay. Sorry, if you hear a baby, it's my sister's, which is around. So, next item on the agenda is broken links on the website, which is PR 109. So this is under issues. We have the pull request, but organically by the community, we starting to receive open issues. So I can make a brief summary of what I know. So there is CIP number one.\n\n**Sebastien** -: Do we need to go over this pair, I think? Because there's a lot of people here who are not editors. So I think probably it's not worth their time.\n\n**Frederic** -: And that one is closed, right? So we good.\n\n**M. Àngels** -: Can you repeat, Fred, please? Fred, were you saying something?\n\n**Frederic** -: I was saying there is been closed. For those who know where, there's an autogen site that is started on the site that lets you access directly the body of the PRs, the equivalent of GitHub. So it's on... seems that Cardano Foundation. It's resolved. I mean to say, we can move to the next item on the agenda.\n\n**M. Àngels** -: I think that I am still having issues accessing one of the items over here. So I'm still facing a broken link. But maybe we can take this offline. \n\n#### PR206\n[PR206 CIP-0030? | deprecate signTx & add chain signing](https://github.com/cardano-foundation/CIPs/pull/206)\n\n**M. Àngels** -: We can take this offline and we can go to the next item on the agenda, which is CIP 30, duplicate sign transaction and add chain signing.\n\n**Sebastien** -: I can talk about this one. So this is basically the fact that right now, whenever you want to chain transactions together, using CIP 30 is kind of awkward. The reason why is because wallets need to show the confirmation prompt that tells them what kind of transaction they're confirming and needs to know what keys to sign with for the inputs. If the input for a transaction isn't on chain yet, there's no way for the wallet to easily know this information. And this leads to problems, because users may want to submit mobile transactions on their favorite decks, but get an error saying, error, you're trying to use... So you tick so that isn't created yet, which is not a great user experience. So to solve this issue, we can allow that to kind of inject knowledge about pending transactions into the wallet.\n\n**Sebastien** -: And this is the only real way to do it, because even if the wallet has man pool support, this is not a perfect solution, because it's all the issues where the chain transactions that were all submitted to the wallet. But that's not always the case. The only kind of generic solution to this is for the DApp itself to give hints about pending transaction state so that the wallet can use this to send a transaction, and assume a specific case will be accepted. So to implement this feature, we basically modify CIP 30 to add this kind of information to the signed transaction function. At the same time, we also modify the format of the endpoint to basically make it easier to modify this in the future. Questions?\n\n**Frederic** -: So one of the question I had regarding that entire process is, is Rob on board with it? So Rob is the original author from CIP 30 and the modification of Bayou.\n\n**Sebastien** -: Yeah.\n\n**Frederic** -: Okay.\n\n**Sebastien** -: And you can see in the discussion on the CIP, there's also Marcel from Farrell that's talked on this issue as well. The problem with the CIP is, as all other modifications to the CIP, there's no governance for CIP 30 that is explicit. So it's unclear when, if, how many changes to CIP 30 should be merged. So this PR, along with the next one we're talking after this, it's just stuck in this limbo. So to avoid getting things stuck in limbo, I just want to spend some time coming up with a way to change the CIP 30 structure to make it easier to have alternatives for various endpoints. And this is also something that the catalyst team was interested in, because they also want to use the same kind of flexibility to potentially introduce a governance API into CIP 30. So it may be that you want to merge this regardless, or we may want to keep this CIP on hold until we get this extended enabled functionality that, because the team also wants to be implemented, that will help their life and also help push this proposal through.\n\n**Frederic** -: I feel that merging will be the easiest path forward, but I agree that if this goes down that path and it can just become a bigger mess later, and it might warrant a separate conversation. By the way, for anybody interested in participating, there's a CIP chat room. I can see that Andrew's in the room right there. I don't know how to proceed regarding this one. Rob, how do you feel?\n\n**M. Àngels** -: Rob? I don't know if you are talking, but at least me, I am not able to listening to you.\n\n**Sebastien** -: He's just-\n\n**Frederic** -: I am hearing Rob.\n\n**M. Àngels** -: Okay.\n\n**Frederic** -: Maria's just restarting the stream. She'll be right back.\n\n**M. Àngels** -: You can refresh the page. Now I can hear you too, Rob.\n\n**Robert** -: Okay. Both of the options that Sebastian said sound good to me. I think it would be great to have some kind of governance process for this, because there are so many contributions. I think it would be great to include Rob on the governance question itself and then maybe go ahead with this or maybe wait, I don't have any particular opinion about it. [Now I've lost everybody.]\n\n**Sebastien** -: We'll see if the Catalyst team is interested in pushing for their potential change to sit through for the [inaudible 00:17:03] function. This is something that was discussed, but not something that they've decided on. It's an open question. But if you decide to spend time on that, we may as well move in that direction if revisiting this issue in a month, two months' time [inaudible 00:17:19] before we can decide to just merge and move on.\n\n**M. Àngels** -: Shall we ping anyone in the comments? Because you were talking about a person that I thought it was Rob, but then I understood it was another person that is involved in this PR.\n\n**Robert** -: It's Rob with the nine Os in the middle. R O O O O B.\n\n**Sebastien** -: Yeah. Rob, Rob Aptius. He's a business [inaudible 00:18:02].\n\n**M. Àngels** -: So, should I ping him?\n\n**Frederic** -: The other, more involved option... Yes, please. Ping him in the comments is going to be good. The other option will be to maybe fork the PR and just make it clear that it has a governance component where people can add and modify it, even though they're not the main author. Otherwise, if we get the access like in [inaudible 00:18:23]-\n\n**Sebastien** -: Yeah. So that's where Matthias is wanting to work on. He's talked about potentially writing this.\n\n**Frederic** -: Okay.\n\n**M. Àngels** -: So what do you want to do? How do you want to follow with this one?\n\n**Sebastien** -: I would just put this on pause because there's not really a rush to merch it, and then see it in one to two months' time what's happening with the Catalyst folks. And if they help us come up with a new registration standard for a CIP 30, that would solve this issue.\n\n**M. Àngels** -:You are okay. You are right. Because I needed to... Thank you very much for that. Okay. Now should be able to, right? So perfect, we are going to put this on hold and we are going to ping Rob. Any of you want to do it? If not, I can do it myself, but I need to know what exactly do you want from Rob?\n\n**Sebastien** -: I don't think you need to ping him. I don't think it'll prove anything for it.\n\n**Frederic** -: Thank you. We can just add a comment, Maria. Feel free to take it on. Just that this is on pause until we have [inaudible 00:20:06] back for CIP 30 and how to add public single contributors.\n\n**M. Àngels** -: This is on hold until... Can you repeat, Fred, something about CIP 30, right? That we're waiting?\n\n**Frederic** -: Until some kind of governance path can be discussed further regarding updating the CIP without being the lead author.\n\n**M. Àngels** -: Makes sense, I guess.\n\n**Robert** -: Do we also want to add something that the question is being pursued in a Catalyst proposal? Did I get that right?\n\n**Sebastien** -: No. No. It's just the Catalyst team is working on a feature that where they may also benefit from the same solution that this CIP would benefit from-\n\n**Robert** -: I got it now. Okay. Thanks [inaudible]. Nevermind then.\n\n**M. Àngels** -: Shall we [inaudible 00:21:10]? Or it's not necessary?\n\n**Sebastien** -: No, you can leave it out.\n\n#### PR209\n[PR209 CCIP-0030? | Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209)\n\n**M. Àngels** -: Okay, perfect. Good. Then we can move to the next item on the agenda, which is also CIP 30, adding optional network ID parameter to enable.\n\n**Sebastien** -: And this one is stuck for the same reason.\n\n### Last Check\n\n#### PR263\n[PR263 CIP-0054? | Cardano Smart NFTs](https://github.com/cardano-foundation/CIPs/pull/263)\n\n**M. Àngels** -: Okay. Let's leave the same comment. So then we have in last sec, CIP 54, Cardano smart NFTs.\n\n**Sebastien** -: So this one was waiting for feedback from NFT marketplaces if I remember correctly, right? Or was it a separate one?\n\n**M. Àngels** -: I think it's a separate one, because there are one that includes a marketplace with its NFT market verification. And this one was added to the developers digest newsletter, but this wasn't requested a specific input from marketplaces. If you need it, we can do it. But for a conversation I had with Matthias, only the other one required a specific input from NFT marketplaces.\n\n**Sebastien** -: So what was the blocker?\n\n**M. Àngels** -: Can you repeat?\n\n**Sebastien** -: So the blocker for the CIP... Was this blocked for the same reason as the fungible token standard, which is the security concerns, but leveraging the mint transactions again? I think in general, probably the CIP will want to reflect the upcoming changes to Vasil, which gives them a better solution to the problem they're trying to solve. So their approach may be somewhat deprecated by this. And in fact, there's two CIPs that were introduced in this, we created the agenda, 66 and 68, that kind of tackle the same problem, I believe, but using Vasil features.\n\n**M. Àngels** -: From the notes that I have from previous meeting, I think that the author was about to do an implementation. And, if implemented, we are going to move it to lab dev. I don't have more information if this has happened.\n\n**Sebastien** -: That's fine. I don't remember a reason in particular to avoid merging, other than the concerns that were raised by the approach and the fact that we may want to revisit this in the context of the newly introduced Vasil hard fork changes.\n\n**M. Àngels** -: So you suggest that we wait on the Vasil?\n\n**Sebastien** -: No, no. I'm just saying that they may want to add a section about this or consider their API, given these new features, or maybe they don't care. I don't know, but as far as I'm concerned, as long as they have an implementation, I don't mind merging it. I don't think there's anything technically wrong by the proposal.\n\n**M. Àngels** -: [inaudible 00:26:08] test approved the PR right now. So we would be missing one approval.\n\n**Frederic** -: Yeah. There's conflicts to resolve.\n\n**Robert** -: Hold on a sec. Okay.\n\n**Frederic** -: It's a matter of speaking the numbering. So I think 54th will be fine.\n\n**M. Àngels** -: Now we have... oh? No. So Fred, are you trying to solve these conflicts, or shall we wait and do it offline?\n\n**Frederic** -: Do it offline. Do it after this.\n\n**M. Àngels** -: Good. So once the conflicts are resolved, shall we merge it offline? Or shall we leave it to merge online in the next meeting?\n\n**Frederic** -: I think it's going to be fine to merge after this meeting once it's there. I'm just looking at it, and it's just the tentative proposals that are in the work. And it's just a matter of moving it to Robert, Sebastien. We've been doing the last ones. If you want to do this one, otherwise it should be fine [inaudible 00:28:14]-\n\n**Robert** -: I'll have a look after the meeting goes. I'm looking at it right now, but we'll finish it up after the meeting.\n\n### Review\n\n#### PR226\n[PR226 CIP-0044? | Additional factors for NFT market verification](https://github.com/cardano-foundation/CIPs/pull/226)\n\n**M. Àngels** -: Okay, perfect. So this is going to be merged offline. And then under review, we have two items. The first one is additional factors for NFT market verification. This is the one that we send communication to some of the NFT marketplaces to give us feedback. So I don't know if any one of you would like to make a summary for our audience today on regards of this PR? I thought it was me that I wasn't listening to anyone, but I think that... Is it me?\n\n**Sebastien** -: No, I think it's just that not be as [inaudible 00:29:29].\n\n**M. Àngels** -: Okay. So, let's go to the comments. No feedback since my last comment. Now I do. Sorry. As nobody was speaking, I thought that I had audio issues, and I reset it. Perfect. So these are the marketplace that were approached, but I am not aware that they have provided feedback either in this court or not in the PR. I mean, in the PR there are no more comments. So I don't know if you want to wait it works more. Maybe we can try to contact the marketplaces again. So if you agree, what I think we could do is to try to reach them again. So maybe now, yes, maybe to take this back after Vasil. \n\n#### PR242\n[PR242 CCIP-0050? | Shelleys Voltaire decentralization update weekly update](https://github.com/cardano-foundation/CIPs/pull/242)\n\n**M. Àngels** -: So next item of the agenda is PR 242. This is the PR around [inaudible 00:31:13] decentralization. We have a specific channel here to discuss this PR. I don't know if any of you want to give a brief summary on the status of this?\n\n**Sebastien** -: I think this one is still pending some sort of response from IOG, right?\n\n**M. Àngels** -: Yes. I think there's Kevin here. I don't know. Maybe if he wants to-\n\n**Robert** -: Just that the author has accepted the possibility that maybe there won't be a response from IOG, and is prepared to go ahead with this in one way or another, is one of the things that came out in the discussion in the Discord, the other channel.\n\n**Sebastien** -: Yeah. I mean, if there's no response from IOG, there's no reason not to merge this, right? Just because it's merged. The [inaudible 00:32:50] Cardano has implemented. From that perspective, if they feel the discussion is fine, and if they've given up hope on receiving a response from IOG, then I think we should just merge this.\n\n**Frederic** -: I would be fine with that.\n\n**Frederic** -: [Inaudible 00:33:18] same here. Just want to bring your attention to the chat. [inaudible 00:33:22] is currently here for CIP 50 and can't call in, but he's currently typing some comments.\n\n**M. Àngels** -: So I'm going to bring Kevin on stage. So maybe he can give us an update from IOG. Hi, Kevin.\n\n**Kevin** -: Hi, everyone. Nice to speak to you. Hopefully you're hearing me okay.\n\n**M. Àngels** -: Yes. Perfect.\n\n**Kevin** -: Excellent. That's great. So the story of the CIP 50 is, we've looked at this, we've evaluated internally. We think it's an interesting suggestion. We're keen to progress this a bit further. We obviously have a few other things on our plates at the moment, but we think it's a great opportunity to engage with the community and to discuss these ideas. So I won't make any commitment on IOG's behalf at this point in time, but I would make positive noises to the author. I would definitely make positive noises to the author. And as Sebastien knows, we're hoping that once we've got an opportunity, probably after Vasil, we can then start to progress discussion on this and similar issues. We think it's a great way to engage with the community. I think there's some good ideas coming out this and other-\n\n**M. Àngels** -:\n h, perfect. Thank you very much, Kevin. [inaudible 00:35:08]-\n\n**Kevin** -: And if I could just add, I suspect people think that IOG is ignoring all the great work you're doing. That's absolutely not the case. We have people who are monitoring the steps, going through them, looking at the ideas. And as I was saying, we obviously just don't have the capacity to progress them all at the moment, but we are taking stock of them and we will see what we can do as we move forward to the new frameworks that are being set up. Alternatives, et cetera.\n\n**M. Àngels** -: Thank you very much, Kevin. That is very, very nice to hear.\n\n**Robert** -: Kevin while you're on, do you see the last question that came into the chat?\n\n**Kevin** -: No, I'm not sure I've got the chat.\n\n**Robert** -: There's a little button in the upper right hand corner. In case you can't get it, there's just a question about the-\n\n**Kevin** -: Oh yeah, I got it.\n \n**Robert** -: Do you see it?\n\n**Kevin** -: Okay. Right. So the question is from Steuf, is that right?\n\n**Robert** -: Yes.\n\n**Kevin** -: Will I be able to access game theory? We can ask the researchers that. We have common analysis that was done internally. I think most of the game theory results are published, but I don't know whether the raw data is published. Tell us exactly what you would like. When we start to engage with you, we can certainly see what we have available. And I don't think there's any issue with sharing any of that information with the community, so this information that IOG has produced. But don't quote me on that. So to reemphasize what I said earlier, there's real willingness and enthusiasm for engaging with the community to the ecosystem and core going forward.\n\n**M. Àngels** -: Good. So next meeting, which is in two weeks, from the CF, we would like to have [inaudible 00:37:56] Ramazon to join. He is a blockchain researcher, and he will also give us his input on this CIP. Anyone else has anything to add on this PR?\n\n**Robert** -: All okay, here.\n\n**M. Àngels** -: So this is everything that we had included in the agenda. So we have left 25 minutes. I don't know if you want to review any specific PR. Rob, you mentioned one that you wanted to review. Maybe we can go to it.\n\n**Robert** -: Do you mean me?\n\n**M. Àngels** -: Yeah. I think that you shared one PR to bring into the agenda that was not urgent, but as we have time left, maybe we can review that one. Just let me go through it.\n\n**Robert** -: That was an issue rather than a PR, and we dealt with it already at the beginning. It was issue 109. We have contending discussion rather than try to fix the problems as they come up in the existing system, to try to come up with an alternative framework that's going to be a little bit easier to manage. For people that weren't following issue 109, this is the website generator that generates cips.cardano.org from the GitHub's CIP repository. And it's a bit clunky, consisting of a bunch of scripts. And Matthias had some suggestions in issue 109 about maybe using Hugo, with Docusource being a little bit too heavy. But without Matthias being here at the meeting, I don't think it makes sense to include it in today's discussion. And it's also not an urgent tissue.\n\n**M. Àngels** -: Perfect.\n\n**Sebastien** -: There's a few CIPs that haven't been reviewed yet, but are ready to be reviewed, notably 62, 66, 68. I think 62 might be a bit early for that one, because there's still a lot of things in the air, but we can introduce it for anybody interested. So this is basically, Catalyst is moving towards a system called DREPS, where basically, people can delegate their Catalyst voting power to other people. And to be able to do this in centralized way, we need to enable basically anybody to sign up to be DREPS. And we also need wallets in DApps to be able to create transactions that delegate your voting power to these DREPS for other people. This CIP defines the changes to CIP 30, which is why I mentioned previously of the Catalyst team may be interested in changing the enable function for CIP 30 in general, to make it easier for making changes to CIP 30, because they also [inaudible 00:41:26] changes to CIP 30. So, that's just that background. There's still some ongoing discussions about the right format API for this CIP, but just FYI that it's out there [inaudible 00:41:47]. No other comment or questions, we can move on to maybe 68?\n\n**Kevin** -: Sorry. Could I just say, Sebastien, CIP 62, the precursor to 62, there's already been some discussion with wallet [inaudible 00:42:16]. What we're doing first is to try to open our discussion to the community. One of the procedural questions is, what's the best [inaudible 00:42:32] to extensions to-\n\n**Frederic** -: Kevin, your audio's cutting in and out somehow. Anybody else having issues?\n\n**Kevin** -: It's Discord. Let me try again. So what I was saying is, there's been some discussion with some wallet providers on CIP 62, the proposed adapt connector. What we're doing here is to open up the discussion to the broader community and to ask for general feedback. One of the procedural points that's come up is what's the best way to provide extensions to CIP 30. So what we don't want to do is to completely replace it. What we want is a mechanism that says, you've got CIP 30, here's an extension. And in this case it's for voting, but it might be that we need extensions to CIP 30 for other purposes, too. So we want to waive, to be able to say, oh, you have access to CIP 30, but not CIP 62. You have access to CIP 30 and some new CIP, and so on. So that there's a way to basically select sensibly between different extensions to the base DApp connector. That's the question, I think, for people on this call.\n\n**M. Àngels** -: So maybe Kevin, if you want to make the question again, so the editors can answer you, if they know it?\n\n**Kevin** -: Yeah. So it's not a question we need answered immediately. We are happy just to raise it with you and for you to think about it. But one of the core questions is, when we provide extended capability to CIP 30, what is the mechanism that we should be using to enable that? So should we be providing some completely self-contained CIP? Should we be saying, oh, this CIP requires CIP 30. What if you've got two incompatible CIPs, both building on CIP 30? So it's starting to raise questions about how do you extend existing capabilities, and how do you enable interoperability? Happy to raise these questions on the PR itself, of course, just to make sure you're aware of them.\n\n**M. Àngels** -: But the... Go ahead, Rob.\n\n**Robert** -: Oh. Well, an issue came up like this with CIP 13, which is for a URI scheme. And it seemed for two or three months that there were going to be other people presenting different syntaxes into the URI scheme, and that if there was the possibility of getting more than one or two of those, it would make sense for each of those to be presented as its own CIP. So that turned out not to be necessary, but we were prepared to have the individual authors for each of those extensions to the URI scheme, submit their own CRP explaining it in detail, so it wouldn't have to be coordinated or accountability or advocacy for this CIP wouldn't have to be shared with the original authors of CIP 13. So I think that this is one of those cases that would do well with that approach, as well.\n\n**Kevin** -: Yes, we're absolutely happy with that. This is more of a technical question about enabling the extension. So, how do you enable the extension consistently in the API? So there needs to be some discussion about that. Sebastien can probably comment on this, but you can imagine having, say, CIP 62 and CIP 63, which both provide extensions to CIP 30, but which are mutually incompatible. And then you need to have some way to say, I can support CIP 62, but not CIP 63, or I can support CIP 30. There actually has to be a way for the user to select between the different capabilities in a consistent way. Let me make sure that question gets raised properly as a comment on CIP.\n\n**M. Àngels** -: That would be fantastic. Thank you very much, Kevin. So shall we move to CIP 68? I think you mentioned, Sebastien, that this was one that was worthwhile mentioning.\n\n**Sebastien** -: Yeah. So basically with the introduction of Vasil, it's possible to mimic global estate for a smart contract, but basically having some UTX entry that holds some special NFT be denoted as the UTX entry that contains the global estate of the contract. This CIP, CIP 68, is basically a standardization for this exact feature, with some emphasis on NFTs, but also not just for NFT.\n\n**Sebastien** -: The interesting about their proposal is that they want to have a single minting policy that handles everything. So instead of having one minting policy for the global estate NFT, one minting policy for the actual NFT series, if this is an NFT mint, and then one NFT for other standards, or sorry, one script for other standards, they all want to have all of this handled by a single script, all in one script. And they document how they would do this with all in one script, by basically stuffing information into the asset name, which as you may remember, asset name on Cardano is just the arbitrary binary strain. So they can [inaudible 00:49:12], they want it there as sort of standard. That's basically the idea of the CIP. The downside of doing this is one, of course, you need to have one master minting script. It maybe kind of awkward to deal with, especially if new standards come out in the future, you can't support these new standards with your existing antique projects.\n\n**Sebastien** -: And the other thing that's awkward about this is the cost of the approach. The approach line described in the CIP is also extremely large. And then last thing [inaudible 00:49:55] Fred mentioned is that also this reduces these amount of space you have for asset deeds, because it adds a pretty big [inaudible 00:50:05]. These are the three core issues with the CIP, but I don't see any technical issues with the CIP as it's described. Obviously there's some practical issues that may mean that people may not want to take this approach. And actually, if you're interested in a separate way to tackle basically the exact same problem, you can look at CIP 56, which is by end maker, which is a proposal for DIDs on Cardano. But actually the approaches for DIDs is another alternative structure that's kind of like, I wouldn't say a competitor, but an alternative to CIP 68 that we're looking at right now.\n\n**M. Àngels** -: Any comments on this one? Shall we bring any of these two last PRs to the next meeting agenda?\n\n**Sebastien** -: Yeah.\n\n**Robert** -: Yeah. I think that sounds great. These are things that I'd like to hear from Matthais about. The last couple of them are technically, I can't really contribute anything about them. I'm sure that he could, though.\n\n**M. Àngels** -: Perfect. We have 12 minutes left. Do you want to review another one, or do you want to go directly to a wrap up and close the session?\n\n**Robert** -: I'm okay with wrapping up.\n\n**M. Àngels** -: Perfect. Any one of you want to do the closing? If not, I have notes on the PR and I can do it myself.\n\n**Frederic** -: One check on for request 263, the conflicts have been resolved. Sebastien, if you want to add your take on this one and nudge it, I think we're good to move it forward at CIP 54.\n\n**M. Àngels** -: Nice.\n\n**Frederic** -: Good to close, otherwise.\n\n**M. Àngels** -: So if you like to merge it online, that would be great.\n\n**Frederic** -: Sebastien, do you want to do it?\n\n**Robert** -: Oops. I-\n\n**Sebastien** -: Yeah, if they're not interested in making changes of their functionality based off the Vasil hard work, then I don't see any problem merging it. Worst case, they can just come in and modify their while we merge the IP later.\n\n### Discussions\nN/A\n\n### Issues\nN/A\n\n### Close \n\n**M. Àngels** -: Okay, perfect. So let's do a wrap-up of the session today. We have briefly mentioned CIP 58, Biblase Primitives, but we have decided to wait until we have Michael Paton in the call. We did the review of broken links on the website that we are going to leave this discussion offline. We have reviewed two PRs related to CIP 30, duplicate signed transaction and chain signing, and adding optional network ID parameter to enable. Both of them are on hold, because we are waiting on a governance process on CIP 30. Then we have PR 263, Cardano smart NFTs. It is the one that we have merged now online. This has been approved and merged during the meeting. We have CIP 50. We had Kevin on stage, and he has mentioned that the IOG is really willing us to engage with this PR and this is probably to be done after Vasil hard fork. And if they have not engaged it yet, it is for a lack of capacity. I would like to thank Kevin for his intervention today, it's very much appreciated. Then we have reviewed CIP 44, additional factors, NFT market verification. This one, what we are going to do is to think again the marketplaces and try to get their feedback. And then we have reviewed CIP 62, governance API for that connectors dot wallet web bridge. And Sebastien has walked us through this PR. And Kevin has raised a question regarding how to extend the capability of CIP 30. And this question is going to be added to the PR itself, and the editors are going to review and go back to Kevin with an answer. And finally, we have reviewed CIP 68, data metadata standard, where Sebastien has walked us through the PR, and we are going to keep this CIP 68 and 62 for review in the next meeting. Thank you very much all for attending. A special thanks to Kevin, that has shared his view on state. And well, next meeting is going to be held on August 2 at half past 8:00 AM, UTC. I'll be on holidays, so my colleague Anthony Mayer, will take over. And I wish you all a very great summer, and see you after the summer. Bye-bye.\n\n**Frederic** -: Bye-bye.\n\n**Robert** -: You too. Bye-bye.\n\n\n## Extra\n\n### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md)\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n© 2022 GitHub, Inc.\nTerms\nPrivacy\nSecurity\nStatus\nDocs\nContact GitHub\nPricing\nAPI\nTraining\nBlog\nAbout\n\n"
  },
  {
    "path": "BiweeklyMeetings/2022-08-02.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [August 02 2022 Transcript](#august-02-2022-transcript)\n  * [Triage](#triage)\n    + [CIP-0027? | Fix status header](#pr214)\n    + [CIP-0030? | Added walletExperimentalApiVersion](#pr225)\n    + [CIP-0045? | Decentralization: Using Pledge as a Bidding Param](#pr229)\n  * [Last Check](#last-check)\n  * [Review](#review)\n    + [CIP-0050? | Shelleys Voltaire decentralization update](#pr242)\n    + [CIP-0062? | Governance API for dApp Connectors (dApps<->Wallet Web-bridge)](#pr296)     \n    + [CIP-0068? | Datum Metadata Standard](#pr299)\n  * [Discussions](#discussions)\n  * [Issues](#issues)\n  * [Close](#close)\n\n## Summary\n\nRough transcript of 02/08/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Transcript might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significance to you.  \n\n\n## Editors Meeting Flow\n\n**Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n\n**Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n\n**New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \n\nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n**Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n\n**Issues**: Review of the open Issues on the CIP GitHub \n\n**Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  \n\n\n## August 02 2022 Transcript\n**Attending Editors**: Matthias Benkort, Sebastien Guillemot, ~Frederic Johnson~, ~Robert Phair~. \n**Guests**: ~Morgan Thomas~, Michael Liesenfelt\n\n### Triage\n\n#### PR214\n[PR214 CIP-0027? | Fix status header](https://github.com/cardano-foundation/CIPs/pull/214)\n\n**Matthias** -: Yes. So we're looking into that one. It's a pretty old one, I think. Yeah, ninth, February. It was just changing the status of a CIP number 27, which I think is... And debated here, not the CIP, but the fact that this is an active CIP nowadays, there have been people disagreeing with that standard and coming up with new standards, which is also fine. But as far as we are concerned, it's indeed active. So there is no problem with the change for me. Robert has approved. The only thing is we will also need to update the top-level README, with that to reflect it. So we can do this as part of a recent PR updating the README and yeah, just get to move on with this particular one, unless you, I don't know, have something to say Sebastien. But-\n\n**Sebastien** -: No.\n\n#### PR225\n[PR225 CIP-0030? | Added walletExperimentalApiVersion](https://github.com/cardano-foundation/CIPs/pull/225)\n\n**Matthias** -: Nope. So let's go. I'm just merging that and I will do the README update in the other PR, which is PR  #311, just for the record. And okay, next one, also a quite old one. CIP 30 Wallet experimental API version.\n\n**Anthony**-: Okay. Apologies. Sorry. I'm behind you. All right. Excellent. Let me just launch this one up here.\n\n**Matthias** -: Let me also watch the stream. Yeah. Well I guess that's one of those lingering CIPs for which we have no news from the author, probably came from a discussion. They made a change to the CIP 30, I think Sebastian response is...\n\n**Sebastien** -: Yeah. Because the problem with this one is that the way they're doing it is different from the way Eternl did this.\n\n**Matthias** -: Yeah.\n\n**Sebastien** -: So somebody needs to decide how they want to resolve this mismatch.\n\n**Matthias** -: So do you think we should pull Marcel in the discussion or-\n\n**Sebastien** -: Yeah. We can try and ping them or sell it to them and see if they want to resolve this or if they want to drop the CIP. They need to figure this out.\n\n**Matthias** -: Yeah. I mean, since there has been no activity for four months on that one, I would assume it's probably being dropped. So I would just ping, Ruslan and maybe Marcel to see if they have anything to comment.\n\n**Matthias** -: Okay. And I will just mark it as waiting for author.\n\n**Anthony**-: Amazing. Excellent. So is everybody happy to move on to CIP 45?\n\n**Matthias** -: Yes. Yes. Now just make sure we keep this CIP 30 update for last check, maybe next meeting. And if no activity has happened, then we'll just I think close it.\n\n**Anthony**-:Okay. Excellent. I'll do so. Great. Thank you, Matthias.\n\n#### PR229\n[PR229 CIP-0045? | Decentralization: Using Pledge as a Bidding Param](https://github.com/cardano-foundation/CIPs/pull/229)\n\n**Matthias** -:So CIP 45. Yeah. So I had a quick look at this one this morning and also at the forums messages. So this is yet another CIP to address incentives, rewards, and things that are in that realm, specifically focused on the pledge, Stake Pool pledge that one. So it sounded a lot similar to a CIP that was discussed in the past, which was the dynamic saturation based on pledge. So the idea of CIP 45 is to make the pledge for pools also dynamic in a way, and depends on the actual number of ADA being stable, the circulating supply, and that way make sure that both the pledge and the saturation levels kind of reflects the actual state of the network. So I haven't been through all the equations just yet, only been through the comments on the forum.\n\n**Matthias** -: So yeah, I think it's a good one to put under review as well. And I would be interested to see a discussion comparing that with CIP 37, and how they do defers on that. I'm pretty sure both authors know or that the two proposals exist, if they don't and it's a good thing we put them together maybe for a chat as well.\n\n**Anthony**-:Okay, excellent.So... Apologies. So from my perspective, this is something that's going to be placed under review.\n\n**Matthias** -: Yeah. I've been also quite late to address that one in a way, because I see it's been published on the 1st of March, so it's been sitting there for quite a bit, might be a bit of effort to resurrect the conversation, but I would definitely yes, love to spend some more time to go through this one point by point, maybe have a kind of comparisons of that with CIP 37. I'm not sure if you had time to go through it, Sebastien, if you have any remarks as well on this one.\n\n**Sebastien** -: No, I don't actually. And do you know why this one was missed for so long? Did we talk about this? And then there was a reason why we lost over it.\n\n**Matthias** -: And I think it just got lost in translation, slipped through the cracks. So I don't know. That's the kind of CIP we also wants to get IOG attentions about, and we know it's been a difficult task. We could probably also pass it through Reza at the CF, who is also now getting to more and more into looking into these things, just at least to get some research feedback on this. And I will also ping Kevin Hammond about that, who is now our point of contact with IOG and our best chance to get something through IOG research.\n\n**Matthias** -: I'm not sure if Michael also, who is here today, you have seen that there is some overlap with CIP 50, as far as I can tell. Both could be complimentary solutions. Not sure if you have seen, or if you had time to also read through that?\n\n**Michael**-: I need to refresh myself on it, but I did. I might have even cited it in my references of CIP 50.\n\n**Matthias** -: Okay. So nothing really substantial, but you are aware that this exists as well. Well, at least now you are.\n\n**Matthias** -: Okay. So yes, let me try to ping also people on that.\n\n**Matthias** -: So the next call would be on the 16th of August, right?\n\n**Anthony**-: Yes.\n\n**Matthias** -: Yes.\n\n**Anthony**-: That's correct.\n\n**Matthias** -: So I'm just commenting that we'll like to do a more of an in-depth review for the next biweekly call, August 16. That it'll be good to have a comparison with CIP 37.\n\n**Matthias** -: Can I ping the right people or what? Yes.\n\n**Matthias** -: Okay.\n\n**Anthony**-: Okay. Fantastic.\n\n**Matthias** -: Okay. So that's it for this one. Let's have it for review next week.\n\n**Anthony**-: Okay.\n\n### Last Check\nN/A\n\n### Review \n\n#### PR242\n[PR242 CIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242)\n\n**Matthias** -: Sorry. In two weeks, in the next call and maybe let's start with CIP 50 now, since we have Michael and Christophe with us. So I did put a small update from what I got from the Discord chat, or there was few thread discussions, but from what I could get is there was this idea that if we end up doing a model or actual simulations of that particular model, it would be nice to use some kind of either genetic algorithms or neural network to try to model a bit more complex behaviors of the different actors, all players, in that sense in the whole simulation. There was also in the meantime, a response shared by IOG research and was specifically Aggelos and Christina, with some well comments on CIP 7 and CIP 50 in particular. I think there are some comments on these two. And I think Michael, you suggested to maybe do a point by point kind of response to address various claims that have been made and try to point to either the inconsistency or disagreement in particular with the interpretation of the CIP 50 proposal.\n\n**Michael**-: Next action item, maybe to open source what they actually have.\n\n**Matthias** -: Yeah. So we could perhaps ask for maybe not a deadline, but at least an estimate or something along those lines. When could we expect to have this particular simulation engine, because yes, that response is mentioning a new simulation engine that they have been using to compare these solutions to the existing protocol, which is planned to be made public, but still hasn't so far. So it would be good to get some... How would you say? Some view on that, just to know when we could expect this to be available to play also. So that's a good point.\n\n**Michael**-: Clear that their new simulation engine is deviating from the original RSS publication paper simulation engine. The figures of merit have changed. Some of the methodologies have changed. They're updating and they're learning from CIP 50, which is good.\n\n**Matthias** -: Okay. So some positive notes still.\n\n**Michael**-: Yeah. On CIP 50, we are formulating a section on a recommended ranking equation. Marcel has shared what Eternl uses, we've considered a couple of others and it's not a binding part of the specification, but rather an advisory recommended section, but we figure it's important to include. Also in development is potentially another three equations that could be tried as part of the equation competition, so to say, with variable leverage. And so instead of a fixed constant leverage to have egalitarian and bias forms of the equation that have a reducing leverage as increasing as pledge increases, we're still considering adding those as well.\n\n**Michael**-: So the more pledge you have, the less it gets you in terms of total stake size that could help address the idea of pool moguls or a pool emperor emerging. But one won't know that until simulation is actually being applied. And then of course, there's vigorous discussion on many aspects of CIP 50 in the discussion channel. And we're updating all of the figures and charts to reflect a reality that after the saturation point, there is not truly a diminishing return because individuals can split pools and continue the returns.\n\n**Matthias** -: Okay, which actually would affect a bit some of the strategy. I think this was something that was a bit mentioned before, that with the CIP 50, there is an actual optimal point of pledge beyond which you want to actually split your pool to maximize your returns.\n\n**Michael**-: Well, there would be a limit. So the design would be to be the \"optimal\" is as much as you have up to the limit and then as much further pledge as you want to contribute to make your pool more relatively attractive and lower leverage, that would be the concept.\n\n**Matthias** -: Okay. And so that limit would be below the saturation limit and like now, right?\n\n**Michael**-: Yes. It would always be a fraction of the saturation limit proportional to the leverage limit, but the scheme doesn't limit from putting more pledge than what would be required to maintain a saturated pool and the factor there isn't technical, but mainly social around pool ranking and perception of pool leverage in a ranking equation or an ecosystem of competing pools.\n\n**Matthias** -: Okay. I'm just thinking about something, which is just a wild idea to maybe test social behavior as well. But we could imagine having a ranking formula that is based on CIP 50, and see if you can get some buy-in from existing Wallets, for instance, to display that ranking and the potential rewards for different pools as if CIP 50 was implemented sort of to start getting an idea of what it would mean for that CIP. You can showcase this one under CIP 50, would be expected to have this ranking and earn this particular amount of reward. Maybe that would make things a bit more concrete for people also.\n\n**Michael**-: Yep. That's part of what's in development under a sub topical thread of the CIP 50 PR discussion here on this Discord. There's been a couple of screenshot images shown of almost exactly that, but as I mentioned, I think we're still under development with those ideas and not ready for inclusion yet.\n\n**Matthias** -: Okay. Okay. Good. Good. I somehow missed that from the discussions.\n\n**Michael**-: Yeah. The sub threads auto archive after 24 hours. So you might have to scroll back and find it from the main PR discussion topic.\n\n**Matthias** -: Yeah. Yeah. I think I see it now, these pool ranking work sub threads on... Yeah. There are 30 different messages in there which I missed. Okay. Then I will try to go through that. Also bring that back to the GitHub issues just for the sake of sharing. Okay.\n\n**Matthias** -: Anything more on CIP 50 from your side?\n\n**Michael**-: Apart from updating all of the charts, I also have a thought that I haven't implemented yet that I should include charts, not relative to the delegator yield, but relative to the pool owner operator yield. And so that would be an additional few charts that would show their return on invested capital that I think is Prometheus pool correlate has done a great criticism and job showing that those charts and those relationships are important relative to the owner. And I agreed that those charts could be included, but haven't yet. And so I think that could be wise to do.\n\n**Matthias** -: Thank you.\n\n**Michael**-: Because the Cardono as a whole, isn't just optimizing the reward equation for what the delegators earn, it's also trying to ensure that the relationships for yield or the operators are also aligned with what we want decentralization to be.\n\n**Matthias** -: Well, I think that was actually the primary goal of the RSS paper originally, not to maximize rewards for people, but actually to incentivize to reach that `k` parameter - the optimal number of stake pool. The reward is just the incentives or the means by which we reach that equilibrium point. But I think the end goal has always been reaching that equilibrium point.\n\n**Michael**-: True. That gets into a very deep philosophical discussion of whether you can use central economic planning to bias the network to a goal target number, a goal target rate, a goal target yield, a goal target count. Obviously the original IOG perspective is that they can, and the K parameter can do that. And so that bias and central planning number works, but the equilibrium point has now become about 10 times less than intended.\n\n**Matthias** -: Yeah. That's the thing.\n\n**Michael**-: Yeah. So then it gets to the philosophy of for the values of Cardano, do we want to have a centrally planned system or do we want the system to become the best version of itself, find its own equilibrium without bias?\n\n**Matthias** -: No. I mean, it's always been an interesting discussion to see that. You want decentralization, but not too much, because there is this `k` that dictates you how much decentralization we tolerate for the system, which I think is also to correlate to the actual networking side of things, because the system that is too decentralized might also have a problem propagating blocks and getting the job done. So I think that's why there is an actual optimal `k`, kind of that is currently being fixed by one party, which also happened to be the party developing the networking stack because it's all a proof of stake system in the end. The network working is way more complicated than it could be compared to a proof of work system.\n\n**Matthias** -: Because there are tons of assumptions that you cannot make and you have those actual hard limits on the block propagation; I mean, how much of the networks needs to reach consensus within a certain time window, which means that in practice, you can't probably reach a point where you have 10K different block producing nodes. I mean, I'm just shooting numbers here. Don't quote me on that. But there is definitely an optimal number from an engineering perspective. And then there is an optimal number from a social perspective also, and we kind of have to find the right balance between the two.\n\n**Michael**-: Yeah. We're hoping that... I'm personally hoping that with some of the peer to peer technologies, the number of network supported relays under the block propagation threshold is increased by hopefully an order of magnitude, maybe two, such that the network capabilities are much more than what the equation is set up to do. That's my hope. I think we're starting to see some evidence that that might be maturing and growing as more peer to peer nodes are adopted on the network. But I agree that could be a problem if you don't have peer to peer. If you do have peer to peer, the ceiling might go up by an order magnitude. And then I think if we unlock the centralization, then what we might have to do is make sure that any network consensus and block propagation stays half an order of magnitude to an order of magnitude, more capable ahead of where the actual community is decentralized to.\n\n**Michael**-: And one of my buddies, Rob, he recently got into this space, he's... There are global consensus mechanisms that scale, even another couple of order of magnitudes beyond which could be considered on an engineering side. Much more complicated, but they're used for things like synchronizing the video of a super bowl or world cup across thousands of data centers globally for a live broadcast, for example. So they exist, other people who are using these technologies on the internet to do global scale consensus, but we might not need to adopt them to enhance a fledgling peer to peer yet.\n\n**Matthias** -: Yeah. And I mean, I guess there's also questions of how many of those scheme are also Byzantine resistant and fault tolerant because that's kind of the point here. We don't just want a consensus, a distributed consensus algorithm, we want one that can resist attacks of various kinds, but that's both an engineering problem and a political problem at the same time. So I mean, I think there are explanations as for why there is a `k`-parameter today. So sort of my point, would that be needed once we have peer to peer enabled? Maybe not. That's kind of the hope. And as you say, let the system auto-balance itself and find its equilibrium regarding decentralization and what's the right amount of decentralization?\n\n**Michael**-: To become the best version of itself.\n\n**Matthias** -: Yes. Let's maybe quote that under the CIP title.\n\n**Matthias** -: Okay. So let's keep the discussions going also and have CIP 50 back for review next week. We haven't got any updates from IOG, think they have been busy with Vasil with some of the recent problem and bugs found. So I haven't heard of Kevin on that. I think Christophe mentioned that he... I mean Kevin said something recently online on the 360 or something like that, but it was nothing really substantial, just that they were looking at it. They were aware that it existed, wanted to well provide also feedback. We'll still a bit waiting on that sentence. So let's see next meeting.\n\n**Anthony**-: Amazing. Great.\n\n#### PR296\n[PR296 CIP-0062? | Governance API for dApp Connectors (dApps<->Wallet Web-bridge](https://github.com/cardano-foundation/CIPs/pull/296)\n\n**Matthias** -: CIP 62 is next in line, right?\n\n**Anthony**-: That's correct.\n\n**Matthias** -: I've been trying to click on the link for 15 seconds and I just realized it was a stream. One can't click on a video, obviously. Anyway, governance API for DApp, which was proposed by Bruno Martins, who is now the tech lead regarding Wallets at IOG if I recall correctly. And this is a proposal to extend CIP 30 with capabilities that would make that voting process a bit more streamlined. Sorry, I did a first run of review on that one this morning and mainly suggested to simplify a bit some of the methods in particular to make things a bit more orthogonal, meaning not to have the API provide five different ways of doing the same things or in that case two different ways.\n\n**Matthias** -: And I'm also asking for a rationale section mainly because, we need a rationale section for any CIPs in general, and because that gives the bases for discussions and that explains, at a later time, why the decisions were made, the context within which they were made. And for that one in particular, because there are a few suggested API or endpoints, you could say, or interfaces, that can be done currently through existing libraries and I don't see why adding them to the bridge, the wallet interface so to speak, makes sense. Or at least there is no justification for it. I can get that it's maybe a bit more simple and that removes some of the burden from the apps implementing that, but those apps are mainly Wallets anyway. So that was a bit some form of the gap in the justification here that I'm liking. I don't know, Sebastien, if you had a look at that yet.\n\n**Sebastien** -: No, unfortunately I was hoping to look into it today, but as you may have heard, there's other stuff that came up. There's still some discussion going on internally related to the CIP, so stuff may still change, but definitely it's good to over it. I agree that it's probably over complicated the way it's testified now and I'll try and find some time to give my thoughts on this.\n\n**Matthias** -: Okay. Because my main understanding on this, or I mean, experience that's... I mean the catalyst voting in general, it's always been done by wallet implementors themselves; [Inaudible] So I don't quite see the need for an external API for that to let any DApp do the registration themselves.\n\n**Sebastien** -: Oh, so the reason for this is because they want to have this de-rep system. So basically anybody can propose themselves to be a representative for catalyst voters and you can delegate your aid out to this representative. Similar to stake pools, there needs to be some sort of stake pool viewer just like there needs to be some sort of de-rep reviewer. So there'll be websites that are made for this. And then some of these dealers may have their own website with a click here to delegate me on all those kind of interface. So the motivation for this is almost only the direct feature.\n\n**Matthias** -: Okay. So, then I don't get the API cause a lot of the API are-\n\n**Sebastien** -: Yeah.\n\n**Matthias** -: It's leveraging key derivation path, which suggests that the key belongs to the Wallet and not to some delegated-\n\n**Sebastien** -: Yeah. I think this is a mistake. It should be like other standards where you start with zero and then if zero is huge to get one and the Wallet handles this, I think. Having the debt analysis is going to be a huge disaster.\n\n**Matthias** -: So okay. Definitely a need for some of the motivation and rational. So I've already flagged that on the PR waiting for some comments now on this. Yeah. So I guess we can just leave it there for now. If we have any of update from the author before the next meeting, we can discuss that again in the next meeting otherwise, I just wait.\n\n#### PR299\n[PR299 CIP-0068? | Datum Metadata Standard](https://github.com/cardano-foundation/CIPs/pull/299)\n\n**Matthias** -: To do. Next one on the agenda, CIP 68. Datum metadata standard, which comes as a replacement or an iteration on the existing metadata standards. But this one aims to be a bit general, although the specification is also focused on NFTs at this stage because that's the main use case driving that proposal.\n\n**Matthias** -: The main spirit as for... I think the main rationale as for why put a metadata in the datum instead of in the transaction is because you cannot access metadata of the transaction as part of your Plutus script, which is a little odd. And it truly sounds like at a political issue, at least the transaction metadata and the datums have become kind of redundant with one another. So having access to the metadata inside the script allows for some extra validations to be done in particular when moving NFTs around.\n\n**Matthias** -: Without access to that, your scripts are basically blind to what happened, which makes it very hard to just update metadata, for instance, if that's ever needed. So I think that's the core motivations behind that CIP. Beyond that the structure is kind of similar to what was already proposed for the NFT standards, except that it's fully accessible from the script's context and something that is meant to be provided as datums, so Plutus built-in data, and possibly interpreted as JSON once again. And well, that's about what I have for now on that. There have been a lot of discussions on it. I admittedly, didn't go through all the comments yet. Sebastien, I see you've been a bit more active than me on this one. So maybe you have some inputs as well.\n\n**Sebastien** -: Yeah. So for this CIP, as you mentioned, is kind of a solid, better version of 25. The problem of 25, of courses is that I have to rely on this initial mint transaction and there is no guarantees that this is the actual mint. This one is slightly better, but still has the same issue, which is that now it's including stuff as part of the asset name. And now you have no way to know if the asset name is really by design or if this was a smart contract where users got to pick the asset name, this is a bit rarer of a situation. So it's slightly better. I still think it's slightly problematic. Personally, I prefer the option that [inaudible 00:44:11] maker came up with. So if there's another CIP that's the DID standard for Cardano and inside, they did standard. They did something very similar to this metadata standard, except they added another layer of indirection to avoid having to have the asset name stuffing, which I think is probably the better approach, but all things considered, I don't think there's anything wrong with CIPP the way it stands now. Obviously there's some issues with it as I mentioned, but if people use it, understanding of these issues, then I don't see anything wrong with it in particular.\n\n**Matthias** -: Okay. We haven't really looked at CIP 66. So this DID standard proposed by the team, which might be good then to bring on the table, at least in the next meeting or next to the new metadata discussion, especially if they have some conflicting opinions on these.\n\n**Sebastien** -: Yeah, I think there were three PRs with conflicting implementations of this many data standard. So there's the metadata standard for us as the end maker one. Then there's a third one that also had something similar. I don't remember.\n\n**Matthias** -: Well, there was on chain metadata proposed by this web team a while back, but I think this one got...\n\n**Sebastien** -: Cardano Smart NFTs.\n\n**Matthias** -: Oh no, that was yet another one, the smart NFTs. The smart NFT were about embedding actual codes on the blockchains that makes those NFT... I mean, that's an API for those NFTs to be embedded.\nSpeaker 4:\nRight. And they want the way to upgrade these...\n\n**Matthias** -: Yeah. To make them programmable and interactive in a way. But there is some overlap maybe less than with CIP 66. Okay. So that would be important to mention and to see if we can get maybe both offers to discuss where there is no problem in having two different proposals. That's always a pain down the line. So platform that need to implement both of them as that both gets really adopted. So we might as well want to have only one. So I'll mention that on the request.\n\n**Matthias** -: Let's put the link.\n\n**Matthias** -: So I will suggest you have maybe a discussion with the two authors as part of the next CIP biweekly, if they can both make it, that would be great. Just to compare trade off and see if there is perhaps one that should prevail over the other.\n\n**Matthias** -: Yeah. And well, that's kind of it from my end. So I guess we can finish things up now.\n\n**Anthony**-: Excellent. Thanks. Thanks Matthias. That's great.\n\n**Matthias** -: Yeah, I'm just finishing up a comment on CIP 68. I can do a small summary of the session after that. No problem. Just trying to get the handle for the author.\n\n### Discussions\nN/A\n\n### Issues\nN/A\n\n### Close \n\n**Matthias** -: Okay. So back to the meeting and the agenda. So we've been through, well CIP 27 of the status of the exchange with move it to active.\n\n**Matthias** -: Then CIP 30, there was the discussion of adding a Wallet experimental API version to it, which happened while back has been idle since. There was a suggestion from Sebastien a while back also to use the Wallet name, to address what that particular suggestion was about. So waiting for the author and we'll close it in the next biweekly if there is no update on that one.\n\n**Matthias** -: CIP 45, which is another proposal that tries to address the pledge/incentives issues on Cardano. We somehow completely missed that one in the past because it's been there since the 1st of March. So we're trying to get back to the author now and see if we can spark back the discussions on this. We reflect this to you as well, to see if we can get that into their feedback pipeline.\n\n**Matthias** -: We'll discuss also updates on CIP 50, mainly related to the recent blog posts that were shared by IOG and the research team. A few action items on that being, make a response to those blog posts and as well, update some of the graphs to take a slightly different perspective. Then what we currently have. And there was also these discussions of maybe trying to make some of the data available to wallets or applications, which also happened on this call as well. We discussed briefly CIP 62, which is an extension of CIP 30 to add methods regarding the catalyst voting registration. It wasn't clear as for why one would want that as part of the CIP 30, that connector. And so if like that, asking for a rationale or some justifications from the original author.\n\n**Matthias** -: And finally CIP 68 regarding the datum metadata standard, which comes as a replacement of CIP 25, there seems to be some overlap with CIP 66. They have both different, slightly different trade offs. So we are suggesting to have a discussion between the authors of the two CIPs and so have that your discussion next week. And that's about it.\n\n**Anthony**-: Excellent. Thank you, Matthias.\n\n**Matthias** -: Yeah so-\n\n**Anthony**-: Anybody else on the call, is there anything that you'd like to discuss or add on or can we complete like that?\n\n**Matthias** -: I think we're good. So thanks everyone for joining and Michael for speaking and updating us also on the CIP 15 and see you in two weeks.\n\n**Anthony**-: Great. Thank you everybody. Bye.\n\n\n---\n## Extra\n\n### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md)\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n© 2022 GitHub, Inc.\nTerms\nPrivacy\nSecurity\nStatus\nDocs\nContact GitHub\nPricing\nAPI\nTraining\nBlog\nAbout\n"
  },
  {
    "path": "BiweeklyMeetings/2022-08-16.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [August 16 2022 Transcript](#august-16-2022-transcript)\n  * [Triage](#triage)\n    + [CIP-0051? | Preserve submitter's ordering of transaction inputs](#pr231)\n    + [CIP-0048? | Extended 721 metadata](#pr249)\n  * [Last Check](#last-check)\n    + [CIP-0030 | Added walletExperimentalApiVersion](#pr225)\n  * [Review](#review)\n    + [CIP-0045? | Decentralization: Using Pledge as a Bidding Param](#pr229)\n    + [CIP-0050? | Shelleys Voltaire decentralization update](#pr242)     \n  * [Discussions](#discussions)\n    + [CIP-0068? | Datum Metadata Standard](#pr299)\n    + [CIP-0066? | NFT Identity](#pr294)\n    + [CIP-0060? | Music Token Metadata](#pr307)\n  * [Issues](#issues)\n  * [Close](#close)\n\n## Summary\n\nRough transcript of 16/08/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Transcript might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significance to you.  \n\n\n## Editors Meeting Flow\n\n**Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n\n**Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n\n**New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \n\nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n**Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n\n**Issues**: Review of the open Issues on the CIP GitHub \n\n**Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  \n\n\n## August 16 2022 Transcript\n**Attending Editors**: Matthias Benkort, Sebastien Guillemot, ~Frederic Johnson~, Robert Phair. \n**Guests**: Christophe Garant, Michael Liesenfelt, Andrew Westberg, Alessandro Konrad, Thomas Vellekoop\n\n### Triage\n\n#### PR231\n[PR231 CIP-0051? | Preserve submitter's ordering of transaction inputs](https://github.com/cardano-foundation/CIPs/pull/231)\n\nA technical issue resulted in this discussion not being recorded. Please review the CIP summary under Close. Apologise for any inconvenience caused. \n\n#### PR249\n[PR249 CCIP-0048? | Extended 721 metadata](https://github.com/cardano-foundation/CIPs/pull/249)\n\nA technical issue resulted in this discussion not being recorded. Please review the CIP summary under Close. Apologise for any inconvenience caused.\n\n### Last Check\n\n#### PR225\n[PR225 CIP-0030 | Added walletExperimentalApiVersion](https://github.com/cardano-foundation/CIPs/pull/225)\n\nA technical issue resulted in this discussion not being recorded. Please review the CIP summary under Close. Apologise for any inconvenience caused. \n\n### Review \n\n#### PR229\n[PR229 CIP-0045? | Decentralization: Using Pledge as a Bidding Param](https://github.com/cardano-foundation/CIPs/pull/229)\n\n**Matthias** -: CIP 45 seems to incentivize pools to create, oh sorry, stake pool operators to create many, many pools by giving them an optimal pledge to follow and is wrongly making the assumptions that one pool equals one individual. Whereas in practice, we know that to be untrue, there are several groups that are run by single individuals, and therefore many of the assumptions of the rationale from that CIP crumbles a bit from that. So I haven't read yet through the comments that the author has made on that, but it seems that those points are being considered at least.\n\n**Matthias** -: There are also a few suggestions purely on the form itself, mainly that this, the CIP contains quite a lot of equations and visualizations, which are so far linked through an external Google drive as images. So I suggested the author to actually use the new latest support from GitHub that landed some months ago to actually display equations directly in GitHub, or at least to use an image, but hosted next to the CIP itself, that will simplify a bit. And the author has acknowledged those points and said it would be working on updating that according to the suggestions. So some more to come, I guess.\n\n**Robert Phair** -: As far as using the equations in CIPs and in GitHub content, the difficulty they ran into with another CIP 50, did they ever work out the presentation of LaTeX type equations on the mobile platform? Someone said they weren't working.\n\n**Matthias** -: So there is only Christophe on the chat commenting that. Yeah, they have done equations on GitHub, prone to some issues as you learn from CIP 50. So you are saying it's specifically on a mobile device, that it is not supported yet?\n\n**Robert Phair** -: That's what I think Christophe was saying.\n\n**Matthias** -: Which is probably okay. I mean, if you are reading a CIP of that magnitude on a mobile that's, I mean, you're pretty brave I would say.\n\n**Robert Phair** -: I get it. I hadn't thought of it that way. They could go back to the original form if they want to see that kind of detail in the equations.\n\n**Matthias** -: Probably, it looks good in VS Code and Jupyter Notebooks, says Christophe. But then in GitHub, some stuff can't render, I guess. And it does not render on mobile. I can't speak if, yeah, not, actually, since you are here, it'll be faster than just writing on the chat. Can we just unmute you. Yes, it's done.\n\n**Christophe** -: Can you guys hear me?\n\n**Robert Phair** -: Yes. Hello?\n\n**Christophe** -: Oh, Hey everybody. Yeah. So as I learned in CIP 50, yeah, the mobile definitely doesn't render, but then there's some brackets, especially curly brackets that doesn't render on GitHub even on desktop. So that's why we reverted back to basically screenshot equations from external source. Pictures.\n\n**Matthias** -: Is it a problem from GitHub specifically, or is it MathJax in general that is just-\n\n**Christophe** -: No it's specifically GitHub and I did some digging and I don't know, I guess the layman's interpretation, it was something with like Java... Sorry, I just got a call. JavaScript rendering on the website itself with GitHub. And there were some conflicts and it seems like a mess, but it'll look good in VS Code and even Jupyter Notebooks and just regular [inaudible 00:04:25] it's fine. But when it's in GitHub README, it breaks. So you have to add some extra back slashes and curly brackets and yeah, we eventually just reverted back. For simpler equations, it is probably okay. But for more complex things, it breaks it seems.\n\n**Matthias** -: Okay. Yeah. I mean, it's a brand new feature, so that's not yet fully ready I imagine. Although it was shipped, but yeah. Okay. I think the equations in CIP 45 are a bit simpler than those on CIP50 or at least I was able to render some of them quite easily, but I haven't tried to render all of them, arguably. So there are some more complex equations below after that.\n\n**Christophe** -: Yeah. If it works great, but yeah, just be prepared to check.\n\n**Matthias** -: Yeah. Okay. Is, by the way, do you or, and I see we have also Michael here, have any comments on CIP45? More on the content of the proposal and how it reflects to CIP 50. There is some kind of overlap, but it's definitely taking a slightly different route or at least just focusing on the pledge parameter here.\n\n**Christophe** -: I personally haven't reviewed it, but now I will. I wasn't that aware of it so...\n\n**Matthias** -: Good. That's why we have the meetings then.\n\n**Christophe** -: But I'll do that.\n\n**Matthias** -: Yeah. Maybe we can move it to review for the next meeting again, just to let people have time to go through the content. It's quite, I mean, the overall idea is quite simple, but the details as always, right, the complexity lies in the details and some of the equations are not quite obvious. So it takes a bit of effort to process.\n\n**Robert Phair** -: Michael, this is a time one that I got you to chime in on the forum about, you made a comment there. So I think it is one of the ones that you've seen.\n\n**Michael** -: The notes. I was looking at a couple of those and there was that I believe it's CIP 37, this one, 45 and I guess 50, that is all with pledge and the centralization metrics is concerned. It's very, well, it's hard to go through you, you'd expect so. [inaudible 00:07:03] so I don't know, I wish I could give us [inaudible 00:07:04] and maybe there's a way that we can bundle them, simpler path to a review. I don't remember its particularities on the whole.\n\n**Matthias** -: The way I see it currently is, we have CIP 50, where most of the [inaudible 00:07:22] discussion really happens, which is probably the most structured of all those proposals that we have at least in terms of the [inaudible 00:07:30] operations, if I can say, or how the feedback is incorporated in the CIP. So all those other CIPs that are kind of overlapping, but not exactly the same, are they think the same issues as CIP 50, I think they should be part of the same discussions because they all have a similar set of assumptions. And they all have a similar set of outcomes. The question is now, which one are we going to adopt in the end? So if there is a more generic discussion happening on this decentralization concern, we want an incentive on [inaudible 00:08:07]. I think it's best driven from CIP 50 and includes feedback or update from all those other side proposals that happened.\n\n**Matthias** -: I think this is a bit what Michael is also saying in the chats, by saying \"I've included CIP 45 in the CIP 50 references since the first draft\". And I think it's good to keep that as part of this, the discussions, because in a way it's part of the whole same discussions. And as we are now trying to get more and more attention from IOG research, I mean, we're not going to have that discussion five times, one for each of those CIPs, but probably once and for all, at least for the next proposal to come and see which direction we take.\n\n**Robert Phair** -: I've also suggested to the CIP 45 author that he come into the discord on the CIP 50 channel, and to review what's already happened and to explain to others that have been following the issue for their issue, how his presentation is different and similar.\n\n**Matthias** -: Yeah, so perhaps that's also kind of, I don't know, part of CIP 50 rationale section, they have a kind of alternatives considered and list a bit of the pro and cons of those various other CIPs and why maybe what was taken from them, what was rejected from them for which reason, because it might actually also have discussions and having one place to centralize all the results there might help too.\n\n**Robert Phair** -: Just quickly. Might there be a benefit to changing the name of the PR 242 discord channel to decentralizations DIPs to encourage a more general discussion like that?\n\n**Matthias** -: Perhaps, but then I would suggest more rewards and incentive rework because I mean, decentralization is of a consequence of that, but this is really about reworking the rewards and incentives of Cardano and how do we currently define stake polls, rewards and all of that?\n\n**Robert Phair** -: Yes.\n\n**Matthias** -: Any comment on those points? Is that no?\n\n**Robert Phair** -: You saw when you, at the [inaudible 00:10:43] when you looked over that there was a suggestion that the MAC addresses on the machine might be considered relevant to the point of CIP 45. And I've suggested that maybe that should be moved off to the Cardano forum and kept out of this CIP 45 discussion on GitHub. I believe it's irrelevant to the CIP as stated and, I think the rationale for doing that is not correct.\n\n**Matthias** -: Yeah. I need to read through that comment a bit more in detail.\n\n**Robert Phair** -: Anything regarding the MAC addresses and how the MAC address could be used to further the ambitions of that CIP I think can be skipped over in considering the CIP. It's been a digression.\n\n**Matthias** -: Okay. So let's have it on the next biweekly that would give people some more time to go through it and hopefully a bit of time for the author to address some of the points that we mentioned. Okay. No comments. So moving to the next one. So we have CIP 50 on review here, but I would like to jump actually on CIP 68 and CIP 66 first, since we've been talking about CIP 50 for pretty much every past meetings. And I would like maybe to keep it for the end more as a closure kind of discussion if people are okay with that.\n\n**Anthony Meyer** -: Yeah. That works for me.\n\n**Robert Phair** -: That's fine.\n\n#### PR242\n[PR242 CIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242)\n\n**Matthias** -: Or US friendly. So, okay. I want to keep some time for CIP 50 as we discussed initially. So maybe Michael, if you're still around and want to give us a short update on progress on that side, there was a discussions with Argulus that happened last week. If I recall correctly in the SPO call. So maybe some news on that. You should be able to speak. But I can't hear you.\n\n**Anthony Meyer** -:I'm also still not hearing Michael. Is it only me?\n\n**Matthias** -: No. Okay. So there is no one speaking, right? I see Michael keeps unmuting himself, but we can't hear you somehow. I thought it might just be me, but no.\n\n**Anthony Meyer** -: No, I'm also not hearing him. \n\n**Matthias** -: Christophe is also unmuted. If you also maybe have some info on that. So he rejoined and we still can't hear you. Nope. Well, that's unfortunate too, I'm not seeing any Michael. Michael is in chat. You don't see him? He's in the list.\n\n**Anthony Meyer** -: I did see Michael at the start of this call.\n\n**Matthias** -: I'm failing on audio. Yeah, we can see that. So I don't know if Christophe maybe wants to give us that shorter bit. I think you've both chatting on that. Okay. Or we can leave it for next time or has it written a update maybe? On the meeting windows app. Yeah.\n\n**Christophe** -: I guess I, can you guys hear me?\n\n**Anthony Meyer** -: Yes.\n\n**Matthias** -: Yes, we can hear you.\n\n**Christophe** -: Thanks, Michael can't speak, but I guess I just put on, I just updated a pull request on the rank leverage based ranking recommendation last night, which we've removed a grading system to kind of be a little bit more objective. So it's just kind of a 10 is the best and then zero is the worst kind of recommendation, but again, it's just a recommendation, not actually core to it.\n\n**Matthias** -: Okay. So, well let's maybe keep room for CIP 50 at the beginning of the next meeting next time to make sure we got time to discuss it and maybe resolve geo problems during the call. I will also try to maybe just post the summary of, again, the conversation that happened on this calls. I haven't been keeping track of that lately, but bit of things have been said, and yeah, so I wasn't part of the SPO call with Argulus, and I would have been curious to just hear what was said. I'm not sure if it was recorded or not. That's cool. Probably not. They are not usually recorded. But anyway, so it's time. \n\n### Discussions\n\n#### PR299\n[PR299 CIP-0068? | Datum Metadata Standard](https://github.com/cardano-foundation/CIPs/pull/299)\n\n**Matthias** -: Okay. So let's have it on the next biweekly that would give people some more time to go through it and hopefully a bit of time for the author to address some of the points that we mentioned. Okay. No comments. So moving to the next one. So we have CIP 50 on review here, but I would like to jump actually on CIP 68 and CIP 66 first, since we've been talking about CIP 50 for pretty much every past meetings. And I would like maybe to keep it for the end more as a closure kind of discussion if people are okay with that.\n\n**Matthias** -: Okay. I see one thumbs up in the chat, two thumbs up in the chat. So CIP 68, which is also a big peace to be discussed. Wait, wait, can I click on that? Anthony, do you think you can bring that one on screen, on the stream?\n\n**Matthias** -: Yeah. Great. So, yeah, I also been through that one today, made quite a few comments and I try to summarize some of the discussion that happened between people. There has been mainly three discussions tracks, as far as I could tell. One between kind of Michael and Alessandro on the metadata spoofing that is currently possible with CIP 25 and how this is still possible with CIP 68, but far less likely. And so discussing possible alternatives or how to mitigate that, or make it even less likely to happen. There has been another conversation discussing the costs, more of that CIP since in this proposal, there is an implied creation of UTXOs.\n\n**Matthias** -: So the core idea is to have, per token two different UTXOs, one capturing the actual asset and one carrying the metadata of that asset, evolving on two separate track, which means that compared to the current approach, there is an extra UTXO being generated that incurs obviously ada deposits and additional costs. So that was being discussed and it'll be nice to have numbers on that maybe, just as a kind of high level analysis and finally, a third discussion on whether or not to store the data on chain as CIP 68 suggests, or do it more like in an option manual, like CIP 54. And in particular, there was quite some disagreement about whether or not CIP 25 should be deprecated in favor of that one. And I think this is a completely separate discussion. So there is a new proposal that offers an alternative to CIP 25 and next to that, there will need be a discussion on whether or not CIP 25 should be deprecated and rendered obsolete. Even though there are now 5+ million tokens that have been minted under CIP 25, despite all the flaws. So yeah, that was more for discussions.\n\n**Sebastien Guillemot** -: Yeah, so [inaudible 00:15:32].\n\n\n**Sebastien Guillemot** -: So my summary of CIP 68, I do not think there's anything technically wrong with the proposal. And I think most of the discussion around the CIP is not so much, well not there's anything technically wrong with the proposal. It's mostly discussion about whether or not people think that this standard will get adoption, which is a fine discussion to have, especially because people, their point of view may, I'll clear the specification itself. But I feel like we're at a point with CIP 68 where I would feel comfortable to say that this looks like it, if nothing comes up in the next, two weeks, we can move this to a draft standard and then set some sort of adoption requirements to mark this as active.\n\n**Sebastien Guillemot** -: If, we say this is technically correct, and nobody's really discussing the technical aspects of this anymore and then it ends up that's [inaudible 00:16:46] is the only project that adopts it, then okay, it just stays as draft forever and never got adoption and that's a fine result. If, people end up bringing this and then decide it's worth whatever trade offs that are involved and gain adoption that we can mark it as active. But I think, the discussion about deprecating CIP 25 for discussions around adoption, I think are a separate discussion of the technical correctness of this spec. And I think at this point we're kind of past the technical correctness stage, is my thoughts on this, but I'm open to hearing what other people think.\n\n**Matthias** -: Yeah. I pretty much agree on that from the technical point of view. So I came quite late in the conversation and really just read for the CIP today and beyond a few minor things. I didn't really spot anything technically wrong. I think I made a few suggestions regarding at least the \"implicitness\" of some privileged labels. Just assuming that some asset labels are blessed and always implicitly present in that CIP since there is this whole registry concept now. I think it would be better to just go for generic and I have also the CIP itself embraced this history for self-defining itself and possibly future evolutions. But yeah, beyond that, indeed. And-\n\n**Sebastien Guillemot** -: Yeah, I noticed here as well, he's under here as well if he wants to comment anything.\n\n**Matthias** -: That's what I was about to ask. Yes. We have a list on also. Let's unmute. You can now speak. Yeah.\n\n**Alessandro Konrad** -: Can you hear me?\n\n**Matthias** -: Yes.\n\n**Alessandro Konrad** -: Okay, great. So first of all, regarding CIP 68 versus CIP 25, the thing is that CIP 68 is defining a more generalized metadata standard for any token. And this is pretty much overseeing because anyone who is commenting on costs is mostly referring to NFT drops. If I meant NFT, the costs are pretty much not there. They are irrelevant. It's really only for NFTs. But the thing is that these costs are, if you implement the amending policy, I would say correctly, the costs are temporarily because you could implement native burning mechanism and then redeem the data at some point, if the NFT is getting worthless. So I think, I don't know if this is, yeah, really a cost then, and CIP 68 kind of forces you to make use of Plutus and I think everyone who is using CIP 25 is making use of very simple native scripts, just the time locking policy.\n\n**Alessandro Konrad** -: And over time, these NFTs are completely locked. There's no way to burn them. So I don't think that's great either because, yeah, I'm pretty sure from all of the five million assets, 90% will probably get worthless over time. I don't know. But these assets are simply then, yeah. [inaudible 00:20:52] simply locked forever and with CIP 68, we could get rid of this because people are more or have to get more into Plutus and then they realize, well, we could actually have some kind of native burning mechanism and redeem the data again because maybe over time we will have less and less data in total supply.\n\n**Matthias** -: Sounds, this could even be framed that way perhaps more clearly on the motivations behind the CIP. What is revealed on the table is this programmability of NFTs. If you don't need that, then CIP 25 is probably a good fit because of its adoption and despite its other problems. But if you need programmability, if you want to be able to manipulate either NFTs or just need metadata access within the script, then that is a sound standard for that. So perhaps, yeah. I don't know, frame it bit more like it, indeed, like you said, right? A generic standard on metadata storing and NFT being one possible component of that, but perhaps not the main use case either.\n\n**Alessandro Konrad** -: Yeah.\n\n**Matthias** -: We have a lot of activities in the chats and maybe it would be worth to bring some of those people on the vocal. So we have Andrew saying: \"I agree, technically, correct. I wouldn't want to deprecate CIP 25 though. NEWM is using CIP 25 to mint NFT\". Thomas: \"disclaimer, you do not need to use produce native script can also be used for the CIP\". Phillip saying: \"I also agree, but forcing people to learn a new standard is not the right way, I think\". Okay. Andrew: \"producer's minting/burning with an unlock policy while guaranteeing that they are true NFTs, non fungible\", and finally Thomas: \"this CIP perfectly allows you to pre-mint assets as a creator and later distribute them with native scripts.\" Should we bring a few people on the vocal maybe to discuss that a bit more?\n\n**Matthias** -: So I would love that then. Andrew, if you [inaudible 00:23:23].\n\n**Alessandro Konrad** -: Yeah. Maybe Thomas because he's the other author.\n\n**Matthias** -: Okay. So Thomas and Andrew, you can unmute yourself if you want to speak, if you don't want to speak, well stay mute.\n\n**Thomas** -: Hi, nice to meet you all. I'm Thomas the other author of this CIP. Yeah. So I think this CIP doesn't force you to use Plutus, but it allows you to use Plutus and fully use it. So as I said, you can pre mint these assets by yourself and then distribute the reference NFTs to a script that you like, you can lock them indefinitely, you can lock them, yeah. And at any address you would like, this here doesn't specify that. But what it does, it allows you to mint with Plutus and that opens a lot of doors. So that...\n\n**Andrew** -: Yeah, I would agree overall I like the CIP. I think it allows for programmability when the NFT requires programmability, but I do like the simplicity of CIP 25. So what we're doing on my new project is we are using Plutus to mint, but we're not following this CIP 68 because we don't need all of those. All of that complexity, all we need Putus for is just to have this continually unlocked policy while at the same time, guaranteeing that you can't reinvent the same NFT twice. So that's what Putus gives us there. So it's basically unlocked policy forever guaranteeing that everything you spit out of that is a true NFT. But I do like that CIP 25 is very simple because we don't have very complex needs as far as programmability I guess.\n\n**Thomas**-: If I can comment on that, I think, I agree with you and I think both CIPs will exist alongside each other, but I think perhaps in the future, when more tools are built for CIP 68, so that it's easier to mint, things are predefined. You can just copy stuff from other people that went before, that this barrier that you're describing will be lowered. So I don't see it as a problem in the future.\n\n**Andrew**-: The new Plutus scripts are all open source. So people could use that as well. If you wanted to have an NFT that has an always open policy, you can always mint more, but then they'll still be guaranteed to be NFTs that you can't do with a simple script.\n\n**Matthias** -: Okay. So I would suggest more concretely to move the proposal maybe to last check for the next call. And as Sebastian was suggesting, so merge it as draft or even proposed I think, in the sense that modulo a few minor points raised today, the proposal is probably already in a shape that is close to final and as soon as we get some adoptions from wallets, market places and the like, move it to active, right? Once we have reference implementations and perhaps a few tools around that.\n\n**Thomas** -: Can I mention, I like the idea of that and what I still want to discuss about the CIP and, well, it was mentioned in the discussions as well, get up, we use this label and this is to distinct tokens that use this CIP and who don't, but this is arbitrary. And I think it'll be good to have a discussion about what a good label should be and so first we came up with these brackets and I think these are bad from the discussions that we get and then we mentioned the new bite and other things, but I think that is something that's still open or at least, yeah, we have a proposal, but I would like to hear others about it, what they find important there.\n\n**Matthias** -: Wouldn't that be a discussions more for CIP 67? Which is proposing this asset name, label or history.\n\n**Thomas** -: That's true. That's true. Yeah.\n\n**Matthias** -: So yeah, perhaps we can have it in the next agenda for next time and make sure that the question is sent out before that. So have a call for comments or call for feedback on that particular CIP 67, expressing the question that's basically there. That would be interesting and collect then the feedback on the next bi-weekly meeting.\n\n**Thomas** -: Sounds good.\n\n#### PR294\n[PR294 CIP-0066? | NFT Identity](https://github.com/cardano-foundation/CIPs/pull/294)\n\n**Matthias** -: Okay. So jumping to the other metadata proposal we have, which is CIP 66 on NFT identity. We wanted to discuss a bit of, I mean, both because I think it was Sebastian two weeks ago that mentioned there might be some overlap between the two. I've been through CIP 66 today and so it's naturally overlapping as far as I could say, but I could definitely see CIP 66 use or make use of CIP 68 to define this identity standard. So the thing I pointed out on CIP 66 is mainly that it's still relying on the same, or it seems to be relying on the same principle as CIP 25. And therefore in there is the same flows as for who is really minting the token and who is providing metadata. And should it just be always the same person? Apparently yes or implicitly, yes because of how the proposal is defined, which has further complications.\n\n**Robert Phair** -: Is the title of the CIP specific enough for people to understand what it's really about?\n\n**Matthias** -: Yeah.\n\n**Robert Phair** -: There was some other suggestions just like maybe NFT verification or verifier identity, if that's what it, in terms of its function or maybe NFT collection, or I thought maybe issuer identity, if it's who is doing it.\n\n**Matthias** -: From what I've grasped also from that proposal, it's mainly about taking the W3C recommendations for the DID standards that came out recently and kind of embed that in transaction with that data on Cardano. So, I mean, that is then very, very specific to the W3C recommendations. And I think the title should maybe mentioned that explicitly that this is a kind of card integration for this particular [inaudible 00:31:28].\n\n**Robert Phair** -: Something like NFT DID. Or-\n\n**Matthias** -: Yeah. NFT DIDs W3C recommendation integration, or maybe it's a bit too verbal, I don't know [inaudible 00:31:42] but it's, from the specification standpoint, it's also very rough on the edges, I would say, and refers a lot to the specifications on the W3C recommendations. It's basically the same, just adapting the format and putting it on kind of metadata. So in that sense, right, it's really just a wrapping CIP; that is wrapping another existing specification and translating the format from Json to [inaudible 00:32:15] somehow, which is also specified at this stage. So-\n\n**Sebastien Guillemot** -: Yeah, my comment about the similarity is that basically, so in CIP 66, you basically have two levels of indirection implementing, whereas in CIP 68, there's only one level of indirection. And with the two levels of indirection, you don't need this kind of asset name stuffing with the brackets and everything, all that goes away. So it's kind of different ideas for how you can go about this. I understand this is not the main innovation that CIP 66 was attempting to bring, which is why they didn't elaborate at all. But their core concept, as you mentioned, would not be compatible with CIP 68 because they went with a double layering direction. So it would be nice if somebody proposed a alternative to CIP 68 that uses a double layer of indirection solution, which as a entirely personal opinion is I think the better approach. But that was just the rationale for that comment.\n\n**Matthias** -: Okay. Is there any more comments on that one actually? Yes Thomas.\n\n**Robert Phair** -: Have Thomas. Yeah.\n\n**Matthias** -: You are now unmute.\n\n**Thomas** -: So that's end. Thanks for that. Could you specify more how you mean by these two layers, any improvement to our CIP is welcome so, but I didn't follow it quite clearly, what you meant with that.\n\n**Sebastien Guillemot** -: Yeah, so basically the way that CIP 68 works is that you have the asset names define the different categories of the assets or the different use cases rather, right? So for a specific name, you have specific utility that this name encodes, whereas the second layer of direction, you basically have a minting policy that will be in charge of other minting policies and these other minting policies are than what name based the split functionality.\n\n**Thomas** -: Okay. Thank you for clarifying. Yeah, I get it.\n\n**Sebastien Guillemot** -: Yeah. So you have two minting policies instead of a single minting policy, you have next to [inaudible 00:35:05] direction.\n\n**Thomas** -: Yeah. I think this processes a bit with an image shared in our CIP as well, that Alisandro made when we proposed this, the CIP doesn't specify this because you don't have to, but you could do it. Yeah.\n\n**Sebastien Guillemot** -: So it would be nice if we had a CIP standard where we did not right away out of the gate, have it, do it standard, come out and not be compatible with it, but baring that discussion, which is kind of tangential. I don't see any problem with CIP 66 as it is from a technical perspective.\n\n**Matthias** -: Well, I do see a few, but I've commented that on the proposal, especially the fact that it seems to narrate the same flows as CIP 25, which seems highly undesirable for something like this, where you would want perhaps to enforce an additional layer of security or make sure that it's not that easy to spoof someone else's identity. Plus, yeah, a bit like some remarks we made on previous CIPs that, it feels a bit rushed on the writing. There were many examples, but not so much details on the specifications and how you should interpret this or that particular scenarios. So yeah. I'm happy to have this [inaudible 00:36:50].\n\n**Sebastien Guillemot** -: Yeah. Which is why I feel like this CIP would've been better had it been something more like CIP 68's approach where they had a CIP that just defines this double indirections scheme up, the scheme they came up with and then made their NFT I think CIP reference saying this word, generic CIP.\n\n**Matthias** -: Would you mind maybe commenting on that? I mean, on the core request itself.\n\n**Sebastien Guillemot** -: Yeah. That's what my comment was supposed to indicate, but I think maybe I wasn't clear enough and maybe people got confused.\n\n#### PR307\n[PR307 CIP-0060? | Music Token Metadata](https://github.com/cardano-foundation/CIPs/pull/307)\n\n**Matthias** -: So, okay. Let's keep it on the agenda for review for the next meeting. And since we have 10 minutes left, let's quickly go through the CIP 60, which on my end, I'm a bit, sorry. That's the only one I haven't got really time to go through today. So since we have Andrew, I'm happy if you can give us a small introduction on that and yeah, just let's have a bit of a chat on it. You are probably muted. Yes. Now you can.\n\n**Andrew** -: Okay. Yep. I can speak now. Yeah. So CIP 60 came about because of there was a lot of, the standard for visual NFT metadata is very well defined in CIP 25. It's kind of geared towards that. It allows music and audio in the files section on CIP 25. But what we needed is more metadata for things like players or wallets that wanted to play music NFTs in a nice format and display all the necessary information like who the various artists are, publishers, et cetera, all the information that's really needed in a music player. And so that's what this CIP is designed to do, is just kind of define some structure extend CIP 25 with a well defined structure for something that is a music NFT, so that wallets and aggregators, and everybody can build players for the music that's in people's wallets. This was in collaboration with I think maybe 10 to 20 different individuals who are all building music type businesses on Cardano.\n\n**Andrew** -: And so we had a lot of input as to what fields were absolutely required. And so that's kind of how the CIP is broken up, is there's required fields and then there's kind of optional fields for defining what it looks like and then players, of course, they can make sure they implement it minimum, all the required fields for playing the music. And then, it again is still an open standard, so if certain music projects will add additional functionality on top of this, but it, again, doesn't need to be specified in the CIP. This is very specifically just so people can have the bare minimum to know that, yes, this is the music NFT and here's how you can play the music inside of it.\n\n**Sebastien Guillemot** -: Yeah. I think for this CIP, we could try and bike shed on the specific fields, but I think this probably will not be super useful on this versioning to help with this anyway. So I think from this one, the tricky part will be trying to measure how much backing the CIP has but as you mentioned, this was then a combination with a few projects, so it'd be good if these projects [inaudible 00:41:11].\n\n**Andrew** -: : Most of them are all signed, to contributors.\n\n**Sebastien Guillemot** -: Yeah. So I know they're all the authors, but it'd be good if they just, being just like, oh yes we're actually using this for real project of some kind. Or if you had a wallet, I know [inaudible 00:41:26] wallet included music NFTs in their wallet. So maybe it'd be good to have them.\n\n**Andrew** -: Yeah. So they're actually one of the people that is involved with this. So maybe if we can get them to comment on it, I'll talk to them about that.\n\n**Matthias** -: And this is something I would love to see in the rationale section as well. Exactly what you just explained. This is a collaborative effort between actual people building with, in the music industry, on, kind of, i don't know, the blockchain in general and that's also why we justifying some of the choices that have been made.\n**Andrew** -: Okay.\n\n**Matthias** -: That just gives a bit of context on where the decision comes from in the legitimacy of that.\n\n**Andrew** -: Okay.\n\n**Matthias** -: From a technical standpoint, just to clarify things, this is proposing to extend the on chain with the data and the set of fields that is provided alongside current NFTs from the CIP 25 right?\n\n**Andrew** -: That's correct. It supports CIP 25 version one and version two.\n\n**Matthias** -: Okay. Then should we maybe move it to last check for the next goal provided that this was already discussed with a few?\n\n**Andrew** -: Yeah. We've had several two hour meetings with people. There was 20 different groups in the room, either producing music on Cardano or representing wallets or players or things like that. So yeah, I will add to the rationale section before next meeting that this comes up.\n\n**Matthias** -: Okay. Thanks.\n\n**Andrew** -: Probably not next meeting, but maybe the meeting after, because the next meeting is always in the times I can't be at.\n\n**Matthias** -: You're right. So let's keep that in for the US based next meeting.\n\n**Andrew** -: Yep, thank you.\n\n\n### Issues\nN/A\n\n### Close \n\n**Matthias** -: So let's just wrap up quickly on what we just discussed. We've been through CIP 51 at the beginning, which we agreed to rediscuss, bring back on the table after the Vasil hard-fork has happened. Since this anyway won't happen before Vasil and further discussions are needed, then CIP 48 extended submitted data for CIP 25. The proposal was is a bit rushed out in terms of quality and format.\nSo the content itself is okay technically-wise, but there are quite a few shortcomings when it comes to how it is written. So we asked the author to fix that. CIP 30, we have agreed to just close up requests. It's been inactive for a while. The author is not responsive. I can't close it myself, unfortunately, because I'm on windows. But if any of the other auditors want to do it, please do. CIP 45 then the using pledge as a bidding program, there is some overlap with CIP 50. This is part of the broader discussions about rewards and incentives and there were concerns being raised about this actually incentivizing large pledge owners to just create more stake pools without actually impacting the decentralization of Cardano. At least not in a good way.\nThen we went through CIP 68, which we agreed to put that last check for next week and merge as proposed given that's, the technical content was, already has been through many iterations although there were a few points raised regarding this two-step beta data identifications that could perhaps, they discussed as well. So anyway, that will be a full two weeks before we go to the last check and we'll see for further updates after that. We've been through the NFT identity proposal to CIP 68, which also sounds technically okay, in the context of CIP 25, although it narrates the same shortcomings and flaws. So perhaps further discussions are needed. The format of that one is also a bit fleshed out and could deserve well, that be a bit more love and especially some more details on, well, the actual details of the CIPs. Possibly also some renaming, since this seems to be heavily inspired by the W3C recommendations, maybe could be made a bit clearer from the CIP title and finally CIP 60, the token metadata extension for music-related tokens, which comes as an extension of CIP 25 and has been a collaboration between many different individuals in the music industry around Cardano.\nIt is mainly proposing a set of 20+ new fields that are specific to music-related NFTs. And we agreed to discuss it as the last check for not the next biweekly, but one after which will be also in the US-friendly time zone. And that's it, sorry, we are four minutes beyond the clock and thank you all.\n\n\n---\n## Extra\n\n### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md)\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n© 2022 GitHub, Inc.\nTerms\nPrivacy\nSecurity\nStatus\nDocs\nContact GitHub\nPricing\nAPI\nTraining\nBlog\nAbout\n"
  },
  {
    "path": "BiweeklyMeetings/2022-09-06.md",
    "content": "**Table of Contents:** \n\n- [Summary](#summary)\n- [Editors Meeting Flow](#editors-meeting-flow)\n- [September 06 2022 Transcript](#september-06-2022-transcript)\n  * [Triage](#triage)\n    + [CIP-0049? | ECDSA and Schnorr signatures in Plutus Core](#pr250)\n    + [CIP-0037? | Dynamic Saturation based on Pledge](#pr163)\n    + [CIP-0038? | Arbitrary Script as Native Script spending conditions](#pr309)\n    + [CIP-0039? | Language annotated address](#pr310)    \n  * [Last Check](#last-check)\n    + [CIP-0060? | Music Token Metadata](#pr307)\n    + [CIP-0068? | Datum Metadata Standard](#pr225)\n  * [Review](#review) \n  * [Discussions](#discussions)\n    + [CCIP-0050? | Shelleys Voltaire decentralization update](#pr242)\n  * [Issues](#issues)\n  * [Close](#close)\n\n## Summary\n\nRough transcript of 06/09/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.  \n<sub>_Transcript might contain errors or miss pieces - call out issues as needed_\n</sub>  \nEditors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significance to you.  \n\n\n## Editors Meeting Flow\n\n**Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..  \n\n**Last Check**: Review of the PRIOR meetings Decisions  - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)  \n\n**New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  \n\nPR -> ‘Draft’: Needs format + approval.  \n‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  \n‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   \n**Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.  \n\n**Issues**: Review of the open Issues on the CIP GitHub \n\n**Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  \n\n\n## September 06 2022 Transcript\n**Attending Editors**: Matthias Benkort, Sebastien Guillemot, ~Frederic Johnson~, Robert Phair. \n**Guests**: Las Safin\n\n### Triage\n\n#### PR250\n[PR250 CIP-0049? | ECDSA and Schnorr signatures in Plutus Core](https://github.com/cardano-foundation/CIPs/pull/250)\n\n**Matthias** -: Okay. Let's start with Sebastien, and first is PR number 250, which is adding some Schnorr compatible signature to Plutus built-in to get some form of Bitcoin support or Bitcoin compatibility support into Cardano or enable some protocols to move assets from one chain to another to smart contracts. So I think this is pushed by MLabs, but in discussion with Input-Output, in particular with Michael Peyton Jones as well. So I see, Inigo has been commenting on that one for a few bits, but it's still ongoing, I think, the draft.\n\n**Matthias** -: I did a very, very sort of basic review today, and on the surface, it looks good. What's going on? Okay. So I don't have much more comment on that one. I think it's probably good to have it for review or last check for next time, given that the various points are being addressed. I would try to get more maybe buy-in from other parties, because right now most of the work is really done behind those walls between IOG and MLabs, but maybe we could get more people on board on that one.\n\n**Robert** -: You had just recently asked Michael to come back into the discussion, and I think that sounds great to just leave it on hold until we hear from him.\n\n**Matthias** -: Yeah. That was, I think, that the list I had to do. He has commented in the past and approved for the best. I think he has even co-written that. That's why. But yeah, I guess it's just an ongoing discussion happening for signing through to Schnorr, and there is maybe not much to add in the end. That is a helpful one as well.\n\n**Matthias** -: There was one thing I was missing from the rationale maybe, because they mentioned they change a bit the serialization format compared to what Bitcoin uses, which I find interesting or curious, so I will be interested in the rationale, why change the serialization format? That can create some layer of frustration between parties integrating after that. If it's nothing really stands out, then that's probably not a big issue, but yeah. Okay. So maybe we leave it as last check for the next biweekly and see if the discussion settles or not and perhaps advertise that on a few more channels or at least it's here. \n\n#### PR163\n[PR163 CIP-0037? | Dynamic Saturation based on Pledge](https://github.com/cardano-foundation/CIPs/pull/307)\n\n**Matthias** -: Next one is the dynamic saturation based on pledge. Not sure why we put this one on triage. It's a last-check item, because we've been reviewing that one for a while. I think the last time we agreed to merge it as proposed. Saying it was only missing a path to active, mentioning the last steps were now to get this idea reviewed by the IOG's research team. Important to see implementation feasibility or not. A bit like CIP 0050 and other of the like, so this has been added by the author, so I think we can just move forward with that one and merge it as planned.\n\n**Anthony**-: Yes. It seems like either you or Sebastien would just be able to put it through.\n\n**Matthias** -: Yep. Let me try that. And that one is 0062. Sorry. I have to do that on the phone. Okay. Good. And I will put a note to add it or modify it with me after the call to include that one now. I have no news on that update from IOG regarding a study group for CIP 0050 or CIP 0037 and the likes. So I will contact Kevin Hammond again to see. I think IOG is at a workshop this week, so they won't probably be much responsive, but maybe we can get some form of response.\n\n#### PR309\n[PR309 CIP-0038? | Arbitrary Script as Native Script spending conditions](https://github.com/cardano-foundation/CIPs/pull/309)\n\n**Matthias** -: Let's jump then maybe to the two CIP you proposed, Sebastien, last week or two weeks ago, since you are here. Oh, a month ago, actually. Well, quite late. So the first one, CIP 0038, competitively for request number 300-09, arbitrary script as native script spending conditions.\n\n**Sebastien** -: Yes. So basically, the problem is that Plutus scripts are not treated the same as native scripts. These are two different kinds of scripts. The reason there's a difference is because Plutus scripts require phase-two validation whereas native scripts do not. This difference makes it tricky to use Plutus scripts for a variety of reasons. And then on top of that, there's no way to specify datum when you're sending to a Plutus script. It's a totally unrelated limitation to Plutus scripts. So these two problems, as I mentioned earlier, make it really hard to basically compose protocols together in Cardano. So for example, if you're using Catalyst and you want the result of the Catalyst vote to be paid out to your DOW address, you can't do it at the moment, because you can't specify a Plutus script as the receiver of the Catalyst rewards.\n\n**Sebastien** -: So there are a few ways we can improve the situation. One of them, of course, would be getting rid of the requirements that Plutus scripts have to have datum and allowing some kind of default case. But a different way to handle this, which I think is a lot easier and also has the added benefit of getting rid of this collateral requirement in these phase-two issues, is to extend the native script functionality.\n\n**Sebastien** -: Native scripts on Cardano are how you can do basic multisig, and they have as one of their conditions the ability to say, \"Oh, you need three out of five public keys to sign this transaction.\" What we can do is extend native scripts, so you can also have similar conditions on script hashes. So you can say that, \"Oh, for this new script to pass, it needs, for example, three of five script hashes to be included in this transaction and succeed.\" So I think this will make it much easier to use native scripts to compose different protocols together without having to introduce user interface validation you have to worry about and without requiring the presence of a datum.\n\n**Matthias** -: Okay. I'm not sure to fully understand the motivations behind it, because as far as I ... I understood your main point is when you send to Plutus script, you have to send to associate also a datum with it. But surely that datum can just be an empty datum, like a unit.\n\n**Sebastien** -: No, because not every API has a way for you to even easily set the datum. For example, if you're spending through data lists, there's no way for you to add the datum in the spend page. If you're specifying an address in Catalyst, there's no way for you to tell the Catalyst team, \"Oh, yeah, and provide this datum.\" So there are a lot of cases where you can't easily provide this information.\n\n**Matthias** -: Then that's more a problem of software interface than a problem with the protocol itself, right?\n\n**Sebastien** -: Well, so the root problem is that Plutus requires a datum, there's not really any protocol needed to add this restriction, and it is something that we can remove and that I think we should remove as a separate CIP. But as you know, changing Plutus' behaviour is quite a large change in this group of things. And then even if we take this path of getting rid of this default Plutus datum behaviour, there's still a difference in functionality between native scripts and Plutus scripts. So I still think even if we had a CIP like this to get rid of the requirement, it would still make sense to provide this kind of composability feature, both as a Plutus script feature and as a native script feature.\n\n**Matthias** -: Okay. I think I will also take the time to go through the CIP. I haven't really been reviewing that one yet. I see it's had mostly comments from IOG folks. What's been the sentiment so far since Michael's and Jared's?\n\n**Sebastien** -: Yeah. Mostly the sentiment has been nobody's particularly objecting to this. People would prefer to spend the time making the Plutus change to get rid of the datum requirement. I think that's definitely something that's worth doing, but I would prefer if we had both options, especially because adding a new feature to native scripts, as we know, is very easy because we've done this in the past, whereas making a change to Plutus is more involved. And so if we only have that path, it would be also kind of delay the time it takes to add this function to the protocol.\n\n**Matthias** -: Yeah, yeah. This sounds like two separate functions in a way. I mean this would solve one problem while not necessarily preventing this to be also enhanced next to it.\n\n**Sebastien** -: Yeah, exactly. So I would like to have both. The discussion of that CIP is mostly a question of prioritisation, which one should core developers focus on first, but I think that's kind of not really the decision we need to make [inaudible 00:27:05] Mostly, this CIP is just mostly studying it. This is a good idea, if we want.\n\n**Matthias** -: Okay. Jared comments on the impact of extending any native script in that direction regarding the ledger holes and the validation that this would ensure.\n\n**Sebastien** -: I don't recall anything that was complicated about this. I looked at the code myself, and currently, we already have two native script versions because, if you remember, at some point, we added time locks, so we already have native script v1, native script v2, so it'd just be a question of adding in native script to v3 with this proposed change, and it's not a breaking change either.\n\n**Las Safin** -: Hello.\n\n**Matthias** -: Hey.\n\n**Las Safin** -:  Good day, Sebastien and Matthias. I have a few questions with regards to the CIP items. I sort of understand the motivation, because you have the whole issue. I understand the whole issue. You have a datum, and you can't really specify that datum as part of those steps, but that's partly an issue with DApps being implemented poorly and partly an issue with the UX of Cardano being bad. But I don't think this actually solves the issue, because if you have some sort of smart contract, have got funds, and you have it now, and everyone votes to send the funds to some DEX, right, and the DEX just sends the funds back.\n\n**Las Safin** -: Or imagine if it's more automated, you can actually do this, even with this native script thing, because what return address do you specify when you send the funds to the docks, not the docks, to the DEX? Well, you want the native script return address, but how do you compute that? It's a hash. Doing that on chain is certainly possible, but it's very inefficient, and I don't see how this solves the problem, myself. I think this is a problem worth solving. I thought about it myself too, but I'm not sure that native scripts are solutions to the problem. I thought maybe what about just adding datums to the address. That's a bit radical, but what are you think about this? How does this solve the problem?\n\n**Sebastien** -: So the key point is that the native script that you're creating can specify a list of scripts that are required, and scripts in Cardano don't have to be deployed on chain, right? So if you want to add extra logic, like how to handle returning something or handling an error case or whatever, you can generate what the Plutus script for that will be, take the hash of it, include that hash inside one of the native script requirements, and then use that as your native script address.\n\n**Las Safin** -: Yeah. I don't think this solves the problem actually, though. I'll give you all a convincing example. Imagine you have some fully automated thing, and I guess the presence of [inaudible 00:30:25] state machine, it does something automatically. At one point, it wants to send funds to a DEX, and the funds should go back to some other script, and the datum will depend on the current state of the state machine. Maybe we just want to send the state machine to the new script actually, and I don't see any way to do this with this mechanism, because there is no way of specifying what datum you want to send back to. Sure, of course, you can specify-\n\n**Sebastien** -: Yes, there is. So basically you create a Plutus script that takes the datum you want to return to as a parameter. Not a runtime parameter, but parameter in the construction of the script itself, like a template.\n\n**Las Safin** -: But that doesn't work, because you can't check this, you can't check this on chain. Although if you check this on chain, you have to do bit-fiddling, you have to check the content of the script, because there's no way to do the parameterisation on chain in a fully automated manner and fully trust this manner on chain, unless you do the bit-fiddling. Of course, that's certainly possible. It doesn't really solve the problem to a satisfactory level in my mind.\n\n**Sebastien** -: If you know what you want the return address to be at the time the user's generating the address, then this is not an issue. If you want to compute this dynamically, then you'll need to have some more complex interaction for this. For example, you could have the script associated instead of native script require [inaudible 00:32:08] smart contract, which then figures something else later or triggers something else later, and you have to do multiple steps. But I think this is more a question of not being able to do this in one go, and the situation you're describing will require multiple steps of execution, but I don't think that's necessarily problematic.\n\n**Las Safin** -: I mean, you're going to have the problem with necessitating multiple steps and then multiple extra transactions to do some sort of wrapping. But in this scenario, it's a very, very minor step forward, because there are very few use cases where this is actually useful, where you'd have a static return address. In almost all DApp interactions, you need to have a dynamic return where you would ... There are two issues here. You, first of all, want to ... It's like an [inaudible 00:32:58] You want to send state to the return address in the form of datum or something, but you also want the party that sends to the return address.\nFor example, the DEX sends funds to some dynamic statements being incentivised. This DEX should also be able to specify extra information. And sure, you can do that for tokens, actually, so it's not a huge problem. The problem is you're also specifying the return name. Because this doesn't really solve it, it's a very minor fix. I mean, sure you could, you could just add this and be like, \"Okay, we've solved this for one particular use case, but maybe we should think of a more general solution before going ahead with this.”\n\n**Sebastien** -: Well, this has everything we need to basically build proxy contracts for layer twos and side chains, which is the main thing that we want. If you want something more complicated, you'll have to do multiple steps, as we discussed, or you may want to use this other functionality described where we allow Plutus scripts with no datum. But the situation you were describing, I don't think it's not possible. It's tedious. It is possible if you're not-\n\n**Las Safin** -: It is impossible because of the CPU limit. It's [inaudible 00:34:14] handle the concept of the serialization of the script on chain, hash it on chain, then modify it on chain. Sure, it's possible, but it's not really the way we should go. What's wrong with just adding the datum to the address, because the datum, is actually part of the address in some sense from a semantic perspective? What about just making it part of the status life once it [inaudible 00:34:38]\n\n**Sebastien** -: You can have a script, part of the native script requirement list, and this script as part of the native script requirement list says the next transaction needs to contain an output with this datum as part of it. It's not great, I agree, but if you want to specify a datum, arbitrary datum, instead of adding this datum to the address itself, you could just encode the requirement of adding this datum as part of this native script that's embedded into the address.\n\n**Las Safin** -: I think ... Yes, but what about just adding the datum to the address? Would this solve your problems, or would it not solve your problems if we just add the datum to their address?\n\n**Sebastien** -: It would not solve the problem for our situation, but I can imagine cases where this is sufficient for them.\n\n**Las Safin** -: Why would it not solve your case? What do you seek to do? Because if you want some datum action, you just say send to this address, and you specify it as part of the address, and that datum may just an NCA [inaudible 00:36:09]\n\n**Sebastien** -: So this would solve your ... So I guess we would get into the same situation where this would solve our problem if we had multiple steps. Basically, if we did this other option you're proposing, where we had the address with the datum embedded inside the address, you would first be sent to a Plutus script, which in our case would then be a Plutus script that then requires composability within native scripts, which is what we're using. So I guess the solution you're providing solves our solution as long as we're okay with multiple steps as well on our side.\n\n**Las Safin** -: Okay. I think actually I also think of a few other more general solutions, so maybe I'll also write up some thoughts, because I think we can maybe just bring more advanced here. Because I think there's also the more general problem of parameterisation being highly non-trivial on chain, but I think we can actually make a solution where you can parameterise any hash by another hash if we change the serialisation format of pieces of it.\n\n**Sebastien** -: Yeah. So again, I think the solution you're providing falls into kind of the same bucket as the ongoing discussion inside the CIP, which is that there are multiple ways we can deal with composition. Each way has some advantages. The implementation I'm proposing is very simple and solves a certain set of issues. The version you're proposing is also interesting. It solves also some set of issues. There's no reason we can't have both, and so I don't see it as a detriment to this CIP in any way.\n\n**Las Safin** -:  Yeah. Maybe it's fine to have both. I mean, the one question I didn't actually say my answer, it says requires, so does that mean it can be anyone in the script cons? Can it be a state validator, mainly policy, a validator can be anything, or does it have to be something specific?\n\n**Sebastien** -: Yeah, that's a good point. We might want to add extra functionality for you to be able to insert more about where the script hash is. I'm not sure if we want to go that far, because I feel like this kind of goes down a rabbit hole of adding too much functionality. It's meant to be fairly simple. So I would say it is just any script that's part of the transaction.\n\n**Las Safin** -: That's fine. I think that's fine. My concerns are over. I think this CIP to step forward and it's certainly useful, but I think we should also think of a more general solution from what [inaudible 00:39:29]\n\n**Sebastien** -: Yeah, I agree. I think we should definitely increase composability in multiple different ways to handle multiple situations.\n\n**Las Safin** -: Right, thank you.\n\n#### PR310\n[PR310 CIP-0039? | Language annotated address](https://github.com/cardano-foundation/CIPs/pull/310)\n\n**Sebastien** -: And on a related note, we have a second CIP that's also proposed by me that's also partially related to this one and partially related to the discussion we just had, which is CIP 0039 for language annotated addresses, which basically says that right now addresses in Cardano, you can't tell the difference between a native script and a Plutus script. But CIP 0039 tries to set a standard for being able to differentiate between script kinds.\n\n**Sebastien** -: There's two ways that can be implemented. It can be implemented as a purely off-chain construct, and the blockchain itself has no knowledge of this difference, or we could go all the way and implement this as an on-chain construct. The discussion inside the CIP is mostly people talking about how they prefer to have this as an on-chain construct, but there is no clear way to make this an on-chain construct that really works for everybody. And so that's kind of the summary of this discussion.\n\n**Matthias** -: So are you proposing to extend the address type to have new types that can now carry a script in the space?\n\n**Sebastien** -: Yeah, that's the basic idea. So basically, we extend the existing address format on Cardano to annotate them to include the script type used inside the address. But as you know, the addresses are parsed by wallets and these things are not necessarily on chain, and so you could have the wallets take an address, use it to assert the script type, and then strip the script type information to submit that off-chain. I assume that part on chain. So that's how you implement the CIP without having to make any changes to the blockchain itself, which I think is more like the first implementation because trying to change the on-chain format of access is one, complicated, and two, there's really no good way to have the chain really enforce script types.\n\n**Matthias** -: But this is kind of the nature of my questions because you have two options also regarding your address. You can either modify the existing types or add new types that will include scripts, which means that you will still have the ability to use the old address type that does not include the script namespace. So I think this makes it slightly easier to implement in a non-breaking manner.\n\n**Sebastien** -: And I said this back in the CIP. So basically, there are two ways. There's one way of allocating new types, like the [inaudible 00:43:08] numbers, and the other way is to extend the existing types. We can extend the existing types without introducing a new number in the header, and this will work except for pointer addresses. The reason why is, because if you change the existing types, you can differentiate between them based on the length of the address. If it's one length, it's one standard. If it's another length, it's a different standard. This doesn't work for pointer addresses, because they have an undefined length, so there's not really a good way to parse them.\n\n**Matthias** -: Maybe there is a CIP to make here to suggest the removal of pointer addresses, since I think we are amongst the two individuals that have been using them on the chain, the only two. So yeah, that will simplify a bit the things. Okay. Should we get that CIP for review next week? Is the discussion still ongoing? Or I see mostly happened months ago, but no, no-\n\n**Sebastien** -: No, I don't think there's any ongoing discussion anymore. I think everybody has said their thoughts on the proposed path. I think some of the stuff has not been decided for the CIP 0039, the language annotated addresses. Michael Peyton Jones and Jared wanted to try and figure out how we can make this an on-chain construct that is actually validated by the blockchain itself. But then you need some way for the blockchain to know ahead of time whether not an address is a native script or a Plutus script. Or the other option is that if you don't validate this ahead of time, but then if somebody sends to the wrong script type, they can never spend from it, which is also not great.\n\n**Matthias** -: So it could be done fully optionally. So if you specify a type and you provide the script part of the transaction, then the ledger validates it. And if it doesn't validate, then it fails. So as a client, you have a way to sort of enforce that there is a ledger validation on top, but if you don't provide it, then yes, the ledger has no way to validate it. Then it's just blindly accepts it, like it does now.\n\n**Sebastien** -: Yeah. And the question is whether not this validation should have been when you send to the address or when you spend from the address.\n\n**Matthias** -: Well, I would say if you can do it when you send to the address, that's where the interest is at this stage, because that's where I think it can happen right now.\n\n**Sebastien** -: Yeah. That was my preference as well. Michael Peyton Jone's preferred to do the validation when you spend from the address.\n\n**Matthias** -: When you spend from it, you can always do it, because you have the script at this stage. But then what happens if you have sent to an address which has a mismatch between the type and the actual script, you are just locked forever.\n\n**Sebastien** -: Yeah. That's Michael Peyton Jones's suggestion.\n\n**Matthias** -: Okay. That's an interesting suggestion.\n\n**Sebastien** -: Yeah. I prefer to avoid people accidentally potentially locking funds forever, if possible, which is why I'm not the biggest fan of that proposal, but also, I understand that the chance that you get this wrong, you send the wrong script type, is also fairly small. It's not the biggest concern, but I think figuring out which validation we will take if we make this an on-chain construct is the main thing that needs to be decided. But if we're in disagreement about the way we want to do the validation, but we're in agreement on the binary format of this, then we can just make this CIP be the off-chain standard only, and then have another discussion about how to do any on-chain validation in the future.\n\n**Matthias** -: I don't quite see the benefits of doing on-chain validation after the fact on this, because this is really a feature to prevent people from shooting themselves in the foot, and now we are just giving them one more way of doing that if we do the validation after the fact. So if it's purely informative for wallets and applications downstream to be able to identify whether or not a certain asset is locked behind a Plutus script or a native script, then I don't see what validations would add on top.\n\n**Sebastien** -: Yeah. I 100% agree with you.\n\n**Matthias** -: Okay. Maybe to move that CIP forward then is to also decide on how you want to implement that between the off-chain or on-chain. And perhaps it can start, as you said, off chain, having wallets already recognising that format, using it, but stripping the parts when actually submitting things on chain. I think that will be quite hard to get adoption across the entire ecosystem in a way, because now you will also get some discrepancies. Some wallets will show an address, and an explorer might show a slightly different address, which might be very confusing for people. So my own preference would be to have that enforced on chain fully, even if there is no validation or extra validation done yet on top of it. That wouldn't be worse than the current status quo, and then we can take a bit more time to think about how we want to validate that if we want to validate it. That's my thoughts, yeah.\n\n**Matthias** -: Regarding the implementability of that CIP, did you discuss that with Jared also on the PR?\n\n**Sebastien** -: Nothing beyond validation rules.\n\n**Matthias** -: Okay, because I imagine if it's just adding new addresses, it should be pretty straightforward implementation-wise, as it's just extending an existing sum type basically. And yeah, it doesn't introduce new validation logic in that sense. It's just a script address that carries some additional information with it. But yeah, that would be to discuss. I will make a more formal review also after the call, adding some comments on itself. And let's see. Let's have it for either review for next biweekly. See if we can get more insights from the core team as to whether this is implementable and what the plan is.\n\n\n### Last Check\n\n#### PR307\n[PR307 CIP-0060? | Music Token Metadata](https://github.com/cardano-foundation/CIPs/pull/307)\n\n**Matthias** -: Last check, also, we have CIP 0060, Music Token Metadata, which we reviewed last time. I think we had a few minor comments which were addressed, that it seems. Okay, yes, we're going to need to change the tips, sadly, change the time zone as it's my bad. I suggested to change the type to processes, but it's actually process. I believe that there's no type of ... We can probably do it ourselves. Far as I'm concerned, this one is also good to go. Any comments, Sebastien or Robert?\n\n**Robert** -: I think since they chose all of their metadata items based on meetings that they already had, that part of it seems complete. They also in the discussion thread answered some questions about the scope of the proposal, so I really don't see that there's anything else to do with this other than merge it. That's already the outcome of their own consensus, their media group.\n\n**Matthias** -: Yeah, exactly, exactly. So it's nice of them to actually put that in paper and record it. And well, I still have reasons to, regarding CIP 0025, but since this one is based on safety, 0025 acts as an extension of it. But that's something which is a bit off-topic here. So I would approve, but under the condition that we change the processes, I mean the type from process to process. I think we can do it, unless Andrew Givens has prevented commit from his branch. If he did, then I think he would just modify it. That'd be fine. And also the status, we need to change it to proposed.\n\n**Matthias** -: What would be the best to active in that one, I guess, some of those parties used the CIP. So if this is already in use, maybe we can even merge it as active right away. Also, that doesn't [inaudible 00:13:14]. I'm just commenting on the branch. Maybe if you want to move to the next one, which is CIP 0068.\n\n#### PR225\n[PR225 CIP-0068? | Datum Metadata Standard](https://github.com/cardano-foundation/CIPs/pull/225)\n\n**Robert** -: We don't have any of the CIP 0068 participants here today on the guest list, it looks like.\n\n**Matthias** -: No. They are US based, so they are unlikely to join today.\n\n**Robert** -: Oh, on the wrong time zone.\n\n**Matthias** -: Yeah.\n\n**Anthony**-: So if everybody's happy, I will leave CIP 0068 in the agenda for the US time zone meeting next week.\n\n**Matthias** -: No, no. CIP 0060.\n\n**Anthony**-: CIP 0060. Apologies.\n\n**Matthias** -: Oh, CIP 0060, I think we will be able to merge it after the call once we have done just the two changes we mentioned, fix the type and change the status to either proposed or active, depending on whether or not this CIP is already used by these artists, music industry companies, which is what I'm capturing on the pro-request comments. But I was simply suggesting maybe to move to CIP 0068 in the meantime.\n\n**Sebastien** -: Keep in mind that for CIP 0068, it depends on CIP 0067, which had a non-trivial update last week.\n\n**Matthias** -: CIP 0067, the label registry, right?\n\n**Sebastien** -: Yeah.\n\n**Matthias** -: Yes. So you want to work us through that bit, Sebastien?\n\n**Sebastien** -: To be honest, I haven't had the time to read through it all.\n\n**Matthias** -: Okay. So should we keep then CIP 0067 for review for the next bi-weekly call and CIP 0068 in the meantime, because they both go hand-in-hand, basically? Is that what you're suggesting?\n\n**Robert** -: Yes. For the USA-friendly time zone, that sounds like it would yield a better discussion.\n\n**Matthias** -: Yeah. I think CIP 0068. It's mostly European folks behind it in spots.\n\n**Sebastien** -: Yeah, I don't think the US time zone quite particularly helped for CIP 0068. I have no issues as it is, but my comment last time, other than seeing whether or not it gets any adoption, it's just the main thing. Just love to see if CIP 0067 had some changes, but I'll need to review it. But for 0068, I have no issue with it.\n\n**Matthias** -: Sorry. I just finished commenting on this one, so CIP 0068, we'll keep it as review for the next meeting, part with CIP 0067 first to make sure-\n\n**Sebastien** -: [inaudible 00:17:58]\n\n**Matthias** -: What? Sebastien, you said something or ...\n\n**Anthony**-: Yeah, I'm also struggling to pick up on Sebastien's line.\n\n**Sebastien** -: I was saying, Matthias, he is really quiet for me. Is he quiet for anybody else?\n\n**Anthony**-: He's not that quiet from my side, no, but Sebastien, your volume and clarity has just improved quite a lot for me.\n\n**Matthias** -: I try to increase my volume maybe a bit, Sebastien.\n\n**Sebastien** -: Way better, way better.\n\n**Matthias** -: Okay, good. So I was just saying CIP 0067 and CIP 0068 for review for next time. We'll go through CIP 0067. There is, I think, already quite some discussions happening on this one, although it's happening in various places. So yeah, probably they've got enough attention. We don't necessarily need to bring more people into the discussion, particularly CIP 0068, which has been going over a lot in a lot of chats. Yeah, okay. So I'll keep them for next time then.\n\n### Review \n### Discussions\n\n#### PR242\n[PR242 CCIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242)\n\n\n**Matthias** -: Okay. So I would say we have about 10 minutes left, so that gives us a bit of time to go through maybe CIP 0050 and some updates on the discussions there. I haven't been following the latest items on that, so I'm not sure if any individual has. Robert, maybe.\n\n**Anthony**-: I'm not getting any audio from Robert. Is it just me?\n\n**Matthias** -: Yes, I do hear you, Robert, but I think Anthony doesn't.\n\n**Robert** -: ... there was hope for, because it's been up for so long, it's become a magnet for proposals that are similar that are coming in and out of the CIP 0050 thread. So there has been commentary, but not really about CIP 0050 itself.\n\n**Matthias** -: I think it was a bit the goal of CIP 0050 also to become the hive mind, as Michael calls it, right, [inaudible 00:53:46].\n\n**Robert** -: Yes.\n\n**Matthias** -: Welcome discussions on incentives, rewards, and how to do better with an initial proposal, but not necessarily the finite proposal, being CIP 0050. I mean, it will be eventually, but it might be vastly different from what was initially submitted. I think that was kind of the idea.\n\n**Robert** -: Yes. And one of those that we just recently merged without the meeting was sort of a really quick and dirty way of dealing with the problem just by a linear relationship between pledge and saturation, something that would work for some centralisation cases, but allow others. So I think we're still looking for something that is going to deal with the civil attack problem and the centralisation problem, all in a nutshell. It's a bit like the grand unified field theory. Everyone has an idea how to tackle a different part of it, but it's hard to put the whole thing together. So since the author is a scientifically rigorous person, it seems to be a theory that hasn't promoted any particular practical application yet. People are still talking about different ways of doing it.\n\n**Matthias** -: Also, new participants in the discussions recently, which is interesting. Okay. So I guess we'll also need to go through a bit about the discussion that happened on GitHub, and also this call, try to make a summary for next time and see. And as I said earlier in the call today, I need to reach out against you, Kevin Hammond from IOG, to see if we can get any more attention from IOG researchers. It would be very nice to get more collaboration on that in an ongoing effort with milestones and actually actionable items a bit. I guess they have Vasil now plans to be held out for September 22nd, so that kind of topic should be next on the pipeline, hopefully.\n\n### Issues\nN/A\n\n### Close \n\n**Matthias** -: Okay. I think it's a good time to wrap up maybe. So I will try to do that. Let me pull back the agenda. Yes, we've been through CIP 0049, candidate CIP, which is adding two new primitives to Plutus to verifying Schnorr and ECDSA signatures, which would bring some form of Bitcoin compatibility into Cardano. It's been mostly discussed by IOG and MLabs. It's in good shape, so we'll have it next time for review and last check.\n\nThen we've finally merged CIP 0037 as proposed, although this is a CIP that falls in the same category as CIP 0050, discussing rewards and incentives. For Cardano, it has different pros and cons as discussed in CIP 0050. So this was more a way to put the closure on that discussion on CIP 0037 to also move it more to the more general CIP 0050 discussion.\n\nThen we've had a last look at CIP 0060 for the music token metadata, which was already reviewed, discussed, and it was really just a last sanity check. We agreed to merge it. We fixed the typo in the type and changed the status to either proposed or active, depending on whether or not industry members are already using it extensively.\n\nWe've postponed the discussion on CIP 0068, because it needs to go hand in hand with CIP 0067, and we haven't really got enough time to go through that CIP 0067 recent update. So we'll have both as review for next week, sorry, for the next meeting I mean.\nWe have discarded CIP 0045 and CIP 0066 from the discussion from the agenda today, because there have not been any substantial updates since last time we discussed them, and we instead looked at CIP 0038 and CIP 0039, which sparked an interesting discussion during the meeting and specifically on how do we maybe improve a bit the overall UX surrounding scripts on Cardano and, in particular, how do we prevent users from shooting themselves in the foot when sending to script addresses.\n\nSo CIP 0038 proposed one way to alleviate some of the problems or some of the difficulty that there is currently with the usage of Plutus scripts and datums. The discussion was now to move forward, we wanted to make a decision on how we want to enforce that, on chain or off chain. On chain, meaning that this requires some buy-in also from the core teams to implement.\n\nCIP 0039, which is more on the side of addresses and how do we improve address. Sorry, I mixed them both. So on chain versus off chain discussions is on CIP 0039, and CIP 0038 was about the extension of the native script to introduce validation of Plutus scripts as the next type constraint, possibly many if combined with the existing primitives of the native scripts.\nI think that was it. So thank you all for joining and see you in two weeks.\n\n**Sebastien** -: Thank you.\n\n**Anthony**-: Thank you, everybody. Just a short note, Matthias, that the next CIP will take place next week, just because this was a delayed CIP.\n\n**Matthias** -: Okay, sorry.\n\n**Anthony**-: Okay. No, just to clarify.\n\n**Matthias** -: Next week then.\n\n**Anthony**-: All right. Thank you.\n\n**Matthias** -: Cheers.\n\n\n---\n## Extra\n\n### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md)\n\n:bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).\n\n\n### CIP creation process as a Sequence Diagram  \n\n_\"Alice has a Cardano idea she'd like to build more formally\":_\n![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true \"sequence_diagram.png\")\n\n### Understanding CIPs further\n\n[![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)\n[![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)\n© 2022 GitHub, Inc.\nTerms\nPrivacy\nSecurity\nStatus\nDocs\nContact GitHub\nPricing\nAPI\nTraining\nBlog\nAbout\n"
  },
  {
    "path": "CIP-0001/CIP-0001.md",
    "content": "Moved to [CIP-0001/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0001/README.md",
    "content": "---\nCIP: 1\nTitle: CIP Process\nCategory: Meta\nStatus: Active\nAuthors:\n    - Frederic Johnson <frederic@advanceweb3.com>\n    - Sebastien Guillemot <sebastien@dcspark.io>\n    - Matthias Benkort <matthias.benkort@cardanofoundation.org>\n    - Duncan Coutts <duncan.coutts@iohk.io>\n    - Michael Peyton Jones <michael.peyton-jones@iohk.io>\n    - Robert Phair <rphair@cosd.com>\nImplementors: N/A\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/366\n    - https://github.com/cardano-foundation/CIPs/pull/331\n    - https://github.com/cardano-foundation/CIPs/tree/3da306f3bfe89fa7de8fe1bf7a436682aeee25c5/CIP-0001#abstract\n    - https://github.com/cardano-foundation/CIPs/pull/924\nCreated: 2020-03-21\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nA Cardano Improvement Proposal (CIP) is a formalised design document for the Cardano community and the name of the process by which such documents are produced and listed. A CIP provides information or describes a change to the Cardano ecosystem, processes, or environment concisely and in sufficient technical detail. In this CIP, we explain what a CIP is, how the CIP process functions, the role of the CIP Editors, and how users should go about proposing, discussing, and structuring a CIP.\n\nThe Cardano Foundation intends CIPs to be the primary mechanisms for proposing new features, collecting community input on an issue, and documenting design decisions that have gone into Cardano. Plus, because CIPs are text files in a versioned repository, their revision history is the historical record of significant changes affecting Cardano.\n\n## Motivation: why is this CIP necessary?\n\nCIPs aim to address two challenges mainly:\n1. The need for various parties to agree on a common approach to ease the interoperability of tools or interfaces.\n2. The need to propose and discuss changes to the protocol or established practice of the ecosystem.\n\nThe CIP process does not _by itself_ offer any form of governance. For example, it does not govern the process by which proposed changes to the Cardano protocol are implemented and deployed. Yet, it is a crucial, community-driven component of the governance decision pipeline as it helps to collect thoughts and proposals in an organised fashion. Additionally, specific projects may choose to actively engage with the CIP process for some or all changes to their project.\n\nThis document outlines the technical structure of the CIP and the technical requirements of the submission and review process.  The history, social features and human elements of the CIP process are described the [CIP repository Wiki][Wiki].\n\n## Specification\n\n### Table of Contents\n\n- [Document](#document)\n  - [Structure](#structure)\n    - [Header Preamble](#header-preamble)\n    - [Translations](#translations)\n    - [Repository Organization](#repository-organization)\n    - [Versioning](#versioning)\n    - [Licensing](#licensing)\n  - [Statuses](#statuses)\n    - [Status: Proposed](#status-proposed)\n    - [Status: Active](#status-active)\n    - [Status: Inactive](#status-inactive)\n  - [Path to Active](#path-to-active)\n  - [Categories](#categories)\n  - [Project Enlisting](#project-enlisting)\n- [Process](#process)\n  - [1. Early Stage](#1-early-stages)\n    - [1.a. Authors open a pull request](#1a-authors-open-a-pull-request)\n      - [Naming CIPs with similar subjects](#naming-cips-with-similar-subjects)\n    - [1.b. Authors seek feedback](#1b-authors-seek-feedback)\n  - [2. Editors' role](#2-editors-role)\n    - [2.a. Triage in bi-weekly meetings](#2a-triage-in-bi-weekly-meetings)\n    - [2.b. Reviews](#2b-reviews)\n  - [3. Merging CIPs in the repository](#3-merging-cips-in-the-repository)\n  - [4. Implementors work towards Active status following their 'Implementation Plan'](#4-implementors-work-towards-active-status-following-their-implementation-plan)\n- [Editors](#editors)\n  - [Missions](#missions)\n  - [Reviews](#reviews)\n  - [Nomination](#nomination)\n\n### Document\n\n#### Structure\n\nA CIP is, first and foremost, a document which proposes a solution to a well-defined problem. Documents are [Markdown][] files with a _Preamble_ and a set of pre-defined sections. CIPs authors must abide by the general structure, though they are free to organise each section as they see fit.\n\nThe structure of a CIP file is summarised in the table below:\n\nName                                            | Description\n---                                             | ---\nPreamble                                        | Headers containing metadata about the CIP ([see below](#header-preamble)).\nAbstract                                        | A short (\\~200 word) description of the proposed solution and the technical issue being addressed.\nMotivation: why is this CIP necessary?          | A clear explanation that introduces a proposal's purpose, use cases, and stakeholders. If the CIP changes an established design, it must outline design issues that motivate a rework. For complex proposals, authors must write a [Cardano Problem Statement (CPS) as defined in CIP-9999][CPS] and link to it as the `Motivation`.\nSpecification                                   | The technical specification should describe the proposed improvement in sufficient technical detail. In particular, it should provide enough information that an implementation can be performed solely based on the design outlined in the CIP. A complete and unambiguous design is necessary to facilitate multiple interoperable implementations. <br/><br/>This section must address the [Versioning](#versioning) requirement unless this is addressed in an optional Versioning section.<br/><br/> If a proposal defines structure of on-chain data it must include a CDDL schema.\nRationale: how does this CIP achieve its goals? | The rationale fleshes out the specification by describing what motivated the design and what led to particular design decisions. It should describe alternate designs considered and related work. The rationale should provide evidence of consensus within the community and discuss significant objections or concerns raised during the discussion. <br/><br/>It must also explain how the proposal affects the backward compatibility of existing solutions when applicable. If the proposal responds to a [CPS][], the 'Rationale' section should explain how it addresses the CPS and answer any questions that the CPS poses for potential solutions.\nPath to Active                                  | Organised in two sub-sections (see [Path to Active](#path-to-active) for detail):<br/><h5>Acceptance Criteria</h5>Describes what are the acceptance criteria whereby a proposal becomes _'Active'_.<br/><h5>Implementation Plan</h5>Either a plan to meet those criteria or `N/A` if not applicable.\n_optional sections_                             | May appear in any order, or with custom titles, at author and editor discretion:<br/>**Versioning**: if [Versioning](#versioning) is not addressed in Specification<br/>**References**<br/>**Appendices**<br/>**Acknowledgements**\nCopyright                                       | The CIP must be explicitly licensed under acceptable copyright terms ([see below](#licensing)).\n\n> [!NOTE]\n> Each of these section titles (*Abstract* onward) should be an H2 heading (beginning with markdown `##`).  Subsections like _Versioning_ or _Acceptance Criteria_ should be H3 headings (e.g. `### Versioning`).  Don't include a H1 title heading (markdown `#`): for web friendly contexts, this will be generated from the Preamble.\n\n##### Header Preamble\n\nEach CIP must begin with a YAML key:value style header preamble (also known as _front matter data_), preceded and followed by three hyphens (`---`).\n\nField          | Description\n---            | ---\n`CIP`          | The CIP number (without leading 0), or \"\\?\" before being assigned\n`Title`        | A succinct and descriptive title.  If necessary, use a `-` delimiter to begin with an applicable classification (see [Naming CIPs with similar subjects](#naming-cips-with-similar-subjects)).  Don't use backticks (<code>`</code>) in titles since they disrupt formatting in other contexts.\n`Category`     | One of the editorially accepted [categories](#categories) covering one area of the ecosystem.\n`Status`       | Proposed \\| Active \\| Inactive (.._reason_..)\n`Authors`      | A list of authors' real names and email addresses (e.g. John Doe <john.doe@email.domain>)\n`Implementors` | A list of implementors committed to delivering an implementation of the proposal, when applicable. `N/A` when not applicable and `[]` when there's currently no implementor.\n`Discussions`  | A list of links where major technical discussions regarding this CIP happened. Links should include any discussion before submission, and _must_ include a link to the pull request that created the CIP and any pull request that modifies it.\n`Solution-To`  | A list of [CPS][] that this CIP addresses, if any. Omitted when not applicable.\n`Created`      | Date created on, in ISO 8601 (YYYY-MM-DD) format\n`License`      | Abbreviation of an approved license(s)\n\nFor example:\n\n```yaml\n---\nCIP: 1\nTitle: CIP Process\nCategory: Meta\nStatus: Active\nAuthors:\n    - Frederic Johnson <frederic.johnson@cardanofoundation.org>\n    - Sebastien Guillemot <sebastien@dcspark.io>\n    - Matthias Benkort <matthias.benkort@cardanofoundation.org>\n    - Duncan Coutts <duncan.coutts@iohk.io>\nImplementors: N/A\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/366\nCreated: 2020-03-21\nLicense: CC-BY-4.0\n---\n```\n\nEspecially because Markdown link syntax is not supported in the header preamble, labels can be added to clarify list items; e.g.:\n```yaml\nDiscussions:\n    - Original-PR: https://github.com/cardano-foundation/CIPs/pull/366\n```\n\n> [!TIP]\n> A reference template is available in [.github/CIP-TEMPLATE.md][CIP-TEMPLATE.md]\n\n##### Repository Organization\n\nA CIP must be stored in a specific folder named after its number (4-digit, left-padded with `0`) and in a file called `README.md`. Before a number is assigned, a placeholder folder name should be used (e.g. `CIP-my-new-feature`). After a number has been assigned, rename the folder.\n\nAdditional supporting files (such as diagrams, binary specifications, dialect grammars, JSON schemas etc.) may be added to the CIP's folder under freely chosen names.\n\nFor example:\n\n```\nCIP-0010\n├── README.md\n├── registry.json\n└── registry.schema.json\n\n```\n\n##### Translations\n\nWhile CIPs are mainly technical documents meant to be read primarily by developers -- and thus often written in English; some may be translated into various languages to increase their outreach. Any file in a CIP folder may also include translated content satisfying the following rules:\n\n- Any translated file shall share a common basename with its original source.\n\n- Translation file basenames must have a suffix using an [ISO 639-1](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) language code, separated by a dot `.` character. (e.g. `README.fr.md`).\n\n- When no language code is provided as suffix, the default language for the document is assumed to be English (UK/US).\n\n- Translated CIPs (i.e. `README` files), must not include the original preamble. They must, however, include the following preamble as yaml frontmatter data:\n\nField          | Description\n---            | ---\n`CIP`          | The CIP number (without leading 0)\n`Source`       | The canonical GitHub link to the original CIP document\n`Title`        | A translation of the CIP's title\n`Revision`     | Whenever possible, the commit hash (7 first hex-digits, e.g. `12ab34c`) of the source in the main repository. If the source was not committed to the main repo, use the best known translation date in ISO format (if unknown, use the date posted in the translation's PR branch).\n`Translators`  | A list of translators names and email addresses (e.g. `John Doe <john.doe@email.domain>`)\n`Language`     | An [ISO 639-1](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) code of the target language (e.g. `fr`)\n\n- Translated CIPs inherit the same licensing terms as their original sources.\n\n##### Versioning\n\nCIPs must indicate how the defined Specification is versioned.  **Note** this does not apply to the CIP text, for which annotated change logs are automatically generated and [available through the GitHub UI](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/viewing-and-comparing-commits/differences-between-commit-views) as a history of CIP files and directories.\n\nAuthors are free to describe any approach to versioning that allows versioned alterations to be added without author oversight.  Stipulating that the proposal must be superseded by another is also considered to be valid versioning.\n\nA single Versioning scheme can be placed either as a subsection of the Specification section or in an optional Versioning top-level section near the end.  If the Specification contains multiple specification subsections, each of these can have a Versioning subsection within it.\n\n##### Licensing\n\nCIPs are licensed in the public domain. More so, they must be licensed under one of the following licenses. Each new CIP must identify at least one acceptable license in its preamble. In addition, each license must be referenced by its respective abbreviation below in the _\"Copyright\"_ section.\n\n| Purpose             | Recommended License                                                                    |\n| ---                 | ---                                                                                    |\n| For software / code | Apache-2.0 - [Apache License, version 2.0][Apache-2.0]                                 |\n| For documentation   | CC-BY-4.0 - [Creative Commons Attribution 4.0 International Public License][CC-BY-4.0] |\n\n> [!WARNING]\n> All licenses not explicitly included in the above lists are not acceptable terms for a Cardano Improvement Proposal unless a later CIP extends this one to add them.\n\n#### Statuses\n\nCIPs can have three statuses: `Proposed`, `Active` or `Inactive`. [The CIP Process section](#process) highlights how CIPs move through these statuses; no CIP should be given one of these statuses without satisfying the criteria described here below.\n\n> [!NOTE]\n> There is no \"draft\" status: a proposal which has not been merged (and hence exists in a PR) is a draft CIP. Draft CIPs should include the status they are aiming for on acceptance. Typically, but not always, this will be _'Proposed'_.\n\n##### Status: Proposed\n\nA _'Proposed'_ CIP is any CIP that meets the essential CIP criteria but is not yet _'Active'_. The criteria that must meet a CIP to be merged as _'Proposed'_ are:\n\n- It must contain all the sections described in [Structure](#structure).\n- The quality of the content must be to the Editors’ satisfaction. That means it must be grammatically sound, well-articulated and demonstrates noticeable efforts in terms of completeness and level of detail.\n- Its technical soundness should have been established. Where necessary, this may require review by particular experts and addressing their concerns. Note that the requirement is that the proposal makes sense (i.e. be technically sound), yet no consulted experts need to think it is a good idea.\n- It must have a valid [Path to Active](#path-to-active) as defined below.\n\n##### Status: Active\n\nAn _'Active'_ CIP has taken effect according to the criteria defined in its _'Path to Active'_ section. Said differently, each CIP defines by which criteria it can become _'Active'_ and those criteria are included in the review process. Exact criteria thereby depends on the nature of the CIP, typically:\n\n- For CIPs that relate to particular projects or pieces of technology, it becomes _'Active'_ by being implemented and released;\n- For changes to the Cardano protocol, a CIP becomes _'Active'_ by being live on the Cardano mainnet within one or more implementations;\n- For ecosystem standards, it means gaining sufficient and visible adoption in the community.\n- It must have a valid [Path to Active](#path-to-active) as defined below: even the CIP is already acknowledged as `Active` or being documented retroactively (after acceptance and implementation).\n\nA proposal that is _'Active'_ is considered complete and is synonymous with \"production readiness\" when it comes to the maturity of a solution. _'Active'_ CIPs will not be updated substantially (apart from minor edits, proofreading and added precisions). They can, nevertheless, be challenged through new proposals if need be.\n\n##### Status: Inactive\n\nAn _'Inactive'_ CIP describes any proposal that does not fit into the other types. A CIP can therefore be _'Inactive'_ for various reasons (e.g. obsolete, superseded, abandoned). Hence the status must indicate a justification between parentheses; for example:\n\n```\nStatus: Inactive (superseded by CIP-0001)\n```\n\n#### Path to Active\n\nThis must be subdivided into two sub-sections:\n\n  - _'Acceptance Criteria'_\n\n    This sub-section must define a list of criteria by which the proposal can become active. Criteria must relate to observable metrics or deliverables and be reviewed by editors and project maintainers when applicable. For example: \"The changes to the ledger rules are implemented and deployed on Cardano mainnet by a majority of the network\", or \"The following key projects have implemented support for this standard\".\n\n  - _'Implementation Plan'_\n\n    This sub-section should define the plan by which a proposal will meet its acceptance criteria, when applicable. More, proposals that require implementation work in a specific project may indicate one or more implementors. Implementors must sign off on the plan and be referenced in the document's preamble.\n\n    In particular, an implementation that requires a hard-fork should explicitly mention it in its _'Implementation Plan'_.\n\n> [!NOTE]\n> The statuses of `Proposed` and `Active` _both_ require a _Path to Active_ section, making this a _required_ section for all viable proposals.  Even if a CIP is edited or submitted with an `Inactive` status, it may still be helpful to have a `Path to Active` if there are conditions that might lead to its acceptance or implementation.\n\n#### Categories\n\nCIPs are classified into distinct categories that help organise (and thus, find) them. Categories are meant to be flexible and evolve as new domains emerge. Authors may leave the category as `?` should they not be sure under which category their proposal falls; editors will eventually assign one or reject the proposal altogether should it relate to an area where the CIP process does not apply.\n\nSubmissions can be made to these categories whenever relevant, without following any particular submission guidelines:\n\nCategory | Description\n---      | ---\nMeta     | Designates meta-CIPs, such as this one, which typically serve another category or group of categories\nWallets  | For standardisation across wallets (hardware, full-node or light)\nTokens   | About tokens (fungible or non-fungible) and minting policies in general\nMetadata | For proposals around metadata (on-chain or off-chain)\nTools    | A broad category for ecosystem features not falling into any other category\n\nAdditionally, representatives of ecosystem categories may explicitly _enlist_ their categories (see next section) to suggest a closer relationship with the CIP process. The following categories are confirmed as enlisted according to CIPs which define that relationship:\n\nCore Category | Description\n---           | ---\nPlutus        | Changes or additions to Plutus, following the process described in [CIP-0035][]\nLedger        | For proposals regarding the Cardano ledger, following the process described in [CIP-0084][]\n\nThese tentatively enlisted categories await CIPs to describe any enlistment relationship:\n\nCore Category  | Description\n---            | ---\nConsensus      | For proposals affecting implementations of the Cardano Consensus layer and algorithms\nNetwork        | Specifications and implementations of Cardano's network protocols and applications\n\n#### Project Enlisting\n\nProject representatives intending to follow an \"enlisted\" category above agree to coordinate with related development by sharing efforts to review and validate new proposals.\nIt should be noted that single organisations can no longer represent any ecosystem or development category, which makes these enlistment guidelines both decentralised and cooperative, including whenever possible:\n\n- allocating time to **review** proposals from actors of the community when solicited by editors (i.e. after one first round of reviews);\n- defining additional rules and processes whereby external actors can engage with their project as part of the CIP process;\n- defining boundaries within their project for which the CIP process does apply;\n- establishing points of contact and any designated reviews for a category;\n- agreeing upon how proposals move from the state of idea (i.e. CIP) to actual implementation work;\n- writing CIPs for significant changes introduced in their projects when it applies.\n\nAny guidelines for this cooperation should be described by a dedicated CIP whenever possible.  When such a CIP is posted or supersedes another one, it will be entered into the above table in the Categories section.  Participants of enlisted categories should follow the requirements outlined in that CIP and should update such proposals whenever these requirements or relationships change.\n\n> [!WARNING]\n> A positive review by any enlisted project representative does not constitute a commitment to implement the CIP. It is still the CIP author's responsibility to create an implementation plan and identify implementors.\n\nEditors occasionally invite representatives from enlisted categories to speak during review meetings and solicit them for ultimate approvals of proposals in their area of expertise.\n\n**Note** Optionally, projects may show their enlisting using the following badge on their introductory README: ![https://github.com/cardano-foundation/CIPs](https://raw.githubusercontent.com/cardano-foundation/CIPs/master/.github/badge.svg)\n>\n> ```md\n> ![https://github.com/cardano-foundation/CIPs](https://raw.githubusercontent.com/cardano-foundation/CIPs/master/.github/badge.svg)\n> ```\n\n### Process\n\n#### 1. Early stages\n\n##### 1.a. Authors open a pull request\n\nProposals must be submitted to the [cardano-foundation/CIPs][Repository] repository as a pull request named after the proposal's title. The pull request title **should not** include a CIP number (and use `?` instead as number); the editors will assign one. Discussions may precede a proposal: early reviews and discussions streamline the process down the line.\n\nPRs should not contain commits that also appear in other repository PR's: usually the consequence of re-using a branch in your fork or submitting your work from your fork's `master` branch.  To avoid this, please:\n- Don't submit your PR from your fork's `master` branch.\n- Create a new branch for every pull request that you intend to submit.\n\n> [!TIP]\n> The CIP title in the pull request should be kept consistent with the CIP header `Title:`.\n\n> [!IMPORTANT]\n> Pull requests should not include implementation code: any code bases should instead be provided as links to a code repository.\n\n> [!NOTE]\n> Proposals addressing a specific CPS should also be listed in the corresponding CPS header, in _'Proposed Solutions'_, to keep track of ongoing work.\n\n###### Naming CIPs with similar subjects\n\nWhen a CIP title *and* subject matter share a common element, begin the CIP title with that common element and end it with the specific portion, delimited with the `-` character.  Example (CIP-0095):\n\n> *Web-Wallet Bridge **-** Governance*\n\nCIP editors will help determine these common elements and, whenever necessary, rename both CIP document titles and PR titles accordingly.  The objective is to provide commonly recognisable names for similar developments (e.g. multiple extensions to another CIP or scheme).\n\n###### Link to proposal from PR first comment\n\nIn the original comment for your pull request, please include a link to the directory or the `README.md` for the CIP in your working branch, so readers and reviewers can easily follow your work.  This makes it easier for editors and the community to read and review your proposal.\n\n> [!NOTE]\n> If this link changes (e.g. from the CIP directory being renamed), please keep this link updated.\n\n###### Follow a reviewer- and editor-friendly review process\n\nAs review progresses:\n- When editors and reviewers submit changes that you accept, commit them from the GitHub UI so these review points are resolved.\n- Even if resolving these in your own environemnt, mark any review points Resolved as they are resolved: otherwise your PR will appear stalled and merging will likely be delayed.\n- **Don't \"force push\"**: which overwrites commit histories and disrupts change visibility during the review process.  Instead, `git merge` the PR branch back into your local environment: which will preserve any collaborative editing history.\n\n\n##### 1.b. Authors seek feedback\n\nAuthors shall champion their proposals. The CIP process is a collaborative effort, which implies discussions between different groups of individuals. While editors may provide specific inputs and help reach out to experts, authors shall actively seek feedback from the community to help move their proposal forward.\n\nDiscussions and comments shall mainly happen on Github in pull requests. When discussed on other mediums, we expect authors or participants to report back a summary of their discussions to the original pull request to keep track of the most critical conversations in a written form and all in one place.\n\nAs much as possible, commenters/reviewers shall remain unbiased in their judgement and assess proposals in good faith. Authors have the right to reject comments or feedback but **are strongly encouraged to address concerns in their 'Rationale' section**. Ultimately, CIP editors shall make the last call concerning the various statements made on a proposal and their treatment by the author(s).\n\nBy opening pull requests or posting comments, commenters and authors agree to our [Code of Conduct][CoC]. Any comment infringing this code of conduct shall be removed or altered without prior notice.\n\n> [!NOTE]\n> For acceptability guidelines, including a concise review checklist, see \n[CIP Wiki > CIPs for Reviewers & Authors](https://github.com/cardano-foundation/CIPs/wiki/2.-CIPs-for-Reviewers-&-Authors).\n\n#### 2. Editors' role\n\n##### 2.a. Triage in bi-weekly meetings\n\nCIP editors meet regularly in [a public Discord server][Discord] to go through newly proposed ideas in a triage phase. As a result of a triage, editors acknowledge new CIPs, and briefly review their preamble. Editors also assign numbers to newly proposed CIPs during this phase. Incidentally, the triage allows new CIPs to get visibility for potential reviews.\n\n##### 2.b. Reviews\n\nIn every meeting, editors will also review in more depth some chosen CIPs (based on their readiness and the stability of the discussions) and assess if they meet the criteria to be merged in their aimed status.\n\nDuring review sessions, editors will regularly invite project maintainers or actors from the ecosystem who are deemed relevant to the meeting's agenda. However, meetings are open and held in public to encourage anyone interested in participating.\n\nA dedicated Discord channel may also be created for some long-running discussions to support quick chats and progress on particular topics (while still being regularly summarised on the repository).\n\n#### 3. Merging CIPs in the repository\n\nOnce a proposal has reached all requirements for its target status (as explained in [Statuses](#statuses)) and has been sufficiently and faithfully discussed by community members, it is merged with its target status.\n\n> [!WARNING]\n> Ideas deemed unsound shall be rejected with justifications or withdrawn by the authors. Similarly, proposals that appear abandoned by their authors shall be rejected until resurrected by their authors or another community member.\n\nCIPs are generally merged with the status _'Proposed'_ until they meet their _'Path to Active'_ requirements. In some rare cases (mainly when written after the facts and resulting in a broad consensus), proposals may be merged as _'Active'_ immediately.\n\nEach proposal is unique and has a bespoke _'Path to Active'_, which must be reviewed case-by-case. There must be sufficient time between the first appearance of a proposal and its merge into the repository to ensure enough opportunity for community members to review it.\n\n#### 4. Implementors work towards Active status following their 'Implementation Plan'\n\nOnce merged, implementors shall execute the CIP's _'Implementation Plan'_, if any. If a proposal has no implementors or no _'Implementation Plan'_, it may simply remain as _'Proposed'_ in the repository.\n\n> [!WARNING]\n> It is perfectly fine to submit ideas in the repository with no concrete implementation plan, yet they should be treated as such: ideas.\n\nBesides, once all of the _'Path to Active'_ requirements have been met, authors shall make another pull request to change their CIP's status to _'Active'_. Editors may also do this on occasion.\n\n### Editors\n\nFor a full, current description of Editor workflow, see [CIP Wiki > CIPs for Editors](https://github.com/cardano-foundation/CIPs/wiki/3.-CIPs-for-Editors).\n\n#### Missions\n\nCIP Editors safeguard the CIP process: they form a group enforcing the process described in this document and facilitating conversations between community actors. CIP editors should strive to keep up to date with general technical discussions and Cardano proposals. For each new draft proposal submitted on [cardano-foundation/CIPs][PullRequest] an editor might review it as follows:\n\n- Read the proposal to check if it is ready, sound, and complete.\n- Check if it has been [properly formatted](#structure).\n- Check if sufficient time has been allowed for proper discussion amongst the community.\n- Ensure the motivation behind the CIP is valid and that design choices have relevant justifications or rationale.\n- Confirm licensing terms are acceptable.\n- Assign a CIP number\n- Assign a given category to help with searching\n- Request wording/grammar adjustments\n\nCIPs that do not meet a sufficient level of quality or don't abide by the process described in this document will be rejected until their authors address review comments.\n\n#### Reviews\n\nNote that editors **may** provide technical feedback on proposals in some cases, although they aren't expected to be the sole technical reviewers of proposals. CIPs are, before anything, a community-driven effort. While editors are here to facilitate the discussion and mediate debates, they aren't necessarily technical experts on all subjects covered by CIPs.\n\nTherefore, CIPs authors are encouraged to reach out to known experts to demonstrate their good faith and openness when they champion a proposal. Editors may help with such efforts but cannot be expected to do this alone.\n\n#### Nomination\n\nExisting editors or the community may nominate new editors, provided they have proven to be already existing and active contributors to the CIP process and are ready to commit some of their time to the CIP process regularly.\n\nThe missions of an editor include, but aren't exclusively limited to, any of the tasks listed above. Active members that seek to become listed editors may also come forth and let it be known. Any application will take the form of a pull request updating this document with a justification as the pull request's description.\n\nCurrent editors are listed here below:\n\n| Robert Phair <br/> [@rphair][] | Ryan Williams <br/> [@Ryun1][] | Thomas Vellekoop <br/> [@perturbing][] |\n| ---                            | ---                            | ---                                    |\n\n[@rphair]: https://github.com/rphair\n[@Ryun1]: https://github.com/Ryun1\n[@perturbing]: https://github.com/perturbing\n\nEmeritus editors:\n- Frederic Johnson - [@crptmppt](https://github.com/crptmppt)\n- Sebastien Guillemot - [@SebastienGllmt](https://github.com/SebastienGllmt)\n- Matthias Benkort - [@KtorZ](https://github.com/KtorZ)\n- Duncan Coutts - [@dcoutts](https://github.com/dcoutts)\n- Adam Dean - [@Crypto2099](https://github.com/Crypto2099)\n\n## Rationale: how does this CIP achieve its goals?\n\n### Key changes from CIP-0001 (version 1)\n\n#### Introduction of Cardano Problem Statements\n\nA significant friction point regarding complex CIPs is often how the main problem is stated. The _'Motivation'_ is often insufficient (or simply underused) to describe various aspects of a problem, its scope, and its constraints. This lack of clarity leads, in the end, to poorly defined issues and debates over solutions that feel unclear amongst different participants.\n\nThe introduction of [CIP-9999: Cardano Problem Statements][CIP-9999] addresses this gap by introducing a formal template and structure around problem statements. However, requiring any CIP to be preceded by a CPS would likely be overkill and become an obstacle to the overall adoption of the CIP process for more straightforward problems. At this stage, it is reasonable to think either (a) that CIP authors would foresee the complexity and state their problem as a CPS beforehand or (b) that editors or reviewers will require authors to write a CPS to clarify a perhaps ambiguous motivation on complex CIPs.\n\nWe also anticipate project maintainers or community actors will write standalone CPS to document well-known issues for which the design space is still to be explored.\n\n#### Explicit enlisting\n\nA recurring pain point with the previous CIP process was the lack of clear ownership/accountability of some proposals affecting remote parts of the ecosystem. On several occasions, proposals from community members have concerned, for example, core components of the Cardano architecture. However, those proposals have been hard to move forward with and to either reject or turn into concrete action steps. Authors usually do not have the technical proficiency required to implement them and rely on the core engineering team in charge of projects to do so. Thus, explicit compliance and collaboration of those engineering teams are necessary to propose changes affecting their work.\n\nBy asking teams to explicitly state their compliance with the CIP process with clear, accountable owners (as individuals), it becomes plausible to now establish a dialogue between community members and technical leadership responsible for specific ecosystem projects. Furthermore, projects that, on the contrary, do not seek to participate in CIP or receive contributions in the form of CIP/CPS are automatically taken out of this process, saving time and energy for both reviewers and authors.\n\n#### Nomination of new editors\n\nThe _'Editors'_ section now details how to become a CIP editor. The process aims to be simple and define those involved the most with editorship tasks as editors. Thus, being an active contributor to the CIP process as a prerequisite only makes sense. We want to leave the room open for either existing editors to refer an existing community as an editor or for community members to formulate that request explicitly.\n\nThere are no delays or number of contributions necessary to pretend to become an editor. Those criteria are often less relevant than others and more subjective, such as the quality of one's participation or their relevance. Since editors also need to work with one another in the end, it seems logical that existing editors have their final say about whom they intend to work with.\n\n#### Removal of `type` in the preamble\n\nThe `type` field in the header has shown to be:\n\n- confusing (often authors are getting it wrong);\n- not-too-useful (as a `type` tells you very little about the nature of the CIP).\n\nAn ad-hoc classification by non-rigid categories, which may evolve over time to reflect ecosystem areas, seems better suited. Therefore, we do not require authors to categorise their CIPs; instead, categories will be added and maintained by editors as a side task atop the CIP process.\n\n#### Simplification of the statuses\n\nOver time we've learnt that the valuable information a status should convey is really about the readiness of a CIP, especially regarding standards. For a long time, many CIPs have lived as `Draft` despite some being used in dozens of systems. Consequently, the `status` has lost a bit of its meaning. The frontier between `Draft` and `Proposed` hasn't always been clear, and it has proven challenging to come up with good statuses to describe all possible rejections. So instead, the current division of statuses is as simple-as-it-can-be and remains flexible regarding rejections.\n\n### Choice of CoC\n\nThe choice of a code of conduct follows other popular open source initiatives. It serves as a good, unilaterally accepted foundation which can be later revisited if necessary.\n\n## Path to Active\n\n### Acceptance criteria\n\n- [x] The proposal has been reviewed by the community and sufficiently advertised on various channels.\n    - [x] Cardano Forum\n    - [x] IOG Technical Community Discord\n    - [x] Twitter\n    - [x] Reddit\n    - [x] Cardano Summit 2022\n    - [x] IO ScotFest 2022\n\n- [x] All major concerns or feedback have been addressed. The document is as unambiguous as it can be and it outlines a process that a supermajority of reviewers is happy to follow.\n\n### Implementation Plan\n\n- [x] Rework existing draft CIPs to adopt this new format and process. In particular, CIPs affecting enlisted projects should be brought to the attention of the respective project maintainers.\n- [x] Edit / align old CIPs preambles and sections to at least reflect also this new format.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0][].\n\n[Apache-2.0]: http://www.apache.org/licenses/LICENSE-2.0\n[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n[CIP-0035]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0035\n[CIP-0084]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0084\n[CIP-9999]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-9999\n[CIP-TEMPLATE.md]: https://github.com/cardano-foundation/CIPs/tree/master/.github/CIP-TEMPLATE.md\n[CODE_OWNERS]: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners\n[CPS]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-9999\n[Discussions:editors]: https://github.com/cardano-foundation/CIPs/discussions/new?category=editors\n[Markdown]: https://en.wikipedia.org/wiki/Markdown\n[PullRequest]: https://github.com/cardano-foundation/CIPs/pulls\n[RFC 822]: https://www.ietf.org/rfc/rfc822.txt\n[Repository]: https://github.com/cardano-foundation/CIPs/pulls\n[CoC]: https://github.com/cardano-foundation/CIPs/tree/master/CODE_OF_CONDUCT.md\n[Discord]: https://discord.gg/J8sGdCuKhs\n[Wiki]: https://github.com/cardano-foundation/CIPs/wiki\n"
  },
  {
    "path": "CIP-0002/CIP-0002.md",
    "content": "Moved to [CIP-0002/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0002/README.md",
    "content": "---\nCIP: 2\nTitle: Coin Selection Algorithms for Cardano\nCategory: Wallets\nAuthors:\n    - Jonathan Knowles <jonathan.knowles@iohk.io>\nImplementors: N/A\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/2\n    - https://github.com/cardano-foundation/CIPs/issues/232\nStatus: Active\nCreated: 2020-05-04\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis article describes, in _human-readable terms_, the coin selection\nalgorithms used by [Cardano\nWallet](https://github.com/cardano-foundation/cardano-wallet/) and other parts of\nthe Cardano ecosystem.\n\nIn the context of this article, **coin selection** refers to the process of\nchoosing _unspent coins_ from a wallet (or [UTxO set](#utxo-set)) in order to\npay money to one or more recipients.\n\n## Motivation: why is this CIP necessary?\n\nThis document was written to help people gain an understanding of the coin\nselection algorithms used in Cardano _without_ having to read through and\nunderstand Cardano source code.\n\nWe aim to provide descriptions of algorithms that:\n\n  - don't require prior experience with any particular programming language;\n  - are understandable for people who are unfamiliar with coin selection;\n  - are precise enough for software engineers to be able to reimplement these\n    algorithms in their preferred programming languages.\n\nWhere appropriate, we also provide mathematical descriptions, for added clarity.\n\n### Scope\n\nCoin selection is a large, complex topic, with many difficult problems to\nsolve. However, all software that performs coin selection must ultimately deal\nwith at least the following pair of problems:\n\n  - How to _generate_ a coin selection, by choosing unspent coins from a wallet\n    (or [UTxO set](#utxo-set)) in order to pay money to one or more\n    recipients.\n  - How to _adjust_ a coin selection in order to pay for a _network fee_, so\n    that the coin selection can be published as a transaction on the\n    blockchain.\n\nThis article concerns itself with the _former_ problem of _how to generate_ a\ncoin selection.\n\nProblems relating to network fees, and how to adjust coin selections to pay for\nsuch fees, are outside the scope of this article.\n\n### Background\n\nThis section introduces the fundamental concepts behind coin selection,\nprovides a discussion of why coin selection is a non-trivial problem, and\ndescribes important goals of coin selection algorithms.\n\n#### What is Coin Selection?\n\nCoin selection is the process of choosing unspent coins from a wallet in order\nto pay money to one or more recipients.\n\n##### Coin Selection in the Physical World\n\nIn the familiar world of _physical_ money, our wallets hold value in the form\nof _coins and banknotes_.\n\nWhen making a payment to someone, we typically select a combination of coins\nand banknotes from a wallet that, when added together, have enough value to\ncover the amount required.\n\nIdeally, we'd always be able to select _just enough_ to cover the exact amount.\nHowever, given that coins and banknotes have fixed values (and cannot be\nsubdivided without destroying their value), it's often impossible to select the\nexact amount required. In such cases, we typically give the recipient _more_\nthan the required amount, and then receive the excess value back as _change_.\n\n> :bulb: **Example**\n>\n> Alice wishes to pay for her lunch.\n>\n> The total price comes to €2.50 (2 euros and 50 cents). In her wallet, she has\n> **five** _one-euro_ coins, and **one** _ten-euro_ note.\n>\n> Note that there is _no_ combination of coins (or notes) in her wallet that\n> when added together give a total of €2.50, but there _are_ several possible\n> combinations that _exceed_ the total.\n>\n> To solve this problem, Alice selects _one_ of these combinations: **three**\n> _one-euro_ coins. She uses the coins to make the payment, and then receives\n> **one** 50-cent coin as change.\n\n##### Coin Selection in Cardano\n\nSimilarly to how a physical wallet holds value in the form of _unspent coins\nand banknotes_, a Cardano wallet holds value in the form of _unspent\ntransaction outputs_. An [unspent transaction\noutput](#unspent-transaction-output) is the result of a previous transaction\nthat transferred money to the wallet, where the value has not yet been spent by\nanother transaction. Each unspent transaction output has an associated [coin\nvalue](#coin-value), and the total value of a wallet is the _sum_ of these coin\nvalues. Collectively, the set of unspent transaction outputs is known as the\n[UTxO set](#utxo-set).\n\nWhen using a Cardano wallet to make a payment, the wallet software must select\na combination of unspent outputs from the wallet's [UTxO set](#utxo-set), so\nthat the total value of selected outputs is enough to cover the target amount.\n\nJust as with physical coins and notes, unspent outputs from the UTxO set\n_cannot_ be subdivided, and must either be spent completely in a given\ntransaction, or not be spent at all. Similarly to a transaction with physical\nmoney, the wallet software must select a combination of unspent outputs whose\ntotal value is _greater_ than the target amount, and then arrange that _change_\nis paid back to the wallet.\n\nCoin selection refers to the process of selecting a combination of unspent\noutputs from a wallet's [UTxO set](#utxo-set) in order to make one or more\npayments, and computing the set of change to be paid back to the wallet.\n\n#### Why is Coin Selection Non-Trivial?\n\nThere are a number of issues which make the problem of coin selection more\ncomplicated than would initially appear.\n\n##### The Transaction Size Limitation\n\nEach [transaction](#transaction) has a _maximum size_, as defined by the\nprotocol. The size of a transaction increases as we add more\n[inputs](#transaction-input) or [outputs](#transaction-output).\n\nTherefore, there's a practical limit on the number of coins we can select for\nany given transaction.\n\n##### The Problem of Dust\n\nOne simple strategy for *selecting coins* might be to mimic what we do when\nmaking a payment with coins and banknotes in the physical world. By giving the\nrecipient an amount that's as close as possible to the amount they're expecting,\nwe can minimize the amount of change they need to return to us.\n\nHowever, trying to replicate this strategy with a UTxO-based wallet has an\nundesirable effect: minimizing the total value of selected coins will also\nminimize the value of change returned to the wallet. When repeated over time,\nthis strategy will tend to cause an accumulation of tiny outputs in the\nwallet's [UTxO set](#utxo-set) known as [**dust**](#dust-output).\n\nDust outputs are a problem, because even if the total value of dust in a wallet\nis more than enough to cover a given target amount, if we attempt to include\nthat dust in a given transaction, we may run out of space (by reaching the\n[transaction size limit](#the-transaction-size-limitation)) before we can cover\nthe target amount.\n\nFor more information on dust avoidance, see [Self Organisation in Coin\nSelection](#self-organisation-in-coin-selection).\n\n##### The Problem of Concurrency\n\nOne simple strategy for *generating change* might be to mimic what a shop\nassistant does when accepting a payment in the real world, which is to minimize\nthe *number* of coins and banknotes that they return to the customer.  This is\nbeneficial for the shop, as it reduces the chances of them running out of\nchange, and beneficial for the customer, as it reduces the amount of change\nthat they have to carry around in their wallet.\n\nAnalogously, when generating change for a UTxO-based wallet, we might be\ntempted to use the simple strategy of just creating a single [change\noutput](#change-output) with the exact excess value.\n\nHowever, using this strategy has an undesirable effect: the repeated act of\nminimizing the number of change outputs will tend (over time) to reduce the\nnumber of entries in a wallet's [UTxO set](#utxo-set). This is bad for two\nreasons:\n\n1.  Having a small [UTxO set](#utxo-set) limits the number of future payments\n    that we can make in parallel.\n\n2.  The approach of coalescing all change into a single output is widely\n    considered to have negative privacy implications.\n\n#### Goals of Coin Selection Algorithms\n\nIn light of the issues described above, we'd ideally like for our coin selection\nalgorithms to be able to:\n\n  * limit, over the course of time, the amount of [dust](#dust-output) that\n    accumulates in the [UTxO set](#utxo-set).\n\n  * maintain, over the course of time, a [UTxO set](#utxo-set) with _useful_\n    outputs: that is, outputs that allow us to process future payments with a\n    reasonably small number of [inputs](#transaction-input).\n\n## Specification\n\n### Structure\n\nThe [Background](#background) section introduces the fundamental concepts\nbehind coin selection, provides a discussion of why coin selection is\na non-trivial problem, and describes the goals of coin selection algorithms.\n\nThe [Interface](#interface) section gives a description of the common interface\nunifying all coin selection algorithms used within Cardano Wallet, the standard\nparameter types, result types, and error types used by this interface, and a\ndescription of the properties that all conforming implementations are expected\nto satisfy.\n\nThe [Algorithms](#algorithms) section gives detailed descriptions of each of\nthe individual coin selection algorithms used in Cardano Wallet, along with\nstep-by-step descriptions of the computations involved.\n\nThe [Reference Implementations](#reference-implementations) section provides\nlinks to reference implementations of each algorithm in various languages.\n\n### Contents\n\n* [Abstract](#abstract)\n* [Motivation](#motivation-why-is-this-cip-necessary)\n  * [Scope](#scope)\n  * [Background](#background)\n    * [What is Coin Selection?](#what-is-coin-selection)\n      * [Coin Selection in the Physical World](#coin-selection-in-the-physical-world)\n      * [Coin Selection in Cardano](#coin-selection-in-cardano)\n    * [Why is Coin Selection Non-Trivial?](#why-is-coin-selection-non-trivial)\n      * [The Transaction Size Limitation](#the-transaction-size-limitation)\n      * [The Problem of Dust](#the-problem-of-dust)\n      * [The Problem of Concurrency](#the-problem-of-concurrency)\n    * [Goals of Coin Selection Algorithms](#goals-of-coin-selection-algorithms)\n* [Specification](#specification)\n  * [Structure](#structure)\n  * [Definitions](#definitions)\n    * [Address](#address)\n    * [Coin Value](#coin-value)\n    * [Transaction](#transaction)\n    * [Transaction Input](#transaction-input)\n    * [Transaction Output](#transaction-output)\n    * [Spent Transaction Output](#spent-transaction-output)\n    * [Unspent Transaction Output](#unspent-transaction-output)\n    * [UTxO Set](#utxo-set)\n    * [Change Output](#change-output)\n    * [Dust Output](#dust-output)\n  * [Interface](#interface)\n    * [Parameters](#parameters)\n      * [Requested Output Set](#requested-output-set)\n      * [Initial UTxO Set](#initial-utxo-set)\n      * [Maximum Input Count](#maximum-input-count)\n    * [Results](#results)\n      * [Coin Selection](#coin-selection)\n      * [Remaining UTxO Set](#remaining-utxo-set)\n    * [Properties](#properties)\n      * [Coverage of Payments](#coverage-of-payments)\n      * [Correctness of Change](#correctness-of-change)\n      * [Conservation of UTxO](#conservation-of-utxo)\n      * [Conservation of Outputs](#conservation-of-outputs)\n    * [Failure Modes](#failure-modes)\n      * [UTxO Balance Insufficient](#utxo-balance-insufficient)\n      * [UTxO Not Fragmented Enough](#utxo-not-fragmented-enough)\n      * [UTxO Fully Depleted](#utxo-fully-depleted)\n      * [Maximum Input Count Exceeded](#maximum-input-count-exceeded)\n  * [Algorithms](#algorithms)\n    * [Largest-First](#largest-first)\n      * [State](#state)\n        * [Available UTxO List](#available-utxo-list)\n        * [Unpaid Output List](#unpaid-output-list)\n        * [Accumulated Coin Selection](#accumulated-coin-selection)\n      * [Computation](#computation)\n    * [Random-Improve](#random-improve)\n      * [Cardinality](#cardinality-1)\n      * [State](#state-1)\n        * [Available UTxO Set](#available-utxo-set)\n        * [Accumulated Coin Selection](#accumulated-coin-selection-1)\n      * [Computation](#computation-1)\n        * [Phase 1: Random Selection](#phase-1-random-selection)\n        * [Phase 2: Improvement](#phase-2-improvement)\n      * [Termination](#termination-1)\n* [Rationale: how does this CIP achieve its goals?](#rationale-how-does-this-cip-achieve-its-goals)\n  * [Motivating Principles](#motivating-principles)\n    * [LargestFirst](#largest-first-2)\n    * [Random-Improve](#random-improve-2)\n      * [Principle 1: Dust Management](#principle-1-dust-management)\n      * [Principle 2: Change Management](#principle-2-change-management)\n      * [Principle 3: Performance Management](#principle-3-performance-management)\n  * [External Resources](#external-resources)\n    * [Self Organisation in Coin Selection](#self-organisation-in-coin-selection)\n* [Path to Active](#path-to-active)\n  * [Acceptance Criteria](#acceptance-criteria)\n  * [Implementation Plan](#implementation-plan)\n    * [Reference Implementations](#reference-implementations)\n      * [Largest-First](#largest-first-1)\n      * [Random-Improve](#random-improve-1)\n* [Copyright](#copyright)\n\n### Definitions\n\nThis section defines common terms that are used throughout this document.\n\n#### Address\n\nAn _address_ is a unique identifier that represents a payment recipient, a\ndestination for a payment.\n\nAddresses are typically owned (and generated) by individual wallets.\n\nIn general, coin selection algorithms are agnostic to the type of addresses\nused to identify payment recipients. Any address type may be used, so long as\nthe set of possible addresses is totally-ordered.\n\n#### Coin Value\n\nA _coin value_ is a non-negative integer value that represents a number of\n[Lovelace](https://cardanodocs.com/cardano/monetary-policy/).\n\nOne [Ada](https://cardanodocs.com/cardano/monetary-policy/) is _exactly_ equal\nto one million Lovelace.\n\n#### Transaction\n\nIn a [UTxO](#utxo-set)-based blockchain, a _transaction_ is a binding between\n[inputs](#transaction-input) and [outputs](#transaction-output).\n\n```\ninput #1  >---+          +---> output #1\n               \\        /\ninput #2  >-----+------+\n               /        \\\ninput #3  >---+          +---> output #2\n```\n\n#### Transaction Input\n\nA _transaction input_ is a _unique reference_ to a single\n[output](#transaction-output) from a previous transaction.\n\nIn general, coin selection algorithms are agnostic to the type of references\nused to identify outputs from previous transactions. Any type may be used, so\nlong as the set of possible references is totally-ordered, and so long as it is\npossible to determine the [coin value](#coin-value) associated with any given\nreference.\n\nIn the case of Cardano and other UTxO-based blockchains, this reference\ngenerally consists of a pair of values (**_h_**, **_n_**), where:\n\n  * **_h_** is a _unique identifier_ for an existing transaction **_t_**;\n  * **_n_** is a 0-based integer index into the output list of transaction\n    **_t_**.\n\n#### Transaction Output\n\nA _transaction output_ consists of a pair of values (**_a_**, **_v_**), where:\n\n  * **_a_** is the [address](#address) of a recipient.\n  * **_v_** is the [coin value](#coin-value) to pay to the recipient.\n\n#### Spent Transaction Output\n\nA _spent transaction output_ is an [output](#transaction-output) from an\nexisting [transaction](#transaction) that has already been referenced as an\n[input](#transaction-input) within a later transaction on the blockchain.\n\nIn effect, the [coin value](#coin-value) associated with that transaction\noutput has been _spent_, and cannot be reused.\n\n#### Unspent Transaction Output\n\nAn _unspent transaction output_ is an [output](#transaction-output) from an\nexisting [transaction](#transaction) that has not yet been referenced as an\n[input](#transaction-input) within a later transaction.\n\nIn effect, the [coin value](#coin-value) associated with that transaction\noutput has _not yet_ been spent, and is still available.\n\n#### UTxO Set\n\nA _UTxO set_ is a set of [unspent transaction\noutputs](#unspent-transaction-output).\n\nThis term is commonly used in two ways:\n\n  * To describe the _complete set_ of all unspent transaction outputs within a\n    _blockchain_.\n\n  * To describe the _subset_ of unspent transaction outputs associated with\n    a _wallet_. The UTxO set of a wallet represents the total unspent value\n    associated with that wallet.\n\nFrom the point of view of a coin selection algorithm, each member of a UTxO set\ncan be represented as a pair of the form (**_u_**, **_v_**), where:\n\n  * **_u_** is a unique reference to an\n    [unspent output](#unspent-transaction-output) from a previous transaction.\n  * **_v_** is the [coin value](#coin-value) associated with **_u_**.\n\nIn general, coin selection algorithms are agnostic to the type of references\nused to identify unspent outputs from previous transactions. Any type may be\nused, so long as the set of possible references is totally-ordered.\n\nIn practice however, the type of each unique reference **_u_** is equivalent\nto the type of a [transaction input](#transaction-input), as transaction inputs\nare simply references to unspent outputs from previous transactions.\n\n#### Change Output\n\nIn the context of a wallet, a _change output_ is a [transaction\noutput](#transaction-output) that transfers value _back_ to the wallet, rather\nthan to an external payment recipient. The [address](#address) associated with\na change output is generated by the wallet, and belongs to the wallet.\n\nChange ouputs are necessary in a UTxO-based blockchain, as the value associated\nwith any given [transaction input](#transaction-input) must be spent _entirely_\nby the transaction that includes it.\n\nWhen selecting entries from a [UTxO set](#utxo-set) to include as inputs in a\ntransaction, a coin selection algorithm will generally not be able to select\ninputs that precisely match the total value of all payments to external\nrecipients, and will therefore need to select more than is strictly required.\nTo avoid the destruction of value, selection algorithms create _change outputs_\nto return the excess value back to the wallet.\n\n#### Dust Output\n\nA _dust output_ is a [transaction output](#transaction-output) with an\nassociated [coin value](#coin-value) that is:\n\n  * small in comparison to payments typically made by the user of the wallet;\n  * small in comparison to the marginal fee associated with including it in\n    a transaction.\n\nDust outputs are a problem, because even if the total value of dust in a wallet\nis more than enough to cover a given payment amount, if we attempt to include\nthat dust in a given transaction, we may run out of space (by reaching the\n[transaction size limit](#the-transaction-size-limitation)) before we can cover\nthe target amount.\n\n### Interface\n\nAll coin selection algorithms used by Cardano Wallet implement a\n_common interface_.\n\nAt the most fundamental level, a coin selection algorithm is a _mathematical\nfunction_ that when applied to a [requested output\nset](#requested-output-set) and an [initial UTxO set](#initial-utxo-set),\nwill produce a [coin selection](#coin-selection): the basis for a\n[transaction](#transaction) in a UTxO-based blockchain.\n\nThis section describes:\n\n  * the [parameters](#parameters) accepted by all coin selection algorithms;\n  * the [results](#results) they produce when successful;\n  * the [error conditions](#failure-modes) that may occur on failure;\n  * the [properties](#properties) that apply to all coin selection\n    algorithms: mathematical laws governing the relationships between parameters\n    and results.\n\nIn this section, the terms _coin selection algorithm_ and _coin selection\nfunction_ will be used interchangeably.\n\n#### Parameters\n\nAll coin selection functions accept the following parameters:\n\n 1. **Requested Output Set**\n\n    A list of payments to be made to recipient addresses, encoded as a list of\n    [transaction outputs](#transaction-output).\n\n 2. **Initial UTxO Set**\n\n    A [UTxO set](#utxo-set) from which the coin selection algorithm can select\n    entries, to cover payments listed in the [requested output\n    set](#requested-output-set).\n\n    In the context of a wallet, this parameter would normally be assigned with\n    the wallet's complete [UTxO set](#utxo-set), giving the coin selection\n    algorithm access to the total value associated with that wallet.\n\n 3. **Maximum Input Count**\n\n    An _upper bound_ on the number of UTxO entries that the coin selection\n    algorithm is permitted to select from the [initial UTxO\n    set](#initial-utxo-set).\n\n    This parameter is necessary for blockchains that impose an upper limit on\n    the size of transactions.\n\n#### Results\n\nAll coin selection functions produce the following result values:\n\n 1. **Coin Selection**\n\n    A _coin selection_ is the basis for a [transaction](#transaction) in a\n    UTxO-based blockchain.\n\n    It is a record with three fields:\n\n      * A set of **_inputs_**, equivalent to a subset of the\n        [initial UTxO set](#initial-utxo-set).\n\n        From the point of view of a _wallet_, this represents the value that\n        has been selected from the wallet in order to cover the total payment\n        value.\n\n      * A set of **_outputs_** (see [transaction output](#transaction-output)).\n\n        Represents the set of payments to be made to recipient addresses.\n\n      * A set of **_change values_** (see [change output](#change-output)),\n        where each change value is simply a [coin value](#coin-value).\n\n        From the point of view of a _wallet_, this represents the change to be\n        returned to the wallet.\n\n 2. **Remaining UTxO Set**\n\n    The _remaining UTxO set_ is a subset of the [initial UTxO\n    set](#initial-utxo-set).\n\n    It represents the set of values that remain after the coin selection\n    algorithm has removed values to pay for entries in the [requested output\n    set](#requested-output-set).\n\n    In the context of a _wallet_, if a coin selection algorithm is applied to\n    the wallet's _complete_ UTxO set, then the _remaining_ UTxO set represents\n    the _updated_ UTxO set of that wallet.\n\n#### Properties\n\nAll coin selection algorithms satisfy a common set of _properties_: general\nrules that govern the relationship between the _parameters_ supplied to coin\nselection functions and the _results_ they are allowed to produce.\n\n##### Coverage of Payments\n\nThis property states that the total value of _inputs_ in the resulting [coin\nselection](#coin-selection) result is sufficient to _cover_ the total value of\nthe [requested output set](#requested-output-set).\n\nIn particular:\n\n  * **_v_**<sub>selected</sub> ≥ **_v_**<sub>requested</sub>\n\nWhere:\n\n  * **_v_**<sub>requested</sub>\n\n    is the total value of the [requested output set](#requested-output-set)\n\n\n  * **_v_**<sub>selected</sub>\n\n    is the total value of the _inputs_ field of the [coin\n    selection](#coin-selection) result.\n\n##### Correctness of Change\n\nThis property states that the correct amount of _change_ was generated.\n\nIn particular:\n\n  * **_v_**<sub>selected</sub>\n  = **_v_**<sub>requested</sub> + **_v_**<sub>change</sub>\n\nWhere:\n\n  * **_v_**<sub>change</sub>\n\n    is the total value of the _change_ field of the [coin\n    selection](#coin-selection) result.\n\n  * **_v_**<sub>requested</sub>\n\n    is the total value of the [requested output set](#requested-output-set)\n\n  * **_v_**<sub>selected</sub>\n\n    is the total value of the _inputs_ field of the [coin\n    selection](#coin-selection) result.\n\n##### Conservation of UTxO\n\nThis property states that every entry in the [initial UTxO\nset](#initial-utxo-set) is included in _either_ the inputs set of the generated\n[coin selection](#coin-selection), _or_ in the [remaining UTxO\nset](#remaining-utxo-set), but _not both_.\n\n  * If a UTxO entry _is_ selected by the coin selection algorithm, it is\n    included in the [coin selection](#coin-selection) inputs set.\n\n  * If a UTxO entry is _not_ selected by the coin selection algorithm, it is\n    included in the [remaining UTxO set](#remaining-utxo-set).\n\nThe following laws hold:\n\n  * **_U_**<sub>initial  </sub> ⊃ **_U_**<sub>remaining</sub>\n  * **_U_**<sub>initial  </sub> ⊇ **_U_**<sub>selected </sub>\n\nAnd:\n\n  * **_U_**<sub>remaining</sub> ∩ **_U_**<sub>selected </sub> = ∅\n  * **_U_**<sub>remaining</sub> ⋃ **_U_**<sub>selected </sub> =\n    **_U_**<sub>initial  </sub>\n\nWhere:\n\n  * **_U_**<sub>initial</sub>\n\n    is the [initial UTxO set](#initial-utxo-set).\n\n  * **_U_**<sub>remaining</sub>\n\n    is the [remaining UTxO set](#remaining-utxo-set).\n\n  * **_U_**<sub>selected</sub>\n\n    is the value of the _inputs_ field of the [coin selection](#coin-selection)\n    result.\n\n##### Conservation of Outputs\n\nThis property states that the [requested output set](#requested-output-set)\nis _conserved_ in the [coin selection](#coin-selection) result.\n\nIn particular, the _outputs_ field of the [coin selection](#coin-selection)\nresult should be _equal to_ the [requested output set](#requested-output-set).\n\n#### Failure Modes\n\nThere are a number of ways in which a coin selection algorithm can fail:\n\n  * **UTxO Balance Insufficient**\n\n    This failure occurs when the total value of the entries within the [initial\n    UTxO set](#initial-utxo-set) (the amount of money _available_) is _less\n    than_ the the total value of all entries in the [requested output\n    set](#requested-output-set) (the amount of money _required_).\n\n  * **UTxO Not Fragmented Enough**\n\n    This failure occurs when the _number_ of entries in the [initial UTxO\n    set](#initial-utxo-set) is _smaller than_ the number of entries in the\n    [requested output set](#requested-output-set), for algorithms that impose\n    the restriction that a single UTxO entry can only be used to pay for _at\n    most one_ output.\n\n  * **UTxO Fully Depleted**\n\n    This failure occurs if the algorithm depletes all entries from the [initial\n    UTxO set](#initial-utxo-set) _before_ it is able to pay for all outputs in\n    the [requested output set](#requested-output-set).\n\n    This can happen _even if_ the total value of entries within the [initial\n    UTxO set](#initial-utxo-set) is _greater than_ the total value of all\n    entries in the [requested output set](#requested-output-set), due to\n    various restrictions that coin selection algorithms impose on themselves\n    when selecting UTxO entries.\n\n  * **Maximum Input Count Exceeded**\n\n    This failure occurs when another input must be selected by the algorithm in\n    order to continue making progress, but doing so will increase the size of\n    the resulting selection beyond an acceptable limit, specified by the\n    [maximum input count](#maximum-input-count) parameter.\n\n### Algorithms\n\nThis section describes the coin selection algorithms used by Cardano Wallet,\nalong with step-by-step descriptions of the computations involved.\n\nAll algorithms implement a _common interface_, as described in the\n[Interface](#interface) section.\n\nThere are two main algorithms used by Cardano Wallet:\n\n  * [Largest-First](#largest-first)\n  * [Random-Improve](#random-improve)\n\nIn general, Cardano Wallet gives _priority_ to the\n[Random-Improve](#random-improve) algorithm, as experimental evidence shows\nthat it performs better at [minimising dust](#goals) and maintaining a UTxO set\nwith [useful outputs](#goals). (See [Self Organisation in Coin\nSelection](#self-organisation-in-coin-selection) for more details.)\n\nHowever, in rare cases, the [Random-Improve](#random-improve) algorithm may\nfail to produce a result. In such cases, Cardano Wallet will fall back to the\n[Largest-First](#largest-first) algorithm.\n\n#### Largest-First\n\nThe **Largest-First** coin selection algorithm considers UTxO set entries\nin _descending order of value_, from largest to smallest.\n\nWhen applied to a set of [requested outputs](#requested-output-set), the\nalgorithm repeatedly selects entries from the [initial UTxO\nset](#initial-utxo-set) until the total value of selected entries is _greater\nthan or equal to_ the total value of requested outputs.\n\nThe name of the algorithm is taken from the idea that the **largest** UTxO\nentry is always selected **first**. Specifically:\n\n> A given UTxO entry **_u_<sub>1</sub>** with\n> value **_v_<sub>1</sub>** can be selected if and only if there is no other\n> unselected entry **_u_<sub>2</sub>** with value **_v_<sub>2</sub>** where\n> **_v_<sub>2</sub>** > **_v_<sub>1</sub>**.\n\n##### State\n\nAt all stages of processing, the algorithm maintains the following pieces of\nstate:\n\n 1. **Available UTxO List**\n\n    This is initially equal to the [initial UTxO set](#initial-utxo-set),\n    sorted into _descending order of coin value_.\n\n    The _head_ of the list is always the remaining UTxO entry with the _largest\n    coin value_.\n\n    Entries are incrementally removed from the _head_ of the list as the\n    algorithm proceeds, until enough value has been selected.\n\n 2. **Selected UTxO Set**\n\n    This is initially equal to the empty set.\n\n##### Computation\n\nThe algorithm proceeds according to the following sequence of steps:\n\n  * **Step 1**\n\n    If the [available UTxO list](#available-utxo-list) is _empty_:\n\n      * Terminate with a [UTxO Balance\n        Insufficient](#utxo-balance-insufficient) error.\n\n    If the [available UTxO list](#available-utxo-list) is _not empty_:\n\n      * Remove an UTxO entry from the head of the [available UTxO\n        list](#available-utxo-list) and add it to the [selected UTxO\n        set](#selected-utxo-set).\n\n  * **Step 2**\n\n    Compare the total size **_n_**<sub>selected</sub> of the [selected UTxO\n    set](#selected-utxo-set) with the [maximum input\n    count](#maximum-input-count) **_n_**<sub>max</sub>.\n\n      * If **_n_**<sub>selected</sub> > **_n_**<sub>max</sub> then:\n\n        * Terminate with a [Maximum Input Count\n          Exceeded](#maximum-input-count-exceeded) error.\n\n      * If **_n_**<sub>selected</sub> ≤ **_n_**<sub>max</sub> then:\n\n        * Go to step 3.\n\n  * **Step 3**\n\n    Compare the total value **_v_**<sub>selected</sub> of the [selected UTxO\n    set](#selected-utxo-set) to the total value **_v_**<sub>requested</sub> of\n    the [requested output set](#requested-output-set):\n\n      * If **_v_**<sub>selected</sub> < **_v_**<sub>requested</sub> then go to\n        step 1.\n      * If **_v_**<sub>selected</sub> ≥ **_v_**<sub>requested</sub> then go to\n        step 4.\n\n  * **Step 4**\n\n    Return a [coin selection](#coin-selection) result where:\n\n      * The _inputs_ set is equal to the [selected UTxO\n        set](#selected-utxo-set).\n\n      * The _outputs_ set is equal to the [requested output\n        set](#requested-output-set).\n\n      * If **_v_**<sub>selected</sub> > **_v_**<sub>requested</sub> then:\n\n        * The _change_ set contains just a single [coin](#coin-value) of value\n          (**_v_**<sub>selected</sub> − **_v_**<sub>requested</sub>).\n\n      * If **_v_**<sub>selected</sub> = **_v_**<sub>requested</sub> then:\n\n        * The _change_ set is empty.\n\n#### Random-Improve\n\nThe **Random-Improve** coin selection algorithm works in _two phases_:\n\n  * In the **first phase**, the algorithm iterates through each of the\n    [requested outputs](#requested-output-set) in _descending order of coin\n    value_, from _largest_ to _smallest_. For each output, the algorithm\n    repeatedly selects entries _at random_ from the [initial UTxO\n    set](#initial-utxo-set), until each requested output has been associated\n    with a set of UTxO entries whose _total value_ is enough to pay for that\n    ouput.\n\n  * In the **second phase**, the algorithm attempts to _expand_ each\n    existing UTxO selection with _additional_ values taken at random from the\n    [initial UTxO set](#initial-utxo-set), to the point where the total value\n    of each selection is as close as possible to _twice_ the value of its\n    associated output.\n\nAfter the above phases are complete, for each output of value\n**_v_**<sub>output</sub> and accompanying UTxO selection of value\n**_v_**<sub>selection</sub>, the algorithm generates a _single_ change output\nof value **_v_**<sub>change</sub>, where:\n\n> **_v_**<sub>change</sub>\n>   = **_v_**<sub>selection</sub>\n>   − **_v_**<sub>output</sub>\n\nSince the goal of the second phase was to expand each selection to the point\nwhere its total value is _approximately twice_ the value of its associated\noutput, this corresponds to a change output whose target value is\n_approximately equal_ to the value of the output itself:\n\n> **_v_**<sub>change</sub>\n>   = **_v_**<sub>selection</sub>\n>   − **_v_**<sub>output</sub>\n>\n> **_v_**<sub>change</sub>\n>   ≈ <span>2</span>**_v_**<sub>output</sub>\n>   − **_v_**<sub>output</sub>\n>\n> **_v_**<sub>change</sub>\n>   ≈ **_v_**<sub>output</sub>\n\n##### Cardinality\n\nThe Random-Improve algorithm imposes the following cardinality restriction:\n\n  * Each entry from the [initial UTxO set](#initial-utxo-set) is used to pay\n    for _at most one_ output from the [requested output\n    set](#requested-output-set).\n\nAs a result of this restriction, the algorithm will fail with a [UTxO Not\nFragmented Enough](#utxo-not-fragmented-enough) error if the number of entries\nin the [initial UTxO set](#initial-utxo-set) is _smaller than_ the number of\nentries in the [requested output set](#requested-output-set).\n\n##### State\n\nAt all stages of processing, the algorithm maintains the following pieces of\nstate:\n\n 1. **Available UTxO Set**\n\n    This is initially equal to the [initial UTxO set](#initial-utxo-set).\n\n 2. **Accumulated Coin Selection**\n\n    The accumulated coin selection is a [coin selection](#coin-selection) where\n    all fields are initially equal to the _empty set_.\n\n##### Computation\n\nThe algorithm proceeds in two phases.\n\n- **Phase 1: Random Selection**\n\nIn this phase, the algorithm iterates through each of the [requested\noutputs](#requested-output-set) in descending order of coin value, from\nlargest to smallest.\n\nFor each output of value **_v_**, the algorithm repeatedly selects entries at\n**random** from the [available UTxO set](#available-utxo-set), until the _total\nvalue_ of selected entries is greater than or equal to **_v_**. The selected\nentries are then _associated with_ that output, and _removed_ from the\n[available UTxO set](#available-utxo-set).\n\nThis phase ends when _every_ output has been associated with a selection of\nUTxO entries.\n\n- **Phase 2: Improvement**\n\nIn this phase, the algorithm attempts to improve upon each of the UTxO\nselections made in the previous phase, by conservatively expanding the\nselection made for each output in order to generate improved change\nvalues.\n\nDuring this phase, the algorithm:\n\n  * processes outputs in _ascending order of coin value_.\n\n  * continues to select values from the [available UTxO\n    set](#available-utxo-set).\n\n  * incrementally populates the\n    [accumulated coin selection](#accumulated-coin-selection-1).\n\nFor each output of value **_v_**, the algorithm:\n\n 1.  **Calculates a _target range_** for the total value of inputs used to\n     pay for that output, defined by the triplet:\n\n     (_minimum_, _ideal_, _maximum_) =\n     (**_v_**, <span>2</span>**_v_**, <span>3</span>**_v_**)\n\n 2.  **Attempts to improve upon the existing UTxO selection** for that output,\n     by repeatedly selecting additional entries at random from the [available\n     UTxO set](#available-utxo-set), stopping when the selection can be\n     improved upon no further.\n\n     A selection with value **_v_<sub>1</sub>** is considered to be an\n     _improvement_ over a selection with value **_v_<sub>0</sub>** if **all**\n     of the following conditions are satisfied:\n\n      * **Condition 1**: we have moved closer to the _ideal_ value:\n\n        abs (_ideal_ − **_v_<sub>1</sub>**) <\n        abs (_ideal_ − **_v_<sub>0</sub>**)\n\n      * **Condition 2**: we have not exceeded the _maximum_ value:\n\n        **_v_<sub>1</sub>** ≤ _maximum_\n\n      * **Condition 3**: when counting cumulatively across all outputs\n        considered so far, we have not selected more than the _maximum_ number\n        of UTxO entries specified by [Maximum Input\n        Count](#maximum-input-count).\n\n 3.  **Creates a _change value_** for the output, equal to the total value\n     of the _improved UTxO selection_ for that output minus the value **_v_**\n     of that output.\n\n 4.  **Updates the [accumulated coin\n     selection](#accumulated-coin-selection-1)**:\n\n      * Adds the _output_ to the _outputs_ field;\n      * Adds the _improved UTxO selection_ to the _inputs_ field;\n      * Adds the _change value_ to the _change values_ field.\n\nThis phase ends when every output has been processed, **or** when the\n[available UTxO set](#available-utxo-set) has been exhausted, whichever occurs\nsooner.\n\n##### Termination\n\nWhen both phases are complete, the algorithm terminates.\n\nThe [accumulated coin selection](#accumulated-coin-selection-1) is returned\nto the caller as the [coin selection](#coin-selection) result.\n\nThe [available UTxO set](#available-utxo-set) is returned to the caller as the\n[remaining UTxO set](#remaining-utxo-set) result.\n\n## Rationale\n\n### Largest-First\n\n\\-\n\n### Random-Improve\n\nThere are several motivating principles behind the design of the algorithm.\n\n#### Principle 1: Dust Management\n\nThe probability that random selection will choose dust entries from a UTxO\nset _increases_ with the proportion of dust in the set.\n\nTherefore, for a UTxO set with a large amount of dust, there's a high\nprobability that a random subset will include a large amount of dust.\n\nOver time, selecting entries randomly in this way will tend to _limit_ the\namount of dust that accumulates in the UTxO set.\n\n#### Principle 2: Change Management\n\nAs mentioned in the [Goals](#goals-of-coin-selection-algorithms) section, it is\ndesirable that coin selection algorithms, over time, are able to create UTxO\nsets that have _useful_ outputs: outputs that will allow us to process future\npayments with a _reasonably small_ number of inputs.\n\nIf for each payment request of value **_v_** we create a change output of\n_roughly_ the same value **_v_**, then we will end up with a distribution of\nchange values that matches the typical value distribution of payment\nrequests.\n\n> :bulb: **Example**\n>\n> Alice often buys bread and other similar items that cost around €1.00 each.\n>\n> When she instructs her wallet software to make a payment for around\n> €1.00, the software attempts to select a set of unspent transaction outputs\n> with a total value of around €2.00.\n>\n> As she frequently makes payments for similar amounts, transactions created by\n> her wallet will also frequently produce change coins of around €1.00 in value.\n>\n> Over time, her wallet will self-organize to contain multiple coins of around\n> €1.00, which are useful for the kinds of payments that Alice frequently makes.\n\n#### Principle 3: Performance Management\n\nSearching the UTxO set for additional entries to _improve_ our change outputs\nis _only_ useful if the UTxO set contains entries that are sufficiently\nsmall enough. But it is precisely when the UTxO set contains many small\nentries that it is less likely for a randomly-chosen UTxO entry to push the\ntotal above the upper bound.\n\n### External Resources\n\n#### Self Organisation in Coin Selection\n\n> | **Title** | Self Organisation in Coin Selection |\n> |:--|:--|\n> | **Author** | [Edsko de Vries](http://www.edsko.net/) |\n> | **Year** | 2018 |\n> | **Location** | https://iohk.io/en/blog/posts/2018/07/03/self-organisation-in-coin-selection/ |\n>\n> This article introduces the [Random-Improve](#random-improve) coin selection\n> algorithm, invented by [Edsko de Vries](http://www.edsko.net/).\n>\n> It describes the three principles of self-organisation that inform the\n> algorithm's design, and provides experimental evidence to demonstrate the\n> algorithm's effectiveness at maintaining healthy UTxO sets over time.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] There exists one or more reference implementations with appropriate testing illustrating the various properties of coin-selection stated in this document.\n\n### Implementation Plan\n\n#### Reference Implementations\n\n##### Largest-First\n\nReference implementations of the [Largest-First](#largest-first) algorithm are\navailable in the following languages:\n\n| _Language_ | _Documentation_ | _Source_ |\n| -- | -- | -- |\n| **Haskell** | [Documentation](https://hackage.haskell.org/package/cardano-coin-selection/docs/Cardano-CoinSelection-Algorithm-LargestFirst.html) | [Source](https://hackage.haskell.org/package/cardano-coin-selection/docs/src/Cardano.CoinSelection.Algorithm.LargestFirst.html) |\n\n##### Random-Improve\n\nReference implementations of the [Random-Improve](#random-improve) algorithm\nare available in the following languages:\n\n| _Language_ | _Documentation_ | _Source_ |\n| -- | -- | -- |\n| **Haskell** | [Documentation](https://hackage.haskell.org/package/cardano-coin-selection/docs/Cardano-CoinSelection-Algorithm-RandomImprove.html) | [Source](https://hackage.haskell.org/package/cardano-coin-selection/docs/src/Cardano.CoinSelection.Algorithm.RandomImprove.html) |\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0003/Byron.md",
    "content": "# Byron key format\n\n- **Deprecated**: yes\n- **Summary**: used by old versions of Daedalus to generate addresses starting with `Ddz`.\n\n## Code\n\n```js\nfunction generateMasterKey(seed) {\n    return hashRepeatedly(seed, 1);\n}\n\nfunction hashRepeatedly(key, i) {\n    (iL, iR) = HMAC\n        ( hash=SHA512\n        , key=key\n        , message=\"Root Seed Chain \" + UTF8NFKD(i)\n        );\n\n    let prv = tweakBits(SHA512(iL));\n\n    if (prv[31] & 0b0010_0000) {\n        return hashRepeatedly(key, i+1);\n    }\n\n    return (prv + iR);\n}\n\nfunction tweakBits(data) {\n    // * clear the lowest 3 bits\n    // * clear the highest bit\n    // * set the highest 2nd bit\n    data[0]  &= 0b1111_1000;\n    data[31] &= 0b0111_1111;\n    data[31] |= 0b0100_0000;\n\n    return data;\n}\n```\n## Test vectors\n\n<details>\n  <summary>Requires no iteration</summary>\n\n  recovery phrase\n  ```\n  roast crime bounce convince core happy pitch safe brush exit basic among\n  ```\n\n  master key\n  ```\n  60f6e2b12f4c51ed2a42163935fd95a6c39126e88571fe5ffd0332a4924e5e5e9ceda72e3e526a625ea86d16151957d45747fff0f8fcd00e394b132155dfdfc2918019cda35f1df96dd5a798da4c40a2f382358496e6468e4e276db5ec35235f\n  ```\n</details>\n\n---\n\n<details>\n  <summary>Requires 4 iterations</summary>\n\n  recovery phrase\n  ```\n  legend dismiss verify kit faint hurdle orange wine panther question knife lion\n  ```\n\n  master key\n  ```\n  c89fe21ec722ee174be77d7f91683dcfd307055b04613f064835bf37c58f6a5f362a4ce30a325527ff66b6fbaa43e57c1bf14edac749be3d75819e7759e9e6c82b264afa7c1fd5b3cd51be3053ccbdb0224f82f7d1c7023a96ce97cb4efca945\n  ```\n</details>\n"
  },
  {
    "path": "CIP-0003/CIP-0003.md",
    "content": "Moved to [CIP-0003/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0003/Icarus.md",
    "content": "# Icarus key format\n\n- **Deprecated**: no\n- **Summary**: Used by Yoroi during the Byron-era (with Byron-style addresses starting with Ae2). Currently used for all Shelley-era wallets.\n\n*Note*: Also supports setting an extra passphrase as an arbitrary byte array of any size (sometimes called a *mnemonic password*). This passphrase acts as a second factor applied to cryptographic key retrieval. When the seed comes from an encoded recovery phrase, the password can therefore be used to add extra protection in case where the recovery phrase were to be exposed.\n\n## Code\n\n```js\nfunction generateMasterKey(seed, password) {\n    let data = PBKDF2\n        ( kdf=HMAC-SHA512\n        , iter=4096\n        , salt=seed\n        , password=password\n        , outputLen=96\n        );\n\n    return tweakBits(data);\n}\n\nfunction tweakBits(data) {\n    // on the ed25519 scalar leftmost 32 bytes:\n    // * clear the lowest 3 bits\n    // * clear the highest bit\n    // * clear the 3rd highest bit\n    // * set the highest 2nd bit\n    data[0]  &= 0b1111_1000;\n    data[31] &= 0b0001_1111;\n    data[31] |= 0b0100_0000;\n\n    return data;\n}\n```\n## Test vectors\n\n<details>\n  <summary>No passphrase</summary>\n\n  recovery phrase\n  ```\n  eight country switch draw meat scout mystery blade tip drift useless good keep usage title\n  ```\n\n  master key\n  ```\n  c065afd2832cd8b087c4d9ab7011f481ee1e0721e78ea5dd609f3ab3f156d245d176bd8fd4ec60b4731c3918a2a72a0226c0cd119ec35b47e4d55884667f552a23f7fdcd4a10c6cd2c7393ac61d877873e248f417634aa3d812af327ffe9d620\n  ```\n</details>\n\n---\n\n<details>\n  <summary>With passphrase</summary>\n\n  recovery phrase\n  ```\n  eight country switch draw meat scout mystery blade tip drift useless good keep usage title\n  ```\n\n  passphrase\n  ```\n  foo (as utf8 bytes)\n  ```\n\n  master key\n  ```\n  70531039904019351e1afb361cd1b312a4d0565d4ff9f8062d38acf4b15cce41d7b5738d9c893feea55512a3004acb0d222c35d3e3d5cde943a15a9824cbac59443cf67e589614076ba01e354b1a432e0e6db3b59e37fc56b5fb0222970a010e\n  ```\n</details>\n\n## Trezor\n\nWhen used < 24 words, the algorithm is the same as **Icarus**\n\nWhen using 24 words, due to incorrect removal of the [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#generating-the-mnemonic) entropy checksum bits (via integer division by 8, incorrectly assuming the entropy checksum is always less than 8 bits), the entropy bytes are passed into the `generateMasterKey()` function together with the checksum which for 24-word mnemonics happens to be 8 bits = 1 byte. This bug has been identified and documented in the following Trezor firmware pull request: https://github.com/trezor/trezor-firmware/pull/1388\n\n*Note*: Trezor also allows users to set an additional [passphrase](https://wiki.trezor.io/Passphrase) that works exactly the same as Icarus passphrase\n"
  },
  {
    "path": "CIP-0003/Ledger_BitBox02.md",
    "content": "# Ledger/BitBox02 key format\n\n- **Deprecated**: no\n- **Summary**: Used by Ledger hardware wallets\n\nReference implementation by Ledger: [HDEd25519.py](https://github.com/LedgerHQ/orakolo/blob/0b2d5e669ec61df9a824df9fa1a363060116b490/src/python/orakolo/HDEd25519.py)\n\nImplementation by BitBox02: [keystore.c](https://github.com/digitalbitbox/bitbox02-firmware/blob/1e36dbfb3c71c3a9d8ea81fe6fad13b18dd735a4/src/keystore.c#L676-L709)\n\n*Note*: Ledger and BitBox02 also allow users to set an additional [passphrase](https://support.ledger.com/hc/en-us/articles/115005214529-Advanced-passphrase-security)\n\n## Code\n\n```js\nfunction generateMasterKey(seed, password) {\n    let data = PBKDF2\n        ( kdf=HMAC-SHA512\n        , iter=2048\n        , salt=\"mnemonic\" + UTF8NFKD(password)\n        , password=UTF8NFKD(spaceSeparated(toMnemonic(seed)))\n        , outputLen=64\n        );\n\n    let cc = HMAC\n        ( hash=SHA256\n        , key=\"ed25519 seed\"\n        , message=UTF8NFKD(1) + data\n        );\n\n    let (iL, iR) = hashRepeatedly(data);\n\n    return (tweakBits(iL) + iR + cc);\n}\n\nfunction hashRepeatedly(message) {\n    let (iL, iR) = HMAC\n        ( hash=SHA512\n        , key=\"ed25519 seed\"\n        , message=message\n        );\n\n    if (iL[31] & 0b0010_0000) {\n        return hashRepeatedly(iL + iR);\n    }\n\n    return (iL, iR);\n}\n\nfunction tweakBits(data) {\n    // * clear the lowest 3 bits\n    // * clear the highest bit\n    // * set the highest 2nd bit\n    data[0]  &= 0b1111_1000;\n    data[31] &= 0b0111_1111;\n    data[31] |= 0b0100_0000;\n\n    return data;\n}\n```\n\n## Test vectors\n\n<details>\n  <summary>No passphrase no iterations</summary>\n\n  recovery phrase\n  ```\n  recall grace sport punch exhibit mad harbor stand obey short width stem awkward used stairs wool ugly trap season stove worth toward congress jaguar\n  ```\n\n  master key\n  ```\n  a08cf85b564ecf3b947d8d4321fb96d70ee7bb760877e371899b14e2ccf88658104b884682b57efd97decbb318a45c05a527b9cc5c2f64f7352935a049ceea60680d52308194ccef2a18e6812b452a5815fbd7f5babc083856919aaf668fe7e4\n  ```\n</details>\n\n---\n\n<details>\n  <summary>No passphrase with iterations</summary>\n\n  recovery phrase\n  ```\n  correct cherry mammal bubble want mandate polar hazard crater better craft exotic choice fun tourist census gap lottery neglect address glow carry old business\n  ```\n\n  master key\n  ```\n  587c6774357ecbf840d4db6404ff7af016dace0400769751ad2abfc77b9a3844cc71702520ef1a4d1b68b91187787a9b8faab0a9bb6b160de541b6ee62469901fc0beda0975fe4763beabd83b7051a5fd5cbce5b88e82c4bbaca265014e524bd\n  ```\n</details>\n\n---\n\n<details>\n  <summary>With passphrase</summary>\n\n  recovery phrase\n  ```\n  abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon art\n  ```\n\n  passphrase\n  ```\n  foo (as utf8 bytes)\n  ```\n\n  master key\n  ```\n  f053a1e752de5c26197b60f032a4809f08bb3e5d90484fe42024be31efcba7578d914d3ff992e21652fee6a4d99f6091006938fac2c0c0f9d2de0ba64b754e92a4f3723f23472077aa4cd4dd8a8a175dba07ea1852dad1cf268c61a2679c3890\n  ```\n</details>\n"
  },
  {
    "path": "CIP-0003/README.md",
    "content": "---\nCIP: 3\nTitle: Wallet Key Generation\nStatus: Active\nCategory: Wallets\nAuthors:\n    - Matthias Benkort <matthias.benkort@cardanofoundation.org>\n    - Sebastien Guillemot <seba@dcspark.io>\nImplementors:\n    - Matthias Benkort <matthias.benkort@cardanofoundation.org>\n    - Sebastien Guillemot <seba@dcspark.io>\nDiscussions:\n    - https://github.com/input-output-hk/implementation-decisions/pull/18\n    - https://github.com/cardano-foundation/cips/pull/33\n    - https://github.com/cardano-foundation/cips/pull/76\n    - https://github.com/cardano-foundation/cips/pull/132\nCreated: 2020-05-07\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nMany wallets utilize some way of mapping a sentence of words (easy to read and write for humans) uniquely back and forth to a sized binary data (harder to remember).\n\nThis document outlines the various mapping algorithms used in the Cardano ecosystem.\n\n## Motivation: why is this CIP necessary?\n\nThe philosophy of cryptocurrencies is that you are in charge of your own finances. Therefore, it is very anti-thematic for wallet software to lock in a user by explicitly describing the algorithm used to derive keys for a wallet (both the master key and key derivation)\n\nTo this end, this document outlines all the relevant key generation algorithms used in the Cardano ecosystem.\n\n## Specification\n\n### Recovery Phrase (mnemonic) Generation\n\nConversion from a recovery phrase to entropy is the same as described in [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md).\n\n### Hierarchical Deterministic Wallets\n\nIn Cardano, hierarchical deterministic (abbrev. HD) wallets are similar to those described in [BIP-0032](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). Notably, we use a variation called [ED25519-BIP32](https://github.com/input-output-hk/adrestia/raw/bdf00e4e7791d610d273d227be877bc6dd0dbcfb/user-guide/static/Ed25519_BIP.pdf). A reference implementation can be found [here](https://docs.rs/ed25519-bip32/).\n\n### Master Key Generation\n\nThe master key generation is the mean by which on turns an initial entropy into a secure cryptographic key.\n\nMore specifically, the generation is a function from an initial seed to an extended private key (abbrev. XPrv) composed of:\n\n- 64 bytes: an extended Ed25519 secret key composed of:\n  - 32 bytes: Ed25519 curve scalar from which few bits have been tweaked according to ED25519-BIP32\n  - 32 bytes: Ed25519 binary blob used as IV for signing\n- 32 bytes: chain code for allowing secure child key derivation\n\n#### History\n\nThroughout the years, Cardano has used different styles of master key generation:\n\n| Name                                    | Used by         | Address prefix in Byron | Is deprecated? | Is Recommended? |\n|-----------------------------------------|-----------------|-------------------------|----------------|-----------------|\n| [Byron](./Byron.md)                     | Daedalus        | Ddz                     | Yes            | No              |\n| [Icarus](./Icarus.md)                   | Yoroi, Daedalus | Ae2                     | No             | Yes             |\n| [Icarus-Trezor](./Icarus.md)            | Trezor          | Ae2                     | No             | No              |\n| [Ledger/BitBox02](./Ledger_BitBox02.md) | Ledger/BitBox02 | Ae2                     | No             | No              |\n\n## Rationale: how does this CIP achieve its goals?\n\nThis CIP is merely to document the existing standards and not to provide rationales for the various methods used.\n\nHowever, you can learn more at the following links:\n\n- [Adrestia documentation](https://cardano-foundation.github.io/cardano-wallet/concepts/master-key-generation)\n- [SLIP-0010](https://github.com/satoshilabs/slips/blob/master/slip-0010.md)\n- [SLIP-0023](https://github.com/satoshilabs/slips/blob/master/slip-0023.md)\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Each generation method is documented and provides test vectors in a language-agnostic way.\n- [x] There exists reference implementations in various languages for each method.\n- [x] At least 2 Cardano wallets (e.g. Yoroi & Daedalus) implement these methods.\n\n### Implementation Plan\n\n- [x] Implementation of each algorithm will be carried out in Yoroi and Daedalus (via cardano-wallet) by Emurgo and Input Output respectively.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0004/CIP-0004.md",
    "content": "Moved to [CIP-0004/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0004/README.md",
    "content": "---\nCIP: 4\nTitle: Wallet Checksums\nStatus: Proposed\nCategory: Wallets\nAuthors:\n  - Ruslan Dudin <ruslan@emurgo.io>\n  - Sebastien Guillemot <seba@dcspark.io>\nImplementors:\n  - Ruslan Dudin <ruslan@emurgo.io>\n  - Sebastien Guillemot <seba@dcspark.io>\nDiscussions:\n  - https://forum.cardano.org/t/cip4-wallet-checksum/32819\n  - https://github.com/cardano-foundation/CIPs/pull/4\nCreated: 2019-05-01\nLicense: Apache-2.0\n---\n\n## Abstract\n\nWe introduce a checksum algorithm to help users verify they are restoring the right wallet before the restoration actually takes place.\n\n## Motivation: why is this CIP necessary?\n\nUsers occasionally enter the wrong [mnemonic](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) for their wallet. In this case, they simply see a 0 ADA wallet after syncing is over. This not only wastes the user's time, in the worst case it makes them think they either lost all their ADA or think there is a bug in the wallet implementation.\n\nTo solve this, we introduce a checksum that can be computed without having to perform wallet restoration.\n\n## Specification\n\nFirst, it's important to note that the method for generating a checksum is heavily dependent on the type of wallet (ex: BIP44, etc.). We outline an algorithm that works with most, but not all, types of wallet.\n\n### Requirements for checksum\n\n1) Easily recomputed without access to mnemonic, private key or other similarly sensitive data\n2) Does not reveal anything about the wallet (irreversible -- cannot tell addresses, private key, etc. from just seeing the checksum)\n3) Negligible chance of collision\n4) Easy to memorize for the user\n5) Can be easily saved both digitally or on paper\n\n### Implementation Outline\n\nTo satisfy (1), the checksum SHOULD be seeded from the public key for the wallet. Notably, in the [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) case, it should come from the bip44 account derivation level's public key.\n**Note**: For HD wallets, the public key used SHOULD contain the chaincode also because we need to make sure that not just the public key, but all its child keys also, are properly generated.\n\nTo satisfy (2) and (3), the a hash of the public key is used\n\nTo satisfy (4) and (5), we generate for an *ImagePart* and a *TextPart*. The brain can roughly remember images allowing you to quickly dismiss checksums that look totally different. However, since images can sometimes be similar, a *TextPart* is also provided for double-checking. Additionally, if the user does not have access to a printer, the text part can be easily written down by hand on a piece of paper to satisfy (5).\n\n## Rationale: how does this CIP achieve its goals?\n\nWe first provide a template for the code, explain the template and then provide the parameterization we use for Cardano\n\n```js\nfunction calculateChecksum(publicKeyHash: string /* note: lowercase hex representation */) {\n  const hash = hash1(publicKeyHash);\n  const [a, b, c, d] = hash_to_32(hash); // get a 4 byte value from the hash\n  const alpha = `ABCDEJHKLNOPSTXZ`; // take 16 letters from the alphabet that are easy to distinguish\n\n  // construct the TextPart from a group of letters and a group of numbers\n  const letters = x => `${alpha[Math.floor(x / 16)]}${alpha[x % 16]}`;\n  const numbers = `${((c << 8) + d) % 10000}`.padStart(4, '0');\n  const id = `${letters(a)}${letters(b)}-${numbers}`;\n\n  return {\n    hash, // used to generate the ImagePart\n    id, // used as the TextPart\n  };\n}\n```\n\n### TextPart rationale\n\nFor ease of perception it seems that short alphanumeric sequences are the best for humans to remember, especially when letters and numbers are separated and not mixed together.\n\n#### Letter part\n\nFor letters, we render the bytes in hex, but replace the alphanumeric used in hex with this letter-only alphabet:\n\n`A B C D E J H K L N O P S T X Z`\n\nThis alphabet satisfies the following requirements:\n\n1) Has exactly 16 letters (one-to-one mapping with 2 bytes in HEX)\n1) Does not contain characters that look too much like each other\n1) Minimizes occurrences of undesirable words in [this list](https://www.noswearing.com/fourletterwords.php).\n\n#### Number part\n\nThe last two bytes are compressed to a 4-digit number. For this we will simply take the last 4 digits of the 16-bit integer number constructed from 2 bytes as `((A << 8) + B) % 10000` (zero-padded).\n\nThis above produces 10000 unique values across all possible values of A and B and giving maximum of 7 potential collisions per value and 6.5 average collisions per value, which is the minimum, given the fact that we reduce maximum potential number 65536 to 4 digits.\n**Note**: resulting number is zero-padded to 4 digits.\n\n### ImagePart rationale\n\nFor the image, we take the result of `hash1` and use it as the seed for the [blockies](https://github.com/ethereum/blockies) library.\n\nThis library in particular has the following benefits:\n\n- Has been audited\n- Used by other blockchains and therefore has common libraries for implementation\n\n**Note**: This library internally re-hashes its input to a 128-bit entropy string\n\n### Hash algorithms used in Byron + ITN\n\nFor `hash1`, we use `blake2b512`. [Blake2b](https://tools.ietf.org/html/rfc7693) is a standardized hash function that is used in Cardano for other purposes like key derivations. Reusing blake2b means one less dependency. We use `512` bytes of output to try and future-proof this algorithm (better to spread the entropy across more bits than needed than end up not capturing the full entropy in the future).\n\nFor `hash_to_32` we use CRC32. We hash a second time for the following:\n\n1) The *TextPart* is constructed from 4 bytes (2 for letters, 2 for numbers) and so we need to project the result of `hash1` down to 4 bytes.\n2) We don't want to simply take the last 4 bytes of `hash1` because that would reveal part of the input used to generate the *ImagePart*. Although strictly speaking this should not be of a concern (since the result of `hash1` doesn't reveal any information about the original key), we take this as a precaution.\n3) `CRC32` is used in the Byron implementation of Cardano as a checksum for addresses, meaning no additional dependency has to be added.\n\nAlthough there is no specification for CRC32 and many variations exist, in Cardano we use the CRC-32-IEEE variation. You can find a C implementation [here](https://github.com/cardano-foundation/ledger-app-cardano/blob/3f784d23c1b87df73cda552ef01428d3e2733237/src/crc32.c#L6)\n\n### Hash algorithms used in Shelley mainnet\n\n1) For `hash1`, we still use `blake2b512` but we now set the blake2b `personalization` to the the utf-8 byte equivalent of `wallets checksum` (exactly 16 utf-8 bytes in length) to avoid collision with any other standard that decides to hash a public key.\n2) For `hash_to_32`, we no longer use `crc32` for the following reasons:\n\n- It has multiple competing implementations all called `crc32` (easily to get the wrong implementation library)\n- It requires building a lookup table, making it slower than other hashing algorithms for similar safety\n- Cardano no longer uses `crc32` in the Shelley mainnet as addresses now use [BIP173 - bech32](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) which has its own checksum algorithm.\n\nInstead, we replace it with [FNV-1a](https://tools.ietf.org/html/draft-eastlake-fnv-10) in 32-bit mode. FNV-1a is fast, easy to implement inline and gives good empirical distribution.\n\n### When no public key is present\n\nNote that a different construction is needed for wallet types which do not have a public key (such as a balance tracking application which simply manages a set of addresses). In the balanace tracking case, simply hashing the set of addresses used is possible, but it means that adding & removing an address would change the checksum (possibly unintuitive). Since the checksum is meant to represent the wallet itself, we also cannot run a checksum on the name of the wallet or any other user-inputted data.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] There exists a reference implementation with test vectors.\n- [ ] Checksums are adopted by two or more wallets.\n  - [x] Yoroi\n\n### Implementation Plan\n\n- [x] Reference implementations:\n  - [Javascript](https://github.com/Emurgo/CIP4)\n\n## Copyright\n\nThis CIP is licensed under Apache-2.0\n"
  },
  {
    "path": "CIP-0005/CIP-0005.md",
    "content": "Moved to [CIP-0005/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0005/README.md",
    "content": "---\nCIP: 5\nTitle: Common Bech32 Prefixes\nCategory: Tools\nStatus: Active\nAuthors:\n  - Matthias Benkort <matthias.benkort@cardanofoundation.org>\nImplementors: N/A\nDiscussions:\n  - https://forum.cardano.org/t/cip5-common-bech32-prefixes/35189\n  - https://github.com/cardano-foundation/CIPs/pull/427\n  - https://github.com/cardano-foundation/CIPs/pull/342\n  - https://github.com/cardano-foundation/CIPs/pull/251\n  - https://github.com/cardano-foundation/CIPs/pull/177\n  - https://github.com/cardano-foundation/CIPs/pull/31\nCreated: 2020-05-28\nLicense: Apache-2.0\n---\n\n## Abstract\n\nThis CIP defines a set of common prefixes (or so-called human-readable part in the [bech32](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)) encoding format) for various bech32-encoded binary data across the Cardano eco-system.\n\n## Motivation: why is this CIP necessary?\n\nMany tools used within the Cardano eco-system are manipulating binary data. Binary data are typically encoded as hexadecimal text strings when shown in a user interface (might it be a console, a url or a structured document from a server). From the user perspective, it can be difficult to distinguish between various encoded data. From the tools developer perspective, it can also be difficult to validate inputs based only on raw bytes (in particular when encoded data often have the same length).\n\nTherefore, we can leverage bech32 for binary data encoding, with a set of common prefixes that can be used across tools and software to disambiguate payloads.\n\n## Specification\n\nWe define the following set of common prefixes with their corresponding semantic. Any software willing to represent binary data in a human-friendly way should abide by these guidelines. Should a data-type be missing, we encourage developers to update this CIP and register a new prefix.\n\n### Keys\n\n| Prefix             | Meaning                                                               | Contents                           |\n| ---                | ---                                                                   | ---                                |\n| `acct_sk`          | CIP-1852's account private key                                        | Ed25519 private key                |\n| `acct_vk`          | CIP-1852's account public key                                         | Ed25519 public key                 |\n| `acct_xsk`         | CIP-1852's extended account private key                               | Ed25519-bip32 extended private key |\n| `acct_xvk`         | CIP-1852's extended account public key                                | Ed25519 public key with chain code |\n| `acct_shared_sk`   | CIP-1854's account private key                                        | Ed25519 private key                |\n| `acct_shared_vk`   | CIP-1854's account public key                                         | Ed25519 public key                 |\n| `acct_shared_xsk`  | CIP-1854's extended account private key                               | Ed25519-bip32 extended private key |\n| `acct_shared_xvk`  | CIP-1854's extended account public key                                | Ed25519 public key with chain code |\n| `addr_sk`          | CIP-1852's address signing key                                        | Ed25519 private key                |\n| `addr_vk`          | CIP-1852's address verification key                                   | Ed25519 public key                 |\n| `addr_xsk`         | CIP-1852's address extended signing key                               | Ed25519-bip32 extended private key |\n| `addr_xvk`         | CIP-1852's address extended verification key                          | Ed25519 public key with chain code |\n| `addr_shared_sk`   | CIP-1854's address signing key                                        | Ed25519 private key                |\n| `addr_shared_vk`   | CIP-1854's address verification key                                   | Ed25519 public key                 |\n| `addr_shared_xsk`  | CIP-1854's address extended signing key                               | Ed25519-bip32 extended private key |\n| `addr_shared_xvk`  | CIP-1854's address extended verification key                          | Ed25519 public key with chain code |\n| `cc_cold_sk`       | CIP-1852’s constitutional committee cold signing key                  | Ed25519 private key                |\n| `cc_cold_vk`       | CIP-1852’s constitutional committee verification signing key          | Ed25519 private key                |\n| `cc_cold_xsk`      | CIP-1852’s constitutional committee cold extended signing key         | Ed25519-bip32 extended private key |\n| `cc_cold_xvk`      | CIP-1852’s constitutional committee extended verification signing key | Ed25519 public key with chain code |\n| `cc_hot_sk`        | CIP-1852’s constitutional committee hot signing key                   | Ed25519 private key                |\n| `cc_hot_vk`        | CIP-1852’s constitutional committee verification signing key          | Ed25519 private key                |\n| `cc_hot_xsk`       | CIP-1852’s constitutional committee hot extended signing key          | Ed25519-bip32 extended private key |\n| `cc_hot_xvk`       | CIP-1852’s constitutional committee extended verification signing key | Ed25519 public key with chain code |\n| `cvote_sk`         | CIP-36's vote signing key                                             | Ed25519 private key                |\n| `cvote_vk`         | CIP-36's vote verification key                                        | Ed25519 public key                 |\n| `drep_sk`          | CIP-1852’s DRep signing key                                           | Ed25519 private key                |\n| `drep_vk`          | CIP-1852’s DRep verification key                                      | Ed25519 public key                 |\n| `drep_xsk`         | CIP-1852’s DRep extended signing key                                  | Ed25519-bip32 extended private key |\n| `drep_xvk`         | CIP-1852’s DRep extended verification key                             | Ed25519 public key with chain code |\n| `gen_sk`           | Genesis signing key                                                   | Ed25519 private key                |\n| `gen_vk`           | Genesis verification key                                              | Ed25519 public key                 |\n| `gen_deleg_sk`     | Genesis delegate private key                                          | Ed25519 private key                |\n| `gen_deleg_vk`     | Genesis delegate public key                                           | Ed25519 public key                 |\n| `gen_utxo_sk`      | Genesis UTXO private key                                              | Ed25519 private key                |\n| `gen_utxo_vk`      | Genesis UTXO public key                                               | Ed25519 public key                 |\n| `kes_sk`           | KES signing key                                                       | KES signing key                    |\n| `kes_vk`           | KES verification key                                                  | KES verification key               |\n| `policy_sk`        | CIP-1855's policy private key                                         | Ed25519 private key                |\n| `policy_vk`        | CIP-1855's policy public key                                          | Ed25519 public key                 |\n| `pool_sk`          | Pool operator signing key                                             | Ed25519 private key                |\n| `pool_vk`          | Pool operator verification key                                        | Ed25519 public key                 |\n| `pool_xsk`         | Pool operator extended signing key                                    | Ed25519-bip32 extended private key |\n| `pool_xvk`         | Pool operator extended verification key                               | Ed25519 public key with chain code |\n| `root_sk`          | CIP-1852's root private key                                           | Ed25519 private key                |\n| `root_vk`          | CIP-1852's root public key                                            | Ed25519 public key                 |\n| `root_xsk`         | CIP-1852's extended root private key                                  | Ed25519-bip32 extended private key |\n| `root_xvk`         | CIP-1852's extended root public key                                   | Ed25519 public key with chain code |\n| `root_shared_sk`   | CIP-1854's root private key                                           | Ed25519 private key                |\n| `root_shared_vk`   | CIP-1854's root public key                                            | Ed25519 public key                 |\n| `root_shared_xsk`  | CIP-1854's extended root private key                                  | Ed25519-bip32 extended private key |\n| `root_shared_xvk`  | CIP-1854's extended root public key                                   | Ed25519 public key with chain code |\n| `stake_sk`         | CIP-1852's stake address signing key                                  | Ed25519 private key                |\n| `stake_vk`         | CIP-1852's stake address verification key                             | Ed25519 public key                 |\n| `stake_xsk`        | CIP-1852's extended stake address signing key                         | Ed25519-bip32 extended private key |\n| `stake_xvk`        | CIP-1852's extended stake address verification key                    | Ed25519 public key with chain code |\n| `stake_shared_sk`  | CIP-1854's stake address signing key                                  | Ed25519 private key                |\n| `stake_shared_vk`  | CIP-1854's stake address verification key                             | Ed25519 public key                 |\n| `stake_shared_xsk` | CIP-1854's extended stake address signing key                         | Ed25519-bip32 extended private key |\n| `stake_shared_xvk` | CIP-1854's extended stake address verification key                    | Ed25519 public key with chain code |\n| `vrf_sk`           | VRF signing key                                                       | VRF signing key                    |\n| `vrf_vk`           | VRF verification key                                                  | VRF verification key               |\n\n### Hashes\n\n| Prefix                 | Meaning                                                               | Contents                                                                 |\n| ---                    | ---                                                                   | ---                                                                      |\n| `asset`                | Fingerprint of a native asset for human comparison                    | See [CIP-0014]                                                           |\n| `pool`                 | Pool operator verification key hash (pool ID)                         | blake2b\\_224 digest of an operator verification key                      |\n| `script`               | Script hash                                                           | blake2b\\_224 digest of a serialized transaction script                   |\n| `addr_vkh`             | Address verification key hash                                         | blake2b\\_224 digest of a payment verification key                        |\n| `addr_shared_vkh`      | Shared address verification key hash                                  | blake2b\\_224 digest of a payment verification key                        |\n| `policy_vkh`           | Policy verification key hash                                          | blake2b\\_224 digest of a policy verification key                         |\n| `stake_vkh`            | Stake address verification key hash                                   | blake2b\\_224 digest of a delegation verification key                     |\n| `stake_shared_vkh`     | Shared stake address verification key hash                            | blake2b\\_224 digest of a delegation verification key                     |\n| `req_signer_vkh`       | Required signer verification key hash                                 | blake2b\\_224 digest of a required signer verification key                |\n| `vrf_vkh`              | VRF verification key hash                                             | blake2b\\_256 digest of a VRF verification key                            |\n| `datum`                | Output datum hash                                                     | blake2b\\_256 digest of output datum                                      |\n| `script_data`          | Script data hash                                                      | blake2b\\_256 digest of script data                                       |\n| `drep_vkh`             | Delegate representative verification key hash                         | blake2b\\_224 digest of a delegate representative verification key        |\n| `cc_cold_vkh`          | Constitutional committee cold verification key hash                   | blake2b\\_224 digest of a constitutional committee cold verification key  |\n| `cc_hot_vkh`           | Constitutional committee hot verification key hash                    | blake2b\\_224 digest of a constitutional committee hot verification key   |\n\n### Miscellaneous\n\n| Prefix              | Meaning                                               | Contents                                                      |\n| ---                 | ---                                                   | ---                                                           |\n| `addr`              | Mainnet address                                       | Network tag, payment credential and optional stake credential |\n| `addr_test`         | Testnet address                                       | Network tag, payment credential and optional stake credential |\n| `stake`             | Mainnet stake address                                 | Network tag and stake credential                              |\n| `stake_test`        | Testnet stake address                                 | Network tag and stake credential                              |\n| `drep`              | DRep identifier                                       | DRep credential, see [CIP-0129]                               |\n| `cc_cold`           | Constitutional committee cold identifier              | Constitutional committee cold credential, see [CIP-0129]      |\n| `cc_hot`            | Constitutional committee hot identifier               | Constitutional committee hot credential, see [CIP-0129]       |\n| `gov_action`        | Governance action identifier                          | Governance action ID, see [CIP-0129]                          |\n\n\n### Deprecated Governance Prefixes\n\nThe some governance prefixes contained within the tables above were originally defined via [CIP-0105].\nWith the authoring of and acceptance of [CIP-0129], the community decide to replace some governance prefix definitions whilst depreciating others.\n\nFurther details on the depreciation and replacement of definitions can be seen via [CIP-105 Deprecated Governance ID Definition](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0105#deprecated-governance-id-definition).\n\nBelow is a table of entries of prefix definitions which were defined via [CIP-0105], but have now been marked as depreciated as [CIP-0129] defined replacements.\\\nThe [CIP-0129] definitions are included within the tables above.\n\n| Prefix             | Meaning                                                               | Contents                                                                 |\n| ---                | ---                                                                   | ---                                                                      |\n| `drep`             | Delegate representative verification key hash (DRep ID)               | blake2b\\_224 digest of a delegate representative verification key        |\n| `drep_script`      | Delegate representative script hash (DRep ID)                         | blake2b\\_224 digest of a serialized delegate representative script       |\n| `cc_cold`          | Constitutional committee cold verification key hash (cold credential) | blake2b\\_224 digest of a constitutional committee cold verification key  |\n| `cc_cold_script`   | Constitutional committee cold script hash (cold credential)           | blake2b\\_224 digest of a serialized constitutional committee cold script |\n| `cc_hot`           | Constitutional committee hot verification key hash (hot credential)   | blake2b\\_224 digest of a constitutional committee hot verification key   |\n| `cc_hot_script`    | Constitutional committee hot script hash (hot credential)             | blake2b\\_224 digest of a serialized constitutional committee hot script  |\n\n## Rationale: how does this CIP achieve its goals?\n\n### About the `_test` suffix\n\nAddress already contains a discriminant tag, yet it requires one to peek at the internal binary payload. With Base58-encoded addresses, people have been used to look at first few characters and distinguish address this way. Not only this is cumbersome, but it is also made harder with both Shelley and Bech32-encoded addresses. On the one hand, the \"common\" part of the internal payload is much less than in Byron addresses and thus, the first bytes of the payload are varying much more. Plus, the bech32 prefix which can now be fixed makes it even more error-prone.\n\nTherefore, having a clear human-readable indicator regarding the network discrimination is useful.\n\n### About `addr`\n\nAddresses probably are the most user-facing object in the current Cardano eco-system. Being able to clearly identify them\n\n> :bulb: Open question: with side-chains and multi-currencies coming soon, would it make sense to include the currency in the bech32 prefix? e.g. `ada1...` or `ada_addr1.`\n\n### About `stake`\n\nStake _addresses_ are references to reward account. They are used in many manipulation involving rewards (registering stake key, delegating, fetching reward balance etc..). We therefore make it a \"first-class\" object and assign it a dedicated prefix.\n\n### About `sk` & `vk`\n\nBoth are rather transparent abbreviations for **s**igning **k**ey and **v**erification **k**ey.\n\n### About `xsk` & `xvk`\n\nThe prefix `x` is typically used in cryptography to refer to e**x**tended keys (e.g. `xpub`, `xprv` ...). Following this convention, we prefix `sk` and `vk` as such when they refer to extended keys.\n\n### About `vkh`\n\nAn abbreviation for **v**erification **k**ey **h**ash.\n\nVerification key hashes are commonly utilized throughout the Cardano\neco-system. For example, they're used in stake pool registration and\nretirement certificates, stake key registration, delegation, and\nderegistration certificates, etc. As a result, it seems useful to have a\nhuman-readable prefix by which one can discern the different kinds of\nverification key hashes.\n\n### Backwards compatibility\n\nThe only prior work done towards that direction has been [jcli](https://input-output-hk.github.io/jormungandr/jcli/introduction.html). Historically, prefixes evolved very organically and without any agreed-upon standard. jcli is however only compatible with Jörmungandr and is not intended to be compatible with the cardano-node. Therefore, there's little concern regarding compatibility here.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] There is a variety of tools and services utilizing this standard:\n  - [x] Trezor, Ledger\n  - [x] cardano-cli\n  - [x] cardano-wallet\n  - [x] Blockfrost\n  - [x] cardanoscan, cexplorer\n  - [x] cardano-signer \n  - ... and more\n\n### Implementation Plan\n\n- Available JavaScript library: [cip5-js](https://www.npmjs.com/package/@dcspark/cip5-js)\n\n## Changelog\n\nIn order to make it easy to keep up with updates to this CIP, we include the following table as a log of the changes sorted in decreasing order of date. Changes to the CIP should include an entry at the top of the table that includes a unique sequential identifier of the change, the date of the changes (in the format YYYY-MM-DD), a summary of the changes, and a link to the pull request that introduces the changes.\n\n| ID  | Date        | Summary of changes                                              | Pull Request                                                  |\n| --- | ---         | ---                                                             | ---                                                           |\n| 2   | 2025-05-13  | Defined bech32 prefixes for extended pool operator keys         | [#1036](https://github.com/cardano-foundation/CIPs/pull/1036) |\n| 1   | 2025-04-22  | Defined bech32 prefixes for genesis keys and created changelog. | [#1027](https://github.com/cardano-foundation/CIPs/pull/1027) |\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0).\n\n[CIP-0014]: https://github.com/cardano-foundation/CIPs/blob/645243e30b5aae109a70ec2b47af70dcc808bc56/CIP-0014\n[CIP-0105]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/README.md\n[CIP-0129]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0129/README.md\n"
  },
  {
    "path": "CIP-0006/CIP-0006.md",
    "content": "Moved to [CIP-0006/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0006/README.md",
    "content": "---\nCIP: 6\nTitle: Stake Pool Extended Metadata\nStatus: Active\nCategory: Tools\nAuthors:\n  - Markus Gufler <gufmar@gmail.com>\n  - Mike Fullman <mike@fullman.net>\nImplementors:\n  - pooltool.io\n  - cexplorer.io\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/15\nCreated: 2020-07-20\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP defines the concept of extended metadata for pools that is referenced from the pool registration data stored on chain.\n\n## Motivation: why is this CIP necessary?\n\nAs the ecosystem around Cardano stake pools proliferate so will the desire to slice, organize and search pool information dynamically.  Currently the metadata referenced on chain provides 512 bytes that can be allocated across the four information categories ([delegation-design-specification Section 4.2)](https://github.com/IntersectMBO/cardano-ledger/releases/latest/download/shelley-delegation.pdf):\n\n| key           | Value                                |  Rules  |\n| ---           | ---                                  |  ---  |\n|  `ticker` | Pool ticker.  uppercase | 5 Characters Maximum, Uppercase letters and numbers |\n|  `description` | Pool Description.  Text that describes the pool | 50 Characters Maximum |\n|  `homepage` | A website URL for the pool  | 64 Characters Maximum, must be a valid URL |\n|  `name` | A name for the pool | 50 Characters Maximum |\n\nMany additional attributes can be envisioned for future wallets, pool explorers, and information aggregators.  The proposal below outlines an initial strategy for capturing this extended metadata.\n\n## Specification\n\n> **Note** Updated: 2020-11-24 2nd key-pair for validation 2021-02-08 json schema\n\n### On Chain referenced (main) metadata file\n\nWe define two more fields for the on chain referenced metadata file that references another JSON file on a URL with the extended metadata.  The proposed metadata is as follows:\n\n| key           | Value                                | Rules  |\n| ---           | ---                                  | ---  |\n|  `ticker`       | Pool ticker.  uppercase              | 5 Characters Maximum, Uppercase letters and numbers  |\n|  `description` | Pool Description.  Text that describes the pool | 50 Characters Maximum |\n|  `homepage` | A website URL for the pool| 64 Characters Maximum, must be a valid URL |\n|  `name` | A name for the pool | 50 Characters Maximum |\n| `extDataUrl` | A URL for extended metadata | optional, 128 Characters Maximum, must be a valid URL |\n| `extSigUrl` | A URL with the extended metadata signature | optional, 128 Characters Maximum, must be a valid URL |\n| `extVkey` | the public Key for verification | optional, 68 Characters |\n\nIn order to include the additional ext Field data, we suggest increasing the maximum size of the main metadata file from currently 512 to 1024 bytes.\n\n### Extended Metadata - flexible but validable\n\nIn difference to the main metadata, the extended metadata should be updateable without having to use the cold key of the pool and without having to perform an on-chain transaction. The consumer of these data should still have the possibility to verify the authenticity of the data.\n\nThe operator notes all his additional pool information in the extended metadata (`extData.json`).\n\nWe propose the pool operator generate a new public-secret key-pair (`extData.skey` and `extData.vkey`)\n\n```shell\ncardano-cli node key-gen \n  --cold-verification-key-file extData.vkey \n  --cold-signing-key-file extData.skey \n  --operational-certificate-issue-counter-file extData.counter\n```\n\nThen a new (not available yet) `cardano-cli` command generate the signature (`extData.sign`) .\n\n```shell\ncardano-cli stake-pool rawdata-sign\n  --raw-metadata-file extData.json\n  --signing-key-file extData.skey\n  --out-file extData.sign\n```\n\nThe operator now:\n\n- has the `extData.json` and `extData.sign` files\n- will publish them at some https:// URL (probably same host as the main metadata)\n- set the published `extData.json` URL in the main metadata `extDataUrl` field\n- set the published `extData.sign` URL in then main metadata `extSigUrl` field\n- set the `extData.vkey` string in the main metadata `extVkey` field\n- re-register the extended main metadata file on chain\n\nThis re-registration of the main metadata file with the `extData.vkey` and the two URLs is only necessary once. Afterwards, the operator can update his extended metadata at any time, compute the new signature with the `cardano-cli stake-pool rawdata-sign` command, and publish both files at the existing `extDataUrl` and `extSigUrl`.\n\n## Rationale: how does this CIP achieve its goals?\n\nIn the following we describe a first minimal version of the extended JSON file format.\n\nSince this extended metadata file can be updated at any time by the pool operator, a **serial number** is useful for consuming applications and services to identify updates.\n\nThere are main thematic sections with respective subordinate data fields:\n\n- the **itn** section is about the verifiable linking of an ITN pool ticker with its counterpart in Mainnet to identify fraudulent duplicates. (already used as not standardized extension)\n- the **pool** section contains additional information about the pool instance\n  - the pool.**contact** section contains information for additional information and contact data \n  - the pool.**media_assets** section contains additional information about the pools media files and colors\n  - the pool.**itn** section is an optional section for ITN pool operators  \n\nThe full schema is given in annexe as [schema.json][]\n\n<details>\n  <summary>See JSON example</summary>\n\n```json\n{\n  \"serial\": 870,\n  \"pool\": {\n    \"id\": \"69579373ec20f2f82d2dc2360410350b308112f2939f92a\",\n    \"country\": \"JPN\",\n    \"status\": \"active\",\n    \"contact\": {\n      \"primary\": \"email\",\n      \"email\": \"info@demopool.org\",\n      \"facebook\": \"demopool12\",\n      \"github\": \"demopooldev\",\n      \"feed\": \"https://www.demopool.org/feed.xml\",\n      \"telegram\": \"demopool\",\n      \"twitter\": \"demopoolbird\"\n    },\n    \"media_assets\": {\n      \"icon_png_64x64\": \"https://www.demopool.org/media/icon64.png\",\n      \"logo_png\": \"https://www.demopool.org/media/logo.png\",\n      \"logo_svg\": \"https://www.demopool.org/media/logo.svg\",\n      \"color_fg\": \"#AABBCC\",\n      \"color_bg\": \"#C0C0C0\"\n    },\n    \"itn\": {\n      \"owner\": \"ed25519_pk1...\",\n      \"witness\": \"ed25519_sig1...\"\n    }\n  }\n}\n```\n</details>\n\n### Backwards compatibility\n\nNo fields are removed or changed in the current on chain metadata.  The new `ext...` fields are optional and not necessary to parse for any entities that do not need additional information about a pool\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] There exist at least two explorers which make use of this extended metadata structure or very close equivalent:\n  - [x] pooltool.io\n  - [x] cexplorer.io\n\n### Implementation Plan\n\n- [x] Provide direct support for this specification in stake pool explorers and other tools.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[schema.json]: https://raw.githubusercontent.com/cardano-foundation/CIPs/master/CIP-0006/schema.json\n"
  },
  {
    "path": "CIP-0006/schema.json",
    "content": "{\n  \"$id\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/master/CIP-0006/schema.json\",\n  \"$schema\": \"http://json-schema.org/draft-07/schema\",\n  \"default\": {},\n  \"description\": \"Additional information for Cardano Stake Pools\",\n  \"examples\": [\n    {\n      \"serial\": 2020072001,\n      \"pool\": {\n        \"id\": \"0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f\",\n        \"country\": \"DE\",\n        \"status\": \"act\",\n        \"contact\": {\n          \"primary\": \"email\",\n          \"email\": \"help@pooldomain.org\",\n          \"facebook\": \"demopool\",\n          \"github\": \"demopool\",\n          \"feed\": \"https://demopool.com/xml/poolrss.xml\",\n          \"telegram\": \"demopool\",\n          \"twitter\": \"demopool\"\n        },\n        \"media_assets\": {\n          \"icon_png_64x64\": \"https://mydemopool.com/icon.png\",\n          \"logo_png\": \"https://mydemopool.com/logo.png\",\n          \"logo_svg\": \"https://mydemopool.com/logo.svg\",\n          \"color_fg\": \"#RRGGBB\",\n          \"color_bg\": \"#RRGGBB\"\n        },\n        \"itn\": {\n          \"owner\": \"ed25519_pk1...\",\n          \"witness\": \"ed25519_sig1...\"\n        }\n      }\n    }\n  ],\n  \"maxLength\": 4096,\n  \"required\": [\n    \"serial\",\n    \"pool\"\n  ],\n  \"title\": \"Extended stake pool metadata\",\n  \"type\": \"object\",\n  \"properties\": {\n    \"serial\": {\n      \"$id\": \"#/properties/serial\",\n      \"default\": 0,\n      \"description\": \"Integer number incremented on every update, by using YYYYMMDDxx (xx each day start by 01 and is incremented on each update\",\n      \"examples\": [\n        2021012001\n      ],\n      \"maxLength\": 10,\n      \"minLength\": 10,\n      \"required\": [],\n      \"title\": \"serial number\",\n      \"type\": \"integer\"\n    },\n    \"pool\": {\n      \"$id\": \"#/properties/pool\",\n      \"default\": {},\n      \"description\": \"pool related metadata\",\n      \"required\": [\n        \"id\"\n      ],\n      \"title\": \"stake pool\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"id\": {\n          \"$id\": \"#/properties/pool/properties/id\",\n          \"type\": \"string\",\n          \"title\": \"Pool ID\",\n          \"description\": \"the pools unique id in hex format\",\n          \"maxLength\": 48,\n          \"minLength\": 48,\n          \"examples\": [\n            \"69579373ec20f2f82d2dc2360410350b308112f2939f92a\"\n          ]\n        },\n        \"country\": {\n          \"$id\": \"#/properties/pool/properties/country\",\n          \"default\": \"\",\n          \"description\": \"3 letter country code as defined in https://www.iso.org/iso-3166-country-codes.html (alpha-3)\",\n          \"maxLength\": 3,\n          \"minLength\": 3,\n          \"examples\": [\n            \"JPN\"\n          ],\n          \"title\": \"declared pool location\",\n          \"type\": \"string\"\n        },\n        \"status\": {\n          \"$id\": \"#/properties/pool/properties/status\",\n          \"default\": \"\",\n          \"maxLength\": 3,\n          \"minLength\": 3,\n          \"description\": \"the current operative status (see examples).\",\n          \"examples\": [\n            \"active\",\n            \"retired\",\n            \"offline\",\n            \"experimental\",\n            \"private\"\n          ],\n          \"title\": \"pool status\",\n          \"type\": \"string\"\n        },\n        \"contact\": {\n          \"$id\": \"#/properties/pool/properties/contact\",\n          \"default\": {},\n          \"description\": \"Optional contact information.\",\n          \"examples\": [\n            {\n              \"primary\": \"email\",\n              \"email\": \"help@demopool.org\",\n              \"facebook\": \"demopool\",\n              \"github\": \"demopool\",\n              \"feed\": \"https://mydemopool.com/xml/poolrss.xml\",\n              \"telegram\": \"demopool\",\n              \"telegram_channel\": \"https://t.me/coolchannel\",\n              \"twitter\": \"demopool\"\n            }\n          ],\n          \"required\": [\n            \"primary\"\n          ],\n          \"title\": \"Pool contact data\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"primary\": {\n              \"$id\": \"#/properties/pool/properties/contact/properties/primary\",\n              \"default\": \"email\",\n              \"description\": \"the pools prefered communication channel\",\n              \"title\": \"primary contact preference\",\n              \"type\": \"string\"\n            },\n            \"email\": {\n              \"$id\": \"#/properties/pool/properties/contact/properties/email\",\n              \"description\": \"valid email contact address\",\n              \"title\": \"email address\",\n              \"type\": \"string\"\n            },\n            \"facebook\": {\n              \"$id\": \"#/properties/pool/properties/contact/properties/facebook\",\n              \"description\": \"a user or page name\",\n              \"title\": \"facebook account\",\n              \"examples\": [\n                \"demopool\"\n              ],\n              \"type\": \"string\"\n            },\n            \"github\": {\n              \"$id\": \"#/properties/pool/properties/contact/properties/github\",\n              \"description\": \"a github username\",\n              \"examples\": [\n                \"demopool\"\n              ],\n              \"title\": \"github account\",\n              \"type\": \"string\"\n            },\n            \"feed\": {\n              \"$id\": \"#/properties/pool/properties/contact/properties/feed\",\n              \"default\": \"\",\n              \"description\": \"RSS feed URL\",\n              \"examples\": [\n                \"https://mydemopool.com/xml/poolrss.xml\"\n              ],\n              \"title\": \"RSS feed\",\n              \"type\": \"string\"\n            },\n            \"telegram\": {\n              \"$id\": \"#/properties/pool/properties/contact/properties/telegram\",\n              \"description\": \"a telegram username\",\n              \"examples\": [\n                \"demopool\"\n              ],\n              \"title\": \"telegram account\",\n              \"type\": \"string\"\n            },\n            \"twitter\": {\n              \"$id\": \"#/properties/pool/properties/contact/properties/twitter\",\n              \"description\": \"a twitter username\",\n              \"examples\": [\n                \"demopool\"\n              ],\n              \"title\": \"twitter account\",\n              \"type\": \"string\"\n            }\n          }\n        },\n        \"media_assets\": {\n          \"$id\": \"#/properties/pool/properties/media_assets\",\n          \"type\": \"object\",\n          \"title\": \"The pools media assets\",\n          \"description\": \"Media file URLs and colors\",\n          \"required\": [\n            \"icon_png_64x64\"\n          ],\n          \"properties\": {\n            \"icon_png_64x64\": {\n              \"$id\": \"#/properties/pool/properties/media_assets/properties/icon_png_64x64\",\n              \"type\": \"string\",\n              \"title\": \"Pool Icon in PNG file format 64x64 px\",\n              \"description\": \"PNG image with exact 64x64 pixel size\",\n              \"examples\": [\n                \"https://mydemopool.com/media/icon64.png\"\n              ]\n            },\n            \"logo_png\": {\n              \"$id\": \"#/properties/pool/properties/media_assets/properties/logo_png\",\n              \"type\": \"string\",\n              \"title\": \"Pool Logo in PNG file format\",\n              \"description\": \"PNG image (should have less than 250 kByte of file size)\",\n              \"examples\": [\n                \"https://mydemopool.com/media/logo.png\"\n              ]\n            },\n            \"logo_svg\": {\n              \"$id\": \"#/properties/pool/properties/media_assets/properties/logo_svg\",\n              \"type\": \"string\",\n              \"title\": \"Pool Logo in SVG file format\",\n              \"description\": \"(shoud have less tha 250 kByte of file size)\",\n              \"examples\": [\n                \"https://mydemopool.com/media/logo.svg\"\n              ]\n            },\n            \"color_fg\": {\n              \"$id\": \"#/properties/pool/properties/media_assets/properties/color_fg\",\n              \"type\": \"string\",\n              \"title\": \"Pool primary color\",\n              \"description\": \"RGB color code.\",\n              \"examples\": [\n                \"#AABBCC\"\n              ]\n            },\n            \"color_bg\": {\n              \"$id\": \"#/properties/pool/properties/media_assets/properties/color_bg\",\n              \"type\": \"string\",\n              \"title\": \"Pool secondary color\",\n              \"description\": \"RGB color code.\",\n              \"default\": \"\",\n              \"examples\": [\n                \"#C0C0C0\"\n              ]\n            }\n          }\n        },\n        \"itn\": {\n          \"$id\": \"#/properties/pool/properties/itn\",\n          \"type\": \"object\",\n          \"title\": \"ITN verification\",\n          \"description\": \"A proof of ownership for an established ITN pool brand.\",\n          \"required\": [\n            \"owner\",\n            \"witness\"\n          ],\n          \"properties\": {\n            \"owner\": {\n              \"$id\": \"#/properties/pool/properties/itn/properties/owner\",\n              \"type\": \"string\",\n              \"title\": \"the ITN pool owner public key\",\n              \"examples\": [\n                \"ed25519_pk1...\"\n              ]\n            },\n            \"witness\": {\n              \"$id\": \"#/properties/pool/properties/itn/properties/witness\",\n              \"type\": \"string\",\n              \"title\": \"the secret key generated witness\",\n              \"examples\": [\n                \"ed25519_sig1...\"\n              ]\n            }\n          }\n        }\n      }\n    }\n  }\n}\n"
  },
  {
    "path": "CIP-0007/CIP-0007.md",
    "content": "Moved to [CIP-0007/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0007/README.md",
    "content": "---\nCIP: 7\nTitle: Curve Pledge Benefit\nAuthors:\n  - Shawn McMurdo <shawn_mcmurdo@yahoo.com>\nCategory: Ledger\nStatus: Proposed\nCreated: 2020-08-11\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/12\n  - https://forum.cardano.org/t/protocol-parameters-pledge-and-sybil-resistance/35100\n  - https://github.com/input-output-hk/cardano-node/issues/1518\nImplementors: []\nLicense: Apache 2.0\n---\n\n## Abstract\n\nModifying the current rewards calculation equation by substituting a n-root curved relationship between pledge and pledge benefit rewards for the current linear relationship will better achieve the original design goal of incentivizing pledge to help prevent Sybil attacks.\nThis also reduces the unfortunate side effect in the current equation that over rewards private pools which provide no additional security benefit.\n\n## Motivation: why is this CIP necessary?\n\nThere are two main reasons for changing the current linear a0 pledge benefit factor in the rewards equation.\n\n1. Pools pledging less than 1 million ADA see very little reward benefit.  This is not a strong incentive for pool operators as at current prices that is approximately $150,000 USD.\n\n2. Private pools get massive reward benefit without providing any additional protection against Sybil attacks. Why should a private pool make 29% more rewards than a pool with 5m ADA pledge while doing the same work?\n\n## Specification\n\nThis is a modification of the maxPool function defined in section 11.8 Rewards Distribution Calculation of “A Formal Specification of the Cardano Ledger”.\n\nmaxPool = (R / (1 + a0)) * (o + (s * a0 * ((o - (s * ((z0 - o) / z0))) / z0)))\n\nwhere:\nR = ((reserve * rho) + fees) * (1 - tau)\no = min(pool_stake / total_stake, z0) = z0 for fully saturated pool\ns = pledge / total_stake\nz0 = 1 / k\nand the following are current protocol parameters:\nk = 150\nrho = 0.0022\na0 = 0.3\ntau = .05\n\nThe idea is to replace s in the above equation with an n-root curve expression of pledge rather than the linear pledge value.\n\nWe use an expression called crossover to represent the point where the curve crosses the line and the benefit in the new and original equations is identical.\nBecause the a0 pledge benefit is spread over the pledge range from 0 to saturation there is a dependence on k and total_stake.\nSince k and total_stake will likely change over time it is best to express crossover in terms of k and total_stake as follows:\n\ncrossover = total_stake / (k * crossover_factor)\n\nwhere crossover_factor is any real number greater than or equal to 1.\nSo crossover_factor is essentially a divisor of the pool saturation amount.\nFor example, setting crossover_factor to 20 with k = 150 and total_stake = 31 billion gives a crossover of approximately 10.3 million.\n\nAlso, we can parameterize the n-root curve exponent.\nThis gives us:\n\ns = pow(pledge, (1 / curve_root)) * pow(crossover, ((curve_root - 1) / curve_root)) / total_stake\n\nThe curve_root could be set to any integer greater than 0 and when set to 1 produces the current rewards equation.\nThe curve_root is n in n-root. For example, 1 = linear, 2 = square root, 3 = cube root, 4 = fourth root, etc.\n\nBy making this modification to the rewards equation we introduce two new protocol parameters, crossover_factor and curve_root, that need to be set thoughtfully.\n\n### Test Cases\n\nSee rewards.php for some simple PHP code that allows you to try different values for crossover_factor and curve_root and compare the resulting rewards to the current equation.\nFor usage, run \"php -f rewards.php help\".\n\nAn interesting set of parameters as an example is:\n\ncurve_root = 3\ncrossover_factor = 8\n\nRunning \"php -f rewards.php 3 8\" produces:\n\nAssumptions\nReserve: 14b\nTotal stake: 31.7b\nTx fees: 0\nFully Saturated Pool\nRewards available in epoch: 29.3m\nPool saturation: 211.3m\n\nCurve root: 3\nCrossover factor: 8\nCrossover: 26.4m\n\nPledge\tRewards\tBenefit\tAlt Rwd\tAlt Bnft\n0k\t150051\t0%\t150051\t0%\n10k\t150053\t0%\t150458\t0.27%\n50k\t150062\t0.01%\t150747\t0.46%\n100k\t150073\t0.01%\t150928\t0.58%\n200k\t150094\t0.03%\t151156\t0.74%\n500k\t150158\t0.07%\t151551\t1%\n1m\t150264\t0.14%\t151941\t1.26%\n2m\t150477\t0.28%\t152432\t1.59%\n5m\t151116\t0.71%\t153282\t2.15%\n10m\t152181\t1.42%\t154122\t2.71%\n20m\t154311\t2.84%\t155180\t3.42%\n50m\t160702\t7.1%\t157012\t4.64%\n100m\t171352\t14.2%\t158821\t5.84%\n211.3m\t195067\t30%\t161305\t7.5%\n\nAs you can see this gives meaningful pledge benefit rewards to pools pledging less than 1m ADA.\n\n## Rationale: how does this CIP achieve its goals?\n\nUsing the n-root curve pledge benefit shows a much more reasonable distribution of pledge related rewards which will encourage meaningful pledges from more pool operators thus making the network more secure against Sybil attacks.\nIt also provides higher rewards for higher pledge without disproportionately rewarding a very few private pool operators who provide no additional security value to the network.\nThis modification maintains the general principles of the current rewards equation and does not introduce any hard limits.\nIt improves the incentives that were originally designed to make them more meaningful for the majority of pool operators.\n\n### Backward Compatibility\n\nThis proposal is backwards compatible with the current reward function by setting the curve_root parameter to 1.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] The new equation is implemented in the ledger and enacted through a hard-fork.\n\n### Implementation Plan\n\n- [ ] Agreement by the Ledger team as defined in [CIP-0084](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0084) under _Expectations for ledger CIPs_ including \"expert opinion\" on changes to rewards & incentives.\n\n- [ ] Author has offered to produce an implementation of this change as a pull request if shown where the current maxPool reward equation is implemented in the code.\n\n## Copyright\n\n2020 Shawn McMurdo. This CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0).\n\n"
  },
  {
    "path": "CIP-0007/rewards.php",
    "content": "<?php\n\n$argc = count($argv);\n\nif ($argc == 1) {\n  // The n-root curve exponent. 1 = linear, 2 = square root, 3 = cube root, 4 = fourth root, etc.\n  $curve_roots = array(2, 3, 4);\n\n  // Divisor of saturation that calculates the pledge where the curve crosses the line\n  $crossover_factors = array(10, 20, 50);\n} else if ($argc == 3) {\n  $curve_roots = array($argv[1]);\n  $crossover_factors = array($argv[2]);\n} else {\n  echo \"Usage: php -f \" . $argv[0] . \" <curve_root> <crossover_factor>\" . PHP_EOL;\n  echo \"  curve_root:  The n-root curve exponent. 1 = linear, 2 = square root, 3 = cube root, etc.\" . PHP_EOL;\n  echo \"               An integer greater than 0.\" . PHP_EOL;\n  echo \"  crossover_factor: Divisor of saturation that calculates the pledge where the curve crosses the line.\" . PHP_EOL;\n  echo \"                    A real number greater than or equal to 1.\" . PHP_EOL;\n  exit;\n}\n\n// Assumptions\n$reserve = 14000000000;\n$total_stake = 31700000000;\n$fees = 0;\n\necho \"Assumptions\" . PHP_EOL;\necho \"Reserve: \" . round($reserve / 1000000000, 1) . \"b\" . PHP_EOL;\necho \"Total stake: \" . round($total_stake / 1000000000, 1) . \"b\" . PHP_EOL;\necho \"Tx fees: \" . $fees . PHP_EOL;\necho \"Fully Saturated Pool\" . PHP_EOL;\n\n// Protocol parameters\n$k = 150;\n$rho = 0.0022;\n$a0 = 0.3;\n$tau = .05;\n\n// Calculated values\n$R = (($reserve * $rho) + $fees) * (1 - $tau);\n$z0 = 1 / $k;\n$o = $z0; // for fully saturated pool\n$saturation = round($total_stake / $k);\n\necho \"Rewards available in epoch: \" . round($R / 1000000, 1) . \"m\" . PHP_EOL;\necho \"Pool saturation: \" . round($saturation / 1000000, 1) . \"m\" . PHP_EOL;\necho PHP_EOL;\n\n// Pool pledge\n$pledges = array(0, 10000, 50000, 100000, 200000, 500000, 1000000, 2000000, 5000000, 10000000, 20000000, 50000000, 100000000, $saturation);\n\n// Compare to zero pledge\n$comparison_pledge = 0;\n$comparison_s = $comparison_pledge / $total_stake;\n$comparison_rewards = round(($R / (1 + $a0)) * ($o + ($comparison_s * $a0 * (($o - ($comparison_s * (($z0 - $o) / $z0))) / $z0))));\n\nforeach ($curve_roots as $curve_root) {\n  foreach ($crossover_factors as $crossover_factor) {\n    $crossover = $total_stake / ($k * $crossover_factor);\n    echo \"Curve root: \" . $curve_root . PHP_EOL;\n    echo \"Crossover factor: \" . $crossover_factor . PHP_EOL;\n    echo \"Crossover: \" . round($crossover / 1000000, 1) . \"m\" . PHP_EOL;\n    echo PHP_EOL;\n\n    echo \"Pledge\\tRewards\\tBenefit\\tAlt Rwd\\tAlt Bnft\" . PHP_EOL;\n\n    foreach ($pledges as $pledge) {\n      if ($pledge < 1000000) {\n        $pledge_str = round($pledge / 1000, 1) . \"k\";\n      } else {\n        $pledge_str = round($pledge / 1000000, 1) . \"m\";\n      }\n\n      // Current Formula (same as alternate formula with curve_root = 1)\n      $s = $pledge / $total_stake;\n      $rewards = round(($R / (1 + $a0)) * ($o + ($s * $a0 * (($o - ($s * (($z0 - $o) / $z0))) / $z0))));\n      $benefit = round(((($rewards / $comparison_rewards) - 1) * 100), 2);\n\n      $alt_numerator = pow($pledge, (1 / $curve_root)) * pow($crossover, (($curve_root - 1) / $curve_root));\n      $alt_s = $alt_numerator / $total_stake;\n      $alt_rewards = round(($R / (1 + $a0)) * ($o + ($alt_s * $a0 * (($o - ($alt_s * (($z0 - $o) / $z0))) / $z0))));\n      $alt_benefit = round(((($alt_rewards / $comparison_rewards) - 1) * 100), 2);\n\n      echo $pledge_str . \"\\t\" . $rewards . \"\\t\" . $benefit . \"%\\t\" . $alt_rewards . \"\\t\" . $alt_benefit . \"%\" . PHP_EOL;\n    }\n\n    echo PHP_EOL;\n  }\n}\n\n"
  },
  {
    "path": "CIP-0008/CIP-0008.md",
    "content": "Moved to [CIP-0008/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0008/README.md",
    "content": "---\nCIP: 8\nTitle: Message Signing\nStatus: Active\nCategory: Tools\nAuthors:\n  - Sebastien Guillemot <sebastien@emurgo.io>\nImplementors:\n  - Mesh <https://meshjs.dev/>\n  - Cardano Ballot <https://github.com/cardano-foundation/cf-cardano-ballot>\n  - SundaeSwap governance <https://governance.sundaeswap.finance/>\n  - Emurgo <https://www.emurgo.io/>\nDiscussions:\n  - https://github.com/Emurgo/EmIPs/pull/5\n  - https://forum.cardano.org/t/message-signing-specification/41032\n  - https://cardano.ideascale.com/a/dtd/Create-message-signing-standard/323158-48088\nCreated: 2020-09-28\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nPrivate keys can be used to sign arbitrary data. If you have the public key, you can verify the data was signed by the owner of the private key. This is how transaction signing works internally but its utility is not limited to transactions. This document tries to set a standard for how to represent and verify signed messages for Cardano.\n\n## Motivation: why is this CIP necessary?\n\nMost common use cases:\n\n1) Proving ownership of a set addresses (possibly to prove ownership of more then X Ada)\n1) Proving ownership of addresses used in a transaction\n1) Proving ownership of an identity or other off-chain data with a public key attached to it\n\n## Specification\n\n### Versions\n\n| version | description     |\n|---------|-----------------|\n| 1       | initial version |\n\n### Signing and Verification\n\n#### Overview\n\nFirst we will show a very basic example of the structure to help the reader understand the definitions that comes after\n\n```\n[\n  bstr,               ; protected header\n  { * label => any }, ; unprotected header\n  bstr / nil,         ; message to sign\n  [                   ; signature array\n    [                     ; first signature\n      bstr                ; protected\n      { * label => any }, ; unprotected\n      bstr                ; signature\n    ]\n  ]\n]\n```\n\nYou can see the structure has two layers -- both containing a `protected` and an `unprotected` section. Items inside `protected` are part of the data signed while `unprotected` is meant to annotate the COSE structure (for example add annotations as you pass a message across a stack). Items MUST NOT be duplicated.\n\nYou can find more complete definitions of `protected` and `unprotected` in [RFC 8152 section-3](https://tools.ietf.org/html/rfc8152#section-3) and you can see some the reserved entries (called `Generic_Headers`) in the maps in [RFC 8152 section-3.1](https://tools.ietf.org/html/rfc8152#section-3.1).\n\nNote: `payload` can be `nil`. This means that the payload is known by both the signer and the verifier and therefore doesn't need to be encoded.\n\nFor your convenience, the structure is provided here:\n\n```\nempty_or_serialized_map = bstr .cbor header_map / bstr .size 0\n\nheader_map = {\n    Generic_Headers,   ; reserved headers (see COSE section 3.1)\n    * label => values  ; any number of int/string labels for application-specific purpose.\n}\n\nHeaders = (\n    protected : empty_or_serialized_map,\n    unprotected : header_map\n)\n\n; signature layer\nCOSE_Signature =  [\n    Headers,\n    signature : bstr\n]\n\n; if signing with just ONE key\nCOSE_Sign1 = [\n    Headers,\n    payload : bstr / nil,\n    signature : bstr\n]\n\n# if signing with >1 key\nCOSE_Sign = [\n    Headers,\n    payload : bstr / nil,\n    signatures : [+ COSE_Signature]\n]\n\nsigned_message = COSE_SIGN / COSE_Sign1\n```\n\n#### Signing and Verification target format\n\nInstead of signing the full structure, we instead sign the following type which is derived from the structure\n\n```\nSig_structure = [\n  context : \"Signature\" / \"Signature1\" / \"CounterSignature\",    ; explained below\n  body_protected : empty_or_serialized_map,                     ; protected from layer 1\n  ? sign_protected : empty_or_serialized_map,                   ; not present in Sign1 case\n  external_aad : bstr,                                          ; explanation below\n  payload : bstr\n]\n```\n\nThe `external_aad` allows an application to ask the user to sign some extra data but NOT put it inside the COSE structure (only as part of the data to sign). Defaults to `h''`. You can read more about this at [RFC 8152 section-4.3](https://tools.ietf.org/html/rfc8152#section-4.3).\n\nThe `context` is meant to encode what structure was used for the COSE request. `CounterSignature` is explained in a later section of this specification.\n\n#### Signing and Verification process\n\nTo be able to effectively verify we need two things:\n\n1) P1 - (optional) knowledge of the relation of a public key and a Cardano address\n1) P2 - Knowledge of which algorithm was used to sign\n\nFor `P1`, the mapping of public keys to addresses has two main cases:\n\n1) for Shelley addresses, one payment key maps to many addresses (base, pointer, enterprise)\n2) for Byron addresses, chaincode and address attributes need to be combined with the public key to generate an address\n\nTo resolve this, one SHOULD add the full address to the protected header when using a v2 address. The v2 addresses contain the chaincode + attributes and we can verify the address matches combining it with the verification public key.\n\n```\n? address: bstr,\n```\n\nFor `P2`, we use the `alg` header and to specify which public key was used to sign, use the [cwt](https://tools.ietf.org/html/rfc8392) protected header.\n\n### Encryption\n\nAlthough COSE defines multiple ways to encrypt, we simplify our spec to the two following cases:\n\n1) Encrypted with the recipient's public key (called `key transport` in COSE spec)\n2) Encrypted with a user-chosen password (called `passwords` in COSE spec)\n\nIn order to facilitate implementations in wallets, we limit the usage of these to the following\n\n```\nChachaPoly\nEd25519PubKey\n```\n\nWe will explain what this means shortly but you can find the full list of the types of encryption allowed by COSE at [RFC 8152 section 5.1.1](https://tools.ietf.org/html/rfc8152#section-5.1.1)\n\n#### Structure\n\nThe COSE specification is made to be composable -- that is you can have a plaintext that you wrap with a signature, then wrap with an encryption, then wrap with a signature again (and so on).\n\nThat means that for encryption in particular, it can either\n\n1) Be used to encrypt plaintext directly\n2) Be used to encrypt another COSE message\n\nIn this spec, we care about the case where you encrypt a `signed_message`\n\nHere is the overall CBOR structure\n\n```\n; holds encrypted content itself\nCOSE_Encrypt = [\n  Headers,\n  ciphertext : bstr / nil, ; contains encrypted signed_message\n  recipients : [+COSE_recipient]\n]\n\n; holds encrypted keys the receiver can use to decrypt the content\nCOSE_recipient = [\n  Headers,\n  ciphertext : bstr / nil, ; contains encrypted key to decrypt the COSE_Encrypt ciphertext\n  ? recipients : [+COSE_recipient] ; in case you need multiple rounds to get decryption key\n]\n```\n\nTo encrypt the structure as a whole, we call our encryption method once for each level (root, recipient, etc.) recursively. For example, we encrypt the `signed_message` and put it in the `COSE_Encrypt` ciphertext, then we encrypt the decryption key and put it in the `COSE_recipient` ciphertext.\n\nFor the `Headers`,\n\n- The `protected` fields MUST be empty. These are meant to be used with AEAD which we  don't need in this  specification (you can read more about it at [RFC 8152 section 5.3](https://tools.ietf.org/html/rfc8152#section-5.3)).\n\nWe define two ways to encrypt content:\n\n##### Password-based encryption\n\nFor password-based encryption we don't need a receiver field (anybody who knows the password can decrypt) so we instead use the following (simplified) structure\n\n```\nCOSE_Encrypt0 = [\n    Headers,\n    ciphertext : bstr / nil,\n]\n\nPasswordEncryption = 16 (COSE_Encrypt0)\n```\n\nThe COSE spec uses the following parameters for ChaCha20/Poly1305 as specified in [10.3](https://tools.ietf.org/html/rfc8152#section-10.3):\n\n- 256-bit key\n- 128-bit tag\n- 96-bit nonce\n\nWe RECOMMEND using `19162` iterations as this matches the existing password encryption in the [Yoroi encryption spec](https://github.com/Emurgo/yoroi-frontend/blob/737595fec5a89409aacef827d356c9a1605515c0/docs/specs/code/ENCRYPT.md)`.\n\n##### Public key based encryption\n\nWe only allow encrypting based on `ED25519` public keys (the ones used for Cardano). To encrypt based on these public keys, you must\n\n1) Compute a password consisting of 22 case-sensitive alphanumeric (a–z, A–Z, 0–9) characters (this gives you ~128 bits of entropy)\n\nNow, for each receiver, you must\n\n2) Compute an ephemeral key pair using `ED25519 extended`\n1) Compute the shared DH secret between the private key from step (1) and the public key received (using the `exchange` functionality)\n1) Use this as the password to encrypt the password in (1) using [the Yoroi encryption spec](https://github.com/Emurgo/yoroi-frontend/blob/737595fec5a89409aacef827d356c9a1605515c0/docs/specs/code/ENCRYPT.md)\n\nThe structure will look like the following:\n\n```\nCOSE_Encrypt = [\n  Headers,\n  ciphertext : bstr / nil, ; contained signed_message encrypted with random password\n  recipients : [+COSE_recipient]\n]\n\nCOSE_recipient = [\n  Headers,\n  ciphertext : bstr / nil, ; contains random password encrypted with shared secret\n]\n\nPubKeyEncryption = 96 (COSE_Encrypt)\n```\n\nThe `Headers` for the recipient MUST have a `epk` label containing the public key of the ephemeral keypair as described in the [CBOR Encoded Message Syntax](http://www.watersprings.org/pub/id/draft-schaad-cose-02.html).\n\n#### Version\n\nThe `Headers` for the body MUST have `version: uint` in the `unprotected` field. See [Versions table](#versions) for possible version numbers.\n\n#### Payload encoding\n\nTo solve `E3`, `signed_message` body header MUST contain `hashed: bool` as an `unprotected` header which defines whether or not we signed the `payload` OR the `Blake2b224` hash of the `payload`. The hash MUST be used in the following two cases\n\n1) The size of the raw `payload` would otherwise be too big to fit in hardware wallet memory (see E1). Note that the exact size for which this is the case depends on the device.\n1) The payload characters (ex: non-ASCII) that cannot be displayed on the hardware wallet device (see E3)\n\nWe RECOMMEND showing the user the full payload on the device if possible because it lowers the attack surface (otherwise the user has to trust that the hash of the payload was calculated correctly).\n\n`Blake2b224` was chosen specifically because `224` bits is already a long string for hardware wallets.\n\n### User-Facing Encoding\n\nOnce we have our top-level `encrypted_message` or `signed_message` we need to encode them in way that can be displayed to users (doesn't need to be stored and can be inferred just from the data)\n\nWe define the encoding in three parts `prefix || data || checksum` (where || means append)\n\n### Prefix\n\nWe need a human-readable prefix. We use \"CM\" for \"Cardano Message\" followed by the message type:\n\n- `encrypted_message`: `cme_`\n- `signed_message`: `cms_`\n- `mac_message`: `cmm_` (unused in this spec)\n\n#### Data\n\nData is simply the `base64url` encoding of the message\n\n#### Checksum\n\nWe use fnv32a on the data for the checksum and store it as the `base64url` encoding of its network byte order representation.\n\n### Other remarks\n\nWe recommend usage of unprotected headers vs protected headers when possible. This is because we have to limit the amount of data passed to a hardware wallet  to satisfy E1. If the only effect of an adversary changing an unprotected header only leads to the signature not matching, then it's best to leave it unprotected.\n\nThe public key SHOULD NOT contain any chaincode information, as it could compromise child non-hardened keys. It is both a privacy and a security risk (see [here](https://bitcoin.org/en/wallets-guide#hierarchical-deterministic-key-creation) for more detail).\n\n## Rationale: how does this CIP achieve its goals?\n\n### Requirements\n\nOn top being usable for all cases mentioned in [Motivation](#motivation-why-is-this-cip-necessary), we also desire the following to ensure it works well with hardware wallets:\n\n- E1 - Low runtime memory environment\n- E2 - Low app size environment (cannot implement every cryptographic algorithm on the device or app size would be too big)\n- E3 - Works well with limited display (some hardware wallets cannot display long text and cannot display UTF8)\n\n### Related specifications\n\n#### Requirement Levels [[RFC 2119](https://tools.ietf.org/html/rfc2119)]\n\nThe key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"NOT RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).\n\n#### Concise Binary Object Representation (CBOR) [[RFC 7049](https://tools.ietf.org/html/rfc7049)]\n\nCBOR is a way to serialize structured data in a more compact way than what is allowed by JSON. It is widely used across the Cardano ecosystem and so we use it to encode the data for this specification.\n\n#### *Concise Data Definition Language (CDDL)* [[RFC 8610](https://tools.ietf.org/html/rfc8610)]\n\nCDDL is a human-readable CBOR notation format. CBOR schemas defined in this document are defined uinsg CDDL. We use `label = int / tstr` in several places.\n\n#### *CBOR Object Signing and Encryption (COSE)* [[RFC 8152](https://tools.ietf.org/html/rfc8152)] \n\nThis is a standard for how to use CBOR for message signing. It is based on the JSON equivalent *JSON Object Signing and Encryption* [RFC 7520](https://tools.ietf.org/html/rfc7520). \n\nWe base our construction on COSE because all Cardano libraries already depend on CBOR due to its use in the base protocol (which means we don't need to introduce a new library). It is also more compact, which is useful in case data generated by this standard ever needs to be stored on-chain.\n\n#### *CBOR Web Token (CWT)* [[RFC 8392](https://tools.ietf.org/html/rfc8392)]\n\nThis is a standard for pre-defined header elements for message signing based on the equivalent standard for JSON (*JWT* [[RFC 7519](https://tools.ietf.org/html/rfc7519)]). This allows us to standardize notions of concepts like expiration time of a signed message.\n\n#### *Address Formats*\n\nBECH32 ([BIP-173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)) is a standard for encoding addresses such that they\n\n- Are human readable (both in length and contain a common prefix)\n- Can easily be displayed in a QR code\n- Contain error detection through a BCH checksum\n\nCardano has several address types based on the era they were created in:\n* `v1` - Legacy Daedalus (starts with Dd)\n* `v2` - Legacy Icarus (starts with Ae2)\n* `v3` - Shelley (bech32)\n\n\nAlthough `v3` is relevant to us for encoding public keys into addresses, we do not use `bech32`'s scheme for encoding in this specification. This is because\n\n- The payload may be too big to reasonably encode in a QR code so the benefits of using base32 are limited.\n- BCH checksums are not made for large payloads and additionally the polynomial used has to be fine-tuned for the expected length (but the length of our payload varies too much in this spec)\n\n#### fnv32a\n\nAlthough Cardano Byron addresses use CRC32 (IEEE variation), due to `E1` and `E2` we use fnv32a for checksums.\n\nThis is because CRC32:\n\n1) Has fairly few collisions compared to other hashes\n2) Is moderately slower than other hashes\n3) Requires more memory than alternatives (need to build a lookup table)\n4) Is somewhat complex implementation (many alternatives exist)\n\nwhile fnv32a:\n\n1) Still has fairly few collisions\n2) Is faster than CRC32 in general\n3) Needs only O(1) memory requirement\n4) Is simple to implement\n\nIn particular, using fnv32a over CRC32 frees up 1024 bytes of memory due to not having a lookup table which is significant on hardware wallets.\n\n#### Blake2b [[RFC 7693](https://tools.ietf.org/html/rfc7693)]\n\nBlake2b is a hash algorithm used commonly in Cardano. Notably, Blake2b-224, Blake2b-256 and Blake2b512 are used depending on the context.\n\n#### base64url [[RFC 4648 section 5](https://tools.ietf.org/html/rfc4648#section-5)]\n\n`base64url` allows encoding bytes in a human-readable format that is also safe to pass in URLs.\n\n#### Other blockchain standards\n\nOther blockchains have existing specifications for message signing, but they mostly revolve around scripts trying to validate messages. We don't leverage any of their work in particular but it may be of interest.\n\n- [BIP-137](https://github.com/bitcoin/bips/blob/master/bip-0137.mediawiki) - simply scheme for message signing that works with P2PKH, P2PSH and bech32\n- [BIP-322](https://github.com/kallewoof/bips/blob/master/bip-0322.mediawiki) - reuses Bitcoin script to process a generic signed message format\n\n- [EIP-191](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-191.md) - encode data for Ethereum contracts\n- [EIP-712](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md) - encode structs for Ethereum contracts\n\n### Existing Code\n\n#### Cryptography\n\nCardano already allows message signing within the WASM bindings. Notably,\n\n1) [sign](https://github.com/Emurgo/cardano-serialization-lib/blob/4792b1b121e728a51686d5fcbffd33489d65c903/rust/src/crypto.rs#L279)\n2) [verify](https://github.com/Emurgo/cardano-serialization-lib/blob/4792b1b121e728a51686d5fcbffd33489d65c903/rust/src/crypto.rs#L322)\n\nYou can see an example of these two functions [here](https://repl.it/repls/FlusteredSimpleFunction)\n\nEven if you use cryptographically secure `sign` and `verify` functions, you still have the following problems:\n\n1) No human-recognizable prefix\n0) No error detection\n0) User could accidentally sign a transaction or a block thinking it's harmless data\n\nWe also have a risk of a few different kinds of replay attacks\n\n4) A dapp asks person A to sign \"BOB\" and then another dapp asks user B to sign \"BOB\". B can just use the signature from A\n0) A dapp asks person A to sign \"BOB\" on a testnet chain. Person B then sends this signed message to the same dapp running on mainnet (same argument applies to sidechains)\n\n### Reference implementations\n\n- [COSE-JS](https://github.com/erdtman/cose-js)\n- [Rust message signing](https://github.com/Emurgo/message-signing)\n\n### Unresolved\n\nThis specification provides no means of Revocation.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] There are wallets supporting creation of signed messages as per this protocol (enumerated 2023-12-19 as per [CardanoBallot list of wallets](https://voting.summit.cardano.org/user-guide) supporting CIP-8 signed messages):\n  - [x] Flint\n  - [x] Eternl\n  - [x] Nami\n  - [x] Typhon\n  - [x] Yoroi\n  - [x] Nufi\n  - [x] Gerowallet\n  - [x] Lace\n- [x] There exist one or more implementations in commonly used development libraries:\n  - [x] [Mesh](https://meshjs.dev/)\n  - [x] `@emurgo/cardano-message-signing-asmjs`\n- [x] There exist CLI Tools supporting creation and verification of signed messages:\n  - [x] [cardano-signer](https://github.com/gitmachtl/cardano-signer)\n- [x] There exist one or more implementations in web sites and other tools:\n  - [x] SundaeSwap Governance voting\n\n### Implementation Plan\n\n- [x] Make this standard available as well-supported means of message signing across Cardano wallets, dApps, and CLI tools.\n- [x] Support this standard in a usable reference implementation ([`@emurgo/cardano-message-signing-asmjs`](https://www.npmjs.com/package/@emurgo/cardano-message-signing-asmjs)).\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n"
  },
  {
    "path": "CIP-0009/CIP-0009.md",
    "content": "Moved to [CIP-0009/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0009/README.md",
    "content": "---\nCIP: 9\nTitle: Protocol Parameters (Shelley Era)\nStatus: Active\nCategory: Ledger\nAuthors:\n  - Kevin Hammond <kevin.hammond@iohk.io>\nImplementors:\n  - IOG <https://iog.io/>\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/45\nCreated: 2021-01-29\nLicense: Apache-2.0\n---\n\n## Abstract\n\nThis CIP is an informational CIP that describes the initial protocol parameter settings for the Shelley era of the Cardano blockchain, plus the changes that have been made.\nIt is intended to serve as a historic record, allowing protocol parameter changes to be tracked back to the original settings.\n\n## Motivation: why is this CIP necessary?\n\nWe need to provide a concise description of the initial protocol parameter choices, that can be used by the community as the base for future proposed protocol changes,\nand that document the chain of changes to the parameters.\n\n\n## Specification\n\n### Proposing Protocol Parameter Changes\n\nThis CIP records only the changes to the protocol parameters that have actually been made.  Suggested changes to protocol parameters should be proposed by preparing and submitting a new CIP, rather than editing this CIP.  The following information should be included.\n\n| Name of the Parameter   | New Parameter (Y/N)  | Deleted Parameter (Y/N) | Proposed Value   | Summary Rationale for Change |\n|-----------------------  |--------------------  |------------------------ |---------------   | ---------------------------- |\n\nWhere necessary, the summary rationale should be supported by a few paragraphs of text giving the full rationale, plus references to any external documents that are needed to understand the proposal.\n\nProtocol parameters are used to affect the operation of the Cardano Protocol.  They may be either **updatable** or **non-updatable**.\nUpdatable parameters can be tuned to vary the operation of the block producing protocol, impacting the proportion of pools that are federated/non-federated,\nhow much influence the \"pledge\" has etc.  Non-updatable parameters affect the fundamentals of the blockchain protocol, including defining the\ngenesis block, basic security properties etc.  Some non-updatable parameters may be embedded within the source code or implemented as software.\nEach major protocol version defines its own sets of updatable/non-updatable parameters.\n\n\n### Updatable Protocol Parameters\n\nThe initial **updatable** protocol parameter values are given below (in JSON format).  Any of these parameters may be changed by submitting\na parameter update proposal.  A change to the major protocol parameter version triggers a \"hard fork\" event.  This will require stake pool operators to\nupgrade to a new software version that complies with the new chain production protocol as well as being able to verify the construction of the chain.\n\n```\n{\n    \"protocolVersion\": {\n        \"major\": 2,\n        \"minor\": 0\n    },\n    \"nOpt\": 150,\n    \"a0\": 0.3,\n    \"minPoolCost\": 340000000,\n    \"decentralisationParam\": 1.0,\n    \"maxBlockBodySize\": 65536,\n    \"maxBlockHeaderSize\": 1100,\n    \"maxTxSize\": 16384,\n    \"tau\": 0.2,\n    \"rho\": 3.0e-3,\n    \"poolDeposit\": 500000000,\n    \"keyDeposit\": 2000000,\n    \"minFeeB\": 155381,\n    \"minFeeA\": 44,\n    \"minUTxOValue\": 1000000,\n    \"extraEntropy\": {\n        \"tag\": \"NeutralNonce\"\n    },\n    \"eMax\": 18\n}\n```\n\nThe meaning of the fields is:\n\n| Field                 \t| Initial Value                                                          \t| Description                                                                                                                                                                                                                      \t|\n|-----------------------\t|------------------------------------------------------------------------\t|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\t|\n| protocolVersion       \t| ```protocolVersion\": {         \"major\": 2,         \"minor\": 2     }``` \t| Protocol version.  Minor versions indicate software updates (will generally be 0).  Major version 1 = Byron, 2 = Shelley                                                                                                         \t|\n| nOpt                  \t| 150                                                                    \t| \"Target number of pools\" (\"k\").  Impacts saturation threshold, encouraging growth in number of stake pools.                                                                                                                                                                  \t|\n| a0                     \t| 0.3                                                                    \t| \"Influence Factor\". Governs how much impact the pledge has on rewards.                                                   v                                                                                                                                                   \t|\n| minPoolCost           \t| 340000000                                                              \t| Minimum Pool Cost per epoch (in lovelace).  Enables pledge effect.                                                                                                                                                               \t|\n| decentralisationParam \t| 1.0                                                                    \t| Level of decentralisation.  Starts at 1.  Block production is fully decentralised when this reaches 0.                                                                                                                           \t|\n| | |\n| maxBlockBodySize      \t| 65536                                                                  \t| Maximum size of a block body.  Limits blockchain storage size, and communication costs.                                                                                                                                          \t|\n| maxBlockHeaderSize    \t| 1100                                                                   \t| Maximum size of the block header.  Should be significantly less than the maximum block size.                                                                                                                                     \t|\n| maxTxSize             \t| 16384                                                                  \t| Maximum size of a transaction.  Several transactions may be included in a block.  Must be strictly less than the max. block body size.                                                                                           \t|\n| | |\n| tau                   \t| 0.2                                                                    \t| Treasury rate (0.2 = 20%).  Proportion of total rewards allocated to treasury each epoch before remaining rewards are distributed to pools.                                                                                                                                                                          |                                          \t|\n| rho                   \t| 3.0e-3                                                                \t| Monetary expansion rate per epoch.  Governs the rewards that are returned from reserves to the ecosystem (treasury, stake pools and delegators).                                                                                  |\n| | |\n| poolDeposit           \t| 500000000                                                              \t| Pool deposit (in lovelace)                                                                                                                                                                                                       \t|\n| keyDeposit            \t| 2000000                                                                \t| Deposit charged for stake keys (in Lovelace).  Ensures that unused keys are returned, so freeing resources.                                                                                                                      \t|\n| | |\n| minFeeB               \t| 155381                                                                 \t| Base transaction fee (in lovelace).                                                                                                                                                                                              \t|\n| minFeeA               \t| 44                                                                     \t| Additional transaction fee per byte of data (in lovelace).                                                                                                                                                                       \t|\n| | |\n| minUTxOValue          \t| 1000000                                                                \t| Minimum allowed value in a UTxO.  Security-related parameter used to prevent the creation of many small UTxOs that could use excessive resource to process.                                                                      \t|\n| | |\n| extraEntropy          \t| ```{         \"tag\": \"NeutralNonce\"     }```                            \t| Should additional entropy be included in the initial phases.  This provides additional certainty that the blockchain has not been compromised by the seed key holders.  Redundant once the system is sufficiently decentralised. \t|\n| eMax                  \t| 18                                                                     \t| Maximum number of epochs within which a pool can be announced to retire, starting from the next epoch.                                                                                                                 \t|\n\n### Non-Updatable Parameters\n\nThe initial non-updatable protocol parameters are given below (in JSON format):\n\n```\n  \"activeSlotsCoeff\": 0.05,\n  ...\n  \"genDelegs\": {\n    \"ad5463153dc3d24b9ff133e46136028bdc1edbb897f5a7cf1b37950c\": {\n      \"delegate\": \"d9e5c76ad5ee778960804094a389f0b546b5c2b140a62f8ec43ea54d\",\n      \"vrf\": \"64fa87e8b29a5b7bfbd6795677e3e878c505bc4a3649485d366b50abadec92d7\"\n    },\n    ...\n    }\n  },\n  \"updateQuorum\": 5,\n  \"networkId\": \"Mainnet\",\n  \"initialFunds\": {},\n  \"maxLovelaceSupply\": 45000000000000000e,\n  \"networkMagic\": 764824073,\n  \"epochLength\": 432000,\n  \"systemStart\": \"2017-09-23T21:44:51Z\",\n  \"slotsPerKESPeriod\": 129600,\n  \"slotLength\": 1,\n  \"maxKESEvolutions\": 62,\n  \"securityParam\": 2160\n}\n```\n\nThe meaning of the fields is:\n\n| Field                 \t| Initial Value                                                          \t| Description\n|-----------------------\t|------------------------------------------------------------------------\t|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\t|\n| activeSlotsCoeff                  \t| 0.05                                                                     \t| The fraction of the total number of slots that will, on average, be selected to include a block in the chain.  Smaller numbers increase security, but reduce efficiency.                                                                                                                 \t|\n| genDelegs                  \t| ...                                                                     \t| Details of the public keys that have been selected by each of the genesis keys to act as a delegate for signing protocol updates etc. |\n| updateQuorum                  \t| 5                                                                     \t| How many of the genesis delegate keys must endorse an update proposal.  |\n| networkId                  \t| \"Mainnet\"                                                                     \t| Is this a testnet or mainnet  |\n| initialFunds                  \t|  {} | initial distribution of funds to addresses. |\n| maxLovelaceSupply                  \t| 45000000000000000                                                                    \t| The limit on the maximum number of lovelace that can be in circulation. |\n| networkMagic                  \t| 764824073                                                                    \t| A magic number used to distinguish different networks. |\n| epochLength                  \t|  432000                                                                   \t| The number of slots in an epoch. |\n| SystemStart                  \t|  \"2017-09-23T21:44:51Z\"                                                                   \t| When did the system originally start operation. |\n| slotsPerKESPeriod             | 129600                                                                   \t| After how many slots will a pool's operational key pair evolve (Key Evolving Signatures). |\n| slotLength             | 1                                                                   \t| The length of each slot (in seconds). |\n| maxKESEvolutions             | 62                                                                   \t| What is the maximum number of times a KES key pair can evolve before a new KES key pair must be generated from the master keys. |\n| securityParam             | 2160                                                                   \t| After how many blocks is the blockchain considered to be final, and thus can no longer be rolled back (i.e. what is the maximum allowable length of any chain fork).  |\n\n\n\n### Pre-Shelley Protocol Parameters\n\nThe original protocol parameters are given in the Byron genesis file.  These parameters need to be included in any operational stake pool so that the Byron portion\nof the chain can be verified, but they can no longer be altered.\n\n```\n{\n    \"avvmDistr\": {\n    ...\n    },\n    \"blockVersionData\": {\n    ...\n    },\n    \"ftsSeed\": \"76617361206f7061736120736b6f766f726f64612047677572646120626f726f64612070726f766f6461\",\n    \"protocolConsts\": {\n    ...\n    },\n    \"startTime\": 1506203091,\n    \"bootStakeholders\": {\n    ...\n    },\n    \"heavyDelegation\": {\n    ...\n    }\n    },\n    \"nonAvvmBalances\": {},\n    \"vssCerts\": {\n    ...\n    }\n```\n\n### Process for Making Changes to Protocol Parameters\n\n#### Governance\n\nChanges will affect many stakeholders and must therefore be subject to open community debate and discussion.\n\nUltimately, the Voltaire protocol voting mechanism will be used to achieve fully automated, decentralised and transparent governance.\nIn the interim, the CIP process will be used.\n\n\n#### Signalling Protocol Parameter Changes\n\nChanges to the parameters need to be signalled to the community well in advance, so that they can take appropriate action.  For the most significant parameters, a minimum of 4-6 weeks\nelapsed time between announcement and enactment is appropriate.  This period must be included in the CIP.  Announcements will be made as soon\nas practical after the conclusion of the vote.\n\n\n#### Applying Protocol Parameter Changes\n\nProtocol parameter changes must be submitted and endorsed within the first 24 hours of the epoch before they are required to come into effect.\nFor example, a change that is intended for epoch 300 must be submitted and endorsed in the first 24 hours of epoch 299.\nOnce a change has been submitted and endorsed by a sufficient quorum of keyholders (currently 5 of the 7 genesis keys), it cannot be revoked.\n\n#### Voiding Proposed Protocol Parameter Changes\n\nOnce a protocol parameter change has been announced, it can only be overridden through the voting process (CIP, Voltaire etc.).  Any vote must be\ncompleted before the start of the epoch in which the change is to be submitted.\n\n### Change Log\n\n#### Changes to the Updatable Parameters since the Shelley Hard Fork Event\n\nFollowing the Shelley hard fork event, the ``decentralisationParam`` parameter has been gradually decreased from ``1.0`` to ``0.3``, with the goal of ultimately decreasing it to ``0`` (at which point\nit can be removed entirely as an updatable parameter).  This has gradually reduced the impact of the federated block producing nodes, so ensuring that the network moves to become a distributed collection of increasingly decentralised stake pools.\nThe parameter was frozen at ``0.32`` between epochs 234 and 240.   The ``nOpt`` parameter was changed from ``150`` to ``500`` in epoch 234.\n\n\n| Epoch |  Date       | Decentralisation | nOpt|\n| ----- |  ---------- | ---------------- | ---- |\n| 208 |\t2020-07-29 |\t1 |\t150|\n| 209 |\t2020-08-03 |\t1 |\t150|\n| 210 |\t2020-08-08 |\t1 |\t150|\n| 211 |\t2020-08-13 |\t0.9 |\t150|\n| 212 |\t2020-08-18 |\t0.8 |\t150|\n| 213 |\t2020-08-23 |\t0.78 |\t150|\n| ... |\t... \t   |\t... |\t...|\n| 227 |\t2020-11-01 |\t0.5 |\t150|\n| ... |\t... \t   |\t... |\t...|\n| 233 |\t2020-12-01 |\t0.38 |\t150|\n| 234 |\t2020-12-06 |\t0.32 |\t500|\n| 235 |\t2020-12-11 |\t0.32 |\t500|\n| ... |\t... \t   |\t... |\t...|\n| 239 |\t2020-12-31 |\t0.32 |\t500|\n| 240 |\t2021-01-05 |\t0.32 |\t500|\n| 241 |\t2021-01-10 |\t0.3 |\t500|\n| ... | ...\t   |\t... |\t...|\n\n\n#### The Allegra Hard Fork Event\n\nThe Allegra Hard Fork Event on 2020-12-16 (epoch 236) introduced token locking capabilities plus some other small changes to the protocol.  No parameters were\nadded or removed.\n\n```\n{\n    \"poolDeposit\": 500000000,\n    \"protocolVersion\": {\n        \"minor\": 0,\n        \"major\": 3\n    },\n    \"minUTxOValue\": 1000000,\n    \"decentralisationParam\": 0.32,\n    \"maxTxSize\": 16384,\n    \"minPoolCost\": 340000000,\n    \"minFeeA\": 44,\n    \"maxBlockBodySize\": 65536,\n    \"minFeeB\": 155381,\n    \"eMax\": 18,\n    \"extraEntropy\": {\n        \"tag\": \"NeutralNonce\"\n    },\n    \"maxBlockHeaderSize\": 1100,\n    \"keyDeposit\": 2000000,\n    \"nOpt\": 500,\n    \"rho\": 3.0e-3,\n    \"tau\": 0.2,\n    \"a0\": 0.3\n}\n```\n\n#### The Mary Hard Fork Event\n\nThe Mary Hard Fork Event will introduce multi-asset token capability.  It is not expected that any parameter will be added or removed.\n\n```\n{\n    \"poolDeposit\": 500000000,\n    \"protocolVersion\": {\n        \"minor\": 0,\n        \"major\": 4\n    },\n    \"minUTxOValue\": 1000000,\n    \"decentralisationParam\": 0.32,\n    \"maxTxSize\": 16384,\n    \"minPoolCost\": 340000000,\n    \"minFeeA\": 44,\n    \"maxBlockBodySize\": 65536,\n    \"minFeeB\": 155381,\n    \"eMax\": 18,\n    \"extraEntropy\": {\n        \"tag\": \"NeutralNonce\"\n    },\n    \"maxBlockHeaderSize\": 1100,\n    \"keyDeposit\": 2000000,\n    \"nOpt\": 500,\n    \"rho\": 3.0e-3,\n    \"tau\": 0.2,\n    \"a0\": 0.3\n}\n```\n\n#### The Alonzo Hard Fork Event\n\nSee [CIP-0028: Protocol Parameters (Alonzo Era)](../CIP-0028).\n\n\n## Rationale: how does this CIP achieve its goals?\n\nThe initial parameter settings were chosen based on information from the Incentivised Testnet, the Haskell Testnet, Stake Pool Operators plus benchmarking and security concerns.  This parameter choice was deliberately conservative,\nin order to avoid throttling rewards in the initial stages of the Cardano mainnet, and to support a wide range of possible stake pool operator (professional, amateur, self, etc.).\nSome parameter choices (``systemStart``, ``securityParam``) were required to be backwards compatible with the Byron chain.\n\n\n### Key Behavioural Parameters\n\n\nThe key  parameters that govern the behaviour of the system are ``nOpt``, ``a0``, ``decentralisationParam`` and ``minPoolCost``.\nChanges to these parameters need to be considered as a package -- there can be unintended consequences when changing a single parameter in isolation.\n\nIt is expected that the following changes to these parameters are likely in the near to medium term:\n\n* increasing ``nOpt`` to align more closely with the number of active pools\n* increasing ``a0`` to increase the pledge effect\n* decreasing ``minPoolCost`` (e.g. in line with growth with the Ada value)\n* decreasing ``decentralisationParam`` to 0 (to enable full decentralisation of block production)\n\nFurther adjustments are likely to be required to tune the system as it evolves.\n\n\n### Economic Parameters\n\nFour parameters govern the economics of the system:  ``tau``, ``rho``, ``minFeeA`` and ``minFeeB``.\nThe first two concern the rate of rewards that are provided to stake pools, delegators and the treasury.\nThe others concern transaction costs.\n\n\n### Transaction and Block Sizes\n\nThree parameters govern block and transaction sizes: ``maxBlockBodySize``, ``maxBlockHeaderSize``, ``maxTxSize``.\nTheir settings have been chosen to ensure the required levels of functionality, within\nconstrained resource restrictions (including long-term blockchain size and real-time worldwide exchange of blocks).\nChanges to these parameters may impact functionality, network reliability and performance.\n\n\n### Backward Compatibility\n\nThis CIP describes the initial set of protocol parameters and the changes to date, so backwards compatibility is not an issue.\nFuture proposals may change any or all of these parameters.\nA change to the major protocol version indicates a major change in the node software.\nSuch a change may involve adding/removing parameters or changing their semantics/formats.\nIn contrast, minor protocol changes are used to ensure key software updates without changing\nthe meaning of any protocol parameters.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] The Shelley ledger era is activated.\n- [x] Documented parameters are in operational use by Cardano Node and Ledger.\n\n### Implementation Plan\n\n- [x] Original (Shelley) and subsequent ledger era parameters are deemed correct by working groups at IOG.\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0). \n"
  },
  {
    "path": "CIP-0010/CIP-0010.md",
    "content": "Moved to [CIP-0010/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0010/README.md",
    "content": "---\nCIP: 10\nTitle: Transaction Metadata Label Registry\nStatus: Active\nCategory: Metadata\nAuthors:\n  - Sebastien Guillemot <sebastien@emurgo.io>\nImplementors: N/A\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/34\n  - https://forum.cardano.org/t/cip10-transaction-metadata-label-registry/41746\nCreated: 2020-10-31\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nCardano transaction metadata forces metadata entries to namespace their content using an unsigned integer key. This specification is a registry of which use cases has allocated which number to avoid collisions.\n\n## Motivation: why is this CIP necessary?\n\nThe top level of the transaction metadata CBOR object is a mapping of `transaction_metadatum_label` to the actual metadata where the `transaction_metadatum_label` represents an (ideally unique) key for a metadata use case. This allows enables the following:\n\n1) Fast lookup for nodes to query all transactions containing metadata that uses a specific key\n2) Allows a single transaction to include multiple metadata entries for different standards\n\n## Specification\n\n### Terminology\n\nTransaction metadata refers to an optional CBOR object in every transaction since the start of the Shelley era. It is defined as the follow CDDL data structure\n\n```\ntransaction_metadatum =\n    { * transaction_metadatum => transaction_metadatum }\n  / [ * transaction_metadatum ]\n  / int\n  / bytes .size (0..64)\n  / text .size (0..64)\n\ntransaction_metadatum_label = uint\n\ntransaction_metadata =\n  { * transaction_metadatum_label => transaction_metadatum }\n```\n\n### Structure\n\nThese are the reserved `transaction_metadatum_label` values:\n\n`transaction_metadatum_label` | description\n----------------------------  | -----------------------\n0 - 15                        | reserved\n65536 - 131071                | reserved - private use\n\nFor the registry itself, please see [registry.json](./registry.json). To add or modify a label definition, please open a pull request against this file. For new label numbers, include background information about your project and/or documentation of the label if available (and state your intended usage if not).\n\nYou can check if a label number is already in use with an API query.  For instance: to check if label `8414` is in use via Koios (no API key needed for `curl`):\n\n```\ncurl -s \"https://api.koios.rest/api/v1/tx_by_metalabel?_label=8414\" -H \"accept: application/json\"\n```\n\n## Rationale: how does this CIP achieve its goals?\n\nCreating a registry for `transaction_metadatum_label` values has the following benefit:\n\n1) It makes it easy for developers to know which `transaction_metadatum_label` to use to query their node if looking for transactions that use a standard\n2) It makes it easy to avoid collisions with other standards that use transaction metadata\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Consistent, long-term use by Cardano implementors of the metadata label registry by all applications requiring a universally acknowledged metadata label.\n- [x] Consistent, long-term use in the CIP editing process: tagging, verifying, and merging new label requirements.\n\n### Implementation Plan\n\n- [x] Confirmed interest and cooperation in this metadata labelling standard and its `registry.json` convention by Cardano implementors: including NFT creators, data aggregators, and sidechains.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n"
  },
  {
    "path": "CIP-0010/registry.json",
    "content": "[\n  {\n    \"transaction_metadatum_label\": 22,\n    \"description\": \"Clarity - DAO creation metadata\"\n  },\n  {\n    \"transaction_metadatum_label\": 87,\n    \"description\": \"milkomeda.com - The protocol magic for the milkomeda protocol\"\n  },\n  {\n    \"transaction_metadatum_label\": 88,\n    \"description\": \"milkomeda.com - the destination address in the sidechain\"\n  },\n  {\n    \"transaction_metadatum_label\": 94,\n    \"description\": \"CIP-0094 - On-chain governance polls\"\n  },\n  {\n    \"transaction_metadatum_label\": 123,\n    \"description\": \"shareslake.com - Bridge routing information\"\n  },\n  {\n    \"transaction_metadatum_label\": 170,\n    \"description\": \"CIP-0170 - KERI-backed metadata attestations\"\n  },\n  {\n    \"transaction_metadatum_label\": 309,\n    \"description\": \"Proof of Existence record\"\n  },\n  {\n    \"transaction_metadatum_label\": 544,\n    \"description\": \"TapDano - Proof Platform\"\n  },\n  {\n    \"transaction_metadatum_label\": 620,\n    \"description\": \"seedtrace.org - supply chain & fair payment tracing\"\n  },\n  {\n    \"transaction_metadatum_label\": 674,\n    \"description\": \"CIP-0020 - Transaction message/comment metadata\"\n  },\n  {\n    \"transaction_metadatum_label\": 721,\n    \"description\": \"CIP-0025 - NFT Token Standard\"\n  },\n  {\n    \"transaction_metadatum_label\": 777,\n    \"description\": \"CIP-0027 - Royalties Standard\"\n  },\n  {\n    \"transaction_metadatum_label\": 839,\n    \"description\": \"Agora - Proposal creation metadata\"    \n  },\n  {\n    \"transaction_metadatum_label\": 867,\n    \"description\": \"CIP-0088 - Token Policy Registration Standard\"\n  },\n  {\n    \"transaction_metadatum_label\": 888,\n    \"description\": \"finitum.io token bridge transactions metadata\"\n  },\n  {\n    \"transaction_metadatum_label\": 1226,\n    \"description\": \"Oracle related transaction metadata\"\n  },\n  {\n    \"transaction_metadatum_label\": 1304,\n    \"description\": \"on-chain certification metadata\"\n  },\n  {\n    \"transaction_metadatum_label\": 1447,\n    \"description\": \"Reeve - transparent and verifiable financial records on-chain\"\n  },\n  {\n    \"transaction_metadatum_label\": 1517,\n    \"description\": \"Reeve - obsolete - pre-launch metadata\"\n  },\n  {\n    \"transaction_metadatum_label\": 1564,\n    \"description\": \"Marlowe - a DSL for writing and executing financial contracts\"\n  },\n  {\n    \"transaction_metadatum_label\": 1667,\n    \"description\": \"CIP-72: dApp registration & Discovery\"\n  },\n  {\n    \"transaction_metadatum_label\": 1668,\n    \"description\": \"Begin Wallet: dApp rating record from dApp Store\"\n  },\n  {\n    \"transaction_metadatum_label\": 1694,\n    \"description\": \"Voltaire - additional metadata for governance, provided in a separate transaction\"\n  },\n  {\n    \"transaction_metadatum_label\": 1854,\n    \"description\": \"CIP-146 Multi-signatures wallet registration\"\n  },\n  {\n    \"transaction_metadatum_label\": 1870,\n    \"description\": \"Open Badges v2.0 compliant metadata\"\n  },\n  {\n    \"transaction_metadatum_label\": 1888,\n    \"description\": \"amphitheatre by the ape society\"\n  },\n  {\n    \"transaction_metadatum_label\": 1904,\n    \"description\": \"Proof of origin and quality related verification data in supply chain\"\n  },\n  {\n    \"transaction_metadatum_label\": 1967,\n    \"description\": \"nut.link metadata oracles registry\"\n  },\n  {\n    \"transaction_metadatum_label\": 1968,\n    \"description\": \"nut.link metadata oracles data points\"\n  },\n  {\n    \"transaction_metadatum_label\": 1983,\n    \"description\": \"cardanohosts.com hosting metadata\"\n  },\n  {\n    \"transaction_metadatum_label\": 1984,\n    \"description\": \"CIP-0171 - On-chain Smart Contract Bytecode Verification\"\n  },\n  {\n    \"transaction_metadatum_label\": 1988,\n    \"description\": \"cardahub.io marketplace metadata\"\n  },\n  {\n    \"transaction_metadatum_label\": 1989,\n    \"description\": \"cardahub.io services metadata\"\n  },\n  {\n    \"transaction_metadatum_label\": 3165,\n    \"description\": \"CPE - Cardano Proposal Examiner\"\n  },\n  {\n    \"transaction_metadatum_label\": 3692,\n    \"description\": \"CIP-0149 - Optional DRep compensation\"\n  },\n  {\n    \"transaction_metadatum_label\": 6676,\n    \"description\": \"Maya Protocol - Cross-chain swap memo (bifrost observer)\"\n  },\n  {\n    \"transaction_metadatum_label\": 6770,\n    \"description\": \"fortunes.coconutpool.com fortune teller\"\n  },\n  {\n    \"transaction_metadatum_label\": 8413,\n    \"description\": \"commitproof.com lets you prove what you knew and when\"\n  },\n  {\n    \"transaction_metadatum_label\": 8414,\n    \"description\": \"claimpaign.com campaigns\"\n  },\n  {\n    \"transaction_metadatum_label\": 10297,\n    \"description\": \"fida.finance transaction metadata\"\n  },\n  {\n    \"transaction_metadatum_label\": 18300,\n    \"description\": \"selfdriven Achievement\"\n  },\n  {\n    \"transaction_metadatum_label\": 18308,\n    \"description\": \"selfdriven Identity\"\n  },\n  {\n    \"transaction_metadatum_label\": 21325,\n    \"description\": \"PRISM's Verifiable Data Registry for the PRISM DID method\"\n  },\n  {\n    \"transaction_metadatum_label\": 61284,\n    \"description\": \"CIP-0015 - Catalyst registration\"\n  },\n  {\n    \"transaction_metadatum_label\": 61285,\n    \"description\": \"CIP-0015 - Catalyst witness\"\n  },\n  {\n    \"transaction_metadatum_label\": 61286,\n    \"description\": \"CIP-0015 - Catalyst deregistration\"\n  }\n]\n"
  },
  {
    "path": "CIP-0010/registry.schema.json",
    "content": "{\n    \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n    \"$id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010\",    \n    \"title\": \"Transaction Metadata Label Registry\",\n    \"description\": \"JSON schema for transaction metadata label registry\",    \n    \"type\": \"array\",\n    \"items\": {\n      \"type\": \"object\",\n      \"properties\": {\n        \"transaction_metadatum_label\": {\n          \"type\": \"integer\",\n          \"minimum\": 0\n        },\n        \"description\": {\n          \"type\": \"string\",\n          \"maxLength\": 256\n        }\n      },\n      \"required\": [\n        \"transaction_metadatum_label\",\n        \"description\"\n      ],\n      \"additionalProperties\": false\n    }\n  }"
  },
  {
    "path": "CIP-0011/CIP-0011.md",
    "content": "Moved to [CIP-0011/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0011/README.md",
    "content": "---\nCIP: 11\nTitle: Staking key chain for HD wallets\nStatus: Active\nCategory: Wallets\nAuthors:\n  - Sebastien Guillemot <sebastien@emurgo.io>\n  - Matthias Benkort <matthias.benkort@iohk.io>\nImplementors: N/A\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/33\n  - https://forum.cardano.org/t/staking-key-chain-for-hd-wallets/41857\n  - https://github.com/cardano-foundation/CIPs/pull/37\nCreated: 2020-11-04\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nStarting with the Shelley hardfork, Cardano makes use of both the *UTXO model* and the *account model*. To support both transaction models from the same master key, we allocate a new chain for [CIP-1852].\n\n## Motivation: why is this CIP necessary?\n\nGenerally it's best to only use a cryptographic key for a single purpose, and so it's best to make the staking key be separate from any key used for UTXO addresses.\n\n## Specification\n\n> **Note** The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"NOT RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).\n\nRecall that [CIP-1852] specifies the following derivation path:\n\n```\nm / purpose' / coin_type' / account' / chain / address_index\n```\n\nWe set `chain=2` to indicate the *staking key chain*. Keys in this chain MUST follow the accounting model for transactions and SHOULD be used for *reward addresses*\n\n### *address_index* value\n\nWe RECOMMEND wallets only use `address_index=0` for compatibility with existing software. This also avoids the need for staking key discovery.\n\nWallets that use multiple staking keys are REQUIRED to use sequential indexing with no gaps. This is to make detection of mangle addresses (addresses where the payment key belongs to the user, but the staking key doesn't) easier.\n\n*Note*: an observer looking at the blockchain will be able to tell if two staking keys belong to the same user if they are generated from the same wallet with different `address_index` values because the payment keys inside the *base addresses* will be the same.\n\n### Test vectors\n\nrecovery phrase\n```\nprevent company field green slot measure chief hero apple task eagle sunset endorse dress seed\n```\n\nprivate key (including chaincode) for `m / 1852' / 1815' / 0' / 2 / 0`\n```\nb8ab42f1aacbcdb3ae858e3a3df88142b3ed27a2d3f432024e0d943fc1e597442d57545d84c8db2820b11509d944093bc605350e60c533b8886a405bd59eed6dcf356648fe9e9219d83e989c8ff5b5b337e2897b6554c1ab4e636de791fe5427\n```\n\nreward address (with `network_id=1`)\n```\nstake1uy8ykk8dzmeqxm05znz65nhr80m0k3gxnjvdngf8azh6sjc6hyh36\n```\n\n## Rationale: how does this CIP achieve its goals?\n\n### Meaning of *account*\n\nThe term \"account\" is unfortunately an overloaded term so we clarify all its uses here:\n\n#### 1) \"Account\" as a BIP44 derivation level\n\nBIP44 uses the term \"account\" as one derivation level to mean the following\n\n> This level splits the key space into independent user identities, so the wallet never mixes the coins across different accounts.\nTo differentiate this from other usage, we sometimes refer to it as an `account'` (the bip32 notation) or a BIP44 Account.\n\n#### 2) \"Account\" as a transaction model\n\nBlockchains like Ethereum does not use the UTXO model and instead uses the [*Account model*](https://github.com/ethereum/wiki/wiki/Design-Rationale#accounts-and-not-utxos) for transactions.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] All notable wallet and tooling providers follow this method of key derivation.\n\n### Implementation Plan\n\n- [x] This method of key derivation has been agreed as canonical and has been included in [CIP-1852].\n- [x] This method of key derivation has been supported by all wallet and tool providers beginning with the Shelley ledger era.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[CIP-1852]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852/README.md\n"
  },
  {
    "path": "CIP-0012/CIP-0012.md",
    "content": "Moved to [CIP-0012/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0012/README.md",
    "content": "---\nCIP: 12\nTitle: On-chain stake pool operator to delegates communication\nStatus: Proposed\nCategory: Metadata\nAuthors:\n  - Marek Mahut <marek.mahut@fivebinaries.com>\n  - Sebastien Guillemot <sebastien@emurgo.io>\n  - Ján Hrnko <jan.hrnko@fivebinaries.com>\nDiscussions:\n  - https://forum.cardano.org/t/on-chain-stake-pool-operator-to-delegates-communication/42229\n  - https://github.com/cardano-foundation/CIPs/pull/44\nCreated: 2020-11-07\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nStandard format for metadata used in an on-chain communication of stake pool owner towards their delegates.\n\n## Motivation: why is this CIP necessary?\n\nStake pool owners and their delegates lack an on-chain communication standard between them.\n\n[CIP-0006](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0006/README.md) already defines an external feed of a stake pool within the extended metadata. However, there is need for a more verifiable on-chain communication standard that will also provide additional cost associated with such communication to prevent its abuse.\n\n## Specification\n\n### Terminology\n\nWe define two types of communication metadata, which are distinguished by transaction metadata label as defined in [CIP-0010: Transaction metadata label registry](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010/README.md):\n\n * *Message board communication* is a type of metadata that has been included in an on-chain transaction between two base addresses associated with a stake pool operator owner address. Given the onetime fee for this communication, we are considering this as a message board of a stake pool, as it also enables delegates to easier access historical metadata communication.\n\n * *Direct delegate communication* is a type of metadata that has been included in an on-chain transaction between a stake pool owner account and a delegate's account. This type of communication is more expensive for the stake pool owner, preventing higher abuse and therefore enables wallets to implement notification granularity. It might be suitable for targeting specific delegates, such as messaging only new joined delegates, loyal delegates, high-amount delegates etc.\n\nAs per CIP-0010, we assign:\n\n* *Message board communication* transaction metadata label `1990`,\n* *Direct delegate communication* transaction metadata label `1991`.\n\n### Metadata\n\nMetadata are written in JSON format and maximum size of metadata around 16KB.\n\nThe root object property is a 3 bytes UTF-8 encoded string representing the ISO 639-3\nlanguage code of the content.\n\n| key                    | Value                                        | Rules                                      |\n| ---------------------- | -------------------------------------------- | ------------------------------------------ |\n| `title` *(required)*   | Title of the communication                   | 64 bytes UTF-8 encoded string              |\n| `content` *(required)* | Content of the communication                 | An array of 64 bytes UTF-8 encoded strings |\n|                        |                                              |\n| `valid` *(optional)*   | Slot number the communication becomes valid  | Unsigned integer                           |\n| `expires` *(optional)* | Slot number until the communication is valid | Unsigned integer                           |\n\n#### Metadata JSON schema\n\nThe [schema.json](./schema.json) file defines the metadata.\n\n#### Metadata example including the transaction metadata label\n\n```\n{\n  \"1991\": [ {\n    \"lat\": {\n      \"title\": \"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do\",\n      \"content\": [\n        \"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do \",\n        \"eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut e\",\n        \"nim ad minim veniam, quis nostrud exercitation ullamco laboris n\",\n        \"isi ut aliquip ex ea commodo consequat. Duis aute irure dolor in\",\n        \" reprehenderit in voluptate velit esse cillum dolore eu fugiat n\",\n        \"ulla pariatur. Excepteur sint occaecat cupidatat non proident, s\",\n        \"unt in culpa qui officia deserunt mollit anim id est laborum.\"\n      ],\n      \"valid\": 10661033,\n      \"expire\": 10669033\n    }\n   },\n   {\n    \"eng\": {\n      \"title\": \"But I must explain to you how all this mistaken idea\",\n      \"content\": [\n        \"But I must explain to you how all this mistaken idea of denounci\",\n        \"ng of a pleasure and praising pain was born and I will give you \",\n        \"a complete account of the system, and expound the actual teachin\",\n        \"gs of the great explorer of the truth, the master-builder of hum\",\n        \"an happiness. No one rejects, dislikes, or avoids pleasure itsel\",\n        \"f, because it is pleasure, but because those who do not know how\",\n        \" to pursue pleasure rationally encounter consequences.\"\n      ],\n      \"valid\": 10661033,\n      \"expire\": 10669033\n    }\n   }\n  ]\n}\n```\n\n## Rationale: how does this CIP achieve its goals?\n\nThe format of the `content` field is required to be an array of 64 bytes chunks, as this is the maximum size of a JSON field in the Cardano ledger. Tools, such as wallets, are required to recompose the content of the message.\n\nThe current Cardano protocol parameter for maximum transaction size, that will hold the metadata, is around 16KB.\n\n### Backwards compatibility\n\nNo backwards compatibility breaking changes are introduced.\n\n## Path to Active\n\n### Acceptance Criteria\n\n * [ ] Indications that more than one wallet or backend supports this standard, including:\n   * [ ] Yoroi (in progress from [Implement CIP12 to Yoroi backends](https://www.lidonation.com/en/proposals/implement-cip12-to-yoroi-backends))\n\n### Implementation Plan\n\n * [x] Develop reference implementation ([CIP12 communication tool examples](https://github.com/fivebinaries/cip-metadata-communication-example))\n * [x] Offer this standard for implementation in downstream tools and wallets: pending their own decisions about whether and how to display communication messages.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0012/schema.json",
    "content": "{\n  \"$schema\": \"http://json-schema.org/draft-07/schema\",\n  \"$id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0012\",\n  \"type\": \"object\",\n  \"title\": \"CIP12\",\n  \"description\": \"Transaction metadata schema for CIP12\",\n  \"patternProperties\": {\n    \"^199{0,1}$\": {\n      \"type\": \"array\",\n      \"items\": [ {\n          \"type\": \"object\",\n          \"patternProperties\": {\n            \"^[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*$\": {\n                \"type\": \"object\",\n                \"required\": [\n                    \"title\",\n                    \"content\"\n                ],\n                \"properties\": {\n                    \"title\": {\n                        \"$id\": \"#/properties/title\",\n                        \"type\": \"string\",\n                        \"title\": \"Title\",\n                        \"description\": \"Title of the communication.\",\n                        \"maxLength\": 64,\n                        \"examples\": [\n                            \"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do\"\n                        ]\n                    },\n                    \"content\": {\n                        \"$id\": \"#/properties/content\",\n                        \"type\": \"array\",\n                        \"title\": \"Content\",\n                        \"description\": \"Content of the communication in chunks\",\n                        \"items\": [\n                          {\n                            \"type\": \"string\",\n                            \"maxLength\": 64\n                          }\n                        ],\n                        \"examples\": [\n                            [\n                              \"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do \",\n                              \"eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut e\",\n                              \"nim ad minim veniam, quis nostrud exercitation ullamco laboris.\"\n                            ]\n                        ]\n                    },\n                    \"valid\": {\n                      \"$id\": \"#/properties/valid\",\n                      \"type\": \"integer\",\n                      \"title\": \"Validity\",\n                      \"description\": \"Slot number when the communication becomes valid\",\n                      \"examples\": [\n                        10669033\n                      ]\n                    },\n                    \"expire\": {\n                        \"$id\": \"#/properties/expire\",\n                        \"type\": \"integer\",\n                        \"title\": \"Expiration\",\n                        \"description\": \"Slot number when the communication expires\",\n                        \"examples\": [\n                          10669033\n                        ]\n                    }\n                },\n                \"additionalProperties\": false\n            }\n          }\n      } ]\n    }\n  }\n}\n"
  },
  {
    "path": "CIP-0013/CIP-0013.md",
    "content": "Moved to [CIP-0013/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0013/README.md",
    "content": "---\nCIP: 13\nTitle: Cardano URI Scheme\nStatus: Proposed\nCategory: Wallets\nAuthors:\n    - Robert Phair <rphair@cosd.com>\n    - Sebastien Guillemot <sebastien@emurgo.io>\n    - Vicente Almonacid <vicente@emurgo.io>\nImplementors: N/A\nDiscussions:\n    - https://github.com/Emurgo/EmIPs/pull/2\n    - https://forum.cardano.org/t/cip-cardano-payment-uri-scheme/41457\n    - https://github.com/cardano-foundation/CIPs/pull/25\n    - https://github.com/cardano-foundation/CIPs/pull/61\n    - https://github.com/cardano-foundation/CIPs/pull/86\n    - https://forum.cardano.org/t/cip-stake-uri-scheme-for-pools-delegation-portfolios/40594\n    - https://forum.cardano.org/t/cip-generalized-cardano-urls/57464\n    - https://github.com/cardano-foundation/CIPs/pull/546\n    - https://github.com/cardano-foundation/CIPs/pull/559\nCreated: 2020-09-22\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis describes a general standard URI scheme with two specific protocols to handle Ada transfers and links to weighted lists of stake pools.\n\n## Motivation: why is this CIP necessary?\n\n### In general:\n\nDevelopers of protocols that use URI schemes should be able to choose unique protocol keywords indicating how these links are handled by applications.\n\nBeyond the two earliest defined protocols below, protocols using distinct keywords (e.g. `//stake`) can be defined in other CIPs and implemented without ambiguity by applications which interpret those particular URI protocols.\n\n### For payment URIs:\n\nUsers who create community content often want donations as a financial incentive. However, forcing users to open their wallet and copy-paste an address lowers the amount of people likely to send tokens (especially if they have to sync their wallet first).\n\nIf donating was as simple as clicking a link that opens a light wallet with pre-populated fields, users may be more willing to send tokens. URI schemes would enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.\n\n### For stake pool URIs:\n\nCentralised sources of information have led a growing amount of stake to be disproportionately assigned to pools pushed near & beyond the saturation point.\n\nStake pool URIs will provide an additional means for small pools to acquire delegation and maintain stability, supporting diversity and possibly fault-tolerance in the Cardano network through a more even distribution of stake.\n\nInterfaces that connect delegators with pools beyond the highly contested top choices of the in-wallet ranking algorithms are important to avoid saturation and maintain decentralization.\n\nLarger pools and collectives can also use these URIs to link to, and spread delegation between, a family of pools they own to avoid any one of their pools becoming saturated.\n\nPool links allow for interfaces to initiate delegation transactions without requiring any code modifications to the wallets themselves.\n\nURIs for weighted stake pool lists provide alternatives to using a JSON file to implement *delegation portfolios* in a way that may better suit certain platforms, applications, or social contexts.\n\n## Specification\n\nThe core implementation should follow the [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) standard (with `bitcoin:` replaced with `web+cardano:`)\n\nExamples:\n```\n<a href=\"web+cardano:Ae2tdPwUPEZ76BjmWDTS7poTekAvNqBjgfthF92pSLSDVpRVnLP7meaFhVd\">Donate</a>\n<a href=\"web+cardano://stake?c94e6fe1123bf111b77b57994bcd836af8ba2b3aa72cfcefbec2d3d4\">Stake with us</a>\n<a href=\"web+cardano://stake?POOL1=3.14159&POOL2=2.71828\">Split between our 2 related pools</a>\n<a href=\"web+cardano://stake?COSD\">Choose our least saturated pool</a>\n<a href=\"web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.hosky.io&code=consensus2023\">Claim $HOSKY</a>\n```\n\nThe protocol term (e.g. `//stake`) is called the _authority_ as defined in [Wikipedia > Uniform Resource Identifier > Syntax](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Syntax).\n\n### Choice of URI scheme name\n\n`cardano:` is chosen over `ada:` because other projects that implement this standard tend to take the project name over the currency name (this makes sense if we consider this protocol as a generic way for interacting with the blockchain through wallets and dApps - as opposed to a simple payment system).\n\nDepending on the protocol registration method (see Rationale), browsers generally enforce a `web+` or `ext+` prefix for non-whitelisted protocols (note: `bitcoin:` was whitelisted; see [registerProtocolHandler > Permitted schemes](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler#permitted_schemes)). The prefix `ext+` is recommended for extensions, but not mandatory (see [protocol_handlers](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers)).\n\n### Grammar & interpretation\n\nThis top-level definition is mainly to allow switching to a particular protocol for each separately defined `authority`, with a payment link being the default:\n\n* When `authority` is unspecified, it is a payment URI (with an address and an optional amount parameter;\n* When `authority` is explicit (containing `//` followed by the authority keyword), it is defined in the `//stake` case below or in a separate CIP for that protocol.\n\n```\ncardanouri = \"web+cardano:\" (paymentref | authorityref)\n\nauthorityref = (stakepoolref | otherref)\notherref = \"//\" authority query\n```\n\nFor grammar reference, see:\n\n  - [Wikipedia > Augmented Backus–Naur form](https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_form)\n  - [RFC 2234: Augmented BNF for Syntax Specifications: ABNF](https://datatracker.ietf.org/doc/html/rfc2234)\n  - [Unicode in ABNF](https://tools.ietf.org/html/draft-seantek-unicode-in-abnf-00)\n\n#### Payment URI queries\n\n```\npaymentref = cardanoaddress [ \"?\" amountparam ]\ncardanoaddress = *(base58 | bech32)\namountparam = \"amount=\" *digit [ \".\" *digit ]\n```\n\nThe amount parameter must follow the [same rules](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki#transfer-amountsize) described in BIP-21, namely, it must be specified in decimal ADA, without commas and using the period (.) decimal separator.\n\n#### Stake pool URI queries\n\n```\nstakepoolref = \"//stake\" query\nquery = ( \"?\" stakepoolpair) *( \"&\" stakepoolpair)\nstakepoolpair = stakepool [ \"=\" proportion]\n\nstakepool = poolhexid | poolticker\npoolhexid = 56HEXDIG\npoolticker = 3*5UNICODE\n\nproportion = *digit [ \".\" *digit ]\n```\n\nFor brevity, essential in many Internet contexts, `poolticker`  must be supported here in addition to the unambiguous `poolhexid`.\n\n##### Interpretation of `proportion`\n\n* If only one stake pool is specified, any proportion is meaningless and ignored.\n* If all stake pools have a numerical proportion, each component of the resulting stake distribution will have the same ratio as the provided `proportion` to the sum of all the propotions.\n* Any missing `proportion` is assigned a precise value of `1`.\n* If a stake pool is listed multiple times, the URI is rejected as invalid.\n\n##### Handling stake pool links\n\nWhen there is more than one pool registered with any of the specified `poolticker` parameters (whether for pool groups which have the same ticker for all pools, or for separate pools using the same ticker), the choice to which pool(s) to finally delegate is left to the user through the wallet UI.\n\nThe wallet UI should always confirm the exact delegation choice even when it is unambiguous from the URI.  When the user has multiple wallets, the wallet UI must select which wallet(s) the user will be delegating from.\n\nIf, during a wallet or other application's development process, it is still only able to support single pool links, these parameters in the URI query string should (by preference of the wallet UI designers) *either* be ignored *or* generate a warning message, to avoid leading the user to believe they are implementing a currently unsupported but perhaps popularly referenced multi-pool delegation list:\n\n* any value for the first URI query argument;\n* any URI query argument beyond the first.\n\n#### Other URI queries\n\nAn ABNF grammar should be specified and explained similarly for each CIP that defines a new Cardano URI authority by explicitly defining the terms `authority` and `query` as for the \"Stake pool\" case above.\n\n### Security Considerations\n\n1. For payment links, we cannot prompt the user to send the funds right away as they may not be fully aware of the URI they clicked or were redirected to. Instead, it may be better to simply pre-populate fields in a transaction.\n2. For either payment or staking links, we should be wary of people who disguise links as actually opening up a phishing website that LOOKS like that corresponding part of the wallet UI.\n3. If wallets *create* stake pool links, the actual ada or lovelace balance should not be used literally as the `proportion` figure, to avoid revealing the identity of the wallet owner who is creating the portfolio (e.g. the proportions could be scaled to normalise the largest to `1`).\n\n## Rationale: how does this CIP achieve its goals?\n\n### Rationale for general URI scheme\n\n#### Why not use Universal links, deep links or other non-protocol-based Solution?\n\nAn alternative solution to the original problem described above is to use standard URL links in combination with a routing backend system. The routing system is used to redirect to the app's URI. The advantage of this scheme is that it allows to provide a fallback mechanism to handle the case when no application implementing the protocol is installed (for instance, by redirecting to the App Store or Google Play). This is the approach behind iOS Universal Links and Android App Links. In general, it provides a better user experience but requires a centralized system which makes it unsuitable for as a multi-app standard.\n\nFor background, see\n\n  - [Android Developer Docs > Add intent filters for incoming links](https://developer.android.com/training/app-links/deep-linking#adding-filters)\n  - [Apple Developer Docs > Defining a custom URL scheme for your app](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app)\n  - [React Native > Linking](https://reactnative.dev/docs/linking.html)\n\n### Rationale for payment links\n\n#### Why confine payment links to address and amount like BIP-21?\n\nBIP-21 is limited to only features Bitcoin supports. A similar feature for Ethereum would, for example, also support gas as an extra parameter. BIP-21 is easily extensible but we have to take precaution to avoid different wallets having different implementations of these features as they become available on Cardano. To get an idea of some extra features that could be added, consider this (still under discussion) proposal for Ethereum: [EIP-681](https://eips.ethereum.org/EIPS/eip-681)\n\n### Rationale for stake pool links\n\n#### How do URI delegation portfolio links supplement use of JSON files for the same purpose?\n\nURIs facilitate the \"social element\" of delegated staking and pool promotion through a socially familiar, easily accessible, and less centralised convention for sharing stake pool references and potential delegation portfolios without having to construct or host a JSON file.\n\nThe processing of a JSON file delivered by a web server will depend highly on a user's platform and might not even be seen by the wallet application at all.  With a properly associated `web+cardano:` protocol, developers and users have another option available in case JSON files are not delivered properly to the wallet application.\n\nFor a CIP based on this principle, see [CIP-0017](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0017/README.md).\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] There exist one or more wallets supporting Payment URIs.\n  - [x] Yoroi\n  - [x] Begin Wallet\n- [x] There exist one or more wallets supporting Stake Pool URIs.\n  - [ ] TBD\n- [x] There exist other CIPs or drafts defining additional URI protocols.\n  - [x] [CIP-0099](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0099/README.md)  \n- [x] There exist one or more wallets supporting additional URI protocols.\n  - [x] Yoroi (CIP-0099)\n  - [x] Begin Wallet (CIP-0099)\n  - [x] VESPR (CIP-0099)  \n\n### Implementation Plan\n\nEncourage wallet and dApp developers to support all currently defined URI protocols, keeping in mind these are each likely to be considered separately:\n\n- Payment URIs\n- Stake Pool URIs\n- all other URI schemes defined in separate CIPs\n\nEducation and advocacy about these standards should be done by:\n\n- Developers of applications and standards requiring new URI schemes\n- Cardano sponsoring companies\n- Community advocates\n- CIP editors\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0014/CIP-0014.md",
    "content": "Moved to [CIP-0014/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0014/README.md",
    "content": "---\nCIP: 14\nTitle: User-Facing Asset Fingerprint \nStatus: Active\nCategory: Tokens\nAuthors:\n  - Matthias Benkort <matthias.benkort@iohk.io>\n  - Rodney Lorrimar <rodney.lorrimar@iohk.io>\nImplementors: N/A\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/64\nCreated: 2020-02-01\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis specification defines a user-facing asset fingerprint as a bech32-encoded blake2b-160 digest of the concatenation of the policy id and the asset name.\n\n## Motivation: why is this CIP necessary?\n\nThe Mary era of Cardano introduces the support for native assets. On the blockchain, native assets are uniquely identified by both their so-called policy id and asset name. Neither the policy id nor the asset name are intended to be human-readable data. \n\nOn the one hand, the policy id is a hash digest of either a monetary script or a Plutus script. On the other hand, the asset name is an arbitrary bytestring of up to 32 bytes (which does not necessarily decode to a valid UTF-8 sequence). In addition, it is possible for an asset to have an empty asset name, or, for assets to have identical asset names under different policies. \n\nBecause assets are manipulated in several user-facing features on desktop and via hardware applications, it is useful to come up with a short(er) and human-readable identifier for assets that user can recognize and refer to when talking about assets. We call such an identifier an _asset fingerprint_.\n\n## Specification\n\nWe define the asset fingerprint in pseudo-code as:\n\n```\nassetFingerprint := encodeBech32\n  ( datapart = hash\n    ( algorithm = 'blake2b'\n    , digest-length = 20\n    , message = policyId | assetName\n    )\n  , humanReadablePart = 'asset'\n  )\n```\n\nwhere `|` designates the concatenation of two byte strings. The `digest-length` is given in _bytes_ (so, 160 bits).\n\n### Reference Implementation\n\n#### Javascript\n\n[cip14-js](https://www.npmjs.com/package/@emurgo/cip14-js)\n\n#### Haskell (GHC >= 8.6.5)\n\n<details>\n  <summary>Language Extensions</summary>\n\n```hs\n{-# LANGUAGE OverloadedStrings #-}\n{-# LANGUAGE QuasiQuotes #-}\n{-# LANGUAGE TypeApplications #-}\n```\n</details>\n\n<details>\n  <summary>Imports</summary>\n\n```hs\n-- package: base >= 4.0.0\nimport Prelude\nimport Data.Function\n    ( (&) )\n\n-- package: bech32 >= 1.0.2\nimport qualified Codec.Binary.Bech32 as Bech32\n\n-- package: bech32-th >= 1.0.2\nimport Codec.Binary.Bech32.TH\n    ( humanReadablePart )\n\n-- package: bytestring >= 0.10.0.0\nimport Data.ByteString\n    ( ByteString )\n\n-- package: cryptonite >= 0.22\nimport Crypto.Hash\n    ( hash )\nimport Crypto.Hash.Algorithms\n    ( Blake2b_160 )\n\n-- package: memory >= 0.14\nimport Data.ByteArray\n    ( convert )\n\n-- package: text >= 1.0.0.0\nimport Data.Text\n    ( Text )\n```\n</details>\n\n```hs\nnewtype PolicyId = PolicyId ByteString\nnewtype AssetName = AssetName ByteString\nnewtype AssetFingerprint = AssetFingerprint Text\n\nmkAssetFingerprint :: PolicyId -> AssetName -> AssetFingerprint\nmkAssetFingerprint (PolicyId policyId) (AssetName assetName)\n    = (policyId <> assetName)\n    & convert . hash @_ @Blake2b_160\n    & Bech32.encodeLenient hrp . Bech32.dataPartFromBytes\n    & AssetFingerprint\n  where\n    hrp = [humanReadablePart|asset|]\n```\n\n### Test Vectors\n\n> :information_source: `policy_id` and `asset_name` are hereby base16-encoded; their raw, decoded, versions should be used when computing the fingerprint.\n\n```yaml\n- policy_id: 7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc373\n  asset_name: \"\"\n  asset_fingerprint: asset1rjklcrnsdzqp65wjgrg55sy9723kw09mlgvlc3\n\n- policy_id: 7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc37e\n  asset_name: \"\"\n  asset_fingerprint: asset1nl0puwxmhas8fawxp8nx4e2q3wekg969n2auw3\n\n- policy_id: 1e349c9bdea19fd6c147626a5260bc44b71635f398b67c59881df209\n  asset_name: \"\"\n  asset_fingerprint: asset1uyuxku60yqe57nusqzjx38aan3f2wq6s93f6ea\n\n- policy_id: 7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc373\n  asset_name: 504154415445\n  asset_fingerprint: asset13n25uv0yaf5kus35fm2k86cqy60z58d9xmde92\n\n- policy_id: 1e349c9bdea19fd6c147626a5260bc44b71635f398b67c59881df209\n  asset_name: 504154415445\n  asset_fingerprint: asset1hv4p5tv2a837mzqrst04d0dcptdjmluqvdx9k3\n\n- policy_id: 1e349c9bdea19fd6c147626a5260bc44b71635f398b67c59881df209\n  asset_name: 7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc373\n  asset_fingerprint: asset1aqrdypg669jgazruv5ah07nuyqe0wxjhe2el6f\n\n- policy_id: 7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc373\n  asset_name: 1e349c9bdea19fd6c147626a5260bc44b71635f398b67c59881df209\n  asset_fingerprint: asset17jd78wukhtrnmjh3fngzasxm8rck0l2r4hhyyt\n\n- policy_id: 7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc373\n  asset_name: 0000000000000000000000000000000000000000000000000000000000000000\n  asset_fingerprint: asset1pkpwyknlvul7az0xx8czhl60pyel45rpje4z8w\n```\n\n## Rationale: how does this CIP achieve its goals?\n\n### Design choices\n\n- The asset fingerprint needs to be _somewhat unique_ (although collisions are plausible, see next section) and refer to a particular asset. It must therefore include both the policy id and the asset name.\n\n- Using a hash gives us asset id of a same deterministic length which is short enough to display reasonably well on small screens.\n\n- We use bech32 as a user-facing encoding since it is both user-friendly and quite common within the Cardano eco-system (e.g. addresses, pool ids, keys).\n\n### Security Considerations\n\n- With a 160-bit digest, an attacker needs at least 2^80 operations to find a collision. Although 2^80 operations is relatively low (it remains expansive but doable for an attacker), it \n  is considered safe within the context of an asset fingerprint as a mean of _user verification_ within a particular wallet. An attacker may obtain advantage if users can be persuaded \n  that a certain asset is in reality another (which implies to find a collision, and make both assets at the reach of the user). \n\n- We recommend however that in addition to the asset fingerprint, applications also show whenever possible a visual checksum calculated from the policy id and the asset name as specified in [CIP-YET-TO-COME](). Such generated images, which are designed to be unique and easy to distinguish, in combination with a readable asset fingerprint gives strong verification means to end users. \n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Asset fingerprints as described have been universally adopted in: wallets, blockchain explorers, query layers, token minting utilities, NFT specifications, and CLI tools.\n\n### Implementation Plan\n\n- [x] Reference implementations available in both Javascript and Haskell.\n- [x] Public presentation with confirmed interest in adopting this standard in advance of Mary ledger era.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0015/CIP-0015.md",
    "content": "Moved to [CIP-0015/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0015/README.md",
    "content": "---\nCIP: 15\nTitle: Registration Transaction Metadata Format\nCategory: Metadata\nStatus: Active\nAuthors:\n    - Sebastien Guillemot <sebastien@dcspark.io>, \n    - Rinor Hoxha <rinor.hoxha@iohk.io>, \n    - Mikhail Zabaluev <mikhail.zabaluev@iohk.io>\nImplementors:\n    - Daedalus <https://daedaluswallet.io/>,\n    - DcSpark <https://www.dcspark.io/>,\n    - Eternl <https://eternl.io/>,\n    - Flint <https://flint-wallet.com/>,\n    - Project Catalyst <https://projectcatalyst.io/>,\n    - Typhon <https://typhonwallet.io/>,\n    - Yoroi <https://yoroi-wallet.com/>\nDiscussions:\n    - https://forum.cardano.org/t/cip-catalyst-registration-metadata-format/44038\n    - https://github.com/cardano-foundation/cips/pulls/58\nCreated: 2020-01-05\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP details a transaction metadata format, used by Cardano's [Project Catalyst](https://projectcatalyst.io) for voter registrations.\n\n## Motivation: why is this CIP necessary?\n\nProject Catalyst uses a sidechain for it's voting system.\nOne of the desirable properties of this sidechain is that even if its' safety is compromised, it doesn't cause a loss of funds on Cardano mainnet. \nTo achieve this, instead of using Cardano wallets' recovery phrase on the sidechain, we introduce the \"voting key\".\n\nHowever, since Catalyst uses stake-based voting, a user needs to associate their mainnet Ada to their voting key. \nThis can be achieved through a voter registration transaction.\n\nWe therefore need a voter registration transaction that serves three purposes:\n\n1. Registers a voting key to be included in the sidechain\n2. Associates Mainnet ada to this voting key\n3. Declare an address to receive Catalyst voting rewards\n\n## Specification\n\n### Voting key format\n\nA voting key is simply an ED25519 key. \nHow this key is created is up to the wallet, although it is not recommended that the wallet derives this key deterministicly from a mnemonic used on Cardano.\n\n### Registration metadata format\n\nA Catalyst registration transaction is a regular Cardano transaction with a specific transaction metadata associated with it.\n\nNotably, there should be four entries inside the metadata map:\n\nVoting registration example:\n\n```cddl\n61284: {\n  // voting_key - CBOR byte array\n  1: \"0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663\",\n  // stake_pub - CBOR byte array\n  2: \"0xad4b948699193634a39dd56f779a2951a24779ad52aa7916f6912b8ec4702cee\",\n  // reward_address - CBOR byte array\n  3: \"0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee47b60edc7772855324c85033c638364214cbfc6627889f81c4\",\n  // nonce\n  4: 5479467\n}\n```\n\nThe entries under keys 1, 2, 3, and 4 represent the Catalyst voting key, the staking key on the Cardano network, the address to receive rewards, and a nonce, respectively. \nA registration with these metadata will be considered valid if the following conditions hold:\n\n- The nonce is an unsigned integer (of CBOR major type 0) that should be monotonically rising across all transactions with the same staking key. \n  - The advised way to construct a nonce is to use the current slot number.\n  - This is a simple way to keep the nonce increasing without having to access the previous transaction data.\n- The reward address is a Shelley address discriminated for the same network this transaction is submitted to.\n\nTo produce the signature field, the CBOR representation of a map containing a single entry with key `61284` and the registration metadata map in the format above is formed, designated here as `sign_data`.\nThis data is signed with the staking key as follows: first, the blake2b-256 hash of `sign_data` is obtained. \nThis hash is then signed using the Ed25519 signature algorithm. The signature metadata entry is added to the transaction under key 61285 as a CBOR map with a single entry that consists of the integer key 1 and signature as obtained above as the byte array value.\n\nSignature example:\n\n```cddl\n61285: {\n  // signature - ED25119 signature CBOR byte array\n  1: \"0x8b508822ac89bacb1f9c3a3ef0dc62fd72a0bd3849e2381b17272b68a8f52ea8240dcc855f2264db29a8512bfcd522ab69b982cb011e5f43d0154e72f505f007\"\n}\n```\n### Versioning\n\nThis CIP is not to be versioned using a traditional scheme, rather if any large technical changes require a new proposal to replace this one.\nSmall changes can be made if they are completely backwards compatible.\n\n### Changelog\n\nCatalyst Fund 3: \n- added the `reward_address` inside the `key_registration` field.\n\nCatalyst Fund 4:\n- added the `nonce` field to prevent replay attacks;\n- changed the signature algorithm from one that signed `sign_data` directly to signing the Blake2b hash of `sign_data` to accommodate memory-constrained hardware wallet devices.\n\nIt was planned that since Fund 4, `registration_signature` and the `staking_pub_key` entry inside the `key_registration` field will be deprecated.\nThis has been deferred to a future revision of the protocol.\n\n## Rationale: how does this CIP achieve its goals?\n\nThe described metadata format allows for the association of a voting key with a stake credential on a Cardano network.\n\n### Associating stake with a voting key\n\nCardano uses the UTxO model so to completely associate a wallet's balance with a voting key (i.e. including enterprise addresses), we would need to associate every payment key to a voting key individually.\nAlthough there are attempts at this (see [CIP-0008]), the resulting data structure is a little excessive for on-chain metadata (which we want to keep small).\n\nGiven the above, we choose to only associate staking keys with voting keys.\nSince most Cardano wallets only use base addresses for Shelley wallet types, in most cases this should perfectly match the user's wallet.\n\n### Future development\n\nA future change of the Catalyst system may make use of a time-lock script to commit ADA on the mainnet for the duration of a voting period.\nThe voter registration metadata in this method will not need an association with the staking key.\nTherefore, the `staking_pub_key` map entry and the `registration_signature` payload with key `61285` will no longer be required.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] This metadata format is implemented by at least 3 wallets\n  - Deadalus <https://daedaluswallet.io/>\n  - Eternl <https://eternl.io/>,\n  - Flint <https://flint-wallet.com/>,\n  - Typhon <https://typhonwallet.io/>,\n  - Yoroi <https://yoroi-wallet.com/>\n- [x] This metadata format is used by Catalyst for at least 3 funds\n  - This format has been used up to and included Catalyst fund 10\n\n### Implementation Plan\n\n- [x] Author(s) to provide a schema cddl file\n  - See the [schema file](./schema.cddl)\n- [x] Author(s) to provide a test vectors file\n  -  See [test vector file](./test-vector.md)\n- [x] Author(s) to provide a npm package to support the creation of this metadata format\n  - [catalyst-registration-js](https://www.npmjs.com/package/@dcspark/catalyst-registration-js)\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[CIP-0008]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0008/README.md\n"
  },
  {
    "path": "CIP-0015/schema.cddl",
    "content": "registration_cbor = {\n  61284: key_registration,\n  61285: registration_signature\n}\n\n$voting_pub_key /= bytes .size 32\n$staking_pub_key /= bytes .size 32\n$ed25519_signature /= bytes .size 64\n$reward_address /= bytes\n$nonce /= uint\n\nkey_registration = {\n  1 : $voting_pub_key,\n  2 : $staking_pub_key,\n  3 : $reward_address,\n  4 : $nonce,\n}\n\nregistration_signature = {\n  1 : $ed25519_signature\n}\n"
  },
  {
    "path": "CIP-0015/test-vector.md",
    "content": "# Test vector for CIP15\n\n### Inputs\n\nPayment **public** key hex\n```\n3273a5316e4de228863bd7cf8dac90d57149e1a595f3dd131073b84e35546676\n```\n\nStaking **private** key hex\n```\nf5beaeff7932a4164d270afde7716067582412e8977e67986cd9b456fc082e3a\n```\n\nCatalyst **private** key hex\n```\n4820f7ce221e177c8eae2b2ee5c1f1581a0d88ca5c14329d8f2389e77a465655c27662621bfb99cb9445bf8114cc2a630afd2dd53bc88c08c5f2aed8e9c7cb89\n```\n\n### Intermediate steps\n\nReward address generated from staking key\n```\nbech32\nstake_test1uzhr5zn6akj2affzua8ylcm8t872spuf5cf6tzjrvnmwemcehgcjm\n\nhex-encoded\ne0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef\n```\n\nData to sign (human readable format)\n```javascript\n61284: {\n  1: '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0',\n  2: '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e',\n  3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',\n  4: 1234,\n},\n```\n\nMetadata (CBOR encoding)\n```\na119ef64a40158200036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a002582086870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e03581de0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef041904d2\n```\n\nBlake2b-256 hash of metadata\n```\na3d63f26cd94002443bc24f24b0a150f2c7996cd3a3fd247248de396faea6a5f\n```\n\n### Output\n\n```javascript\n{\n  61284: {\n    1: '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0',\n    2: '0x1c5d88aa573da97e5a4667e0f7c4a9c6a3d848934c3b0a5b9296b401540f2aef',\n    3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',\n    4: 1234\n  },\n  61285: {\n    1: '0x6c2312cd49067ecf0920df7e067199c55b3faef4ec0bce1bd2cfb99793972478c45876af2bc271ac759c5ce40ace5a398b9fdb0e359f3c333fe856648804780e'\n  }\n}\n```\n"
  },
  {
    "path": "CIP-0016/CIP-0016.md",
    "content": "Moved to [CIP-0016/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0016/README.md",
    "content": "---\nCIP: 16\nTitle: Cryptographic Key Serialisation Formats\nStatus: Active\nCategory: Tools\nAuthors:\n  - Luke Nadur <luke.nadur@iohk.io>\nImplementors:\n  - jcli <https://github.com/input-output-hk/catalyst-core/tree/main/src/jormungandr/jcli>\n  - cardano-signer <https://github.com/gitmachtl/cardano-signer>\n  - cardano-serialization-lib <https://github.com/Emurgo/cardano-serialization-lib>\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/57\nType: Standards\nCreated: 2020-12-21\nLicense: Apache-2.0\n---\n\n## Abstract\n\nThis CIP defines serialisation formats for the following types of\ncryptographic keys across the Cardano eco-system:\n\n- Regular Ed25519 keys\n\n- [BIP32-Ed25519](https://ieeexplore.ieee.org/document/7966967) extended keys\n  (Ed25519 extended keys with BIP32-style derivation)\n\n## Motivation\n\nThroughout the Cardano eco-system, different projects have used different\nserialisation formats for cryptographic keys.\n\nFor example, for BIP32-Ed25519 extended signing keys, the\n[`cardano-crypto`](https://github.com/input-output-hk/cardano-crypto)\nimplementation supports a 128-byte binary serialization format, while\n[`jcli`](https://input-output-hk.github.io/jormungandr/jcli/introduction.html)\nand\n[`cardano-addresses`](https://github.com/input-output-hk/cardano-addresses)\nsupports a 96-byte binary serialization format.\n\nAnother example would be\n[`cardano-cli`](https://github.com/input-output-hk/cardano-node) which\nsupports a custom JSON format, referred to as \"text envelope\", (which can be\nused for serialising keys) that isn't supported by other projects in the\neco-system.\n\nThis has introduced compatibility problems for both users and developers:\n\n- Users cannot easily utilize their keys across different tools and software\n  in the Cardano eco-system as they may be serialized in different ways.\n\n- Developers wanting to support the different serialisation formats may need\n  to write potentially error-prone (de)serialisation and conversion\n  operations.\n\nTherefore, this CIP aims to define standard cryptographic key serialisation\nformats to be used by projects throughout the Cardano eco-system.\n\n## Specification\n\n### Verification Keys\n\nFor the verification (public) key binary format, we simply use the raw 32-byte\nEd25519 public key data.\n\nThis structure should be Bech32 encoded, using one of the appropriate `*_vk`\nprefixes defined in CIP-0005.\n\n### Extended Verification Keys\n\nFor extended verification (public) keys, we define the following 64-byte\nbinary format:\n\n```\n+-----------------------+-----------------------+\n| Public Key (32 bytes) | Chain Code (32 bytes) |\n+-----------------------+-----------------------+\n```\n\nThat is, a 32-byte Ed25519 public key followed by a 32-byte chain code.\n\nThis structure should be Bech32 encoded, using one of the appropriate `*_xvk`\nprefixes defined in CIP-0005.\n\n### Signing Keys\n\nFor the signing (private) key binary format, we simply use the raw 32-byte\nEd25519 private key data.\n\nThis structure should be Bech32 encoded, using one of the appropriate `*_sk`\nprefixes defined in CIP-0005.\n\n### Extended Signing Keys\n\nFor extended signing (private) keys, we define the following 96-byte binary\nformat:\n\n```\n+---------------------------------+-----------------------+\n| Extended Private Key (64 bytes) | Chain Code (32 bytes) |\n+---------------------------------+-----------------------+\n```\n\nThat is, a 64-byte Ed25519 extended private key followed by a 32-byte chain\ncode.\n\nThis structure should be Bech32 encoded, using one of the appropriate `*_xsk`\nprefixes defined in CIP-0005.\n\n## Rationale\n\n### Extended Signing Key Format\n\nAs mentioned in the [Abstract](#abstract), the original\n[`cardano-crypto`](https://github.com/input-output-hk/cardano-crypto)\nimplementation defined a 128-byte binary serialization format for\nBIP32-Ed25519 extended signing keys:\n\n```\n+---------------------------------+-----------------------+-----------------------+\n| Extended Private Key (64 bytes) | Public Key (32 bytes) | Chain Code (32 bytes) |\n+---------------------------------+-----------------------+-----------------------+\n```\n\nHowever, as it turns out, keeping around the 32-byte Ed25519 public key is\nredundant as it can easily be derived from the Ed25519 private key (the first\n32 bytes of the 64-byte extended private key).\n\nTherefore, because other projects such as\n[`jcli`](https://input-output-hk.github.io/jormungandr/jcli/introduction.html)\nand\n[`cardano-addresses`](https://github.com/input-output-hk/cardano-addresses)\nalready utilize the more compact 96-byte format, we opt to define that as the\nstandard.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Confirm support by applications and tools from different developers:\n  - [x] [jcli](https://github.com/input-output-hk/catalyst-core/tree/main/src/jormungandr/jcli)\n  - [x] [cardano-signer](https://github.com/gitmachtl/cardano-signer)\n  - [x] [cardano-serialization-lib](https://github.com/Emurgo/cardano-serialization-lib)\n\n### Implementation Plan\n\nN/A\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0).\n"
  },
  {
    "path": "CIP-0017/CIP-0017.json",
    "content": "{ \"title\": \"CIP-0017 - Cardano Delegation Portfolio\"\n, \"$schema\": \"https://json-schema.org/draft-07/schema\"\n, \"type\": \"object\"\n, \"required\":\n    [ \"name\"\n    , \"pools\"\n    ]\n, \"properties\":\n    { \"name\":\n        { \"type\": \"string\"\n        , \"minLength\": 1\n        }\n    , \"description\":\n        { \"type\": \"string\"\n        , \"minLength\": 1\n        }\n    , \"author\":\n        { \"type\": \"string\"\n        , \"minLength\": 1\n        }\n    , \"pools\":\n        { \"type\": \"array\"\n        , \"minItems\": 1\n        , \"items\":\n            { \"type\": \"object\"\n            , \"required\":\n                [ \"id\"\n                , \"weight\"\n                ]\n            , \"properties\":\n                { \"id\":\n                    { \"type\": \"string\"\n                    , \"minLength\": 56\n                    , \"maxLength\": 56\n                    , \"contentEncoding\": \"base16\"\n                    }\n                , \"name\":\n                    { \"type\": \"string\"\n                    , \"minLength\": 1\n                    }\n                , \"ticker\":\n                    { \"type\": \"string\"\n                    , \"minLength\": 3\n                    , \"maxLength\": 5\n                    }\n                , \"weight\":\n                    { \"type\": \"integer\"\n                    , \"minimum\": 1\n                    }\n                }\n            }\n        }\n    }\n}\n"
  },
  {
    "path": "CIP-0017/CIP-0017.md",
    "content": "Moved to [CIP-0017/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0017/README.md",
    "content": "---\nCIP: 17\nTitle: Cardano Delegation Portfolio\nStatus: Inactive (abandoned for lack of interest)\nCategory: Tools\nAuthors:\n  - Matthias Benkort <matthias.benkort@cardanofoundation.org>\nImplementors: []\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/82\nCreated: 2020-04-02\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis document details a common format for sharing Cardano delegation portfolio across various tools and wallets. \n\n## Motivation: why is this CIP necessary?\n\nStakeholders have indicated the desire to split their stake in various sizes and delegate to n pools from a single wallet/mnemonic. Albeit there are no monetary incentive for users to do this, the desire to drive decentralisation is sufficiently prevalent to justify it. Furthermore, stakeholders want to introduce a certain social element to this activity by sharing their delegation portfolio with other stakeholders. This specification should help to standardize the representation of portfolios across tools for more interoperability. \n\n## Specification\n\n### Overview\n\nWe'll use JSON as a data format for it is commonly used and supported across many programming languages, and is also relatively readable on itself. Portfolios should abide by the [JSON schema given in appendix](CIP-0017.json). \n\nAt minima, a portfolio should cover a list of delegation choices (pools and weights) and have a human-readable name for easier identification. \n\n### Weights\n\nFor each pool, we demand a `weight` which can capture a certain stake proportion within the portfolio. The value is an integer, and relative to other weights in the portfolio. For example, a portfolio with two pools and respective weights of `1` and `2` means that we expect users to assign twice more stake to the second pool than the first. Fundamentally, this means that for every 3 Ada, 1 Ada should go to the first pool, and 2 Ada should go to the second. Note that this is equivalent to having weights of `10`/`20` or `14` / `28`. Weights are ultimately interpreted as fractions.\n\nPortfolios which treat all stake pools equally should use the same weight (e.g. `1`) for each pool. \n\n### Example\n\n```json\n{ \"name\": \"Metal 🤘\"\n, \"description\": \"Pools supporting Metal music across the world.\"\n, \"pools\": \n  [ { \"id\": \"d59123f4dce7c62fa74bd37a759c7ba665dbabeb28f08b4e5d4802ca\"\n    , \"name\": \"Dark Tranquility\"\n    , \"ticker\": \"DARK\"\n    , \"weight\": 42\n    }\n  , { \"id\": \"5f3833027fe8c8d63bc5e75960d9a22df52e41bdf62af5b689663c50\"\n    , \"ticker\": \"NITRO\"\n    , \"weight\": 14\n    }\n  , { \"id\": \"a16abb03d87b86f30bb743aad2e2504b126286fe744d3d2f6a0b4aec\"\n    , \"name\": \"Loudness\"\n    , \"ticker\": \"LOUD\"\n    , \"weight\": 37\n    }\n  , { \"id\": \"9f9bdee3e053e3102815b778db5ef8d55393f7ae83b36f906f4c3a47\"\n    , \"weight\": 25\n    }\n  ]\n}\n```\n\n## Rationale: how does this CIP achieve its goals?\n\n1. JSON is widely used, widely supported and quite lightweight. Makes for a reasonable choice of data format.\n\n2. Using JSON schema for validation is quite common when dealing with JSON and it's usually sufficiently precise to enable good interoperability. \n\n3. The portfolio should only capture information that are not subject to radical change. That is, stake pools parameters like pledge or fees are excluded since they can be changed fairly easily using on-chain certificate updates. \n\n4. The JSON schema doesn't enforce any `additionalProperties: false` for neither the top-level object definition nor each stake pool objects. This allows for open extension of the objects with custom fields at the discretion of applications implementing this standard. The semantic of well-known properties specified in this document is however fixed.\n\n5. Since the portfolio format isn't _immediately user-facing_, we favor base16 over bech32 for the pool id's encoding for there's better support and tooling for the former.\n\n### Backwards Compatibility\n\n#### Adafolio\n\nThe format used by [Adafolio](https://adafolio.com) share a lot of similarities with the proposed format in this CIP. In order to power its frontend user interface, Adafolio contains however several fields which we consider _too volatile_ and unnecessary to the definition of a portfolio. This doesn't preclude the format used by Adafolio as a valid portfolio format (see also point (4). in the rationale above).\n\nThe only point of incompatibility regards the `pool_id` field (in Adafolio) vs the `id` field (in this proposal) which we deem more consistent with regards to other field. \n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] At least one pair of applications (wallets, explorers or other tools) together support the following:\n  - [ ] generation of the specified portfolio file format\n  - [ ] interpretation and use of the specified portfolio file format\n\n### Implementation Plan\n\n- [ ] Provide a reference implementation and/or parsing library to read and/or write files in this schema.\n\n# Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0018/CIP-0018.md",
    "content": "Moved to [CIP-0018/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0018/README.md",
    "content": "---\nCIP: 18\nTitle: Multi-Stake-Keys Wallets \nStatus: Proposed\nCategory: Wallets\nAuthors:\n  - Matthias Benkort <matthias.benkort@iohk.io>\nImplementors: []\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/83\nCreated: 2020-03-18\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis document describes how to evolve sequential wallets from Cardano to support multiple stake keys. This proposal is an extension of [CIP-1852] and [CIP-0011].\n\n## Motivation: why is this CIP necessary?\n\nCardano wallets originally approached stake delegation by considering a single stake key per wallet. While this was beneficial in terms of ease of implementation and simplicity of reasoning, this is unsuitable for many users with large stakes. Indeed, the inability to split out the stake into multiple pools often leads to over-saturation of existing pools in case of delegation. The only workaround so far requires users to split their funds into multiple accounts and manage them independently. This can be quite cumbersome for a sufficiently large number of accounts. \n\nEven for smaller actors, it can be interesting to delegate to multiple pools to limit risks. Pools may underperform or simply change their parameters from a day to another (for which wallets still do not warn users about). Delegating to more pools can reduce the impact of pool failure (for one or more epochs) or unattended changes in pool fees. It may as well be a matter of choice if users do want to delegate to several independent entities for various other reasons.\n\nAnother concern regards privacy leaks coming with the existing wallet scheme. Since the same stake key is associated with every single address of the wallet, it creates a kind of watermark that allows for tracing all funds belonging to the same wallet very easily (it suffices to look at the stake part of addresses). By allowing the wallet to hold multiple stake keys, rotating through them when creating changes does make the traceability a bit harder. One could imagine using a hundred stake keys delegated to the same pool.\n\n## Specification\n\n### Overview\n\nThe restriction from [CIP-0011] regarding the derivation index reserved for stake key is rendered obsolete by this specification. That is, one is allowed to derive indexes beyond the first one (index = 0) to effectively administrate multi-stake keys accounts. The creation of new stake keys is however tightly coupled to the registration of associated stake keys to allow wallet software to automatically discover stake keys on-chain. In this design, stake key indexes form **at all time a contiguous sequence with no gap**.\n\n### Key registration\n\nWe introduce the concept of _UTxO stake key pointer_ to reliably keep track of stake keys on the blockchain. The gist is to require that every key registration and/or deregistration consume and create a special UTxO which in itself is pointing to the next available stake key of the wallet. Such pointer allows piggybacking on the existing UTxO structure to cope with concurrency issues and rollbacks that are inherent to a distributed system such as Cardano. Plus, this mechanism only demands a low overhead for wallet software and may be recognized as a special spending pattern by hardware devices. \n\nIn more details, we require that beyond the first stake key (index = 0), all registrations must satisfy the following rules:\n\n1. Stake keys must be derived sequentially, from 0 and onwards.\n1. Every stake key registration must be accompanied by a matching delegation certificate. \n1. Every registration transaction must create a special output of exactly `minUTxOValue` Ada such that its address is an enterprise address with a single **payment part** using the stake key hash of the next available stake key of the wallet to be registered after processing the registration transaction. \n1. Unless no key beyond the first one is registered, every registration transaction must consume the special UTxO stake key pointer corresponding to the previous key registration (resp. de-registration) for that wallet.\n> **Note** The `minUTxOValue` is fixed by the protocol. It is defined as part of the Shelley genesis and can be updated via on-chain protocol updates. At the moment, this equals 1 Ada on the mainnet. \n\n#### Example\n\nFor example, a wallet that has already registered stake keys 0, 1 and 2 have a UTxO for which the payment part is a hash of the stake key at index=3. If the wallet wants to register two new stake keys at index 3 and 4, it'll do so in a single transaction, by consuming the pointer UTxO and by creating a new one for which the payment part would be a hash of the stake key at index=5. \n\nNote that this only requires two signatures from stake keys at indexes 3 and 4. \n\n### Key de-registration\n\nKey de-registrations work symmetrically and require that:\n\n1. Stake keys are de-registered sequentially, from the highest and downwards. \n1. Unless the first key of the wallet is being de-registered, every de-registration transaction must create a special output of exactly `minUtxOValue` Ada such that its address is an enterprise address with a single **payment part** using the stake key hash of the next stake key of the wallet after processing the de-registration transaction.\n1. Every de-registration must consume the special UTxO stake key pointer corresponding to the previous key de-registration (resp. registration) for that wallet. \n\n### Backwards Compatibility\n\nAs stated in the introduction, this proposal is built on top of [CIP-0011] such that backward compatibility is preserved when a single key is used. In fact, The management of the first stake key at index 0 remains unchanged and does not require any pointer. This preserves backward compatibility with the existing design for a single stake key wallet and offers a design that can be implemented on top, retro-actively. \n\nNevertheless, we do assume that existing wallets following [CIP-0011] are already fully capable of discovering addresses using stake keys not belonging to the wallet. Some may even report them as _mangled_.\n> **Note** An address is said _mangled_ when it has a stake part, and the stake part isn't recognized as belonging to its associated wallet. That is, the payment part and the stake part appear to come from two different sources. This could be the case if the address has been purposely constructed in such a way (because the stake rights and funds are managed by separate entities), or because the stake part refers to a key hash which is no longer known of the wallet (because the associated key registration was rolled back).\n\nAs a result, this extension would not incapacitate existing wallets since the payment ownership is left untouched. However, wallets not supporting the extension may display addresses delegated to keys beyond the first one as mangled and may also fail to report rewards correctly across multiple keys. \n\nWe deem this to be an acceptable and fairly minor consequence but encourage existing software to raise awareness about this behaviour.\n\n\n## Rationale: how does this CIP achieve its goals?\n\n- Carrying an extra UTxO pointer makes it possible to not worry (too much) about concurrency issues and problems coming with either, multiple instances of the wallet (like many users do between a mobile and desktop wallet) or the usual rollbacks which may otherwise create gaps in the indexes. By forcing all registration (resp. deregistration) transactions to be chained together, we also enforce that any rollbacks do maintain consistency of the index state: if any intermediate transaction is rolled back, then transactions they depend on are also rolled back. \n\n- The first registration induces an extra cost for the end-user for the wallet needs to create a new UTxO with a minimum value. That UTxO is however passed from registration to registration afterwards without any extra cost. It can also be fully refunded upon de-registering the last stake key. So in practice, it works very much like a key deposit. \n\n- We do not allow mixing up key registration and key deregistration as part of the same transaction for it makes the calculation of the pointer trickier for wallet processing transactions. A single transaction either move the pointer up or down. \n\n- There's in principle nothing preventing someone from sending money to the special key-registration tracking address. Wallets should however only keep track of UTxOs created as part of transactions that register stake keys (and have therefore been authorized by the wallet itself). Applications are however encouraged to collect any funds sent to them in an ad-hoc manner on such keys. \n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] There exists one or more reference implementations with appropriate testing illustrating the viability of this approach and specification.\n\n### Implementation Plan\n\n- [ ] Update this proposal to account for the Conway Ledger era, which brings new types of certificates for registering stake keys.\n\n- [ ] Develop the proposed Reference Implementation as suggested when this CIP was originally published (see Discussion link in header for history).\n- [ ] Contact wallet and dApp representatives in the community to develop and maintain interest in their support for this specification.\n\n# Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[CIP-1852]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852\n[CIP-0011]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0011\n"
  },
  {
    "path": "CIP-0019/CIP-0019-byron-addresses.cddl",
    "content": "BYRON_ADDRESS =\n    ( #6.24(<<BYRON_ADDRESS_PAYLOAD>>)\n    , uint32 ; crc32 of the CBOR serialized address payload\n    )\n\nBYRON_ADDRESS_PAYLOAD =\n    ( bytes .size 28            ; blake2b_224(sha3_256(BYRON_ADDRESS_ROOT)) digest\n    , BYRON_ADDRESS_ATTRIBUTES\n    , BYRON_ADDRESS_TYPE\n    )\n\nBYRON_ADDRESS_ROOT =\n    ( BYRON_ADDRESS_TYPE\n    , BYRON_ADDRESS_SPENDING_DATA\n    , BYRON_ADDRESS_ATTRIBUTES\n    )\n\nBYRON_ADDRESS_TYPE =\n       0  ; Public key\n    // 2  ; Redemption\n\nBYRON_ADDRESS_SPENDING_DATA =\n    ( 0, bytes .size 64 ) ; Ed25519 Public key | Associated BIP-32 chain code\n    //\n    ( 2, bytes .size 32 ) ; Ed25519 Public key\n\nBYRON_ADDRESS_ATTRIBUTES =\n    { 1 : <<bytes .cbor BYRON_DERIVATION_PATH_CIPHERTEXT>>  ; Double CBOR-encoded ChaCha20/Poly1305 encrypted digest, see CIP for details.\n    , 2 : <<uint32>>                             ; CBOR-encoded network discriminant\n    }\n\nBYRON_DERIVATION_PATH_CIPHERTEXT = ; Obtained by encrypting a serialized derivation path\n    bytes .size 28\n\nBYRON_DERIVATION_PATH =\n    [ * uint32 ]\n"
  },
  {
    "path": "CIP-0019/CIP-0019-cardano-addresses.abnf",
    "content": "ADDRESS = %b0000 | NETWORK-TAG | KEY-HASH    | KEY-HASH       ; type 00, Base Shelley address\n        \\ %b0001 | NETWORK-TAG | SCRIPT-HASH | KEY-HASH       ; type 01, Base Shelley address\n        \\ %b0010 | NETWORK-TAG | KEY-HASH    | SCRIPT-HASH    ; type 02, Base Shelley address\n        \\ %b0011 | NETWORK-TAG | SCRIPT-HASH | SCRIPT-HASH    ; type 03, Base Shelley address\n        \\ %b0100 | NETWORK-TAG | KEY-HASH    | POINTER        ; type 04, Pointer Shelley address deprecated in Conway\n        \\ %b0101 | NETWORK-TAG | SCRIPT-HASH | POINTER        ; type 05, Pointer Shelley address deprecated in Conway\n        \\ %b0110 | NETWORK-TAG | KEY-HASH                     ; type 06, Payment Shelley address\n        \\ %b0111 | NETWORK-TAG | SCRIPT-HASH                  ; type 07, Payment Shelley address\n        \\ %b1000 | BYRON-PAYLOAD                              ; type 08, Byron / Bootstrap address\n        \\ %b1110 | NETWORK-TAG | KEY-HASH                     ; type 14, Stake Shelley address\n        \\ %b1111 | NETWORK-TAG | SCRIPT-HASH                  ; type 15, Stake Shelley address\n\nNETWORK-TAG  = %b0000 ; Testnet\n             \\ %b0001 ; Mainnet\n\nPOINTER = VARIABLE-LENGTH-UINT ; slot number\n        | VARIABLE-LENGTH-UINT ; transaction index\n        | VARIABLE-LENGTH-UINT ; certificate index\n\nVARIABLE-LENGTH-UINT = (%b1 | UINT7 | VARIABLE-LENGTH-UINT)\n                     / (%b0 | UINT7)\nUINT7 = 7BIT\n\nKEY-HASH = 28OCTET\n\nSCRIPT-HASH= 28OCTET\n\nBYRON-PAYLOAD = *OCTET ; see 'Byron Addresses' section or cddl specification.\n"
  },
  {
    "path": "CIP-0019/CIP-0019.md",
    "content": "Moved to [CIP-0019/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0019/README.md",
    "content": "---\nCIP: 19\nTitle: Cardano Addresses\nStatus: Active\nCategory: Ledger\nAuthors:\n  - Matthias Benkort <matthias.benkort@cardanofoundation.org>\nImplementors: N/A\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/78\nCreated: 2020-03-25\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis specification describes the structure of addresses in Cardano, covering both addresses introduced in the Shelley era and the legacy format from the Byron era.\n\n## Motivation: why is this CIP necessary?\n\nDocument design choices for posterity. Most applications interacting with the Cardano blockchain will likely not have any need for this level of details, however, some might. This CIP is meant to capture this knowledge. \n\n## Specification\n\n### Introduction\n\nIn Cardano, an address is a **sequence of bytes** that conforms to a particular format, which we describe below.\n\nHowever, users will typically come into contact with addresses only after these addresses have been **encoded** into sequences of human-readable characters. In Cardano, the [Bech32][] and [Base58][] encodings are used to encode addresses, as opposed to standard hexadecimal notation (Base16, example `0x8A7B`). These encoded sequence of characters have to be distinguished from the byte sequences that they encode, but lay users will (and should) perceive the encoded form as \"the\" address.\n\n### User-facing Encoding\n\nBy convention, **Shelley** and stake addresses are encoded using **[Bech32][]**, with the exception that Cardano does not impose a length limit on the sequence of characters. The human-readable prefixes are defined in [CIP-0005][]; the most common prefix is `addr`, representing an address on mainnet. Bech32 is the preferred encoding, as its built-in error detection may protect users against accidental misspellings or truncations.\n\nAgain by convention, **Byron** addresses are encoded in **[Base58][]**.\n\nHistorically, Byron addresses were introduced before the design of Bech32, which solves various issues of the Base58 encoding format (see [Bech32's motivation](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#motivation) for more detail). Byron addresses were however kept as Base58 to easily distinguish them from new addresses introduced in Shelley, massively making use of Bech32 for encoding small binary objects.\n\nCave: In principle, it is possible for a Shelley address to be encoded in Base58 and a Byron address to be encoded in Bech32 (without length limit). However, implementations are encouraged to reject addresses that were encoded against convention, as this helps with the goal that lay users only encounter a single, canonical version of every address.\n\nExamples of different addresses encoded in different eras:\n\n| Address Type | Encoding | Example                                                                                                              |\n| ---          | ---      | ---                                                                                                                  |\n| Byron        | Base58   | `37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na` |\n| Shelley      | bech32   | `addr1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0yu80w`                                                         |\n| stake        | bech32   | `stake1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5egfu2p0u`                                                        |\n\n### Binary format\n\nIn Cardano, the sequence of bytes (after decoding with Bech32 or Base58) that represents an address  comprises two parts, a one-byte **header** and a **payload** of several bytes. Depending on the header, the interpretation and length of the payload varies. \n\nIn the header-byte, bits [7;4] indicate the type of addresses being used; we'll call these four bits the **header type**. The remaining four bits [3;0] are either unused or refer to what we'll call the **network tag**. There are currently 11 types of addresses in Cardano which we'll divide into three categories: [Shelley addresses], [stake addresses], and [Byron addresses]. \n\n```\n  1 byte     variable length   \n <------> <-------------------> \n┌────────┬─────────────────────┐\n│ header │        payload      │\n└────────┴─────────────────────┘\n    🔎                          \n    ╎          7 6 5 4 3 2 1 0  \n    ╎         ┌─┬─┬─┬─┬─┬─┬─┬─┐ \n    ╰╌╌╌╌╌╌╌╌ │t│t│t│t│n│n│n│n│ \n              └─┴─┴─┴─┴─┴─┴─┴─┘ \n```\n\nSee also the more detailed [ABNF grammar in annex].\n\n#### Network Tag\n\nExcept for [Byron addresses] (type 8 = `1000`), the second half of the header (bits [3;0]) refers to the network tag which can have the following values and semantics. Other values of the network tag are currently reserved for future network types. In the case of [Byron addresses], bits [3;0] have a completely separate definition detailed in the section below.\n\nNetwork Tag (`. . . . n n n n`)   | Semantic\n---                               | ---\n`....0000`                        | Testnet(s) \n`....0001`                        | Mainnet\n\n\n#### Shelley Addresses \n\nThere are currently 8 types of Shelley addresses summarized in the table below:\n\nHeader type (`t t t t . . . .`) | Payment Part     | Delegation Part\n---                             | ---              | ---\n(0) `0000....`                  | `PaymentKeyHash` | `StakeKeyHash`\n(1) `0001....`                  | `ScriptHash`     | `StakeKeyHash`\n(2) `0010....`                  | `PaymentKeyHash` | `ScriptHash`\n(3) `0011....`                  | `ScriptHash`     | `ScriptHash`\n(4) `0100....`                  | `PaymentKeyHash` | `Pointer`\n(5) `0101....`                  | `ScriptHash`     | `Pointer`\n(6) `0110....`                  | `PaymentKeyHash` | ø\n(7) `0111....`                  | `ScriptHash`     | ø\n\n- `PaymentKeyHash` and `StakeKeyHash` refer to `blake2b-224` hash digests of Ed25519 verification keys. How keys are obtained is out of the scope of this specification. Interested readers may look at [CIP-1852] for more details.\n\n- `ScriptHash` refer to `blake2b-224` hash digests of serialized monetary scripts. How scripts are constructed and serialized is out of the scope of this specification.\n\n- `Pointer` is detailed in the section below.\n\n##### Payment part\n\nFundamentally, the first part of a Shelley address indicates the ownership of the funds associated with the address. We call it the **payment part**. Whoever owns the payment parts owns any funds at the address. As a matter of fact, in order to spend from an address, one must provide a witness attesting that the address can be spent. In the case of a `PaymentKeyHash`, it means providing a signature of the transaction body made with the signing key corresponding to the hashed public key (as well as the public key itself for verification). For monetary scripts, it means being able to provide the source script and meet the necessary conditions to validate the script. \n\n##### Delegation part\n\nThe second part of a Shelley address indicates the owner of the stake rights associated with the address. We call it the **delegation part**. Whoever owns the delegation parts owns the stake rights of any funds associated with the address. In most scenarios, the payment part and the delegation part are owned by the same party. Yet it is possible to construct addresses where both parts are owned and managed by separate entities. We call such addresses **mangled addresses** or **hybrid addresses**. \n\nSome addresses (types 6 and 7) carry no delegation part whatsoever. Their associated stake can't be delegated. They can be used by parties who want to prove that they are not delegating funds which is typically the case for custodial businesses managing funds on the behalf of other stakeholders. Delegation parts can also be defined in terms of on-chain [pointers]. \n\n##### Pointers\n\n> **Note**\n> From the Conway ledger era, new pointer addresses cannot be added to Mainnet.\n\nIn an address, a **chain pointer** refers to a point of the chain containing a stake key registration certificate. A point is identified by 3 coordinates:\n\n- An absolute slot number \n- A transaction index (within that slot)\n- A (delegation) certificate index (within that transaction)\n\nThese coordinates form a concise way of referring to a stake key (typically half the size of a stake key hash). They are serialized as three variable-length positive numbers following the ABNF grammar here below:\n\n```abnf\nPOINTER = VARIABLE-LENGTH-UINT ; slot number\n        | VARIABLE-LENGTH-UINT ; transaction index\n        | VARIABLE-LENGTH-UINT ; certificate index\n\nVARIABLE-LENGTH-UINT = (%b1 | UINT7 | VARIABLE-LENGTH-UINT) \n                     / (%b0 | UINT7)\n\nUINT7 = 7BIT \n```\n\n#### Stake Addresses\n\nLike [Shelley addresses], stake addresses (also known as **reward addresses**) start with a single header byte identifying their type and the network, followed by 28 bytes of payload identifying either a stake key hash or a script hash. \n\nHeader type (`t t t t . . . .`) | Stake Reference\n---                             | ---\n(14) `1110....`                  | `StakeKeyHash`\n(15) `1111....`                  | `ScriptHash`\n\n- `StakeKeyHash` refers to `blake2b-224` hash digests of Ed25519 verification keys. How keys are obtained is out of the scope of this specification. Interested readers may look at [CIP-1852] for more details.\n\n- `ScriptHash` refers to `blake2b-224` hash digests of serialized monetary scripts. How scripts are constructed and serialized is out of the scope of this specification.\n\n#### Byron Addresses\n\nBefore diving in, please acknowledge that a lot of the supported capabilities of Byron addresses have remained largely unused. The initial design showed important trade-offs and rendered it unpractical to sustain the long-term goals of the network. A new format was created when introducing Shelley and Byron addresses were kept only for backward compatibility. Byron addresses are also sometimes called **bootstrap addresses**.\n\n\nLike many other objects on the Cardano blockchain yet unlike Shelley addresses, Byron addresses are [CBOR]-encoded binary objects. Conveniently enough, the first 4 bits of their first byte are always equal to `1000....` which allows us to land back on our feet w.r.t to the address type. Their internal structure is however vastly different and a bit unusual. \n\n```\n┌────────┬──────────────┬────────┐\n│  root  │  attributes  │  type  │\n└────────┴──────────────┴────────┘\n  ╎        ╎              ╎ \n  ╎        ╎              ╰╌╌ Standard   \n  ╎        ╎              ╰╌╌ Redeem\n  ╎        ╎ \n  ╎        ╰╌╌ Derivation Path\n  ╎        ╰╌╌ Network Tag    \n  ╎\n  ╎                   ┌────────┬─────────────────┬──────────────┐\n  ╰╌╌╌╌ double-hash ( │  type  │  spending data  │  attributes  │ )\n                      └────────┴─────────────────┴──────────────┘\n                                 ╎        \n                                 ╰╌╌ Verification Key\n                                 ╰╌╌ Redemption Key\n```\n\nThe address `root` uniquely identifies the address and is a double-hash digest (SHA3-256, and then Blake2b-224) of the address type, spending data, and attributes. \n\nThen comes the address attributes which are both optional. The network tag is present only on test networks and contains an identifier that is used for network discrimination. The [derivation path] (detailed below) was used by legacy so-called random wallets in the early days of Cardano and its usage was abandoned with the introduction of Yoroi and so-called **Icarus addresses**. \n\nFinally, the address type allows for distinguishing different sub-types of Byron addresses. **Redeem addresses** are used inside the Byron genesis configuration and were given to early investors who helped to fund the project. \n\nA full and more detailed [CDDL specification of Byron addresses] is given in the annex to the CIP. \n\n##### Derivation path \n\nHistorically, Cardano wallets have been storing information about the wallet structure directly within the address. This information comes in the form of two derivation indexes (in the sense of child key derivation as defined in [BIP-0032]) which we call **derivation path**. To protect the wallet's anonymity, the derivation path is stored encrypted using a ChaCha20/Poly1305 authenticated cipher. \n\n### Test Vectors\n\nAll test vectors below use the following payment key, stake key, script and pointer:\n\n- `addr_vk1w0l2sr2zgfm26ztc6nl9xy8ghsk5sh6ldwemlpmp9xylzy4dtf7st80zhd`\n- `stake_vk1px4j0r2fk7ux5p23shz8f3y5y2qam7s954rgf3lg5merqcj6aetsft99wu`\n- `script1cda3khwqv60360rp5m7akt50m6ttapacs8rqhn5w342z7r35m37`\n- `(2498243, 27, 3)`\n\n```yaml\nmainnet:\n    type-00: addr1qx2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer3n0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgse35a3x\n    type-01: addr1z8phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gten0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgs9yc0hh\n    type-02: addr1yx2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzerkr0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shs2z78ve\n    type-03: addr1x8phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gt7r0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shskhj42g\n    type-04: addr1gx2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer5pnz75xxcrzqf96k\n    type-05: addr128phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtupnz75xxcrtw79hu\n    type-06: addr1vx2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzers66hrl8\n    type-07: addr1w8phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtcyjy7wx\n    type-14: stake1uyehkck0lajq8gr28t9uxnuvgcqrc6070x3k9r8048z8y5gh6ffgw\n    type-15: stake178phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtcccycj5\n\ntestnet:\n    type-00: addr_test1qz2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer3n0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgs68faae\n    type-01: addr_test1zrphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gten0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgsxj90mg\n    type-02: addr_test1yz2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzerkr0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shsf5r8qx\n    type-03: addr_test1xrphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gt7r0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shs4p04xh\n    type-04: addr_test1gz2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer5pnz75xxcrdw5vky\n    type-05: addr_test12rphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtupnz75xxcryqrvmw\n    type-06: addr_test1vz2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzerspjrlsz\n    type-07: addr_test1wrphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtcl6szpr\n    type-14: stake_test1uqehkck0lajq8gr28t9uxnuvgcqrc6070x3k9r8048z8y5gssrtvn\n    type-15: stake_test17rphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtcljw6kf\n```\n## Rationale: how does this CIP achieve its goals?\n\nAs stated in [Motivation](#motivation-why-is-this-cip-necessary) this CIP is provided for informational purposes regarding a single deliberate design. Further rationale and motivation for this design are available in the [Design Specification for Delegation and Incentives in Cardano - Section 3.2 :: Addresses & Credentials ](https://github.com/intersectmbo/cardano-ledger/releases/latest/download/shelley-delegation.pdf).\n\n### Reference Implementation(s)\n\n- [IntersectMBO/cardano-addresses (Byron & Shelley)](https://github.com/IntersectMBO/cardano-addresses)\n\n- [IntersectMBO/cardano-ledger-specs (Byron)](https://github.com/IntersectMBO/cardano-ledger-specs/blob/d5eaac6c4b21a8e69dc3a5503a72e3c3bfde648e/byron/ledger/impl/src/Cardano/Chain/Common/Address.hs)\n\n- [IntersectMBO/cardano-ledger-specs (Shelley)](https://github.com/IntersectMBO/cardano-ledger-specs/blob/1e7e6e03a46e8118b318ed105214767aec0f3976/shelley/chain-and-ledger/executable-spec/src/Shelley/Spec/Ledger/Address.hs)\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Confirmation by consensus, with no reported dispute since publication, that this document fully descibes how Cardano addresses are universally implemented.\n\n### Implementation Plan\n\n- [x] Publish this documentation for confirmation that it accurately describes conventionals of universal use.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[ABNF grammar in annex]: https://raw.githubusercontent.com/cardano-foundation/CIPs/master/CIP-0019/CIP-0019-cardano-addresses.abnf\n[base58]: https://tools.ietf.org/id/draft-msporny-base58-01.html\n[bech32]: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki\n[BIP-0032]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki\n[Byron addresses]: #byron-addresses\n[CBOR]: https://www.rfc-editor.org/rfc/rfc8949\n[CDDL specification of Byron addresses]: https://raw.githubusercontent.com/cardano-foundation/CIPs/master/CIP-0019/CIP-0019-byron-addresses.cddl\n[CIP-0005]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005\n[CIP-1852]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852\n[derivation path]: #derivation-path\n[pointers]: #pointers\n[Shelley addresses]: #shelley-addresses\n[Stake addresses]: #stake-addresses\n"
  },
  {
    "path": "CIP-0020/CIP-0020.md",
    "content": "Moved to [CIP-0020/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0020/README.md",
    "content": "---\nCIP: 20\nTitle: Transaction message/comment metadata\nStatus: Active\nCategory: Metadata\nAuthors:\n    - Martin Lang <martin@martinlang.at>\n    - Ola Ahlman <ola@ahlnet.nu>\n    - Andrew Westberg <andrewwestberg@gmail.com>\nImplementors:\n    - CNTools <https://cardano-community.github.io/guild-operators/#/Scripts/cntools>\n    - JorManager <https://bitbucket.org/muamw10/jormanager/>\n    - StakePoolOperator Scripts <https://github.com/gitmachtl/scripts>\n    - Cardanoscan.io <https://cardanoscan.io>\n    - AdaStat.net <https://adastat.net>\n    - Eternl Wallet <https://eternl.io>\n    - CardanoWall <https://cardanowall.com>\n    - Nami Wallet <https://namiwallet.io>\n    - CNFT <https://cnft.io>\n    - Cardano Explorer <https://cexplorer.io>\n    - SundaeSwap <https://https://sundaeswap.finance/>\n    - Minswap <https://minswap.org/>\n    - MuesliSwap <https://muesliswap.com/>\n    - DripDropz.io <https://dripdropz.io/>\n    - Typhon Wallet <https://typhonwallet.io/>\n    - Ledger Live <https://www.ledger.com/>\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/100\n    - https://github.com/cardano-foundation/CIPs/pull/394\nCreated: 2021-06-13\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis describes a basic JSON schema to add messages/comments/memos as transaction metadata by using the metadatum label **674**:\nallowing informational, commerical, or any other text to be included in a transaction on the Cardano blockchain.\n\n## Motivation: why is this CIP necessary?\n\nWe have the utilities on the cardano blockchain now since the introduction of the \"allegra-era\". A simple consens about adding messages, comments or memos to transactions is still missing.\nSo the CIP authors came together to form a first implementation of this. It is straight and simple, additional keys and content can be added later.\nThe IOG main wallet `Daedalus` can now also directly show attached metadata information in the transaction details view. This CIP is the missing link to bring it together.\n\nSome of the current Tools/Sites/Explorers that have implemented it already:\n* [CNTools](https://cardano-community.github.io/guild-operators/#/Scripts/cntools)\n* [JorManager](https://bitbucket.org/muamw10/jormanager/)\n* [StakePoolOperator Scripts](https://github.com/gitmachtl/scripts)\n* [Cardanoscan.io](https://cardanoscan.io)\n* [AdaStat.net](https://adastat.net)\n* [Eternl Wallet](https://eternl.io)\n* [CardanoWall](https://cardanowall.com)\n* [Nami Wallet](https://namiwallet.io)\n* [CNFT](https://cnft.io)\n* [Cardano Explorer](https://cexplorer.io)\n* [SundaeSwap](https://https://sundaeswap.finance/)\n* [Minswap](https://minswap.org/)\n* [MuesliSwap](https://muesliswap.com/)\n* [DripDropz.io](https://dripdropz.io/)\n* [Typhon Wallet](https://typhonwallet.io/)\n* [Ledger Live](https://www.ledger.com/)\n\n## Specification\n\nThe specification for the individual strings follow the general design specification for JSON metadata, which is already implemented and in operation on the cardano blockchain.\nThe used metadatum label is **`\"674\":`**, this number was choosen because it is the T9 encoding of the string \"msg\".\nThe message content has the key **`\"msg\":`** and consists of an **array** of individual **message-strings**.\nThe number of theses **message-strings** must be at least one for a single message, more for multiple messages/lines. Each of theses individual **message-strings** array entries must be at most 64 bytes when UTF-8 encoded.\n\n### Format:\n```\n{\n  \"674\":\n         {\n           \"msg\":\n                  [\n                    \"message-string 1\" //Optional: ,\"message-string 2\",\"message-string 3\" ...\n                  ]\n         }\n}\n```\n\n### Example for a single message/comment/memo:\n``` json\n{\n  \"674\":\n         {\n           \"msg\":\n                  [\n                    \"This is a comment for the transaction xyz, thank you very much!\"\n                  ]\n         }\n}\n```\n\n### Example for multiple messages/comments/memos:\n``` json\n{\n  \"674\":\n         {\n           \"msg\":\n                  [\n                    \"Invoice-No: 1234567890\",\n                    \"Customer-No: 555-1234\",\n                    \"P.S.: i will shop again at your store :-)\"\n                  ]\n         }\n}\n```\n\n&nbsp;<p>\n\n### Some Integration examples\n\n**Ledger Live** is offering a memo field\n![image](https://user-images.githubusercontent.com/47434720/204649383-c34ae733-e136-41b8-8fa8-619dde978621.png)\n\n**Daedalus** shows the metadata text (could be improved if CIP is implemented):\n![image](https://user-images.githubusercontent.com/47434720/121822100-85b38a80-cc9d-11eb-9d13-1869746a69b2.png)\n\n**Cardanoscan.io**, **Adastat.net** and other tools implemented it already, to show messages along transactions:\n![image](https://user-images.githubusercontent.com/47434720/204633595-d865c7ee-0c30-4af1-bb55-3c0ad323b58c.png)\n![image](https://user-images.githubusercontent.com/47434720/204634111-256c6c18-974a-41f5-a6e4-b9edee8f9d62.png)\n\n**eternl.io** has added it with a message field on the sending-page, and shows it also on the transactions-page:\n![image](https://user-images.githubusercontent.com/47434720/204632224-5be33098-00f6-41da-a2f0-7c138b28354f.png)\n![image](https://user-images.githubusercontent.com/47434720/204632802-33f1afa5-d9b2-494f-84fe-d7f0594a7f1b.png)\n\n**StakePool Operator Scripts**: It works on the commandline like any other script of the collection by just adding the \"msg: ...\" parameter to a transaction. This automatically generates the needed metadata.json structure and attaches it to the transaction itself.\n![image](https://user-images.githubusercontent.com/47434720/129110626-6bc5b3c3-102d-4793-b508-7d4190b31cf7.png)\n\n**CNTools**:<br>\n![image](https://user-images.githubusercontent.com/47434720/130353491-fc0f3a69-1937-4e72-b680-c04cc069b5c4.png)\n\n## Rationale: how does this CIP achieve its goals?\n\nThis design is simple, so many tools on the cardano blockchain can implement it easily. The array type was choosen to have consistency, no need to switch between a string or\nan array format, or testing against a string or array format. Updates in the future are possible, like adding a versioning key `\"ver\":`, adding a key `\"utxo\":` to provide specific data for every tx-out#idx in the transaction, adding the `\"enc\":` key like for encrypted messages, making subarrays in the message-strings, etc. But for now, we need a common agreement to provide general messages/comments/memos with this CIP. The starting design war choosen as simple as possible to keep the additional transaction fees as low as possible.\n\n### Wallet Implementation\n\nWould be a good idea to hide the message/comment/note behind a \"show unmoderated content\" button/drop-down. Like the Metadata display on the Cardano Explorer. Also, it should be displayed as plain-text non-clickable. To enhance security further, URLs could be automatically deleted or hidden from such comments, to not welcome bad actors with phishing attempts. Another solution to start with would be to really limit the character space for display in Wallets, like limiting it to `a-zA-z0-9` and a handful of special chars like `+-_#()[]:` without a `.<>\"/\\` chars, so a domain or html code would not work. Last points are worth for discussions of course, because it would also filter out unicode.\n\n### Handling ill-formed 674 metadata\n\nIt is up to the wallet-/display-/receiver-implementor to parse and check the provided metadata. As for the current state, its not possible to have the same label \"674\" more than once in a cardano transaction. So a check about that can be ignored at the moment. This CIP provides the correct implementation format, the parsing should search for the \"674\" metadata label and the \"msg\" key underneath it. There should also be a check, that the provided data within that \"msg\" key is an array. All other implementations like a missing \"msg\" key, or a single string instead of an array, should be marked by the display-implementor as \"invalid\". Additional keys within the \"674\" label should not affect the parsing of the \"msg\" key. As written above, we will likely see more entries here in the future like a \"version\" key for example, so additional keys should not harm the parsing of the \"msg\" key.\n\n### Implementation conclusion\n\nA transaction message should be considered valid if the following apply:\n\n* Label = 674.\n* has property \"msg\".\n* msg property contains an array of strings, even for a single-line message.\n* Each line has a maximum length of 64 characters.\n* If there are additional properties, they don't invalidate the message. They can just be ignored.\n\nIf any of the above is not met, ignore the metadata as a transaction message. Can still be displayed as general metadata to the transaction.\n\n_Optional to consider for the implementer:_\n\n* For message creation both single-line and multi-line input should be considered valid. The wallet/tool isn't required to support multi-line input.\n* Message display in explorers/wallets should however preferably support multi-line messages even if it only supports single-line on creation. Not a requirement but should at least indicate that there are more data if only the first line is displayed. Maybe a link to explorer etc in the case it's not possible to solve in UI in a good way.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] There exist a variety of wallet-based, dApp, and CLI implementations of this standard, developed by a a wide variety of providers, and is in regular use.\n\n### Implementation Plan\n\nAs per the first two Discussion links:\n- [x] The format in this CIP has been the ground base for supporting transaction messages / comments / memos.\n- [x] The format and its interpretation have been considered and implemented by both creator/sender implementations and wallet/receiver/display implementations.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n"
  },
  {
    "path": "CIP-0021/CIP-0021.md",
    "content": "Moved to [CIP-0021/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0021/README.md",
    "content": "---\nCIP: 21\nTitle: Transaction requirements for interoperability with hardware wallets\nStatus: Active\nCategory: Wallets\nAuthors:\n  - Gabriel Kerekes <gabriel.kerekes@vacuumlabs.com>\n  - Rafael Korbas <rafael.korbas@vacuumlabs.com>\n  - Jan Mazak <jan.mazak@vacuumlabs.com>\nImplementors: N/A\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/107\nCreated: 2021-06-15\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP describes all the restrictions applicable to Cardano transactions which need to be signed by hardware wallets.\n\n## Motivation: why is this CIP necessary?\n\nDue to certain limitations of hardware (abbrev. HW) wallets, especially very small memory and a limited set of data types supported by Ledger, HW wallets are not able to process all valid transactions which are supported by Cardano nodes.\n\nThe limitations also result in an inability of HW wallets to see the whole transaction at once. Transaction data are streamed into HW wallets in small chunks and they compute a rolling hash of the transaction body which is signed at the end. Consequently, a HW wallet only provides witness signatures, and the transaction body which was signed has to be reconstructed by the client. We thus need a common transaction serialization format which will allow no ambiguity. In addition, the format must define ordering of map keys in such a way that it’s possible to check for duplicate keys by HW wallets.\n\nSeveral of the restrictions also stem from security or UX concerns, e.g. the forbidden combination of pool registration certificates and withdrawals in a single transaction (see reasoning below).\n\nTo ensure interoperability, SW wallets and other tools working with HW wallets should only use transactions which conform to the following rules.\n\n## Specification\n\nCertain transaction elements, described as allowed in this document, might not be supported by some HW wallets. Support also depends on HW wallet firmware or app versions. If transaction signing fails for a transaction which is built according to this specification, make sure to check the documentation of the HW wallet you are using.\n\n> **Note:** It might take some time for recent Cardano ledger spec changes to be implemented for HW wallets. Thus it might happen that further restrictions might apply on top of the restrictions mentioned in this CIP until the changes are implemented on HW wallets.\n\n### Canonical CBOR serialization format\n\nTransactions must be serialized in line with suggestions from [Section 3.9 of CBOR specification RFC](https://datatracker.ietf.org/doc/html/rfc7049#section-3.9). In particular:\n\n- Integers must be as small as possible.\n- The expression of lengths in major types 2 through 5 must be as short as possible.\n- The keys in every map must be sorted from lowest value to highest.\n- Indefinite-length items must be made into definite-length items.\n\nSee the RFC for details.\n\n### Tags in sets\n\nConway introduced optional 258 tags in certain items that are considered sets semantically but encoded as arrays in CBOR. HW wallets will support this optional encoding, but it must be consistent across the transaction: either there are no tags 258 in sets, or there are such tags everywhere (as described in the CDDL specification).\n\n### Transaction body\n\n#### Unsupported entries\n\nThe following transaction body entries must not be included:\n* `6 : update`\n* `20 : proposal procedures`\n\n#### Integers\n\nHW wallets support at most `int64` for signed integers and `uint64` for unsigned integers i.e. larger integers are not supported overall. Additionally, any integer value must fit in the appropriate type.\n\n#### Numbers of transaction elements\n\nThe number of the following transaction elements individually must not exceed `UINT16_MAX`, i.e. 65535:\n\n- inputs in transaction body\n- outputs in transaction body\n- asset groups (policy IDs) in an output or in the mint field\n- tokens (asset names) in an asset group\n- certificates in transaction body\n- pool owners in a pool registration certificate\n- pool relays in a pool registration certificate\n- withdrawals in transaction body\n- collateral inputs in transaction body\n- required signers in transaction body\n- reference inputs in transaction body\n- the total number of witnesses\n\nFor voting procedures, it is only allowed to include a single voter with a single voting procedure.\n\n#### Optional empty lists and maps\n\nUnless mentioned otherwise in this CIP, optional empty lists and maps must not be included as part of the transaction body or its elements.\n\nSince Conway, the [CDDL specification](https://github.com/intersectmbo/cardano-ledger/tree/master/eras/conway/impl/cddl-files) is stricter, so many arrays are now treated as non-empty sets, and some maps are required to be non-empty. HW wallets enforce this in many cases.\n\n#### Outputs\n\nA new, \"post Alonzo\", output format has been introduced in the Babbage ledger era which uses a map instead of an array to store the output data. For now, both the \"legacy\" (array) and \"post Alonzo\" (map) output formats are supported by HW wallets but we encourage everyone to migrate to the \"post Alonzo\" format as support for the \"legacy\" output format might be removed in the future. Both formats can be mixed within a single transaction, both in outputs and in the collateral return output.\n\n##### Legacy outputs\n\nOutputs containing no multi-asset tokens must be serialized as a simple tuple, i.e. `[address, coin, ?datum_hash]` instead of `[address, [coin, {}], ?datum_hash]`.\n\n##### Post Alonzo outputs\n\nIf the `data` of `datum_option` is included in an output, it must not be empty. `script_ref` (reference script) must also not be empty if it is included in an output.\n\n#### Multiassets\n\nSince multiassets (`policy_id` and `asset_name`) are represented as maps, both need to be sorted in accordance with the specified canonical CBOR format. Also, an output or the mint field must not contain duplicate `policy_id`s and a policy must not contain duplicate `asset_name`s.\n\n#### Certificates\n\nCertificates of the following types are not supported and must not be included:\n* `genesis_key_delegation`\n* `move_instantaneous_rewards_cert`\n* `stake_vote_deleg_cert`\n* `stake_reg_deleg_cert`\n* `vote_reg_deleg_cert`\n* `stake_vote_reg_deleg_cert`\n\nIf a transaction contains a pool registration certificate, then it must not contain:\n\n- any other certificate;\n- any withdrawal;\n- mint entry;\n- any output containing datum, datum hash or reference script;\n- script data hash;\n- any collateral input;\n- any required signer;\n- collateral return output;\n- total collateral;\n- reference inputs;\n- voting procedures;\n- treasury value;\n- donation value.\n\nIt is allowed to arbitrarily combine other supported certificate types.\n\n#### Withdrawals\n\nSince withdrawals are represented as a map of reward accounts, withdrawals also need to be sorted in accordance with the specified canonical CBOR format. A transaction must not contain duplicate withdrawals.\n\n#### Auxiliary data\n\nHW wallets do not serialize auxiliary data because of their complex structure. They only include the given auxiliary data hash in the transaction body. The only exception is Catalyst voting registration because it requires a signature computed by the HW wallet.\n\nIn this exceptional case, auxiliary data must be encoded in their \"tuple\" format:\n\n```\n[ transaction_metadata: { * transaction_metadatum_label => transaction_metadatum }, auxiliary_scripts: [ * native_script ]]\n```\n\nThe `auxiliary_scripts` must be an array of length 0.\n\n## Rationale: how does this CIP achieve its goals?\n\n### Canonical CBOR serialization format\n\nAs HW wallets don't return the whole serialized transaction, a common CBOR serialization is needed so that software wallets and other tools interacting with HW wallets are be able to deterministically reproduce the transaction body built and signed by the HW wallet.\n\nThe specified canonical CBOR format is consistent with how certain other data are serialized (e.g. Plutus script data in Alonzo) and allows the use of standard CBOR libraries out of the box.\n\n### Transaction body\n\n#### Credentials\n\nGenerally, HW wallets require that any key hash credential (and withdrawal address too) is given by the derivation path of the key (otherwise the user will not be aware that the key belongs to his wallet). This does not apply to Plutus transactions where HW wallets instead aim for maximum flexibility at the cost of users being potentially misled. (It is very hard to foresee how Plutus script authors would use various transaction elements and any restriction applied by HW wallets might break a use case which is otherwise perfectly sound and safe.)\n\nWhen signing a transaction, Ledger and Trezor use a _transaction signing mode_ that describes upfront what the intent is\n(the software wallet is responsible for choosing an appropriate mode). The transaction is then validated according to the mode.\nThere are, in principle, four options:\n* _Stake pool registration transaction_. Stake pool registration certificates are signed on their own, the transaction should contain nothing that is not necessary.\n* _Ordinary transaction_. Credentials must be given as key paths.\n* _Multisig transaction_. Credentials must be script hashes; only [multisig keys](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1854/README.md) are allowed.\n* _Plutus transaction_. The only mode that allows elements related to running Plutus scripts (script data hash etc.). No extra restrictions on transaction elements or their combinations. The drawback is that more is shown to the user (e.g. witnesses are not hidden as in ordinary transactions). Please only use this mode if no other mode is sufficient.\n\nThis brief description does not aim to capture the full complexity of signing modes; always verify that transactions you aim to construct are supported by other tools you will rely on (hardware wallets, software wallets, command-line tools like [`cardano-hw-cli`](https://github.com/vacuumlabs/cardano-hw-cli) etc.).\n\n#### Multiassets\n\nAllowing duplicate `policy_id`s (or `asset_name`s) might lead to inconsistencies between what is displayed to the user and how nodes and other tools might interpret the duplicate keys, i.e. all policies (or asset names) would be shown to the user, but nodes and other tools might eventually interpret only a single one of them.\n\n#### Certificates\n\nCombining withdrawals and pool registration certificates isn't allowed because both are signed by staking keys by pool owners. If it was allowed to have both in a transaction then the witness provided by a pool owner might inadvertently serve as a witness for a withdrawal for the owner's account.\n\n#### Withdrawals\n\nSimilarly to multiassets, allowing duplicate withdrawals might lead to inconsistencies between what is displayed to the user and how nodes and other tools might interpret the duplicate keys.\n\n#### Auxiliary data\n\nThe specified auxiliary data format was chosen in order to be compatible with other Cardano tools, which mostly use this serialization format.\n\n### Stake key signing vs other keys\n\nA DRep witness can serve for both certificates and votes at the same time. Unlike with stake keys (where combining pool registration with e.g. withdrawals is forbidden), no restriction is imposed on the combination of certificates and votes.\nWe think that votes and DRep certificates are rare and substantially distinguished parts of a transaction, signed by DRep keys which are likely to only be used by users with deep enough understanding (and, unlike stake keys, are always visible when providing witnesses). A single vote or a DRep certificate is unlikely to have a major effect (esp. not on the loss of funds). If submitting unintended votes turns out to be a problem, it is likely better to solve it on the level of Cardano blockchain ledger by providing a mechanism allowing for replacing or cancelling votes.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Confirmation (by default if no ongoing incompatibilities) since Alonzo ledger era that this interoperability between software and hardware wallets has been generally achieved.\n\n### Implementation Plan\n\n- [x] Tools exist which can be used to validate or transform transactions into a HW wallet compatible format if possible:\n  - [x] [`cardano-hw-interop-library`](https://github.com/vacuumlabs/cardano-hw-interop-lib)\n  - [x] [`cardano-hw-cli`](https://github.com/vacuumlabs/cardano-hw-cli) (which uses the interop library)\n\n## Restrictions for specific hardware devices\n\nThe following list of features with missing support on particular hardware devices is subject to occasional changes. Some features might be added, but some could also be removed (e.g. if they take too much space needed for other features).\n\n#### Ledger: Nano S Plus, Nano X, Stax\n\nEverything described here as allowed should (eventually) work on these devices.\n\n#### Ledger: Nano S\n\nMissing features:\n- signing operational certificates\n- derivation of native script hashes\n- stake pool registration and retirement\n- display of certain details of Byron addresses (though addresses themselves are supported)\n\n#### Trezor\n\nMissing features:\n- derivation of stake pool cold keys\n- signing operational certificates\n- signing pool registration certificates as operator (only as owner is allowed)\n- derivation of DRep and constitutional committee keys\n- DRep certificates (registration, retirement, update)\n- constitutional committee certificates\n- voting procedures\n- treasury and donation elements of transactions\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0022/CIP-0022.md",
    "content": "Moved to [CIP-0022/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0022/README.md",
    "content": "---\nCIP: 22\nTitle: Pool operator verification\nStatus: Active\nCategory: Tools\nAuthors:\n  - Andrew Westberg <andrewwestberg@gmail.com>\n  - Martin Lang <martin@martinlang.at>\n  - Ola Ahlman <ola@ahlnet.nu>\nImplementors:\n  - CNCLI\n  - JorManager\n  - StakePoolOperator Scripts\n  - CNTools\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/102\nCreated: 2021-06-21\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis proposal describes a method allowing a stakepool operator to provide credentials to verify that they are the rightful manager for their stakepool.\n\n## Motivation: why is this CIP necessary?\n\nMany websites such pooltool.io, adapools.org, and others need to allow pool operators special access to modify the way their pool appears on the website. SPOCRA and other organizations also have a need to allow voting on proposals and ensure that each vote cast is from a valid pool operator. Today, these sites and organizations all use different techniques for validating pool operators.\n\npooltool.io - Validates operators by receiving 1 ada spent from the pool's registered rewards account\n\nadapools.org - Validates operators by requesting that the operator include a special generated value in their extended pool metadata json file.\n\nThis proposal is to simplify and streamline a single approach that all can reference in order to verify that a pool operator is who they say they are.\n\n## Specification\n\nIn order to achieve the goals of this CIP, the pool operator needs to provide some credential or credentials to the validating party which cannot be spoofed. The VRF pool keys and VRF signature algorithm implemented in libsodium are chosen to build and provide this credential/signature. This signature can then be validated and the operator verified without ever exposing any of the pool's private key information. This technique is very similar to verifying that a block produced by another pool is valid. The only difference is that instead of validating the slot seed for a given pool, we're validating a pre-determined message hash.\n\n### Verification Steps:\n\n1. Stakepool Operator (SPO) sends their pool_id and public pool.vrf.vkey to the Validating Server (VS)\n2. VS validates that the vrf hash in the pool's registration certificate on the blockchain matches the blake2b hash of the sent vkey. Note: The VS should use the latest registration certificate on the chain for matching as the VRF is a \"hot\" key and can be changed at any time by the pool operator. A single point-in-time verification is sufficient to properly identify the pool operator.\n3. The VS sends a challenge request to the SPO which is the domain of the VS and a random 64-byte nonce.\n4. The SPO creates a blake2b hash of \"cip-0022{domain}{random_nonce}\" and then signs this with their private VRF key.\n5. The SPO sends this to VS as the challenge response within a 5-minute window to the VS\n6. The VS validates the signed challenge response\n\n### Code Example (Validating server):\n\n```kotlin\n// Server side, create inputs for a challenge. Store this and only allow responses\n// within 5 minutes to be successful.\nval random = SecureRandom()\nval domain = \"pooltool.io\"\nval nonce = ByteArray(64)\nrandom.nextBytes(nonce)\nprintln(\"domain: $domain, nonce: ${nonce.toHexString()}\")\n```\n\n### Code Example (Pool Operator side):\n\n```kotlin\n// Node operational VRF-Verification-Key: pool.vrf.vkey\n//{\n//    \"type\": \"VrfVerificationKey_PraosVRF\",\n//    \"description\": \"VRF Verification Key\",\n//    \"cborHex\": \"5820e0ff2371508ac339431b50af7d69cde0f120d952bb876806d3136f9a7fda4381\"\n//}\n//\n// Node operational VRF-Signing-Key: pool.vrf.skey\n//{\n//    \"type\": \"VrfSigningKey_PraosVRF\",\n//    \"description\": \"VRF Signing Key\",\n//    \"cborHex\": \"5840adb9c97bec60189aa90d01d113e3ef405f03477d82a94f81da926c90cd46a374e0ff2371508ac339431b50af7d69cde0f120d952bb876806d3136f9a7fda4381\"\n//}\n\n// We assume the pool operator has access to the pool's vrf secret key\nval skeyCbor = \"5840adb9c97bec60189aa90d01d113e3ef405f03477d82a94f81da926c90cd46a374e0ff2371508ac339431b50af7d69cde0f120d952bb876806d3136f9a7fda4381\".hexToByteArray()\nval vrfSkey = (CborReader.createFromByteArray(skeyCbor).readDataItem() as CborByteString).byteArrayValue()\nval vkeyCbor = \"5820e0ff2371508ac339431b50af7d69cde0f120d952bb876806d3136f9a7fda4381\".hexToByteArray()\nval vrfVkey = (CborReader.createFromByteArray(vkeyCbor).readDataItem() as CborByteString).byteArrayValue()\n\n// Client side, construct and sign the challenge\nval challengeSeed = \"cip-0022${domain}\".toByteArray() + nonce\nval challenge = SodiumLibrary.cryptoBlake2bHash(challengeSeed, null)\nprintln(\"challenge: ${challenge.toHexString()}\")\n\nval signature = SodiumLibrary.cryptoVrfProve(vrfSkey, challenge)\nprintln(\"signature: ${signature.toHexString()}\")\n```\n\n### Code Example (Validating server):\n\n```kotlin\n// Server side, verify the message based on only knowing the pool_id, public vkey, signature, and constructing\n// the challenge ourselves the same way the client should have.\nval challengeSeed = \"cip-0022${domain}\".toByteArray() + nonce\nval challenge = SodiumLibrary.cryptoBlake2bHash(challengeSeed, null)\n\n// Get the vkeyHash for a pool from the \"query pool-params\" cardano-cli command\n// This comes from the pool's registration certificate on the chain.\nval vkeyHash = \"f58bf0111f8e9b233c2dcbb72b5ad400330cf260c6fb556eb30cefd387e5364c\".hexToByteArray()\n\n// Verify that the vkey from the latest minted block on the blockchain (or the client supplied if they\n// haven't yet minted a block) is the same as the one on-chain in the pool's registration certificate\nval vkeyHashVerify = SodiumLibrary.cryptoBlake2bHash(vrfVkey, null)\nassertThat(vkeyHash).isEqualTo(vkeyHashVerify)\n\n// Verify that the signature matches\nval verification = SodiumLibrary.cryptoVrfVerify(vrfVkey, signature, challenge)\nprintln(\"verification: ${verification.toHexString()}\")\n\nprintln(\"Verification SUCCESS!\")\n```\n\n### Code Example output:\n\n```\nvrfSkey: adb9c97bec60189aa90d01d113e3ef405f03477d82a94f81da926c90cd46a374e0ff2371508ac339431b50af7d69cde0f120d952bb876806d3136f9a7fda4381\nvrfVkey: e0ff2371508ac339431b50af7d69cde0f120d952bb876806d3136f9a7fda4381\ndomain: pooltool.io, nonce: c936ab102a86442c7120f75fa903b41d9f6f984a9373a6fa0b7b8cb020530318bdec84512468681c7d8454edf3a0e0bf21f59c401028030a8fb58117edc8b03c\nchallenge: 6977c480a3acb4c838ba95bb84d1f4db1c2591ea6ebe5805ed0394f706c23b05\nsignature: a3c9624aa14f6f0fba3d47d3f9a13bb55f0790eacd7bad9a89ce89fecb9e7eb8ca0d19aea8b6a7be39ae3e8b9768211b4d8aa789e82c1e150826fe15a0b0323f08e18635deb94c49d7f4421750d44903\nsignatureHash: 9ca4c7e63ba976dfbe06c7a0e6ec4aec5a5ef04b721ffc505222606dfc3d01572ddce3b55ac5c9470f061f137dafe31669794ea48118d1682d888efbe0cb4d1a\nverification: 9ca4c7e63ba976dfbe06c7a0e6ec4aec5a5ef04b721ffc505222606dfc3d01572ddce3b55ac5c9470f061f137dafe31669794ea48118d1682d888efbe0cb4d1a\nVerification SUCCESS!\n```\n\n## Rationale: how does this CIP achieve its goals?\n\nImplementing this simplifies and commonizes the process for verifying that a pool operator is who they say they are in 3rd party systems. Having a common way of verify pool operators also allows simple integration into pool management tools.\n\nThere is also some overlap with [CIP-0006](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0006/README.md#extended-metadata---flexible-but-validable) and the `rawdata-sign` command although it specifies generating a new key instead of utilizing the pool's existing `vrf.skey` to sign like this proposal.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Tools that have implemented, or are implementing, this proposal:\n  - [x] [CNCLI](https://github.com/AndrewWestberg/cncli)\n  - [x] [JorManager](https://bitbucket.org/muamw10/jormanager/)\n  - [x] [StakePoolOperator Scripts](https://github.com/gitmachtl/scripts)\n  - [x] [CNTools](https://cardano-community.github.io/guild-operators/#/Scripts/cntools)\n\n### Implementation Plan\n\n- [x] Consensus between providers of the most popular tools and CLIs for stake pool operators that this approch is viable and desirable.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0023/CIP-0023.md",
    "content": "Moved to [CIP-0023/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0023/README.md",
    "content": "---\nCIP: 23\nTitle: Fair Min Fees\nAuthors:\n  - Shawn McMurdo <shawn_mcmurdo@yahoo.com>\n  - Ryan Wiley <rian222@gmail.com>\nCategory: Ledger\nStatus: Proposed\nCreated: 2021-02-04\nDiscussions:\n - https://forum.cardano.org/t/fair-min-fees-cip/47534\n - https://github.com/cardano-foundation/CIPs/pull/66\nImplementors: []\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP introduces a new protocol parameter, `minPoolMargin`, which specifies a lower bound on the variable fee (margin) a stake pool may set. The parameter is introduced initially set to `0` to avoid disrupting existing pool certificates.  This proposal does not change or reduce the existing minimum fixed pool fee (`minPoolCost`).\n\n## Motivation: why is this CIP necessary?\n\nThe current minimum fixed pool fee places a large and unfair burden on delegators to pools with smaller amounts of stake.\nThis incentivizes people to delegate to pools with higher stake causing centralization and creating an unequal playing field for stake pool operators.\n\nUsing a minimum variable pool fee reduces the imbalance between stake pools with less or more stake to a more reasonable range that allows for more fair competition between stake pools and more fair rewards for delegators to stake pools with less stake.\n\nThis creates a more fair marketplace for all stake pool operators and increases decentralization, which is a goal of Cardano.\n\n## Specification\n\nThis CIP introduces a new protocol parameter, `minPoolMargin`, which represents the\nminimum variable fee (margin) that a stake pool can set. This parameter is\ndistinct from the existing `minPoolCost`, which represents the minimum fixed\nfee a pool can set. Both limits are enforced independently by the ledger.\n\n- `minPoolMargin` defines the lower bound for the pool margin (variable fee), i.e.,\n  the minimum allowable percentage of rewards a pool can take. Pool\n  registration and update certificates MUST have `margin >= minPoolMargin`.\n- `minPoolCost` retains its current meaning and enforcement as the minimum\n  fixed fee a pool can set.\n\nThis CIP does not prescribe specific values for either parameter. Concrete\nvalues for `minPoolMargin` and `minPoolCost` are to be chosen and enacted through\nthe standard protocol parameter update process.\n\n### Backward Compatibility\n\nTo maintain compatibility for existing pool certificates whose current margin is below the new `minPoolMargin`, the ledger's rewards calculation should treat the protocol parameter `minPoolMargin` as the effective margin for those pools. In other words, if a pool's margin is less than `minPoolMargin`, the protocol-level `minPoolMargin` overrides the pool's registered `margin` during reward calculation. This minimizes disruption and lets legacy pool certificates remain valid while ensuring the ledger enforces the new minimum fee during reward distribution.\n\nIt is also recommended to introducce the hard-fork with `minPoolMargin` initially set to `0`. Doing so minimizes migration friction for stake pool operators and gives governance time to raise the parameter to its target value through the normal paramater change governance action process.\n\nShould this clamping approach prove infeasible, pool certificates with a margin lower than `minPoolMargin` would need to be re-registered with compliant values, but the goal is to avoid disruption as much as possible.\n\n## Rationale: how does this CIP achieve its goals?\n\nThe PHP code in minfees.php in the pull request allows exploration of the effects of choosing different values for the minimum fixed and variable fees.\nRunning minfees without any arguments gives the usage message as below.\n\n```\nphp minfees.php\n\nUsage: php minfees.php <min_fixed_fee> <min_rate_fee> <pledge>\n  min_fixed_fee:  Minimum fixed fee in ADA.\n               An integer greater than or equal to 0.\n  min_rate_fee: Minimum rate fee in decimal. Example: 1.5% = .015\n                    A real number greater than or equal to 0.\n  pledge: Optional pledge amount in ADA. Defaults to 100000\n                    A real number greater than or equal to 0.\n```\n\nRunning minfees with the proposed values gives the following comparison of current and proposed pool operator and staker results at various pool stake levels.\n\n```\nphp minfees.php 50 .015 100000\n\nReserve: 13b\nTotal stake: 32b\nTx fees: 0\nRewards available in epoch: 31.2m\nPool saturation: 64m\nPledge: 100k\nStaker Delegation: 100k\nCurrent Fixed Fee: 340\nCurrent Rate: 0%\nNew Fixed Fee: 50\nNew Rate: 1.5%\n\n                +---------- Current ----------+ +-------- Proposed ---------+\nPool    Total   Pool    Staker  Staker  Current Pool    Staker  Staker  New\nStake   Rewards Cur Fee Cur Fee Cur Rew Fee %   New Fee New Fee New Rew Fee %\n2m      1501    340     17      58.1    22.7%   71.8    3.6     71.5    4.8%\n5m      3752    340     6.8     68.2    9.1%    105.5   2.1     72.9    2.8%\n10m     7503    340     3.4     71.6    4.5%    161.8   1.6     73.4    2.2%\n20m     15007   340     1.7     73.3    2.3%    274.4   1.4     73.7    1.8%\n30m     22511   340     1.1     73.9    1.5%    386.9   1.3     73.7    1.7%\n64m     48023   340     0.5     74.5    0.7%    769.6   1.2     73.8    1.6%\n```\n\nDefinitions:\nPool Stake - Total stake delegated to pool.\nTotal Rewards - Total rewards generated by the pool in one epoch.\nPool Cur Fee - The total amount of fees taken by the pool with current parameters.\nStaker Cur Fee - The amount of fees paid by a staker who delegates 100k ADA  with current parameters.\nStaker Cur Rew - The amount of rewards received by a staker who delegates 100k ADA  with current parameters.\nCurrent Fee % - The percentage of rewards taken by the pool as fees  with current parameters.\nPool New Fee - The total amount of fees taken by the pool with proposed parameters.\nStaker New Fee - The amount of fees paid by a staker who delegates 100k ADA with proposed parameters.\nStaker New Rew - The amount of rewards received by a staker who delegates 100k ADA with proposed parameters.\nNew Fee % - The percentage of rewards taken by the pool as fees with proposed parameters.\nNote: All amounts other than %s are in ADA.\n\nThe table above shows that currently a delegator staking 100k ADA to a stake pool with 2m ADA total delegation to the pool is paying an exorbitant 22.7% in fees while the same delegator staking with a fully saturated pool would only pay 0.7% in fees.\nThis is a substantial and unfair advantage that large pools have in the stake pool marketplace.\nThis is a strong incentive to centralize stake to fewer larger pools which reduces the resiliency of the network.\n\nThe proposed minimum fees bring this imbalance into a more reasonable range of 1.6% to 4.8%.\nIt is much more likely that a small stake pool with other advantages or selling points would be able to convince a delegator to accept about 2 less ADA in rewards per epoch for their 100k delegation than about 17 ADA as in the current case.\nThis is particularly true as the price of ADA increases.\nAt current price of $0.90 USD, a delegator staking 100k ADA is giving up over $1000 USD per year by delegating to a small pool!\nThis does not even include the amount lost by comounding rewards being staked over the year.\n\n16.5 ADA/epoch * 73 epochs/year =  1204.5 ADA/year\n1204.5 ADA/year * $0.90 USD/ADA = $1084.05 USD/year\n\nWith proposed parameters the same delegator would only be giving up about $150 USD per year to support a small pool.\n\n2.3 ADA/epoch * 73 epochs/year =  167.9 ADA/year\n167.9 ADA/year * $0.90 USD/ADA = $151.11 USD/year\n\nThe calculations below show that given the price increase in ADA compared to when the protocol parameters were first set, we can maintain viable funding for stake pool operators with the proposed parameter changes.\n\nAnnual pool operator funding given initial parameters:\n340 ADA/epoch * $0.08 USD/ADA = $27.20 USD/epoch\n$27.20 USD/epoch * 73 epochs/year = $1985.60 USD/year\n\nAnnual pool operator funding given proposed parameters for stake pool with 2 million ADA delegation:\n71.8 ADA/epoch * $0.90 USD/ADA = $64.62 USD/epoch\n$64.62 USD/epoch * 73 epochs/year = $4717.26 USD/year\n\nAnnual pool operator funding given proposed parameters for fully saturated stake pool:\n769.6 ADA/epoch * $0.90 USD/ADA = $692.64 USD/epoch\n$692.64 USD/epoch * 73 epochs/year = $50,562.72 USD/year\n\nIn summary, the proposed parameter changes would create a more fair marketplace for stake pools, provide more fair rewards for delegators to smaller pools and would lower incentives for centralization providing a more resilient network.\n\n### Test Cases\n\nSee the minfees.php code to test different potential values of the parameters.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- Consensus on initial parameter value – An initial value for the new protocol parameter `minPoolMargin` must be agreed upon before hard-fork combinator (HFC) activation. The choice should consider operational viability, empirical analyses, and community feedback.\n- Endorsement by Technical Bodies – The Cardano Parameter-Change Proposals (PCP) Committee and the Intersect Technical Steering Committee (TSC) should both recommend the proposal as technically sound and aligned with the protocol’s long-term roadmap.\n- Stakeholder Concurrence – A majority of stake pool operators (SPOs), ecosystem tooling maintainers, dReps, and other infrastructure providers must signal readiness to upgrade.\n- Governance Ratification – The on-chain Hard-Fork Governance Action must pass the requisite dRep and Constitutional Committee thresholds, establishing legal-constitutional legitimacy and stakeholder support for the change.\n\n### Implementation Plan\n\n- Community Deliberation (Preparation Phase)\n  - Publish the finalized CIP revision and present it to the PCP committee, TSC, CIP Editors, and wider community channels (Discord, X, Cardano Forum, etc.).\n  - Collect structured feedback, particularly on candidate values for the new parameter values and iterate until broad technical consensus emerges.\n- Specification & Code Integration (Development Phase)\n  - Once initial parameter values are determined, integrate the new rewards calculation logic and governance features for the new parameter into cardano-node and related libraries (ledger, CLI, wallet APIs).\n  - Determine the best method to deal with existing pool registration certificates that currently have a variable fee lower than what the new `minPoolMargin` parameter allows.\n  - Submit pull requests to the canonical repositories; obtain code reviews from IOG, CF, and community contributors.\n  - Release a new protocol version that includes the changes made in this CIP.\n  - Use a dedicated pre-production testnet that mirrors main-net parameters but enforces the new changes, allowing SPOs and exchanges to test end-to-end flows.\n- Readiness Sign-off (Testing Phase)\n  - Require at least two weeks of uninterrupted testnet stability plus green results from regression and property-based tests.\n  - Monitor ecosystem dApps and tooling to confirm that major node implementations, explorers, wallets, and exchange integrations support the new rule set.\n- On-chain Governance (Ratification Phase)\n  - File the Hard-Fork Governance Action on-chain with the agreed initial parameter value tagged for the next hard fork event.\n  - Modify the existing Cardano Constitution to include definitions and guardrails for the new protocol parameters and have it ratified by the tripartite government of Cardano.\n  - Mobilize dRep outreach to ensure quorum and super-majority passage; concurrently, the Constitutional Committee validates procedural compliance.\n- Hard-Fork Activation (Deployment Phase)\n  - Upon successful vote, the hard fork event is automatically triggered upon epoch turnover.\n  - Monitor main-net metrics during the changeover epoch; provide real-time support for any late-upgrading SPOs.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)"
  },
  {
    "path": "CIP-0023/minfees.php",
    "content": "<?php\n\n$argc = count($argv);\n\nif ($argc == 3) {\n  $new_fixed = $argv[1];\n  $new_rate = $argv[2];\n  $pledge = 100000;\n} else if ($argc == 4) {\n  $new_fixed = $argv[1];\n  $new_rate = $argv[2];\n  $pledge = $argv[3];\n} else {\n  echo \"Usage: php \" . $argv[0] . \" <min_fixed_fee> <min_rate_fee> <pledge>\" . PHP_EOL;\n  echo \"  min_fixed_fee:  Minimum fixed fee in ADA.\" . PHP_EOL;\n  echo \"               An integer greater than or equal to 0.\" . PHP_EOL;\n  echo \"  min_rate_fee: Minimum rate fee in decimal. Example: 1.5% = .015\" . PHP_EOL;\n  echo \"                    A real number greater than or equal to 0.\" . PHP_EOL;\n  echo \"  pledge: Optional pledge amount in ADA. Defaults to 100000\" . PHP_EOL;\n  echo \"                    A real number greater than or equal to 0.\" . PHP_EOL;\n  exit;\n}\n\nif ($pledge < 1000000) {\n  $pledge_str = round($pledge / 1000, 1) . \"k\";\n} else {\n  $pledge_str = round($pledge / 1000000, 1) . \"m\";\n}\n\n// Protocol parameters\n$k = 500;\n$rho = 0.003;\n$a0 = 0.3;\n$tau = .2;\n\n// Assumptions\n$current_fixed = 170;\n$current_rate = 0.0;\n$reserve = 1690000000;\n$total_stake = 37000000000;\n$fees = 32000;\n$staker = 100000;\n\nif ($staker < 1000000) {\n  $staker_str = round($staker / 1000, 1) . \"k\";\n} else {\n  $staker_str = round($staker / 1000000, 1) . \"m\";\n}\n\n// Calculated values\n$R = (($reserve * $rho) + $fees) * (1 - $tau);\n$z0 = 1 / $k;\n$saturation = $total_stake / $k;\n$half_saturation = $saturation / 2;\n$ds = array(2000000, 5000000, 10000000, 20000000, $half_saturation, $saturation);\n$os = array();\n\nforeach ($ds as $d) {\n  $os[] = $d / $total_stake;\n}\n\necho \"Reserve: \" . round($reserve / 1000000000, 1) . \"b\" . PHP_EOL;\necho \"Total stake: \" . round($total_stake / 1000000000, 1) . \"b\" . PHP_EOL;\necho \"Tx fees: \" . $fees . PHP_EOL;\necho \"Rewards available in epoch: \" . round($R / 1000000, 1) . \"m\" . PHP_EOL;\necho \"Pool saturation: \" . round($saturation / 1000000, 1) . \"m\" . PHP_EOL;\necho \"Pledge: \" . $pledge_str . PHP_EOL;\necho \"Staker Delegation: \" . $staker_str . PHP_EOL;\necho \"Current Fixed Fee: \" . $current_fixed . PHP_EOL;\necho \"Current Rate: \" . round($current_rate * 100, 1) . '%' . PHP_EOL;\necho \"New Fixed Fee: \" . $new_fixed . PHP_EOL;\necho \"New Rate: \" . round($new_rate * 100, 1) . '%' . PHP_EOL;\necho PHP_EOL;\n\necho \"\\t\\t/---------- Current ----------\\\\ /-------- Proposed ---------\\\\\" . PHP_EOL;\necho \"Pool\\tTotal\\tPool\\tStaker\\tStaker\\tCurrent\\tPool\\tStaker\\tStaker\\tNew\" . PHP_EOL;\necho \"Stake\\tRewards\\tFee\\tFee\\tRew\\tFee %\\tFee\\tFee\\tRew\\tFee %\" . PHP_EOL;\necho \"---------------------------------------------------------------------\" . PHP_EOL;\n\n$i = 0;\n\nforeach ($os as $o) {\n  // Rewards Formula\n  $s = $pledge / $total_stake;\n  $rewards = round(($R / (1 + $a0)) * ($o + ($s * $a0 * (($o - ($s * (($z0 - $o) / $z0))) / $z0))));\n  $current_rate_basis = $rewards - $current_fixed;\n  $current_rate_fee = $current_rate_basis * $current_rate;\n  $current_fees = $current_fixed + $current_rate_fee;\n\n  if ($current_fees > $rewards) {\n    $current_fees = $rewards;\n  }\n\n  $current_fee_per_staker = $current_fees * ($staker / $ds[$i]);\n  $current_reward_per_staker = ($rewards - $current_fees) * ($staker / $ds[$i]);\n  $current_fee_percent = round(($current_fees / $rewards) * 100, 1);\n  $new_rate_basis = $rewards - $new_fixed;\n  $new_rate_fee = $new_rate_basis * $new_rate;\n  $new_fees = $new_fixed + $new_rate_fee;\n  $new_fee_per_staker = $new_fees * ($staker / $ds[$i]);\n  $new_reward_per_staker = ($rewards - $new_fees) * ($staker / $ds[$i]);\n  $new_fee_percent = round(($new_fees / $rewards) * 100, 1);\n  $d_str = round($ds[$i] / 1000000, 1) . 'm';\n\n  echo $d_str . \"\\t\" . $rewards . \"\\t\" . round($current_fees, 1) . \"\\t\" . round($current_fee_per_staker, 1) . \"\\t\" . round($current_reward_per_staker, 1) . \"\\t\" . $current_fee_percent . \"%\\t\" . round($new_fees, 1) . \"\\t\" . round($new_fee_per_staker, 1) . \"\\t\" . round($new_reward_per_staker, 1) . \"\\t\" . $new_fee_percent . '%' . PHP_EOL;\n  $i++;\n}\n\necho PHP_EOL;\n\n"
  },
  {
    "path": "CIP-0024/CIP-0024.md",
    "content": "Moved to [CIP-0024/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0024/README.md",
    "content": "---\nCIP: 24\nTitle: Non-Centralizing Rankings\nAuthors:\n  - Shawn McMurdo <shawn_mcmurdo@yahoo.com>\nCategory: Wallets\nStatus: Proposed\nDiscussions:\n  - https://forum.cardano.org/t/how-to-improve-daedalus-rankings/40478\n  - https://github.com/cardano-foundation/CIPs/pull/21\nImplementors: []\nCreated: 2020-09-15\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nModify the current Daedalus ranking system by removing the centralizing Nash Equilibrium goal of the ranking methodology in order to give more fair rankings and improve the viability of the stake pool operator community and the network overall.  To do this we need to remove the stated goal of having k fully saturated pools and all other pools having no stake other than owner pledge, which goes against the Cardano goal of decentralization.\n\n## Motivation: why is this CIP necessary?\n\nThere are two main reasons for changing the current ranking methodology:\n\n1. Allow for more than k successful stake pools.\n\n2. Provide better decentralization away from a very few stake pool operators creating many pools.\n\n## Specification\n\nThis is a modification of the ranking methodology defined in section 5.6 Non-Myopic Utility of “Shelley Ledger: Delegation/Incentives Design Spec. (SL-D1 v.1.20, 2020/07/06)” as follows:\n\n1. Remove the following statement from section 5.6:\n\n\"The idea is to first rank all pools by “desirability”, to then assume that the k most desirable\npools will eventually be saturated, whereas all other pools will lose all their members, then to\nfinally base all reward calculations on these assumptions.\"\n\n2. Remove the following statement from section 5.6.1:\n\n\"We predict that pools with rank ≤ k will eventually be saturated, whereas pools with rank\n> k will lose all members and only consist of the owner(s).\"\n\n3. Add the following to section 5.6.1:\n\nFor all pools with proposed_pool_stake greater than saturation_warning_stake add k to their rank.\nWhere:\nproposed_pool_stake = pool_live_stake + proposed_user_stake\nsaturation_warning_stake = (total_stake / k) * saturation_warning_level\nsaturation_warning_level is a real number greater than 0 representing the percent of saturation which is undesirable.  A proposed value for saturation_warning_level is 0.95 meaning 95% saturated.\n\nFor example, if a pool has non-myopic desirability rank of 3, pool_live_stake of 207m ADA, proposed_user_stake of 100k ADA with total_stake of 31.7b ADA, k = 150 and saturation_warning_level = 0.95, we would calculate:\n207m + 100k > (31.7b / 150) * 0.95\nand see that\n207.1m > 200.8m\nis true so we would change the pool rank to 153 (3 + k) and all pools previously ranked 4 through 153 would move up 1 rank.\n\n4. Remove secion 5.6.2.\n\n5. Remove section 5.6.3.\n\n6. Remove section 5.6.4.\n\n7. Add to secion 5.6.5.\n\nFor example, apparent performance, desirability and ranking can be made non-myopic for ranking purposes as follows:\n\ndnm[n] :=\n average(d[1]...d[n],and[n + 1]...and[i])  if n < i\n average(d[1]...d[n])  if n = i\n (dnm[n - 1] * h) + (d[n] * (1 - h))  otherwise.\n \nwhere:\nn = epoch number beginning at n = 1 in the first epoch that the pool is eligible for potential rewards.\ndnm[n] = the non-myopic desirability of the pool in the nth epoch.\nd[n] = the desirability in the nth epoch unaware of historical desirability.\nand[n] = the average desirability of the network as a whole in the nth epoch unaware of historical desirability.\nh = historical influence factor, which is any real number between 0 and 1 exlusive.\ni = integer(1 / h) which is the initial number of epochs during which we use the average desirability\n\nAs an example, setting h to 0.1 would mean that the initial number of epochs for using the averaging functions (i) would be 10.  If a pool has been eligible to receive rewards (n) for 3 epochs then we use the average of the pool's desirability for those 3 epochs and the overall network desirability for the prior 7 epochs.  After the 10th epoch we would use 90% of the previous epoch's non-myopic historical desirability and 10% of the current epoch's desirability to arrive at the new non-myopic desirability.\n\nThis gives a more reasonable ranking for newer pools that do not have enough historical data to provide fair rankings.\n\n## Rationale: how does this CIP achieve its goals?\n\nUsing this non-centralizing ranking methodology gives a more fair ranking of stake pools based on performance, pledge and saturation which will encourage delegators to choose better pools.\nIt will also bring the rankings more in line with the general Cardano principle of increasing decentralization.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] One or more wallet software implements this new ranking approach.\n\n### Implementation Plan\n\n- [ ] Author has offered to produce an implementation of this change as a cardano-wallet / Daedalus pull request if shown where the current desirability equation is implemented in the code.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n"
  },
  {
    "path": "CIP-0025/CIP-0025.md",
    "content": "Moved to [CIP-0025/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0025/README.md",
    "content": "---\nCIP: 25\nTitle: Media Token Metadata Standard\nStatus: Active\nCategory: Tokens\nAuthors:\n  - Alessandro Konrad <alessandro.konrad@live.de>\n  - Smaug <smaug@pool.pm>\nImplementors: N/A\nDiscussions:\n  - https://forum.cardano.org/t/cip-nft-metadata-standard/45687\n  - https://www.reddit.com/r/CardanoDevelopers/comments/mkhlv8/nft_metadata_standard/\n  - https://github.com/cardano-foundation/CIPs/pull/85\n  - https://github.com/cardano-foundation/CIPs/pull/267\n  - https://github.com/cardano-foundation/CIPs/pull/341\n  - https://github.com/cardano-foundation/CIPs/pull/527\n  - https://github.com/cardano-foundation/CIPs/pull/593\nCreated: 2021-04-08\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis proposal defines an Media Token Metadata Standard for Native Tokens.\n\n## Motivation: why is this CIP necessary?\n\nTokens on Cardano are a part of the ledger. Unlike on Ethereum, where metadata can be attached to a token through a smart contract, this isn't possible on Cardano because tokens are native and Cardano uses a UTxO ledger, which makes it hard to directly attach metadata to a token.\nSo the link to the metadata needs to be established differently.\n\nCardano has the ability to send metadata in a transaction, allowing the creation of a link between a token and the metadata. To make the link unique, the metadata should be appended to the same transaction, where the token forge happens:\n\n> Given a token in a EUTXOma ledger, we can ask “where did this token come from?” Since tokens\n> are always created in specific forging operations, we can always trace them back through their\n> transaction graph to their origin.\n\n—Section 4 in the paper [UTXOma:UTXO with Multi-Asset Support](https://iohk.io/en/research/library/papers/utxomautxo-with-multi-asset-support/)\n\nThat being said, we have unique metadata link to a token and can always prove that with 100% certainty. No one else can manipulate the link except if the policy allows it to ([update mechanism](#update-metadata-link-for-a-specific-token)).\n\n## Specification\n\nThis is the registered `transaction_metadatum_label` value\n\n| transaction_metadatum_label | description  |\n| --------------------------- | ------------ |\n| 721                         | Token Metadata |\n\n### General structure\n\nThe structure allows for multiple token mints, also with different policies, in a single transaction.\n\n```\n{\n  \"721\": {\n    \"<policy_id>\": {\n      \"<asset_name>\": {\n        \"name\": <string>,\n\n        \"image\": <uri | array>,\n        \"mediaType\": image/<mime_sub_type>,\n\n        \"description\": <string | array>,\n\n        \"files\": [{\n          \"name\": <string>,\n          \"mediaType\": <mime_type>,\n          \"src\": <uri | array>,\n          <other_properties>\n        }],\n\n        <other properties>\n      }\n    },\n    \"version\": <version_id>\n  }\n}\n```\n\n### CDDL\n\n[Version 1](./cddl/version_1.cddl)\\\n[Version 2](./cddl/version_2.cddl)\n\n- In version `1` the **`asset_name`** must be `utf-8` encoded and in text format for the key in the metadata map. In version `2` the the raw bytes of the **`asset_name`** are used.\n\n- In version `1` the **`policy_id`** must be in text format for the key in the metadata map. In version `2` the the raw bytes of the **`policy_id`** are used.\n\n- The  **`name`** property is marked as required.\n- The **`image`** property is required and must be a valid [Uniform Resource Identifier (URI)](https://www.rfc-editor.org/rfc/rfc3986) pointing to a resource with mime type `image/*`.  Note that this resource is used as thumbnail or the actual link if the token is an image (ideally <= 1MB). If the string representing the resource location is >64 characters, an array may be used in place of a simple JSON string type, which viewers will automatically concatenate to create a single URI.\n\t- Please note that if distributed storage systems like IPFS or Arweave are used it is required to use a URI containing the respective scheme (e.g., `ipfs://` or `ar://`) and not merely the content identifier (CID) as token viewers may not be able to locate the file.\n\t\t- Valid identifiers would include:\n\t\t\t- `\"https://cardano.org/favicon-32x32.png\"`\n\t\t\t- `\"ipfs://QmbQDvKJeo2NgGcGdnUiUFibTzuKNK5Uij7jzmK8ZccmWp\"`\n\t\t\t- `[\"ipfs://\", \"QmbQDvKJeo2NgGcGdnUiUFibTzuKNK5Uij7jzmK8ZccmWp\"]`\n\t\t- Invalid identifiers would include:\n\t\t\t- `\"cardano.org/favicon-32x32.png\"`\n\t\t\t- `\"QmbQDvKJeo2NgGcGdnUiUFibTzuKNK5Uij7jzmK8ZccmWp\"`\n\t\t\t- `[\"Qm\", \"bQDvKJeo2NgGcGdnUiUFibTzuKNK5Uij7jzmK8ZccmWp\"]`\n\t-  If an inline base64-encoded image will be used, the data must be prepended with a valid `data:<mime_type>;base64` prefix as specified by the [data URL scheme standard](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs) to indicate the image is an inline data object\n\t- See [the OpenSea \"IPFS and Arweave URIs\" section in their reference guide](https://docs.opensea.io/docs/metadata-standards#ipfs-and-arweave-uris) for more helpful information on the topic.\n\n- The **`description`** property is optional.\n\n- The **`mediaType`** and **`files`** properties are optional.<br /> **`mediaType`** is however required inside **`files`**. The **`src`** property inside **`files`** is an URI pointing to a resource of this mime type. If the mime type is `image/*`, **`mediaType`** points to the same image, like the on in the **`image`** property, but in an higher resolution.\n\n- The **`version`** property is also optional. If not specified the version is `1`. It will become mandatory in future versions if needed.\n\n- This structure really just defines the basis. New properties and standards can be defined later on for varies uses cases. That's why there is an \"other properties\" tag.\n\n- The retrieval of the metadata should be the same for all however.\n\nOptional fields allow to save space in the blockchain. Consequently the minimal structure for a single token is:\n\n#### Version 1\n\n```\n{\n  \"721\": {\n    \"<policy_id>\": {\n      \"<asset_name>\": {\n        \"name\": <string>,\n        \"image\": <uri | array>\n      }\n    }\n  }\n}\n```\n\n#### Version 2\n\n```\n{\n  \"721\": {\n    \"<policy_id>\": {\n      \"<asset_name>\": {\n        \"name\": <string>,\n        \"image\": <uri | array>\n      }\n    },\n    \"version\": 2\n  }\n}\n```\n\n### References\n\n- Mime types: [RFC6838: Media Type Specifications and Registration Procedures](https://tools.ietf.org/html/rfc6838)\n- CIP about reserved labels: [CIP-0010: Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010)\n- [EIP-721](https://eips.ethereum.org/EIPS/eip-721)\n- URI/URL standards: [RFC3986](https://tools.ietf.org/html/rfc3986), [RFC2397](https://tools.ietf.org/html/rfc2397)\n\n## Rationale: how does this CIP achieve its goals?\n\n### Retrieve valid metadata for a specific token\n\nAs mentioned above this metadata structure allows to have either one token or multiple tokens with also different policies in a single mint transaction. A third party tool can then fetch the token metadata seamlessly. It doesn't matter if the metadata includes just one token or multiple. The procedure for the third party is always the same:\n\n1. Find the latest mint transaction with the label 721 in the metadata of the specific token that mints a positive amount of the token\n2. Lookup the 721 key\n3. Lookup the Policy Id of the token\n4. Lookup the Asset name of the token\n5. You end up with the correct metadata for the token\n\n### Update metadata link for a specific token\n\nUsing the latest mint transaction with the label 721 as valid metadata for a token allows to update the metadata link of this token. As soon as a new mint transaction is occurring including metadata with the label 721 and a positive amount of the token, the metadata link is considered updated and the new metadata should be used. This is only possible if the policy allows to mint or burn the same token again.\n\nSince modern token policies or ledger rules should generally make burning of tokens permissionless, the metadata update is restricted to minting (as in positive amounts) transaction and excludes burning transactions explicitly.\n\n### Backward Compatibility\n\nTo keep token metadata compatible with changes coming up in the future, we use the **`version`** property.\nA future version will introduce [schema.org](https://schema.org).\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Support of this NFT definition in a commercially significant number and variety of NFT-related services and wallets.\n- [x] Evolution of this document and standard beyond its early adoption and use cases (up through the point when alternative NFT standards have emerged).\n\n### Implementation Plan\n\n- [x] Promulgation of this standard among NFT creators, minting services, token analytic / query services, and wallets.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0025/cddl/version_1.cddl",
    "content": "string = text .size (0..64)\n\npolicy_id = string\nasset_name = string ; utf-8\n\nfiles_details = \n  {\n    name : string,\n    mediaType : string,\n    src : string / [* string]\n  }\n\nmetadata_details = \n  {\n    name : string,\n    image : string / [* string], \n    ? mediaType : string,\n    ? description : string / [* string],\n    ? files : [* files_details]\n  }\n\nlabel_metadata = { * policy_id => { * asset_name => metadata_details } }\n\nmetadata = { 721 : uint => label_metadata }"
  },
  {
    "path": "CIP-0025/cddl/version_2.cddl",
    "content": "string = text .size (0..64)\n\npolicy_id = bytes ; no longer in text\nasset_name = bytes ; no longer in text and utf-8\n\nfiles_details = \n  {\n    name : string,\n    mediaType : string,\n    src : string / [* string]\n  }\n\nmetadata_details = \n  {\n    name : string,\n    image : string / [* string], \n    ? mediaType : string,\n    ? description : string / [* string],\n    ? files : [* files_details]\n  }\n\nlabel_metadata = { * policy_id => { * asset_name => metadata_details }, version: 2 } ; version 2\n\nmetadata = { 721 : uint => label_metadata }"
  },
  {
    "path": "CIP-0026/README.md",
    "content": "---\nCIP: 26\nTitle: Cardano Off-Chain Metadata\nStatus: Active\nCategory: Metadata\nAuthors:\n  - Matthias Benkort <matthias.benkort@iohk.io>\n  - Michael Peyton Jones <michael.peyton-jones@iohk.io>\n  - Polina Vinogradova <polina.vinogradova@iohk.io>\nImplementors:\n  - cardano-token-registry <https://github.com/cardano-foundation/cardano-token-registry>\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/112\nCreated: 2021-08-10\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nWe introduce a standard for off-chain metadata that can map opaque on-chain identifiers to metadata suitable for human consumption. This will support user-interface components, and allow resolving trust issues in a moderately decentralized way.\n\n## Motivation: why is this CIP necessary?\n\nOn the blockchain, we tend to refer to things by hashes or other opaque identifiers. But these are not very human friendly:\n* In the case of hashes, we often want to know the preimage of the hash, such as\n   * The script corresponding to an output locked by a script hash\n   * The public key corresponding to a public key hash\n* We want other metadata as appropriate, such as\n   * A human-friendly name\n   * The name of the creator, their website, an icon, etc. etc.\n* We would like such metadata to be integrated into the UI of our applications\n   * For example, if I’ve accepted a particular name for a currency, I’d like to see that name everywhere in the UI instead of the hash\n* We want the security model of such metadata to be sound\n   * For example, we don’t want users to be phished by misleading metadata\n\nWe think there is a case for a metadata distribution system that would fill these needs in a consistent fashion. This would be very useful for Plutus, multi-asset support, and perhaps even some of the existing Cardano infrastructure. Moreover, since much of the metadata which we want to store is not determined by the blockchain, we propose a system that is independent of the blockchain, and relies on non-blockchain trust mechanisms.\n\nThe Rationale section provides additional justifications for the design decisions in this document.\n\n### Use Cases\n\n#### Hashed Content\n\nMany pieces of information on the Cardano blockchain are stored as hashes, and only revealed at later stages when required for validation. This is the case for example of scripts (Plutus or phase-1), datums, and public keys. It is likely that (some) users will want to know the preimages of those hashes in a somewhat reliable way and, before they are revealed on-chain.\n\n#### Off-Chain Metadata\n\nUnlike some (un)popular opinions suggest, a blockchain is a poor choice for a content database. Blockchains are intrinsically ledgers and they are good at recording events or hashes. Yet, there are several elements for which hashes aren't providing a great user experience and to which we would rather attach some human-readable metadata (like names, websites, contact details etc...). This is the case for stake pool for instance for which [SMASH](https://github.com/input-output-hk/smash/) already provides a solution. This is also the case for monetary policies and scripts. In both cases, having the ability to attach extra metadata to _some_ hash with a way to ensure the authenticity of the data is useful.\n\n## Specification\n\nThis specification covers some parts of a bigger system likely involving multiple components. What part is being implemented and by who is considered out of the scope of this specification. We however envision a setup in which users have access to a client application (a.k.a the wallet), which itself is able to connect to some remote server. We assume the server to also offer a user-interface (either via a graphical user-interface or a application programming interface) for accepting content. \n\n> **Note** The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"NOT RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).\n\n### Hash Function\n\nThere are several places in this document where we need an arbitrary hash function. We will  henceforth refer to this simply as “hash”. The hash function MUST be **Blake2b-256** (unless explicitly said otherwise). The hash of a string is the hash of the bytes of the string according to its encoding.\n\n### Metadata Structure\n\nMetadata consists of a mandatory _metadata subject_, and a number of _metadata properties_ which describes that subject. Each property consists of a mapping from _property names_ to _property values_, _sequence numbers_ and _signatures_.\n\nMetadata subjects, property names, and property values must all be represented as UTF-8 encoded strings. In addition, property values must parse as valid JSON.\n\nThere is no particular interpretation attached to a metadata subject: it can be anything (see however the special-case of phase-1 monetary policy below). We anticipate however that the primary use-case for it will be something that appears on the blockchain, like the hash of a script.\n\nWe will refer to a whole metadata as a _metadata object_ and to a particular property assignment for a particular metadata subject as a _metadata entry_. We will say that a metadata object is _well-formed_ when it validates according to the [JSON-schema specification given in annex][schema.json]. To be valid, a metadata object MUST be (at least) well-formed.\n\n```json\n{\n  \"subject\": \"a5408d0db0d942fd80374\",\n  \"contact\": {\n    \"value\": \"Cid Kramer\",\n    \"sequenceNumber\": 0,\n    \"signatures\": [\n      {\n        \"signature\": \"79a4601\",\n        \"publicKey\": \"bc77d04\"\n      }\n    ]\n  }\n}\n```\n\n#### Sequence Numbers\n\nMetadata entries MUST have a `sequenceNumber` associated with them. This is a monotonically increasing integer which is used to ensure that clients and servers do not revert to “earlier” versions of an entry. Upon receiving new metadata objects, servers SHOULD verify the sequence number for each entry already known for that subject and reject submissions with a lower sequence number. \n\n#### Attestation Signatures\n\nMetadata entries MAY have attestations `signatures` associated with them, in the form of an array of objects. Attestation signatures are indeed annotated. An annotated signature for a message is an object with of a `publicKey`, and a `signature` of a specified message (see below) by the corresponding private key.\n\n> <sub>░ note ░</sub> \n> \n> When we say “signature” in the rest of this document we mean “annotated signature”.\n\nAn attestation signature for an entry is a signature of the entry message:\n\n```js\nhash(\n  hash(CBOR(subject)) + \n  hash(CBOR(name)) + \n  hash(CBOR(value)) + \n  hash(CBOR(sequenceNumber))\n)\n```\n\nwhere `+` designates the concatenation of two bytestrings and `CBOR` designates a function which encodes its input into binary according to [RFC-8949](https://www.rfc-editor.org/rfc/rfc8949). That is, JSON strings are encoded as major type 3, JSON integers as major types 0 or 1, JSON floats as major type 7, JSON arrays as major type 4, JSON objects as major type 5, JSON booleans as major type 7 and JSON null as major type 7; according to the specification.\n\nFor example, the attestation message for the example entry above is:\n\n```js\nhash(\n  hash(0x75613534303864306462306439343266643830333734) +  // text \"a5408d0db0d942fd80374\"\n  hash(0x67636F6E74616374) +                              // text \"contact\"\n  hash(0x6A436964204B72616D6572) +                        // text \"Cid Kramer\"\n  hash(0x00)                                              // uint 0\n)\n// cd731afcc904c521e0c6b3cc0b560b8157ee29c3e41cd15f8dc8984edf600029\n```\n\nThe `publicKey` and the `signature` MUST be base16-encoded and stored as JSON strings. All signatures must be verifiable through the **Ed25519 digital signature** scheme and public keys must therefore be 32-byte long Ed25519 public keys. \n\n\n### Well-known Properties\n\nThe following properties are considered well-known, and the JSON in their values MUST have the given structure and semantic interpretation. New properties can be added to this list by amending this CIP. The role of well-known properties is to facilitate integration between applications implementing this CIP. Nevertheless, registries are encouraged to **not** restrict properties to only this limited set but, registries (or metadata servers) MUST verify the well-formedness of those properties when present in a metadata object.\n\n<details>\n  <summary><code>preimage</code></summary>\n\n```json\n{ \n    \"type\": \"object\", \n    \"description\": \"A hashing algorithm identifier and a base16-enocoded bytestring, such that the bytestring is the preimage of the metadata subject under that hash function.\",\n    \"requiredProperties\": [ \"alg\", \"msg\" ],\n    \"properties\": { \n        \"alg\": { \n            \"type\": \"string\", \n            \"description\": \"A hashing algorithm identifier. The length of the digest is given by the subject.\", \n            \"enum\": [ \"sha1\", \"sha\", \"sha3\", \"blake2b\", \"blake2s\", \"keccak\", \"md5\" ] \n        }, \n        \"msg\": { \n            \"type\": \"string\", \n            \"description\": \"The actual preimage.\",\n            \"encoding\": \"base16\"\n        }\n    }\n}\n```\n</details>\n\n\n<details>\n  <summary><code>name</code></summary>\n\n```json\n{\n    \"type\": \"string\",\n    \"description\": \"A human-readable name for the metadata subject, suitable for use in an interface or in running text.\",\n    \"maxLength\": 50,\n    \"minLength\": 1\n}\n```\n</details>\n\n\n<details>\n  <summary><code>description</code></summary>\n\n```json\n{\n    \"type\": \"string\",\n    \"description\": \"A longer description of the metadata subject, suitable for use when inspecting the metadata subject itself.\",\n    \"maxLength\": 500\n}\n```\n</details>\n\n<details>\n  <summary><code>ticker</code></summary>\n\n```json\n{\n  \"type\": \"string\",\n  \"description\": \"A short identifier for the metadata subject, suitable to show in listings or tiles.\",\n  \"maxLength\": 9,\n  \"minLength\": 2\n}\n```\n</details>\n\n<details>\n  <summary><code>decimals</code></summary>\n\n```json\n{\n  \"type\": \"integer\",\n  \"description\": \"When the metadata subject refers to a monetary policy, refers to the number of decimals of the currency.\",\n  \"minimum\": 0,\n  \"maximum\": 19\n},\n```\n</details>\n\n<details>\n  <summary><code>url</code></summary>\n\n```json\n{\n    \"type\": \"string\",\n    \"description\": \"A universal resource identifier pointing to additional information about the metadata subject.\",\n    \"format\": \"uri\",\n    \"maxLength\": 250\n}\n```\n</details>\n\n<details>\n  <summary><code>logo</code></summary>\n\n```json\n{\n  \"type\": \"string\",\n  \"description\": \"An `image/png` object which is 64KB in size at most.\",\n  \"encoding\": \"base64\",\n  \"maxLength\": 87400\n}\n```\n</details>\n\n### Verifying Metadata \n\n#### General Case\n\nApplications that want to display token metadata MUST verify signatures of metadata entries against a set of trusted keys for certain subjects. We will call such applications _\"clients\"_. Conceptually we expect clients to maintain a mapping of many subjects to many verification keys. In case where a metadata entry contains no signatures, when none of the provided signatures was produced by a known key for the corresponding subject or when none of the provided signatures verifies: the metadata entry MUST be considered invalid and not be presented to end-users.\n\nNote that:\n\n- In this scenario, a single valid signature is sufficient to consider a metadata entry valid but there can be many signatures (invalid or valid). So long as one is valid, the entry is considered verified.\n\n- The verification is done per _entry_. That is, a metadata object may contain both verified and unverified entries. Plus, entries under the same subject may be verified by different keys. \n\nThe way by which the trusted keys are registered into clients is unspecified although we already consider the following, **non-overlapping**, **complementary**, options:\n\n1. Clients MAY explicitly prompt the consumer / end-user about whether to accept a certain entry. While this is unpractical for some cases (e.g. token metadata), it may be relevant for some.\n\n1. Clients MAY come with a set of pre-configured well-known trusted keys chosen at the discretion of the application editor. \n\n2. End-users SHOULD have the ability to add/remove keys from their trusted set. This allows end-users to introduce trusted keys they know before they end up in the pre-configured set (which likely follow the application release cycle). In this context, keys are advertised by the signing authority by some means, for instance, on social media or on another form of public key registry (e.g. [keybase.io](http://keybase.io/))\n\n3. Mappings of subjects to keys MAY be recorded on-chain, using transaction metadata and an appropriate label registered on [CIP-0010]. In some scenarios, the context within which the transaction is signed may be enough to reliably trust the legitimacy of a mapping. For example, in the case of a monetary policy, one could imagine _registering trusted keys_ in the same transaction minting tokens. Because the transaction is inserted in the ledger, it must have been signed by the token issuer and therefore, the specified keys are without doubt acknowledged by the token issuer. As a result, clients having access to on-chain data can automatically discover new mappings from observing the chain. \n\n#### Special Case: Phase-1 Monetary Policies\n\n> <sub>░ note ░</sub> \n> \n> This approach is now considered superseded by the more general approach. While it has some nice properties, new applications should consider sticking to the general case **even for phase-1 monetary policies**. Servers who seek backward-compatibility should implement both. \n\nWe consider the case of phase-1 monetary policies introduced during the Allegra era of Cardano. Such policies are identified by a simple (native) script which is validated by the ledger during the so-called phase-1 validations. Such scripts are made of key hashes, combined via a set of basic first-order logic primitives (ALL, ANY-OF, N-OF...) such that, it is possible to statically verify whether a set of signatures would validate the script. \n\nThese scripts therefore make relatively good verification mechanisms for metadata associated with phase-1 monetary policies. Hence, we introduce the following well-known property:\n\n<details>\n  <summary><code>policy</code></summary>\n\n```json\n{ \n  \"type\": \"string\",\n  \"description\": \"A CBOR-serialized phase-1 monetary policy, used as a pre-image to produce a policyId.\",\n  \"encoding\": \"base16\",\n  \"minLength\": 56,\n  \"maxLength\": 120\n}\n```\n</details>\n\n<br/>\n\nMetadata objects that contain an extra top-level property `policy` MUST therefore abide by the following rules:\n\n1. Their subject MUST be an `assetId`, encoded in base16; where the `assetId` is the concatenation of a `policyId` (28 bytes) and an `assetName` (up to 32 bytes). \n2. The `policy` MUST therefore re-hash (through blake2b-224) into the first 28 bytes of the metadata's subject (the policy id).\n3. Every metadata entry MUST have a set of signatures such that, the monetary script given in policy can be validated using the provided signatures, irrespective of the time constraints. Said differently, the public keys from the annotated signature must re-hash into key hashes present in the policy AND each key must verify its associated signature AND the provided signatures must\nbe sufficient to validate the monetary script according to the semantic given by the cardano ledger without considering the time constraints.\n\nFor example, consider the following phase-1 monetary policy, represented in JSON:\n\n```json\n{\n    \"type\": \"all\",\n    \"scripts\": [\n        {\n            \"keyHash\": \"2B0C33E73D2A70733EDC971D19E2CAFBADA1692DB2D35E7DC9453DF2\",\n            \"type\": \"sig\"\n        },\n        {\n            \"keyHash\": \"E2CAFBADA1692DB2D35E7DC9453DF22B0C33E73D2A70733EDC971D19\",\n            \"type\": \"sig\"\n        }\n    ]\n}\n```\n\nTo validate such a policy, each entry would require 2 signatures: \n\n- from `2B0C33E73D2A70733EDC971D19E2CAFBADA1692DB2D35E7DC9453DF2`\n- and from `E2CAFBADA1692DB2D35E7DC9453DF22B0C33E73D2A70733EDC971D19`\n\nThe policy MAY also contain some additional time constraints (VALID-AFTER, VALID-BEFORE) specifying a certain slot number. For the sake of verifying policies, these should be ignored and consider _valid_. \n\n### Recommendations For Metadata Servers\n\nThe following section gives some recommendations to application developers willing to implement a metadata server / registry. Following these recommendations will facilitate interoperability between applications and also, provide some good security foundation for the server. In this context, what we refer to as a _metadata server_ is a web server that exposes the functionality of a simple key-value store, where the keys are metadata subjects and property names, and the values are their property values.\n\n##### Querying Metadata\n\nThe metadata server SHOULD implement the following HTTP methods:\n\n```\nGET /metadata/{subject}/property/{property name}\n```\n\nThis SHOULD return the property values for the given property name (if any) associated with the subject. This is returned as a array of JSON objects whose key is the property name and return the complete JSON entries for that subject+name (including `value`, `sequenceNumber` and `signatures`).\n\nThe metadata server SHOULD set the Content-Length header to allow clients to decide if they wish to download sizeable metadata.\n\n```\nGET /metadata/{subject}/properties\n```\n\nThis SHOULD return all the property names which are available for that subject (if any). These are returned as a JSON list of strings.\n\n```\nGET /metadata/{subject}\n```\n\nThis SHOULD return a array of the full metadata objects associated with this subject, including the subject and all properties associated with it. \n\n```\nPOST /metadata/query\nREQUEST BODY : a JSON object with the keys:\n  “subjects” : A list of subjects, encoded as strings in the same way as the queries above.\n  “properties” : An optional list of property names, encoded as strings in the same way as the query above.\n```\n\nThis endpoint provides a way to batch queries, making several requests of the server with only one HTTP request.\n\nIf only `“subjects”` is supplied, this query SHOULD return a list of subjects with all their properties. The response format will be as similar as possible to the `GET /metadata/{subject}` request, but nested inside a list.\n\nIf `“subjects”` and `“properties”` are supplied, the query will return a list of subjects, with their properties narrowed down to only those specified by `“properties”`.\n\n> <sub>░ suggestion ░</sub> \n>\n> Metadata servers MAY provide other methods of querying metadata, such as:\n> \n> * Searching for all mappings whose “name” property value is a particular string\n> * Searching for all metadata items which are signed by a particular cryptographic key, or uploaded by a particular user\n\n##### Modifying metadata\n\nThe metadata server needs some way to add and modify metadata entries. The method for doing so is largely up to the implementor, but recommend to abide by the following rules:\n\n1. The server MUST only accept updates for metadata entries that have a higher sequence number than the previous entry.\n1. The server MUST always verify well-formedness of metadata entries before accepting them.\n1. The server MUST always cryptographically verify metadata entries' signatures before accepting them.\n1. The server MAY reject entries with no signatures. \n1. The server MAY support the POST, PUT, and DELETE verbs to modify metadata entries.\n\n##### Authentication\n\nIf the server supports modifications to metadata entries, it SHOULD provide some form of authentication which controls who can modify them. Servers MUST NOT use the attestation signatures on metadata entries as part of authentication (with the exception of phase-1 monetary policy). Attestation signatures are per-entry, and are orthogonal to determining who controls the metadata for a subject.\n\nSimple systems may want to use little more than cryptographic signatures, but more sophisticated systems could have registered user accounts and control access in that way.\n\n##### Audit\n\nThe metadata server MAY provide a mechanism auditing changes to metadata, for example by storing the update history of an entry and allowing users to query it (via the API or otherwise).\n\n#### Hardening\n\nAllowing unrestricted updates to non-verifiable metadata would allow malicious users to “squat” or take over another user’s metadata subjects. This is why we recommend that server implementations have some kind of authentication system to mitigate this.\n\nOne approach is to have a system of “ownership” of metadata subjects. This notion of ownership is vague, although in some cases there are obvious choices (e.g. for a multisig minting policy, the obvious owners are the signatories who can authorize minting). It is up to the server to pick a policy for how to decide on owners, and enforce security; or indeed to take a different approach entirely. \n\nSee the earlier “Authentication” section for a description of a possible approach to managing ownership.\n\nDepending on the authentication mechanism they use, servers may also need to worry about replay attacks, where an attacker submits a (correctly signed) old record to “revert” a legitimate change.  However, these can be unconditionally prevented by correctly implementing sequence numbers as described earlier, which prevents old entries from being accepted.\n\n### Recommendations For Metadata Clients\n\nSimilar to the recommendations for metadata servers, this section gives some recommendations to application developers willing to implement a metadata client. Following these recommendations will facilitate interoperability between applications and also, provide some good security foundation for the clients. A metadata client refers to the component that communicates with a metadata server and maintains the user’s trusted metadata mapping. This may be implemented as part of a larger system, or may be an independent component (which could be shared between multiple other systems, e.g. a wallet frontend and a blockchain explorer).\n\n- The metadata client MUST allow the metadata server (or servers) that it references to be configured by the end-user.\n- The metadata client MUST maintain a local mapping of trusted keys and metadata entries.\n- The metadata client MUST only accept updates with a higher sequence number than the entry it currently has.\n- The metadata client MUST always verify well-formedness or metadata entries before accepting them.\n- The metadata client MUST always verify any signatures on metadata entries before accepting them.\n- The metadata client SHOULD allow browsing of its trusted keys.\n- The metadata client SHOULD allow modifications of its trusted keys by the end-user.\n- The metadata client SHOULD use a Trust On First Use (TOFU) strategy for updating this store. When an update is requested for a metadata entry, the client should query the server, but not trust the resulting metadata entry unless the user agrees to use it (either by explicit consent, or implicitly via the set of trusted keys). If the entry is trusted, it should be copied to the local store.\n- The metadata client MAY be configurable to limit the amount downloaded.\n- The metadata client MAY accept user updates for metadata entries.\n\n## Rationale: how does this CIP achieve its goals?\n\n### Interfaces and progressive enhancement\n\nThe design space for a metadata server is quite large. For example, any of the following examples could work, or other combinations of these features:\n\n- A single centralized server maintained by the Cardano Foundation, and updated by emailing the administrator (no user-facing front end website)\n- An open-source federation of servers with key-based authentication.\n- A commercial server with an account-based system, a web-frontend, and a payments system for storage.\n\nThis design aims to be agnostic about the details of the implementation, by specifying only a very simple interface between the client, server, and system-component users (wallet, etc.). This allows:\n- Progressive enhancement of servers over time. Initially servers may provide a very bare-bones implementation, but this can be improved later.\n- Competition between multiple implementations, including from third parties.\n\n### Decentralization\n\nFor much of the metadata we are concerned with there is no “right” answer. The metadata server is thus playing a key trusted role - even if that trust is partial because users can rely on attestation signatures. We therefore believe that it is critical that we allow users to choose which metadata server (or servers) they refer to.\n\nAn analogy is with DNS nameservers: these are a trusted piece of infrastructure for any particular user, but users have a choice of which nameservers to use, and can use multiple.\n\nThis also makes it possible for these servers to be a true piece of community infrastructure, rather than something wedded to a major player (although we hope that the Cardano Foundation and IOHK will produce a competitive offering).\n\n### Verifiable vs non-verifiable metadata\n\nA key distinction is between metadata that is verifiably correct and that which is non-verifiable.\n\nThe key example of verifiable metadata is hashe pre-images. Where the metadata subject is a hash, the preimage of that hash is verifiable metadata, since we can simply hash it and check that it matches. This covers several cases that we are interested in:\n\n- Mapping script hashes to the script\n- Mapping public key hashes to the public key\n\nHowever, most metadata is non-verifiable:\n\n- Human-readable names for scripts are not verifiable: there is no “right” answer to what the name of a script is.\n- Many scripts do not have an obvious “owner” (certainly this is true for Plutus scripts), but even for those which do (e.g. phase-1 monetary scripts) this does not mean that the owner is trusted! See the “Security” section below for more discussion on trust.\n- Any associations with authors, websites, icons, etc are similarly non-verifiable as there is no basis for establishing trust.\n\n### Security\n\nMost of the security considerations relate to non-verifiable metadata. Verifiable metadata can generally always be accepted as is (provided that it is verified). Our threat model is that non-verifiable metadata may always have been provided by an attacker.\n\nAccepting non-verifiable metadata blindly can lead to attacks. For example, a malicious server or user might attempt to name their currency “Ada”. If we blindly accept this and overwrite the existing mapping for “Ada”, this would lead to easy phishing attacks. The approach we take is heavily inspired by petname systems, GPG keyservers, and local address books. The user always has a local mapping which is trusted, and then adding to or updating that mapping requires explicit user consent, unless we can prove that this is trustworthy (i.e. the metadata is verifiable).\n\nHow can users decide whether to trust an update? This is where the attestation signatures come into play. If a user trusts the entity which signs the metadata record, that may be sufficient for them to accept it as a legitimate update. \n\nClients could also be tricked into downloading large amounts of metadata that the user does not want. For this reason clients should expose some kind of configurable download limiting, and we suggest that the server set the Content-Length header to support this. However, this problem is no worse than that faced by the average web browser, so we do not think it will be a problem in practice.\n\nClients also need to worry about replay attacks, where they are sent old (correctly signed) records in an attempt to “roll back” a legitimate update. The easiest way to avoid this is to correctly implement sequence numbers, in which case old updates will be rejected.\n\n### Data storage location\n\nThis design needs to store a fair amount of data in a shared location. We might wonder whether we should use the blockchain for this: we could store metadata updates in transaction metadata.\n\nHowever, storing this information on-chain does not actually help us:\n\n- The trust model for metadata is different than that of the ledger and transactions. The only trust we have (and can expect to have) in the metadata is that it is signed by a particular key, regardless of the purpose or nature of the data. E.g. when posting a script, there is no explicit association between the script and the signing key other than the owner of the key choosing to post it\n- The metadata is precisely that: metadata. While it is about the chain, it does not directly affect ledger state transitions and therefore we should not require it to be associated with a specific transaction.\n\nBesides, on-chain storage comes with considerable downsides:\n\n- Higher cost to users for modifications and storage\n- Increases in the UTXO size\n- Awkwardness of querying the data\n- Size limits on transaction metadata\n\nFor this reason, we think that a traditional database is a much better fit. However, it would be perfectly possible for someone to produce an implementation that was backed by the chain if they believed that that could be competitive.\n\n### Storage cost\n\nMetadata may potentially be sizable. For example, preimages of hashes can in principle be any size!\n\nServers will want some way to manage this to avoid abuse. However, this is a typical problem faced by web services and can be solved in the usual ways: size limits per account, charging for storage, etc.\n\n### Backwards compatibility\n\nSee [Special Case: Phase-1 Monetary Policies](#special-case--phase--1-monetary-policies) which covers existing implementations. \n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Document commercial or community implementations of any of the use cases described above.\n  - [cardano-token-registry](https://github.com/cardano-foundation/cardano-token-registry)\n\n### Implementation Plan\n\n- [x] Provide a reference implementation: [Off-chain metadata tools](https://github.com/input-output-hk/offchain-metadata-tools)\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[schema.json]: https://raw.githubusercontent.com/cardano-foundation/CIPs/master/CIP-0026/schema.json\n[CIP-0010]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010\n"
  },
  {
    "path": "CIP-0026/schema.json",
    "content": "{ \"title\": \"Cardano Off-Chain Metadata\"\n, \"$schema\": \"https://json-schema.org/draft-07/schema\"\n, \"required\":\n  [ \"subject\"\n  ]\n, \"additionalProperties\": { \"$ref\": \"#/definitions/entry\" }\n, \"properties\":\n  { \"subject\":\n    { \"type\": \"string\"\n    , \"description\": \"The subject, a namespace for multiple metadata entries, typically a hash digest.\"\n    , \"minLength\": 1\n    , \"maxLength\": 255\n    }\n  , \"policy\":\n    { \"type\": \"string\"\n    , \"description\": \"A CBOR-serialized phase-1 monetary policy, used as a pre-image to produce a policyId.\"\n    , \"encoding\": \"base16\"\n    , \"minLength\": 56\n    , \"maxLength\": 120\n    }\n  , \"preimage\":\n    { \"type\": \"object\"\n    , \"description\": \"A hashing algorithm identifier and a base16-enocoded bytestring, such that the bytestring is the preimage of the metadata subject under that hash function.\"\n    , \"requiredProperties\": [ \"alg\", \"msg\" ]\n    , \"properties\":\n      { \"alg\":\n          { \"type\": \"string\"\n          , \"description\": \"A hashing algorithm identifier. The length of the digest is given by the subject.\"\n          , \"enum\":\n            [ \"sha1\", \"sha\", \"sha3\", \"blake2b\", \"blake2s\", \"keccak\", \"md5\" ]\n          }\n      , \"msg\":\n        { \"type\": \"string\"\n        , \"description\": \"The actual preimage.\"\n        , \"encoding\": \"base16\"\n        }\n      }\n    }\n  , \"name\":\n    { \"type\": \"string\"\n    , \"description\": \"A human-readable name for the metadata subject, suitable for use in an interface or in running text.\"\n    , \"maxLength\": 50\n    , \"minLength\": 1\n    }\n  , \"description\":\n    { \"type\": \"string\"\n    , \"description\": \"A longer description of the metadata subject, suitable for use when inspecting the metadata subject itself.\"\n    , \"maxLength\": 500\n    }\n  , \"ticker\":\n    { \"type\": \"string\"\n    , \"description\": \"A short identifier for the metadata subject, suitable to show in listings or tiles.\"\n    , \"maxLength\": 9\n    , \"minLength\": 2\n    }\n  , \"decimals\":\n    { \"type\": \"integer\"\n    , \"description\": \"When the metadata subject refers to a monetary policy, refers to the number of decimals of the currency.\"\n    , \"minimum\": 1\n    , \"maximum\": 19\n    }\n  , \"url\":\n    { \"type\": \"string\"\n    , \"description\": \"A universal resource identifier pointing to additional information about the metadata subject.\"\n    , \"format\": \"uri\"\n    , \"maxLength\": 250\n    }\n  , \"logo\":\n    { \"type\": \"string\"\n    , \"description\": \"A `image/png` object which is 64KB in size at most.\"\n    , \"encoding\": \"base64\"\n    , \"maxLength\": 87400\n    }\n  }\n, \"definitions\":\n  { \"entry\":\n    { \"type\": \"object\"\n    , \"additionalProperties\": false\n    , \"required\":\n      [ \"value\"\n      , \"sequenceNumber\"\n      , \"signatures\"\n      ]\n    , \"properties\":\n      { \"value\": {}\n      , \"sequenceNumber\": { \"$ref\": \"#/definitions/sequenceNumber\" }\n      , \"signatures\": { \"$ref\": \"#/definitions/signatures\" }\n      }\n    }\n  , \"sequenceNumber\":\n    { \"type\": \"integer\"\n    , \"minimum\": 0\n    }\n  , \"signatures\":\n    { \"type\": \"array\"\n    , \"items\":\n      { \"type\": \"object\"\n      , \"additionalProperties\": false\n      , \"required\":\n        [ \"publicKey\"\n        , \"signature\"\n        ]\n      , \"properties\":\n        { \"publicKey\":\n          { \"type\": \"string\"\n          , \"description\": \"An Ed25519 Public key, verifying the companion signature.\"\n          , \"encoding\": \"base16\"\n          , \"minLength\": 64\n          , \"maxLength\": 64\n          }\n        , \"signature\":\n          { \"type\": \"string\"\n          , \"description\": \"A signed attestation.\"\n          , \"encoding\": \"base16\"\n          , \"minLength\": 128\n          , \"maxLength\": 128\n          }\n        }\n    }\n    }\n  }\n}\n\n\n"
  },
  {
    "path": "CIP-0027/CIP-0027.md",
    "content": "Moved to [CIP-0027/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0027/README.md",
    "content": "---\nCIP: 27\nTitle: CNFT Community Royalties Standard\nStatus: Active\nCategory: Tokens\nAuthors:\n  - Huth S0lo <john@digitalsyndicate.io>\n  - TheRealAdamDean <adam@crypto2099.io>\nImplementors: N/A\nDiscussions:\n  - https://forum.cardano.org/t/cip-royalties/68599\n  - https://github.com/cardano-foundation/CIPs/pull/116\nCreated: 2021-08-29\nLicense: Apache-2.0\n---\n\n## Abstract\n\nThis proposed standard will allow for uniform royalties' distributions across the secondary market space. It is easy to implement using metadata only, and does not require a smart contract.  However, it is scalable to allow for the usage of a downstream smart contract, as needed by the asset creator.\n\n## Motivation: why is this CIP necessary?\n\nThere is a significant interest within the Cardano Community for an implementation of royalties distribution when a Cardano Asset is resold on the secondary market. It has become a common theme to see and hear statements that the only thing stopping artists from adopting Cardano, is that they are waiting for an implementation of royalties.\n\nAt the present time, smart contracts do not create a simple mechanism to implement royalties.  By developing a community standard, we can resolve the immediate need for royalties, and create a path forward for a potential future iteration of smart contracts.\n\n## Specification\n\nA new tag of 777 is proposed for this implementation.  The community guidelines have been agreed as follows:\n1) A brand new unused policy for implementation is required.\n2) The royalties tags are to be written to an unnamed token, using the policy to be used for the intended Cardano Assets.\n3) Only the first minted set of instructions will be honored.  Any future updates or rewrites will be ignored.  This prevents a Cardano Asset maker from changing the royalties at a future date.\n4) Within this created asset will be the metadata for royalties distributions.  It will use a tag of 777, and then have two tags to identify the percentage of future sales requested as a royalty, and the payment address to forward those royalties to.  Those tags will be \"rate\" and \"addr\" respectively.\n5) The \"rate\" key tag can be any floating point value from 0.0 to 1.0, to represent between 0 and 100 percent.  For example, a 12.5 percent royalty would be represented with \"rate\": \"0.125\".  Previous version 1.0 of this proposal used pct instead of rate.  Marketplaces to continue to honor legacy pct tag.\n6) The \"addr\" key tag can be a string value, or an array.  It is to include a single payment address.  By allowing for an array, the payment address can exceed the per line 64 character limitation.  This payment address could be part of a smart contract, which should allow for greater flexibility of royalties distributions, controlled by the asset creator.\n7) The royalty token must be minted prior to creating any assets off the policy.  All markets will be instructed to look only for the first minted asset on a policy, which would need to be the unnamed 777 token.\n\n### Example JSON with string\n\n{\n\t\"777\": {\n\t\t\"rate\": \"0.2\",\n\t\t\"addr\": \"addr1v9nevxg9wunfck0gt7hpxuy0elnqygglme3u6l3nn5q5gnq5dc9un\"\n\t}\n}\n\n### Example JSON with array\n\n{\n\t\"777\": {\n\t\t\"rate\": \"0.2\",\n\t\t\"addr\": [\n\t\t\t\"addr1q8g3dv6ptkgsafh7k5muggrvfde2szzmc2mqkcxpxn7c63l9znc9e3xa82h\",\n\t\t\t\"pf39scc37tcu9ggy0l89gy2f9r2lf7husfvu8wh\"\n\t\t]\n\t}\n}\n\n### Process Flow\n\n1) Create policy for planned assets.\n2) Mint no name token with community standard royalties metadata.\n3) Burn no name token to free up UTxO (recommended, but not required).\n4) Mint planned assets using this same policy.\n\n## Rationale: how does this CIP achieve its goals?\n\nBy creating a new tag for the distinct purpose of royalties distributions, Cardano Asset makers, and Marketplaces can uniformly apply royalties to assets with predictable results.\n\nBy creating the instructions on a single, no name token, all marketplaces will know the correct location of the royalties asset, without having to further locate it.\n\nBy enforcing the requirement of honoring only the first mint, cardano asset buyers and owners can predict the future resale value of the assets in their possession.\n\nThe solution is scalable to any desired royalty percentage.  It is easy to work with this new standard, and does not require an in depth understanding of smart contracts.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Support of royalty distribution according to this standard by multiple significant NFT related platforms.\n- [x] Implementation in libraries supporting NFT minting, including:\n  - [x] Mesh ([Minting Royalty Token](https://meshjs.dev/apis/transaction/minting#mintingRoyaltyToken))\n\n### Implementation Plan\n\n- [x] Incorporate input from many Cardano NFT related entities, including:\n  - [x] Artano\n  - [x] BuffyBot\n  - [x] CNFT.io\n  - [x] Digital Syndicate\n  - [x] Fencemaker\n  - [x] MADinArt\n  - [x] NFT-Maker.io\n  - [x] Hydrun\n  - [x] Tokhun\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0028/README.md",
    "content": "---\nCIP: 28\nTitle: Protocol Parameters (Alonzo Era)\nStatus: Active\nCategory: Ledger\nAuthors:\n  - Kevin Hammond <kevin.hammond@iohk.io>\nImplementors:\n  - IOG\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/140\nCreated: 2021-10-14\nLicense: Apache-2.0\n---\n\n## Abstract\n\nThis CIP extends CIP-0009 to include the new protocol parameters that have been introduced for Alonzo, specifically those relating to the costing of Plutus scripts.  It describes the initial settings for those parameters.\n\n## Motivation: why is this CIP necessary?\n\nWe need to document the chain of changes to the protocol parameters.  This document describes precisely the changes that have been made from CIP-0009, allowing the differences to be determined.  It thus supplements rather than replaces CIP-0009.\n\n## Specification\n\n### New Updatable Protocol Parameters\n\nThe new **updatable** protocol parameter values for Alonzo are given below (in JSON format).  Any of these parameters may be changed by submitting\na parameter update proposal to the chain, and without triggering a \"hard fork\".  Note that these parameters are given using the names used\nin the genesis file.  Be aware that some parameters are shown differently using ``cardano-cli query protocol-parameters`` -- this has been raised\nas an issue with the development team.\n\n```\n{\n    \"lovelacePerUTxOWord\": 34482,\n    \"executionPrices\": {\n        \"prSteps\":\n\t{\n\t    \"numerator\" :   721,\n\t    \"denominator\" : 10000000\n\t\t},\n        \"prMem\":\n\t{\n\t    \"numerator\" :   577,\n\t    \"denominator\" : 10000\n\t}\n    },\n    \"maxTxExUnits\": {\n        \"exUnitsMem\":   10000000,\n        \"exUnitsSteps\": 10000000000\n    },\n    \"maxBlockExUnits\": {\n        \"exUnitsMem\":   50000000,\n        \"exUnitsSteps\": 40000000000\n    },\n    \"maxValueSize\": 5000,\n    \"collateralPercentage\": 150,\n    \"maxCollateralInputs\": 3,\n    \"costModels\": {\n        \"PlutusV1\": {\n            \"sha2_256-memory-arguments\": 4,\n            \"equalsString-cpu-arguments-constant\": 1000,\n            \"cekDelayCost-exBudgetMemory\": 100,\n            \"lessThanEqualsByteString-cpu-arguments-intercept\": 103599,\n            \"divideInteger-memory-arguments-minimum\": 1,\n            \"appendByteString-cpu-arguments-slope\": 621,\n            \"blake2b-cpu-arguments-slope\": 29175,\n            \"iData-cpu-arguments\": 150000,\n            \"encodeUtf8-cpu-arguments-slope\": 1000,\n            \"unBData-cpu-arguments\": 150000,\n            \"multiplyInteger-cpu-arguments-intercept\": 61516,\n            \"cekConstCost-exBudgetMemory\": 100,\n            \"nullList-cpu-arguments\": 150000,\n            \"equalsString-cpu-arguments-intercept\": 150000,\n            \"trace-cpu-arguments\": 150000,\n            \"mkNilData-memory-arguments\": 32,\n            \"lengthOfByteString-cpu-arguments\": 150000,\n            \"cekBuiltinCost-exBudgetCPU\": 29773,\n            \"bData-cpu-arguments\": 150000,\n            \"subtractInteger-cpu-arguments-slope\": 0,\n            \"unIData-cpu-arguments\": 150000,\n            \"consByteString-memory-arguments-intercept\": 0,\n            \"divideInteger-memory-arguments-slope\": 1,\n            \"divideInteger-cpu-arguments-model-arguments-slope\": 118,\n            \"listData-cpu-arguments\": 150000,\n            \"headList-cpu-arguments\": 150000,\n            \"chooseData-memory-arguments\": 32,\n            \"equalsInteger-cpu-arguments-intercept\": 136542,\n            \"sha3_256-cpu-arguments-slope\": 82363,\n            \"sliceByteString-cpu-arguments-slope\": 5000,\n            \"unMapData-cpu-arguments\": 150000,\n            \"lessThanInteger-cpu-arguments-intercept\": 179690,\n            \"mkCons-cpu-arguments\": 150000,\n            \"appendString-memory-arguments-intercept\": 0,\n            \"modInteger-cpu-arguments-model-arguments-slope\": 118,\n            \"ifThenElse-cpu-arguments\": 1,\n            \"mkNilPairData-cpu-arguments\": 150000,\n            \"lessThanEqualsInteger-cpu-arguments-intercept\": 145276,\n            \"addInteger-memory-arguments-slope\": 1,\n            \"chooseList-memory-arguments\": 32,\n            \"constrData-memory-arguments\": 32,\n            \"decodeUtf8-cpu-arguments-intercept\": 150000,\n            \"equalsData-memory-arguments\": 1,\n            \"subtractInteger-memory-arguments-slope\": 1,\n            \"appendByteString-memory-arguments-intercept\": 0,\n            \"lengthOfByteString-memory-arguments\": 4,\n            \"headList-memory-arguments\": 32,\n            \"listData-memory-arguments\": 32,\n            \"consByteString-cpu-arguments-intercept\": 150000,\n            \"unIData-memory-arguments\": 32,\n            \"remainderInteger-memory-arguments-minimum\": 1,\n            \"bData-memory-arguments\": 32,\n            \"lessThanByteString-cpu-arguments-slope\": 248,\n            \"encodeUtf8-memory-arguments-intercept\": 0,\n            \"cekStartupCost-exBudgetCPU\": 100,\n            \"multiplyInteger-memory-arguments-intercept\": 0,\n            \"unListData-memory-arguments\": 32,\n            \"remainderInteger-cpu-arguments-model-arguments-slope\": 118,\n            \"cekVarCost-exBudgetCPU\": 29773,\n            \"remainderInteger-memory-arguments-slope\": 1,\n            \"cekForceCost-exBudgetCPU\": 29773,\n            \"sha2_256-cpu-arguments-slope\": 29175,\n            \"equalsInteger-memory-arguments\": 1,\n            \"indexByteString-memory-arguments\": 1,\n            \"addInteger-memory-arguments-intercept\": 1,\n            \"chooseUnit-cpu-arguments\": 150000,\n            \"sndPair-cpu-arguments\": 150000,\n            \"cekLamCost-exBudgetCPU\": 29773,\n            \"fstPair-cpu-arguments\": 150000,\n            \"quotientInteger-memory-arguments-minimum\": 1,\n            \"decodeUtf8-cpu-arguments-slope\": 1000,\n            \"lessThanInteger-memory-arguments\": 1,\n            \"lessThanEqualsInteger-cpu-arguments-slope\": 1366,\n            \"fstPair-memory-arguments\": 32,\n            \"modInteger-memory-arguments-intercept\": 0,\n            \"unConstrData-cpu-arguments\": 150000,\n            \"lessThanEqualsInteger-memory-arguments\": 1,\n            \"chooseUnit-memory-arguments\": 32,\n            \"sndPair-memory-arguments\": 32,\n            \"addInteger-cpu-arguments-intercept\": 197209,\n            \"decodeUtf8-memory-arguments-slope\": 8,\n            \"equalsData-cpu-arguments-intercept\": 150000,\n            \"mapData-cpu-arguments\": 150000,\n            \"mkPairData-cpu-arguments\": 150000,\n            \"quotientInteger-cpu-arguments-constant\": 148000,\n            \"consByteString-memory-arguments-slope\": 1,\n            \"cekVarCost-exBudgetMemory\": 100,\n            \"indexByteString-cpu-arguments\": 150000,\n            \"unListData-cpu-arguments\": 150000,\n            \"equalsInteger-cpu-arguments-slope\": 1326,\n            \"cekStartupCost-exBudgetMemory\": 100,\n            \"subtractInteger-cpu-arguments-intercept\": 197209,\n            \"divideInteger-cpu-arguments-model-arguments-intercept\": 425507,\n            \"divideInteger-memory-arguments-intercept\": 0,\n            \"cekForceCost-exBudgetMemory\": 100,\n            \"blake2b-cpu-arguments-intercept\": 2477736,\n            \"remainderInteger-cpu-arguments-constant\": 148000,\n            \"tailList-cpu-arguments\": 150000,\n            \"encodeUtf8-cpu-arguments-intercept\": 150000,\n            \"equalsString-cpu-arguments-slope\": 1000,\n            \"lessThanByteString-memory-arguments\": 1,\n            \"multiplyInteger-cpu-arguments-slope\": 11218,\n            \"appendByteString-cpu-arguments-intercept\": 396231,\n            \"lessThanEqualsByteString-cpu-arguments-slope\": 248,\n            \"modInteger-memory-arguments-slope\": 1,\n            \"addInteger-cpu-arguments-slope\": 0,\n            \"equalsData-cpu-arguments-slope\": 10000,\n            \"decodeUtf8-memory-arguments-intercept\": 0,\n            \"chooseList-cpu-arguments\": 150000,\n            \"constrData-cpu-arguments\": 150000,\n            \"equalsByteString-memory-arguments\": 1,\n            \"cekApplyCost-exBudgetCPU\": 29773,\n            \"quotientInteger-memory-arguments-slope\": 1,\n            \"verifySignature-cpu-arguments-intercept\": 3345831,\n            \"unMapData-memory-arguments\": 32,\n            \"mkCons-memory-arguments\": 32,\n            \"sliceByteString-memory-arguments-slope\": 1,\n            \"sha3_256-memory-arguments\": 4,\n            \"ifThenElse-memory-arguments\": 1,\n            \"mkNilPairData-memory-arguments\": 32,\n            \"equalsByteString-cpu-arguments-slope\": 247,\n            \"appendString-cpu-arguments-intercept\": 150000,\n            \"quotientInteger-cpu-arguments-model-arguments-slope\": 118,\n            \"cekApplyCost-exBudgetMemory\": 100,\n            \"equalsString-memory-arguments\": 1,\n            \"multiplyInteger-memory-arguments-slope\": 1,\n            \"cekBuiltinCost-exBudgetMemory\": 100,\n            \"remainderInteger-memory-arguments-intercept\": 0,\n            \"sha2_256-cpu-arguments-intercept\": 2477736,\n            \"remainderInteger-cpu-arguments-model-arguments-intercept\": 425507,\n            \"lessThanEqualsByteString-memory-arguments\": 1,\n            \"tailList-memory-arguments\": 32,\n            \"mkNilData-cpu-arguments\": 150000,\n            \"chooseData-cpu-arguments\": 150000,\n            \"unBData-memory-arguments\": 32,\n            \"blake2b-memory-arguments\": 4,\n            \"iData-memory-arguments\": 32,\n            \"nullList-memory-arguments\": 32,\n            \"cekDelayCost-exBudgetCPU\": 29773,\n            \"subtractInteger-memory-arguments-intercept\": 1,\n            \"lessThanByteString-cpu-arguments-intercept\": 103599,\n            \"consByteString-cpu-arguments-slope\": 1000,\n            \"appendByteString-memory-arguments-slope\": 1,\n            \"trace-memory-arguments\": 32,\n            \"divideInteger-cpu-arguments-constant\": 148000,\n            \"cekConstCost-exBudgetCPU\": 29773,\n            \"encodeUtf8-memory-arguments-slope\": 8,\n            \"quotientInteger-cpu-arguments-model-arguments-intercept\": 425507,\n            \"mapData-memory-arguments\": 32,\n            \"appendString-cpu-arguments-slope\": 1000,\n            \"modInteger-cpu-arguments-constant\": 148000,\n            \"verifySignature-cpu-arguments-slope\": 1,\n            \"unConstrData-memory-arguments\": 32,\n            \"quotientInteger-memory-arguments-intercept\": 0,\n            \"equalsByteString-cpu-arguments-constant\": 150000,\n            \"sliceByteString-memory-arguments-intercept\": 0,\n            \"mkPairData-memory-arguments\": 32,\n            \"equalsByteString-cpu-arguments-intercept\": 112536,\n            \"appendString-memory-arguments-slope\": 1,\n            \"lessThanInteger-cpu-arguments-slope\": 497,\n            \"modInteger-cpu-arguments-model-arguments-intercept\": 425507,\n            \"modInteger-memory-arguments-minimum\": 1,\n            \"sha3_256-cpu-arguments-intercept\": 0,\n            \"verifySignature-memory-arguments\": 1,\n            \"cekLamCost-exBudgetMemory\": 100,\n            \"sliceByteString-cpu-arguments-intercept\": 150000\n        }\n    }\n}\n```\n\nThe meaning of the fields is:\n\n| Field                 \t| Initial Value                                                          \t| Description                                                                                                                                                                                                                      \t|\n|-----------------------\t|------------------------------------------------------------------------\t|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\t|\n| lovelacePerUTxOWord       \t| 34482 \t| Deposit charged per word of UTxO storage.  |\n| executionPrices | `{ \"prSteps\": { \"numerator\" : 721, \"denominator\" : 10000000}, \"prMem\": { \"numerator\" :   577, \"denominator\" : 10000 } }` | Fee per Plutus execution step and per memory unit |\n| maxTxExUnits | `{ \"exUnitsMem\":   10000000,        \"exUnitsSteps\": 10000000000 }` | Maximum number of memory units and steps in a single transaction. |\n| maxBlockExUnits | `{ \"exUnitsMem\":   50000000, \"exUnitsSteps\": 40000000000 }` | Maximum number of memory units and steps in a single block. |\n| maxValueSize | 5000 | The limit on the serialized size of the Value in each output. |\n| collateralPercentage | 150 | Percentage of fee that is used as collateral for a failed transaction. |\n| maxCollateralInputs | 3 | Maximum number of collateral inputs in a transaction. |\n| costModels | `{  \"PlutusV1\": { ... } }` | Detailed cost models for each Plutus version. |\n\nEach version of the Plutus interpreter may use different cost model parameters and settings.  Although the parameters are updatable,\nthey are likely to be changed only when introducing new Plutus interpreter versions at a \"hard fork\".\nFor simplicity, the details of the parameter settings is omitted here.\n\n### Obsoleted Updatable Protocol Parameters\n\n``minUTxOValue`` is no longer used.  It is replaced by ``lovelacePerUTxOWord``.\n\n### Non-Updatable Parameters\n\nThere are no changes to the non-updatable protocol parameters.\n\n## Rationale: how does this CIP achieve its goals?\n\nThe majority of the parameters are needed to enable the use of Plutus scripts on-chain.  They relate to the fees calculations for\ntransactions that include Plutus scripts.\n\n``executionPrices`` are specified in fractions of lovelace per Plutus CPU execution step or memory unit.\nThese have been set to be consistent with the cost for a full transaction.\n\n``lovelacePerUTxOWord`` replaces ``minUTxOValue``.\nRather than determining a fixed minimum deposit, the new value scales each word that is used.\nThe value is set to give a very similar result for an ada-only UTxO entry (previously, 1,000,000 lovelace; now 999,978 lovelace, since each ada-only\nUTxO entry is 29 words).\n\n``collateralPercentage``has been chosen to be higher than the transaction fee.  Collateral should only be used to pay fees if a user has deliberately\nsubmitted a transaction that is known to fail.  Setting the percentage high acts to discourage the submission of rogue transactions, which\nmaliciously consume chain resources.\n\n``maxCollateralInputs`` has been set to allow the option of multiple inputs to be used to pay collateral, if needed (e.g. so that\nmultiple instance of a transaction can be submitted without sharing a single collateral, that might restrict concurrency or cause\nscript failure if the collateral was not available).\n\n``maxValueSize`` has been set based on benchmarking.\n\n``costModels`` has been set for ``PlutusV1`` based on benchmarking inputs.  Each Plutus Core primitive has associated costs.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] The Alonzo ledger era is activated.\n- [x] Documented parameters have been in operational use by Cardano Node and Ledger as of the Alonzo ledger era.\n\n### Implementation Plan\n\n- [x] Alonzo ledger era parameters are deemed correct by working groups at IOG.\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0).\n"
  },
  {
    "path": "CIP-0029/CIP-0029.md",
    "content": "Moved to [CIP-0029/README.md](./README.md).\n"
  },
  {
    "path": "CIP-0029/README.md",
    "content": "---\nCIP: 29\nTitle: Phase-1 Monetary Scripts Serialization Formats\nStatus: Active\nCategory: Tools\nAuthors:\n  - Matthias Benkort <matthias.benkort@iohk.io>\nImplementors:\n  - IOG\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/117\nCreated: 2020-08-17\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis specification describes how to serialize Phase-1 monetary scripts (a.k.a. _\"native scripts\"_) to various formats (JSON, CBOR) to facilitate inter-operability between applications.\n\n## Motivation: why is this CIP necessary?\n\nWhile the existence of scripts is well-known, and have an unambiguous on-chain representation. There's no agreed upon format for off-chain or higher-level interfaces for which a binary string is a poor fit. This CIP regroups both the on-chain binary format and other, more verbose, formats like JSON.\n\n## Specification\n\nThis specification covers at present two serialization formats: JSON and CBOR. The CBOR matches exactly the on-chain representation and is extracted from the cardano-ledger-specs source code and put here as a convenient place to lookup while the source can change location over time.\n\n### CBOR\n\nThe CBOR serialization format is given as a [CDDL specification in annexe](./phase-1-monetary-scripts.cddl). When a hash of the phase-1 monetary script is needed, it usually refers to a Blake2b-192 digest of the corresponding serialized script byte-string prefixed with a null byte: `\\x00`.\n\n### JSON\n\nThe JSON format is given as a [JSON schema in annexe](./phase-1-monetary-scripts.json). It is preferred in user interfaces such as command-lines or APIs, where some level of human inspection may be required.\n\n### Notes\n\n- Scripts may contain unbounded integers! Implementation parsing them, either from CBOR or JSON shall be prepared to handle possible big integers (>= 2^64).\n\n### Test Vectors\n\n```yaml\n- json:\n    { \"type\": \"sig\"\n    , \"keyHash\": \"00000000000000000000000000000000000000000000000000000000\"\n    }\n  cbor:\n    \"8200581c00000000000000000000000000000000000000000000000000000000\"\n    \n- json:\n    { \"type\": \"all\"\n    , \"scripts\":\n      [ { \"type\": \"sig\"\n        , \"keyHash\": \"00000000000000000000000000000000000000000000000000000000\"\n        }\n      , { \"type\": \"any\"\n        , \"scripts\":\n          [ { \"type\": \"after\"\n            , \"slot\": 42\n            }\n          , { \"type\": \"sig\"\n            , \"keyHash\": \"00000000000000000000000000000000000000000000000000000001\"\n            }\n          ]\n        }\n      ]\n    }\n  cbor:\n    \"8201828200581c000000000000000000000000000000000000000000000000000000008202828204182a8200581c00000000000000000000000000000000000000000000000000000001\"\n\n- json:\n    { \"type\": \"before\"\n    , \"slot\": 42\n    }\n  cbor:\n    \"8205182a\"\n\n- json:\n    { \"type\": \"atLeast\"\n    , \"required\": 2\n    , \"scripts\":\n      [ { \"type\": \"sig\", \"keyHash\": \"00000000000000000000000000000000000000000000000000000000\" }\n      , { \"type\": \"sig\", \"keyHash\": \"00000000000000000000000000000000000000000000000000000001\" }\n      , { \"type\": \"sig\", \"keyHash\": \"00000000000000000000000000000000000000000000000000000002\" }\n      ]\n    }\n  cbor:\n    \"00830302838200581c000000000000000000000000000000000000000000000000000000008200581c000000000000000000000000000000000000000000000000000000018200581c00000000000000000000000000000000000000000000000000000002\"\n```\n\n## Rationale: how does this CIP achieve its goals?\n\n- The preimage for computing script hashes is prefixed with `\\x00` to distinguish them from phase-2 monetary scripts (a.k.a Plutus Script) which are then prefixed with `\\x01`. This is merely a discriminator tag.\n\n- The current JSON format is based off the cardano-cli's format which has been used widely for minting tokens and is likely the most widely accepted format at the moment.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] There exist official software releases supporting this serialization format:\n  - [x] [cardano-cli](https://github.com/IntersectMBO/cardano-cli)\n  - [x] [cardano-api](https://github.com/IntersectMBO/cardano-api)\n\n### Implementation Plan\n\n  - [x] Incorporating this serialization format into Cardano software libraries and command line tools.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0029/phase-1-monetary-scripts.cddl",
    "content": "script =\n  [  script_key\n  // script_all\n  // script_any\n  // script_n_of_k\n  // script_after\n  // script_before\n  ]\n\nscript_key =\n  (0, keyhash)\n\nscript_all =\n  (1, [ * script ])\n\nscript_any =\n  (2, [ * script ])\n\nscript_n_of_k =\n  (3, n: uint, [ * script ])\n\n; Timelock validity intervals are half-open intervals [a, b).\n; This field specifies the left (included) endpoint a.\nscript_after =\n  (4, uint)\n\n; Timelock validity intervals are half-open intervals [a, b).\n; This field specifies the right (excluded) endpoint b.\nscript_before =\n  (5, uint)\n\nkeyhash =\n  bytes .size 28\n"
  },
  {
    "path": "CIP-0029/phase-1-monetary-scripts.json",
    "content": "{ \"$schema\": \"<https://json-schema.org/draft-07/schema>\"\n, \"title\": \"Phase-1 Monetary Scripts\"\n, \"oneOf\":\n    [ { \"$ref\": \"#/definitions/Script@keyHash\" }\n    , { \"$ref\": \"#/definitions/Script@after\" }\n    , { \"$ref\": \"#/definitions/Script@before\" }\n    , { \"$ref\": \"#/definitions/Script@any\" }\n    , { \"$ref\": \"#/definitions/Script@all\" }\n    , { \"$ref\": \"#/definitions/Script@atLeast\" }\n    ]\n, \"definitions\":\n    { \"Script@keyHash\":\n        { \"type\": \"object\"\n        , \"additionalProperties\": false\n        , \"required\": [ \"type\", \"keyHash\" ]\n        , \"properties\":\n            { \"type\":\n                { \"type\": \"string\"\n                , \"enum\": [ \"sig\" ]\n                }\n            , \"keyHash\":\n                { \"type\": \"string\"\n                , \"encoding\": \"base16\"\n                , \"minLength\": 56\n                , \"maxLength\": 56\n                }\n            }\n        }\n    , \"Script@before\":\n        { \"type\": \"object\"\n        , \"additionalProperties\": false\n        , \"required\": [ \"type\", \"slot\" ]\n        , \"properties\":\n            { \"type\":\n                { \"type\": \"string\"\n                , \"enum\": [ \"before\" ]\n                }\n            , \"slot\":\n                { \"type\": \"integer\"\n                , \"minimum\": 1\n                }\n            }\n        }\n    , \"Script@after\":\n        { \"type\": \"object\"\n        , \"additionalProperties\": false\n        , \"required\": [ \"type\", \"slot\" ]\n        , \"properties\":\n            { \"type\":\n                { \"type\": \"string\"\n                , \"enum\": [ \"after\" ]\n                }\n            , \"slot\":\n                { \"type\": \"integer\"\n                , \"minimum\": 1\n                }\n            }\n        }\n    , \"Script@any\":\n        { \"type\": \"object\"\n        , \"additionalProperties\": false\n        , \"required\": [ \"type\", \"scripts\" ]\n        , \"properties\":\n            { \"type\":\n                { \"type\": \"string\"\n                , \"enum\": [ \"any\" ]\n                }\n            , \"scripts\":\n              { \"type\": \"array\"\n              , \"items\": { \"$ref\": \"#\" }\n              }\n            }\n        }\n    , \"Script@all\":\n        { \"type\": \"object\"\n        , \"additionalProperties\": false\n        , \"required\": [ \"type\", \"scripts\" ]\n        , \"properties\":\n            { \"type\":\n                { \"type\": \"string\"\n                , \"enum\": [ \"all\" ]\n                }\n            , \"scripts\":\n              { \"type\": \"array\"\n              , \"items\": { \"$ref\": \"#\" }\n              }\n            }\n        }\n    , \"Script@atLeast\":\n        { \"type\": \"object\"\n        , \"additionalProperties\": false\n        , \"required\": [ \"type\", \"required\", \"scripts\" ]\n        , \"properties\":\n            { \"type\":\n                { \"type\": \"string\"\n                , \"enum\": [ \"atLeast\" ]\n                }\n            , \"required\":\n                { \"type\": \"integer\"\n                , \"minimum\": 0\n                }\n            , \"scripts\":\n              { \"type\": \"array\"\n              , \"items\": { \"$ref\": \"#\" }\n              }\n            }\n        }\n    }\n}\n"
  },
  {
    "path": "CIP-0030/README.md",
    "content": "---\nCIP: 30\nTitle: Cardano dApp-Wallet Web Bridge\nStatus: Active\nCategory: Wallets\nAuthors:\n  - rooooooooob\nImplementors:\n  - Begin <https://begin.is/>\n  - Eternl <https://eternl.io/>\n  - Flint <https://flint-wallet.com/>\n  - GeroWallet <https://www.gerowallet.io/>\n  - Lace <https://www.lace.io/>\n  - Nami <https://namiwallet.io/>\n  - NuFi <https://nu.fi/>\n  - RayWallet <https://raywallet.io/>\n  - Yoroi <https://yoroi-wallet.com/>\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/88\n  - https://github.com/cardano-foundation/CIPs/pull/148\n  - https://github.com/cardano-foundation/CIPs/pull/151\n  - https://github.com/cardano-foundation/CIPs/pull/183\n  - https://github.com/cardano-foundation/CIPs/pull/208\n  - https://github.com/cardano-foundation/CIPs/pull/323\n  - https://github.com/cardano-foundation/CIPs/issues/169\n  - https://github.com/cardano-foundation/CIPs/issues/178\n  - https://github.com/cardano-foundation/CIPs/issues/204\n  - https://github.com/cardano-foundation/CIPs/issues/253\n  - https://github.com/cardano-foundation/CIPs/issues/386\n  - https://github.com/cardano-foundation/CIPs/issues/404\n  - https://github.com/cardano-foundation/CIPs/issues/419\n  - https://github.com/cardano-foundation/CIPs/pull/446\nCreated: 2021-04-29\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis documents describes a webpage-based communication bridge allowing webpages (i.e. dApps) to interface with Cardano wallets. This is done via injected javascript code into webpages. This specification defines the manner that such code is to be accessed by the webpage/dApp, as well as defining the API for dApps to communicate with the user's wallet. This document currently concerns the Shelley-Mary era but will have a second version once Plutus is supported. This specification is intended to cover similar use cases as web3 for Ethereum or [EIP-0012](https://github.com/ergoplatform/eips/pull/23) for Ergo. The design of this spec was based on the latter.\n\n## Motivation: why is this CIP necessary?\n\nIn order to facilitate future dApp development, we will need a way for dApps to communicate with the user's wallet. While Cardano does not yet support smart contracts, there are still various use cases for this, such as NFT management. This will also lay the groundwork for an updated version of the spec once the Alonzo hardfork is released which can extend it to allow for Plutus support.\n\n## Specification\n\n### Data Types\n\n#### Address\n\nA string representing an address in either bech32 format, or hex-encoded bytes. All return types containing `Address` must return the hex-encoded bytes format, but must accept either format for inputs.\n\n#### Bytes\n\nA hex-encoded string of the corresponding bytes.\n\n#### `cbor<T>`\n\nA hex-encoded string representing [CBOR](https://tools.ietf.org/html/rfc7049) corresponding to `T` defined via [CDDL](https://tools.ietf.org/html/rfc8610) either inside of the [Shelley Multi-asset binary spec](https://github.com/input-output-hk/cardano-ledger-specs/blob/0738804155245062f05e2f355fadd1d16f04cd56/shelley-ma/shelley-ma-test/cddl-files/shelley-ma.cddl) or, if not present there, from the [CIP-0008 signing spec](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0008/README.md).\nThis representation was chosen when possible as it is consistent across the Cardano ecosystem and widely used by other tools, such as [cardano-serialization-lib](https://github.com/Emurgo/cardano-serialization-lib), which has support to encode every type in the binary spec as CBOR bytes.\n\n#### DataSignature\n\n```ts\ntype DataSignature = {|\n  signature: cbor<COSE_Sign1>,\n  key: cbor<COSE_Key>,\n|};\n```\n\n#### TransactionUnspentOutput\n\nIf we have CBOR specified by the following CDDL referencing the Shelley-MA CDDL:\n\n```cddl\ntransaction_unspent_output = [\n  input: transaction_input,\n  output: transaction_output,\n]\n```\n\nthen we define\n\n```ts\ntype TransactionUnspentOutput = cbor<transaction_unspent_output>\n```\n\nThis allows us to use the output for constructing new transactions using it as an output as the `transaction_output` in the Shelley Multi-asset CDDL does not contain enough information on its own to spend it.\n\n#### Paginate\n\n```ts\ntype Paginate = {|\n  page: number,\n  limit: number,\n|};\n```\nUsed to specify optional pagination for some API calls. Limits results to {limit} each page, and uses a 0-indexing {page} to refer to which of those pages of {limit} items each. dApps should be aware that if a wallet is modified between paginated calls that this will change the pagination, e.g. some results skipped or showing up multiple times but otherwise the wallet must respect the pagination order.\n\n#### Extension\n\nAn extension is an object with a single field `\"cip\"` that describes a CIP number extending the API (as a plain integer, without padding). For example:\n\n```ts\n{ \"cip\": 30 }\n```\n\n### Error Types\n\n#### APIError\n\n```ts\nAPIErrorCode {\n\tInvalidRequest: -1,\n\tInternalError: -2,\n\tRefused: -3,\n\tAccountChange: -4,\n}\nAPIError {\n\tcode: APIErrorCode,\n\tinfo: string\n}\n```\n\n* InvalidRequest - Inputs do not conform to this spec or are otherwise invalid.\n* InternalError - An error occurred during execution of this API call.\n* Refused - The request was refused due to lack of access - e.g. wallet disconnects.\n* AccountChange - The account has changed. The dApp should call `wallet.enable()` to reestablish connection to the new account. The wallet should not ask for confirmation as the user was the one who initiated the account change in the first place.\n\n#### DataSignError\n\n```ts\nDataSignErrorCode {\n\tProofGeneration: 1,\n\tAddressNotPK: 2,\n\tUserDeclined: 3,\n}\ntype DataSignError = {\n\tcode: DataSignErrorCode,\n\tinfo: String\n}\n```\n\n* ProofGeneration - Wallet could not sign the data (e.g. does not have the secret key associated with the address)\n* AddressNotPK - Address was not a P2PK address and thus had no SK associated with it.\n* UserDeclined - User declined to sign the data\n\n#### PaginateError\n\n```ts\ntype PaginateError = {|\n    maxSize: number,\n|};\n```\n{maxSize} is the maximum size for pagination and if the dApp tries to request pages outside of this boundary this error is thrown.\n\n#### TxSendError\n\n```ts\nTxSendErrorCode = {\n\tRefused: 1,\n\tFailure: 2,\n}\ntype TxSendError = {\n\tcode: TxSendErrorCode,\n\tinfo: String\n}\n```\n\n* Refused - Wallet refuses to send the tx (could be rate limiting)\n* Failure - Wallet could not send the tx\n\n#### TxSignError\n\n```ts\nTxSignErrorCode = {\n\tProofGeneration: 1,\n\tUserDeclined: 2,\n}\ntype TxSignError = {\n\tcode: TxSignErrorCode,\n\tinfo: String\n}\n```\n\n* ProofGeneration - User has accepted the transaction sign, but the wallet was unable to sign the transaction (e.g. not having some of the private keys)\n* UserDeclined - User declined to sign the transaction\n\n### Initial API\n\nIn order to initiate communication from webpages to a user's Cardano wallet, the wallet must provide the following javascript API to the webpage. A shared, namespaced `cardano` object must be injected into the page if it did not exist already. Each wallet implementing this standard must then create a field in this object with a name unique to each wallet containing a `wallet` object with the following methods. The API is split into two stages to maintain the user's privacy, as the user will have to consent to `cardano.{walletName}.enable()` in order for the dApp to read any information pertaining to the user's wallet with `{walletName}` corresponding to the wallet's namespaced name of its choice.\n\n#### `cardano.{walletName}.enable({ extensions: Extension[] } = {}): Promise<API>`\n\nErrors: `APIError`\n\nThis is the entrypoint to start communication with the user's wallet. The wallet should request the user's permission to connect the web page to the user's wallet, and if permission has been granted, the full API will be returned to the dApp to use. The wallet can choose to maintain a whitelist to not necessarily ask the user's permission every time access is requested, but this behavior is up to the wallet and should be transparent to web pages using this API. If a wallet is already connected this function should not request access a second time, and instead just return the `API` object.\n\nUpon start, dApp can explicitly request a list of additional functionalities they expect as a list of CIP numbers capturing those extensions. This is used as an extensibility mechanism to document what functionalities can be provided by the wallet interface. CIP-0030 provides a set of base interfaces that every wallet must support. Then, new functionalities are introduced via additional CIPs and may be all or partially supported by wallets.\n\nDApps are expected to use this endpoint to perform an initial handshake and ensure that the wallet supports all their required functionalities. Note that it's possible for two extensions to be mutually incompatible (because they provide two conflicting features). While we may try to avoid this as much as possible while designing CIPs, it is also the responsability of wallet providers to assess whether they can support a given combination of extensions, or not. Hence wallets aren't expected to fail should they not recognize or not support a particular combination of extensions. Instead, they should decide what they enable and reflect their choice in the response to `api.getExtensions()` in the Full API. As a result, dApps may fail and inform their users or may use a different, less-efficient, strategy to cope with a lack of functionality.\n\nIt is at the extension author's discretion if they wish to separate their endpoints from the base API via namespacing. Although, it is highly recommend that authors do namespace all of their extensions. If namespaced, endpoints must be preceded by `.cipXXXX.` from the `API` object, without any leading zeros.\n\nFor example; CIP-0123's endpoints should be accessed by:\n```ts\napi.cip123.endpoint1()\napi.cip123.endpoint2()\n```\n\nFor list of accepted CIP-30 extensions please see [CIP-30 Accepted Extensions Register](./extensions-register.md).\n\nAuthors should be careful when omitting namespacing. Omission should only be considered when creating endpoints to override those defined in this specification or other extensions. Even so when overriding; the new functionality should not prevent dApps from accessing past functionality thus overriding must ensure backwards compatibility.\n\nAny namespace omission needs to be fully justified via the proposal's Rationale section, with explanation to why it is necessary. Any potential backwards compatibility considerations should be noted to give wallets and dApps a clear unambiguous direction.\n\n##### Draft or Experimental Extensions\n\nExtensions that are draft, in development, or prototyped should not use extension naming nor should they use official namspacing until assigned a CIP number. Draft extension authors are free to test their implementation endpoints by using the [Experimental API](#experimental-api). Once a CIP number is assigned implementors should move functionality out of the experimental API.\n\n##### Can extensions depend on other extensions?\n\nYes. Extensions may have other extensions as pre-requisite. Some newer extensions may also invalidate functionality introduced by earlier extensions. There's no particular rule or constraints in that regards. Extensions are specified as CIP, and will define what it entails to enable them.\n\n##### Should extensions follow a specific format?\n\nYes. They all are CIPs.\n\n##### Can extensions add their own endpoints and/or error codes?\n\nYes. Extensions may introduce new endpoints or error codes, and modify existing ones. Although, it is recommended that endpoints are namespaced. Extensions may even change the rules outlined in this very proposal. The idea being that wallet providers should start off implementing this CIP, and then walk their way to implementing their chosen extensions.\n\n##### Are wallet expected to implement all extensions?\n\nNo. It's up to wallet providers to decide which extensions they ought to support.\n\n\n#### `cardano.{walletName}.isEnabled(): Promise<bool>`\n\nErrors: `APIError`\n\nReturns true if the dApp is already connected to the user's wallet, or if requesting access would return true without user confirmation (e.g. the dApp is whitelisted), and false otherwise. If this function returns true, then any subsequent calls to `wallet.enable()` during the current session should succeed and return the `API` object.\n\n#### `cardano.{walletName}.apiVersion: String`\n\nThe version number of the API that the wallet supports. Set to `1`.\n\n#### `cardano.{walletName}.supportedExtensions: Extension[]`\n\nA list of extensions supported by the wallet. Extensions may be requested by dApps on initialization. Some extensions may be mutually conflicting and this list does not thereby reflect what extensions will be enabled by the wallet. Yet it informs on what extensions are known and can be requested by dApps if needed.\n\n#### `cardano.{walletName}.name: String`\n\nA name for the wallet which can be used inside of the dApp for the purpose of asking the user which wallet they would like to connect with.\n\n#### `cardano.{walletName}.icon: String`\n\nA URI image (e.g. data URI base64 or other) for img src for the wallet which can be used inside of the dApp for the purpose of asking the user which wallet they would like to connect with.\n\n### Full API\n\nUpon successful connection via `cardano.{walletName}.enable()`, a javascript object we will refer to as `API` (type) / `api` (instance) is returned to the dApp with the following methods. All read-only methods (all but the signing functionality) should not require any user interaction as the user has already consented to the dApp reading information about the wallet's state when they agreed to `cardano.{walletName}.enable()`. The remaining methods `api.signTx()` and `api.signData()` must request the user's consent in an informative way for each and every API call in order to maintain security.\n\nThe API chosen here is for the minimum API necessary for dApp <-> Wallet interactions without convenience functions that don't strictly need the wallet's state to work. The API here is for now also only designed for Shelley's Mary hardfork and thus has NFT support. When Alonzo is released with Plutus support this API will have to be extended.\n\n#### `api.getExtensions(): Promise<Extension[]>`\n\nErrors: `APIError`\n\nRetrieves the list of extensions enabled by the wallet. This may be influenced by the set of extensions requested in the initial `enable` request.\n\n#### `api.getNetworkId(): Promise<number>`\n\nErrors: `APIError`\n\nReturns the network id of the currently connected account. 0 is testnet and 1 is mainnet but other networks can possibly be returned by wallets. Those other network ID values are not governed by this document. This result will stay the same unless the connected account has changed.\n\n#### `api.getUtxos(amount: cbor<value> = undefined, paginate: Paginate = undefined): Promise<TransactionUnspentOutput[] | null>`\n\nErrors: `APIError`, `PaginateError`\n\nIf `amount` is `undefined`, this shall return a list of all UTXOs (unspent transaction outputs) controlled by the wallet. If `amount` is not `undefined`, this request shall be limited to just the UTXOs that are required to reach the combined ADA/multiasset value target specified in `amount`, and if this cannot be attained, `null` shall be returned. The results can be further paginated by `paginate` if it is not `undefined`.\n\n#### (DEPRECATED) `api.getCollateral(params: { amount: cbor<Coin> }): Promise<TransactionUnspentOutput[] | null>`\n\nErrors: `APIError`\n\n##### DEPRECATION NOTICE\n\nSince [CIP-0040 | Collateral Output](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0040/README.md) and Babbage era \"Collateral Return\" and \"Total Collateral\" fields on a transaction body are supported, a transaction can now use up to three **any** collateral inputs and specify the collateral return outputs to receive extra ada and tokens back as change. Transaction-building SDKs and libraries now all support this functionality as well (see [Blaze](https://blaze.butane.dev/), [Mesh](https://meshjs.dev/), [Lucid Evolution](https://anastasia-labs.github.io/lucid-evolution/), [CSL](https://github.com/Emurgo/cardano-serialization-lib)). The dedicated transaction fields and strong tooling support removes the **need** for dedicated cumbersome API for providing *special* collateral inputs to exist.\n\nDApps should make effort to build transactions using the latest available best methods and practices. In this case it means always utilising collateral return and not risking burning UTxOs with no return. Wallets looking to implement this standard are free to **not** support this deprecated API function, which does require some extra special management of UTxOs within the wallet, beyond normal logic.\n\nDeprecating this method aims to motivate DApp implementors not to use this method, but rather to use newer better techniques.\n\nAny future versions of \"wallet-to-dapp\" APIs seeking to replace CIP30 should **not ever** include any methods of this kind. This mistake of history should be forgotten forever.\n\n##### Description\n\nThe function takes a required object with parameters. With a single **required** parameter for now: `amount`. (**NOTE:** some wallets may be ignoring the amount parameter, in which case it might be possible to call the function without it, but this behavior is not recommended!). Reasons why the `amount` parameter is required:\n1. Dapps must be motivated to understand what they are doing with the collateral, in case they decide to handle it manually.\n2. Depending on the specific wallet implementation, requesting more collateral than necessarily might worsen the user experience with that dapp, requiring the wallet to make explicit wallet reorganisation when it is not necessary and can be avoided.\n3. If dapps don't understand how much collateral they actually need to make their transactions work - they are placing more user funds than necessary in risk.\n\nSo requiring the `amount` parameter would be a by-spec behavior for a wallet. Not requiring it is possible, but not specified, so dapps should not rely on that and the behavior is not recommended.\n\nThis shall return a list of one or more UTXOs (unspent transaction outputs) controlled by the wallet that are required to reach **AT LEAST** the combined ADA value target specified in `amount` **AND** the best suitable to be used as collateral inputs for transactions with plutus script inputs (pure ADA-only utxos). If this cannot be attained, an error message with an explanation of the blocking problem shall be returned. **NOTE:** wallets are free to return utxos that add up to a **greater** total ADA value than requested in the `amount` parameter, but wallets must never return any result where utxos would sum up to a smaller total ADA value, instead in a case like that an error message must be returned.\n\nThe main point is to allow the wallet to encapsulate all the logic required to handle, maintain, and create (possibly on-demand) the UTXOs suitable for collateral inputs. For example, whenever attempting to create a plutus-input transaction the dapp might encounter a case when the set of all user UTXOs don't have any pure entries at all, which are required for the collateral, in which case the dapp itself is forced to try and handle the creation of the suitable entries by itself. If a wallet implements this function it allows the dapp to not care whether the suitable utxos exist among all utxos, or whether they have been stored in a separate address chain (see https://github.com/cardano-foundation/CIPs/pull/104), or whether they have to be created at the moment on-demand - the wallet guarantees that the dapp will receive enough utxos to cover the requested amount, or get an error in case it is technically impossible to get collateral in the wallet (e.g. user does not have enough ADA at all).\n\nThe `amount` parameter is required, specified as a `string` (BigNumber) or a `number`, and the maximum allowed value must be agreed to be something like 5 ADA. Not limiting the maximum possible value might force the wallet to attempt to purify an unreasonable amount of ADA just because the dapp is doing something weird. Since by protocol the required collateral amount is always a percentage of the transaction fee, it seems that the 5 ADA limit should be enough for the foreseeable future.\n\n#### `api.getBalance(): Promise<cbor<value>>`\n\nErrors: `APIError`\n\nReturns the total balance available of the wallet. This is the same as summing the results of `api.getUtxos()`, but it is both useful to dApps and likely already maintained by the implementing wallet in a more efficient manner so it has been included in the API as well.\n\n#### `api.getUsedAddresses(paginate: Paginate = undefined): Promise<Address[]>`\n\nErrors: `APIError`\n\nReturns a list of all used (included in some on-chain transaction) addresses controlled by the wallet. The results can be further paginated by `paginate` if it is not `undefined`.\n\n#### `api.getUnusedAddresses(): Promise<Address[]>`\n\nErrors: `APIError`\n\nReturns a list of unused addresses controlled by the wallet.\n\n#### `api.getChangeAddress(): Promise<Address>`\n\nErrors: `APIError`\n\nReturns an address owned by the wallet that should be used as a change address to return leftover assets during transaction creation back to the connected wallet. This can be used as a generic receive address as well.\n\n#### `api.getRewardAddresses(): Promise<Address[]>`\n\nErrors: `APIError`\n\nReturns the reward addresses owned by the wallet. This can return multiple addresses e.g. CIP-0018.\n\n#### `api.signTx(tx: cbor<transaction>, partialSign: bool = false): Promise<cbor<transaction_witness_set>>`\n\nErrors: `APIError`, `TxSignError`\n\nRequests that a user sign the unsigned portions of the supplied transaction. The wallet should ask the user for permission, and if given, try to sign the supplied body and return a signed transaction. If `partialSign` is true, the wallet only tries to sign what it can. If `partialSign` is false and the wallet could not sign the entire transaction, `TxSignError` shall be returned with the `ProofGeneration` code. Likewise if the user declined in either case it shall return the `UserDeclined` code. Only the portions of the witness set that were signed as a result of this call are returned to encourage dApps to verify the contents returned by this endpoint while building the final transaction.\n\n#### `api.signData(addr: Address, payload: Bytes): Promise<DataSignature>`\n\nErrors: `APIError`, `DataSignError`\n\nThis endpoint utilizes the [CIP-0008 signing spec](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0008/README.md) for standardization/safety reasons. It allows the dApp to request the user to sign a payload conforming to said spec. The user's consent should be requested and the message to sign shown to the user. The payment key from `addr` will be used for base, enterprise and pointer addresses to determine the EdDSA25519 key used. The staking key will be used for reward addresses. This key will be used to sign the `COSE_Sign1`'s `Sig_structure` with the following headers set:\n\n* `alg` (1) - must be set to `EdDSA` (-8)\n* `kid` (4) - Optional, if present must be set to the same value as in the `COSE_key` specified below. It is recommended to be set to the same value as in the `\"address\"` header.\n* `\"address\"` - must be set to the raw binary bytes of the address as per the binary spec, without the CBOR binary wrapper tag\n\nThe payload is not hashed and no `external_aad` is used.\n\nIf the payment key for `addr` is not a P2Pk address then `DataSignError` will be returned with code `AddressNotPK`. `ProofGeneration` shall be returned if the wallet cannot generate a signature (i.e. the wallet does not own the requested payment private key), and `UserDeclined` will be returned if the user refuses the request. The return shall be a `DataSignature` with `signature` set to the hex-encoded CBOR bytes of the `COSE_Sign1` object specified above and `key` shall be the hex-encoded CBOR bytes of a `COSE_Key` structure with the following headers set:\n\n* `kty` (1) - must be set to `OKP` (1)\n* `kid` (2) - Optional, if present must be set to the same value as in the `COSE_Sign1` specified above.\n* `alg` (3) - must be set to `EdDSA` (-8)\n* `crv` (-1) - must be set to `Ed25519` (6)\n* `x` (-2) - must be set to the public key bytes of the key used to sign the `Sig_structure`\n\n#### `api.submitTx(tx: cbor<transaction>): Promise<hash32>`\n\nErrors: `APIError`, `TxSendError`\n\nAs wallets should already have this ability, we allow dApps to request that a transaction be sent through it. If the wallet accepts the transaction and tries to send it, it shall return the transaction id for the dApp to track. The wallet is free to return the `TxSendError` with code `Refused` if they do not wish to send it, or `Failure` if there was an error in sending it (e.g. preliminary checks failed on signatures).\n\n### Experimental API\n\nMultiple experimental namespaces are used:\n- under `api` (ex: `api.experimental.myFunctionality`).\n- under `cardano.{walletName}` (ex: `window.cardano.{walletName}.experimental.myFunctionality`)\n\nThe benefits of this are:\n1. Wallets can add non-standardized features while still following the CIP30 structure\n1. dApp developers can use these functions explicitly knowing they are experimental (not stable or standardized)\n1. New features can be added to CIP30 as experimental features and only moved to non-experimental once multiple wallets implement it\n1. It provides a clear path to updating the CIP version number (when functions move from experimental -> stable)\n\n## Rationale: how does this CIP achieve its goals?\n\nSee justification and explanations provided with each API endpoint.\n\n### Extensions\n\nExtensions provide an extensibility mechanism and a way to negotiate (possibly conflicting) functionality between a DApp and a wallet provider. There's rules enforced as for what extensions a wallet decide to support or enable. The current mechanism only gives a way for wallets to communicate their choice back to a DApp.\n\nWe use object as extensions for now to leave room for adding fields in the future without breaking all existing interfaces. At this point in time however, objects are expected to be singleton.\n\nExtensions can be seen as a smart versioning scheme. Except that, instead of being a monotonically increasing sequence of numbers, they are multi-dimensional feature set that can be toggled on and off at will. This is a versioning \"à-la-carte\" which is useful in a context where:\n\n1. There are multiple concurrent standardization efforts on different fronts to accommodate a rapidly evolving ecosystem;\n2. Not everyone agrees and has desired to support every existing standard;\n3. There's a need from an API consumer standpoint to clearly identify what features are supported by providers.\n\n#### Namespacing Extensions\n\nBy encouraging the explicit namespacing of each extension we aim to improve the usability of extensions for dApps. By allowing special cases where namespacing can be dropped we maintain good flexibility in extension design.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] The interface is implemented and supported by various wallet providers. See also: [cardano-caniuse](https://www.cardano-caniuse.io/).\n- [x] The interface is used by DApps to interact with wallet providers. Few examples:\n  - https://www.jpg.store/\n  - https://app.minswap.org/\n  - https://muesliswap.com/\n  - https://exchange.sundaeswap.finance/\n  - https://app.indigoprotocol.io/\n\n### Implementation Plan\n\n- [x] Provide some reference implementation of wallet providers\n  - [Berry-Pool/nami-wallet](https://github.com/berry-pool/nami/blob/4d7539b2768464480a9cff53a2d66af9879f8534/src/pages/Content/injected.js)\n  - [Emurgo/yoroi-wallet](https://github.com/Emurgo/yoroi-frontend/blob/f4eabb25eedd564821514059479835601f8073ab/packages/yoroi-connector/example-cardano/index.js)\n\n- [x] Provide some reference implementation of the dapp connector\n  - [cardano-foundation/connect-with-wallet](https://github.com/cardano-foundation/cardano-connect-with-wallet)\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0030/extensions-register.md",
    "content": "# CIP-30 Accepted Extensions Register\n\nThis registry aims to document all CIP-30 extensions accepted as CIPs.\n\nThe aim of this document is to aid the discoverability of CIP-30 extensions.\n\n| Extension CIP | Link | Description |\n| --- | --- | --- |\n| CIP-0095 - Web-Wallet Bridge - Conway ledger era | https://github.com/cardano-foundation/CIPs/tree/master/CIP-0095 | Extension to enable support for Conway ledger era and governance |\n| CIP-0103 - Web-Wallet Bridge - Bulk transaction signing | https://github.com/cardano-foundation/CIPs/tree/master/CIP-0103 | Extension to provide an additional endpoint for dApp to sign multiple transactions in bulk |\n| CIP-0104 - Web-Wallet Bridge - Account public key | https://github.com/cardano-foundation/CIPs/tree/master/CIP-0104 | Extension to provide an additional endpoint for dApp to get the extended account public key from a connected wallet |\n| CIP-0106 - Web-Wallet Bridge - Multisig wallets | https://github.com/cardano-foundation/CIPs/tree/master/CIP-0106 | Extension to provide a interface for dApps and Cardano Multisig-wallets |"
  },
  {
    "path": "CIP-0031/README.md",
    "content": "---\nCIP: 31\nTitle: Reference inputs\nStatus: Active\nCategory: Plutus\nAuthors:\n    - Michael Peyton Jones <michael.peyton-jones@iohk.io>\nImplementors:\n    - Michael Peyton Jones <michael.peyton-jones@iohk.io>\n    - Jared Corduan <jared.corduan@iohk.io>\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/159\nCreated: 2021-11-29\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nWe introduce a new kind of input, a _reference_ input, which allows looking at an output without spending it.\nThis will facilitate access to information stored on the blockchain without the churn associated with spending and recreating UTXOs.\n\n## Motivation: why is this CIP necessary?\n\nDatums in transaction outputs provide a way to store and access information on the blockchain.\nHowever, they are quite constrained in a number of ways.\nMost notably, in order to access the information which is contained in them, you have to _spend_ the output that the datum is attached to.\n\nThis has a number of undesirable features:\n1. Even if the output is recreated after being spent, it is still a _new_ output. Any other user who wishes to look at the data cannot spend the old output (which is gone), but must rather spend the new output (which they will not know about until the next block). In practice this throttles some applications to one \"operation\" per block.\n2. Looking at the _information_ in the datum requires _spending_ the output, which means that care must be taken over the distribution of any funds in the output (possibly requiring scripts), and spending conditions must be met. This is overly stringent, inconvenient, and expensive.\n\nWe would like to have a mechanism for accessing the information in datums that avoids these issues.\n\n### Use cases\n\nHere are some cases where we expect this to be helpful.\n\n1. Inspecting the state (datum, or locked value) of an on-chain application without having to consume the output, e.g. checking the current state of a stablecoin state machine.\n2. On-chain data providers that store data in outputs, to be referenced by other scripts.\n3. (With inline datums) Creating a single UTXO with data to be used in multiple subsequent transactions, but only paying the cost for submitting it once.\n\n### Enabling further improvements\n\nThis proposal was designed in tandem with two further proposals which make use of reference scripts, CIP-32 (Inline datums) and CIP-33 (Reference scripts).\nA full assessment of the worth of this proposal should take into account the fact that it is an enabler for these other proposals.\n\n## Specification\n\n### Reference inputs\n\nWe introduce a new kind of transaction input, a reference input.\nTransaction authors specify inputs as either normal (spending) inputs or reference inputs.\n\nA reference input is a transaction input, which is linked to a particular transaction output as normal, except that it _references_ the output rather than _spending_ it. That is:\n\n- A referenced output must exist in the UTXO set.\n- Any value on a referenced output is _not_ considered when balancing the transaction.\n- The spending conditions on referenced outputs are _not_ checked, nor are the witnesses required to be present.\n    - i.e. validators are not required to pass (nor are the scripts themselves or redeemers required to be present at all), and signatures are not required for pubkey outputs.\n- Referenced outputs are _not_ removed from the UTXO set if the transaction validates.\n- Reference inputs _are_ visible to scripts.\n\nFor clarity, the following two behaviours which are present today are unchanged by this proposal:\n\n1. Transactions must _spend_ at least one output.[^1]\n2. Spending an output _does_ require the spending conditions to be checked.[^2]\n\n[^1]: This restriction already exists, and is important. It seems unnecessary, since transactions must always pay fees and fees must come from somewhere, but fees could in principle be paid via reward withdrawals, so the requirement to spend a UTXO is relevant.\n[^2]: That is, this proposal does not change outputs or the spending of outputs, it instead adds a new way of _referring_ to outputs.\n\n### Script context\n\nScripts are passed information about transactions via the script context.\nThe script context therefore needs to be augmented to contain information about reference inputs.\n\nChanging the script context will require a new Plutus language version in the ledger to support the new interface.\nThe change in the new interface is: a _new_ field is added to the structure which contains the list of reference inputs.\n\nThe interface for old versions of the language will not be changed.\nScripts with old versions cannot be spent in transactions that include reference inputs, attempting to do so will be a phase 1 transaction validation failure.\n\n### Extra datums\n\nToday, transactions can contain extra datums that are not required for validation.\nCurrently the extra datums must all be pre-images of datum hashes that appear in outputs.\nWe change this so that the extra datums can also be pre-images of datum hashes that appear in reference inputs.[^3]\n\nNote that the existing mechanism includes the hash of the extra datum structure in the transaction body, so that additional datums cannot be stripped by an attacker without voiding transaction signatures.\n\n[^3]: Pre-images of datum hashes that appear in _spent_ inputs are of course mandatory.\n\n### CDDL\n\nThe CDDL for transaction bodies will change to the following to reflect the new field.\n```\ntransaction_body =\n { 0 : set<transaction_input>    ; inputs\n ...\n , ? 16 : set<transaction_input> ; reference inputs\n }\n```\n\n## Rationale: how does this CIP achieve its goals?\n\nThe key idea of this proposal is to use UTXOs to carry information.\nBut UTXOs are currently a bad fit for distributing information.\nBecause of locality, we have to include outputs that we use in the transaction, and the only way we have of doing that is to _spend_ them - and a spent output cannot then be referenced by anything else.\nTo put it another way: outputs are resource-like, but information is not resource-like.\n\nThe solution is to add a way to _inspect_ (\"reference\") outputs without spending them.\nThis allows outputs to play double duty as resource containers (for the value they carry) and information containers (for the data they carry).\n\n### Requirements\n\nWe have a number of requirements that we need to fulfil.\n- Determinism\n    - It must be possible to predict the execution of scripts precisely, given the transaction.\n- Locality\n    - All data involved in transaction validation should be included in the transaction or the outputs which it spends (or references).\n- Non-interference\n    - As far as possible, transactions should not interfere with others. The key exception is when transactions consume resources that other transactions want (usually by consuming UTXO entries).\n- Replay protection\n    - The system should not be attackable (e.g. allow unexpected data reads) by replaying old traffic.\n- Storage control and garbage-collection incentives\n    - The amount of storage required by the system should have controls that prevent it from overloading nodes, and ideally should have incentives to shrink the amount of storage that is used over time.\n- Optimized storage\n    - The system should be amenable to optimized storage solutions.\n- Data transfer into scripts\n    - Scripts must have a way to observe the data.\n- Tool and library support\n    - It should not be too difficult for tools and libraries to work with the new system.\n- Hydra\n    - The system should be usable without compromising the needs of Hydra, such as parallel processing of independent parts of the transaction graph.\n\nReference inputs satisfy these requirements, mostly by inheriting them from the corresponding properties of UTXOs.\n\n- Referencing an output still requires the output to be presented as part of the transaction and be unspent, so determinism is preserved.\n- Referenced outputs appear as transaction inputs, so locality is preserved.\n- Outputs can be referenced multiple times, so we have non-interference even under heavy usage of referencing. Conflicts can occur only if the output is actually spent.\n- Replay protection is inherited because a transaction must always spend at least one UTXO, and UTXOs can only be spent once.\n- Storage control is inherited from control of the UTXO set, via the min UTXO value incentives. Data can be \"retired\" by spending the input (rather than referencing it), reclaiming the min UTXO value.\n- Optimized storage is inherited directly from work on improving UTXO storage.\n- Data transfer into scripts works automatically since scripts can see transaction inputs.\n- Tools and libraries will only have to deal with a new kind of transaction input, and unless they care about scripts they can likely ignore them entirely.\n- Hydra is able to work with reference inputs (see below).\n\n### Why UTXOs?\n\nThere are various approaches to augmenting Cardano with the ability to store and retrieve data more easily.\nAll of these require some kind of resource-like system for the _storage_ that is used for data.\nThe main argument in favour of the reference input approach is that it reuses our existing resource-like system: UTXOs.\n\nAs we've seen above, this allows us to satisfy most of our requirements for free.\nAny other approach would need new solutions to these problems.\n\nAs a brief example, suppose we wanted to instead implement data storage as an on-chain, hash-indexed data store (a proposal we considered).\n\nThen we would need to answer a lot of questions:\n- How is the data accessed and retrieved? Are these stateful operations? Does this make transaction ordering more significant, threatening determinism?\n- How is the storage usage controlled? Do people pay for storing data? Do they pay for a fixed period, or perpetually? How is data retired?\n- How is the storage going to be implemented? How will this affect node memory usage?\n- How are scripts going to access the data in the store?\n- How will tools interact with and visualize the store and changes to it?\n\n### How should we present the information to scripts?\n\nScripts definitely need to see reference inputs.\nBut we have at least two options for how we represent this in the script context: put the reference inputs in their own field; or include them with the other inputs, but tag them appropriately.\n\nKeeping them separate seems wise given the potential for confusing reference inputs for normal inputs.\nThat would be quite a dangerous programming error, as it might lead a script to believe that e.g. an output had been spent when in fact it had only been referenced.\n\nWe also have the question of what to do about old scripts.\nWe can't really present the information about reference inputs to them in a faithful way: representing them as spending inputs would be wildly misleading, and there is nowhere else to put them.\nWe could omit the information entirely, but this is dangerous in a different way.\nOmitting information may lead scripts to make assumptions about the transaction that are untrue; for this reason we prefer not to silently omit information as a general principle.\nThat leaves us only one option: reject transactions where we would have to present information about reference inputs to old scripts.\n\n### Accessing the datums of reference inputs\n\nCurrently this proposal has somewhat limited utility, because datums in outputs are just hashes, and the spending party is required to find and provide the preimage themselves.\nTherefore the CIP-32 proposal for inline datums is complementary, as it allow UTXOs to carry the data itself rather than a hash.\n\nIn the mean time (or if CIP-32 is not implemented), we still want users to be _able_ to provide the datums corresponding to datum hashes in reference outputs, so that at least it is possible to reference the data, albeit clumsily.\nThe easiest solution here is to reuse the existing mechanism for providing pre-images of datum hashes which appear in outputs.\n\nProviding datum hash pre-images remains optional, since there are reasons to use reference inputs even without looking at the datum, e.g. to look at the value in an output.\n\n### Accessing the value locked in outputs\n\nThe motivation of this proposal mainly requires looking at the _datums_ of outputs.\nBut reference inputs allow us to do more: they let us look at the _value_ locked in an output (i.e. how much Ada or other tokens it contains).\n\nThis is actually a very important feature.\nSince anyone can lock an output with any address, addresses are not that useful for identifying _particular_ outputs on chain, and instead we usually rely on looking for particular tokens in the value locked by the output.\nHence, if a script is interested in referring to the data attached to a _particular_ output, it will likely want to look at the value that is locked in the output.\n\nFor example, an oracle provider would need to distinguish the outputs that they create (with good data) from outputs created by adversaries (with bad data).\nThey can do this with a token, so long as scripts can then see the token!\n\n### Hydra\n\nWe want reference inputs to be usable inside Hydra heads.\nThis raises a worry: since Hydra processes independent parts of the transaction graph in parallel, what happens if it accepts one transaction that references an output, and one that spends the output, but then the first transaction gets put into a checkpoint before the second?\n\nFortunately, Hydra already has to deal with double-spend conflicts of this kind (although in the naive protocol this results in a decommit).\nThis proposal simply introduces a new kind of conflict, a reference-spend conflict.\nReference-spend conflicts should be handled by the same mechanism that is used to handle double-spend conflicts.\n\n### Controlling referencing\n\nOne thing that a user might want to do is to control who can reference an output.\nFor example, an oracle provider might want to only allow a transaction to reference a particular output if the transaction also pays them some money.\n\nReference inputs alone do _not_ provide any way to do this.\nAnother mechanism would be required, but there is no consensus on what the design should be, so it is currently out of scope for this proposal.\nA brief summary of a few options and reasons why they are not obvious choices is included below.\n\nA key issue is that the choice to control referencing must lie with the _creator_ of the output, not the _spender_.\nTherefore we _must_ include some kind of change to outputs so that the creator can record their requirements.\n\n#### Check inputs\n\nA \"check input\" is like a reference input except that the spending conditions _are_ checked.\nThat is, it acts as proof that you _could_ spend the input, but does not in fact spend it.\n\nSince check inputs cause validator scripts to be run, it seems like they could allow us to control referencing.\nThere are two wrinkles:\n\n- The same script would be used for both referencing and spending, overloading the meaning of the validator script. This is still _usable_, however, since the redeemer could be used to indicate which action is being taken.\n- We would need a flag on outputs to say \"this output cannot be referenced, but only checked\". Exactly what this should look like is an open question, perhaps it should be generic enough to control all the possible ways in which an output might be used (of which there would be three).\n\n#### Referencing conditions\n\n\"Referencing conditions\" would mean adding a new field to outputs to indicate under what conditions the output may be referenced.\nThis could potentially be an entire additional address, since the conditions might be any of the normal spending conditions (public key or script witnessing).\n\nHowever, this would make outputs substantially bigger and more complicated.\n\n### Related work\n\nReference inputs are very similar to Ergo's \"data inputs\".\nWe chose to name them differently since \"data\" is already a widely used term with risk for confusion.\nWe might also want to introduce other \"verb\" inputs in future.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Fully implemented in Cardano as of the Vasil protocol upgrade.\n\n### Implementation Plan\n\n- [x] Passes all requirements of both Plutus and Ledger teams as agreed to improve Plutus script efficiency and usability.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0032/README.md",
    "content": "---\nCIP: 32\nTitle: Inline datums\nStatus: Active\nCategory: Plutus\nAuthors:\n    - Michael Peyton Jones <michael.peyton-jones@iohk.io>\nImplementors:\n    - Michael Peyton Jones <michael.peyton-jones@iohk.io>\n    - Jared Corduan <jared.corduan@iohk.io>\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/160\nCreated: 2021-11-29\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nWe propose to allow datums themselves to be attached to outputs instead of datum hashes.\nThis will allow much simpler communication of datum values between users.\n\n## Motivation: why is this CIP necessary?\n\nConceptually, datums are pieces of data that are attached to outputs.\nHowever, in practice datums are implemented by attaching _hashes_ of datums to outputs, and requiring that the spending transaction provides the actual datum.\n\nThis is quite inconvenient for users.\nDatums tend to represent the result of computation done by the party who creates the output, and as such there is almost no chance that the spending party will know the datum without communicating with the creating party.\nThat means that either the datum must be communicated between parties off-chain, or communicated on-chain by including it in the witness map of the transaction that creates the output (\"extra datums\").\nThis is also inconvenient for the spending party, who must watch the whole chain to spot it.\n\nIt would be much more convenient to just put the _datum itself_ in an output, which is what we propose.\n\n### Use cases\n\nWe expect that, provided we are able to bring the cost low enough, a large proportion of dapp developers will make use of this feature, as it will simplify their systems substantially.\n\n## Specification\n\nTransaction outputs are changed so that the datum field can contain either a hash or a datum (an \"inline datum\").\n\nThe min UTXO value for an output with an inline datum depends on the size of the datum, following the `coinsPerUTxOWord` protocol parameter.\n\nWhen an output with an inline datum is spent, the spending transaction does not need to provide the datum itself.\n\n### Script context\n\nScripts are passed information about transactions via the script context.\nThe script context therefore needs to be augmented to contain information about inline datums.\n\nChanging the script context will require a new Plutus language version in the ledger to support the new interface.\n\nThere are two changes in the new version of the interface:\n- The datum field on transaction outputs can either be a hash or the actual datum.\n- The datum field on transaction inputs can either be a hash or the actual datum.\n\nThe interface for old versions of the language will not be changed.\nScripts with old versions cannot be spent in transactions that include inline datums, attempting to do so will be a phase 1 transaction validation failure.\n\n### CDDL\n\nThe CDDL for transaction outputs will change as follows to reflect the new alternative.\n```\ntransaction_output =\n  [ address\n  , amount : value\n  , ? datum : $hash32 / plutus_data\n  ]\n```\nTODO: should there be a dedicated production for datum-hash-or-datum? Does it need to be tagged?\n\n## Rationale: how does this CIP achieve its goals?\n\nThe key idea of this proposal is simply to restore the conceptually straightforward situation where datums are attached to outputs.\nHistorically, this was the way that the EUTXO model was designed, and switching to datum hashes on outputs was done to avoid bloating UTXO entries, which at that time (pre-multiasset) were constant-size (see [^1] page 7).\n\nNow that we have variable-sized UTXO entries and the accounting to support them, we can restore inline datums.\n\nSince inline datums change very little about the model apart from where data is stored, we don't need to worry about violating any of the other requirements of the ledger, but we do need to worry about the effect on the size of the UTXO set.\n\n### UTXO set size\n\nThis proposal gives users a way to put much larger amounts of data into the UTXO set.\nWon’t this lead to much worse UTXO set bloat?\n\nThe answer is that we already have a mechanism to discourage this, namely the minimum UTXO value.\nIf inline datums turns out to drive significantly increased space usage, then we may need to increase `coinsPerUTxOWord` in order to keep the UTXO size down.\nThat will be costly and inconvenient for users, but will still allow them to use inline datums where they are most useful and the cost is bearable.\nFurthermore, we hope that we will in fact be able to _reduce_ `coinsPerUTxOWord` when the upcoming work on moving the UTXO mostly to on-disk storage is complete.\n\nAnother guard rail would be to enforce upper limits on the size of inline datums.\nAt the extreme, we could bound them to the size of a hash, which would guarantee no more space usage than today.\nHowever, this is much worse for users, since it introduces a sharp discontinuity where an inline datum is entirely acceptable, until it crosses the size threshold at which point it is unacceptable, and there is no way to avoid this.\nGenerally we prefer to avoid such discontinuities in favour of gradually increasing costs.\n\nIn practice, what is implemented here may depend on whether the UTXO-on-disk work is completed by the time that this proposal is implemented.\n\n### Other modes of specifying datums\n\nWe could deprecate the other methods of specifying datums (datum hashes or datum hashes+extra datums).\nHowever, the other approaches also have some advantages.\n\n- Transmission costs: creator pays versus consumer pays\n    - Inline datums: creator pays\n    - Datum hashes: consumer pays\n    - Datum hashes+extra datums: both pay\n- Min UTXO value costs\n    - Inline datums: depends on data size\n    - Datum hashes: fixed cost\n    - Datum hashes+extra datums: fixed cost\n- Privacy\n    - Inline datums: datum is immediately public\n    - Datum hashes: datum is not public until consumed\n    - Datum hashes+extra datums: datum is immediately public, but only to chain-followers\n- Communication of datums\n    - Inline datums: easy on-chain communication\n    - Datum hashes: off-chain communication necessary\n    - Datum hashes+extra datums: complicated on-chain communication\n\nAny one of these factors could be important to particular use cases, so it is good to retain the other options.\n\n### The script context\n\n#### Including information about inline datums\n\nIn principle we do not need to let scripts see whether a datum is inline or not.\nWe could pretend that inline datums are non-inline and insert them into the datum witness map.\n\nThe underlying question is: do we want scripts to be able to make assertions about whether datums are inline or not?\nThere are reasons to want to do this: _not_ using inline datums causes communication issues for users, and so it is quite reasonable that an application developer may want to be able to enforce their use.\n\nFurthermore, as a general principle we try to keep the script context as faithful to real transactions as possible.\nEven if the use for the information is not immediately obvious, we try to err on the side of providing it and letting users decide.\n\nHence we _do_ include information about inline datums in the script context.\n\n#### Representation and backwards compatibility\n\nThere are a couple of options for how to change the representation of the script context to include the new information, and whether to make a backwards compatibility effort for old language versions.\n\nFor the new script context:\n\n1. Match the ledger representation as much as possible: change the fields on inputs and outputs to be either a datum hash or a datum.\n2. Try to only have one way to look up datums: put inline datums in the datum witness map and insert their hashes into the corresponding inputs and outputs; optionally add a boolean to inputs and outputs to indicate whether the datum was originally inline.\n\nFor backwards compatibility:\n\n1. Don't try to represent inline datums for scripts using old language versions: old scripts simply can't be run in transactions that use inline datums (since we can't represent the information).\n2. Rewrite inline datums as non-inline datums: put inline datums in the datum witness map and insert their hashes into the corresponding inputs and outputs.\n\nFor the new script context, option 1 has the significant advantage of matching the ledger representation of transactions.\nThis makes it easier to implement, and also avoids conceptual overhead for users who would have to distinguish the two ways of representing transactions.\nWhile the conceptual distance here may be small, if we let it grow over time then it may become quite confusing.\n\nWe then have the choice of what to do about backwards compatibility.\nOption 2 would work, but is more complicated for the ledger and is inconsistent in representation with our choice for the new script context (inline datums are sometimes represented faithfully, and sometimes put in the witness map).\nOption 1 is simple, but doesn't allow old scripts to work with inline datums.\nThis would not be so bad if it just meant that old scripts could not be spent in transactions that include inline datums, but it also introduces a new way to make an unspendable output.\nIf a user creates an output with an old script and an inline datum, then any transaction spending that output will include an inline datum, which we would not allow.\n\nUnfortunately, we cannot prevent users from creating such outputs in general, since script addresses do not include the script language, so the ledger cannot tell whether the inline datum is permissible or not.\nClient code typically _will_ be able to do this, since it will usually know the script.\n\nThe mitigating factor is that we expect this to be uncommon in practice, particularly since we expect that most users will move to the new version relatively quickly, since we expect support for inline datums to be desirable, and released alongside other desirable features.\n\nHence we choose both option 1s and do _not_ provide backwards compatibility for old language versions.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Fully implemented in Cardano as of the Vasil protocol upgrade.\n\n### Implementation Plan\n\n- [x] Passes all requirements of both Plutus and Ledger teams as agreed to improve Plutus script efficiency and usability.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[^1]: Chakravarty, Manuel M. T. et al., \"The extended UTXO model\"\n"
  },
  {
    "path": "CIP-0033/README.md",
    "content": "---\nCIP: 33\nTitle: Reference scripts\nStatus: Active\nCategory: Plutus\nAuthors:\n    - Michael Peyton Jones <michael.peyton-jones@iohk.io>\nImplementors:\n    - Michael Peyton Jones <michael.peyton-jones@iohk.io>\n    - Jared Corduan <jared.corduan@iohk.io>\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/161\n    - https://github.com/cardano-foundation/CIPs/pull/213\nCreated: 2021-11-29\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nWe propose to allow scripts (\"reference scripts\") to be attached to outputs, and to allow reference scripts to be used to satisfy script requirements during validation, rather than requiring the spending transaction to do so.\nThis will allow transactions using common scripts to be much smaller.\n\n## Motivation: why is this CIP necessary?\n\nScript sizes pose a significant problem. This manifests itself in two ways:\n1. Every time a script is used, the transaction which caused the usage must supply the whole script as part of the transaction. This bloats the chain, and passes on the cost of that bloat to users in the form of transaction size fees.\n2. Transaction size limits are problematic for users. Even if individual scripts do not hit the limits, a transaction which uses multiple scripts has a proportionally greater risk of hitting the limit.\n\nWe would like to alleviate these problems.\n\nThe key idea is to use reference inputs and modified outputs which carry actual scripts (\"reference scripts\"), and allow such reference scripts to satisfy the script witnessing requirement for a transaction.\nThis means that the transaction which _uses_ the script will not need to provide it at all, so long as it referenced an output which contained the script.\n\n## Specification\n\nWe extend transaction outputs with a new optional field, which contains a script (a \"reference script\").\n\nThe min UTXO value for an output with an additional script field depends on the size of the script, following the `coinsPerUTxOWord` protocol parameter.\n\nWhen we are validating a transaction and we look for the script corresponding to a script hash, in addition to the scripts provided in the transaction witnesses, we also consider any reference scripts from the outputs referred to by the inputs of the transaction.\n\n### Script context\n\nScripts are passed information about transactions via the script context.\nWe propose to augment the script context to include some information about reference scripts.\n\nChanging the script context will require a new Plutus language version in the ledger to support the new interface.\nThe change is: a new optional field is added to outputs and inputs to represent reference scripts.\nReference scripts are represented by their hash in the script context.\n\nThe interface for old versions of the language will not be changed.\nScripts with old versions cannot be spent in transactions that include reference scripts, attempting to do so will be a phase 1 transaction validation failure.\n\n### CDDL\n\nThe CDDL for transaction outputs will change as follows to reflect the new field.\n```\ntransaction_output =\n  [ address\n  , amount : value\n  , ? datum : $hash32\n  , ? ref_script : plutus_script\n  ]\n```\nTODO: can we use a more generic type that allows _any_ script in a forwards-compatible way?\n\n## Rationale: how does this CIP achieve its goals?\n\nThe key idea of this proposal is stop sending frequently-used scripts to the chain every time they are used, but rather make them available in a persistent way on-chain.\n\nThe implementation approach follows in the wake of CIP-31 (Reference inputs) and CIP-32 (Inline datums).\nThe former considers how to do data sharing on chain, and concludes that referencing UTXOs is a good solution.\nThe latter shows how we can safely store substantial data in UTXOs by taking advantage of existing mechanisms for size control.\n\nIt is therefore natural to use the same approach for scripts: put them in UTXOs, and reference them using reference inputs.\n\n### Storing scripts in outputs\n\nThere are a few possible alternatives for where to store reference scripts in outputs.\n\n#### 1: The address field\n\nIn principle, we could add an \"inline scripts\" extension that allowed scripts themselves to be used in the address field instead of script hashes.\nWe could then use such scripts as reference scripts.\n\nHowever, this approach suffers from a major confusion about the functional role of the script.\nYou would only be able to provide a reference script that _also_ controlled the spending of the output.\nThis is clearly not what you want: the reference script could be anything, perhaps a script only designed for use in quite specific circumstances; whereas in many cases the user will likely want to retain control over the output with a simple public key.\n\n#### 2: The datum field\n\nWith inline datums, we could put reference scripts in the datum field of outputs.\n\nThis approach has two problems.\nFirst, there is a representation confusion: we would need some way to know that a particular datum contained a reference script.\nWe could do this implicitly, but it would be better to have an explicit marker.\n\nSecondly, this prevents having an output which is locked by a script that needs a datum _and_ has a reference script in it.\nWhile this is a more unusual situation, it's not out of the question.\nFor example, a group of users might want to use a Plutus-based multisig script to control the UTXO with a reference script in it.\n\n#### 3: A new field\n\nA new field is the simplest solution: it avoids these problems because the new field clearly has one specific purpose, and we do not overload the meanings of the other fields.\n\n### UTXO set size\n\nThis proposal gives people a clear incentive to put large amounts (i.e. kilobytes) of data in outputs as reference scripts.\n\nThis is essentially the same problem which is faced in CIP-32, and we can take the same stance.\nWe don't want to bloat the UTXO set unnecessarily, but we already have mechanisms for limiting that (in the form of the min UTXO value), and these should work transparently for reference scripts as they will for inline datums.\n\n### Changing the script context\n\nWe don't strictly need to change the script context.\nWe could simply omit any information about reference scripts carried by outputs.\nThis would mean that we don't need to change the interface.\n\nWe don't have obvious use cases for the information about reference scripts, but the community may come up with use cases, and our general policy is to try and include as much information about the transaction as we can, unless there is a good reason not to.\n\nWe also have the question of what to do about old scripts.\nWe can't really present the information about reference scripts to them in a faithful way, there is nowhere to put the information.\nWe could omit the information entirely, but this is dangerous in a different way.\nOmitting information may lead scripts to make assumptions about the transaction that are untrue; for this reason we prefer not to silently omit information as a general principle.\nThat leaves us only one option: reject transactions where we would have to present information about reference scripts to old scripts.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Fully implemented in Cardano as of the Vasil protocol upgrade.\n\n### Implementation Plan\n\n- [x] Passes all requirements of both Plutus and Ledger teams as agreed to improve Plutus script efficiency and usability.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0034/README.md",
    "content": "---\nCIP: 34\nTitle: Chain ID Registry\nStatus: Proposed\nCategory: Tools\nAuthors:\n  - Sebastien Guillemot <seba@dcspark.io>\nImplementors: []\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/158\n  - https://github.com/cardano-foundation/CIPs/pull/332\n  - https://github.com/cardano-foundation/CIPs/pull/412\nCreated: 2021-11-24\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nCurrently Cardano has two easily-usable networks: \"mainnet\" and \"testnet\". However, in the future, we expect more networks to exist and so we need some way to refer to these networks to be able to write better multi-network applications and systems.\n\n## Motivation: why is this CIP necessary?\n\nCardano currently has three ways to refer to a network:\n- The \"network ID\" included in every address and also optionally present in the transaction body. This only stores 16 possibilities (4 bits)\n- The \"network magic\" used for Byron addresses and in the handshake with other nodes in the network layer. This is a random 32-bit number\n- The genesis block hash (a 28-byte number)\n\nBlockchains can have multiple deployments of the same codebase. For example:\n\n1. Test networks where the base asset has no value (so devs can test at no cost)\n1. Test networks where the protocol is simplified for ease of testing (ex: Cardano but with a Proof of Authority consensus for stable block production in testing)\n1. Test networks for new features\n    1. Plutus Application Backend (PAB) testnet\n    2. Shelley incentivized testnet\n1. Forks that diverge in feature set (the many forks of Bitcoin and Ethereum)\n\ndApps may be deployed on specific testnets that match their criteria and wallets need to know about these networks to know how to behave.\n\nAdditionally, having a standardized registry for networks allows easy integration into the broader crypto ecosystem via standards like [CAIP-2](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-2.md)\n\n## Specification\n\nWe create a machine-readable registry of networks\n\nAll entries in this registry should have the following entries:\n\n- User-friendly name\n- Network ID\n- Network magic\n- Genesis hash\n\nWhen representing these networks in a human-readable string, the following format shall be used:\n\n```\ncip34:NetworkId-NetworkMagic\n```\n\n# Rationale: how does this CIP achieve its goals?\n\nWe pick this format for the following reason:\n- The network ID is too small to be used by itself. You can see from [chainlist](https://chainlist.org/) that 16 possibilities is too few\n- The genesis hash is too long and user-unfriendly to be used.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] There are at least two (from different providers) wallets, libraries, CLI packages, or other tools which use this standard for network identification.\n\n### Implementation Plan\n\n- [x] Develop and publish reference implementation: [CIP34-JS](https://www.npmjs.com/package/@dcspark/cip34-js)\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n"
  },
  {
    "path": "CIP-0034/registry.json",
    "content": "{\n    \"PreProduction\": {\n        \"Name\": \"Pre-Production\",\n        \"NetworkId\": 0,\n        \"NetworkMagic\": 1,\n        \"GenesisHash\": \"d4b8de7a11d929a323373cbab6c1a9bdc931beffff11db111cf9d57356ee1937\"\n    },\n    \"Preview\": {\n        \"Name\": \"Preview\",\n        \"NetworkId\": 0,\n        \"NetworkMagic\": 2,\n        \"GenesisHash\": \"72593f260b66f26bef4fc50b38a8f24d3d3633ad2e854eaf73039eb9402706f1\"\n    },\n    \"Mainnet\": {\n        \"Name\": \"Mainnet\",\n        \"NetworkId\": 1,\n        \"NetworkMagic\": 764824073,\n        \"GenesisHash\": \"5f20df933584822601f9e3f8c024eb5eb252fe8cefb24d1317dc3d432e940ebb\"\n    },\n    \"LegacyTestnet\": {\n        \"Name\": \"Legacy Testnet\",\n        \"NetworkId\": 0,\n        \"NetworkMagic\": 1097911063,\n        \"GenesisHash\": \"96fceff972c2c06bd3bb5243c39215333be6d56aaf4823073dca31afe5038471\"\n    }\n}\n"
  },
  {
    "path": "CIP-0034/schema.json",
    "content": "{\n  \"definitions\": {\n    \"network\": {\n      \"$id\": \"#/definitions/network\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"Name\": {\n          \"type\": \"string\"\n        },\n        \"NetworkId\": {\n          \"type\": \"integer\",\n          \"minimum\": 0,\n          \"exclusiveMaximum\": 16\n        },\n        \"NetworkMagic\": {\n          \"type\": \"integer\",\n          \"minimum\": 0,\n          \"exclusiveMaximum\": 4294967295\n        },\n        \"GenesisHash\": {\n          \"type\": \"string\",\n          \"pattern\": \"^[0-9a-fA-F]+$\",\n          \"minLength\": 64,\n          \"maxLength\": 64\n        }\n      },\n      \"required\": [\n        \"Name\",\n        \"NetworkId\",\n        \"NetworkMagic\",\n        \"GenesisHash\"\n      ]\n     }\n  },\n  \"type\": \"object\",\n  \"additionalProperties\": { \"$ref\": \"#/definitions/network\" }\n}"
  },
  {
    "path": "CIP-0035/README.md",
    "content": "---\nCIP: 35\nTitle: Changes to Plutus Core\nStatus: Active\nCategory: Meta\nAuthors:\n  - Michael Peyton Jones <michael.peyton-jones@iohk.io>\nImplementors: N/A\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/215\n  - https://github.com/cardano-foundation/CIPs/pull/428\n  - https://github.com/cardano-foundation/CIPs/pull/437\n  - https://github.com/cardano-foundation/CIPs/pull/484\nCreated: 2022-02-09\nLicense: CC-BY-4.0\n---\n\n# Changes to Plutus Core\n\n## Abstract\n\nThis CIP specifies a process for proposing changes to Plutus Core, its builtins, and its interface to the Cardano ledger.\nIt gives a taxonomy of typical changes, and explains how these changes may be made, which in some cases requires a CIP.\nIt introduces the 'Plutus' CIP category for tracking these.\n\n## Motivation: why is this CIP necessary?\n\nThe Plutus Core language, its builtins, and its interface to the ledger are all likely to evolve significantly over time. There are many reasons for this:\n- We may be able to increase performance, improve safety, or reduce script sizes by changing the language.\n- We may be able to improve performance by providing builtin versions of expensive functions.\n- We may need to provide builtin versions of sensitive functions (e.g. cryptography) in order to ensure access to high-quality implementations.\n- We may find bugs in the implementation that need to be fixed.\n- We may need to change the interface to the ledger in order to represent changes in transaction formats.\n- We may wish to remove elements which have been deprecated due to the addition of improved versions.\n- … and more\n\nThis CIP gives a taxonomy of changes, explains how such changes might be implemented in Cardano, and prescribes processes for proposing such changes.\n\n## Background\n\nThis CIP assumes general familiarity with Plutus Core and the Cardano ledger, but we give some brief background here.\n\n### Plutus Core\n\n_Plutus Core_ is a script language used in the Cardano ledger. \nFor the purposes of this document, Plutus Core consists of various _language constructs_, and also _builtin types and functions_.\n\nPlutus Core has a number of builtin types, such as integers, and builtin functions, such as integer addition. \nBuiltin functions provide access to functionality that would be difficult or expensive to implement using the basic constructs of Plutus Core, which is otherwise little more than the untyped lambda calculus.\nBuiltin functions can operate only over builtin types or arbitrary Plutus Core terms treated opaquely. \nBuiltin types come with a _size metric_ which is used by costing functions. \nFor example, the size metric for integers returns the bit-size of the integer.\n\nThe performance of Plutus Core scripts has two components: how expensive the script actually is to run (_real performance_) and how expensive we say it is to run in the ledger (_model performance_). \n\nModel performance is calculated by costing _evaluation_ in abstract resource units (\"exunits\") of CPU and memory. \nIndividual steps of evaluation are costed, and builtin functions must also come with a _costing function_ that provides costing information for them. \nThe costing function for a builtin function is a mathematical function which takes the sizes of the arguments (as computed by their size metrics), and returns an estimate of the budget that will be used to perform that function. \nFor example, the costing function for addition says that the CPU and memory costs are both proportional to the maximum of the sizes of the input integers (with some appropriate constants).\n\nDetermining costing functions is done empirically, by running the function in question against a large number of inputs and choosing a costing function that fits the data well.\n\nPlutus Core has a _language version_ (LV).\nThis is the version of the Plutus Core programming language itself, and it controls e.g. which constructs are available in the language.\nChanging any of the features which are guarded by the language version requires a new language version to be supported by the chain.\nNote that changing the set of builtin types or functions does _not_ require a new language version; any individual Plutus Core language version is compatible with any set of builtin types and functions.\n\nDepending on the type of change, a major or minor bump to the language version may be required.\nThe following table shows typical examples.\n\n| Change                                                | Type  | Notes                     |\n|-------------------------------------------------------|-------|---------------------------|\n| Adding a construct to the language                    | Minor | Backwards-compatible.     |\n| Removing a construct from the language                | Major | Not backwards-compatible. |\n| Changing the behaviour of a construct in the language | Major | Not backwards-compatible. |\n| Changing the binary format of the language in a backwards-compatible way | Minor | Safe even if it makes previously non-deserializable scripts deserializable.[^backwards-safe] |\n| Changing the binary format of the language            | Major | Not backwards-compatible. |\n\n[^backwards-safe]: See \"Are backwards-compatible binary format changes really safe?\".\n\nSince we always need a new Plutus Core langauge version for any change to the language, in the rest of this document we will focus on the introduction of a new langauge version as the proxy for changes to the language.\n\n### Scripts in the Cardano ledger\n\nThe Cardano ledger recognizes various kinds of _scripts_ identified by _language_.\nThis language tag is the only way that the ledger has to distinguish between different types of script.\nHence if we require different behaviour, we need a new language.\nWe refer to these languages as _ledger languages_ (LLs).\n\nPart of the specification of a language in the ledger is how scripts of that language are run, what arguments they are passed, how those arguments are structured, etc. \nWe refer to this as the _ledger-script interface_.\n\nBecause we want to occasionally change e.g. the ledger-script interface for Plutus Core scripts, this means we need several ledger languages which all run scripts written in Plutus Core.[^ledger-language-versions]\nAll Plutus Core ledger languages which are used in the ledger must be supported forever, in order to be able to validate the history of the chain.\n\n[^ledger-language-versions]: The Plutus Core family of ledger languages are sometimes referred to as the Plutus Core _ledger language versions_, and named as such (\"PlutusV1\", \"PlutusV2\" etc.) although they actually entirely distinct _languages_ from the perspective of the ledger. In this document we will use the more precise language and refer to them just as distinct ledger languages.\n\nLedger languages also have an associated subset of the _protocol parameters_. \nThese parameters provide the ability to control some aspects of evaluation without a software update. \nThe most notable example is a set of parameters which parameterize the costing of program execution.\nHence, a different Plutus Core ledger language can have a different set of costing protocol parameters.\n\nWe can change the behaviour of ledger languages in a backwards compatible way with new protocol versions.\nThis ensures that the new behaviour only becomes available at a particular time in the history of the chain.\n\nOverall the combination of ledger language and protocol version controls:\n- The protocol parameters which are available\n- The ledger-script interface\n- The Plutus Core language versions that are available\n- The set of builtin types and values that are available\n\n### Types of change\n\nThis document considers the following types of change:\n\n1. The Plutus Core language\n    1. Adding a new Plutus Core language version \n2. The Plutus Core builtin functions and types\n    1. Adding a new builtin function or type\n    2. Removing a builtin function or type\n    3. Changing the behaviour of a builtin function or type\n3. The ledger-script interface\n    1. Changing the interface between the ledger and the interpreter\n4. Protocol parameters\n    1. Improving model performance (i.e. changing the costing parameters so that scripts use less budget)\n    2. Regressing model performance (i.e. changing the costing parameters so that scripts use more budget)\n    3. Adding costing parameters\n    4. Removing costing  parameters\n5. Performance of the Plutus Core interpreter\n    1. Improving real performance\n    2. Regressing real performance\n\n### Types of release\n\nChanges to Plutus Core can be released onto Cardano in four ways, with ascending levels of difficulty:\n\n1. A _protocol parameter_ change (PP), taking effect as soon as the new parameters are accepted (in a new epoch).\n2. A _software update_ (SU) to the node, taking effect when nodes upgrade.\n3. A _hard fork_ (HF) (accompanied by a software update), requiring a software update for the new protocol version, and taking effect after the hard fork.\n4. A new Plutus Core _ledger language_ (LL), introduced in a hard fork, and taking effect for scripts that use the new language, but not for those that use the old language.\n\nIntuitively, these correspond to how _compatible_ the change is.\n- A backwards- and forwards-compatible change can be deployed with a software update, as nobody can perceive the difference.\n- A backwards-compatible (but not forwards-compatible) change must be deployed in a hard fork, since it makes more blocks acceptable than before.\n- A backwards-incompatible change requires a new Plutus Core ledger language, so that the ledger can distinguish them, and maintain the old behaviour for old scripts.\n\nThe following table lists, for each type of change in \"Types of change\", what kind of release it requires.\n\n| Change                                                                     | Release            | Notes                                                                                               |\n|----------------------------------------------------------------------------|--------------------|-----------------------------------------------------------------------------------------------------|\n| Adding a new Plutus Core language version                                 | HF                 | Backwards-compatible since the new behaviour is guarded by the new LV. |\n| Adding a new builtin function or type                                      | HF (rarely LL[^binary-backwards]) | Backwards-compatible. Requires a binary format change.                                              |\n| Removing a builtin function or type                                        | LL                 | This will cause scripts which use this builtin to be rejected, so is not backwards compatible.      |\n| Changing the behaviour of a builtin function or type                       | LL                 | This changes the behaviour of existing scripts, so is not backwards compatible.                     |\n| Changing the interface between the ledger and the interpreter              | LL                 | The ledger must provide scripts with exactly the right interface. New interface means new language. |\n| Improving model performance                                                | PP                 | _Must_ strictly follow an improvement in real performance.[^why-perf-1]                                      |\n| Regressing model performance                                               | PP                 |                                                                                                     |\n| Adding cost model parameters                                               | HF                 | All nodes must recognize the new parameter.                                                         |\n| Removing cost model parameters                                             | LL                 | Old scripts will require all the old parameters.                                                    |\n| Improving real performance                                                 | SU                 |                                                                                                     |\n| Regressing real performance                                                | SU                 | _Must_ strictly follow a regression in model performance.[^why-perf-2]                                       |\n\n[^binary-backwards]: The binary format change is backwards compatible unless it breaches the limit of how many builtin functions or types can be encoded, in which case that must be changed, forcing a new LL.\n[^why-perf-1]: See \"Why do performance changes require extra steps?\".\n[^why-perf-2]: See \"Why do performance changes require extra steps?\".\n\n## Specification\n\n### Scope\n\nThis CIP deals with the types of change listed in \"Types of change\".\nThat list aims to cover the most typical changes to Plutus Core, but it is not exhaustive.\nCIPs which do not propose changes in the list but whose authors believe they significantly affect Plutus Core should nonetheless be assigned to the Plutus category.\n\nAdditionally, there is significant overlap with the Ledger category around the ledger-script interface and the protocol parameters.\nCIPs which change these parts of Cardano should generally use the Plutus category and not the Ledger category, although the Editors may ask the Ledger reviewers to comment.\n\n### The Plutus reviewers\n\nThe following table gives the current set of reviewers for Plutus CIPs.\n\n| Name                 | Email                        | GitHub username |\n|----------------------|------------------------------|-----------------|\n| Ziyang Liu           | ziyang.liu@iohk.io           | zliu41          |\n\n### Changes that require a CIP\n\nThis proposal requires that some of the changes listed in \"Types of change\" (specified below) should:\n\n1. Be proposed in a CIP.\n2. Go through additional process in addition to the [usual CIP process](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0001/README.md).\n\nThe additional process mostly takes the form of additional information that should be present in the CIP before it moves to particular stages.\n\nThe requirement to propose a change via a CIP is, as all CIPs are, advisory. \nIn exceptional circumstances or where swift action is required, we expect that changes may still be made without following this process. \nIn such circumstances, a retrospective CIP SHOULD be made after the fact to record the changes and the rationale for them.\n\nChanges that require a CIP do not have to each be in an individual CIP, they can be included in batches or in other CIPs. \nSo, for example, a single CIP could propose multiple new builtin functions, or a CIP proposing a change to the ledger could also propose a change to the ledger-script interface.\n\n### Processes\n\nAll changes that require a CIP SHOULD adhere to the following generic process.\n\nIn order to move to Proposed status:\n- The Specification MUST include:\n    - The type of change that is being proposed.\n    - For changes to Plutus Core itself, a formal specification of the changes which is precise enough to update the Plutus Core specification from.\n- The Acceptance Criteria MUST include:\n    - The external implementations are available.\n    - The `plutus` repository is updated with the specification of the proposal.\n    - The `plutus` repository is updated with an implementation of the proposal.\n- The Implementation Plan MUST include:\n    - The type of release that the change requires.\n\n#### Additions to the Plutus Core Builtins\n\nProposals for additions to the set of Plutus Core builtins SHOULD be proposed in a CIP and SHOULD adhere to the following additional process.\n\nIn order to move to Proposed status:\n- The Specification MUST include:\n    - Names and types/kinds for the new functions or types.\n    - A source for the implementation (e.g. a library which can be linked against); or a generic description of the functionality which is implementable in any programming language.\n    - For new builtin types: a rough description of how the size of a value of that type can be measured.\n    - For new builtin functions: a description of their time and space complexity.\n- The Rationale MUST include:\n    - If an external implementation is provided: an argument that it satisfies the following non-exhaustive list of criteria:\n        - It is trustworthy \n        - It always terminates\n        - It (or its Haskell bindings) never throw any exceptions\n        - Its behaviour is predictable (e.g. does not have worst-case behaviour with much worse performance)\n    - Discussion of how any measures and costing functions were determined.\n- The Acceptance Criteria MUST include:\n    - The ledger is updated to include new protocol parameters to control costing of the new builtins.\n\nThe Rationale of a CIP should always be a clear argument for why the CIP should be adopted.\nIn this case we recommend including:\n- An argument for the utility of the new builtins.\n- Examples of real-world use cases where the new additions would be useful.\n- If feasible, a comparison with an implementation using the existing features, and an argument why the builtin is preferable (e.g. better performance).\n\n#### Protocol parameter updates\n\nProtocol parameter updates that affect Plutus Core should be proposed in the Ledger category and following its processes.\nThe only additional process required is review by the Plutus reviewers.\n\n#### Performance changes \n\nThis CIP does not require any process for proposing performance changes. \n\n#### Bug fixes\n\nA \"bug fix\" is a change to behaviour where:\n- The implemented behaviour does not match the specification; or\n- The specified behaviour is clearly wrong (in the judgement of relevant experts)\n\nIn this case the fix may be submitted directly to the `plutus` repository and is NOT required to go through the CIP process. \nIt must still be released as appropriate. \nFor example, if a bug fix changes behaviour, it will have to wait for a new Plutus Core ledger language.\n\n#### Other changes\n\nProposals for other additions, removals, or changes to behaviour of any part of Plutus Core or its builtins SHOULD be proposed in a CIP.\n\n## Rationale: how does this CIP achieve its goals?\n\n### Do removals and changes really need a new ledger language?\n\nNot being able to make removals or changes to behaviour without a LL is quite painful. \nFor example, it means that we cannot just fix bugs in the semantics: we must remain bug-for-bug compatible with any given LL.\n\nIt is tempting to think that if we can show that a particular behaviour has never been used in the history of the chain, then changing it is backwards-compatible, since it won’t change the validation of any of the actual chain. \nHowever, this is sadly untrue. \n\n1. The behaviour could be triggered (potentially deliberately) in the interval between the update proposal being accepted and it being implemented. This is extremely dangerous and could lead to an un-managed hard fork.\n2. The behaviour could be triggered in a script which has not yet been executed on the chain, but whose hash is used to lock an output. This could lead to that output being unexpectedly un-spendable, or some other change in behaviour. Moreover, since we only have the hash of the script, we have no way of telling whether this is the case.\n\nSo even if a behaviour is obscure, we cannot just change it.\n\n### Are backwards-compatible binary format changes really safe?\n\nChanging the binary format in a backwards compatible way may mean that binary scripts which previously would have been invalid might now deserialize correctly into a program.\n\nThere is a worry here: scripts which fail execution (a phase 2 validation failure) actually get posted on the chain as failures. \nWe must be careful not to turn any such failures into successes, otherwise we could break history.\n\nHowever, we do not need to worry in this case, since checking that a script deserializes properly is a phase 1 validation check, so no scripts will be posted as failures due to failing to deserialize, so we cannot break any such postings by making deserialization more lenient.\n\n### Why do performance changes require extra steps?\n\nPerformance changes must be carefully managed in order to avoid the possibility of an accidental hard fork.\n\nConsider an example of improving performance. \nThe interpreter gets 50% faster (real performance), which is released as a software update. \nNow, we want to lower the cost model parameters (model performance) so that users will be charged fewer resources for their scripts.\n\nHowever, the parameter change means that scripts which previously would have exceeded the transaction/block limit become acceptable. \nThe parameter change is not itself a hard fork, because all the nodes accept the new parameters by consensus. \nBut if the model performance tracks real performance well, then nodes which have not adopted the software update may have issues with the real performance of these newly allowed scripts! \nIn the worst case, they might suffer resource exhaustion, preventing them from following the new chain, which is tantamount to a hard fork.\n\nThis is a relatively unlikely scenario, since it requires a situation where nodes are close enough to their resource limits that an (effective) regression in real performance of scripts can push them over the edge. \nNonetheless, the cautious approach is to not perform such parameter updates until we are sure that all nodes are using a version with the required software update, i.e. after the protocol version has been bumped in a hard fork.\n\nConversely, if (for some reason) we needed to regress the real performance of the interpreter, we should only do this after all the nodes have accepted a regression in model performance (increasing the cost model parameters).\n\n### Why are we concerned about the implementations of builtins being trustworthy?\n\nBuiltin functions in Plutus Core are implemented via Haskell functions. Often these implementations come from somewhere else, e.g. a cryptography library written in C.\n\nIt is vitally important that these libraries are trustworthy. \nThe Plutus Core package (and hence its dependencies) are linked into the Cardano node. \nA buffer overrun vulnerability in the implementation of a builtin function could therefore become an attack on a node.\n\n### Why is the process for new builtins so much more structured?\n\nWe expect additions to builtins to be particularly common, and to have lots of interest from the community.\n\nHowever, the process of adding new builtins is not totally straightforward, due in particular to the need to find a good implementation and to cost it. \nSurfacing these difficulties quickly is a key goal of this process.\n\nFinally, builtins are a comparatively structured extension point for the language. \nIn comparison, proposals for changes to Plutus Core itself are likely to be much more heterogeneous.\n\n### Why are we reluctant to release new ledger language?\n\nLedger languages incur a large maintenance cost. \nEach one must continue to work, perfectly, in perpetuity. Furthermore, they may need their own, independent set of cost model protocol parameters, etc.\n\nSo it is very desirable to keep the number of ledger languages down. \nThe simplest way to do this is to batch changes, and only release a new ledger language occasionally.\n\n## Path to Active\n\n### Acceptance Criteria\n\nThis CIP requires the acceptance of the Plutus team, which it has in virtue of its authorship.\n\n### Implementation Plan\n\nNo implementation is required.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0][].\n\n[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n"
  },
  {
    "path": "CIP-0036/README.md",
    "content": "---\nCIP: 36\nTitle: Catalyst Registration Transaction Metadata Format (Updated)\nCategory: Tools\nStatus: Proposed\nAuthors:\n  - Giacomo Pasini <giacomo.pasini@iohk.io>\n  - Kevin Hammond <kevin.hammond@iohk.io>\n  - Mark Stopka <mark.stopka@perlur.cloud>\nImplementors:\n  - cardano-signer <https://github.com/gitmachtl/cardano-signer>\nDiscussions:\n  - https://forum.cardano.org/t/cip-catalyst-registration-metadata-format/44038\n  - https://github.com/cardano-foundation/CIPs/pull/188\n  - https://github.com/cardano-foundation/CIPs/pull/349\n  - https://github.com/cardano-foundation/CIPs/pull/373\nCreated: 2021-12-06\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nCardano uses a sidechain for its treasury system. One needs to \"register\" to participate on this sidechain by submitting a registration transaction on the mainnet chain. This CIP details the registration transaction format.\nThis is a revised version of the original [CIP-15 | Registration Transaction Metadata Format](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015).\n\n## Motivation: why is this CIP necessary?\n\nCardano uses a sidechain for its treasury system (\"Catalyst\") and for other voting purposes. One of the desirable properties of this sidechain is that even if its safety is compromised, it doesn't cause loss of funds on the main Cardano chain. To achieve this, instead of using your wallet's recovery phrase on the sidechain, we need to use a brand new \"voting key\".\n\nHowever, since 1 ADA = 1 vote, a user needs to associate their mainnet ADA to their new voting key. This can be achieved through a registration transaction.\n\nIn addition, to encourage participation by a broader range of ADA holders, it should be possible to delegate one's rights to vote to (possibly multiple) representatives and/or expert voters. Such delegations will still be able to receive Catalyst rewards. \n\nWe therefore need a registration transaction that serves three purposes:\n\n1. Registers a \"voting key\" to be included in the sidechain and/or delegates to existing \"voting key\"s\n2. Associates mainnet ADA to this voting key(s)\n3. Declares a payment address to receive Catalyst rewards\n\n**Note**: This schema does not attempt to differentiate delegations from direct registrations, as the two options have exactly the same format. It also does not distinguish between delegations that are made as \"private\" arrangements (proxy votes)\nfrom those that are made by delegating to representatives who promote themselves publicly.\nDistinguishing these possibilities is left to upper layers or future revisions of this standard, if required.\nIn this document, we will use the term 'delegations' to refer to all these possibilities.\n\n## Specification\n\n### Registration metadata format\n\nA registration transaction is a regular Cardano transaction with a specific transaction metadata associated with it.\n\nNotably, there should be five entries inside the metadata map:\n - A non-empty array of delegations, as described below;\n - A stake address for the network that this transaction is submitted to (to point to the Ada that is being delegated);\n - A Shelley payment address (see [CIP-0019](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0019)) discriminated for the same network this transaction is submitted to, to receive rewards.\n - A nonce that identifies that most recent delegation\n - A non-negative integer that indicates the purpose of the vote. This is an optional field to allow for compatibility with CIP-15. For now, we define 0 as the value to use for Catalyst, and leave others for future use. A new registration should not invalidate a previous one with a different voting purpose value.\n\n### Delegation format\n\nA delegation assigns (a portion of) the ADA controlled by one or more UTxOs on mainnet to the voting key in the sidechain as voting power.  The UTxOs can be identified via the stake address at some designated point in time.\n\nEach delegation therefore contains:\n  - a voting key: simply an ED25519 public key. This is the spending credential in the sidechain that will receive voting power from this delegation. For direct voting it's necessary to have the corresponding private key to cast votes in the sidechain. How this key is created is up to the wallet.\n  - the weight that is associated with this key: this is a 4-byte unsigned integer (CBOR major type 0, The weight may range from 0 to 2^32-1) that represents the relative weight of this delegation over the total weight of all delegations in the same registration transaction.\n\n### Voting key \n\nThe terms \"(CIP-36) voting keys\" and \"(CIP-36) vote keys\" should be used interchangeably to indicate the keys described in this specification. But it should be made clear that implementations should favour the term \"(CIP-36) vote key\" and that the association of both terms aims to reduce the possibility of confusion.\n\nThe term governance should not be associated with these keys nor should these keys be associated with other vote or voting keys used in the ecosystem. When discussing these keys in a wider context they should be specified by such terminology as \"CIP-36 vote keys\" or \"CIP-36 style vote keys\".\n\n#### Derivation path\n\nTo avoid linking voting keys directly with Cardano spending keys, the voting key derivation path must start with a specific segment:\n\n`m / 1694' / 1815' / account' / chain / address_index`\n\nWe recommend that implementors only use `address_index=0` to avoid the need for voting key discovery.\n\n#### Tooling\n\nSupporting tooling should clearly define and differentiate this as a unique key type, describing such keys as \"CIP-36 vote keys\". When utilizing Bech32 encoding the appropriate `cvote_sk` and `cvote_vk` prefixes should be used as described in [CIP-05](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005).\n\nExamples of acceptable `keyType`s for supporting tools:\n\n| `keyType` | Description |\n| --------- | ----------- |\n| `CIP36VoteSigningKey_ed25519` | Catalyst Vote Signing Key |\n| `CIP36VoteExtendedSigningKey_ed25519` | Catalyst Vote Signing Key |\n| `CIP36VoteVerificationKey_ed25519` | Catalyst Vote Verification Key |\n| `CIP36VoteExtendedVerificationKey_ed25519` | Catalyst Vote Verification Key |\n\nFor hardware implementations:\n| `keyType` | Description |\n| --------- | ----------- |\n| `CIP36VoteVerificationKey_ed25519` | Hardware Catalyst Vote Verification Key |\n| `CIP36VoteHWSigningFile_ed25519` | Hardware Catalyst Vote Signing File |\n\nThe intention with this design is that if projects beyond Catalyst implement this specification they are able to add to themselves `keyType` **Description**s.\n\n### Example - Registration\n\n#### Voting registration example:\n```\n61284: {\n  // delegations - CBOR byte array \n  1: [[\"0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663\", 1], [\"0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee\", 3]],\n  // stake_pub - CBOR byte array\n  2: \"0xad4b948699193634a39dd56f779a2951a24779ad52aa7916f6912b8ec4702cee\",\n  // payment_address - CBOR byte array\n  3: \"0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee47b60edc7772855324c85033c638364214cbfc6627889f81c4\",\n  // nonce\n  4: 5479467\n  // voting_purpose: 0 = Catalyst\n  5: 0\n}\n```\nThe entries under keys 1, 2, 3, 4 and 5 represent the Catalyst delegation array,\nthe staking credential on the Cardano network, the payment address to receive rewards,\na nonce, and a voting purpose, respectively. A registration with these metadata will be\nconsidered valid if the following conditions hold:\n\n- The nonce is an unsigned integer (of CBOR major type 0) that should be \n  monotonically rising across all transactions with the same staking key.\n  The advised way to construct a nonce is to use the current slot number.\n  This is a simple way to keep the nonce increasing without having to access\n  the previous transaction data.\n- The payment address is a Shelley payment address discriminated for the same network\n  this transaction is submitted to.\n- The delegation array is not empty\n- The weights in the delegation array are not all zero\n\nDelegation to the voting key `0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663` will have relative weight 1 and delegation to the voting key `0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee` relative weight 3 (for a total weight of 4).\nSuch a registration will assign 1/4 and 3/4 of the value in ADA to those keys respectively, with any remainder assigned to the second key.\n\nThe registration witness depends on the type of stake credential used.\nTo produce the witness field in case of a staking public key, the CBOR representation of a map containing\na single entry with key 61284 and the registration metadata map in the\nformat above is formed, designated here as `sign_data`.\nThis data is signed with the staking key as follows: first, the\nblake2b-256 hash of `sign_data` is obtained. This hash is then signed\nusing the Ed25519 signature algorithm. The witness metadata entry is\nadded to the transaction under key 61285 as a CBOR map with a single entry\nthat consists of the integer key 1 and signature as obtained above as the byte array value.\n\n#### Witness example:\n```\n61285: {\n  // witness - ED25119 signature CBOR byte array\n  1: \"0x8b508822ac89bacb1f9c3a3ef0dc62fd72a0bd3849e2381b17272b68a8f52ea8240dcc855f2264db29a8512bfcd522ab69b982cb011e5f43d0154e72f505f007\"\n}\n```\n\n### Deregistration metadata format (Catalyst)\n\nThis deregistration format is currently only specified for Catalyst (vote_purpose=0), other voting chain purposes may handle a deregistration in a different way.\nThere was a discussion before if an empty delegation array could also be used to fulfil a deregistration. This idea was cancelled, because it would currently require additional resources in the Hardware-Wallets state machine to do additional checks about an empty array. So the decision was made to leave the registration part untouched and only add the deregistration via the unused key 61286. Wallets/Tools are not forced to support this deregistration method.\n\nDefinition:\n- A deregistration removes all the voting power (associated stake amount) for the provided stake credential from the delegated vote-public-keys.\n- A deregistration resets the state of the stake credential on the voting chain like they were never registered before.\n- A deregistration transaction is a regular Cardano transaction with a specific transaction metadata associated with it.\n\nNotably, there should be three entries inside the metadata map (key 61286):\n - The public key of the stake signing key\n - A nonce that identifies that most recent deregistration.\n - A non-negative integer that indicates the purpose of the vote. For now, we define 0 as the value to use for Catalyst, and leave others for future use.\n\nBe aware, the deregistration metadata key is 61286, and not 61284 like it is used for a registration! The registraton metadata format and specification is independent from the deregistration one, and may not be supported by all wallets/tools.\n \n#### Example - Deregistration (Catalyst)\n\n```\n{\n  61286: {\n    // stake_pub - CBOR byte array\n    1: \"0x57758911253f6b31df2a87c10eb08a2c9b8450768cb8dd0d378d93f7c2e220f0\",\n    // nonce\n    2: 74412400,\n    // voting_purpose: 0 = Catalyst\n    3: 0\n  },\n  61285: {\n    // witness - ED25119 signature CBOR byte array\n    1: \"0xadb7c90955c348e432545276798478f02ee7c2be61fd44d22f9de22131d9bcf0b23eb413766b74b9e7ba740e71266467a5d35363411346972db9e7b710b00603\"\n  }\n}\n```\nCBOR-Hex:\n`A219EF66A301582057758911253F6B31DF2A87C10EB08A2C9B8450768CB8DD0D378D93F7C2E220F0021A046F7170030019EF65A1015840ADB7C90955C348E432545276798478F02EE7C2BE61FD44D22F9DE22131D9BCF0B23EB413766B74B9E7BA740E71266467A5D35363411346972DB9E7B710B00603`\n\nThe entries under keys 1, 2 and 3 represent the staking credential on the Cardano network, a nonce, and a voting purpose, respectively.\nA deregistration with these metadata will be considered valid if the following conditions hold:\n\n- The stake credentials is a stake public-key byte array (of CBOR major type 2)\n- The nonce is an unsigned integer (of CBOR major type 0) that should be \n  monotonically rising across all transactions with the same staking key.\n  The advised way to construct a nonce is to use the current slot number.\n  This is a simple way to keep the nonce increasing without having to access\n  the previous transaction data.\n- The voting_purpose is an unsigned integer (of CBOR major type 0)\n\nTo produce the witness field in case of a staking public key, the CBOR representation of a map containing\na single entry with key 61286 and the deregistration metadata map in the\nformat above is formed, designated here as `sign_data`.\nThis data is signed with the staking key as follows: first, the\nblake2b-256 hash of `sign_data` is obtained. This hash is then signed\nusing the Ed25519 signature algorithm. The witness metadata entry is\nadded to the transaction under key 61285 as a CBOR map with a single entry\nthat consists of the integer key 1 and signature as obtained above as the byte array value.\n\n### Metadata schema\n\nSee the [schema file](./schema.cddl).\n\n### Test vector\n\nSee [test vector file](./test-vector.md).\n\n## Rationale: how does this CIP achieve its goals?\n\n### Associating voting power with a voting key\n\nThis method has been used since Fund 2.\nFor future fund iterations, a new method making use of time-lock scripts may\nbe introduced as described [below][future-development].\n\nRecall: Cardano uses the UTXO model so to completely associate a wallet's balance with a voting key (i.e. including enterprise addresses), we would need to associate every payment key to a voting key individually. Although there are attempts at this (see [CIP-0008]), the resulting data structure is a little excessive for on-chain metadata (which we want to keep small)\n\nGiven the above, we choose to associate staking credentials with voting keys. At the moment, the only supported staking credential is a staking key. Since most Cardano wallets only use base addresses for Shelley wallet types, in most cases this should perfectly match the user's wallet.\n\nThe voting power that is associated with each delegated voting key is derived from the user's total voting power\nas follows.\n\n1. The total weight is calculated as a sum of all the weights;\n2. The user's total voting power is calculated as a whole number of ADA (rounded down);\n3. The voting power associated with each voting key in the delegation array is calculated as the weighted fraction of the\n   total voting power (rounded down);\n4. Any remaining voting power is assigned to the last voting key in the delegation array.\n\nThis ensures that the voter's total voting power is never accidentally reduced through poor choices of weights,\nand that all voting powers are exact ADA.\n\n### Future development\n\n[future-development]: #future-development\n\nA future change of the Catalyst system may make use of a time-lock script to commit ADA on the mainnet for the duration of a voting period. The voter registration metadata in this method will not need an association\nwith a staking credential. Therefore, the `staking_credential` map entry\nand the `registration_witness` payload with key 61285 will no longer\nbe required.\n\n### Changelog\n\nFund 3 added the `reward_address` inside the `key_registration` field.\n\nFund 4:\n- added the `nonce` field to prevent replay attacks;\n- changed the signature algorithm from one that signed `sign_data` directly\n  to signing the Blake2b hash of `sign_data` to accommodate memory-constrained hardware wallet devices.\n\nIt was planned that since Fund 4, `registration_signature` and the `staking_pub_key` entry inside the `key_registration` field will be deprecated.\nThis has been deferred to a future revision of the protocol.\n\nFund 8: \n - renamed the `voting_key` field to `delegations` and add support for splitting voting power across multiple vote keys.\n - added the `voting_purpose` field to limit the scope of the delegations.\n - rename the `staking_pub_key` field to `stake_credential` and `registration_signature` to `registration_witness` to allow for future credentials additions.\n\nFund 10:\n- Replaced the `reward_address` field with `payment_address` field, keeping it at index 3. Stipulating that `payment_address` must be a Shelley payment address, otherwise voting reward payments will not be received.\n  - **Note:** up to Catalyst's Fund 9, voting rewards were paid via MIR transfer to a stake address provided within the `reward_address` field. From Fund 10 onwards, a regular payment address must be provided in the `payment_address` field to receive voting rewards. This allows Catalyst to avoid MIR transfers and instead pay voting rewards via regular transactions.\n\nFund 11:\n - added the `deregistration` metadata format.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] Have this registration format supported in Catalyst infrastructure for two Catalyst funds.\n- [ ] Have this registration format supported by three wallets/tools.\n  - [cardano-signer](https://github.com/gitmachtl/cardano-signer)\n\n### Implementation Plan\n\n- [x] Authors to provide test vector file.\n  - See the [schema file](./schema.cddl).\n- [x] Authors to provide CDDL schema file.\n  - See [test vector file](./test-vector.md).\n- [x] Authors to test this format for security and compatibility with existing Catalyst infrastructure.\n\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0036/schema.cddl",
    "content": "registration_cbor = {\n  61284: key_registration,\n  61285: registration_witness\n}\n\n$cip36_vote_pub_key /= bytes .size 32\n$payment_address /= bytes\n$nonce /= uint\n$weight /= uint .size 4\n$voting_purpose /= uint\nlegacy_key_registration = $cip36_vote_pub_key\ndelegation = [$cip36_vote_pub_key, $weight]\n\n; May support other stake credentials in the future.\n; Such additional credentials should be tagged at the CDDL/CBOR level\n; so that parsing is not ambiguous and future proof.\n; However, to avoid breaking changes, the simple key credential is\n; left untagged.\n$stake_credential /= $staking_pub_key\n$stake_witness /= $ed25519_signature\n; A stake key credential, not tagged for backward compatibility\n$staking_pub_key /= bytes .size 32\n; Witness for a stake key credential, not tagged for backward compatibility\n$ed25519_signature /= bytes .size 64\n\n\nkey_registration = {\n  1 : [+delegation] / legacy_key_registration,\n  2 : $stake_credential,\n  3 : $payment_address,\n  4 : $nonce,\n  ? 5 : $voting_purpose .default 0\n}\n\n\nregistration_witness = {\n  1 : $stake_witness\n}\n\n\nderegistration_cbor = {\n  61286: key_deregistration,\n  61285: deregistration_witness\n}\n\nkey_deregistration = {\n  1 : $stake_credential,\n  2 : $nonce,\n  ? 3 : $voting_purpose .default 0\n}\n\nderegistration_witness = {\n  1 : $stake_witness\n}\n"
  },
  {
    "path": "CIP-0036/test-vector.md",
    "content": "# Test Vector for CIP-0036\n\n## Keys\n\n**Note:** Not all keys are required for certificate recreation.\n\nPayment **private** signing key Hex:\n```\n614fdfe13d403bee2014570b190d81851f17d8daca0b6dd1ce33014403191003\n```\n\nPayment **public** verification Hex:\n```\n7a24dd8e692cec94b612c2ec81f508aada96557c2052a447b9d197b006fa7d2a\n```\n\nStaking **private** signing key Hex:\n```\n852fa5d17df3efdfdcd6dac53ec9fe5593f3c0bd7cadb3c2af76c7e15dfa8a5c\n```\n\nStaking **public** verification key Hex:\n```\ne3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369\n```\n\nCIP-36 Vote **public** verification key Hex:\n```\n0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0\n```\n\nCIP-36 Vote **extended private** signing key Hex:\n```\n4820f7ce221e177c8eae2b2ee5c1f1581a0d88ca5c14329d8f2389e77a465655c27662621bfb99cb9445bf8114cc2a630afd2dd53bc88c08c5f2aed8e9c7cb89\n```\n\n## Addresses\n- This example uses Pre-Production testnet (testnet-magic 1).\n\nPayment Address:\n```\nbech32: \"addr_test1qprhw4s70k0vzyhvxp6h97hvrtlkrlcvlmtgmaxdtjz87xrjkctk27ypuv9dzlzxusqse89naweygpjn5dxnygvus05sdq9h07\"\n\nhex-encoded: \"004777561e7d9ec112ec307572faec1aff61ff0cfed68df4cd5c847f1872b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9\"\n````\n\nStaking Address:\n```\nbech32: \"stake_test1upetv9m90zq7xzk303rwgqgvnje7hvjyqef6xnfjyxwg86gzpmj80\"\n\nhex-encoded: \"e072b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9\"\n```\n\n## Certificate Example\n\n- Assigning all voting power to a single voting key. \n\n### Human Readable Format\n\nLegacy CIP-15 version:\n```javascript\n\"61284\": {\n  \"1\": \"0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0\",\n  \"2\": \"0xe3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369\",\n  \"3\": \"0xe072b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9\",\n  \"4\": 1234\n}\n```\n\nCIP-36 version:\n```javascript\n\"61284\": {\n  \"1\": [[\"0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0\", 1]],\n  \"2\": \"0xe3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369\",\n  \"3\": \"0x004777561e7d9ec112ec307572faec1aff61ff0cfed68df4cd5c847f1872b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9\",\n  \"4\": 1234,\n  \"5\": 0\n}\n```\n\n### CBOR Encoding\n\nLegacy CIP-15 version:\n```\na119ef64a40158200036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0025820e3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e43236903581de072b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9041904d2\n```\n\nCIP-36 version:\n```\na119ef64a501818258200036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a001025820e3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369035839004777561e7d9ec112ec307572faec1aff61ff0cfed68df4cd5c847f1872b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9041904d20500\n```\n\n### Blake2b-256 Hash\n\nLegacy CIP-15 version:\n```\n9946e71b5f6c16150cf431910a0f7dbb8084a992577847802e60d32becb3d6be\n```\n\nCIP-36 version:\n```\n3110fbad72589a80de7fc174310e92dac35bbfece1690c2dce53c2235a9776fa\n```\n\n## Metadata Example with Witness\n\nLegacy CIP-15 version:\n```javascript\n{\n  \"61284\": {\n    \"1\": \"0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0\",\n    \"2\": \"0xe3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369\",\n    \"3\": \"0xe072b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9\",\n    \"4\": 1234\n  },\n  \"61285\": {\n    \"1\": \"0xa9ec8735804c6c4c5c4a02e9589c65508ec7060063b2d7dbeba82d1cbfa1b8be6b457f95d4ead5e8b454b989624fa44e0b89a64d089fdc0a6a1268fef4876d0f\" \n  }\n}\n```\n\nCIP-36 version:\n```javascript\n{\n  \"61284\": {\n    \"1\": [[\"0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0\", 1]],\n    \"2\": \"0xe3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369\",\n    \"3\": \"0x004777561e7d9ec112ec307572faec1aff61ff0cfed68df4cd5c847f1872b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9\",\n    \"4\": 1234,\n    \"5\": 0\n  },\n  \"61285\": {\n    \"1\": \"0xcbb96ba1596fafc18eec84e306feea3067ba1c6ace95b11af820bcbd53837ef32bdcf28176749061e1f2a1300d4df98c80582722786e40cf330072d0b78a7408\"\n  }\n}\n```"
  },
  {
    "path": "CIP-0037/README.md",
    "content": "---\nCIP: 37 \nTitle: Dynamic Saturation Based on Pledge\nStatus: Proposed\nCategory: Ledger\nAuthors:\n  - Casey Gibson <caseygibson@protonmail.ch>\nImplementors: []\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/163\nCreated: 2021-12-03\nLicense: CC-BY-4.0  \n---\n\n## Abstract\n\nThe pledge should be used to calculate the saturation point of a pool: setting a maximum delegation proportional to pledge.\n\n## Motivation: why is this CIP necessary?\n\nCurrently Cardano has been plagued with an ever increasing amount of single entity Stake Pool Operators (SPO) creating multiple pools. The pools that are known to be operated by single entity SPOs account for just 18.72% of the total stake and 50% of the total stake can be attributed to at least 23 single entities (as of 3rd Dec 2021).\n\nThe vision of Cardano is that it everyone should be able to have the opportunity to be able to run a stake pool regardless of their financial capabilities and this is even more important for developing countries.\n\nThe issue we're currently facing is that many SPOs have been able to exploit a loophole that has allowed them to use their influence to create many sub-pools without any restrictions. As the size of their pools grow, instead of honouring the saturation limits already in place, they are bypassing them by creating more sub-pools. From a technical point, it is theoretically possible for a single entity to run enough stake pools to control more then 50% of the total stake. \n\nWhile unlikely, the system does not take into account external influences (eg. political) that could harm the system. Shelly has been active for less then 2 years and we are already seeing the risks on a small scale. As real world adoption continues, there could be situations in the next decade that could jeopardise the decentralisation of Cardano. One example could be that a political party could run a ISPO (Initial Stake Pool Offering) on a mass scale. Seeing as Cardano has the potential to be used for voting (even at a political level), the integrity of Cardano could be questioned if political parties controlled stake pools with large shares of total stake. \n\nThe pledge used in a pool was meant to show how serious a SPO is and how much \"skin in the game\" they had. The idea was that if they have more pledge, they have more to lose if something goes wrong. This seems to have lost it's meaning as SPOs that already have a dominating position have created many sub-pools. Some have split up their pledge evenly, some have next to no pledge and have gained high amounts of stake through influential means. This has not only reduced the security of Cardano, but has also lost the meaning of having pledge in the pool. \n\nFor example, a SPO might have a pledge of 30,000 ADA across 10 pools, while another SPO might have 1,000,000 pledge but only has 1 pool with a small amount of active stake. Seeing as the SPO with 1M pledge has more overall, they have more to lose and should be trusted more. Since there is no technical advantage to having a high pledge, the meaning and purpose of a pledge is redundant.\n\nTo make the pledge a meaningful metric that is fair to all SPOs and aligns with the core values of Cardano, the pledge should be used to calculate the saturation point of a pool. This will mean that SPOs, no matter how many pools they operate, will have a maximum saturation based on their total pledge. For example, if a pool operates a single pool and wanted to open up another pool with the same amount of stake, they will have to assign the equal amount of pledge against that new pool. If a pool wishes to up their saturation point, they will need to assign a higher amount of pledge.\n\nThis proposal has had active discussions for over 6 months and is now waiting for a review from IOG to provide feedback on the feasibility and soundness of the approach.\n\n1. This CIP should be considered a medium priority as it directly impacts the health and growth of the Cardano ecosystem. Large Cardano pools have had several years to take advantage of the lack of oversight and have control of a large portion of mining operations. This continued lack of restrictions will further damage the trust and reliability of the framework.\n\n2. Timelines around the implementation of the CIP will depend on urgency, however its implementation should be trivial as there are no new parameters required or risks involved. Further this CIP from a high-level aspect only requires an update to the existing algorithm. From an external context, the CIP will require trivial updates as it should be self-contained in cardano-node.\n\n## Specification\n\nFor this to be able to work, there firstly needs to be an upper limit and a lower limit. The K parameter can still be used as the upper saturation limit of a single pool. As in, if a SPO has enough pledge assigned to a single pool, that pool will be able to run at the maximum saturation point of K. The lower limit is in place to safe guard small SPOs and allow them to grow.\n\nAn example of how Dynamic Saturation would be calculated:\n\n500,000 ADA Pledged = Saturation point at 100% of K\n\n250,000 ADA Pledged = Saturation point at 50% of K\n\n125,000 ADA Pledged = Saturation point at 25% of K\n\n62,500 ADA Pledged = Saturation point at 12.5% of K\n\nTo not penalise small pools, there should be a lower limit saturation point, such as 10% of K. Based on this, a pool with a pledge of 50,000 has the same saturation point as a pool with 25,000 pledge, both being 10% of K. This will allow smaller pools to still have some growth potential.\n\nThe only way a pool can receive more stake across all their pools without impacting their rewards is to increase their total pledge.\n\nExample with SPO of 1,000,000 Pledge with current k implementation:\n\n| Pools | Pledge    | Saturation Per Pool | Total Stake | Fees                 |\n|-------|-----------|---------------------|-------------|----------------------|\n| 1     | 1,000,000 | 100% of K           | ~65M        | 340 fee + margin     |\n| 2     | 500,000   | 100% of K           | ~130M       | 340 fee + margin x2  |\n| 4     | 250,000   | 100% of K           | ~260M       | 340 fee + margin x4  |\n| 8     | 125,000   | 100% of K           | ~520M       | 340 fee + margin x8  |\n| 16    | 62,500    | 100% of K           | ~1040M      | 340 fee + margin x16 |\n\nExample with SPO of 1,000,000 Pledge with Dynamic Saturation:\n\n| Pools | Pledge    | Saturation Per Pool | Total Stake | Fees                 |\n|-------|-----------|---------------------|-------------|----------------------|\n| 1     | 1,000,000 | 100% of K           | ~65M        | 340 fee + margin     |\n| 2     | 500,000   | 100% of K           | ~130M       | 340 fee + margin x2  |\n| 4     | 250,000   | 50% of K            | ~130M       | 340 fee + margin x4  |\n| 8     | 125,000   | 25% of K            | ~130M       | 340 fee + margin x8  |\n| 16    | 62,500    | 12.5% of K          | ~130M       | 340 fee + margin x16 |\n\nAs we can see above with the **current** implementation of K, a pool owner can split the pool and double their delegators active stake (or however many times they split).\n\nThe Dynamic Saturation method caps the pools so that the amount of total stake across all pools is the same no matter how much they split up their pledge and the only benefit will be the extra fee collected (340 ADA) per pool.\n\nThis will mean that the saturation metric will have a direct corelation to an SPOs total pledge.\n\n### Proposals Based On Feedback\n\nAfter some discussions among the community and some help from https://github.com/cffls, the below code example has been proposed for how the dynamic saturation could work.\n\n```\nlet lovelace = 1000000;\n\nfunction calc_sat(pledge){\n    k = 500;\n    e = 0.2;\n    l = 125;\n    total_supply = 33719282563 * lovelace;\n    orig_sat = total_supply / k;\n    new_sat = orig_sat * Math.max(e, min(1 / k, pledge / orig_sat * l));\n    final_sat = max(new_sat, orig_sat);\n    console.log(`pledge: ${pledge / lovelace}, sat: ${final_sat / lovelace}`);\n}\n\nfunction max(val1, val2){\n    if(val1 < val2){\n        return val1;\n    }\n    return val2;\n}\n\nfunction min(val1, val2){\n    if(val1 > val2){\n        return val1;\n    }\n    return val2;\n}\n\ncalc_sat(50000 * lovelace);\ncalc_sat(100000 * lovelace);\ncalc_sat(150000 * lovelace);\ncalc_sat(250000 * lovelace);\ncalc_sat(500000 * lovelace);\ncalc_sat(750000 * lovelace);\ncalc_sat(1000000 * lovelace);\ncalc_sat(2000000 * lovelace);\n```\n\nResults:\n\n```\n[Log] pledge: 50000, sat: 13487713.0252\n[Log] pledge: 100000, sat: 13487713.0252\n[Log] pledge: 150000, sat: 18750000\n[Log] pledge: 250000, sat: 31250000\n[Log] pledge: 500000, sat: 62500000\n[Log] pledge: 750000, sat: 67438565.126\n[Log] pledge: 1000000, sat: 67438565.126\n[Log] pledge: 2000000, sat: 67438565.126\n```\n\n## Rationale: how does this CIP achieve its goals?\n\nSince a single entity SPO only has a certain amount of ADA they can pledge, they will eventually hit their saturation point no matter how many pools they create. The only way they can add more delegators is to increase their pledge. Once they run out of pledge and reach their saturation point, the delegators will have no choice but to move to another SPO and increase decentralisation.\n\nIn the above example, the base pledge of 500,000 ADA should be set as a parameter that can be adjusted in the future. E.g, if it is found that it is too low or too high to gain 100% saturation, it can be adjusted in the same way k can be adjusted.\n\nOne of the questions raised by the community was, will the lower limit stop the growth of small pools if it is set at a level where they can't reach the expected annual 5% return on ADA. This case could be handled a few ways, but the main aim would be to keep it at a sustainable amount for small pools.\n\n1. The value is a percentage of k, such as 10%. This percentage could increase as needed, such as to 15% of k.\n2. The value could be calculated based on the average of active stake compared to active pools. E.g, active stake = 23837 M / 3000 = saturation point of 7.94 M ADA\n\n## Path To Active\n\n### Acceptance Criteria\n\n- [ ] The new relationship between pledge and saturation defined here is implemented in the Ledger and enacted through a hard-fork.\n\n### Implementation Plan\n\n- [ ] Agreement by the Ledger team as defined in [CIP-0084](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0084) under _Expectations for ledger CIPs_ including \"expert opinion\" on changes to rewards & incentives.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n"
  },
  {
    "path": "CIP-0040/README.md",
    "content": "---\nCIP: 40\nTitle: Collateral Output\nStatus: Active\nCategory: Ledger\nAuthors:\n  - Sebastien Guillemot <seba@dcspark.io>\n  - Jared Corduan <jared.corduan@iohk.io>\n  - Andre Knispel <andre.knispel@iohk.io>\nImplementors: N/A\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/216\nCreated: 2022-02-10\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis document describes adding a new output type to transactions called Collateral Outputs.\n\n## Motivation: why is this CIP necessary?\n\nAs of Alonzo, transactions that call Plutus smart contracts are required to put up collateral to cover the potential cost of smart contract execution failure. Inputs used as collateral have the following properties:\n\n1. Cannot contain any tokens (only ADA)\n2. Cannot be a script address\n3. Must be a UTXO input\n4. Must be at least some percentage of the fee in the tx (concrete percentage decided by a protocol parameter)\n5. Can be the same UTXO entry as used in non-collateral tx input\n6. Is consumed entirely (no change) if the contract execution fails during phase 2 validation\n7. Is not consumed if phase phase 2 validation succeeds\n\nAdditionally, there cannot be more than *maxColInputs* (protocol parameter) inputs and the inputs have to cover a percentage of the fee defined by *collateralPercent* (protocol parameter)\n\nHowever,\n\n- Restriction #1 is problematic because hardcore dApp users rarely have UTXO entries that do not contain any tokens. To combat this, wallets have created a special wallet-dependent \"collateral\" UTXO to reserve for usage of collateral for dApps which is not a great UX.\n- Restriction #6 is problematic because wallets want to protect users from signing transactions with large collateral as they cannot verify whether or not the transaction will fail when submitted (especially true for hardware wallets)\n\n## Specification\n\nIf phrase-2 verification fails, we can send outputs to a special output marked as the collateral output.\n\nThere are two ways to create collateral outputs\n\n1. Add collateral outputs as a new field inside the transaction. This change is similar to how collateral inputs were created a new field\n2. Change the definition of outputs as `TxOut = Addr × Value × DataHash? × Source?` where source (optional for backwards compatibility) is an enum `0 = regular output, 1 = collateral output`.\n\nOption #1 provides the best backwards compatibility because we don't expect phase-2 validation to be a common occurrence and so wallets that (due to not being updated) never check collateral outputs will still in the overwhelming majority of cases return the correct result.\n\nAdditionally, this requires updating the collateral requirement.\n\nIf no collateral output is specified (and therefore no tokens are in the collateral input), then we keep the old definition\n\n```\nubalance (collateral txb ◁ utxo) ≥ quot (txfee txb * (collateralPercent pp)) 100\n```\n\nHowever, if collateral output is specified, then\n1. Each collateral output needs to satisfy the same minimum ADA requirement as regular outputs\n2. Collateral output needs to be balanced according to `sum(collateral_input) = sum(collateral_output) + collateral_consumed`\nWhere `collateral_consumed` is equal to the old formula (`quot (txfee txb * (collateralPercent pp)) 100`). Note that when collateral is consumed, any certificate, etc. in the transaction is ignored so they have no impact on the change calculation.\n\n## Rationale: how does this CIP achieve its goals?\n\n### Self-contained balancing\n\nSome use-cases like hardware wallets, who do not have access to the content of the collateral inputs, cannot easily check if the collateral is balanced. Similar to how we specify an explicit fee as part of the transaction body to tackle this problem, the transaction body also needs a new field that explicitly specified how much collateral will be consumed in the case of phase-2 validation failure.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Fully implemented in Cardano as of the Vasil protocol upgrade.\n\n### Implementation Plan\n\n- [x] Passes all Ledger team requirements for desirability and feasibility.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0042/README.md",
    "content": "---\nCIP: 42\nTitle: New Plutus Builtin serialiseData\nStatus: Active\nCategory: Plutus\nAuthors:\n  - Matthias Benkort <matthias.benkort@iohk.io>\n  - Sebastian Nagel <sebastian.nagel@iohk.io>\nImplementors: \n  - Michael Peyton Jones <michael.peyton-jones@iohk.io>\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/218\nCreated: 2022-02-09\nLicense: Apache-2.0\n\n---\n\n## Abstract\n\nThis document describes the addition of a new Plutus builtin for serialising `BuiltinData` to `BuiltinByteString`.\n\n## Motivation: why is this CIP necessary?\n\nAs part of developing on-chain script validators for [the Hydra Head protocol](https://eprint.iacr.org/2020/299), we stumble across a peculiar need for on-chain scripts: we need to verify and compare digests obtained from hashing elements of the script's surrounding transaction.\n\nIn this particular context, those elements are transaction outputs (a.k.a. `TxOut`). While Plutus already provides built-in for hashing data-structure (e.g. `sha2_256 :: BuiltinByteString -> BuiltinByteString`), it does not provide generic ways of serialising some data type to `BuiltinByteString`.\n\nIn an attempt to pursue our work, we have implemented [an on-chain library (plutus-cbor)][plutus-cbor] for encoding data-types as structured [CBOR / RFC 8949][CBOR] in a _relatively efficient_ way (although still quadratic, it is as efficient as it can be with Plutus' available built-ins) and measured the memory and CPU cost of encoding `TxOut` **in a script validator on-chain**.\n\n![](https://i.imgur.com/AtHE0p4.png)\n\nThe above graph shows the memory and CPU costs **relative against a baseline**, of encoding a `TxOut` using `plutus-cbor` in function of the number of assets present in that `TxOut`. The costs on the y-axis are relative to the maximum execution budgets (as per mainnet's parameters, December 2021) allowed for a single script execution. As can be seen, this is of linear complexity, i.e. O(n) in terms of the number of assets. These results can be reproduced using the [encoding-cost][] executable in our repository.\n\n> Note that we have also calculated similar costs for ada-only `TxOut`, in function of the number of `TxOut` which is about twice as worse but of similar linear shape.\n\nWe we can see on the graph, the cost is manageable for a small number of assets (or equivalently, a small number of outputs) but rapidly becomes limiting. Ideally, we would prefer the transaction size to be the limiting factor when it comes to the number of outputs we can handle in a single validation.\n\nBesides, in our discussions with the Marlowe team, we also discovered that they shared a similar problem when it came to serialising merkleized ASTs.\n\nUnderneath it all, it seems that it would be beneficial to have a new built-in at our disposal to serialise any Plutus `BuiltinData` to `BuiltinByteString` such that validators could leverage more optimized implementations and bytestring builders via built-ins than what's available on-chain, hopefully reducing the overall memory and CPU costs.\n\n## Specification\n\n### Function definition\n\nWe define a new Plutus built-in function with the following type signature:\n\n```hs\nserialiseData :: BuiltinData -> BuiltinByteString\n```\n\n### Binary data format\n\nBehind the scene, we expect this function to use a well-known encoding format to ease construction of such serialisation off-chain (in particular, for non-Haskell off-chain contract codes). A natural choice of binary data format in this case is [CBOR][] which is:\n\n1. Efficient;\n2. Relatively simple;\n3. Use pervasively across the Cardano ecosystem\n\nFurthermore, the Plutus' ecosystem already provides [a _quite opinionated_ implementation of a CBOR encoder][encodeData] for built-in `Data`. For the sake of documenting it as part of this proposal, we provide here-below the CDDL specification of that existing implementation:\n\n```cddl\nplutus_data =\n    constr<plutus_data>\n  / { * plutus_data => plutus_data }\n  / [ * plutus_data ]\n  / big_int\n  / bounded_bytes\n\nconstr<a> =\n    #6.121([])\n  / #6.122([a])\n  / #6.123([a, a])\n  / #6.124([a, a, a])\n  / #6.125([a, a, a, a])\n  / #6.126([a, a, a, a, a])\n  / #6.127([a, a, a, a, a, a])\n  ; similarly for tag range: #6.1280 .. #6.1400 inclusive\n  / #6.102([uint, [* a]])\n\nbig_int = int / big_uint / big_nint\nbig_uint = #6.2(bounded_bytes)\nbig_nint = #6.3(bounded_bytes)\n\nbounded_bytes = bytes .size (0..64)\n```\n\n> NOTE: The CDDL specification is extracted from the wider [alonzo_cddl specification][] of the Cardano ledger.\n\n### Cost Model\n\nThe `Data` type is a recursive data-type, so costing it properly is a little tricky. The Plutus source code defines an instance of `ExMemoryUsage` for `Data` with [the following interesting note](https://github.com/input-output-hk/plutus/blob/37b28ae0dc702e3a66883bb33eaa5e1156ba4922/plutus-core/plutus-core/src/PlutusCore/Evaluation/Machine/ExMemory.hs#L205-L225):\n\n> This accounts for the number of nodes in a `Data` object, and also the sizes of the contents of the nodes.  This is not ideal, but it seems to be the best we can do. At present this only comes into play for 'equalsData', which is implemented using the derived implementation of '==' [...].\n\nWe propose to re-use this instance to define a cost model linear in the size of data defined by this instance. What remains is to find a proper coefficient and offset for that linear model. To do so, we can benchmark the execution costs of encoding arbitrarily generated `Data` of various sizes, and retro-fit the cost into a linear model (provided that the results are still attesting for that type of model).\n\nBenchmarking and costing `serialiseData` was done in [this PR](https://github.com/input-output-hk/plutus/pull/4480) according to this strategy. As the benchmark is not very uniform, because some cases of `Data` \"structures\" differ in CPU time taken to process, the linear model is used as an **upper bound** and thus conservatively overestimating actual costs.\n\n## Rationale: how does this CIP achieve its goals?\n\n* Easy to implement as it reuses existing code of the Plutus codebase;\n* Such built-in is generic enough to also cover a wider set of use-cases, while nicely fitting ours;\n* Favoring manipulation of structured `Data` is an appealing alternative to many `ByteString` manipulation use-cases;\n* CBOR as encoding is a well-known and widely used standard in Cardano, existing tools can be used;\n* The hypothesis on the cost model here is that serialisation cost would be proportional to the `ExMemoryUsage` for `Data`; which means, given the current implementation, proportional to the number and total memory usage of nodes in the `Data` tree-like structure.\n* Benchmarking the costs of serialising `TxOut` values between [plutus-cbor][] and [cborg][] confirms [cborg][] and the existing [encodeData][]'s implementation in Plutus as a great candidate for implementing the built-in:\n\n  ![](https://i.imgur.com/6GWrIHb.png)\n\n  Results can be reproduced with the [plutus-cbor benchmark][].\n\n### Alternatives\n\n* We have identified that the cost mainly stems from concatenating bytestrings; so possibly, an alternative to this proposal could be a better way to concatenate (or to cost) bytestrings (Builders in Plutus?)\n\n* If costing for `BuiltinData` is unsatisfactory, maybe we want have only well-known input types, e.g. `TxIn`, `TxOut`, `Value` and so on.. `WellKnown t => t -> BuiltinByteString`\n\n### Backward Compatibility\n\n* Additional built-in: so can be added to PlutusV1 and PlutusV2 without breaking any existing script validators. A hard-fork is however required as it would makes more blocks validate.\n\n## Path To Active\n\n### Acceptance Criteria\n\n- [x] Release it as a backward-compatible change within the Vasil protocol upgrade\n\n### Implementation Plan\n\n- [x] Using the existing _sizing metric_ for `Data`, determine a costing function (using existing tooling / benchmarks? TBD)\n- [x] The Plutus team updates plutus to add the built-in to PlutusV1 and PlutusV2 and uses a suitable cost function\n- [x] The binary format of `Data` is documented and embraced as an interface within `plutus`. (see [cardano-ledger's CDDL specification](https://github.com/IntersectMBO/cardano-ledger/blob/faa40b812511bfb6592cdfbdd85fe560cbcaed43/eras/babbage/impl/cddl-files/babbage.cddl#L306-L311))\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0).\n\n[CBOR]: https://www.rfc-editor.org/rfc/rfc8949\n[plutus-cbor]: https://github.com/input-output-hk/hydra-poc/tree/a4b843a040897e45120cb63b666d965759091651/plutus-cbor\n[cborg]: https://hackage.haskell.org/package/cborg-0.2.4.0\n[encoding-cost]: https://github.com/input-output-hk/hydra-poc/tree/759fee84475f951aaf2f35acdb8ab82094ec5fbf/plutus-cbor/exe/encoding-cost/Main.hs\n[alonzo_cddl specification]: https://github.com/input-output-hk/cardano-ledger/blob/aebd64e015ec0825776c256faed9d8632712beb0/eras/alonzo/test-suite/cddl-files/alonzo.cddl#L276-L296\n[encodeData]: https://github.com/input-output-hk/plutus/blob/1f31e640e8a258185db01fa899da63f9018c0e85/plutus-core/plutus-core/src/PlutusCore/Data.hs#L108\n[plutus-cbor benchmark]: https://github.com/input-output-hk/hydra-poc/tree/759fee84475f951aaf2f35acdb8ab82094ec5fbf/plutus-cbor/bench/Main.hs\n"
  },
  {
    "path": "CIP-0045/README.md",
    "content": "---\nCIP: 45\nTitle: Decentralized WebRTC dApp-Wallet Communication\nStatus: Active\nCategory: Wallets\nAuthors: \n    - Fabian Bormann <fabian.bormann@cardanofoundation.org>\n    - Jaime Caso <jaime.caso@cardanofoundation.org>\nImplementors:\n    - Fabian Bormann <fabian.bormann@cardanofoundation.org>\n    - Jaime Caso <jaime.caso@cardanofoundation.org>\nDiscussions: \n    - https://github.com/cardano-foundation/CIPs/pull/395\nCreated: 2022-11-29\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nWe want to introduce a decentralized communication method between dApps and wallets based on WebTorrent trackers and WebRTC. This CIP also contains a proof of concept implementation injecting the wallet rpc methods into the dApps global window object similar to [CIP-0030](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030).\n\n## Motivation\n\nIn a decentralized ecosystem a communication between wallet-apps and dApps is still challanging. The inter-app communication on mobile devices does not directly allow remote procedure calls and is mostly restricted to Universal Links (iOS) or Deeplinks (Android). State-of-the-art solutions like WalletConnect tackle these problems using WebRTC communication which also works across devices, but requires a central signaling server to estalblish a WebRTC connection. In this CIP we want to introduce an architecture which uses WebTorrent trackers for the peer discovery to remove the need of this central component. \n\n## Specification\n\n### Establish a WebRTC Connection Using a Signaling Server (State-of-the-art approach)\n\n```mermaid\nsequenceDiagram\n    dApp-->>+Signaling Server: Who am I?\n    Signaling Server-->>dApp: You are <ip:port>\n    Wallet-->>+Signaling Server: Who am I?\n    Signaling Server-->>Wallet: You are <ip:port>\n    dApp->>Wallet: messages\n    Wallet->>dApp: messages\n```\n\nThe data will be send peer to peer via a WebRTC data channel once the ip discovery has been finished. E.g. WalletConnect expects/provides a relay server URL to initialize the connection. While this method allows dApps to communitcate peer-to-peer with wallets it also leads to a [possible SPOF](https://twitter.com/walletconnect/status/1407279853943001088?lang=en).\n\n### Establish a WebRTC Connection Using WebTorrent Tracker (Our approach)\n\n```mermaid\nflowchart LR\n    subgraph dApp\n        subgraph .torrent server\n        end\n    end\n\n    subgraph Wallet[Wallet App]\n    end\n\n    dApp-->|.torrent| TrackerA[Tracker 1]\n    dApp-->|.torrent| TrackerB[Tracker 2]\n    dApp-->|.torrent| TrackerC[...]\n    dApp-->|.torrent| TrackerD[Tracker n]\n\n    dApp-->|.torrent| TrackerA[Tracker 1]\n    dApp-->|.torrent| TrackerB[Tracker 2]\n    dApp-->|.torrent| TrackerC[...]\n    dApp-->|.torrent| TrackerD[Tracker n]\n\n    dApp-->|Share public key| Wallet \n```\n\nDeep links, Universal Links, or even the clipboard could be utilized to share the identifier (public key) on the same device (in cases of a wallet based on web technology like Ionic). For sharing the identifier across different devices, QR codes would come into play. This method could be applied, for example, between a wallet mobile app and a dapp running on a PC, or vice versa. The wallet application would then initiate a query to a list of trackers using this distinct identifier in order to establish the WebRTC connection. After this process is completed, the data is transmitted peer-to-peer following the WebRTC standard, for instance, to invoke RPC calls.\n\n```mermaid\nflowchart LR\n    Wallet-->|queries| TrackerA[Tracker 1]\n    Wallet-->|queries| TrackerB[Tracker 2]\n    Wallet-->|queries| TrackerC[...]\n    Wallet-->|queries| TrackerD[Tracker n]\n\n    Wallet-->|queries| TrackerA[Tracker 1]\n    Wallet-->|queries| TrackerB[Tracker 2]\n    Wallet-->|queries| TrackerC[...]\n    Wallet-->|queries| TrackerD[Tracker n]\n\n    subgraph dApp\n        subgraph .torrent server\n        end\n    end\n\n    Wallet<--Establish WebRTC data channel\\n for peer to peer communication-->dApp\n```\n\n#### CIP-0013 Compliant Identifiers\n\nThe keys (public key and corresponding 64-byte secret key) are generated using a function that implements Ed25519. This function requires a (random) seed, which can also be stored and re-used to ensure that whenever a client employs a dApp or a Wallet, the same key pair is generated consistently, even if the browser or mobile app is restarted. The public key will be used as an identifier for the torrent-based peer discovery. When this identifier is shared through methods like QR codes or links, it needs to be compliant to the following Cardano Uri Scheme [(CIP-0013)](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013): \n\n| [scheme]\t    | [authority] |\t[version]  |\t[data]    |\n|---------------|-------------|------------|--------------|\n| web+cardano:  |\t//connect |\t/v1\t       | ?identifier= | \n\n```\nweb+cardano://connect/v1?identifier=<public_key>\n```\n### Proof of Concept \n\nThe idea of using WebTorrent trackers instead of signaling servers for peer discovery was already mentioned in [Aug 2018 by Chris McCormick](https://mccormick.cx/news/entries/on-self-hosting-and-decentralized-software):\n \"I've also been tinkering with WebTorrent. [...]\nWorking with this technology made me realise something the other day: it's now possible to host back-end services, or \"servers\" inside browser tabs. [...] So anyway, I've made this weird thing to enable developers to build \"backend\" services which run in browser tabs\"\n\nMcCormick's idea has been developed and open sourced as a library called [bugout](https://github.com/chr15m/bugout/) (MIT).\n\nFor this proof of concept we wrote two small pieces of software:\n\n- A html page aka the dApp\n- An ionic react app (to target mutliple devices) aka the wallet app\n\nThe whole code is provided within this [demo implementation](https://github.com/fabianbormann/WebRTC-WebTorrent-tracker-communication-demo) that also contains a step-by-step guide.\n\n#### dApp\n\nThe dApp consists of a standard HTML5 template including the following lines of code:\n\n```html\n<script src=\"https://chr15m.github.io/bugout/bugout.min.js\"></script>\n<script>\n    var bugout = new Bugout({ \n        seed: localStorage[\"poc-server-seed\"],\n        announce: [\n            'udp://tracker.opentrackr.org:1337/announce', \n            'udp://open.tracker.cl:1337/announce', \n            'udp://opentracker.i2p.rocks:6969/announce', \n            'https://opentracker.i2p.rocks:443/announce',\n            'wss://tracker.files.fm:7073/announce',\n            'wss://spacetradersapi-chatbox.herokuapp.com:443/announce',\n            'ws://tracker.files.fm:7072/announce'\n        ]\n        });\n    localStorage[\"poc-server-seed\"] = bugout.seed;\n\n    var connected = false;\n    bugout.on(\"connections\", function (clients) {\n        if (clients == 0 && connected == false) {\n            connected = true;\n            console.log(\"[info]: server ready\");\n            console.log(`[info]: share this address with your wallet app -> ${bugout.address()}`);\n        }\n        console.log(`[info]: ${clients} clients connected`);\n    });\n\n    bugout.register(\"api\", function (address, args, callback) {\n        const api = { version: args.api.version, address: address }\n\n        for (method of args.api.methods) {\n            api[method] = () => new Promise((resolve, reject) => {\n                bugout.rpc(address, method, {}, (result) => resolve(result));\n            });\n        }\n\n        window.cardano = window.cardano || {};\n        window.cardano[args.api.name] = api;\n        console.log(`[info]: injected api of ${args.api.name} into window.cardano`);\n    });\n</script>\n```\n\n#### Wallet App\n\nThe wallet app is a standard ionic react app built by the ionic cli:\n\n```zsh\nionic start WalletApp blank --type=react\ncd WalletApp\nnpm i bugout\n```\n\nThe following lines of code were added to the index.tsx file:\n\n```js\nconst bugout = new Bugout(\n  \"<HASH provided by the dAPP>\", {\n    announce: [\n      'udp://tracker.opentrackr.org:1337/announce', \n      'udp://open.tracker.cl:1337/announce', \n      'udp://opentracker.i2p.rocks:6969/announce', \n      'https://opentracker.i2p.rocks:443/announce',\n      'wss://tracker.files.fm:7073/announce',\n      'wss://spacetradersapi-chatbox.herokuapp.com:443/announce',\n      'ws://tracker.files.fm:7072/announce'\n    ]\n  });\n\nbugout.on(\"server\", function() {\n  console.log(\"[info]: connected to server\")\n  bugout.rpc(\"<HASH provided by the dAPP>\", \"api\", {\"api\": {\n    version: \"1.0.3\",\n    name: 'boostwallet',\n    methods: [\"getRewardAddresses\"]\n  }});\n});\n\nbugout.register(\"getRewardAddresses\", (address:string, args:any, callback:Function) => {\n    callback([\"e1820506cb0ce54ae755b2512b6cf31856d7265e8792cb86afc94e0872\"]);\n});\n```\n\nThis example has a few restrictions:\n\n1. bugout is currently not compatible with Webpack 5, so polyfills are not automatically included and a react-scripts eject is needed to add them to the webpack.config.js file\n\n2. bugout does not directly provide type declarations. There are some declarations within a [PR](https://github.com/chr15m/bugout/pull/45), but they need to be adjusted (a few parameters are not mandatory) and added to a bugout.d.ts file.\n \n### User Flow\n\n```mermaid\nsequenceDiagram\n    dApp-->>Wallet: Share address using Deeplink /Universal Link / QR\n    Wallet-->>Tracker List: Accept connection and start quering using the address\n    Wallet-->>dApp: Once connected register RPC functions and share the API\n    dApp-->>dApp: Inject the API to window.cardano[walletName]\n    dApp-->>Wallet: Call RPC functions (e.g. getRewardAddresses)\n    Wallet-->>Wallet: If needed bring app to foregrund (e.g. request signing)\n    Wallet-->>dApp: Send response\n```\n\n### Security Aspects\n\nWe decided to spawn the server within the dApp to force the user to manually scan a QR code (using a wallet app) or accept an \"Open with `<WalletAppName>`\" ui dialog (in case of Universal Links or Deeplinks). This prevents the user from connecting the wallet to an unwanted dApp. Additionally we need to add  a few security checks to prevent a misusage of this method.\n\n- The wallet app needs to verifiy the origin (address) of the RPC call\n- dApps should ask the user for permission to inject the wallet names into the window.cardano object to prevent XSS attack (Maybe using a graphical representation of the wallet app address e.g. blockies)\n\n## Rationale\n\nThe purpose of this CIP mainly consists of two parts. It addresses the current lack of dApp mobile support, but at the same time provides an even more decentralized alternative to state-of-the-art communication methods. To achieve this goal we have introduced a WebTorrent and WebRTC based architecture. To demonstrate a viable implementation, we have implemented a proof of concept which also shows how a rpc method injection like CIP-0030 might look like.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] A library should be build to make it easy from dAPP and wallet side to implement the proposed communication method\n- [x] The library target should be browser to avoid the need of manual polyfills\n- [x] Mobile testing on different devices and operating systems needs to be done with a special focus to the wallet app running in background mode\n- [x] Potential security issues and attack vectors need to be discussed in detail\n    1. We discussed potential security issues in the [CIP discussion](https://github.com/cardano-foundation/CIPs/pull/395#issuecomment-1669460822) and we\n      implement an identicon solutin, but it is obviously an never ending task      \n- [x] A full reference implementation is needed to test if the entire user flow and at the same time provide this as a how-to for developers\n    1. Has been implemented here https://github.com/fabianbormann/cip-0045-demo-implementation\n\n### Implementation Plan\n\n- [x] Fork/Extend bugout to add webpack 5 and typescript support\n- [x] Povide a general intermediate cardano-connect typescript library to provide \n    1. A check for mobile/desktop environment\n    2. Depending on the environment provide interfaces for CIP-0030 / and / or CIP-?\n    3. Add a full implementation of the server/client side code above to define a communication standard similar to CIP-0030 (getRewardAddresses, signData, signTx, ...)\n- [x] Start discussions about security gaps within the proposed method with various developers and also look for research papers\n- [x] Check if the wallet app also reacts to rpc calls in background mode on Android\n- [x] Check if the wallet app also reacts to rpc calls in background mode on iOS\n- [x] Implement the library within an example dApp:\n    1. Implemented in Cardano Ballot for the [summit voting 2023](https://voting.summit.cardano.org/)\n    2. Implemented by (SundeaSwap)[https://www.youtube.com/watch?v=mRpXIh-DyYM]\n    3. Implemented into the [cardano-connect-with-wallet core and react library](https://github.com/cardano-foundation/cardano-connect-with-wallet/tree/main)\n    4. Implemented in [walkinwallet](https://walkinwallet.com/) \n      \n\n### Updates\n\n- The re-implementation of bugout that matches the expectations below is now available as [meerkat](https://github.com/fabianbormann/meerkat)\n\n- A general [cardano-connect typescript library](https://github.com/fabianbormann/cardano-peer-connect) with 100% CIP-30 support has been provided\n\n- The copy & paste [demo implementation](https://github.com/fabianbormann/cip-0045-demo-implementation) is ready to use \n\n- Cardano Foundation's [connect-with-wallet](https://github.com/cardano-foundation/cardano-connect-with-wallet) component does include the dApp part of CIP-45 (via feature flag), so that dApp developers don't need to write a single line of code if they rely on this component\n\n- The wording of the CIP-45 has been changed. Many thanks to [@jehrhardt](https://github.com/jehrhardt) for his valuable explanation and suggestions\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n"
  },
  {
    "path": "CIP-0049/README.md",
    "content": "---\nCIP: 49\nTitle: ECDSA and Schnorr signatures in Plutus Core\nStatus: Active\nCategory: Plutus\nAuthors:\n  - Koz Ross <koz@mlabs.city>\n  - Michael Peyton-Jones <michael.peyton-jones@iohk.io>\n  - Iñigo Querejeta Azurmendi <querejeta.azurmendi@iohk.io>\nImplementors:\n  - MLabs\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/250\nCreated: 2022-04-27\nLicense: Apache-2.0\n---\n\n## Abstract\n\nSupport ECDSA and Schnorr signatures over the SECP256k1 curve in Plutus Core;\nspecifically, allow validation of such signatures as builtins.\nThese builtins work over ``BuiltinByteString``s.\n\n## Motivation: why is this CIP necessary?\n\nSignature schemes based on the SECP256k1 curve are common in the blockchain\nindustry; a notable user of these is Bitcoin. Supporting signature schemes which\nare used in other parts of the industry provides an interoperability benefit: we\ncan verify signatures produced by other systems as they are today, without\nrequiring other people to produce signatures specifically for us. This not only\nprovides us with improved interoperability with systems based on Bitcoin, but\nalso compatibility with other interoperability systems, such as Wanchain and\nRenbridge, which use SECP256k1 signatures for verification. Lastly, if we can\nverify Schnorr signatures, we can also verify Schnorr-compatible multi or\nthreshold signatures, such as [MuSig2](https://eprint.iacr.org/2020/1261.pdf) or\n[Frost](https://eprint.iacr.org/2020/852).\n\n## Specification\n\nTwo new builtin functions would be provided:\n\n* A verification function for ECDSA signatures using the SECP256k1 curve; and\n* A verification function for Schnorr signatures using the SECP256k1 curve.\n\nThese would be based on [`secp256k1`](https://github.com/bitcoin-core/secp256k1), \na reference implementation of both kinds of signature scheme in C. This \nimplementation would be called from Haskell using direct bindings to C. These\nbindings would be defined in `cardano-base`, using its existing `DSIGN`\ninterface, with new builtins in Plutus Core on the basis of the `DSIGN`\ninterface for both schemes.\n\nThe builtins would be costed as follows: ECDSA signature verification has\nconstant cost, as the message, verification key and signature are all\nfixed-width; Schnorr signature verification is instead linear in the message\nlength, as this can be arbitrary, but as the length of the verification key and\nsignature are constant, the costing will be constant in both.\n\nMore specifically, Plutus would gain the following primitive operations:\n\n* `verifyEcdsaSecp256k1Signature :: BuiltinByteString -> BuiltinByteString ->\n  BuiltinByteString -> BuiltinBool`, for verifying 32-byte message hashes signed \n  using the ECDSA signature scheme on the SECP256k1 curve; and\n* `verifySchnorrSecp256k1Signature :: BuiltinByteString -> BuiltinByteString\n  -> BuiltinByteString -> BuiltinBool`, for verifying arbitrary binary messages \n  signed using the Schnorr signature scheme on the SECP256k1 curve.\n\nBoth functions take parameters of a specific part of the signature scheme, even\nthough they are all encoded as `BuiltinByteString`s. In order, for both\nfunctions, these are:\n\n1. A verification key;\n2. An input to verify (either the message itself, or a hash);\n3. A signature.\n\nThe two different schemes handle deserialization internally: specifically, there\nis a distinction made between 'external' representations, which are expected as\narguments, and 'internal' representations, used only by the implementations\nthemselves. This creates different expecations for each argument for both of\nthese schemes; we describe these below.\n\nFor the [ECDSA signature\nscheme](https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm),\nthe requirements are as follows. Note that these differ from the serialization\nused by Bitcoin, as the serialisation of signatures uses DER-encoding, which \nresult in variable size signatures up to 72 bytes (instead of the 64 byte encoding\nwe describe in this document).\n\n* The verification key must correspond to the _(x, y)_ coordinates of a point \n  on the SECP256k1 curve, where _x, y_ are unsigned integers in big-endian form.\n* The verification key must correspond to a result produced by\n  [``secp256k1_ec_pubkey_serialize``](https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1.h#L394), \n  when given a length argument of 33, and the ``SECP256K1_EC_COMPRESSED`` flag.\n  This implies all of the following:\n    * The verification key is 33 bytes long.\n    * The first byte corresponds to the parity of the _y_ coordinate; this is\n      `0x02` if _y_ is even, and `0x03` otherwise.\n    * The remaining 32 bytes are the bytes of the _x_ coordinate.\n* The input to verify must be a 32-byte hash of the message to be checked. We \n  assume that the caller of `verifyEcdsaSecp256k1Signature` receives the \n  message and hashes it, rather than accepting a hash directly: doing so \n  [can be dangerous](https://bitcoin.stackexchange.com/a/81116/35586).\n  Typically, the hashing function used would be SHA256; however, this is not\n  required, as only the length is checked.\n* The signature must correspond to two unsigned integers in big-endian form;\n  henceforth _r_ and _s_.\n* The signature must correspond to a result produced by\n  [``secp256k1_ecdsa_serialize_compact``](https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1.h#L487).\n  This implies all of the following:\n    * The signature is 64 bytes long.\n    * The first 32 bytes are the bytes of _r_.\n    * The last 32 bytes are the bytes of _s_.\n  ``` \n      ┏━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━┓\n      ┃ r <32 bytes> │ s <32 bytes>  ┃\n      ┗━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━┛\n      <--------- signature ---------->\n  ```\nFor the Schnorr signature scheme, we have the following requirements, as\ndescribed in the requirements for [BIP-340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki):\n\n* The verification key must correspond to the _(x, y)_ coordinates of a point \n  on the SECP256k1 curve, where _x, y_ are unsigned integers in big-endian form.\n* The verification key must correspond to a result produced by \n  [``secp256k1_xonly_pubkey_serialize``](https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1_extrakeys.h#L61).\n  This implies all of the following:\n    * The verification key is 32 bytes long.\n    * The bytes of the signature correspond to the _x_ coordinate.\n* The input to verify is the message to be checked; this can be of any length,\n  and can contain any bytes in any position.\n* The signature must correspond to a point _R_ on the SECP256k1 curve, and an\n  unsigned integer _s_ in big-endian form.\n* The signature must follow the BIP-340 standard for encoding. This implies all\n  of the following:\n    * The signature is 64 bytes long.\n    * The first 32 bytes are the bytes of the _x_ coordinate of _R_, as a \n      big-endian unsigned integer.\n    * The last 32 bytes are the bytes of `s`.\n  ``` \n      ┏━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━┓\n      ┃ R <32 bytes> │ s <32 bytes>  ┃\n      ┗━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━┛\n      <--------- signature ---------->\n  ```\n\nThe builtin operations will error with a descriptive message if given inputs\nthat don't correspond to the constraints above, return `False` if the signature\nfails to verify the input given the key, and `True` otherwise.\n\n## Rationale: how does this CIP achieve its goals?\n\nWe consider the implementation trustworthy: `secp256k1` is the reference\nimplementation for both signature schemes, and is already being used in\nproduction by Bitcoin. Specifically, ECDSA signatures over the SECP256k1 curve\nwere used by Bitcoin before Taproot, while Schnorr signatures over the same\ncurve have been used since Taproot.\n\nAn alternative approach could be to provide low-level primitives, which would\nallow any signature scheme (not just the ones under consideration here) to be\nimplemented by whoever needs them. While this approach is certainly more\nflexible, it has two significant drawbacks:\n\n* It requires 'rolling your own crypto', rather than re-using existing\n  implementations. This has been shown historically to be a bad idea;\n  furthermore, if existing implementations have undergone review and audit, any\n  such re-implementations would give us the same assurances as those that have\n  been reviewed and audited.\n* It would be significantly costlier, as the computation would happen in Plutus\n  Core. Given the significant on-chain size restrictions, this would likely be\n  too costly for general use: many such schemes rely on large precomputed\n  tables, for example, which are totally unviable on-chain.\n\nIt may be possible that some set of primitive can avoid both of these issues\n(for example, the suggestions in [this\nCIP](https://github.com/cardano-foundation/CIPs/pull/220)); in the meantime,\nproviding direct support for commonly-used schemes such as these is worthwhile.\n\n### Backward Compatibility\n\nAt the Plutus Core level, implementing this proposal induces no\nbackwards-incompatibility: the proposed new primitives do not break any existing\nfunctionality or affect any other builtins. Likewise, at levels above Plutus\nCore (such as `PlutusTx`), no existing functionality should be affected.\n\nOn-chain, this requires a hard fork.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Include tests of functionality with implementation.\n- [x] Satisfaction of CIP-0035 requirements ([Additions to the Plutus Core Builtins](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0035#additions-to-the-plutus-core-builtins)) including costing.\n- [x] Inclusion of SECP in Plutus core ([as of Valentine hard fork](https://docs.cardano.org/cardano-testnet/about/secp/)).\n\n### Implementation Plan\n\n- [x] Provide an implementation: by MLabs, [merged into Plutus](https://github.com/input-output-hk/plutus/pull/4368).\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0).\n"
  },
  {
    "path": "CIP-0050/README.md",
    "content": "---\nCIP: 50\nTitle: Pledge Leverage-Based Staking Rewards\nCategory: Ledger\nStatus: Proposed\nAuthors:\n  - Michael Liesenfelt <michael.liesenfelt@gmail.com>\n  - Ryan Wiley\n  - Rich Manderino [ECP]\n  - Stef M [RABIT]\n  - Wayne [OTG]\n  - Homer J (AAA)\n  - Chad [BBHMM]\nImplementors: []\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/242\n  - https://forum.cardano.org/t/cip-shelley-s-basho-voltaire-decentralization-update/97685\n  - https://forum.cardano.org/t/minimum-pool-fees-with-a-brief-mention-of-k-changes/97002/82\n  - https://github.com/cardano-foundation/CIPs/pull/1042\nCreated: 4 April 2022 (original), 20 May 2025 (updated)\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nImproving decentralization is critical for Cardano’s long-term health and growth. The current reward-sharing scheme (RSS) has yielded a stable but suboptimal level of decentralization. In hindsight, the original parameters *k* (the desired number of pools) and *a₀* (pledge influence factor) have not achieved their intended goals. Many stake pools with zero or minimal pledge manage to attract large delegations, undermining the Sybil-resistance that pledge was meant to provide (Liesenfelt, 2022). This proposal introduces a new pledge leverage parameter, *L*, into the RSS to more directly and fairly constrain such under-pledged pools. By capping rewards for pools with excessive stake relative to pledge, *L* penalizes severely under-pledged pools while having minimal effect on well-pledged or small pools. The adjusted scheme aligns economic incentives with decentralization: it redistributes stake toward well-pledged pools (increasing their rewards) and makes it more difficult for single entities to dominate via multiple pools. We present the motivation, specification, and rationale for this change, including simulations illustrating its impact. The goal is to significantly improve effective decentralization (approaching the theoretical *k* target) without unfairly harming small pool operators.\n\n## Motivation: Why is this CIP necessary?\n\n### Stagnating Decentralization and Sybil Concerns\n\nCardano’s block production is less decentralized in practice than the protocol parameter *k* = 500 implies. Although *k* intends to cap pool sizes and guide the network toward saturated equal-sized pools, in reality many of the top pools are operated by the same entities, which defeats the purpose (Fancee, 2022). For example, certain large exchanges run dozens of pools (e.g. 91 by Binance and 31 by Coinbase), collectively controlling roughly 12.59% of stake. This means the Nakamoto Coefficient – the minimum number of distinct entities required to control greater than 50% of block production is only about 25 as of epoch 559 (Balance Analytics, 2025). In other words, the *effective* decentralization is on the order of only a few dozen independent actors, far below the target of 500 pools (Liesenfelt, 2022).\n\nAs of epoch 560, **473 pools have zero pledge**, yet they still command **2,740,223,943 ADA** in delegated stake (Koios, 2025).  This concentration is fueled by Sybil behavior: many pools are essentially split nodes run by one operator. Pool-splitting hurts the network as a whole: operators running multiple low-pledge pools collect multiple fixed fees and margins, reducing rewards for delegators and squeezing out smaller, independent operators (Kiayias, 2020).\n\nUnder the current Reward Sharing Scheme (RSS) there is no explicit mechanism to limit leverage (stake-to-pledge ratio). An operator can split stake across many pools with zero or tiny amounts of pledge and still earn nearly full rewards on each pool. The saturation parameter *k* limits stake per pool but cannot limit how many pools a single entity operates. The pledge-influence factor a₀ was intended to discourage Sybil attacks, yet at its present value (0.3) it provides only a modest boost to heavily pledged pools. A private pool with high pledge might earn ~3.33 % annualized, while a zero-pledge public pool still earns ~2.6% which is only ~22% less. That small gap is *statistically unnoticed* by most delegators and is overwhelmed by normal epoch-to-epoch luck variance.\n\nCrucially, it now takes a pledge of only about **53,870,468 ADA** spread across enough low-pledge pools to control more than 50% of total stake (Koios, 2025). This minimal capital requirement highlights how the current design enables highly leveraged Sybil attacks that erode decentralization and threaten network resilience.\n\n### Limits of the Current Parameters (*k* and *a₀*)\n\nCardano’s decentralization parameters face a dilemma. The parameter *k* governs the target number of pools (decentralization threshold), and *a₀* is the traditional lever for Sybil resistance via pledge. In theory, setting a higher *a₀* would strongly reward pledged stake and penalize pools with little pledge, thereby discouraging Sybil attacks (multiple zero-pledge pools). However, increasing *a₀* would also widen the reward gap between large pledged pools and smaller community pools, harming small pool operators. As of February 2022, with *a₀*=0.3, roughly **1.25 billion ADA** concentrated in **19 fully pledged pools** earns maximal rewards (Fancee, 2022), giving wealthy operators a significant yield advantage. Raising *a₀* further would make this disparity even worse – effectively creating *two classes of stakeholders*, where large custodial actors can offer materially higher yields than individual operators. This is antithetical to Cardano’s egalitarian ethos and has proven politically difficult: the community not made any significant efforts to adjust *a₀* upward, likely knowing it would push many small pools out of the ecosystem.\n\nCardano's previous increase of k from 150 to 500 did result in a modest increase in the number of unique pools making blocks, but it also presented a tradeoff. Some multi-pool operators responded by creating additional low-pledge pools to capture more stake. A concern that has been shared about raising *k* is that it carries the risk of a proliferation of minimally-pledged pools run by the same entities, increasing total pool count with only a minor improvement in the actual diversity of operators. This dilution weakens Sybil resistance and keeps effective decentralization, as measured by k-effective, significantly below the target *k*.\n\nTo investigate these relationships, the Rewards Sharing Simulation (RSS) engine (University of Edinburgh: Blockchain Technology Lab, 2025) was used with minor modifications to model CIP-50 behavior. When sweeping *k* from 250 to 2,000 while holding *a₀* at a very low value (0.1), the headline “target pool” count grows, but the Nakamoto coefficient actually falls from about 142 at *k*=1,000 to just 116 at *k*=2,000. The hypothesis here is that pledge is too insignificant which leads big operators to simply split their stake into even more zero-pledge pools.  The on-chain diversity looks larger, yet real control collapses into fewer hands.\n\n![Current Cardano Rewards Sharing Scheme](images/RSS1.png \"Current Cardano Rewards Sharing Scheme\")\n\n(University of Edinburgh: Blockchain Technology Lab, 2025)\n\nMoving a₀ to the opposite extreme tells demonstrates a different issue. At *a₀*=10, the simulation does push the Nakamoto coefficient upward to around 173 at *k*=1,000.  But there is a small drop to 169 at *k*=2,000.  The hypothesis here is that in this case, pledge has actually been made *too* significant such that only whales with large amounts of pledge are able to compete. This would presumably reshape the ecosystem into an elite upper tier and a struggling lower tier. In effect, we swap Sybil risk for wealth concentration which indirectly harms decentralization.\n\nIn summary, Cardano’s current RSS parameters are insufficient to prevent Sybil attacks and pool splitting: *k* sets an ideal pool count but doesn’t control for unique identities, and *a₀* is too weak (for political and economic reasons) to enforce meaningful pledge contributions. As a result, many pools with zero or tiny pledge and high delegated stake thrive – which deviates from the original decentralization goals of the Shelley design. An adjustment is needed to strengthen Sybil resistance without unfairly disadvantaging small pools.\n\n### Objectives for an Improved Scheme\n\nAny improvement to the reward scheme should adhere to the following high-level goals:\n\n* **Fairness**: All stakeholders, from small delegators to whales and exchanges, should have the opportunity to earn *on average* the same *yield* (rewards per unit of stake). The system should avoid creating “VIP” pools with inherently better returns. In other words, no two classes of stakeholders. \n\n* **Sybil Protection:** Running multiple pools *must* come at a cost. The scheme should *require* a meaningful pledge to support each pool’s delegated stake – not just mildly incentivize it. Creating many low-pledge pools should result in diminishing returns, removing the current advantage of pool splitting (Kiayias, 2020). \n\n* **Decentralization:** The effective number of independent block-producing entities (k-effective) should converge towards the target *k*. The **Minimum Attack Vector (MAV)** (a.k.a. Nakamoto coefficient – number of entities to control 51%) should remain stable or increase. \n\n* **Predictability and Simplicity:** The new reward formula should be as simple and transparent as possible, avoiding unnecessary complexity (e.g. no exotic curves or cryptic parameters). Operators and delegators should easily understand the cause-and-effect of the parameters on rewards. \n\nThis CIP addresses these goals by introducing a new pledge leverage parameter *L* and corresponding modifications to the reward formula. The motivation is to curb extreme leverage (high stake with low pledge) in a targeted way that primarily affects Sybil or multi-pool scenarios, while ordinary single-pool operators with reasonable pledge are largely unaffected (and may even benefit from a fairer playing field). In short, we seek to increase decentralization and security without sacrificing the openness and egalitarian nature of Cardano’s stake pool system.\n\n## Specification\n\n### Introducing the Pledge Leverage Parameter (*L*)\n\nFor reference we will share the relevant elements of the existing Cardano rewards formula here:\n\n![Cardano Rewards Formula](images/RewardsFormula.png \"Current Cardano Rewards Formula\")    \n\n(Pledging and Rewards | Cardano Docs, n.d.)\n\n*  *R* - Epoch Rewards Pot\n*  *a₀* - Pledge Influence Factor\n*  *k*  - Target Number of Stake Pools\n*  *𝜎'* - Pool stake eligible for rewards\n*  *𝜎* = Pool’s total stake (pledge + delegated stake)\n*  *p'* = Pool pledge eligible for rewards\n*  *p* = Pool’s pledge\n*  *z0*  - Circulating ADA divided by k\n\nWe propose adding a new protocol parameter L (maximum pledge leverage) to the staking reward formula that fits in the third equation for calculating 𝜎'. The parameter L is defined as the maximum ratio of total stake to pledge that a pool can have before its rewards begin to plateau. In other words, L imposes a pledge-based saturation point for each pool.\n\n* **Range of *L*:** 1 ≤ *L* ≤ 10,000 (dimensionless ratio). An *L* of 10,000 represents an extremely high allowed leverage (i.e. pledge need only be 0.01% of the stake), effectively similar to the status quo with a very weak pledge influence. An *L* of 1 represents a very strict requirement where a pool’s stake cannot exceed its pledge (100% pledge) if it is to earn full rewards. \n\n* **Reward Formula Changes:** The reward calculation (pool reward R) is modified to incorporate a pledge leverage cap as a new parameter L. Each pool’s stake is effectively capped by its pledge according to L such that the eligible pool stake used in reward computations is:\n\n![CIP-50 Formula](images/CIP50Formula.png \"CIP-50 Formula\")\n\n This means a pool is subject to *two* soft caps: one based on the global saturation (*k*) and one based on its own pledge.\n\n* **Stake cap (k):** If a pool’s total stake 𝜎 exceeds *1/k* (the normal saturation point), it gets no extra rewards beyond that point (as in the current formula). \n\n* **Pledge cap (L):** If 𝜎 exceeds *L·p* (i.e. the pool’s stake is more than *L* times its pledge), then any stake above that is not counted for rewards either. In effect, the pool is “leverage-saturated” if it tries to grow too large without sufficient pledge backing. \n\n### Implications:\n  * A pool with **very low pledge** relative to its delegation will hit the pledge cap long before the *k* cap. For example, a pool pledging 1k ADA with *L*=100 can fully utilize at most 100k ADA of stake; beyond that, additional delegations won’t increase its rewards. If that pool has, say, 1 million ADA delegated, it will still only earn rewards as if it had 100k (plus its 1k pledge) – the rest of its stake is effectively providing zero rewards to its delegators. This creates a strong incentive for delegators to move to better-pledged pools if their pool is over-leveraged. \n\n  * A pool with **adequate pledge** will not be affected by the *L* cap until it reaches the normal saturation point. For instance, with *L*=100 and *k*=500, a pool needs about 1% pledge to utilize full stake up to *1/k*. In absolute terms, given the current saturation point around 75M ADA. At *L*=100, a pledge of ~750k ADA would be required to support 75M stake. Pools that meet this pledge-to-stake ratio can grow to saturation normally and will earn the same rewards as under the current formula. \n\n  * Pools with a **substantial pledge** relative to their stake will not be constrained by the pledge leverage parameter, *L*. These high-pledge pools will instead only reach the global network saturation point, which is determined by *1/k*. Furthermore, these well-pledged pools will also receive a small additional reward boost based on the pledge influence factor, *a₀*, in the existing reward formula, providing them with a modest advantage over pools that are approaching the leverage cap. \n\n  * If a pool’s stake is **below saturation**, it can still earn rewards on the full amount of stake as long as its pledge is at least *𝜎·L*. Smaller pools typically have smaller 𝜎, so the pledge needed is modest. For example, at *L*=100 and *k*=500, a pool with 500k ADA total stake would only need a pledge of ~5k ADA (1% of 500k) to not be limited by leverage, and it would offer delegators a competitive APY. This is a reasonable pledge threshold, demonstrating that **honest small pools are not penalized** by *L*. They can achieve comparable yields as large pools on a proportional basis. \n\n  * Crucially, a pool with **zero pledge will earn zero rewards** if it has any delegated stake. This is a clear break from the current scheme, where a pool with 0 pledge can still generate rewards for delegators (just slightly less). Under the new formula, some amount of pledge becomes absolutely mandatory.  This eliminates the “free rider” problem of profit-seeking pool operators undermining the network’s security.\n\n## Rationale: How Does This CIP Achieve Its Goals?\n\n### Penalizing Under-Pledged Pools (Sybil Deterrence)\n\nThe pledge leverage parameter *L* directly targets the worst-offending pools from a Sybil perspective – those with lots of stake but little skin in the game. By establishing an upper limit on stake relative to pledge, *L* introduces a hard economic penalty for over-leveraged pools. An operator can no longer create unlimited pools with minimal pledge and expect nearly full rewards on all of them. Any pool that is* severely under-pledged *will quickly hit the leverage cap and see its additional delegated stake yield zero incremental rewards.\n\nThis has an immediate discouraging effect on Sybil behaviors:\n\n* A malicious actor attempting to control a large portion of stake by spinning up many pools would now need to proportionally increase pledge for each pool to make them effective. Otherwise, delegators will not join those pools (due to poor returns) or will abandon them once they realize additional stake is wasted. The economic cost of a Sybil attack thus becomes *linearly proportional* to the stake under control, thanks to the pledge requirement, rather than merely the fixed cost of running many nodes. \n\n* Importantly, *L* removes the “free ride” incentive that previously existed where splitting one’s stake into multiple pools could circumvent the saturation limit. Under the new scheme, splitting stake across N pools without adding more pledge might split one’s effective rewards as well. For example, if an entity with a fixed total pledge *p* runs two pools, each pool will have at most *p·L* worth of effective stake. If they had combined everything in one pool, they’d have *p·L* effective stake (assuming that was the limiting factor). By splitting into two pools with pledge p/2 each, each pool caps at (p/2·L), for a combined effective stake of *p·L* – the same as one pool. Thus, there is no gain in total rewards by operating multiple pools under a fixed pledge budget. Any attempt to gain more by adding a new pool will just spread the pledge thinner and impose a lower cap per pool, keeping the total unchanged. This is a fundamental change: in the current scheme, splitting stake *can* increase an entity’s total rewards (because each pool can almost fully saturate and earn fees), but with *L* enforced, splitting yields *diminishing returns* unless accompanied by more pledge. \n\n* Furthermore, *L* ensures pledge is absolutely mandatory for participation, aligning every operator’s incentives with the network’s security. Unlike today where many pools operate with almost zero pledge, under the new formula a pool with 0 pledge simply cannot earn rewards. Even a minimal pledge pool will severely limit its delegators’ returns if it grows, making it unappealing. This policy embodies the principle that if you want to benefit from community delegation, you must put up a bond to secure the network. It converts pledge from a weak nudge into a strict requirement, dramatically strengthening Sybil resistance. \n\nIn short, *L* provides an enforceable limit on Sybil actors and their maximum return on invested capital. It closes the loophole that allows large holders to game the system by simply multiplying pools. By tying rewards to pledge, the economic playing field is leveled: operators must either commit capital or accept a cap on their pool’s influence. This directly realigns incentives with decentralization and security.\n\n### Minimal Impact on Honest Small Pools\n\nA key advantage of using *L* (a leverage cap) instead of raising *a₀* (linear pledge influence) is that it minimizes negative effects on small or medium operators. The leverage cap kicks in when a pool tries to scale beyond what its pledge supports. Small pools, by definition, are not huge in stake, so most will not even reach the cap if *L* is tuned reasonably. For example, a pool with 1M ADA stake and 10k ADA pledge at *L*=100 is right at the cap (since 10k*100 = 1M); if it grows above 1M, then yes, it would need more pledge to maintain max rewards. But if that pool stays small or gradually grows alongside its pledge, its delegators experience no reduction in yield. In practice, many community pools already maintain a healthy pledge relative to their current delegation. These pools will see no change in their rewards from the new formula, except that they might actually become more attractive to delegators compared to under-pledged competitors.\n\nBy contrast, increasing *a₀* would hurt small pools immediately by lowering their rewards relative to large pools (regardless of the small pool’s size). The *L* parameter avoids that blunt harm by acting as a soft cut-off rather than a across-the-board tax. Pools earn normally up to a point, then flatline. Thus, a small pool that isn’t anywhere near saturation or leverage limits will function just as before (or better, since delegators may redistribute in its favor). The reward system aims to remain largely egalitarian: most pools that meet the pledge ratio can reach a similar maximum reward per stake. While increasing a₀ can create a slightly steeper reward gradient favoring high-pledge pools, introducing *L* creates a flat plateau for all pools that meet the leverage requirement while still maintaining a minor pledge benefit through *a₀* up to the global saturation point. This leverages the new *L* parameter to be more egalitarian while still incentivizing pledge, aiming to minimize the creation of disparate classes of participants.\n\n\n### Discouraging Multi-Pool Splitting and Easing *k* Increases\n\nOne of the strongest arguments for the leverage-based approach is its effect on multi-pool operators (MPOs). In the current scheme, an MPO (like an exchange or a pool group) can slice their stake into *N* pools and, aside from the minor dilution of pledge, face little downside. They often benefit by collecting multiple fixed fees and saturating more pools. This has led directly to the situation of single entities running tens of pools and dominating the top ranks.\n\nWith *L*, the advantage of operating multiple pools is blunted for operators with too little pledge to support them. Since the rewards of each pool are limited by pledge, an MPO with a fixed total pledge won’t gain by spreading it thin. In fact, operating more pools could reduce their overall efficiency if their pledge per pool drops. The rationale is simple: if splitting your pledge into two pools halves the effective cap of each, you end up with the same total effective stake across your pools (and thus the same total rewards) as if you kept one pool fully pledged. Therefore, a rational operator under the new scheme would have no incentive to run more pools than necessary to accommodate their stake and pledge. We anticipate that many MPOs will consolidate or reduce the number of pools they run once *L* is in effect, because having many half-pledged pools would just advertise their leverage weakness and fail to increase their earnings.\n\nThis property is especially important when considering future increases in *k*. If Cardano wants to raise *k* (say to 1000 or beyond) to encourage further decentralization, *L* will ensure that those additional pool “slots” actually translate to new operators, not just existing MPOs multiplying again. As noted earlier, raising *k* alone without leverage control might invite big players to split stake into more pools. But if those players are constrained by pledge, they cannot effectively occupy all the new slots at full rewards. For instance, an exchange with limited pledge might fill some pools to the cap, but then either stop or create more pools that are underperforming. This leaves room (and incentive) for other operators to step in and operate the remaining pools, because delegators will seek out pools that *can* give full rewards. Thus, *L* works in synergy with raising *k*: it amplifies the decentralization impact of a larger *k* by preventing single entities from monopolizing the new capacity. In effect, *L* helps align *k* (the protocol’s target) with *k-effective* (the real outcome). We can safely pursue higher *k* values knowing that effective decentralization will follow more closely, rather than being undermined by Sybil pool clusters.\n\n### Validating Behavior with Reward Sharing Simulation Engine\n\nTo test whether the leverage cap (*L*) proposed in CIP-50 delivers the intended balance between Sybil resistance and fairness, we re-ran the University of Edinburgh Reward-Sharing Simulation Engine with two configurations:\n\n1. **Baseline** – the current Cardano rewards formula exploring *k = 250 → 2,000* and *a₀ ∈ {0.1, 0.3, 0.5, 1, 10}*. \n\n2. **CIP-50** – identical *k* sweep but with *a₀ locked at 0.3* and *L ∈ {10, 100, 1 000, 10,000}*.\n\n![Current RSS vs CIP-50](images/RSS2.png \"Current RSS vs CIP-50\")\n\n(University of Edinburgh: Blockchain Technology Lab, 2025)\n\n**Decentralization is roughly the same or slightly improved.**    \nWhere the baseline delivers 159 independent entities for the current parameter set (*k=500, a₀=0.3*), CIP-50 achieves **~160** at almost all settings of *L*. Thus the new rule neither harms decentralization nor relies on an unpalatable increase to *a₀*.\n\n**Network pledge rises slightly.**    \nTotal pledged stake in the baseline hovers between **0.73 and 0.93** of the maximum possible, depending on *a₀* and *k*. CIP-50 nudges this figure upward at *a₀*=0.3, showing that a leverage ceiling likely would entice operators to increase their pledges rather than spawn extra pools.\n\n**Lower *L* values are preferred.**    \nWhile any finite *L* blocks the worst Sybil behavior, tighter caps yield the best Sybil protection without penalizing small-to-medium operators the way a large *a₀* increase would. The sweet spot lies at the lower end of the tested range (~10 to ~100), where Sybil protection is strongest yet the number of viable pools remains healthy.\n\n***L* primarily strengthens Sybil protection.**    \nIn the baseline, lowering *a₀* to 0.1 caused a notable drop in Nakamoto coefficient at *k=2000*. To investigate this particular issue, further simulations were run with extremely low values of *a₀* with the current rewards formula and with CIP-50 and a flat *L* value of 10.\n\n![Current RSS with low a0 values](images/RSS3.png \"Current RSS with low a0 values\")\n\n![CIP-50 with low a0 values and L=10](images/RSS4.png \"CIP-50 with low a0 values and L=10\")\n\n(University of Edinburgh: Blockchain Technology Lab, 2025)\n\nThe addition of *L* resulted in a notable improvement in the Nakamoto coefficient over the baseline rewards formula.  Taken together, the simulations support the hypothesis that CIP-50’s leverage cap will accomplish its primary mission of curbing Sybil pool proliferation.\n\n## Path to Active\n\n### Acceptance Criteria\n\n**Consensus on an Initial *L*** – An initial value of *L* must be agreed upon before hard-fork combinator (HFC) activation. The choice should balance Sybil protection against operational viability, drawing on empirical analyses (e.g., RSS results) and community feedback. \n\n**Endorsement by Technical Bodies** – The Cardano Parameter-Change Proposals (PCP) Committee and the Intersect Technical Steering Committee (TSC) should both recommend the proposal as technically sound and aligned with the protocol’s long-term roadmap. \n\n**CIP Editorial Approval** – Cardano CIP Editors must confirm that the specification is complete, unambiguous, and internally consistent with existing CIPs. \n\n**Stakeholder Concurrence** – A majority of stake pool operators (SPOs), ecosystem tooling maintainers, dReps, and other infrastructure providers must signal readiness to upgrade. \n\n**Governance Ratification** – The on-chain Hard-Fork Governance Action must pass the requisite dRep and Constitutional Committee thresholds, establishing legal-constitutional legitimacy and stakeholder support for the change.\n\n### Implementation Plan\n\n**Community Deliberation (Preparation Phase)**\n\n* Publish the finalized CIP-50 revision and present it to the PCP committee , TSC, CIP Editors, and wider community channels (Discord, X, Cardano Forum, etc.). \n\n* Collect structured feedback—particularly on candidate values for *L*—and iterate until broad technical consensus emerges. \n\n**Specification & Code Integration (Development Phase)**\n\n* Once an initial *L* is determined, integrate the leverage-cap logic into cardano-node and related libraries (ledger, CLI, wallet APIs). \n\n* Submit pull requests to the canonical repositories; obtain code reviews from IOG, CF, and community contributors. \n\n* Release a new protocol version that includes the changes made in this CIP. \n\n* Use a dedicated pre-production testnet that mirrors main-net parameters but enforces the new *L* rule, allowing SPOs and exchanges to test end-to-end flows. \n\n**Readiness Sign-off (Testing Phase)**\n\n* Require at least two weeks of uninterrupted testnet stability plus green results from regression and property-based tests. \n\n* Monitor ecosystem dApps and tooling to confirm that major node implementations, explorers, wallets, and exchange integrations support the new rule set. \n\n**On-chain Governance (Ratification Phase)**\n\n* File the Hard-Fork Governance Action on-chain with the agreed *L*, tagged for the next hard fork event. \n\n* Mobilize dRep outreach to ensure quorum and super-majority passage; concurrently, the Constitutional Committee validates procedural compliance. \n\n**Hard-Fork Activation (Deployment Phase)**\n\n* Upon successful vote, the hard fork event is automatically triggered upon epoch turnover. \n\n* Monitor main-net metrics during the changeover epoch; provide real-time support for any late-upgrading SPOs.\n\n## References\n\n  AdaPulse. (2023, February 23). *MAV: The Safety Metric In Block Production Decentralization*. AdaPulse. Retrieved May 20, 2025, from https://adapulse.io/mav-the-safety-metric-in-block-production-decentralization\n\n  *Balance Analytics*. (2025, May 20). Average Resulting Decentralization. Retrieved May 20, 2025, from https://www.balanceanalytics.io/chartboards/decentralization\n\n  Balance Analytics. (2025, May 20). *Group Stake Donut Chart*. Balance Analytics. Retrieved May 20, 2025, from https://www.balanceanalytics.io/chartboards/donut_shop\n\n  Fancee, T. (2022, February 1). *CIP - Leverage-based Saturation and Pledge Benefit*. Cardano Forum. Retrieved May 20, 2025, from https://forum.cardano.org/t/cip-leverage-based-saturation-and-pledge-benefit/95632\n\n  Kiayias, A. (2020, November 12). *The general perspective on staking in Cardano*. Input | Output. Retrieved May 20, 2025, from https://iohk.io/en/blog/posts/2020/11/13/the-general-perspective-on-staking-in-cardano/\n\n  Kiayias, A. (2020, November 29). *Blockchain reward sharing - a comparative systematization from first principles*. Input | Output. https://iohk.io/en/blog/posts/2020/11/30/blockchain-reward-sharing-a-comparative-systematization-from-first-principles/\n\n  Koios. (2025, May 28). *Pool List API*. https://api.koios.rest/\n\n  Liesenfelt, M. (2022, April 4). *Pledge Leverage-Based Staking Rewards*. Cardano Improvement Proposals. Retrieved May 20, 2025, from https://cips.cardano.org/cip/CIP-0050\n\n  Pledging and rewards | Cardano Docs. (n.d.). Cardano Docs. Retrieved June 4, 2025, from https://docs.cardano.org/about-cardano/learn/pledging-rewards\n\n  University of Edinburgh: Blockchain Technology Lab. (2025, May 28). *Rewards Sharing Simulation Engine*. https://github.com/Blockchain-Technology-Lab/Rewards-Sharing-Simulation-Engine\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0052/README.md",
    "content": "---\nCIP: 52\nTitle: Cardano audit best practice guidelines\nStatus: Proposed\nCategory: Meta\nAuthors:\n  - Simon Thompson <simon.thompson@iohk.io>\nImplementors: []\nDiscussions: \n  - https://github.com/cardano-foundation/CIPs/pull/252\n  - https://github.com/cardano-foundation/CIPs/pull/344\n  - https://github.com/cardano-foundation/CIPs/pull/406\n  - https://github.com/cardano-foundation/CIPs/pull/560\nCreated: 2022-04-25\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThese guidelines describe the audit process in general before setting out for DApp developers what information they will need to supply to auditors as part of the process. These are guidelines rather than requirements, and different auditors may engage differently, providing complementary services. The guidelines aim to establish a common baseline, including alternative ways of satisfying high-level requirements. Appendices provide (1) a glossary, (2) an audit FAQ, (3) a list of auditors for Cardano, and (4) a sample audit report.\n\n## Motivation: why is this CIP necessary?\n\nThis CIP aims to promote the process of audit for DApps on Cardano, to improve the overall standard of assurance of DApps built for Cardano, and thus to contribute the improvement of the wider Cardano ecosystem.  \n\n## Specification\n\n### Introduction\n\nDApp users seek assurance about DApps that they wish to use. This comes from running automated tools on DApps and their components, as well as by audit of complete DApps. Secure evidence of these tool (level 1) and audit (level 2) results is provided by a certification service, and made available to users through a service such as a DApp store or wallet. In the longer term, results of formal verification (level 3) will also form part of the certification process.\n\nDApp developers seek to drive adoption through their DApps being certified. Wallets and DApp stores are enhanced by providing certification services, and the wider Cardano ecosystem is strengthened through certification becoming widespread. Best practice standards can be developed by the audit and tooling communities, and systematised by the Cardano Foundation. This document is a first step in that direction.\n\n**Assurance can only ever be partial:** a DApp can be shown to have some good features and to avoid some bad ones, but this is not a guarantee that using a DApp will not have negative consequences for a user. This is not simply because tools and audits cannot give complete coverage, but also because attacks may come at lower (e.g. network, browser) or higher (e.g. crypto-economic) levels than addressed here.\n\nThese are guidelines rather than requirements, and different auditors may engage differently, providing complementary services. The guidelines aim to establish a common baseline, including alternative ways of satisfying high-level requirements. Appendices provide (1) a glossary, (2) an audit FAQ, (3) a list of auditors for Cardano, and (4) a sample audit report.\n\n### Prerequisites\n\n#### Key terms\n\n***(Smart) contract***: a program that runs on blockchain. In the case of Cardano, this will be a Plutus program that will contain Plutus Core components that run on blockchain as well as other code that runs off chain. All auditors will scrutinise on-chain code, some will examine off-chain code too.Some auditors might also provide orthogonal services eg. auditing a zero-knowledge protocol or an economic model.\n\n***DApp***: a complete “distributed” application that runs on blockchain. This will include off-chain code written in other languages, e.g. running in a browser, and will integrate or link with other services such as wallets and oracles.\n\n***Assurance***: the process of establishing various properties of systems, both positive (it does this) and negative (it doesn’t do this), with different degrees of certainty.\n\n***Audit***: the process of establishing assurance by means of manual examination of artefacts, systems, processes etc. Can involve some tooling, but it is a human-led process.\n\n***Tooling***: using automated processes to establish degrees of assurance of systems. Tools may be run on target DApps by parties providing such a service.\n\n***Evidence***: artefacts coming out of tooling and audit that can support assertions of assurance of systems. Examples include formal proofs, test suites, prior counterexamples and so on, as well as audit reports.\n\n***Certification***: the process and technology of giving to DApp end-users and developers secure evidence of forms of assurance about DApps and their component smart contracts. In the case of Cardano our approach is to provide information on  chain as transaction metadata. \n\n*Note*: “certification” has also been used informally to cover the combined process of testing, audit, verification and providing evidence of these, as in “level 1 certification”. If it is felt that it is too confusing to use the term in both senses, then another term should be found, e.g. *evidencing* or *witnessing*. \n\n***Component***: a discrete part of the complete system supplied by a third party, such as a wallet, (part of) which will be run on the user’s system.\n\n***Service***: a part of the system, such as Blockfrost, that is provided by an online server accessed through a well-defined protocol.\n\n***Scope***: the parts of the DApp that are subject to audit. A repository may contain much more than Plutus code. Some audits will look at the complete app, some will just concentrate on on-chain transactions, others on the web interface around it. The possible scopes are divided in three main categories:\n* On-chain\n* Off-chain\n* Context: the business and economic models for the DApp  \n\n***Deployment***: once a DApp is developed it is deployed by submitting the relevant on-chain scripts onto the Cardano blockchain as transaction validator scripts. The scripts being deployed  might be the scripts that have been audited, or be instances of them in the case that the audited scripts are *parametric*.\n\n#### Audit FAQ\n\n##### *What is an audit?*\n\nAn audit is a comprehensive investigation of a DApp that provides an in-depth analysis on bugs, vulnerabilities, code quality and correctness of implementation. An audit does not necessarily analyse completed DApps and often will instead analyse a fragment of a DApp. For example many auditors will only analyse the on-chain code of a DApp.  \n\n##### *Who provides an audit?*\n\nAudits are provided by companies that specialise in the area of the developed DApp. In this case it will be experts on the Cardano blockchain and Plutus smart contracts.\n\n##### *How does audit work? What is the process?*\n\nThis first part of the process is tendering, where developers will need to provide preliminary information about their DApp to candidate auditors, as described below.\n\nOnce a contract is agreed, the next step in the process is to provide the auditors with the necessary information to perform the audit as set out in the guidelines below. Auditors may work with developers to ensure that the documentation and other materials for audit are prepared to the standard that is required for the audit to take place. Different auditors will have different requirements, but the guidelines below establish the minimum requirements.\n\nAuditors will typically produce a first version of a report, which the developer can use as a guide to improving their DApp, before submitting changes to produce the final version of the code on which the final, published report is based. Once a DApp is audited, it will be deployed on the Cardano blockchain.\n\n##### *When should a developer contact an auditor?*\n\nA developer should contact an auditor when they have a final working version of a DApp or fragment of a DApp that they want to have audited. Once the contract is agreed, the developer will need to provide the auditor with a final version of the DApp for audit. \n\nHowever, it is recommended to contact a potential auditor as early as possible because many auditors also provide consultation services for the design and development of the DApps. A developer is encouraged to contact the auditor as early as possible so as to mitigate any design issues which may be very hard if not impossible to fix. Early contact is also encouraged because securing a time slot with an auditor in advance shortens the DApp’s overall time to market, finally, early contact allows for scheduling and potentially avoids long delays between starting and completing an audit.\n\n##### *What is audited when an audit takes place?*\n\nAll audits will examine the on-chain code that is used to validate transactions submitted to advance the smart contracts that constitute part of a DApp. Audit may also cover more of the code in a DApp, including on- and off-chain code written in Plutus, as well as other languages, e.g. JavaScript running in a browser. \n\n##### *What guarantees can and cannot be given by an audit?*\n\nAn audit ***is not*** a guarantee of unbreakable security nor a way to offset trust or responsibility. An audit will provide an in-depth review of the source code of a DApp. The audit will provide a comprehensive code review detailing any found vulnerabilities, comments on the quality of code as well as an analysis of the implementation in regards to the supplied specification. An audit cannot guarantee that all possible vulnerabilities will be found or that the deployed DApp will perform as intended. This is especially true in the cases where an audit only looks at a fragment of a DApp or when a DApp has been updated.\n\n##### *Who are the stakeholders involved in the audit process?*\n\nDApps are used by *DApp users*, and built by *DApp developers*. Audit is performed by *audit companies*, using tools developed by themselves and other *tool developers*. Tooling can be run by *tool service providers*, and evidence of those and other results produced by *certification providers*. Audit is also impacted by components (e.g. light wallets) and services (e.g. blockfrost) provided by *ecosystem members*. Standards can be developed by *industry consortia* or *governance organisations* (e.g. the Cardano Foundation). In the widest sense, all *holders of Ada* stand to benefit from Cardano building an expectation that DApps are certified.\n\n### Cardano auditors\n\n| Audit company   | URL                                     | Contact email      | Public key      |\n| -----------     | -----------                             | -----------        | -----------        |\n| FYEO Inc.       | https://gofyeo.com/blockchain-security  | sales@gofyeo.com  | |\n| Hachi           | https://hachi.one                       | team@hachi.one        | |\n| MLabs           | https://mlabs.city                      | info@mlabs.city      | 64BC640B5454215D12165EEAEEFF303D2643ABA2 (PGP, ed25519) |\n| Runtime Verification           | https://www.runtimeverification.com | contact@runtimeverification.com  | |\n| Tweag                | https://www.tweag.io                  | sales@tweag.io                  | |\n| Vacuumlabs (audits → Invariant0) | https://vacuumlabs.com/   | info@invariant0.com  | 16541FD112978F3C6D49E79881E6B1F9C0BC6BF9 (PGP, ed25519) |\n| CertiK      | https://www.certik.com/products/smart-contract-audit/   | sales@certik.com  | |\n| Invariant0  | https://invariant0.com/                     | info@invariant0.com  | 3C010EA5654D57D0AEF0E50B75D3AA3D42D52499 (PGP, ed25519) |\n\n\n### Tendering\nIn order to provide a quote for audit, developers will need to supply\n* A specification of the DApp to be audited (more details below).\n* The scope of the audit.\n* An estimate of the scale of the audit work, e.g. the number of lines in the on-chain code to be audited, or the code itself, in its current state of development.\n\n### Submission\nIn order to be audited, developers will need to supply the following documentation.\n\n#### *Specification / design documents*\n\nSubmitters shall provide specification and design documents that describe in a precise and unambiguous way the architecture, interfaces and requirements characterising the DApp. \n\nThe documentation shall identify the expected behaviour of the code, given without direct reference to the code itself. The description should also include high-level examples demonstrating use cases of the DApp. All assumptions about how the DApp will be used will be described. The documentation shall identify and document all the interfaces with other components and services.\n\nSubmitters might also wish to explain mitigating actions that they have taken to protect against potential failures and attacks to the DApp.\n\n#### *On-Chain Specification* \n\nThe format of transactions accepted by the smart contracts should be specified using the template provided in the auxiliary document `Tx-spec.md`.\n\nThe document should clearly specify the properties to be satisfied by the smart contract.\n* Properties shall be as extensive as possible and ideally would cover functionality, robustness, safety, liveness and efficiency, e.g. cost of execution, of the smart contract. \n* Discussion should describe whether any of the properties addresses common vulnerabilities pertaining to Cardano blockchain or the smart contract domain in general. \n\nA formal specification is recommended but not mandatory. \n\n#### *Off-Chain Specification*\n\nFor off-chain analysis additional information should be provided for the components and services interfaced:\n* For all interfacing components, a specification shall be given detailing their expected behaviour in relation to the DApp, including any assumptions, constraints and requirements of the component that are expected to hold by the DApp developers.\n* It also shall be stated whether any of the interfacing components have been certified.\n\n#### *Testing*\n\nIdeally, submitters should submit a description of how the DApp has been tested, the results of the tests, and details of how those test results can be replicated.In particular:\n* The test cases and their results shall be recorded or reproducible in a machine-readable format to facilitate subsequent analysis.\n* Tests are to be performed for each targeted platform (browser, wallet etc).\n* The identity, configuration and version of all test components involved shall be documented.\n* The checksum and version of the DApp submitted for certification shall correspond to the same version making the subject of the test report. \n* An evaluation of the test coverage and test completion should be provided. \n\nIn the case that off-chain code is included in the scope of the audit, testing should be able to assess the performance and robustness of the DApp against significant throughput, under substantial workload, and in the scenario of a DoS attack.\n\n#### *Source code and version*\n\nA final version of the source code should be provided that works with the use cases specified in the documentation. Information needs to be provided to allow the DApp to be built in an unambiguous and reproducible way, including any external components and services that the DApp uses.  This could be in the form of\n\n\n* The URL for a commit to a repository.\n* Build information for the DApp: a pure nix build is particularly suitable, since this will identify versions of  libraries, compilers, OS, etc.\n* For the on-chain code for a DApp, the specific contracts to be audited.\n\n#### *Versioning*\n\nVersioning information needs to be given in a way that allows end users of a DApp to determine whether or not the version of the DApp that they are using is covered by certification information held on blockchain.\n\n\nThis can be done in a number of different ways, depending on the type of audit. These include:\n1. The hash of a URL for a commit to a publicly-available repository.\n2. A hash that identifies the files that contain the on-chain code that has been audited, e,g computing, from the root of the repository, listed in lexicographic order.\n\n#### *Registration*\n\nIt is planned that DApps will be registered on the Cardano blockchain. This is currently under discussion. Once that discussion has been settled, it will also be possible to provide on-chain evidence of audit, linked to a registered entity. The mechanism for this is described in a separate document which it is intended to make into another CIP. A current draft of that document is here: [Proof of Audit document](https://docs.google.com/document/d/1FvgX8QiGKVPv4c7HanZ92zwstD9U1amOf8eHvyIb1dI).\n\n### Requirements for Auditors\n\n#### *Responsibilities*\nAuditors shall be able to carry out the following activities: \n* Review the requirement specification document against the intended environment and use so as to:\n   * Identify any inconsistencies, security flaws or incomplete requirements\n   * Identify any implicit assumptions and whether they are justifiable or not\n   * Evaluate the adequacy of strategies applied by the submitter to guarantee the consistency, correctness and completeness of the requirements\n   * Identify a threat model to guarantee that any identified mitigations are indeed appropriate against a list of possible vulnerabilities for Cardano smart contracts, and which is currently being finalised.\n*  The source code shall be audited by manual and/or automated means. In particular,\n   * The source code shall be reviewed against the requirements to ensure that all of these are properly taken into account and completely fulfilled.\n   * The adequacy of the source code documentation and traceability with the requirements shall be assessed.\n   * The source code shall be free from coding patterns/programming mistakes that may introduce exploitable vulnerabilities/failures leading to security issues.\n* Produce a detailed audit report describing scope, methodology, and results categorised by severity. In particular,\n   * Any discrepancies, deviations or spotted vulnerabilities shall be described and classified with an appropriate severity level. Recommendations to rectify the identified deficiencies shall also be provided whenever appropriate.\n   * When automated tools are used as a replacement for manual review/code inspection, they shall be documented or referenced. Note that it’s the responsibility of the auditor to ensure that such tooling may not exhibit potential failures that can adversely affect the review outcome.\n   * Any strategies/methodologies used to assess the consistency, correctness and completeness of the requirements shall also be documented or referenced.\n\n#### *Key competencies*\n\nAuditors shall provide credentials for the following competencies:\n* They shall have an in-depth knowledge of the syntax and semantics of the smart contract language to be audited, the underlying blockchain technology and associated computation and cost models.\n* They shall be competent in the strategies and methods used to elaborate threat models.\n* They shall be competent in assessing the suitability of methods (or combination of methods) used to justify the consistency, correctness and completeness of requirements against the list of common vulnerabilities pertinent to the smart contract domain and to guarantee (as far as possible) the absence of security flaws in the design.\n* They shall be competent in various test and verification methods and have solid background in the various test coverage criteria (i.e., statement, data flow, branching, compound condition, MC/DC and Path).\n* They shall also be able to assess whether the set of test cases produced for each specific test objective/property are sufficient enough to cover all the possible functional cases.\n* They shall have analytical and critical thinking ability pertaining to the:\n   * deployment and execution of smart contracts on the underlying blockchain technology;\n   * Potential attacks or sequence of events relative to the smart contract’s logic that may lead to an unsafe state or invalidate some of the fundamental properties of the contract.\n* They shall be able to judge the adequacy of the justifications provided by submitters w.r.t., development processes (e.g., requirement elicitation techniques, threat models, test objectives and test cases, coding standard, quality management, etc) for Level 2 certification.\n\n#### *Disclosure*\nDisclosure\nIt is common – but not universal – practice for disclosure/publication of audit report, for example as a part of a responsible disclosure policy. A typical policy would be to publish a report after a certain period (e.g. 30-90 day) or at the point that a DApp goes live, whichever is earlier.\n\n## Rationale: how does this CIP achieve its goals?\n\nThese guidelines are the result of a process of discussion between IOG staff and members of the audit and academic communities over a series of online meetings in February and March 2022. Audit organisations involved include Tweag, WellTyped, Certik, Runtime Verification, BT Block, MLabs, Quviq and Hachi/Meld, all of which supported the guidelines outlined here.\n\n## Path to active\n\n### Acceptance Criteria\n\n- [ ] Evidence that Cardano audits are being performed according to this proposed standard, by reference to specific audit(s) citing CIP-0052 and containing these audit elements.\n\n### Implementation Plan\n\n- [x] Initial set of Cardano auditors provided with CIP, with others added afterward along with contact information and verification keys.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n\n"
  },
  {
    "path": "CIP-0052/Tx-spec.md",
    "content": "# Cardano Tx blueprint specification\n\n## Purpose\nEstablish a standard submitter requirement for a Plutus on-chain audit. This standard is designed to be orthogonal to the domain of the DApp, easy to write, intuitive and helpful for the auditor and finally, concrete.\n\n## Content\nThe common aspect to all Plutus DApps is their transaction blueprint specification. That is, what are the allowable transactions for the particular set of validator scripts and monetary policies in question and what are the specific datum/redeemer pairs that must be consumed and the expectations on the produced datums.\n\nThis document should include the system flow or transaction dependency. For example, if the system is a DEX, we would expect the flow to outline that one must initiate a pool *before* applying an order to it.\n\n## Format\nDesigned to be as intuitive as possible. No additional explanation needed after looking at an example:\n```YAML\ntransactions:\n  openPool:\n    inputs:\n      pkUtxo:\n        value: v\n        satisfies: v must have 2 coins with at least M amount. # spoken-language annotation\n\n    mints:\n      factoryToken:\n        amount: 1\n\n    outputs:\n      scriptUtxo:\n        script: poolValidator\n        datum: Pool v\n        value: v <> factoryToken(1)\n\n  buy:\n    inputs:\n      scriptUtxo:\n        script: poolValidator\n        datum: Pool v1\n        redeemer: Buy\n\n      pkUtxo:\n        address: a\n        value: v2\n\n    outputs:\n      scriptUtxo:\n        script: poolValidator\n        datum: Pool buyEquationPool(v1, v2)\n        value: buyEquationPool(v1, v2) # buyEquation is a pure-math formula listed somewhere…\n\n      pkUtxo:\n        address: a\n        value: buyEquationBuyer(v1, v2)\n```\n\n## Format Considerations\nWe should rely on a simple textual format for two reasons: \n  *  easy to automatically generate and consume with tooling; and \n  *  easy to incorporate as comments to code and or Markdown files, which is how most clients provide their design documents.\n\n## Specifying Tx-flow\nIn addition to specifying each transaction separately, these will be presented to the chain according to an underlying logic, or flow, which could be seen as a state transition system. Ideally these flows will be specified, but it is understood that specifying those systems formally is a lot of work and detail. We propose a very high-level description of these systems, which omits a lot of detail but conveys the essential information needed by the auditor.\n\nWe advocate for a simple, flat, set of states: all the states' labels appearing. We can easily generate a dot-file from this and it is low-effort for the developer of the contract to produce. Developers and auditors can add more information as they want on the label itself, which should be ids of elements in the transactions listed above.\n```YAML\nflow:\n  startGovernance:\n\tfrom: initial\n\tto: hasNPools(0)\n\n  openPool:\n\tfrom: hasNPools(n)\n\tto: hasNPools(n+1)\n\n  buy:\n\tid: hasNPools(n)\n\n  sell:\n\tid: hasNPools(n)\n\n  closePool:\n\tfrom: hasNPools(n+1)\n\tto: hasNPools(n)\n```\n\nIt is worth noting that `hasNPools(n+1)` should perhaps be read as just a string, not parsing the application of `n+1` to a family of states `hasNPools`. Even if the output graph contains three states labeled `hasNPools(0)`, `hasNPools(n)` and `hasNPools(n+1)` the auditor can still have a clear understanding of the flow of the DApp in question.\n\n"
  },
  {
    "path": "CIP-0054/README.md",
    "content": "---\nCIP: 54\nTitle: Cardano Smart NFTs\nStatus: Proposed\nCategory: Tokens\nAuthors:\n  - Kieran Simkin <hi@clg.wtf>\nImplementors:\n  - Kieran Simkin\nDiscussions:\n  - https://forum.cardano.org/t/cip-draft-cardano-smart-nfts/100470\n  - https://github.com/cardano-foundation/CIPs/pull/263\nCreated: 2022-05-18\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP specifies a standard for an API which should be provided to Javascript NFTs, it also defines some additions to the 721 metadata standard defined in [CIP-0025](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025) which allow an NFT to specify it would like to receive certain current information from the blockchain. \n\n## Motivation: why is this CIP necessary?\n\nCurrently if an NFT creator wishes to change or otherwise “evolve” their NFT after minting, they must burn the token and re-mint. It would be very nice if the user were able to modify their NFT simply by sending it to themselves with some extra data contained in the new transaction metadata. This would allow implementation of something like a ROM+RAM concept, where you have the original immutable part of the NFT (in Cardano’s case represented by the original 721 key from the mint transaction), and you also have a mutable part – represented by any subsequent transaction metadata.\n\nIt would also be nice to be able to retrieve data that has been previously committed to the blockchain, separately to the NFT which wishes to access it. This would be useful for retrieving oracle data such as current Ada price quotes – as well as for allowing an NFT to import another NFT’s data.\n\nFurther to this - for on-chain programatically generated NFTs, it makes sense to mint the code to render the NFT as one token, and then have the individual NFTs contain only the input variables for that code. This CIP specifies an additional metadata option which specifies that an NFT should be rendered by another token - this will massively reduce code duplication in on-chain NFTs.\n\nThis combination of functionality enables many exciting new possibilities with on-chain NFTs.\n\n## Specification\n\n### The Metadata\n\nMinting metadata for Smart NFTs – based on the existing [CIP-0025](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025) standard:\n\n```\n{\n\t\"721\": {\n\t\t\"<policy_id>\": {\n\t\t\t\"<asset_name>\": {\n\t\t\t\t\"name\": <string>,\n\n\t\t\t\t\"image\": <uri | array>,\n\t\t\t\t\"mediaType\": \"image/<mime_sub_type>\",\n\n\t\t\t\t\"description\": <string | array>,\n\n\t\t\t\t\"files\": [{\n\t\t\t\t\t\"id\": <string>\n\t\t\t\t\t\"name\": <string>,\n\t\t\t\t\t\"mediaType\": <mime_type>,\n\t\t\t\t\t\"src\": <uri | array>,\n\t\t\t\t\t<other_properties>\n\t\t\t\t}],\n\n\t\t\t\t\"uses\": {\n\t\t\t\t\t\"transactions\": <string | array>,\n\t\t\t\t\t\"tokens\": <string | array>,\n\t\t\t\t\t\"renderer\": <string>\t  \n\t\t\t\t}\n\t\t\t}\n\t\t},\n\t\t\"version\": \"1.0\"\n\t}\n}\n```\n\nHere we have added the “uses” key – any future additions to the Smart NFT API can be implemented by adding additional keys here. \nWe've also added an additional field to the files array - this is to specify a unique identifier to enable the files to be referenced by the Javascript API below. \n\n#### The transactions key\n\nTo enable evolving NFTs where the NFT monitors a transaction history and changes in response to new transaction metadata, we define a sub-key called “transactions”, which can contain either a string or an array, specifying the tokens or addresses the NFT wishes to receive the transaction history for. These transaction histories will be provided to the NFT via the Javascript API detailed below.\n\nWe also define a special keyword “own” which can be used to monitor the NFT’s own transaction history. So if we wish to create an “evolvable” NFT that can respond to additions to its own transaction history, the “uses” key within the metadata would look like:\n\n```\n\t\"uses\": {\n\t\t\"transactions\": \"own\"\n\t}\n```\n\nIf you wanted to create an evolving NFT which monitors its own transaction history, as well as that of an external smart contract address, the metadata would look like this:\n\n```\n \t\"uses\": {\n\t\t\"transactions\": [\n\t\t\t\"own\",\n\t\t\t\"addr1wywukn5q6lxsa5uymffh2esuk8s8fel7a0tna63rdntgrysv0f3ms\"\n\t\t]\t\t\t\n\t}\n```\nFinally, we also provide the option to receive the transaction history for a specific token other than the NFT itself (generally this is intended to enable import of Oracle data or control data from an external source – although monitoring an address transaction history could also be used for that). \n\nWhen specifying an external token to monitor, you should do so via the token’s fingerprint as in this example:\n\n```\n \t\"uses\": {\n\t\t\"transactions\": [\n\t\t\t\"own\",\t\t\t\n\t\t\t\"asset1frc5wn889lcmj5y943mcn7tl8psk98mc480v3j\"\n\t\t]\n\t}\n```\n\n#### The tokens key\n\nTo enable modifier tokens - (that is, a token which you can hold alongside a Smart NFT which changes the Smart NFT's appearance or behaviour in some way); we provide a way for the Smart NFT to monitor the tokens held by a specific address. Similarly to the “transactions” key, the “tokens” key will also accept either a string or array.\n\nIn this case we define the “own” keyword to mean the tokens held by the same stake key that currently holds the Smart NFT itself.\n\nFor example, to create an evolvable NFT which also supports modifier tokens, the “uses” block would look like this: \n\n```\n\t\"uses\": {\n\t\t\"transactions\": \"own\",\n\t\t\"tokens\": \"own\"\n\t}\n```\n\nWe could also monitor a particular smart contract address, for example if we wanted to see how many tokens were listed for sale on a marketplace. The following example creates an NFT that supports modifier tokens and also monitors the tokens held by a script address:\n\n```\n\t\"uses\": {\n\t\t\"tokens\": [\n\t\t\t\"own\",\n\t\t\t\"addr1wywukn5q6lxsa5uymffh2esuk8s8fel7a0tna63rdntgrysv0f3ms\"\n\t\t]\n\t}\n```\n\n#### The renderer key\n\nThe idea behind the renderer key is to reduce code duplication in on-chain Javascript by moving the generative code part of the project into a single asset which is minted once in the policy. Each individual NFT within a project is then just a set of input parameters to the generative script - this totally removes the need to fill the metadata of every mint transaction with encoded HTML and Javascript, as is the case with many on-chain Javascript NFTs now. \n\nWhen a Smart NFT is encountered which specifies another asset as the renderer, the site rendering the NFT should look-up the referenced asset and render that - the rendering token will then be responsible for reading the appropriate information via the Javascript API below and changing its appearance and/or behaviour based on that. In its simplest form, the rendering token could simply read the current token fingerprint and use that to seed a random number generator - this would enable a generative project to mint NFTs without even changing anything in the metadata and still have the renderer change its appearance for each one. In practice though, it's probably cooler to put actual traits like \"colour scheme\" or \"movement speed\" into the metadata and then have the renderer change its behaviour based on that. \n\nVia the Javascript API, the rendering token will always receive the properties of the child token which specified it as its renderer. This means if you wish to use a renderer with a token which also evolves based on its own transaction history, you will need to specify both \"renderer\" and \"transactions\" keys within the child token, and within the renderer token you do not need to specify these keys. \n\nFor example, to create a Smart NFT which is rendered by another token, and is also evolvable based on its own transaction history, the \"uses\" key would look like this:\n\n```\n\t\"uses\": {\n\t\t\"transactions\": \"own\",\n\t\t\"renderer\": \"asset1frc5wn889lcmj5y943mcn7tl8psk98mc480v3j\"\n\t}\n```\n\n### The Javascript API\n\nWhen an on-chain Javascript NFT is rendered which specifies any of the metadata options above, the website / dApp / wallet which creates the `<iframe>` sandbox, should inject the API defined here into that `<iframe>` sandbox. It is worth saying that the wallet dApp integration API from [CIP-0030](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030) should probably not be exposed inside the sandbox, to prevent cross-site-scripting attacks. \n\nThe Paginate data type along with APIError and PaginateError are copied directly from [CIP-0030](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030) and these functions should operate in a similar manner to that API. \n\nIt is recommended that the Smart NFT API not be injected for every NFT – only the ones which specify the relevant metadata - this is an important step so that it’s clear which NFTs require this additional API, and also to enable pre-loading and caching of the required data. We are aiming to expose only the specific data requested by the NFT in its metadata – in this CIP we are not providing a more general API for querying arbitrary data from the blockchain. \n\n*There is potentially a desire to provide a more open-ended interface to query arbitrary data from the blockchain – perhaps in the form of direct access to GraphQL – but that may follow in a later CIP – additional fields which could be added to the `uses: {}` metadata to enable the NFT to perform more complex queries on the blockchain.*\n\nAlthough an asynchronous API is specified – so the data could be retrieved at the time when the NFT actually requests it – it is expected that in most instances the site which renders the NFT would gather the relevant transaction logs in advance, and inject them into the `<iframe>` sandbox at the point where the sandbox is created, so that the data is immediately available to the NFT without having to\nperform an HTTP request. \n\n### `cardano.nft.fingerprint: String`\n\nThe fingerprint of the current token - in the case where we're rendering a child token, this will be the fingerprint of the child token. \n\n### `cardano.nft.metadata : Array`\n \nThe content of the 721 key from the metadata json from the mint transaction of the current NFT - if we are rendering on behalf of a child NFT, this will be the metadata from the child NFT.\n\n### `cardano.nft.getTransactions( string which,  paginate: Paginate = undefined ) : Promise<Object>`\n\nErrors: `APIError`, `PaginateError`\n\nThe argument to this function should be either an address, token fingerprint or the keyword “own”. It must match one of the ones specified via the `transactions` key in the new metadata mechanism detailed above.\n\nThis function will return a list of transaction hashes and metadata relating to the specified address or token. The list will be ordered by date with the newest transaction first, and will match the following format:\n\n```\n {\n\t\"transactions\": [\n\t\t{ \n\t\t\t\"txHash\":  \"1507d1b15e5bd3c7827f1f0575eb0fdc3b26d69af0296a260c12d5c0c78239e0\",\n\t\t\t\"metadata\": <raw metadata from blockchain>,\n\t\t\t\"datum\": <the datum from the UTXO holding the token, if set>\n\t\t},\n\t\t<more transactions here>\n\t],\n\t\"fetched\": \"2022-05-01T22:39:03.369Z\"\n}\n```\nFor simplicity, we do not include anything other than the txHash and the metadata – since any other relevant details about the transaction can always be encoded into the metadata, there is no need to over-complicate by including other transaction data like inputs, outputs or the date of the transaction etc. That is left for a potential future extension of the API to include more full GraphQL support.\n\n### `cardano.nft.getTokens( string address, paginate: Paginate = undefined ) : Promise<Object>`\n\nErrors: `APIError`, `PaginateError`\n\nThis function accepts either an address or the keyword “own” as its argument - it must match one of the ones specified via the the `tokens` key in the new metadata mechanism detailed above.\n\nThis function will return a list of the tokens held by the address specified in the argument, or held by the same stake key as the current token in the case of the “own” keyword. \n\n```\n {\n\t\"tokens\": [\n\t\t{ \n\t\t\t\"policyID\": \"781ab7667c5a53956faa09ca2614c4220350f361841a0424448f2f30\",\n\t\t\t\"assetName\": \"Life150\",\n\t\t\t\"fingerprint\": \"asset1frc5wn889lcmj5y943mcn7tl8psk98mc480v3j\",\n\t\t\t\"quantity\": 1,\n\t\t\t\"datum\": <the datum from the UTXO holding the token, if set>\n\t\t},\n\t\t<more tokens here>\n\t],\n\t\"fetched\": \"2022-05-01T22:39:03.369Z\"\n}\n```\n\n### `cardano.nft.getFileURL( string id = null, string fingerprint = null ) : Promise<String>`\n\nErrors: `APIError`\n\nThis function provides access to the contents of files listed in the `files[]` array for this NFT - if the NFT is rendering on behalf of another NFT, the files arrays from both should be merged, with the child NFT items overwriting the rendering NFT, in the case of ID conflicts. \n\nThe first argument specifies which entry from the files array should be retreived - if this argument is null, then the NFT's default image should be returned, which will typically come from the NFT's `image` metadata field rather than the files array. \nThe second argument allows you to specify which token's files to search - it should either be the token itself (either the child token or the rendering token, in the case of tokens with a separate renderer). In the case where an NFT also uses the `tokens` part of this API, then the getFileURL() function will also allow you to specify any one of the fingerprints returned by the getTokens() query.\n\nThe URL returned by this function should be in a format that is accessible from within the `<iframe>` sandbox - perhaps using `window.URL.createObjectURL()` to generate a static URL from raw data if necessary. \n\n## Rationale: how does this CIP achieve its goals?\n\nCurrently the NFT sites which support on-chain Javascript NFTs do so by creating a sandboxed `<iframe>` into which they inject the HTML from the NFT’s metadata. From within this sandbox it is not possible to bring-in arbitrary data from external sources – everything must be contained within the NFT, or explicitly bought into the sandbox via an API.\n\nThis proposal suggests an addition to the 721 metadata key from [CIP-0025](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025), to enable an NFT to specify that it would like to receive a particular transaction history accessible to it from within the sandbox – thus defining it as a “Smart NFT”.\n\nIn tandem with the additional metadata, we also define a standard for the Javascript API which is provided to the NFT within the sandbox.\n\n## The Smart NFT toolchain\n\nThis CIP now has a [reference implementation](https://clg.wtf/policy/smart-life) which consists of a [front-end React control](https://github.com/kieransimkin/SmartNFTPortal) which takes care of rendering an NFT - it creates the sandbox and exposes the CIP54 Javascript API to it. This works in tandem with a [backend library](https://github.com/kieransimkin/libcip54) which takes care of reading the necessary data from a dbsync instance and making it available for the front end control to render. \n\nThere is also an [integrated development environment](https://nft-playground.dev/) made available to enable realtime experimentation and debugging of Smart NFTs without having to repeatedly mint new tokens. \n\nFurthermore, [a complete visual blockchain explorer](https://clg.wtf/) has been made available which utilises libcip54 and SmartNFTPortal and fully supports the reference implementation of this standard. \n\nThe first CIP54 collection has been minted on mainnet under the policy ID `1eaf3b3ffb75ff27c43c512c23c6450b307f138281efb1d690b84652` and is [available to see here](https://clg.wtf/policy/smart-life). [A number of other instructive example NFTs](https://nft-playground.dev/examples) have also been provided as part of the NFT Playground website.\n\n[Libcip54](https://github.com/kieransimkin/libcip54), [SmartNFTPortal](https://github.com/kieransimkin/SmartNFTPortal), [Cardano Looking Glass](https://github.com/kieransimkin/looking-glass) and the [NFT Playground](https://github.com/kieransimkin/cip54-playground) are all opensource - pull requests are welcome!\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] Identify at least 1 pair of wallets, minting services, CLIs, or software utilities from separate providers which do at least 1 each of:\n  - [ ] creating NFTs according to this specification\n  - [ ] rendering NFTs according to this specification\n\n### Implementation Plan\n\n- [X] Provide a [reference](https://github.com/kieransimkin/libcip54) [implementation](https://github.com/kieransimkin/smartnftportal) of this scheme, which illustrates both:\n  - [X] [a means of creating a \"Smart NFT\"](https://nft-playground.dev/)\n  - [X] [a means of rendering it](https://clg.wtf/)\n  - [ ] Update this specification to match the new features added in the reference implementation.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0055/README.md",
    "content": "---\nCIP: 55\nTitle: Protocol Parameters (Babbage Era)\nStatus: Active\nCategory: Ledger\nAuthors:\n  - Jared Corduan <jared.corduan@iohk.io>\nImplementors:\n  - IOG\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/265\nCreated: 2022-05-19\nLicense: Apache-2.0\n---\n\n## Abstract\n\nThis CIP extends CIP-0028 to introduce a change to one of the Alonzo protocol parameters in the Babbage era, namely `lovelacePerUTxOWord`.\nWe propose to have this updateable parameter be based on bytes instead of words (eight bytes).\nAdditionally, two Alonzo era protocol parameters were removed, namely the decentralization parameter and the extra entropy parameter.\n\n## Motivation: why is this CIP necessary?\n\n### Lovelace Per UTxO Byte\n\nSince the Shelley era, there has been an minimum number of lovelace requirement for every unspent transaction output.\nThis requirement acts like a deposit, guarding the network from dust (the proliferation of small-valued unspent transaction outputs).\nInitially it was a constant value, since the Shelley era UTxO were simple and quite uniform.\nStarting in the Mary era, however, the constant value was replace with a\n[formula](https://cardano-ledger.readthedocs.io/en/latest/explanations/min-utxo-mary.html)\nto account for the variability in outputs that contained multi-assets.\nThe formula was [changed again](https://cardano-ledger.readthedocs.io/en/latest/explanations/min-utxo-alonzo.html)\nin the Alonzo era.\nBoth the Mary and the Alonzo era formulas provide an upper bound on the size in memory of an unspent transaction output in the Haskell implementation.\nWe would like to simplify the formula to instead count the number of bytes in the CBOR serialization.\n\n### Transitional Praos\n\nTwo Alonzo era protocol parameters need to be removed for the Babbage era, since they relate to `TPraos`.\nTransitional Praos (named `TPraos` in the code base) is the addition of two features to\n[Praos](https://iohk.io/en/research/library/papers/ouroboros-praosan-adaptively-securesemi-synchronous-proof-of-stake-protocol/),\nwhich were added to provide a smooth transition from\n[Ouroboros-BFT](https://iohk.io/en/research/library/papers/ouroboros-bfta-simple-byzantine-fault-tolerant-consensus-protocol).\nIn particular, Transitional Praos included an overlay schedule which could be tuned by the `d` parameter\n(`d == 1` means that all the blocks are produced by the BFT nodes, `d == 0` means that none of them are).\nIt also included a way of injecting extra entropy into the epoch nonce.\nThe extra entropy feature was used precisely once, and was\n[explained wonderfully](https://iohk.io/en/blog/posts/2021/03/29/the-secure-transition-to-decentralization)\nby one of the original authors of the Praos paper.\n\nThe Babbage era removes both of the \"transitional\" features of TPraos, rendering the decentralization parameter\nand the extra entropy parameter useless.\n\n## Specification\n\nThe removal of the decentralization parameter and the extra entropy parameter is self explanatory.\nWe now describe the specification of the `coinsPerUTxOByte` parameter.\n\n### Rename\n\nThe name of the protocol parameter is actually `coinsPerUTxOWord` in the Haskell implementation.\nIt should be renamed to `coinsPerUTxOByte`.\n\n### Translation from the Alonzo era to the Babbage era\n\nAt the moment that the hard fork combinator translates the Alonzo era ledger state to the Babbage era,\nthe current value of `coinsPerUTxOWord` will be converted to\n\n```\n⌊ coinsPerUTxOWord / 8 ⌋\n```\n\n### The new minimum lovelace calculation\n\nIn the Babbage era, unspent transaction outputs will be required to contain _at least_\n\n```\n(160 + |serialized_output|) * coinsPerUTxOByte\n```\n\nmany lovelace. The constant overhead of 160 bytes accounts for the transaction input\nand the entry in the UTxO map data structure (20 words * 8 bytes).\n\n## Rationale: how does this CIP achieve its goals?\n\nWe would like the formula for the minimum lovelace in a unspent transaction output\nbe simpler and easier to reason about by all users of the Cardano network, while at\nthe same time accounting for the size of the output.\n\n### Backwards compatibility\n\nThe [translation](#translation-from-the-alonzo-era-to-the-babbage-era) section\nexplains how we will transition from the `coinsPerUTxOWord` parameter to the `coinsPerUTxOByte` parameter.\nStarting in the Babbage era, update proposals that want to modify `coinsPerUTxOByte` must bear in mind\nthat the measurement is in bytes, not words.\n\nThe two protocol parameters that have been removed, `d` and `extraEntropy`, can no longer be used\nin protocol parameter updates.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] The Babbage ledger era is activated.\n- [x] Documented parameters have been in operational use by Cardano Node and Ledger as of the Babbage ledger era.\n\n### Implementation Plan\n\n- [x] Babbage ledger era parameters are deemed correct by working groups at IOG.\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0).\n"
  },
  {
    "path": "CIP-0057/README.md",
    "content": "---\nCIP: 57\nTitle: Plutus Contract Blueprint\nStatus: Active\nCategory: Tools\nAuthors:\n  - KtorZ <matthias.benkort@cardanofoundation.org>\n  - scarmuega <santiago@carmuega.me>\nImplementors:\n  - Aiken <https://aiken-lang.org>\n  - Plu-Ts <https://github.com/HarmonicPool/plu-ts>\n  - OpShin <https://github.com/OpShin>\n  - Lucid <https://lucid.spacebudz.io/>\n  - Mesh.js <https://martify.io/>\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/258\n  - https://discord.gg/yUkkhqBnyV\n  - https://github.com/aiken-lang/aiken/issues/972\nCreated: 2022-05-15\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis document specifies a language for documenting Plutus contracts in a machine-readable manner. This is akin to what [OpenAPI](https://swagger.io/specification) or [AsyncAPI](https://www.asyncapi.com/docs/specifications/v2.4.0) are for, documenting HTTP services and asynchronous services respectively. In a similar fashion, A Plutus contract has a binary interface which is mostly defined by its datum and redeemer.\n\nThis document is therefore a meta-specification defining the vocabulary and validation rules with which one can specify a Plutus contract interface, a.k.a **Plutus contract blueprint**.\n\n## Motivation: why is this CIP necessary?\n\nWhile publicly accessible, on-chain contracts are currently inscrutable. Ideally, one would want to get an understanding of transactions revolving around script executions. This is both useful to visualize and to control the evolution of a contract life-cycle; but also, as a user interacting with a contract, to ensure that one is authorizing a transaction to do what it's intended to. Having a machine-readable specification in the form of a JSON-schema makes it easier (or even, possible) to enable a wide variety of use cases from a single concise document, such as:\n\n- Code generators for serialization/deserialization of Contract's elements\n- Contract API Reference / Documentation, also automatically generated\n- Extra automated transaction validation layers\n- Better wallet UI / integration with DApps\n- Automated Plutus-code scaffolding\n\nMoreover, by making the effort to write a clear specification of their contracts, DApps developers make their contracts easier to audit (as they're able to specify the expected behavior).\n\n## Specification\n\n### Overview\n\nThis specification introduces the notion of a _Plutus contract blueprint_, as a JSON document which it itself a _JSON-schema_ as per the definition of given in [JSON Schema: A Media Type for Describing JSON Documents: Draft 2020-12](https://json-schema.org/draft/2020-12/json-schema-core.html).\n\nSaid differently, Plutus blueprints are first and foremost, valid JSON schemas (according to the specification linked above). This specification defines a core vocabulary and additional keywords which are tailored to the specification of Plutus contracts. Tools supporting this specification must implement the semantic and validation rules specified in this document.\n\nMeta-schemas for Plutus blueprints (i.e. schemas used for validating Plutus blueprints themselves) are given [in annexe](./schemas/README.md).\n\nA _Plutus contract blueprint_ is made of a single document describing one or more on-chain validators. By convention, the document is named `plutus.json` and should be located at the root of a project's repository to facilitate its discoverability.\n\n### Document Structure\n\nThe document itself is a JSON object with the following fields:\n\n| Fields                       | Description                                               |\n| ---                          | ---                                                       |\n| [preamble](#preamble)        | An object with meta-information about the contract        |\n| [validators](#validators)    | An object of named validators                             |\n| ?[definitions](#definitions) | A registry of definition re-used across the specification |\n\nNote that examples of specifications are given later in the document to keep the specification succinct enough and not bloated with examples.\n\n#### preamble\n\nThe `preamble` fields stores meta-information about the contract such as version numbers or a short description. This field is mainly meant for humans as a mean to contextualize a specification.\n\n| Fields         | Description                                                                  |\n| ---            | ---                                                                          |\n| title          | A short and descriptive title of the application                             |\n| ?description   | A more elaborate description                                                 |\n| ?version       | A version number for the project.                                            |\n| ?compiler      | Information about the compiler or framework used to produce the validator(s) |\n| ?plutusVersion | The Plutus version assumed for all validators                                |\n| ?license       | A license under which the specification and contract code is distributed     |\n\n#### compiler\n\nThe `compiler` field is optional, but allows specifying metadata about the toolkit that produced the validator and blueprint.\n\n| Fields   | Description                                                      |\n| ---      | ---                                                              |\n| name     | The name of the compiler/framework/tool that generated the file. |\n| ?version | An optional version number in any format.                        |\n\n#### validators\n\nValidators are the essence of the blueprint. This section describes each validator involved in the contract (simple applications will likely have only a single validator). A validator is mainly defined by three things: a title, arguments (i.e parameters, redeemer and/or datum) and some compiled code. Parameters refer to compile-time arguments that can be applied to a validator template. They must be instantiated to produce a final compiled code as they are embedded in the code of the validator itself. This is often the case for validators that must hold on unique external nonce to produce unique hashes.\n\n| Fields        | Description                                                                                                                     |\n| ---           | ---                                                                                                                             |\n| title         | A short and descriptive name for the validator                                                                                  |\n| ?description  | An informative description of the validator                                                                                     |\n| redeemer      | A description of the redeemer format expected by this validator                                                                 |\n| ?datum        | A description of the datum format expected by this validator                                                                    |\n| ?parameters   | A list of parameters required by the script in addition of the datum and redeemer                                               |\n| ?compiledCode | The full compiled and cbor-encoded serialized flat script                                                                       |\n| ?hash         | A blake2b-224 hash digest of the validator script, as found in addresses. Optional, but mandatory if `compiledCode` is provided |\n\n##### redeemer, datum and parameters\n\n`redeemer`, `datum` and `parameters` items all share the same schema structure. They must define a `schema` that describes how to construct valid on-chain values for each of these fields, and they also specify a purpose (`spend`, `mint`, `withdraw` or `publish`) that indicates in which context it can figure. The purpose is either a string, or an applicator `oneOf` that specifies multiple (distinct) purposes. Similarly, an argument is either an object as described below, or an applicator `oneOf` of such objects. In case where it is defined as an applicator, `purpose` values between objects must be strictly non-overlapping as they are used as discriminant in chosing a schema. This allows, for example, to define different redeemer schemas for different purposes.\n\n| Fields       | Description                                                                                                      |\n| ---          | ---                                                                                                              |\n| ?title       | A short and descriptive name for the redeemer, datum or parameter                                                |\n| ?description | An informative description of the redeemer, datum or parameter                                                   |\n| ?purpose     | One of `\"spend\"`, `\"mint\"`, `\"withdraw\"` or `\"publish\"`, or a `oneOf` applicator of those                        |\n| schema       | A _Plutus Data Schema_ using the core vocabulary defined below, or a `oneOf` applicator of _Plutus Data Schemas_ |\n\n#### definitions\n\nA set of extra schemas to be re-used as references across the specification.\n\n### Core vocabulary\n\nPlutus blueprints ultimately describes on-chain data value that can be found at the validator's interface boundaries. This means that while we would generally operate at the level of _Plutus Data_, the vocabulary covers in practice any of the possible Untyped Plutus Core (abbrev. UPLC) primitives that can appear at a validator's boundary (e.g. compile-time parameters). Any UPLC primitive is therefore represented as a schema with a `dataType` keyword. The possible values for `dataType` are detailed just below. In addition, and depending on the value of `dataType`, we may find additional keywords in the vocabulary.\n\n| dataType      | UPLC Type  | Description                                                               |\n| ---           | ---        | ---                                                                       |\n| `integer`     | Data       | A signed integer at an arbitrary precision, wrapped as `iData`.           |\n| `bytes`       | Data       | A bytes string of an arbitrary length, wrapped as `bData`.                |\n| `list`        | Data       | An ordered list of Plutus data, wrapped as `listData`                     |\n| `map`         | Data       | An associative list of Plutus data keys and values, wrapped as `mapData`. |\n| `constructor` | Data       | A constructor with zero, one or many fields, wrapped as `constrData`.     |\n| `#unit`       | Unit       | A builtin unit value (the unary constructor).                             |\n| `#boolean`    | Boolean    | A builtin boolean value.                                                  |\n| `#integer`    | Integer    | A builtin signed integer at an arbitrary precision.                       |\n| `#bytes`      | ByteString | A builtin bytes string of an arbitrary length.                            |\n| `#string`     | String     | A builtin UTF-8 text string.                                              |\n| `#pair`       | ProtoPair  | A builtin pair of `Data` elements.                                        |\n| `#list`       | ProtoList  | A builtin list of `Data` elements.                                        |\n\n> **Warning**\n>\n> While they exist for completeness, frameworks are strongly discouraged to use any of the constructs starting with a `#` as they refer to Plutus Core builtins types used by the Plutus virtual machines but aren't meant to figure in outward-facing interfaces. Validators should, as much as possible, stick to `integer`, `bytes`, `list`, `map` and `constructor` (and any composition of those) for their binary interface.\n\nUsing these primitives, it becomes possible to represent the entire domain (i.e. possible values) which can be manipulated by Plutus contracts.\n\n### Additional keywords\n\nSimilarly to JSON schemas, we provide extra validation keywords and keywords for applying subschemas with logic to further refine the definition of core primitives. Keywords allow to combine core data-types into bigger types and we'll later give some pre-defined definitions which we assume to be part of the core vocabulary and therefore, recognized by any tool supporting this standard.\n\nWhen presented with a validation keyword with a malformed value (e.g. `\"maxLength\": \"foo\"`), programs are expected to return an appropriate error.\n\nBeside, we define a _Plutus Data Schema_ as a JSON object with a set of fields depending on its corresponding data-type. When we refer to a _Plutus Data Schema_, we refer to the entire schema definition, with its validations and with the semantic of each keywords applied.\n\nUnless otherwise specified, keywords are all considered optional.\n\nHere below are detailed all the accepted keywords for each data-type.\n\n#### For any data-type\n\n> **Note** Keywords in this section applies to any instance data-type described above.\n\n##### `dataType`\n\nThe value of this keyword must be a string, with one of the following value listed in the first column of the table above. This keyword is **optional**. When missing, the instance is implicitly typed as an opaque Plutus Data. When set, it defines the realm of other applicable keywords for that instance.\n\n##### `title`\n\nThis keyword's value must be a string. This keyword can be used to decorate a user interface and qualify an instance with some short title.\n\n##### `description`\n\nThis keyword's value must be a string. This keyword can be used to decorate a user interface and provide explanation about the purpose of the instance described by this schema.\n\n##### `$comment`\n\nThis keyword's value must be a string. It is meant mainly for programmers and humans reading the specification. This keyword should be ignored by programs.\n\n##### `allOf`\n\nThis keyword's value must be a non-empty array.  Each item of the array MUST be a valid _Plutus Data Schema_. An instance validates successfully against this keyword if it validates successfully against all schemas defined by this keyword's value.\n\n##### `anyOf`\n\nThis keyword's value must be a non-empty array. Each item of the array must be a valid _Plutus Data Schema_. An instance validates successfully against this keyword if it validates successfully against at least one schema defined by this keyword's value.\n\n##### `oneOf`\n\nThis keyword's value must be a non-empty array. Each item of the array must be a valid _Plutus Data Schema_. An instance validates successfully against this keyword if it validates successfully against exactly one schema defined by this keyword's value.\n\n##### `not`\n\nThis keyword's value must be a valid _Plutus Data Schema_. An instance is valid against this keyword if it fails to validate successfully against the schema defined by this keyword.\n\n#### For `{ \"dataType\": \"bytes\" }`\n\n> **Note** Keywords in this section only applies to `bytes`. Using them in conjunction with an invalid data-type should result in an error.\n\n##### `enum`\n\nThe value of this keyword must be an array of hex-encoded string literals. An instance validates successfully against this keyword if once hex-encoded, its value matches one of the elements of the keyword's values.\n\n##### `maxLength`\n\nThe value of this keyword must be a non-negative integer. A bytes instance is valid against this keyword if its length is less than, or equal to, the value of this keyword.\n\n##### `minLength`\n\nThe value of this keyword must be a non-negative integer. A bytes instance is valid against this keyword if its length is greater than, or equal to, the value of this keyword.\n\n#### For `{ \"dataType\": \"integer\" }`\n\n> **Note** Keywords in this section only applies to `integer`. Using them in conjunction with an invalid type should result in an error.\n\n##### `multipleOf`\n\nThe value of \"multipleOf\" must be a integer, strictly greater than 0. The instance is valid if division by this keyword's value results in an integer.\n\n##### `maximum`\n\nThe value of \"maximum\" must be a integer, representing an inclusive upper limit. This keyword validates only if the instance is less than or exactly equal to \"maximum\".\n\n##### `exclusiveMaximum`\n\nThe value of \"exclusiveMaximum\" must be an integer, representing an exclusive upper limit. The instance is valid only if it has a value strictly less than (not equal to) \"exclusiveMaximum\".\n\n##### `minimum`\n\nThe value of \"minimum\" must be an integer, representing an inclusive lower limit. This keyword validates only if the instance is greater than or exactly equal to \"minimum\".\n\n##### `exclusiveMinimum`\n\nThe value of \"exclusiveMinimum\" must be a integer, representing an exclusive lower limit. The instance is valid only if it has a value strictly greater than (not equal to) \"exclusiveMinimum\".\n\n#### For `{ \"dataType\": \"list\" }`\n\n> **Note** Keywords in this section only applies to `list`. Using them in conjunction with an invalid data-type should result in an error.\n\n##### `items`\n\nThe value of this keyword must be either another _Plutus Data Schema_ or a list of _Plutus Data Schema_. When this keyword is a single schema, it applies its subschema to all child instances of the list. When it is a list, then the list is expected to have exactly the same number of elements as specified by the keyword and each element must match against the schema corresponding to its position. The list variation is useful to represent product types such as tuples.\n\n##### `maxItems`\n\nThe value of this keyword must be a non-negative integer. An array instance is valid against \"maxItems\" if its size is less than, or equal to, the value of this keyword.\n\n##### `minItems`\n\nThe value of this keyword must be a non-negative integer. A list instance is valid against \"minItems\" if its size is greater than, or equal to, the value of this keyword. Omitting this keyword has the same behavior as a value of 0.\n\n##### `uniqueItems`\n\nThe value of this keyword must be a boolean. If this keyword has boolean value false, the instance validates successfully. If it has boolean value true, the instance validates successfully if all of its elements are unique.\n\n#### For `{ \"dataType\": \"map\" }`\n\n> **Note** Keywords in this section only applies to `map`. Using them in conjunction with an invalid data-type should result in an error.\n\n##### `keys`\n\nThe value of this keyword must be another _Plutus Data Schema_. This keyword applies its subschema to all keys of the map.\n\n##### `values`\n\nThe value of this keyword must be another _Plutus Data Schema_. This keyword applies its subschema to all values of the map.\n\n##### `maxItems`\n\nThe value of this keyword must be a non-negative integer. An object instance is valid against \"maxItems\" if its number of key-value pair elements is less than, or equal to, the value of this keyword.\n\n##### `minItems`\n\nThe value of this keyword must be a non-negative integer. An object instance is valid against \"minItems\" if its number of key-value pair elements is greater than, or equal to, the value of this keyword.\n\n#### For `{ \"dataType\": \"constructor\" }`\n\n> **Note** Keywords in this section only applies to `constructor`. Using them in conjunction with an invalid data-type should result in an error.\n\n##### `index`\n\nThis keyword's value must be a non-negative integer. An instance is valid against this keyword if it represents a Plutus constructor whose index is the same as this keyword's value. This keyword is mandatory.\n\n##### `fields`\n\nThis keyword's value must be an array of valid _Plutus Data Schema_; possibly empty. An instance is valid against this keyword if it represents a Plutus constructor for which each field is valid under each subschema given by this keyword's value. Fields are compared positionally. This keyword is mandatory.\n\n## Example(s)\n\n<details>\n  <summary>Aiken's Hello World</summary>\n\n```json\n{\n  \"$schema\": \"https://cips.cardano.org/cips/cip57/schemas/plutus-blueprint.json\",\n\n  \"$id\": \"https://github.com/aiken-lang/aiken/blob/main/examples/hello_world/plutus.json\",\n\n  \"$vocabulary\": {\n    \"https://json-schema.org/draft/2020-12/vocab/core\": true,\n    \"https://json-schema.org/draft/2020-12/vocab/applicator\": true,\n    \"https://json-schema.org/draft/2020-12/vocab/validation\": true,\n    \"https://cips.cardano.org/cips/cip57\": true\n  },\n\n  \"preamble\": {\n    \"title\": \"aiken-lang/hello_world\",\n    \"description\": \"Aiken contracts for project 'aiken-lang/hello_world'\",\n    \"version\": \"1.0.0\",\n    \"plutusVersion\": \"v2\"\n  },\n\n  \"validators\": [\n    {\n      \"title\": \"hello_world\",\n      \"datum\": {\n        \"title\": \"Datum\",\n        \"purpose\": \"spend\",\n        \"schema\": {\n          \"anyOf\": [\n            {\n              \"title\": \"Datum\",\n              \"dataType\": \"constructor\",\n              \"index\": 0,\n              \"fields\": [\n                {\n                  \"title\": \"owner\",\n                  \"dataType\": \"bytes\"\n                }\n              ]\n            }\n          ]\n        }\n      },\n      \"redeemer\": {\n        \"title\": \"Redeemer\",\n        \"schema\": {\n          \"anyOf\": [\n            {\n              \"title\": \"Redeemer\",\n              \"dataType\": \"constructor\",\n              \"index\": 0,\n              \"fields\": [\n                {\n                  \"title\": \"msg\",\n                  \"dataType\": \"bytes\"\n                }\n              ]\n            }\n          ]\n        }\n      },\n      \"compiledCode\": \"58ad0100003232322225333004323253330063372e646e64004dd7198009801002240009210d48656c6c6f2c20576f726c64210013233300100137586600460066600460060089000240206eb8cc008c00c019200022253335573e004294054ccc024cdc79bae300a00200114a226660060066016004002294088c8ccc0040052000003222333300a3370e008004016466600800866e0000d2002300d001001235573c6ea8004526165734ae855d11\",\n      \"hash\": \"5e1e8fa84f2b557ddc362329413caa3fd89a1be26bfd24be05ce0a02\"\n    }\n  ]\n}\n```\n</details>\n\n## Rationale: how does this CIP achieve its goals?\n\n### Documenting binary interfaces\n\nTHe primary goal of this CIP is to offer a mean of interoperability between tools of the ecosystem. In a world where every step of a contract development happens within a single framework -- like it's been the case with PlutusTx, this may not be seen as particularly useful. However, as soon as we start having an ecosystem of tools that operate a different levels (e.g. a language compiler, a transaction building library, an chain explorer, ...) we need some level of interoperability between them. Because the on-chain binary interface is the ultimate source of truth, it only makes sense to find an adequate way to capture it.\n\n### Choice of JSON-Schemas as a foundation\n\nJSON schemas are pervasively used in the industry for describing all sort of data models. Over the years, they have matured enough to be well understood by and familiar to a large portion of developers. Plus, tooling now exists in pretty much any major language to parse and process JSON schemas. Thus, using it as a foundation for the blueprint only makes sense.\n\n### Divergence from JSON-Schemas primitives\n\nThis specification defines a new set of primitives types such as `integer`, `bytes`, `list`, `map` and `constructor` instead of the classic `integer`, `number`, `string`, `bool`, `array`, `object`, `null`. This is not only to reflect better the underlying structure of Plutus data which differs from JSON by many aspects, but also to allow defining or re-defining logic and validation keywords for each of those primitives.\n\nNote however that apart from the keyword `type`, the terminology (and semantic) used for JSON schemas has been preserved to not \"reinvent the wheel\" and makes it easier to build tools on top by leveraging what already exists. Plutus schemas do not use `type` but use `dataType` instead to avoid possible confusion with JSON-schemas. A Plutus data schema is almost a JSON-schemas, but only supports a subset of the available keywords and has subtle differences for some of them (e.g. keywords for the `bytes` data-type operate mostly on hex-encoded strings).\n\n### UPLC builtins\n\nIn the original design specification of CIP-0057, we did not include UPLC builtins. But, there are a few legitimate cases where they might be found in the binary interface of validators. In particular, the `ProtoPair` builtin for constructing 2-tuples. This poses a problem of exhaustiveness (why only include ProtoPair and not the others where similar arguments could probably be made anyway). This is solved by being exhaustive in the capabilities of the blueprint specification, while discouraging their usage.\n\nAnother point of designs here is to make `Data` rather transparent and promote Data's constructor variants as first-class data-types even though it's not faithfully representing what is really happening on-chain. An alternative, more faithful, representation to what's proposed would have been to have `data` as one of the data-type, and then keywords that identifies which of the data variant we are dealing with. So for example, instead of writing:\n\n```\n{ \"dataType\": \"integer\" }\n```\n\nOne would have written:\n\n```\n{ \"dataType\": \"data\", \"variant\": \"iData\" }\n```\n\nYet, because we do want `Data` to be the primary binary interface medium, we keep the former notation as it's more succinct and is a unambiguous shorthand. This also allows to segregate all builtins behind a common notation -- that is, prefixed with a `#`.\n\n### Purpose\n\nOriginally, blueprints did not include any notion of _purpose_. However, as one of the end goal is to utilize blueprint as an input source for user interfaces, it becomes useful to:\n\n1. indicates under what circumstances is a certain validator expected to be used.\n2. provides different schemas based on the purpose\n\nYet, whereas there's a notion of purpose on-chain that is tightly coupled to the script context, different on-chain framework may handle the purpose differently. Some may chose, for example, to abstract that concern away from their users. Which is why we only make the purpose an _optional_ field (except for `datum`) to leave a bit of flexibility for blueprint producers. For consumers, we recommend to treat purposes as discriminants to refine interfaces, but assume that a validator without purpose simply apply to _any_ purpose.\n\n### Additional Resources\n\n- https://json-schema.org/draft/2020-12/json-schema-core.html\n- https://json-schema.org/draft/2020-12/json-schema-validation.html\n\n## Path to Active\n\n### Acceptance criteria\n\n- [x] Blueprints are produced by one or (ideally) more smart-contract frameworks on Cardano.\n  - [x] Aiken (implemented)\n  - [ ] Plu-ts (under way)\n  - [x] OpShin (implemented)\n  - [ ] Helios (under consideration)\n  - [ ] PlutusTx (?)\n  - [ ] Plutarch (?)\n  - [ ] Scalus (?)\n\n- [x] There exist one or (ideally) more tools leveraging the blueprints\n  - [x] [Aiken](https://aiken-lang.org/)\n  - [x] [Mesh.js](https://meshjs.dev/)\n  - [x] [Lucid](https://lucid.spacebudz.io/)\n  - [x] [Bloxbean/cardano-client-lib](https://github.com/bloxbean/cardano-client-lib)\n  - [ ] [PyCardano](https://pycardano.readthedocs.io)\n  - [ ] [Demeter](https://demeter.run/)\n\n### Implementation Plan\n\n- [x] Write specifications for a few real-world contracts, identify and fix gaps\n- [x] PoC of a toolkit generating blueprint definitions for a validator\n- [x] Parse and interpret blueprints to produce smart-constructors for datums and redeemers in various languages\n  - [x] JavaScript\n  - [x] TypeScript\n  - [ ] Python\n- [x] (optional) develop a tool for rendering Plutus blueprint specifications as documentation\n  - [paima/aiken-mdx](https://www.npmjs.com/package/@paima/aiken-mdx)\n\n## Copyright\n\nCC-BY-4.0\n"
  },
  {
    "path": "CIP-0057/schemas/README.md",
    "content": "# Plutus Contract Blueprint - Meta-Schemas\n\nIn these folders you'll find meta JSON-schemas for CIP-0057; Meta-schemas are JSON schemas describing how a Plutus Contract Blueprint should be structured. They also define several common data-types that can be referenced when writing your own specification.\n\nSchema                                                               | Description\n---                                                                  | ---\n[plutus-blueprint.json](./plutus-blueprint.json)                     | The meta-schema for the blueprint specification document itself\n[plutus-blueprint-argument.json](./plutus-blueprint-argument.json)   | The meta-schema for blueprints runtime arguments (i.e datums & redeemers)\n[plutus-blueprint-parameter.json](./plutus-blueprint-parameter.json) | The meta-schema for blueprints compile-time parameters\n[plutus-data.json](./plutus-data.json)                               | Definitions of the _Plutus Data Schema_ and the various supported keywords\n[plutus-builtin.json](./plutus-builtin.json)                         | Definitions of the Untyped Plutus Core builtin types\n"
  },
  {
    "path": "CIP-0057/schemas/plutus-blueprint-argument.json",
    "content": "{\n    \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n    \"$id\": \"https://cips.cardano.org/cips/cip57/schemas/plutus-blueprint-argument.json\",\n    \"$vocabulary\": {\n        \"https://json-schema.org/draft/2020-12/vocab/core\": true,\n        \"https://json-schema.org/draft/2020-12/vocab/applicator\": true,\n        \"https://json-schema.org/draft/2020-12/vocab/validation\": true,\n        \"https://cips.cardano.org/cips/cip57\": true\n    },\n\n    \"type\": \"object\",\n    \"required\": [\"schema\"],\n    \"properties\": {\n        \"title\": {\n            \"type\": \"string\"\n        },\n        \"description\": {\n            \"type\": \"string\"\n        },\n        \"purpose\": {\n            \"anyOf\": [\n                {\n                    \"$ref\": \"#/$defs/purpose\"\n                },\n                {\n                    \"type\": \"object\",\n                    \"required\": [\"oneOf\"],\n                    \"properties\": {\n                        \"oneOf\": {\n                            \"type\": \"array\",\n                            \"minItems\": 1,\n                            \"items\": {\n                                \"$ref\": \"#/$defs/purpose\"\n                            }\n                        }\n                    }\n                }\n            ]\n        },\n        \"schema\": {\n            \"anyOf\": [\n                {\n                    \"$ref\": \"plutus-data.json\"\n                },\n                {\n                    \"$ref\": \"#/$defs/applicator\"\n                }\n            ]\n        }\n    },\n\n    \"$defs\": {\n        \"purpose\": {\n            \"type\": \"string\",\n            \"enum\": [\"spend\", \"mint\", \"withdraw\", \"publish\"]\n        },\n        \"applicator\": {\n            \"type\": \"object\",\n            \"required\": [\"oneOf\"],\n            \"properties\": {\n                \"oneOf\": {\n                    \"$ref\": \"#/$defs/schemaArray\"\n                }\n            }\n        },\n        \"schemaArray\": {\n            \"type\": \"array\",\n            \"minItems\": 1,\n            \"items\": {\n                \"$ref\": \"#\"\n            }\n        }\n    }\n}\n"
  },
  {
    "path": "CIP-0057/schemas/plutus-blueprint-parameter.json",
    "content": "{\n    \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n    \"$id\": \"https://cips.cardano.org/cips/cip57/schemas/plutus-blueprint-parameter.json\",\n    \"$vocabulary\": {\n        \"https://json-schema.org/draft/2020-12/vocab/core\": true,\n        \"https://json-schema.org/draft/2020-12/vocab/applicator\": true,\n        \"https://json-schema.org/draft/2020-12/vocab/validation\": true,\n        \"https://cips.cardano.org/cips/cip57\": true\n    },\n\n    \"type\": \"object\",\n    \"required\": [\"schema\"],\n    \"properties\": {\n        \"title\": {\n            \"type\": \"string\"\n        },\n        \"description\": {\n            \"type\": \"string\"\n        },\n        \"purpose\": {\n            \"anyOf\": [\n                {\n                    \"$ref\": \"#/$defs/purpose\"\n                },\n                {\n                    \"type\": \"object\",\n                    \"required\": [\"oneOf\"],\n                    \"properties\": {\n                        \"oneOf\": {\n                            \"type\": \"array\",\n                            \"minItems\": 1,\n                            \"items\": {\n                                \"$ref\": \"#/$defs/purpose\"\n                            }\n                        }\n                    }\n                }\n            ]\n        },\n        \"schema\": {\n            \"anyOf\": [\n                {\n                    \"$ref\": \"plutus-data.json\"\n                },\n                {\n                    \"$ref\": \"plutus-builtin.json\"\n                },\n                {\n                    \"$ref\": \"#/$defs/applicator\"\n                }\n            ]\n        }\n    },\n\n    \"$defs\": {\n        \"purpose\": {\n            \"type\": \"string\",\n            \"enum\": [\"spend\", \"mint\", \"withdraw\", \"publish\"]\n        },\n        \"applicator\": {\n            \"type\": \"object\",\n            \"required\": [\"oneOf\"],\n            \"properties\": {\n                \"oneOf\": {\n                    \"$ref\": \"#/$defs/schemaArray\"\n                }\n            }\n        },\n        \"schemaArray\": {\n            \"type\": \"array\",\n            \"minItems\": 1,\n            \"items\": {\n                \"$ref\": \"#\"\n            }\n        }\n    }\n}\n"
  },
  {
    "path": "CIP-0057/schemas/plutus-blueprint.json",
    "content": "{\n    \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n    \"$id\": \"https://cips.cardano.org/cips/cip57/schemas/plutus-blueprint.json\",\n    \"$vocabulary\": {\n        \"https://json-schema.org/draft/2020-12/vocab/core\": true,\n        \"https://json-schema.org/draft/2020-12/vocab/applicator\": true,\n        \"https://json-schema.org/draft/2020-12/vocab/validation\": true,\n        \"https://cips.cardano.org/cips/cip57\": true\n    },\n    \"type\": \"object\",\n    \"required\": [\n        \"preamble\",\n        \"validators\"\n    ],\n    \"properties\": {\n        \"preamble\": {\n            \"$ref\": \"#/$defs/preamble\"\n        },\n        \"validators\": {\n            \"type\": \"array\",\n            \"items\": {\n                \"$ref\": \"#/$defs/validator\"\n            }\n        },\n        \"definitions\": {\n            \"type\": \"object\",\n            \"additionalProperties\": true\n        }\n    },\n    \"$defs\": {\n        \"preamble\": {\n            \"type\": \"object\",\n            \"additionalProperties\": false,\n            \"required\": [\n                \"title\",\n                \"version\",\n                \"plutusVersion\"\n            ],\n            \"properties\": {\n                \"title\": {\n                    \"type\": \"string\"\n                },\n                \"description\": {\n                    \"type\": \"string\"\n                },\n                \"version\": {\n                    \"type\": \"string\"\n                },\n                \"plutusVersion\": {\n                    \"type\": \"string\",\n                    \"enum\": [ \"v1\", \"v2\", \"v3\" ]\n                },\n                \"compiler\": {\n                    \"type\": \"object\",\n                    \"required\": [ \"name\" ],\n                    \"additionalProperties\": false,\n                    \"properties\": {\n                        \"name\": {\n                            \"type\": \"string\"\n                        },\n                        \"version\": {\n                            \"type\": \"string\"\n                        }\n                    }\n                },\n                \"license\": {\n                    \"type\": \"string\"\n                }\n            }\n        },\n        \"validator\": {\n            \"type\": \"object\",\n            \"required\": [\n              \"title\",\n              \"redeemer\"\n            ],\n            \"properties\": {\n                \"title\": {\n                    \"type\": \"string\"\n                },\n                \"description\": {\n                    \"type\": \"string\"\n                },\n                \"compiledCode\": {\n                    \"$ref\": \"#/$defs/compiledCode\"\n                },\n                \"hash\": {\n                    \"$ref\": \"#/$defs/hashDigest\"\n                },\n                \"datum\": {\n                    \"$ref\": \"plutus-blueprint-argument.json\"\n                },\n                \"redeemer\": {\n                    \"$ref\": \"plutus-blueprint-argument.json\"\n                },\n                \"parameters\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"$ref\": \"plutus-blueprint-parameter.json\"\n                    }\n                }\n            }\n        },\n        \"compiledCode\": {\n            \"type\": \"string\",\n            \"contentEncoding\": \"base16\",\n            \"description\": \"A cbor-serialised flat-encoded Plutus script\",\n            \"example\": \"01450100002601\"\n        },\n        \"hashDigest\": {\n            \"type\": \"string\",\n            \"contentEncoding\": \"base16\",\n            \"description\": \"Blake2b-224 hash digest of the serialised Plutus script, with language tag prefix.\",\n            \"minLength\": 56,\n            \"maxLength\": 56\n        }\n    }\n}\n"
  },
  {
    "path": "CIP-0057/schemas/plutus-builtin.json",
    "content": "{\n    \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n    \"$id\": \"https://cips.cardano.org/cips/cip57/schemas/plutus-builtin.json\",\n    \"$vocabulary\": {\n        \"https://json-schema.org/draft/2020-12/vocab/core\": true,\n        \"https://json-schema.org/draft/2020-12/vocab/applicator\": true,\n        \"https://json-schema.org/draft/2020-12/vocab/validation\": true,\n        \"https://cips.cardano.org/cips/cip57\": true\n    },\n    \"allOf\": [\n        {\n            \"$ref\": \"#/$defs/annotation\"\n        },\n        {\n            \"anyOf\": [\n                {\n                    \"$ref\": \"#/$defs/primitive\"\n                },\n                {\n                    \"$ref\": \"#/$defs/applicator\"\n                }\n            ]\n        }\n    ],\n    \"$defs\": {\n        \"primitive\": {\n            \"oneOf\": [\n                {\n                    \"$ref\": \"#/$defs/_unit\"\n                },\n                {\n                    \"$ref\": \"#/$defs/_boolean\"\n                },\n                {\n                    \"$ref\": \"#/$defs/_integer\"\n                },\n                {\n                    \"$ref\": \"#/$defs/_bytes\"\n                },\n                {\n                    \"$ref\": \"#/$defs/_string\"\n                },\n                {\n                    \"$ref\": \"#/$defs/_pair\"\n                },\n                {\n                    \"$ref\": \"#/$defs/_list\"\n                }\n            ]\n        },\n        \"_unit\": {\n            \"type\": \"object\",\n            \"required\": [\n                \"dataType\"\n            ],\n            \"properties\": {\n                \"dataType\": {\n                    \"type\": \"string\",\n                    \"const\": \"#unit\"\n                }\n            }\n        },\n        \"_boolean\": {\n            \"type\": \"object\",\n            \"required\": [\n                \"dataType\"\n            ],\n            \"properties\": {\n                \"dataType\": {\n                    \"type\": \"string\",\n                    \"const\": \"#boolean\"\n                }\n            }\n        },\n        \"_integer\": {\n            \"type\": \"object\",\n            \"required\": [\n                \"dataType\"\n            ],\n            \"properties\": {\n                \"dataType\": {\n                    \"type\": \"string\",\n                    \"const\": \"#integer\"\n                }\n            }\n        },\n        \"_bytes\": {\n            \"type\": \"object\",\n            \"required\": [\n                \"dataType\"\n            ],\n            \"properties\": {\n                \"dataType\": {\n                    \"type\": \"string\",\n                    \"const\": \"#bytes\"\n                }\n            }\n        },\n        \"_string\": {\n            \"type\": \"object\",\n            \"required\": [\n                \"dataType\"\n            ],\n            \"properties\": {\n                \"dataType\": {\n                    \"type\": \"string\",\n                    \"const\": \"#string\"\n                }\n            }\n        },\n        \"_list\": {\n            \"type\": \"object\",\n            \"required\": [\n                \"dataType\",\n                \"items\"\n            ],\n            \"properties\": {\n                \"dataType\": {\n                    \"type\": \"string\",\n                    \"const\": \"#list\"\n                },\n                \"items\": {\n                    \"$ref\": \"plutus-data.json\"\n                }\n            }\n        },\n        \"_pair\": {\n            \"type\": \"object\",\n            \"dataType\": \"object\",\n            \"required\": [\n                \"dataType\",\n                \"left\",\n                \"right\"\n            ],\n            \"properties\": {\n                \"dataType\": {\n                    \"type\": \"string\",\n                    \"const\": \"#pair\"\n                },\n                \"left\": {\n                    \"$ref\": \"plutus-data.json\"\n                },\n                \"right\": {\n                    \"$ref\": \"plutus-data.json\"\n                }\n            }\n        },\n        \"annotation\": {\n            \"type\": \"object\",\n            \"properties\": {\n                \"title\": {\n                    \"type\": \"string\"\n                },\n                \"description\": {\n                    \"type\": \"string\"\n                }\n            }\n        },\n        \"applicator\": {\n            \"type\": \"object\",\n            \"maxProperties\": 1,\n            \"minProperties\": 1,\n            \"properties\": {\n                \"allOf\": {\n                    \"$ref\": \"#/$defs/schemaArray\"\n                },\n                \"anyOf\": {\n                    \"$ref\": \"#/$defs/schemaArray\"\n                },\n                \"oneOf\": {\n                    \"$ref\": \"#/$defs/schemaArray\"\n                },\n                \"not\": {\n                    \"$ref\": \"#\"\n                }\n            }\n        },\n        \"schemaArray\": {\n            \"type\": \"array\",\n            \"minItems\": 1,\n            \"items\": {\n                \"$ref\": \"#\"\n            }\n        }\n    }\n}\n"
  },
  {
    "path": "CIP-0057/schemas/plutus-data.json",
    "content": "{\n    \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n    \"$id\": \"https://cips.cardano.org/cips/cip57/schemas/plutus-data.json\",\n    \"$vocabulary\": {\n        \"https://json-schema.org/draft/2020-12/vocab/core\": true,\n        \"https://json-schema.org/draft/2020-12/vocab/applicator\": true,\n        \"https://json-schema.org/draft/2020-12/vocab/validation\": true,\n        \"https://cips.cardano.org/cips/cip57\": true\n    },\n    \"allOf\": [\n        {\n            \"$ref\": \"#/$defs/annotation\"\n        },\n        {\n            \"anyOf\": [\n                {\n                    \"$ref\": \"#/$defs/primitive\"\n                },\n                {\n                    \"$ref\": \"#/$defs/applicator\"\n                }\n            ]\n        }\n    ],\n    \"$defs\": {\n        \"primitive\": {\n            \"oneOf\": [\n                {\n                    \"$ref\": \"#/$defs/integer\"\n                },\n                {\n                    \"$ref\": \"#/$defs/bytes\"\n                },\n                {\n                    \"$ref\": \"#/$defs/list\"\n                },\n                {\n                    \"$ref\": \"#/$defs/map\"\n                },\n                {\n                    \"$ref\": \"#/$defs/constructor\"\n                }\n            ]\n        },\n        \"integer\": {\n            \"type\": \"object\",\n            \"required\": [\n                \"dataType\"\n            ],\n            \"properties\": {\n                \"dataType\": {\n                    \"type\": \"string\",\n                    \"const\": \"integer\"\n                }\n            }\n        },\n        \"bytes\": {\n            \"type\": \"object\",\n            \"required\": [\n                \"dataType\"\n            ],\n            \"properties\": {\n                \"dataType\": {\n                    \"type\": \"string\",\n                    \"const\": \"bytes\"\n                }\n            }\n        },\n        \"list\": {\n            \"type\": \"object\",\n            \"required\": [\n                \"dataType\",\n                \"items\"\n            ],\n            \"properties\": {\n                \"dataType\": {\n                    \"type\": \"string\",\n                    \"const\": \"list\"\n                },\n                \"items\": {\n                    \"oneOf\": [\n                        {\n                            \"$ref\": \"#\"\n                        },\n                        {\n                            \"type\": \"array\",\n                            \"items\": { \"$ref\": \"#\" }\n                        }\n                    ]\n                }\n            }\n        },\n        \"map\": {\n            \"type\": \"object\",\n            \"dataType\": \"object\",\n            \"required\": [\n                \"dataType\",\n                \"keys\",\n                \"values\"\n            ],\n            \"properties\": {\n                \"dataType\": {\n                    \"type\": \"string\",\n                    \"const\": \"map\"\n                },\n                \"keys\": {\n                    \"$ref\": \"#\"\n                },\n                \"values\": {\n                    \"$ref\": \"#\"\n                }\n            }\n        },\n        \"constructor\": {\n            \"type\": \"object\",\n            \"required\": [\n                \"dataType\",\n                \"index\",\n                \"fields\"\n            ],\n            \"properties\": {\n                \"dataType\": {\n                    \"type\": \"string\",\n                    \"const\": \"constructor\"\n                },\n                \"index\": {\n                    \"type\": \"integer\",\n                    \"minimum\": 0\n                },\n                \"fields\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                        \"$ref\": \"#\"\n                    }\n                }\n            }\n        },\n        \"annotation\": {\n            \"type\": \"object\",\n            \"properties\": {\n                \"title\": {\n                    \"type\": \"string\"\n                },\n                \"description\": {\n                    \"type\": \"string\"\n                }\n            }\n        },\n        \"applicator\": {\n            \"type\": \"object\",\n            \"maxProperties\": 1,\n            \"minProperties\": 1,\n            \"properties\": {\n                \"allOf\": {\n                    \"$ref\": \"#/$defs/schemaArray\"\n                },\n                \"anyOf\": {\n                    \"$ref\": \"#/$defs/schemaArray\"\n                },\n                \"oneOf\": {\n                    \"$ref\": \"#/$defs/schemaArray\"\n                },\n                \"not\": {\n                    \"$ref\": \"#\"\n                }\n            }\n        },\n        \"schemaArray\": {\n            \"type\": \"array\",\n            \"minItems\": 1,\n            \"items\": {\n                \"$ref\": \"#\"\n            }\n        }\n    }\n}\n"
  },
  {
    "path": "CIP-0058/README.md",
    "content": "---\nCIP: 58\nTitle: Plutus Bitwise Primitives\nCategory: Plutus\nAuthors:\n    - Koz Ross <koz@mlabs.city>\n    - Maximilian König <maximilian@mlabs.city>\nImplementors:\n    - Las Safin <me@las.rs>\nStatus: Inactive (superseded by CIP-0121 and CIP-0122)\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/283\n    - https://github.com/input-output-hk/plutus/issues/4252\n    - https://github.com/input-output-hk/plutus/pull/4733\nCreated: 2022-05-27\nLicense: Apache-2.0\n---\n\n# Abstract\n\nAdd primitives for bitwise operations, based on `BuiltinByteString`, without \nrequiring new data types.\n\n# Motivation\n\nBitwise operations are one of the most fundamental building blocks of algorithms\nand data structures. They can be used for a wide variety of applications,\nranging from representing and manipulating sets of integers efficiently, to\nimplementations of cryptographic primitives, to fast searches. Their wide\navailability, law-abiding behaviour and efficiency are the key reasons why they\nare widely used, and widely depended on.\n\nAt present, Plutus lacks meaningful support for bitwise operations, which\nsignificantly limits what can be usefully done on-chain. While it is possible to\nmimic some of these capabilities with what currently exists, and it is always\npossible to introduce new primitives for any task, this is extremely\nunsustainable, and often leads to significant inefficiencies and duplication of\neffort. \n\nWe describe a list of bitwise operations, as well as their intended semantics,\ndesigned to address this problem.\n\n## Example applications\n\nWe provide a range of applications that could be useful or beneficial on-chain,\nbut are difficult or impossible to implement without some, or all, of the\nprimitives we propose.\n\n### Finite field arithmetic\n\n[Finite field arithmetic](https://en.wikipedia.org/wiki/Finite_field_arithmetic)\nis an area with many applications, ranging from [linear block\ncodes](https://en.wikipedia.org/wiki/Block_code) to [zero-knowledge\nproofs](https://en.wikipedia.org/wiki/Zero-knowledge_proof) to scheduling and\nexperimental design. Having such capabilities on-chain is useful in for a wide\nrange of applications. \n\nA good example is multiplication over the [Goldilocks\nfield](https://blog.polygon.technology/introducing-plonky2) (with characteristic\n$2^64 - 2^32 + 1$). To perform this operation requires 'slicing' the\nrepresentation being worked with into 32-bit chunks. As finite field\nrepresentations are some kind of unsigned integer in every implementation, in\nPlutus, this would correspond to `Integer`s, but currently, there is no way to\nperform this kind of 'slicing' on an `Integer` on-chain.\n\nFurthermore, finite field arithmetic can gain significant performance\noptimizations with the use of bitwise primitive operations. Two good examples\nare power-of-two division and computing inverses. The first of these (useful\neven in `Integer` arithmetic) replaces a division by a power of 2 with a shift;\nthe second uses a count trailing zeroes operation to compute a multiplicative\nfinite field inverse. While some of these operations could theoretically be done\nby other means, their performance is far from guaranteed. For example, GHC does\nnot convert a power-of-two division or multiplication to a shift, even if the\ndivisor or multiplier is statically-known. Given the restrictions on computation\nresources on-chain, any gains are significant.\n\nHaving bitwise primitives, as well as the ability to convert `Integer`s into a\nform amenable to this kind of work, would allow efficient finite field\narithmetic on-chain. This could enable a range of new uses without being\ninefficient or difficult to port.\n\n### Succinct data structures\n\nDue to the on-chain size limit, many data structures become impractical or\nimpossible, as they require too much space either for their elements, or their\noverheads, to allow them to fit alongside the operations we want to perform on\nthem. [Succinct data\nstructures](https://en.wikipedia.org/wiki/Succinct_data_structure) could serve \nas a solution to this, as they represent data in an amount of space much \ncloser to the entropy limit and ensure only constant overheads. There are \nseveral examples of these, and all rely on bitwise operations for their \nimplementations.\n\nFor example, consider wanting to store a set of `BuiltinInteger`s\non-chain. Given current on-chain primitives, the most viable option involves\nsome variant on a `BuiltinList` of `BuiltinInteger`s; however,\nthis is unviable in practice unless the set is small. To see why, suppose that\nwe have an upper limit of $k$ on the `BuiltinInteger`s we want to store;\nthis is realistic in practically all cases. To store $n$\n`BuiltinInteger`s under the above scheme requires \n\n$$n \\cdot \\left( \\left\\lceil \\frac{\\log_2(k)}{64} \\right\\rceil \\cdot 64  + c\\right)\n$$\n\nbits, where $c$ denotes the constant overhead for each cons cell of\nthe `BuiltinList` holding the data. If the set being represented is dense\n(meaning that the number of entries is a sizeable fraction of $k$), this cost\nbecomes intolerable quickly, especially when taking into account the need to\nalso store the operations manipulating such a structure on-chain with the script\nwhere the set is being used.\n\nIf we instead represented the same set as a\n[bitmap](https://en.wikipedia.org/wiki/Bit_array) based on\n`BuiltinByteString`, the amount of space required would instead be \n\n$$\\left\\lceil \\frac{k}{8} \\right\\rceil \\cdot 8 + \\left\\lceil\n\\frac{\\log_2(k)}{64} \\right\\rceil \\cdot 64\n$$\n\nbits. This is significantly better unless $n$ is small. Furthermore,\nthis representation would likely be more efficient in terms of time in practice,\nas instead of having to crawl through a cons-like structure, we can implement\nset operations on a memory-contiguous byte string:\n\n- The cardinality of the set can be computed as a population count. This\ncan have terrifyingly efficient implementations: the\n[Muła-Kurz-Lemire](https://lemire.me/en/publication/arxiv161107612/)\nalgorithm (the current state of the art) can process four kilobytes per loop\niteration, which amounts to over four thousand potential stored integers.\n- Insertion or removal is a bit set or bit clear respectively.\n- Finding the smallest element uses a count leading zeroes.\n- Finding the last element uses a count trailing zeroes.\n- Testing for membership is a check to see if the bit is set.\n- Set intersection is bitwise and.\n- Set union is bitwise inclusive or.\n- Set symmetric difference is bitwise exclusive or.\n\nA potential implementation could use a range of techniques to make these\noperations extremely efficient, by relying on\n[SWAR](https://en.wikipedia.org/wiki/SWAR)\ntechniques if portability is desired, and\n[SIMD](https://en.wikipedia.org/wiki/Single_instruction,_multiple_data) \ninstructions for maximum speed. This would allow both potentially large \ninteger sets to be represented on-chain without breaking the size limit, and \nnodes to efficiently compute with such, reducing the usage of resources by the \nchain. Lastly, in practice, if compression techniques are used (which also \nrely on bitwise operations!), the number of required bits can be reduced \nconsiderably in most cases without compromising performance: the current \nstate-of-the-art ([Roaring Bitmaps](https://roaringbitmap.org/)) can be\nused as an example of the possible gains.\n\nIn order to make such techniques viable, bitwise primitives are mandatory.\nFurthermore, succinct data structures are not limited to sets of integers, but\n*all* require bitwise operations to be implementable.\n\n### Binary representations and encodings\n\nOn-chain, space comes at a premium. One way that space can be saved is with binary\nrepresentations, which can potentially represent something much closer to the\nentropy limit, especially if the structure or value being represented has\nsignificant redundant structure. While some possibilities for a more efficient\n'packing' already exist in the form of `BuiltinData`, it is rather\nidiosyncratic to the needs of Plutus, and its decoding is potentially quite\ncostly. \n\nBitwise primitives would allow more compact binary encodings to be defined,\nwhere complex structures or values are represented using fixed-size\n`BuiltinByteString`s. The encoders and decoders for these could also be\nimplemented more efficiently than currently possible, as there exist numerous\nbitwise techniques for this.\n\n### On-chain vectors\n\nFor linear structures on-chain, we are currently limited to `BuiltinList`\nand `BuiltinMap`, which don't allow constant-time indexing. This is a\nsignificant restriction, especially when many data structures and algorithms\nrely on the broad availability of a constant-time-indexable linear structure,\nsuch as a C array or Haskell `Vector`. While we could introduce a primitive \ndata type like this, doing so would be a significant undertaking, and would \nrequire both implementing and costing a large API.\n\nWhile for variable-length data, we don't have any alternatives if constant-time\nindexing is a goal, for fixed-length (or limited-length at least) data, there is\na possibility, based on a similar approach taken by the\n[`finitary`](https://hackage.haskell.org/package/finitary)\nlibrary. Essentially, given finitary data, we can transform any item into a\nnumerical index, which is then stored by embedding into a byte array. As the\nindexes are of a fixed maximum size, this can be done efficiently, but only if\nthere is a way of converting indices into bitstrings, and vice versa. Such a\nconstruction would allow using a (wrapper around) `BuiltinByteString` as\na constant-time indexable structure of any finitary type. This is not much of a\nrestriction in practice, as on-chain, fixed-width or size-bounded types are\npreferable due to the on-chain size limit.\n\nCurrently, all the pieces to make this work already exist: the only missing\npiece is the ability to convert indices (which would have to be\n`BuiltinInteger`s) into bit strings (which would have to be\n`BuiltinByteString`s) and back again. With this capability, it would be\npossible to use these techniques to implement something like an array or vector\nwithout new primitive data types.\n\n## Goals\n\nTo ensure a focused and meaningful proposal, we specify our goals below.\n\n### Useful primitives\n\nThe primitives provided should enable implementations of algorithms and data\nstructures that are currently impossible or impractical. Furthermore, the\nprimitives provided should have a high power-to-weight ratio: having them should\nenable as much as possible to be implemented.\n\n### Maintaining as many algebraic laws as possible\n\nBitwise operations, via [Boolean\nalgebras](https://en.wikipedia.org/wiki/Boolean_algebra_(structure)), have a \nlong and storied history of algebraic laws, dating back to important results \nby the like of de Morgan, Post and many others. These algebraic laws are \nuseful for a range of reasons: they guide implementations, enable easier \ntesting (especially property testing) and in some cases much more efficient \nimplementations. To some extent, they also formalize our intuition about how \nthese operations 'should work'. Thus, maintaining as many of these laws in our \nimplementation as possible, and being clear about them, is important.\n\n### Allowing efficient, portable implementations\n\nProviding primitives alone is not enough: they should also be efficient. This is\nnot least of all because many would associate 'primitive operation' with a\nnotion of being 'close to the machine', and therefore fast. Thus, it is on us to\nensure that the implementations of the primitives we provide have to be\nimplementable in an efficient way, across a range of hardware.\n\n### Clear indication of failure\n\nWhile totality is desirable, in some cases, there isn't a sensible answer for us\nto give. A good example is a division-by-zero: if we are asked to do such a\nthing, the only choice we have is to reject it. However, we need to make it as\neasy as possible for someone to realize why their program is failing, by\nemitting a sensible message which can later be inspected.\n\n## Non-goals\n\nWe also specify some specific non-goals of this proposal.\n\n### No metaphor-mixing between numbers and bits\n\nA widespread legacy of C is the mixing of treatment of numbers and blobs of\nbits: specifically, the allowing of logical operations on representations of\nnumbers. This applies to Haskell as much as any other language: according to the\n[Haskell\nReport](https://www.haskell.org/onlinereport/haskell2010/haskellch15.html#x23-20800015), \nit is in fact *required* that any type implementing\n`Bits` implement `Num` first. While GHC Haskell [only mandates\n`Eq`](https://hackage.haskell.org/package/base-4.16.1.0/docs/Data-Bits.html#t:Bits), \nit still defines `Bits` instances for types clearly meant to\nrepresent numbers. This is a bad choice, as it creates complex situations and\npartiality in several cases, for arguably no real gain other than easier\ntranslation of bit twiddling code originally written in C.\n\nEven if two types share a representation, their type distinctness is meant to be\na semantic or abstraction boundary: just because a number is represented as a\nblob of bits does not necessarily mean that arbitrary bit manipulations are\nsensible. However, by defining such a capability, we create several semantic\nproblems:\n\n- Some operations end up needing multiple definitions to take this into\naccount. A good example are shifts: instead of simply having left or right\nshifts, we now have to distinguish *arithmetic* versus *logical*\nshifts, simply to take into account that a shift can be used on something\nwhich is meant to be a number, which could be signed. This creates\nunnecessary complexity and duplication of operations.\n- As Plutus `BuiltinInteger`s are of arbitrary precision, certain\nbitwise operations are not well-defined on them. A good example is bitwise\ncomplement: the bitwise complement of $0$ cannot be defined sensibly, and in\nfact, is partial in its `Bits` instance.\n- Certain bitwise operations on `BuiltinInteger` would have quite\nundesirable semantic changes in order to be implementable. A good example\nare bitwise rotations: we should be able to 'decompose' a rotation left or\nright by $n$ into two rotations (by $m_1$ and $m_2$ such that $m_1 + m_2 = n$)\nwithout changing the outcome. However, because trailing zeroes are not\ntracked by the implementation, this can fail depending on the choice of\ndecomposition, which seems needlessly annoying for no good reason.\n- Certain bitwise operations on `BuiltinInteger` would require\nadditional arguments and padding to define them sensibly. Consider bitwise\nlogical AND: in order to perform this sensibly on `BuiltinInteger`s\nwe would need to specify what 'length' we assume they have, and some policy\nof 'padding' when the length requested is longer than one, or both,\narguments. This feels unnecessary, and it isn't even clear exactly how we\nshould do this: for example, how would negative numbers be padded?\n\nThese complexities, and many more besides, are poor choices, owing more to the\nlegacy of C than any real useful functionality. Furthermore, they feel like a\ncasual and senseless undermining of type safety and its guarantees for very\nsmall and questionable gains. Therefore, defining bitwise operations on\n`BuiltinInteger` is not something we wish to support.\n\nThere are legitimate cases where a conversion from `BuiltinInteger` to\n`BuiltinByteString` is desirable; this conversion should be provided, and\nbe both explicit and specified in a way that is independent of the machine or\nthe implementation of `BuiltinInteger`, as well as total and\nround-tripping. Arguably, it is also desirable to provide built-in support for\n`BuiltinByteString` literals specified in a way convenient to their\ntreatment as blobs of bytes (for example, hexadecimal or binary notation), but\nthis is outside the scope of this proposal.\n\n# Specification\n\n## Proposed operations\n\nWe propose several classes of operations. Firstly, we propose two operations for\ninter-conversion between  `BuiltinByteString` and `BuiltinInteger`:\n\n```haskell\nintegerToByteString :: BuiltinInteger -> BuiltinByteString\n```\n\nConvert a non-negative number to its bitwise representation, erroring if given a\nnegative number.\n\n---\n```haskell\nbyteStringToInteger :: BuiltinByteString -> BuiltinInteger\n```\n\nReinterpret a bitwise representation to its corresponding non-negative number.\n\n---\nWe also propose several logical operations on `BuiltinByteString`s:\n\n```haskell\nandByteString :: BuiltinByteString -> BuiltinByteString -> BuiltinByteString\n```\nPerform a bitwise logical AND on arguments of the same\nlength, producing a result of the same length, erroring otherwise.\n\n---\n```haskell\niorByteString :: BuiltinByteString -> BuiltinByteString -> BuiltinByteString\n```\nPerform a bitwise logical IOR on arguments of the same\nlength, producing a result of the same length, erroring otherwise.\n\n---\n```haskell\nxorByteString :: BuiltinByteString -> BuiltinByteString -> BuiltinByteString\n```\nPerform a bitwise logical XOR on arguments of the same\nlength, producing a result of the same length, erroring otherwise.\n\n---\n```haskell\ncomplementByteString :: BuiltinByteString -> BuiltinByteString\n```\nComplement all the bits in the argument, producing a\nresult of the same length.\n\n---\nLastly, we define the following additional operations:\n\n```haskell\nshiftByteString :: BuiltinByteString -> BuiltinInteger -> BuiltinByteString\n```\nPerforms a bitwise shift of the first argument by a number of bit positions\nequal to the absolute value of the second argument. A positive second argument\nindicates a shift towards higher bit indexes; a negative second argument\nindicates a shift towards lower bit indexes.\n\n---\n```haskell\nrotateByteString :: BuiltinByteString -> BuiltinInteger -> BuiltinByteString\n```\nPerforms a bitwise rotation of the first argument by a number of bit positions\nequal to the absolute value of the second argument.  A positive second argument\nindicates a rotation towards higher bit indexes; a negative second argument\nindicates a rotation towards lower bit indexes.\n\n---\n```haskell\npopCountByteString :: BuiltinByteString -> BuiltinInteger\n```\nReturns the number of $1$ bits in the argument.\n\n---\n```haskell\ntestBitByteString :: BuiltinByteString -> BuiltinInteger -> BuiltinBool\n```\nIf the position given by the second argument is not in\nbounds for the first argument, error; otherwise, if the bit given by that\nposition is $1$, return `True`, and `False` otherwise.\n\n---\n```haskell\nwriteBitByteString :: BuiltinByteString -> BuiltinInteger -> BuiltinBool -> BuiltinByteString\n```\nIf the position given by the second argument is not in bounds for the first \nargument, error; otherwise, set the bit given by that position to $1$ if the \nthird argument is `True`, and $0$ otherwise.\n\n---\n```haskell\ncountLeadingZeroesByteString :: BuiltinByteString -> BuiltinInteger\n```\n\nCounts the initial sequence of 0 bits in the argument (that is, starting from\nindex 0). If the argument is empty, this returns 0.\n\n---\n```haskell\ncountTrailingZeroesByteString :: BuiltinByteString -> BuiltinInteger\n```\n\nCounts the final sequence of 0 bits in the argument (that is, starting from the\n1 bit with the highest index). If the argument is empty, this returns 0.\n\n## Semantics\n\n### Preliminaries\n\nWe define $\\mathbb{N}^{+} = \\\\{ x \\in \\mathbb{N} \\mid x \\neq 0 \\\\}$. We assume\nthat `BuiltinInteger` is a faithful representation of $\\mathbb{Z}$, and will\nrefer to them (and their elements) interchangeably. A *byte* is some \n$x \\in \\\\{ 0,1,\\ldots,255 \\\\}$.\n\nWe observe that, given some *base* $b \\in \\mathbb{N}^{+}$, any \n$n \\in \\mathbb{N}$ can be viewed as a sequence of values in $\\\\{0,1,\\ldots, b - 1\\\\}$.\nWe refer to any such sequence as a *base* $b$ *sequence*. In such a 'view', given \na base $b$ sequence $S = s_0 s_1 \\ldots s_k$, we can compute its corresponding \n$m \\in \\mathbb{N}^+$ as \n\n$$\\sum_{i \\in \\\\{0,1,\\ldots,k\\\\}} b^{k - i} \\cdot s_i$$\n\nIf $b > 1$ and $Z$ is a base $b$ sequence consisting only of zeroes, we observe \nthat for any other base $b$ sequence $S$, $Z \\cdot S$ and $S$ correspond to the \nsame number, where $\\cdot$ is sequence concatenation.\n\nWe use *bit sequence* to refer to a base 2 sequence, and *byte sequence* to\nrefer to a base 256 sequence. For a bit sequence $S = b_0 b_1 \\ldots b_n$, we\nrefer to $\\\\{0,1,\\ldots,n \\\\}$ as the *valid bit indices* of $S$; analogously,\nfor a byte sequence $T = y_0 y_1 \\ldots y_m$, we refer to $\\\\{0,1,\\ldots,m\\\\}$\nas the *valid byte indices* of $T$. We observe that the length of $S$ is $n + 1$\nand the length of $T$ is $m + 1$; we refer to these as the *bit length* of $S$\nand the *byte length* of $T$ for clarity. We write $S[i]$ and $T[j]$ to\nrepresent $b_i$ and $y_j$ for valid bit index $i$ and valid byte index $j$\nrespectively.\n\nWe describe a 'view' of bytes as bit sequences. Let $y$ be a byte; its\ncorresponding bit sequence is $S_y = y_0 y_1 y_2 y_3 y_4 y_5 y_6 y_7$ such that\n\n$$\\sum_{i \\in \\\\{0,1,\\ldots,7\\\\}} 2^{7 - i} \\cdot y_i = y$$\n\nFor example, the byte $55$ has the corresponding byte sequence $00110111$. For\nany byte, its corresponding byte sequence is unique. We use this to extend our\n'view' to byte sequences as bit sequences. Specifically, let \n$T = y_0 y_1 \\ldots y_m$ be a byte sequence. Its corresponding bit sequence \n$S = b_0b_1 \\ldots b_m b_{m + 1} \\ldots b_{8(m + 1) - 1}$ such that for any valid bit index $j$ of $S$,\n$b_j = 1$ if and only if $T[j / 8][j \\mod 8] = 1$, and is $0$ otherwise. \n\nBased on the above, we observe that any `BuiltinByteString` can be a bit\nsequence or a byte sequence. Furthermore, we assume that `indexByteString` and \n`sliceByteString` 'agree' with valid byte indices. More precisely, suppose \n`bs` represents a byte sequence $T$; then `indexByteString bs i` is seen as \nequivalent to $T[\\mathtt{i}]$; we extend this notion to `sliceByteString` \nanalogously. Throughout, we will refer to `BuiltinByteString`s and their 'views'\nas bit or byte sequences interchangeably.\n\n### Representation of `BuiltinInteger` as `BuiltinByteString` and conversions\n\nWe describe the translation of `BuiltinInteger` into `BuiltinByteString`, which\nis implemented as the `integerToByteString` primitive. Let $i$ be the argument\n`BuiltinInteger`; if this is negative, we produce an error, specifying at least\nthe following:\n\n- The fact that specifically the `integerToByteString` operation failed;\n- The reason (given a negative number); and \n- What exact number was given as an argument.\n\nOtherwise, we produce the `BuiltinByteString` corresponding to the base 256\nsequence which represents $i$.\n\nWe now describe the reverse operation, implemented as the `byteStringToInteger`\nprimitive. This treats its argument `BuiltinByteString` as a base 256 sequence,\nand produces its corresponding number as a `BuiltinInteger`. We note that this\nis necessarily non-negative.\n\nWe observe that `byteStringToInteger` 'undoes' `integerToByteString`:\n\n```haskell\nbyteStringToInteger . integerToByteString = id\n```\n\nThe other direction does not necessarily hold: if the argument to\n`byteStringToInteger` contains a prefix consisting only of zeroes, and we\nconvert the resulting `BuiltinInteger` `i` back to a `BuiltinByteString` using\n`integerToByteString`, that prefix will be lost.\n\n### Bitwise logical operations on `BuiltinByteString`\n\nThroughout, let $S = s_0 s_1 \\ldots s_n$ and $T = t_0 t_1 \\ldots t_n$ be byte \nsequences, and let $S^{\\prime}$ and $T^{\\prime}$ be their corresponding bit\nsequences, with bit lengths $n^{\\prime} + 1$ and $m^{\\prime} + 1$ respectively.\nWhenever we specify a *mismatched length error* result, its error message \nmust contain at least the following information:\n\n- The name of the failed operation;\n- The reason (mismatched lengths); and\n- The byte lengths of the arguments.\n\nFor any of `andByteString`, `iorByteString` and `xorByteString`, given inputs\n$S$ and $T$, if $n \\neq m$, the result is an error which must contain at least\nthe following information:\n\n- The name of the failed operation;\n- The reason (mismatched lengths); and\n- The byte lengths of the arguments.\n\nIf $n = m$, the result of each of these operations is the bit sequence \n$U = u_0u_1 \\ldots u_{n^{\\prime}}$, such that for all $i \\in \\\\{0, 1, \\ldots, n^{\\prime}\\\\}$,\n$U[i] = 1$ under the following conditions:\n\n- For `andByteString`, when $S^{\\prime}[i] = T^{\\prime}[i] = 1$;\n- For `iorByteString`, when at least one of $S^{\\prime}[i], T^{\\prime}[i]$ is\n  $1$;\n- For `xorByteString`, when $S^{\\prime}[i] \\neq T^{\\prime}[i]$.\n\nOtherwise, $U[i] = 0$.\n\nWe observe that, for length-matched arguments, each of these operations\ndescribes a commutative and associative operation. Furthermore, for any given\nbyte length $k$, each of these operations has an identity element:\n\n- For `andByteString` and `xorByteString`, the byte sequence of length $k$ where\n  each element is zero; and\n- For `iorByteString`, the byte sequence of length $k$ where each element is\n  255.\n\nLastly, `andByteString` and `iorByteString` have an absorbing element for each\nbyte length $k$, which is the byte sequence of length $k$ where each element is\nzero and 255 respectively.\n\nWe now describe the semantics of `complementByteString`. For input $S$, the\nresult is the bit sequence $U = u_0 u_1 \\ldots u_{n^{\\prime}}$ such that for all\n$i \\in \\{0, 1, \\ldots, n^{\\prime}\\}$, we have $U[i] = 0$ if $S^{\\prime}[i] = 1$ \nand $1$ otherwise.\n\nWe observe that `complementByteString` is self-inverting. We also note\nthe following equivalences hold assuming `b` and `b'` have the\nsame length; these are [De Morgan's\nlaws](https://en.wikipedia.org/wiki/De_Morgan%27s_laws):\n\n```haskell\ncomplementByteString (andByteString b b') = iorByteString (complementByteString b) (complementByteString b')\n```\n\n```haskell\ncomplementByteString (iorByteString b b') = andByteString (complementByteString b) (complementByteString b')\n```\n\n### Mixed operations\n\nThroughout, let $S = s_0 s_1 \\ldots s_n$ be a byte sequence, and let \n$S^{\\prime}$ be its corresponding bit sequence with bit length $n^{\\prime} + 1$.\n\nWe describe the semantics of `shiftByteString` and `rotateByteString`.\nInformally, both of these are 'bit index modifiers': given a positive $i$, the\nindex of a bit in the result 'increases' relative to the argument, and given a\nnegative $i$, the index of a bit in the result 'decreases' relative to the\nargument. This can mean that for some bit indexes in the result, there is no\ncorresponding bit in the argument: we term these *missing indexes*.\nAdditionally, by such calculations, a bit index in the argument may be projected\nto a negative index in the result: we term these *out-of-bounds indexes*. How we\nhandle missing and out-of-bounds indexes is what distinguishes `shiftByteString`\nand `rotateByteString`:\n\n* `shiftByteString` sets any missing index to $0$ and ignores any data at\n  out-of-bounds indexes.\n* `rotateByteString` uses out-of-bounds indexes as sources for missing indexes\n  by 'wraparound'.\n\nWe describe the semantics of `shiftByteString` precisely. Given arguments $S$\nand some $i \\in \\mathbb{Z}$, the result is the bit sequence \n$U = u_0 u_1 \\ldots u_{n^{\\prime}}$ such that for all \n$j \\in \\\\{0, 1, \\ldots, n^{\\prime}\\\\}$, we have $U[j] = S^{\\prime}[j - i]$ if \n$j - i$ is a valid bit index for $S^{\\prime}$ and $0$ otherwise.\n\nLet $k, \\ell \\in \\mathbb{Z}$ \nsuch that either \n$k$ or $\\ell$ is $0$, or \n$k$ and $\\ell$ have the same sign. \nWe observe that, for any `bs`, we have\n\n\n```haskell\nshiftByteString (shiftBytestring bs k) l = shiftByteString bs (k + l)\n```\n\nWe now describe the semantics of `rotateByteString` precisely; we assume the\nsame arguments as for `shiftByteString` above. The result is the bit sequence \n$U = u_0 u_1 \\ldots u_{n^{\\prime}}$ such that for all \n$j \\in \\\\{0, 1, \\ldots, n^{\\prime}\\\\}$, we have $U[j] = S^{\\prime}[n^{\\prime} + j - i \\mod n^{\\prime}]$.\n\nWe observe that for any $k, \\ell$, and any\n`bs`, we have\n\n```haskell\nrotateByteString (rotateByteString bs k) l = rotateByteString bs (k + l)\n```\n\nWe also note that\n\n```haskell\nrotateByteString bs 0 = shiftByteString bs 0 = bs\n```\n\nLastly, we note that\n\n```haskell\nrotateByteString bs k = rotateByteString bs (k `remInteger` (lengthByteString bs * 8))\n```\n\nFor `popCountByteString` with argument $S$, the result is \n\n$$\\sum_{j \\in \\\\{0, 1, \\ldots, n^{\\prime}\\\\}} S^{\\prime}[j]$$\n\nInformally, this is just the total count of $1$ bits. We observe that \nfor any `bs` and `bs'`, we have\n\n```haskell\npopCountByteString bs + popCountByteString bs' = popCountByteString (appendByteString bs bs')\n```\n\nWe now describe the semantics of `testBitByteString` and `writeBitByteString`. \nThroughout, whenever we specify an *out-of-bounds error* result, its error \nmessage must contain at least the following information:\n\n- The name of the failed operation;\n- The reason (out of bounds access);\n- What index was accessed out-of-bounds; and\n- The valid range of indexes.\n\nFor `testBitByteString` with arguments $S$ and some $i \\in \\mathbb{Z}$, if $i$\nis a valid bit index of $S^{\\prime}$, the result is `True` if \n$S^{\\prime}[i] = 1$, and `False` if $S^{\\prime}[i] = 0$. If $i$ is not a valid \nbit index of $S^{\\prime}$, the result is an out-of-bounds error.\n\nFor `writeBitByteString` with arguments $S$, some $i \\in \\mathbb{Z}$ and some\n`BuiltinBool` $b$, if $i$ is not a valid bit index for $S^{\\prime}$, the result\nis an out-of-bounds error. Otherwise, the result is the bit sequence \n$U = u_0 u_1 \\ldots u_{n^{\\prime}}$ such that for all $j \\in \\\\{0, 1, \\ldots, n\\\\}$, we\nhave:\n\n- $U[j] = 1$ when $i = j$ and $b$ is `True`;\n- $U[j] = 0$ when $i = j$ and $b$ is `False`;\n- $U[j] = S^{\\prime}[j]$ otherwise.\n\nLastly, we describe the semantics of `countLeadingZeroesByteString` and\n`countTrailingZeroesByteString`. Given the argument $S$,\n`countLeadingZeroesByteString` gives the result $k$ such that all of the\nfollowing hold:\n\n- $0 \\leq k < n^{\\prime} + 1$;\n- For all $0 \\leq i < k$, $S^{\\prime}[i] = 0$; and\n- If $n^{\\prime} \\neq 0$, then $S^{\\prime}[k] = 1$.\n\nGiven the same argument, `countTrailingZeroesByteString` instead gives the\nresult $k$ such that all of the following hold:\n\n- $0 \\leq k < n^{\\prime} + 1$;\n- For all $k \\leq i < n^{\\prime}$, $S^{\\prime}[i] = 0$; and\n- If $k /neq n^{\\prime} + 1$, then $S^{\\prime}[n^{prime} - k] = 1$.\n\nLet `zeroes` be a `BuiltinByteString` consisting only of zero bytes of length\n`len`. We observe that\n\n```haskell\ncountTrailingZeroesByteString zeroes = countLeadingZeroesByteString zeroes = len\n* 8\n```\n\nFurthermore, for two `BuiltinByteString`s `bs` and `bs'`, we have\n\n```haskell\ncountLeadingZeroesByteString (iorByteString bs bs') = \n  min (countLeadingZeroesByteString bs) (countLeadingZeroesByteString bs')\n\ncountTrailingZeroesByteString (iorByteString bs bs') = \n  min (countTrailingZeroesByteString bs) (countTrailingZeroesByteString bs')\n```\n\nwhere `min` is the minimum value function.\n\n### Costing\n\nAll of the primitives we describe are linear in one of their arguments. For a\nmore precise description, see the table below.\n\nPrimitive | Linear in\n--- | ---\n`integerToByteString` | Argument (only one)\n`byteStringToInteger` | Argument (only one)\n`andByteString` | One argument (same length for both)\n`iorByteString` | One argument (same length for both)\n`xorByteString` | One argument (same length for both)\n`complementByteString` | Argument (only one)\n`shiftByteString` | `BuiltinByteString` argument\n`rotateByteString` | `BuiltinByteString` argument\n`popCountByteString` | Argument (only one)\n`testBitByteString` | `BuiltinByteString` argument\n`writeBitByteString` | `BuiltinByteString` argument\n`countLeadingZeroesByteString` | Argument (only one)\n`countTrailingZeroesByteString` | Argument (only one)\n\n# Rationale\n\n## Why these operations?\n\nFor work in finite field arithmetic (and the areas it enables), we frequently\nneed to move between the 'worlds' of `BuiltinInteger` and `BuiltinByteString`.\nThis needs to be consistent, and allow round-trips. We simplify this by only\nrequiring conversions work on non-negative integers: this means that the\ntranslations can be simpler and more efficient, and also avoids representational\nquestions for negative numbers.\n\nOur choice of logical AND, IOR, XOR and complement as the primary logical \noperations is driven by a mixture of prior art, utility and convenience. These\nare the typical bitwise logical operations provided in hardware, and in most\nprogramming languages; for example, in the x86 instruction set, the following\nbitwise operations have existed since the 8086:\n\n- `AND`: Bitwise AND.\n- `OR`: Bitwise IOR.\n- `NOT`: Bitwise complement.\n- `XOR`: Bitwise XOR.\n\nLikewise, on the ARM instruction set, the following bitwise operations have\nexisted since ARM2:\n\n- `AND`: Bitwise AND.\n- `ORR`: Bitwise IOR.\n- `EOR`: Bitwise XOR.\n- `ORN`: Bitwise IOR with complement of the second argument.\n- `BIC`: Bitwise AND with complement of the second argument.\n\nGoing 'up a level', the C and Forth programming languages (according to C89 and\nANS Forth respectively) define bitwise AND (denoted `&` and `AND` \nrespectively), bitwise IOR (denoted `|` and `OR` respectively), bitwise XOR \n(denoted ` ^` and `XOR` respectively) and bitwise complement (denoted `~` and \n`NOT` respectively) as primitive bitwise operations. These choices are mirrored \nby basically all 'high-level' languages; for example, Haskell's `Bits` type\nclass defines these same four operations as `.&.`, `.|.`, `xor` and `complement`\nrespectively.\n\nThis ubiquity in choices leads to most algorithm descriptions that rely on \nbitwise operations to assume that these specific four operations are \n'primitive', implying that they are constant-time and constant-cost. While we\ncould reduce the number of primitive bitwise operations (and, in fact, due to\nPost, we know that there exist two operations that can implement all of them),\nthis would be both inconvenient and inefficient. As an example, consider\nimplementing XOR using AND, IOR and complement: this would translate `x XOR y`\ninto \n\n```\n(COMPLEMENT x AND y) IOR (x AND COMPLEMENT y)\n```\n\nThis is both needlessly complex, and also inefficient, as it requires copying\nthe arguments twice, only to then throw away both copies. This is less of a\nconcern if copying is 'cheap', but given that we need to operate on\nvariable-width data (specifically `BuiltinByteString`s), this seems needlessly\nwasteful.\n\nLike our 'baseline' bitwise operations above, shifts and rotations are widely\nused, and considered as primitive. For example, x86 platforms have had the\nfollowing available since the 8086:\n\n- `RCL`: Rotate left.\n- `RCR`: Rotate right.\n- `SHL`: Shift left.\n- `SHR`: Shift right.\n\nLikewise, ARM platforms have had the following available since ARM2:\n\n- `ROR`: Rotate right.\n- `LSL`: Shift left.\n- `LSR`: Shift right.\n\nWhile C and Forth both have shifts (denoted with `<<` and `>>` in C, and \n`LSHIFT` and `RSHIFT` in Forth), they don't have rotations; however, many \nhigher-level languages do: Haskell's `Bits` type class has `rotate`, which \nenables both left and right rotations.\n\nWhile `popCountByteString` could in theory be simulated using \n`testBitByteString` and a fold, this is quite inefficient: the best way to \nsimulate this operation would involve using something similar to the \nHarley-Seal algorithm, which requires a large lookup table, making it \nimpractical on-chain. Furthermore, population counting is important for several\nclasses of succinct data structure (particularly rank-select dictionaries and\nbitmaps), and is in fact provided as part of the `SSE4.2` x86 instruction set \nas a primitive named `POPCNT`.\n\nIn order to usefully manipulate individual bits, both `testBitByteString`\nand `writeBitByteString` are needed. They can also be used as part of \nspecifying, and verifying, that other bitwise operations, both primitive and\nnon-primitive, are behaving correctly. They are also particularly essential for\nbinary encodings.\n\n`countLeadingZeroesByteString` and `countTrailingZeroesByteString` is an\nessential primitive for several succinct data structures: both Roaring Bitmaps\nand rank-select dictionaries rely on them for much of their usefulness. For\nfinite field arithmetic, these instructions are also beneficial to have\navailable as efficiently as possible. Furthermore, this operation is provided \nin hardware by several instruction sets: \non x86, there exist (at least) `BSF`, `BSR`, `LZCNT` and `TZCNT`, while on ARM, \nwe have `CLZ` for counting leading zeroes. These instructions also exist in higher-level \nlanguages: for example, GHC's `FiniteBits` type class has `countTrailingZeros` \nand `countLeadingZeros`. Lastly, while they can be emulated by\n`testBitByteString`, this is tedious, error-prone and extremely slow.\n\n# Backwards compatibility \n\nAt the Plutus Core level, implementing this proposal introduces no\nbackwards-incompatibility: the proposed new primitives do not break any existing\nfunctionality or affect any other builtins. Likewise, at levels above Plutus\nCore (such as `PlutusTx`), no existing functionality should be affected.\n\nOn-chain, this requires a hard fork, as this introduces new primitives.\n\n# Path to Active\n\nMLabs will implement these primitives, as well as tests for these. Costing will\nhave to be done after this is complete, but must be done by the Plutus Core\nteam, due to limitations in how costing is performed.\n\n# Copyright\n\nThis CIP is licensed under Apache-2.0.\n"
  },
  {
    "path": "CIP-0059/README.md",
    "content": "---\nCIP: 59\nTitle: Terminology Surrounding Core Features\nStatus: Active\nCategory: Meta\nAuthors:\n  - Jared Corduan <jared.corduan@iohk.io>\nImplementors: N/A\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/274\nCreated: 2022-06-09\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP seeks to clarify the language around groups of features.\nAt the very least, it provides some history.\n\n## Motivation: why is this CIP necessary?\n\nWhen @CharlesHoskinson conceived of Cardano, he had a vision for what features the network would support.\nThis vision is still present on the [Cardano roadmap website](https://roadmap.cardano.org).\nIn particular, the features are grouped into \"phases\", which are mostly named after poets (Goguen is the exception).\nThe word \"era\" is used interchangeably with \"phases\" on the roadmap.\n\n### History\n\nThe word \"era\", however, has been muddled by an implementation detail in the Cardano ledger.\nThe Shelley phase was implemented as an entire re-write of the code from the Byron phase.\nWhile the consensus layer for the Shelley phase was written with an abstraction in place for the ledger,\nthe ledger layer was not written with any abstractions to make future phases possible.\n\nUpon starting into the Goguen phase, the ledger team retroactively introduce a notion of \"era\"\ninto the ledger code, and deemed the Shelley features \"the Shelley era\".\nIn hindsight, however, the word \"era\" in unfortunate, since the Goguen phase was completed in the ledger\nby what was called \"the Allegra era, the Mary era, the Alonzo era, and the Babbage era\".\n\nThe names Allegra and Mary were chosen for their connection to the poet Percy Shelley,\nand were only intended to be used as\n[variable names](https://github.com/input-output-hk/cardano-ledger/blob/1cbf1fc2bb005a8206e5b5a7cdf44d35baaca455/eras/shelley-ma/impl/src/Cardano/Ledger/Allegra.hs#L40)\nfor a very specific abstraction used in the ledger code.\n(The story is even a bit more confusing, since the Allegra and Mary era share a lot of code\nand are specified together in the \"Shelley-MA\n[specification](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/mary-ledger.pdf).\nThe letters \"MA\" can hilariously refer to both \"Mary Allegra\" and \"Multi-Assets\".)\n\nHow did we then go from poets to Alonzo?\nRecall that \"Goguen\" was the only non-poet named in the phases on the Cardano roadmap.\nWe found it fitting, therefore, to name the ledger era which introduced Plutus\nafter the person who invented the lambda calculus\n(Plutus Core uses a variant of [system F](https://en.wikipedia.org/wiki/System_F).).\n\nMoreover, going forward, we decided to use names in A, B, C, ... order, names coming from\nother people who walk the line between mathematics and computer science.\nOne lack of consistency to notice is that we have used both first and last names.\nThe inconsistency was mostly driven by the desire to find short and memorable names.\n\nAnother complication to the story is the notion of \"intra-era hard forks\".\nA new era _must_ be introduced with a hard fork, but the ledger can also\nchange semantics during a controlled hard fork with another mechanism, namely\nan intra-era hard fork.\nThis is an implementation detail which involves bumping the major protocol version\nbut not creating a new ledger era.\nThe Alonzo era experienced an intra-era hard fork when going from major protocol version 5 to 6.\n\nYet another complication stems from the named releases.\nWe chose to honor the late Cardano community member and Bulgarian mathematician Vasil Dabov\nby naming a release date after him.\nThe ledger era after the Alonzo era was named Babbage.\nBabbage is a feature set, Vasil is a release date which ushered in the Babbage era.\n\nLastly, it is important to understand that not all of the semantic changes to the Cardano network involve the ledger,\nthough the changes to the ledger are often the most user-facing.\nChanges to the consensus protocol or the networking layer may also involve a hard fork.\nMoreover, there is an abstraction that sits between the consensus and ledger layers,\nwhich we have named the \"protocol\" (a regrettably vague name).\n\nThe distinction between the ledger protocols and the ledger eras\ncorrespond roughly to how block headers are validated (protocol) versus\nhow block bodies are validated (era).\nThe Shelley era used the \"transitional Praos\" protocol (or TPraos for short).\nIt consisted of Praos together with a transition system to move away from Ouroboros-BFT.\nThe Babbage era replaced TPraos with Praos.\n\n## Specification\n\nA table of all the features, as of the time this CIP was submitted, can be found [here](./feature-table.md).\n\nNote that the protocol version mentioned above is unrelated to the node-to-node and node-to-client protocol versions.\nThe consensus layer maintains a versioning scheme for the node queries which does not necessarily\nalign with the protocol version described in this CIP.\n\nNote also that the protocol version present inside of each block header indicates the maximum supported protocol version\nthat the block producer is capable of supporting (see section 13, Software Updates, of the\n[Shelley ledger specification](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/shelley-ledger.pdf)).\n\nLet us use the following language:\n\n* **Phase** - A phase in Cardano is a high level collection of features described on the Cardano roadmap.\n* **Ledger Era** - A ledger era (or era for short if there is no confusion) in Cardano is a collection of ledger features introduced at a hard fork. Moreover, starting with the Alonzo era, they will be named after mathematicians and computer scientists (preferably both!) in A, B, C, ... ordering. Some letters might prove challenging.\n* **Intra-era Hardfork** - An intra-era hard fork in Cardano is a small and focused semantic change to the ledger which requires a hard fork.\n* **Consensus mechanism** - A consensus mechanism in Cardano is a collection of consensus features introduced at a hard fork. Historically, these have had the name \"Ouroboros\" in them.\n* **Ledger Protocol** - A ledger protocol in Cardano is a collection of ledger features sitting between the consensus layer and the ledger layer, roughly characterized by block header validation.\n* **Release Dates** - When we are confident about the release of a new features, we can chose to honor Cardano community members by naming a date after them.\n\n## Rationale: how does this CIP achieve its goals?\n\nIf we can agree to common language, it will greatly improve communication among ourselves and also with new community members.\n\n### Backwards compatibility\n\nSince this is an issue of language, we will strive to use consistent language going forward, and we can correct misalignment when we find it.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Terminology has met with positive response from community.\n- [x] Terminology has continued in use particularly in the CIP process and the Feature Table has been kept up to date.\n\n### Implementation Plan\n\n- [x] Ledger architects have committed to standardising their language for the community.\n- [x] Table of strict definitions, with protocol versions and block heights, is produced to remove any ambiguities.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0059/feature-table.md",
    "content": "# Cardano Features\n\n| Date    | Phase    | Era     | Slot Number | Epoch Number | Protocol Version | Ledger Protocol | Consensus Mechanism     | Notes              |\n|---------|----------|---------|------------:|-------------:|-----------------:|-----------------|-------------------------|--------------------|\n| 2017/09 | Byron    | Byron   |           0 |            0 |              0,0 | -               | Ouroboros Classic       |                    |\n| 2020/02 | Byron    | Byron   |     3801600 |          176 |              1,0 | -               | Ouroboros BFT           |                    |\n| 2020/07 | Shelley  | Shelley |     4492800 |          208 |              2,0 | TPraos          | Ouroboros Praos         |                    |\n| 2020/12 | Goguen   | Allegra |    16588800 |          236 |              3,0 | TPraos          | Ouroboros Praos         |                    |\n| 2021/03 | Goguen   | Mary    |    23068800 |          251 |              4,0 | TPraos          | Ouroboros Praos         |                    |\n| 2021/09 | Goguen   | Alonzo  |    39916975 |          290 |              5,0 | TPraos          | Ouroboros Praos         |                    |\n| 2021/10 | Goguen   | Alonzo  |    43372972 |          298 |              6,0 | TPraos          | Ouroboros Praos         | intra-era hardfork |\n| 2022/09 | Goguen   | Babbage |    72316896 |          365 |              7,0 | Praos           | Ouroboros Praos         | Vasil HF           |\n| 2023/02 | Goguen   | Babbage |    84844885 |          394 |              8,0 | Praos           | Ouroboros Praos         | Valentine HF       |\n| 2024/09 | Voltaire | Conway  |   133660855 |          507 |              9,0 | Praos           | Ouroboros Genesis/Praos | Chang HF           |\n| 2025/01 | Voltaire | Conway  |   146620809 |          537 |             10,0 | Praos           | Ouroboros Genesis/Praos | Plomin HF          |\n"
  },
  {
    "path": "CIP-0060/README.md",
    "content": "---\nCIP: 60\nTitle: Music Token Metadata\nStatus: Active\nCategory: Metadata\nAuthors:\n  - Andrew Westberg <awestberg@projectnewm.io>\n  - Ryan Jones <rjones@projectnewm.io>\n  - Justin Morgan <jusemorgan@gmail.com>\n  - Ian Singer <tcl@fre5hmusic.com>\n  - Anthony Eizmendiz <aeizmendiz@icloud.com>\n  - Session Cruz <session@demu.pro>\n  - Jimmy Londo <SickCityCleveland@gmail.com>\n  - Gudbrand Tokerud <Gudbrand.tokerud@gmail.com>\n  - Kevin St.Clair <kos1777@gmail.com>\n  - Brandon Loyche <dsqise@gmail.com>\n  - Andrew Donovan <adonovan23@gmail.com>\n  - The Finest LLC (DBA So Litty Records) <solittyrecords@gmail.com>\n  - Cristhian Escobar <escobarcristhian18@gmail.com>\n  - Gabriel Stephan Talamantes <contact@psyencelab.media>\nImplementors:\n  - NEWM <newm.io>\n  - SoundRig <soundrig.io>\n  - SickCityNFT <sickcity.xyz>\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/307\n  - https://github.com/cardano-foundation/CIPs/pull/367\n  - https://github.com/cardano-foundation/CIPs/pull/502\n  - https://github.com/cardano-foundation/CIPs/pull/868\nCreated: 2022-07-26\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis proposal defines an extension to CIP-25 and CIP-68 for token metadata specific to music tokens.\n\n## Motivation: why is this CIP necessary?\n\nMusic tokens on Cardano can be either NFTs or FTs and contain links to audio files. In order for players, indexers, and wallets to be able to properly search and categorize a user's music collection, we need to define a common schema for creating music on Cardano. If all parties creating these music tokens follow similar patterns, apps can consume this information and make proper use of it. The existing CIP-25 is a good base to build upon, but for a good music experience, we need to standardize additional fields that will be required specifically for music tokens.\n\n## Specification\n\nThis CIP divides the additional metadata parameters into two categories of `Required` and `Optional`. When minting a music token on Cardano, you are expected to include ALL of the required fields. If you choose to include one or more of the optional fields, they must be named exactly as defined in this CIP. This will properly allow indexing apps and music players to utilize as much of your token metadata as possible without issues.\n\n[CDDL Spec Version 3 ](./cddl/version-3.cddl)<br/>\n[CDDL Spec Version 2 (deprecated)](./cddl/version-2.cddl)<br/>\n[CDDL Spec Version 1 (deprecated)](./cddl/version-1.cddl)\n\n### Summary of v2 Changes ###\nIn version 2 of the CIP-60 spec, `album_title` has been renamed to `release_title`. `release` is a more generic name that covers all types of releases from Albums, EPs, LPs, Singles, and Compilations. At the top level, we are grouping those metadata items that relate to the release under a new key `release`. At the file for each song, there is a new `song` key that holds the metadata specific to the individual song. These changes separate the music-specific metadata from the general CIP-25/CIP-68 NFT metadata. A music player can look at just the information necessary instead of having to ignore extra NFT-related fields. CIP-68 NFTs are officially supported and an example specific to CIP-68 has been added below.\n\n### Summary of v3  Proposed Changes ###\nVersion 3 reorders identifiers like IPN, ISNI, etc into objects tied with the entities they are associated with. `contributing_artists`, `artists`, and `featured_artists` fields are explicitly defined to reduce interpretation.  `ipi` array replaced with `author` array, which includes `ipi` key.  Removed the `parental_advisory` field, as it was redundant (`explicit` is all players need to look for). `lyricist` is removed and merged into `contributing_artist`, under `role`.  `copyright` adds `master` and `composition` to distinguish recording and composition copyright owners.  Certain fields may be included in `release` within \"Album/EP\" `release_type` if they are qualifying GRAM (Group Registration for Works on an Album of Music) publications. This is done in order to help conserve data in otherwise redundant entries.\n\n### Required Fields ###\n| Field | Type | Example(s) | Notes |\n| -------- | -------- | -------- | -------- |\n| artists     | Array\\<Artist\\>   | \"artists\": [{\"name\": \"Sick City\", \"isni\":\"xxxxxxxxxxxxx\", \"links:{ \"website\":\"https://sickcity.xyz\"}}]  | Players should use these values to determine the song's artist, and should be kept minimal. `isni` and `links` are optional.  Included in `song` for \"Single\" and \"Multiple\" releases, and in `release` for \"Album/EP\" types. |\n| release_title| String | \"release_title\": \"Mr. Bad Guy\" | Included in `release` |\n| track_number | Integer | \"track_number\": 1 |  Included in `song` |\n| song_title | String \\| Array\\<String\\> | \"song_title\": \"Let's Turn it On\" |  Included in `song` |\n| song_duration | String | \"song_duration\": \"PT3M21S\"  | ISO8601 Duration Format, included in `song`  https://www.iso.org/iso-8601-date-and-time-format.html |\n| copyright | String | \"copyright\": {\"master\":\"℗ 1985 Sony Records\", \"composition\":\"© 1985 Marvin Gaye\"}  or <br/> \"copyright\": {\"composition\": \"Public Domain\", \"master\": \"℗ 2024 Cool Guy\"} | Included in `release` within \"Album/EP\" `release_type` (ONLY IF **ALL** compositions are owned by the same artist) , and in `song` within \"Single\" and \"Multiple\" releases. |\n| genres | Array\\<String\\> | \"genres\": [\"Rock\",\"Classic Rock\"] | Limited to 3 genres total. Players should ignore extra genres. Included in `song` within \"Single\" and \"Multiple\" releases, and in `release` for \"Album/EP\" releases should all songs share the same `genre` values. |\n| release_type | Enum\\<String\\> | \"release_type\": \"Single\" | Must be \"Single\", \"Album/EP\" for GRAM (Group Registration for Works on an Album of Music- https://www.copyright.gov/rulemaking/gram/) publications, or \"Multiple\" (for all other cases\"). \"Multiple\" and \"Album/EP\" releases need to be wary of txn size limits .  Included in `release`  |\n| music_metadata_version | Integer | \"music_metadata_version\" : \"3\" | Players should look for the presence of this field to determine if the token is a Music Token.  Use integers only. |\n\n#### Optional Fields ###\n| Field | Type | Example(s) | Notes |\n| -------- | -------- | -------- | -------- |\n| isni | String | \"artists\": [{\"name\": \"Sick City\", \"isni\":\"xxxxxxxxxxxxx\", \"links:{ \"website\":\"https://sickcity.xyz\"}}] |  Included in `song` with `artists` and `featured_artists` |\n| links | Map | \"artists\": [{\"name\": \"Sick City\", \"isni\":\"xxxxxxxxxxxxx\", \"links:{ \"website\":\"https://sickcity.xyz\"}}] | Included in `artists` and `featured_artist`, and in `release` where applicable, i.e. if a \"Multiple\" `release_type` is a single artist album and has recurring links |\n| ai_generated | Boolean | \"ai_generated\": \"true\"  | Used to distinguish works that are entirely AI generated. |\n| contributing_artists |  Array\\<Artist\\> | \"contributing_artists\": [{\"name\":\"Jimmy Londo\", \"ipi\":\"158743685\", \"role\":[\"guitars\", \"vocals\"]}]  | Contributing artist are defined as any creative contributor who is not necessarily identified as an author, but will receive performance royalties when applicable.  eg, a band would place the band name in `artists`, while the band members would be listing individually here.  Should not pass to players, but readable within metadata.  May contain `ipn` or `ipi` (based on use/jurisdiction, i.e. `ipi` within the US; enables indexing of similarly named contributors) `links`, and `role`, all of which are optional |\n| ipn | String | \"contributing_artists\": [{\"name\":\"Jimmy Londo\", \"ipn\":\"158743685\", \"role\":[\"guitars\", \"vocals\"]}] |  Included in `song` within `contributing_artists` where used (typically outside US, though internationally recognized.)|\n| role | string | \"contributing_artists\": [{\"name\":\"Jimmy Londo\", \"ipi\":\"158743685\", \"role\":[\"guitars\", \"vocals\"]}] | Included in `song` within `contributing_artists` (declares a contributor's role/contribution to the work), as well as `authors` (establishing role in songwriting, following \"Roles\" from ASCAP)|\n| series | string | \"series\": \"That's What I call Music\" | Included in `release` |\n| collection | string | \"collection\": \"Now Dance\" | Included in `release` |\n| set | string | \"set\": \"86 - 20 Smash Dance Hits of the Year\" | If the song is a part of a collection of songs, such as an album, EP, live performance, etc. that is separate from this release, it can be listed here.  Included in `song` |\n| mood | String | \"mood\": \"Empowered\" | Included in `song` |\n| lyrics | URL | \"lyrics\": \"ipfs://QmSmadTEhB9bJQ1WHq58yN1YZaJo4jv5BwVNGaePvEj4Fy\" | Included in `song` |\n| special_thanks | Array\\<String\\> | \"special_thanks\": [\"Your mom\",\"Your grandma\"] | Included in `song` |\n| visual_artist | String | \"visual_artist\": \"beeple\" | Included in `release` |\n| distributor | String | \"distributor\": \"https://newm.io\" | Included in `release` |\n| release_date | String | \"release_date\": \"2022-07-27\" | ISO8601 Date Format, included in `release` |\n| publication_date | String | \"publication_date\": \"2022-07-27\" | ISO8601 Date Format, included in `release` https://www.iso.org/iso-8601-date-and-time-format.html |\n| catalog_number | Integer | \"catalog_number\": REC#4582 | Catalog numbers for digital releases should only be entered if the label or digital distributor has given a unique catalog number for the release. Included in `release` | \n| bitrate | String | \"bitrate\": \"256 kbit/s\" | Included in `song` |\n| bpm | String | \"bpm\": \"120 BPM\" | Included in `song`|\n| mix_engineer | String | \"mix_engineer\": \"Robert Smith II\" |  Included in `song` for \"Single\" and \"Multiple\" `release_type`, and in `release` for \"Album/EP\" types (if shared across the entire release, otherwise, in `song`). |\n| mastering_engineer | String | \"mastering_engineer\": \"Michael Tyson\" | Included in `song` |\n| producer | String | \"producer\": \"Simon Cowell\" |  Included in `song` for \"Single\" and \"Multiple\" `release_type`, and in `release` for \"Album/EP\" types (if shared across the entire release, otherwise, in `song`). |\n| co_producer | String | \"co_producer\": \"Shavaun Dempsey\" |  Included in `song` for \"Single\" and \"Multiple\" `release_type`, and in `release` for \"Album/EP\" types (if shared across the entire release, otherwise, in `song`). |\n| featured_artists | Array\\<Artist\\> | \"featured_artists\": [{\"name\":\"Paul McCartney\", isni\":\"xxxxxxxxx\", \"links\"{\"website\":\"www.paulmccartney.com\"} }] | `feautured_artists` should be passed to players along with the `artists`, and should be expected to appear as \"artistName(s) ft. featuredArtist(s)\".  Contains `isni` and `links` keys, included in `song`  Should be kept minimal. |\n| recording_engineer | String | \"recording_engineer\": \"Sharon Liston\" |  Included in `song` for \"Single\" and \"Multiple\" `release_type`, and in `release` for \"Album/EP\" types (if shared across the entire release, otherwise, in `song`). |\n| explicit | Boolean | \"explicit\": true |  Included in `song` | \n| isrc | String | \"isrc\": \"US-SKG-22-12345\" |  Included in `song` |\n| iswc | String | \"iswc\": \"T-123456789-Z\" |  Included in `song` |\n| authors | Array\\<Author\\> | \"authors\": [{\"name\":\"Mark Ronson\", \"ipi:\"157896357\", \"share\":\"25%\"}] | Publishers and authors will be listed here. May contain `ipi`, `role`, and `share`. Included in `song` |\n| ipi | String | \"authors\": [{\"name\":\"Mark Ronson\", ipi:\"157896357\", \"role\":\"Composer/Author\", \"share\":\"25%\"}] |  Included in `song` within `authors` and `contributing_artists`|\n| share | String | \"authors\": [{\"name\":\"Mark Ronson\", ipi:\"157896357\", \"share\":\"25%\"}] |  Included in `song` within `authors`.  Total percentage of all listed authors' shares MUST equal 100% |\n| metadata_language | String | \"metadata_language\": \"en-US\" | https://tools.ietf.org/search/bcp47 | Included in `song` |\n| country_of_origin | String | \"country_of_origin\": \"United States\" |  Included in `song` | \n| language | String | \"language\": \"en-US\" | https://tools.ietf.org/search/bcp47 | Included in `song` |\n| derived_from | String | \"derived_from\" : \"Some other work\" |  Included in `song`|\n\n### Examples ##\n\n### Single Release ###\n\n```\n{\n    \"721\": {\n        \"<policyId>\": {\n            \"<assetName>\": {\n                \"name\": \"<releaseName>\",\n                \"image\": \"<mediaURL>\",\n                \"music_metadata_version\": 3,\n                \"release\": {\n                        \"release_type\": \"<Single/Multiple>\",\n                        \"release_title\": \"<releaseTitle>\",\n                        \"distributor\": \"<distributor>\"\n                          },                \n                \"files\": [\n                    {\n                        \"name\": \"<fileName>\",\n                        \"mediaType\": \"<mimeType>\",\n                        \"src\": \"<mediaURL>\",\n                        \"song\": {\n                            \"song_title\": \"<songName>\",\n                            \"song_duration\": \"PT<minutes>M<seconds>S\",\n                            \"track_number\": 1,\n                            \"mood\": \"<mood>\",\n                            \"artists\": [\n                                {\n                                    \"name:\": \"<artistName>\",\n                                    \"isni\": \"<isni>\",\n                                    \"links\": {\n                                            \"<linkName>\": \"<url>\",\n                                            \"<link2Name>\": \"<url>\",\n                                            \"<link3Name>\": \"<url>\"\n                                        }\n                                    },\n                                {\n                                    \"name:\": \"<artistName>\",\n                                    \"isni\": \"<isni>\",\n                                    \"links\": {\n                                            \"<linkName>\": \"<url>\",\n                                            \"<link2Name>\": \"<url>\",\n                                            \"<link3Name>\": \"<url>\"\n                                        }\n                                    }\n                            ],\n                            \"featured_artists\": [\n                                {\n                                    \"name:\": \"<artistName>\",\n                                    \"isni\": \"<isni>\",\n                                    \"links\": {\n                                            \"<linkName>\": \"<url>\",\n                                            \"<link2Name>\": \"<url>\",\n                                            \"<link3Name>\": \"<url>\"\n                                        }\n                                    },\n                               {\n                                    \"name:\": \"<artistName>\",\n                                    \"isni\": \"<isni>\",\n                                    \"links\": {\n                                            \"<linkName>\": \"<url>\",\n                                            \"<link2Name>\": \"<url>\",\n                                            \"<link3Name>\": \"<url>\"\n                                        }\n                                    }\n                            ],\n                            \"authors\": [\n                                {\n                                        \"name\": \"<authorName>\",\n                                        \"ipi\": \"<ipi>\",\n                                        \"share\": \"<percentage>\"\n                                    },\n                                    {\n                                        \"name\": \"<authorName>\",\n                                        \"ipi\": \"<ipi>\",\n                                        \"share\": \"<percentage>\"\n                                    },\n                                    {\n                                        \"name\": \"<authorName>\",\n                                        \"ipi\": \"<ipi>\",\n                                        \"share\": \"<percentage>\"\n                                    }\n                            ],\n                            \"contributing_artists\": [\n                                {\n                                   \"name\": \"<artistName>\",\n                                        \"ipn\": \"<ipi>\",\n                                        \"role\": [\n                                            \"<roleDescription>\",\n                                            \"<roleDescription>\"\n                                        ]\n                                    \n                                },\n                                 {\n                                   \"name\": \"<artistName>\",\n                                        \"ipi\": \"<ipi>\",\n                                        \"role\": [\n                                            \"<roleDescription>\",\n                                            \"<roleDescription>\"\n                                        ]\n                                    \n                                },\n                                 {\n                                   \"name\": \"<artistName>\",\n                                        \"ipi\": \"<ipi>\",\n                                        \"role\": [\n                                            \"<roleDescription>\",\n                                            \"<roleDescription>\"\n                                        ]\n                                    \n                                }\n                            ],\n                            \"collection\": \"<collectionName>\",\n                            \"genres\": [\n                                \"<genre>\",\n                                \"<genre>\",\n                                \"<genre>\"\n                            ],\n                            \"copyright\": {\"master\": \"℗ <year, copyrightHolder>\", \"composition\": \"© <year, copyrightHolder>\"}\n                        }\n                    }\n                    \n                ]\n            }\n        }\n    }\n}\n```\n### Album Release ###\n```\n{\n    \"721\": {\n        \"c00d776a22ca5db986039420b2a9b3f880d593136a9e2262fabeeb58\": {\n            \"ZiplineFromOuterspace\": {\n                \"name\": \"Refraktal - Zipline From Outerspace\",\n                \"image\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                \"music_metadata_version\": 3,\n                \"release\": {\n                    \"release_type\": \"Album/EP\",\n                    \"release_title\": \"Zipline From Outerspace\",\n                    \"copyright\": {\n                        \"master\": \"℗ 2024 Refraktal\",\n                        \"composition\": \"© 2024 Refraktal\"\n                    },\n                    \"artists\": [\n                        {\n                            \"name:\": \"Refraktal\",\n                            \"isni\": \"0000000517483974\",\n                            \"links\": {\n                                \"website\": \"https://refraktal.com\",\n                                \"exclusive_content\": \"https://refraktalnft.duckdns.org\"\n                            }\n                        }\n                    ],\n                    \"contributing_artists\": [\n                        {\n                            \"name\": \"Sudo Scientist\",\n                            \"ipi\": \"1251891449\",\n                            \"role\": [\n                                \"guitar on VOID and Lullaby for My Demons\",\n                                \"synth\",\n                                \"programming\"\n                            ]\n                        },\n                        {\n                            \"name\": \"RX the Pharm Tech\",\n                            \"ipi\": \"1251891057\",\n                            \"role\": [\n                                \"guitar on Bellywub\",\n                                \"synth\",\n                                \"programming\"\n                            ]\n                        }\n                    ],\n                    \"genre\": [\n                        \"Electronic\",\n                        \"Experimental\",\n                        \"Psychedelic\"\n                    ]\n                },\n                \"files\": [\n                    {\n                        \"name\": \"Void\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Void\",\n                            \"song_duration\": \"PT4M21S\",\n                            \"track_number\": 1,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Bellywub\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Bellywub\",\n                            \"song_duration\": \"PT5M31S\",\n                            \"track_number\": 2,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Lullaby for my Demons\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Lullaby for My Demons\",\n                            \"song_duration\": \"PT3M11S\",\n                            \"track_number\": 3,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Meliorism\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Meliorism\",\n                            \"song_duration\": \"PT4M21S\",\n                            \"track_number\": 4,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Zipline From Outerspace\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Zipline From Outerspace\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 5,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT2M12S\",\n                            \"track_number\": 6,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 7,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 8,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 9,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 10,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 11,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 12,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 13,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 14,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 15,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 16,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 17,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 18,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 19,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    },\n                    {\n                        \"name\": \"Another Cool Song\",\n                        \"mediaType\": \"audio/wav\",\n                        \"src\": \"ipfs://QmeeHGqiRo8gvAfhG6MuHSTKv6rQpw2bxbnDkAPYvt9jD2\",\n                        \"song\": {\n                            \"song_title\": \"Another Cool Song\",\n                            \"song_duration\": \"PT3M36S\",\n                            \"track_number\": 20,\n                            \"isrc\": \"US-SKG-22-12345\",\n                            \"iswc\": \"T-123456789-Z\"\n                        }\n                    }\n                ]\n            }\n        }\n    }\n}\n```\n#### CIP-68 ###\n\n```\n{\n    \"constructor\": 0,\n    \"fields\": [\n        {\n            \"map\": [\n                {\"k\": {\"bytes\": \"373231\"}, \"v\": {\n                    \"map\": [\n                        {\"k\": {\"bytes\": \"<encoded policyId>\"}, \"v\": {\n                            \"map\": [\n                                {\"k\": {\"bytes\": \"<encoded assetName>\"}, \"v\": {\n                                    \"map\": [\n                                        {\"k\": {\"bytes\": \"6E616D65\"}, \"v\": {\"bytes\": \"<encoded releaseName>\"}},\n                                        {\"k\": {\"bytes\": \"696D616765\"}, \"v\": {\"bytes\": \"<encoded mediaURL>\"}},\n                                        {\"k\": {\"bytes\": \"6D757369635F6D657461646174615F76657273696F6E\"}, \"v\": {\"int\": 3}},\n                                        {\"k\": {\"bytes\": \"72656C65617365\"}, \"v\": \n                                            {\n                                                \"map\": [\n                                                    {\"k\": {\"bytes\": \"72656C656173655F74797065\"}, \"v\": {\"bytes\": \"<encoded Single/Multiple>\"}},\n                                                    {\"k\": {\"bytes\": \"72656C656173655F7469746C65\"}, \"v\": {\"bytes\": \"<encoded releaseTitle>\"}},\n                                                    {\"k\": {\"bytes\": \"6469737472696275746F72\"}, \"v\": {\"bytes\": \"<encoded distributor>\"}}\n                                                ]\n                                            }\n                                        },\n                                        {\"k\": {\"bytes\": \"66696C6573\"}, \"v\": \n                                            {\n                                                \"array\": [\n                                                    {\n                                                        \"map\": [\n                                                            {\"k\": {\"bytes\": \"6E616D65\"}, \"v\": {\"bytes\": \"<encoded fileName>\"}},\n                                                            {\"k\": {\"bytes\": \"6D6564696154797065\"}, \"v\": {\"bytes\": \"<encoded mimeType>\"}},\n                                                            {\"k\": {\"bytes\": \"737263\"}, \"v\": {\"bytes\": \"<encoded mediaURL>\"}},\n                                                            {\"k\": {\"bytes\": \"736F6E67\"}, \"v\": \n                                                                {\n                                                                    \"map\": [\n                                                                        {\"k\": {\"bytes\": \"736F6E675F7469746C65\"}, \"v\": {\"bytes\": \"<encoded songName>\"}},\n                                                                        {\"k\": {\"bytes\": \"736F6E675F6475726174696F6E\"}, \"v\": {\"bytes\": \"<encoded PT<minutes>M<seconds>S>\"}},\n                                                                        {\"k\": {\"bytes\": \"747261636B5F6E756D626572\"}, \"v\": {\"int\": track#}},\n                                                                        {\"k\": {\"bytes\": \"6D6F6F64\"}, \"v\": {\"bytes\": \"<encoded mood>\"}},\n                                                                        {\"k\": {\"bytes\": \"61727469737473\"}, \"v\": \n                                                                            {\n                                                                                \"array\": [\n                                                                                    {\n                                                                                        \"map\": [\n                                                                                            {\"k\": {\"bytes\": \"6E616D65\"}, \"v\": {\"bytes\": \"<encoded artistName>\"}},\n                                                                                            {\"k\": {\"bytes\": \"69736E69\"}, \"v\": {\"bytes\": \"<encoded ISNI>\"}},\n                                                                                            {\"k\": {\"bytes\": \"6C696E6B73\"}, \"v\": \n                                                                                                {\n                                                                                                    \"map\": [\n                                                                                                        {\"k\": {\"bytes\": \"<encoded linkName>\"}, \"v\": {\"bytes\": \"<encoded url>\"}},\n                                                                                                        {\"k\": {\"bytes\": \"<encoded link2Name>\"}, \"v\": {\"bytes\": \"<encoded url>\"}},\n                                                                                                        {\"k\": {\"bytes\": \"<encoded link3Name>\"}, \"v\": {\"bytes\": \"<encoded url>\"}}\n                                                                                                    ]\n                                                                                                }\n                                                                                            }\n                                                                                        ]\n                                                                                    }\n                                                                                ]\n                                                                            }\n                                                                        },\n                                                                        {\"k\": {\"bytes\": \"6665617475726564_61727469737473\"}, \"v\": \n                                                                            {\n                                                                                \"array\": [\n                                                                                    {\n                                                                                        \"map\": [\n                                                                                            {\"k\": {\"bytes\": \"6E616D65\"}, \"v\": {\"bytes\": \"<encoded artistName>\"}},\n                                                                                            {\"k\": {\"bytes\": \"69736E69\"}, \"v\": {\"bytes\": \"<encoded ISNI>\"}},\n                                                                                            {\"k\": {\"bytes\": \"6C696E6B73\"}, \"v\": \n                                                                                                {\n                                                                                                    \"map\": [\n                                                                                                        {\"k\": {\"bytes\": \"<encoded linkName>\"}, \"v\": {\"bytes\": \"<encoded url>\"}},\n                                                                                                        {\"k\": {\"bytes\": \"<encoded link2Name>\"}, \"v\": {\"bytes\": \"<encoded url>\"}},\n                                                                                                        {\"k\": {\"bytes\": \"<encoded link3Name>\"}, \"v\": {\"bytes\": \"<encoded url>\"}}\n                                                                                                    ]\n                                                                                                }\n                                                                                            }\n                                                                                        ]\n                                                                                    }\n                                                                                ]\n                                                                            }\n                                                                        },\n                                                                        {\"k\": {\"bytes\": \"617574686F7273\"}, \"v\": \n                                                                            {\n                                                                                \"array\": [\n                                                                                    {\n                                                                                        \"map\": [\n                                                                                            {\"k\": {\"bytes\": \"6E616D65\"}, \"v\": {\"bytes\": \"<encoded authorName>\"}},\n                                                                                            {\"k\": {\"bytes\": \"697069\"}, \"v\": {\"bytes\": \"<encoded IPI>\"}},\n                                                                                            {\"k\": {\"bytes\": \"7368617265\"}, \"v\": {\"bytes\": \"<encoded percentage>\"}}\n                                                                                        ]\n                                                                                    }\n                                                                                ]\n                                                                            }\n                                                                        },\n                                                                        {\"k\": {\"bytes\": \"636F6E747269627574696E675F61727469737473\"}, \"v\": \n                                                                            {\n                                                                                \"array\": [\n                                                                                    {\n                                                                                        \"map\": [\n                                                                                            {\"k\": {\"bytes\": \"6E616D65\"}, \"v\": {\"bytes\": \"<encoded artistName>\"}},\n                                                                                            {\"k\": {\"bytes\": \"697069\"}, \"v\": {\"bytes\": \"<encoded IPI>\"}},\n                                                                                            {\"k\": {\"bytes\": \"726F6C65\"}, \"v\": \n                                                                                                {\n                                                                                                    \"array\": [\n                                                                                                        {\"bytes\": \"<encoded roleDescription>\"},\n                                                                                                        {\"bytes\": \"<encoded roleDescription>\"}\n                                                                                                    ]\n                                                                                                }\n                                                                                            }\n                                                                                        ]\n                                                                                    }\n                                                                                ]\n                                                                            }\n                                                                        },\n                                                                        {\"k\": {\"bytes\": \"636F6C6C656374696F6E\"}, \"v\": {\"bytes\": \"<encoded collectionName>\"}},\n                                                                        {\"k\": {\"bytes\": \"67656E726573\"}, \"v\": \n                                                                            {\n                                                                                \"array\": [\n                                                                                    {\"bytes\": \"<encoded genre1>\"},\n                                                                                    {\"bytes\": \"<encoded genre2>\"},\n                                                                                    {\"bytes\": \"<encoded genre3>\"}\n                                                                                ]\n                                                                            }\n                                                                        },\n                                                                        {\"k\": {\"bytes\": \"636F707972696768\"}, \"v\": \n                                                                            {\n                                                                                \"map\": [\n                                                                                    {\"k\": {\"bytes\": \"6D6173746572\"}, \"v\": {\"bytes\": \"<encoded ℗ <year, copyrightHolder>\"}},\n                                                                                    {\"k\": {\"bytes\": \"636F6D706F736974696F6E\"}, \"v\": {\"bytes\": \"<encoded © <year, copyrightHolder>\"}}\n                                                                                ]\n                                                                            }\n                                                                        }\n                                                                    ]\n                                                                }\n                                                            }\n                                                        ]\n                                                    }\n                                                ]\n                                            }\n                                        }\n                                    ]\n                                }}\n                            ]\n                        }}\n                    ]\n                }}\n            ]\n        },\n        {\n            \"int\": 1\n        }\n    ]\n}\n```\n\n## Rationale: how does this CIP achieve its goals?\n\nImplementing this simplifies and commonizes the process for creating music tokens on Cardano. It greatly simplifies the work that apps have to make when consuming such tokens.\n\nThis CIP is the result of several online meetings between many different companies building music-related projects on top of Cardano. These meetings were organized as many in the community started to see fragmentation in the way music NFTs were being minted on Cardano. These meetings gave the opportunity for a bit of a reset and will allow a much brighter future for music on Cardano. As long as all projects agree on some of these basic fields, there is great flexibility in this CIP to do application-specific unique things on top of the music NFT itself. The CIP is intentionally open-ended and can be updated in future versions if there are additional fields that the wider group could benefit from.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Has been implemented by a number of parties, including:\n  - [x] SickCityNFT - sickcity.xyz\n  - [x] NEWM - newm.io\n  - [x] SoundRig - soundrig.io\n  - [x] The Listening Room - https://thelr.io/\n  - [x] Jukeboys\n  - [x] So Litty Records\n  - [x] Arp Radio - https://arpradio.media \n\n### Implementation Plan\n\n- [x] Consensus of companies building music-related Cardano projects to develop a mutually beneficial metadata vocabulary.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n"
  },
  {
    "path": "CIP-0060/cddl/version-1.cddl",
    "content": "string = text .size (0..64)\n\npolicy_id = string / bytes ; hex string for CIP-25 version 1, bytes version 2\nasset_name = string / bytes ; utf-8 for CIP-25 version 1, bytes for version 2\n\nartist_details =\n  {\n    name : string,                                                             ; artist or band name\n    ? image : string / [* string],      ; optional image of the artist\n  }\n\nfiles_details = \n  {\n    name : string,\n    mediaType : string,\n    src : string / [* string],\n\n    ; For Single, these values are defined at the top level. For Multiple, define them for each track.\n    ? artists : [* artist_details],\n    ? album_title : string,\n    ? track_number: uint,\n    ? song_title: string / [* string],\n    ? song_duration: string .regexp \"^P(?!$)(T(?=\\d)(\\d+H)?(\\d+M)?(\\d+S)?)$\",    ; iso8601 duration\n    ? genres: [1*3 string],\n    ? copyright: string,\n\n    ; For Single, these values are defined at the top level. For Multiple, optionally define them for each track\n    ? contributing_artists : [* artist_details],\n    ? series: string,\n    ? collection: string,\n    ? set: string,\n    ? mood: string,\n    ? lyrics: string,\n    ? lyricists: [* string],\n    ? special_thanks: [* string],\n    ? visual_artist: string,\n    ? distributor: string,\n    ? release_date: string,\n    ? publication_date: string,\n    ? catalog_number: uint,\n    ? bitrate: string,\n    ? mix_engineer: string,\n    ? mastering_engineer: string,\n    ? producer: string,\n    ? co_producer: string,\n    ? featured_artist: artist_details,\n    ? recording_engineer: string,\n    ? release_version: uint,\n    ? parental_advisory: string,\n    ? explicit: bool,\n    ? isrc: string,\n    ? iswc: string,\n    ? ipi: [* string],\n    ? ipn: [* string],\n    ? isni: [* string],\n    ? metadata_language: string,\n    ? country_of_origin: string,\n    ? language: string,\n    ? derived_from: string,\n    ? links: { * string => string / [* string] },\n  }\n\nmetadata_details = \n  {\n    name : string,\n    image : string / [* string],\n    music_metadata_version: 1,\n    release_type: \"Single\" / \"Multiple\",\n\n    ; Fields that are required if this is a \"Single\". They are omitted for \"Multiple\" and should be defined under file_details instead.\n    ? artists : [* artist_details],\n    ? album_title : string,\n    ? track_number: uint,\n    ? song_title: string / [* string],\n    ? song_duration: string .regexp \"^P(?!$)(T(?=\\d)(\\d+H)?(\\d+M)?(\\d+S)?)$\",  ; iso8601 duration\n    ? genres: [1*3 string],\n    ? copyright: string,\n\n    ; Fields that are optional for \"Single\". They are omitted for \"Multiple\" and may be defined under file_details instead.\n    ? contributing_artists : [* artist_details],\n    ? series: string,\n    ? collection: string,\n    ? set: string,\n    ? mood: string,\n    ? lyrics: string,\n    ? lyricists: [* string],\n    ? special_thanks: [* string],\n    ? visual_artist: string,\n    ? distributor: string,\n    ? release_date: string,\n    ? publication_date: string,\n    ? catalog_number: uint,\n    ? bitrate: string,\n    ? mix_engineer: string,\n    ? mastering_engineer: string,\n    ? producer: string,\n    ? co_producer: string,\n    ? featured_artist: artist_details,\n    ? recording_engineer: string,\n    ? release_version: uint,\n    ? parental_advisory: string,\n    ? explicit: bool,\n    ? isrc: string,\n    ? iswc: string,\n    ? ipi: [* string],\n    ? ipn: [* string],\n    ? isni: [* string],\n    ? metadata_language: string,\n    ? country_of_origin: string,\n    ? language: string,\n    ? derived_from: string,\n    ? links: { * string => string / [* string] },\n\n    files : [* files_details],                                                 ; was optional in CIP-25, required by CIP-60\n    ? version: 1 / 2,                                                          ; CIP-25 version\n    ? mediaType : string,                                                      ; mediaType for the image. audio goes under files.\n    ? description : string / [* string],\n  }\n\nlabel_metadata = { * policy_id => { * asset_name => metadata_details } }\n\nmetadata = { 721 : uint => label_metadata }"
  },
  {
    "path": "CIP-0060/cddl/version-2.cddl",
    "content": "string = text .size (0..64)\n\npolicy_id = string / bytes ; hex string for CIP-25 version 1, bytes version 2\nasset_name = string / bytes ; utf-8 for CIP-25 version 1, bytes for version 2\n\nartist_details =\n  {\n    name : string,                      ; artist or band name\n    ? image : string / [* string],      ; optional image of the artist\n  }\n\nrelease_details = \n  {\n    ? release_title : string,\n    ? copyright: string,\n\n    ? visual_artist: string,\n    ? distributor: string,\n    ? release_date: string,\n    ? publication_date: string,\n    ? catalog_number: uint,\n    ? release_version: uint,\n    ? producer: string,\n    ? co_producer: string,\n    ? distributor: string,\n    ? metadata_language: string,\n    ? country_of_origin: string,\n    ? language: string,\n    ? links: { * string => string / [* string] },\n  }\n\nsong_details = \n  {\n    ; For Single, some of these values are defined at the top level. For Multiple, define them for each track.\n    ? artists : [* artist_details],\n    ? track_number: uint,\n    ? song_title: string / [* string],\n    ? song_duration: string .regexp \"^P(?!$)(T(?=\\d)(\\d+H)?(\\d+M)?(\\d+S)?)$\",    ; iso8601 duration\n    ? genres: [1*3 string],\n    ? copyright: string,\n\n    ; For Single, some of these values are defined at the top level. For Multiple, optionally define them for each track\n    ? contributing_artists : [* artist_details],\n    ? series: string,\n    ? collection: string,\n    ? set: string,\n    ? mood: string,\n    ? lyrics: string,\n    ? lyricists: [* string],\n    ? special_thanks: [* string],\n    ? visual_artist: string,\n    ? distributor: string,\n    ? release_date: string,\n    ? publication_date: string,\n    ? catalog_number: uint,\n    ? bitrate: string,\n    ? bpm: string,\n    ? mix_engineer: string,\n    ? mastering_engineer: string,\n    ? producer: string,\n    ? co_producer: string,\n    ? featured_artist: artist_details,\n    ? recording_engineer: string,\n    ? release_version: uint,\n    ? parental_advisory: string,\n    ? explicit: bool,\n    ? isrc: string,\n    ? iswc: string,\n    ? ipi: [* string],\n    ? ipn: [* string],\n    ? isni: [* string],\n    ? metadata_language: string,\n    ? country_of_origin: string,\n    ? language: string,\n    ? derived_from: string,\n    ? links: { * string => string / [* string] },\n  }\n\nfiles_details = \n  {\n    name : string,\n    mediaType : string,\n    src : string / [* string],\n    song : song_details,                                                       ; song music_metadata that applies to the track.\n  }  \n\nmetadata_details = \n  {\n    name : string,\n    image : string / [* string],\n    music_metadata_version: 2,                                                 ; v2 update moves music metadata under its own music_metadata section.\n    release_type: \"Single\" / \"Multiple\",\n    release: release_details,                                                  ; top-level music metadata that applies to the whole album.\n\n    files : [* files_details],                                                 ; was optional in CIP-25, required by CIP-60\n    ? version: 1 / 2,                                                          ; CIP-25 version\n    ? mediaType : string,                                                      ; mediaType for the image. audio goes under files.\n    ? description : string / [* string],\n  }\n\nlabel_metadata = { * policy_id => { * asset_name => metadata_details } }\n\nmetadata = { 721 : uint => label_metadata }"
  },
  {
    "path": "CIP-0060/cddl/version-3.cddl",
    "content": "string = text .size (0..64)\npolicy_id = string / bytes ; hex string for CIP-25 version 1, bytes version 2\nasset_name = string / bytes ; utf-8 for CIP-25 version 1, bytes for version 2\n\nartist_details =\n  {\n    name: string,\n    ? isni : string,\n    ? links: { * string => string },\n  }\n\nauthor_details =\n  {\n    name: string,\n    ? ipi: string,\n    ? share: string,\n  }\n\ncontributing_artist_details =\n  {\n    name: string,\n    ? ipn: string,\n    ? ipi: string,\n    ? role: [* string],\n    ? links: { * string => string }\n  }\n\ncommon_music_details = (\n  ? artists : [+ artist_details],\n  ? genres: [1*3 string],\n  ? copyright: { master: string, composition: string },\n  ? contributing_artists : [* contributing_artist_details]\n)\n\nrelease_details = \n  {\n    release_type: \"Single\" / \"Multiple\" / \"Album/EP\",\n    release_title : string,\n    ? distributor: string,\n    ? visual_artist: string,\n    ? release_date: string,\n    ? publication_date: string,\n    ? catalog_number: string,\n    ? series: string,\n    ? collection: string,\n  } // Extend with common_music_details when release_type is \"Album/EP\"\n  (release_details.release_type == \"Album/EP\" => common_music_details)\n\nsong_details = \n  {\n    song_title: string / [* string],\n    song_duration: string .regexp \"^P(?!$)(T(?=\\d)(\\d+H)?(\\d+M)?(\\d+S)?)$\",\n    track_number: uint,\n    \n    ? featured_artists : [* artist_details],\n    ? authors: [* author_details],\n    ? mood: string,\n    ? set: string,\n    ? lyrics: string,\n    ? special_thanks: [* string],\n    ? bitrate: string,\n    ? bpm: string,\n    ? mix_engineer: string,\n    ? mastering_engineer: string,\n    ? producer: string,\n    ? co_producer: string,\n    ? recording_engineer: string,\n    ? explicit: bool,\n    ? isrc: string,\n    ? iswc: string,\n    ? metadata_language: string,\n    ? country_of_origin: string,\n    ? language: string,\n    ? derived_from: string,\n    ? ai_generated: bool,\n  } // Include common_music_details only when release_type is not \"Album/EP\"\n  (release_details.release_type != \"Album/EP\" => common_music_details)\n\nfiles_details = \n  {\n    name : string,\n    mediaType : string,\n    src : string,\n    song : song_details,\n  }  \n\nmetadata_details = \n  {\n    name : string,\n    image : string,\n    music_metadata_version: 3,\n    release: release_details,\n    files : [+ files_details],\n    \n    ? version: 1 / 2,\n    ? mediaType : string,\n    ? description : string / [* string],\n  }\n\nlabel_metadata = { * policy_id => { * asset_name => metadata_details } }\nmetadata = { 721 : label_metadata }\n"
  },
  {
    "path": "CIP-0067/README.md",
    "content": "---\nCIP: 67\nTitle: Asset Name Label Registry\nStatus: Proposed\nCategory: Tokens\nAuthors: \n  - Alessandro Konrad <alessandro.konrad@live.de>\n  - Thomas Vellekoop <thomas.vellekoop@iohk.io>\nImplementors: N/A\nDiscussions:\n - https://github.com/cardano-foundation/CIPs/pull/298\n - https://github.com/cardano-foundation/CIPs/pull/586\nCreated: 2022-07-13\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis proposal defines a standard to identify Cardano native assets by the asset name to put them in an asset class, as intended by their issuer.\n\n## Motivation: why is this CIP necessary?\n\nAs more assets are minted and different standards emerge to query data for these assets, it's getting harder for 3rd parties to determine the asset class and associated extra assumptions that may arise from this identification. For example, if an asset is identified as a non-fungible token, a third party is interested in its onchain associated metadata. This standard is similar to [CIP-0010](../CIP-0010), but focuses on the asset name of a native asset.\n\n## Specification\n\nTo give issuers the option to classify assets, the `asset_name` MUST be prefixed with 4 bytes encoding the following binary value:\n```\n[ 0000 | 16 bits label_num | 8 bits checksum | 0000 ]\n```\n- The leading and ending four 0s are brackets\n- `label_num` has a fixed size of 2 bytes (`Label range in decimal: [0, 65535]`). \nIf `label_num` < 2 bytes, the remaining bits MUST be left-padded with 0s.\n- `checksum` has a fixed size of 1 byte. The checksum is calculated by applying the [CRC-8](#CRC-8) algorithm on the `label_num (including the padded 0s)`. \n\n### CRC-8\n\n- Polynomial: `0x07`\n- Lookup table:\n```\n[\n  0x00, 0x07, 0x0e, 0x09, 0x1c, 0x1b, 0x12, 0x15, 0x38, 0x3f, 0x36, 0x31, 0x24,\n  0x23, 0x2a, 0x2d, 0x70, 0x77, 0x7e, 0x79, 0x6c, 0x6b, 0x62, 0x65, 0x48, 0x4f,\n  0x46, 0x41, 0x54, 0x53, 0x5a, 0x5d, 0xe0, 0xe7, 0xee, 0xe9, 0xfc, 0xfb, 0xf2,\n  0xf5, 0xd8, 0xdf, 0xd6, 0xd1, 0xc4, 0xc3, 0xca, 0xcd, 0x90, 0x97, 0x9e, 0x99,\n  0x8c, 0x8b, 0x82, 0x85, 0xa8, 0xaf, 0xa6, 0xa1, 0xb4, 0xb3, 0xba, 0xbd, 0xc7,\n  0xc0, 0xc9, 0xce, 0xdb, 0xdc, 0xd5, 0xd2, 0xff, 0xf8, 0xf1, 0xf6, 0xe3, 0xe4,\n  0xed, 0xea, 0xb7, 0xb0, 0xb9, 0xbe, 0xab, 0xac, 0xa5, 0xa2, 0x8f, 0x88, 0x81,\n  0x86, 0x93, 0x94, 0x9d, 0x9a, 0x27, 0x20, 0x29, 0x2e, 0x3b, 0x3c, 0x35, 0x32,\n  0x1f, 0x18, 0x11, 0x16, 0x03, 0x04, 0x0d, 0x0a, 0x57, 0x50, 0x59, 0x5e, 0x4b,\n  0x4c, 0x45, 0x42, 0x6f, 0x68, 0x61, 0x66, 0x73, 0x74, 0x7d, 0x7a, 0x89, 0x8e,\n  0x87, 0x80, 0x95, 0x92, 0x9b, 0x9c, 0xb1, 0xb6, 0xbf, 0xb8, 0xad, 0xaa, 0xa3,\n  0xa4, 0xf9, 0xfe, 0xf7, 0xf0, 0xe5, 0xe2, 0xeb, 0xec, 0xc1, 0xc6, 0xcf, 0xc8,\n  0xdd, 0xda, 0xd3, 0xd4, 0x69, 0x6e, 0x67, 0x60, 0x75, 0x72, 0x7b, 0x7c, 0x51,\n  0x56, 0x5f, 0x58, 0x4d, 0x4a, 0x43, 0x44, 0x19, 0x1e, 0x17, 0x10, 0x05, 0x02,\n  0x0b, 0x0c, 0x21, 0x26, 0x2f, 0x28, 0x3d, 0x3a, 0x33, 0x34, 0x4e, 0x49, 0x40,\n  0x47, 0x52, 0x55, 0x5c, 0x5b, 0x76, 0x71, 0x78, 0x7f, 0x6a, 0x6d, 0x64, 0x63,\n  0x3e, 0x39, 0x30, 0x37, 0x22, 0x25, 0x2c, 0x2b, 0x06, 0x01, 0x08, 0x0f, 0x1a,\n  0x1d, 0x14, 0x13, 0xae, 0xa9, 0xa0, 0xa7, 0xb2, 0xb5, 0xbc, 0xbb, 0x96, 0x91,\n  0x98, 0x9f, 0x8a, 0x8d, 0x84, 0x83, 0xde, 0xd9, 0xd0, 0xd7, 0xc2, 0xc5, 0xcc,\n  0xcb, 0xe6, 0xe1, 0xe8, 0xef, 0xfa, 0xfd, 0xf4, 0xf3,\n]\n```\n \n### Example:\n\n#### Construct a label\nWe want to use the decimal label `222` for an asset name:\n\n1. Convert to hex and pad with missing 0s => `0x00de`\n2. Calculate CRC-8 checksum => `0x14`\n3. Add brackets and combine label => `0x000de140`\n\n#### Verify a label\nWe have the following asset name: `0x000de140`\n\n1. Slice off the first 4 bytes of the asset name => `0x000de140`\n2. Check if first 4 bits and last 4 bits are `0b0000` (`0x0`)\n3. Slice off the 2 `label_num` bytes and apply them to the CRC-8 algorithm. If the result matches with the `checksum` byte, a `valid` label was found and it can be returned. => `0x00de`\n4. Convert to decimal => `222`\n\n### Reserved labels\n\nThese are the reserved `asset_name_label` values\n\n| `asset_name_label` | class | description |\n|--------------------|-------|-------------|\n| 0 - 15             | -     | private use |\n\n### Adding an entry to the registry\n\n> The keywords \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL\n> NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\",  \"MAY\", and\n> \"OPTIONAL\" in this section are to be interpreted as described in\n> [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).\n\nThose wishing to propose an addition to this registry **MUST** draft a new CIP describing the standard for implementing\nthe token. Once the CIP has achieved the `Under Review` status the proposer **SHALL** make the necessary edits to \n[registry.json](./registry.json). These changes **SHOULD** be submitted under a separate pull request against the CIP\nrepository and include a brief description of the standard and a link to the CIP Pull Request describing implementation\ndetails.\n\n### Test Vectors\n\nKeys represent labels in `decimal` numbers. Values represent the entire label, including brackets and checksum in `hex`:\n\n```yaml\n0     : 00000000\n1     : 00001070\n23    : 00017650\n99    : 000632e0\n533   : 00215410\n2000  : 007d0550\n4567  : 011d7690\n11111 : 02b670b0\n49328 : 0c0b0f40\n65535 : 0ffff240\n```\n\n## Rationale: how does this CIP achieve its goals?\n\nAsset name labels make it easy to identify native assets and classify them in their asset class intended by the issuer. Since the identification of these native assets is done by third parties, the design is focused on the usability for them.\n\nFirst, the label should be quickly parsable with a first check. That is, an initial check on an asset name that is easy and will exclude a big subset of the available token names that do not follow standard. This is why the label starts and ends with `0000` in bits. Additionally, in its hex notation, this is differentiable by a human in its readable form, a more common representation.\n\nSecondly, the remaining verification on whether a certain `asset_name_label` standard is followed should be a one shot calculation. Here we mean that the calculation of the check should be straightforward, the label should not be fitted via brute force by a third party. That's why the label contains the bit representation of the integer label it tries to follow.\n\nAnother thing that is important to understand is that an oblivious token issuer might not be aware of this standard. This could lead to the unintentional misinterpretation by third parties and injection attacks. We can minimize this attack vector by making the label format obscure. That is why the label also contains a checksum derived from the `asset_name_label` to add characters that are deterministically derived but look like nonsense. Together with the above zero \"brackets\", and the fixed size binary encoding, it make it unlikely someone follows this standard accidentally. The CRC-8 checksum is chosen for it low-impact on resources and its readily available implementations in multiple languages.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [X] Get support for this CIP by wallets, explorers, minting platforms and other 3rd parties.\n- [X] Get support by tools/libraries like Lucid, PlutusTx, cardano-cli, etc. to generate/verify labels.\n\n### Implementation Plan\n\n- [X] Provide reference implementations:\n  - [X] [Lucid TypeScript implementation of toLabel/fromLabel](https://github.com/spacebudz/lucid/blob/39cd2129101bd11b03b624f80bb5fe3da2537fec/src/utils/utils.ts#L500-L522)\n  - [X] [Lucid TypeScript implementation of CRC-8](https://github.com/spacebudz/lucid/blob/main/src/misc/crc8.ts)\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0067/registry.json",
    "content": "[\n  {\n    \"asset_name_label\": 100,\n    \"class\": \"NFT\",\n    \"description\": \"CIP-0068 - Datum Metadata Standard (Reference NFT)\",\n    \"documentation\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0068\"\n  },\n  {\n    \"asset_name_label\": 222,\n    \"class\": \"NFT\",\n    \"description\": \"CIP-0068 - Datum Metadata Standard (222 sub standard)\",\n    \"documentation\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0068\"\n  },\n  {\n    \"asset_name_label\": 333,\n    \"class\": \"FT\",\n    \"description\": \"CIP-0068 - Datum Metadata Standard (333 sub standard)\",\n    \"documentation\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0068\"\n  },\n  {\n    \"asset_name_label\": 444,\n    \"class\": \"RFT\",\n    \"description\": \"CIP-0068 - Datum Metadata Standard (444 sub standard)\",\n    \"documentation\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0068\"\n  },\n  {\n    \"asset_name_label\": 500,\n    \"class\": \"NFT\",\n    \"description\": \"CIP-0102 - Datum Metadata Standard (500 sub standard)\",\n    \"documentation\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0102\"\n  }\n]"
  },
  {
    "path": "CIP-0067/registry.schema.json",
    "content": "{\n  \"$schema\": \"http://json-schema.org/draft-07/schema\",\n  \"$id\": \"https://cips.cardano.org/cips/cip67/registry.schema.json\",\n  \"type\": \"array\",\n  \"title\": \"Asset Name Label Registry\",\n  \"description\": \"JSON schema for asset name label registry\",\n  \"default\": [],\n  \"examples\": [\n    [\n      {\n        \"asset_name_label\": 222,\n        \"class\": \"NFT\",\n        \"description\": \"CIP-0068 - NFT Metadata Standard (222 sub standard)\",\n        \"documentation\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0068\"\n      }\n    ]\n  ],\n  \"additionalItems\": false,\n  \"items\": {\n    \"$id\": \"#/items\",\n    \"anyOf\": [\n      {\n        \"$id\": \"#/items/anyOf/0\",\n        \"type\": \"object\",\n        \"title\": \"The first anyOf schema\",\n        \"description\": \"An entry in the asset name label registry\",\n        \"default\": {},\n        \"examples\": [\n          {\n            \"asset_name_label\": 222,\n            \"class\": \"NFT\",\n            \"description\": \"CIP-0068 - NFT Metadata Standard (222 sub standard)\"\n          }\n        ],\n        \"required\": [\"asset_name_label\", \"class\", \"description\"],\n        \"properties\": {\n          \"asset_name_label\": {\n            \"$id\": \"#/items/anyOf/0/properties/asset_name_label\",\n            \"type\": \"integer\",\n            \"title\": \"The asset_name_label number\",\n            \"default\": 0,\n            \"examples\": [222]\n          },\n          \"class\": {\n            \"$id\": \"#/items/anyOf/0/properties/class\",\n            \"type\": \"string\",\n            \"title\": \"The asset class\",\n            \"default\": \"\",\n            \"examples\": [\"NFT\", \"FT\", \"SFT\"]\n          },\n          \"description\": {\n            \"$id\": \"#/items/anyOf/0/properties/description\",\n            \"type\": \"string\",\n            \"title\": \"The asset name label description\",\n            \"default\": \"\",\n            \"examples\": [\"CIP-0068 - NFT Metadata Standard (222 sub standard)\"]\n          },\n          \"documentation\": {\n            \"$id\": \"#/items/anyOf/0/properties/documentation\",\n            \"type\": \"string\",\n            \"format\": \"url\",\n            \"title\": \"Documentation Link\",\n            \"default\": \"\",\n            \"examples\": [\"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0068\"]\n          }\n        },\n        \"additionalProperties\": false\n      }\n    ]\n  }\n}\n"
  },
  {
    "path": "CIP-0068/README.md",
    "content": "---\nCIP: 68\nTitle: Datum Metadata Standard\nStatus: Active\nCategory: Tokens\nAuthors:\n  - Alessandro Konrad <alessandro.konrad@live.de>\n  - Thomas Vellekoop <thomas.vellekoop@iohk.io>\nImplementors:\n  - Alessandro Konrad (SpaceBudz)\n  - 5Binaries (Blockfrost)\n  - Smaug (Pool.pm)\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/299\n  - https://github.com/cardano-foundation/CIPs/pull/359\n  - https://github.com/cardano-foundation/CIPs/pull/458\n  - https://github.com/cardano-foundation/CIPs/pull/471\n  - https://github.com/cardano-foundation/CIPs/pull/494\n  - https://github.com/cardano-foundation/CIPs/issues/520\n  - https://github.com/cardano-foundation/CIPs/pull/586\nCreated: 2022-07-13\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis proposal defines a metadata standard for native assets making use of output datums not only for NFTs but any asset\nclass.\n\n## Motivation: why is this CIP necessary?\n\nThis proposal addresses a few shortcomings\nof [CIP-0025](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0025):\n\n- Lack of programmability;\n- Difficult metadata update / evolution;\n- Non-inspectable metadata from within Plutus validators\n\nBesides these shortcomings CIP-0025 has\nsome [flaws](https://github.com/cardano-foundation/CIPs/pull/85#issuecomment-1054123645) in its design.\nFor people unaware of CIP-0025 or want to use a different way of minting or want to use a different metadata\nformat/mechanism you open up a protocol to metadata spoofing, because this standard is so established and metadata in\nminting transactions are interpreted by most platforms by default. Since this standard is not enforced at the protocol\nlevel there is no guarantee everyone will be aware of it or follow the rules. At the same time you limit and constraint\nthe capabilities of the ledger if everyone was forced to follow the rules of CIP-0025.\n\nThis standard tackles all these problems and offers many more advantages, not only for NFTs, but also for any asset\nclass that may follow. Additionally, this CIP will introduce a way to classify tokens so that third parties like wallets\ncan easily know what the kind of token it is.\n\n## Specification\n\n### Considerations\n\nThe basic idea is to have two assets issued, where one references the other. We call these two a `reference NFT` and\nan `user token`, where the `user token` can be an NFT, FT or any other asset class that is transferable and represents\nany value. So, the `user token` is the actual asset that lives in a user's wallet.\n\nTo find the metadata for the `user token` you need to look for the output, where the `reference NFT` is locked in. How\nthis is done concretely will become clear below. Moreover, this output contains a datum, which holds the metadata. The\nadvantage of this approach is that the issuer of the assets can decide how the transaction output with\nthe `reference NFT` is locked and further handled. If the issuer wants complete immutable metadata, the `reference NFT`\ncan be locked at the address of an unspendable script. Similarly, if the issuer wants the NFTs/FTs to evolve or wants a\nmechanism to update the metadata, the `reference NFT` can be locked at the address of a script with arbitrary logic that\nthe issuer decides.\n\nLastly and most importantly, with this construction, the metadata can be used by a Plutus V2 script with the use of\nreference inputs [CIP-0031](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0031). This will drive further\ninnovation in the token space.\n\n### Labels\n\nEach asset name must be prefixed by a label. The intent of this label is to identify the purpose of the token. For\nexample, a reference NFT is identified by the label 100 and so every token considered a reference NFT should start its\nasset name with the hex `000643b0`. This is\nfollowing [CIP-0067](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0067), which specifies how the label\nprefix should be formatted.\n\nExamples of asset names:\n\n| asset_name_label | asset_name_content | resulting_label_hex | resulting_content_hex | resulting_asset_name_hex     |\n|------------------|--------------------|---------------------|-----------------------|------------------------------|\n| 100              | GenToken           | 000643b0            | 47656e546f6b656e      | 000643b047656e546f6b656e     |\n| 100              | NeverGonna         | 000643b0            | 4e65766572476f6e6e61  | 000643b04e65766572476f6e6e61 |\n| 222              | GiveYouUp          | 000de140            | 47697665596f755570    | 000de14047697665596f755570   |\n\nFor simplicity purposes, the document will use the label `(100)` or `(<label>)` in the following documentation, but\nunderstand it should follow the CIP-0067 specification.\n\n### Reference NFT label\n\nThis is the registered `asset_name_label` value\n\n| asset_name_label | class | description                                           |\n|------------------|-------|-------------------------------------------------------|\n| 100              | NFT   | Reference NFT locked at a script containing the datum |\n\n### Constraints and conditions\n\nFor a correct relationship between the `user token` and the `reference NFT` a few conditions MUST be met.\n\n- The `user token` and `reference NFT` MUST be under the same policy ID.\n- For a specific `user token` there MUST exist exactly **one** `reference NFT`\n- The `user token` and associated `reference NFT` MUST follow the standard naming pattern. The asset name of both assets\n  is prefixed with its respective `asset_name_label` followed by a pattern defined by the asset class (e.g.\n  asset_name_label 222)\n\nSome remarks about the above,\n\n1. The `user token` and `reference NFT` do not need to be minted in the same transaction. The order of minting is also\n   not important.\n2. It may be the case that there can be multiple `user tokens` (multiple asset names or quantity greater than 1)\n   referencing the same `reference NFT`.\n\nThe datum in the output with the `reference NFT` contains the metadata at the first field of the constructor 0. The\nversion number is at the second field of this constructor. The third field allows for arbitrary plutus data. This could\nbe useful to forward relevant data to the plutus script:\n\n```\nbig_int = int / big_uint / big_nint\nbig_uint = #6.2(bounded_bytes)\nbig_nint = #6.3(bounded_bytes)\n\nmetadata =\n  { * metadata => metadata }\n  / [ * metadata ]\n  / big_int\n  / bounded_bytes\n\nversion = int\n\n; Custom user defined plutus data.\n; Setting data is optional, but the field is required\n; and needs to be at least Unit/Void: #6.121([])\nextra = plutus_data\n\ndatum = #6.121([metadata, version, extra])\n```\n\n#### 222 NFT Standard\n\n> **Note** Since `version >= 1`\n\nBesides the necessary standard for the `reference NFT` we're introducing three specific token standards in this CIP.\nNote that the possibilities are endless here and more standards can be built on top of this CIP for FTs, other NFTs,\nrich fungible tokens, etc. The first is the `222` NFT standard with the registered `asset_name_label` prefix value\n\n| asset_name_label | class | description                                                          |\n|------------------|-------|----------------------------------------------------------------------|\n| 222              | NFT   | NFT held by the user's wallet making use of CIP-0025 inner structure |\n\n##### Class\n\nThe `user token` represents an NFT (non-fungible token).\n\n##### Pattern\n\nThe `user token` and `reference NFT` MUST have an identical name, preceded by the `asset_name_label` prefix.\n\nExample:\\\n`user token`: `(222)Test123`\\\n`reference NFT`: `(100)Test123`\n\n##### Metadata\n\nThis is a low-level representation of the metadata, following closely the structure of CIP-0025. All UTF-8 encoded keys\nand values need to be converted into their respective byte's representation when creating the datum on-chain.\n\n```\nfiles_details =\n  {\n    ? name : bounded_bytes, ; UTF-8\n    mediaType : bounded_bytes, ; UTF-8\n    src : uri,\n    ; ... Additional properties are allowed\n  }\n\nmetadata =\n  {\n    name : bounded_bytes, ; UTF-8\n\n    ; The image URI must point to a resource with media type (mime type) `image/*`\n    ; (for example `image/png`, `image/jpeg`, `image/svg+xml`, etc.)\n    image : uri,\n\n    ? description : bounded_bytes, ; UTF-8\n    ? files : [* files_details]\n    ; ... Additional properties are allowed\n  }\n\n; A valid Uniform Resource Identifier (URI) as a UTF-8 encoded bytestring.\n; The URI scheme must be one of `https` (HTTP), `ipfs` (IPFS), `ar` (Arweave) or `data` (on-chain).\n; Data URLs (on-chain data) must comply to RFC2397.\nuri = bounded_bytes / [ * bounded_bytes ] ; UTF-8\n  \n; Custom user defined plutus data.\n; Setting data is optional, but the field is required\n; and needs to be at least Unit/Void: #6.121([])\nextra = plutus_data\n\ndatum = #6.121([metadata, version, extra])\n\nversion = 1 / 2 / 3\n```\n\nExample datum as JSON:\n\n```json\n{\n  \"constructor\": 0,\n  \"fields\": [\n    {\n      \"map\": [\n        {\n          \"k\": {\n            \"bytes\": \"6E616D65\"\n          },\n          \"v\": {\n            \"bytes\": \"5370616365427564\"\n          }\n        },\n        {\n          \"k\": {\n            \"bytes\": \"696D616765\"\n          },\n          \"v\": {\n            \"bytes\": \"697066733A2F2F74657374\"\n          }\n        }\n      ]\n    },\n    {\n      \"int\": 1\n    }\n  ]\n}\n```\n\n##### Retrieve metadata as 3rd party\n\nA third party has the following NFT `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(222)TestToken` they want\nto lookup. The steps are\n\n1. Construct `reference NFT` from `user token`: `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(100)TestToken`\n2. Look up `reference NFT` and find the output it's locked in.\n3. Get the datum from the output and lookup metadata by going into the first field of constructor 0.\n4. Convert to JSON and encode all string entries to UTF-8 if possible, otherwise leave them in hex.\n\n##### Retrieve metadata from a Plutus validator\n\nWe want to bring the metadata of the NFT `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(222)TestToken` in\nthe Plutus validator context. To do this we\n\n1. Construct `reference NFT`\n   from `user token`: `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(100)TestToken` (off-chain)\n2. Look up `reference NFT` and find the output it's locked in. (off-chain)\n3. Reference the output in the transaction. (off-chain)\n4. Verify validity of datum of the referenced output by checking if policy ID of `reference NFT` and `user token` and\n   their asset names without the `asset_name_label` prefix match. (on-chain)\n\n#### 333 FT Standard\n\n> **Note** Since `version >= 1`\n\nThe second introduced standard is the `333` FT standard with the registered `asset_name_label` prefix value\n\n| asset_name_label | class | description                                                                                      |\n|------------------|-------|--------------------------------------------------------------------------------------------------|\n| 333              | FT    | FT hold by the user's wallet making use of Cardano foundation off-chain registry inner structure |\n\n##### Class\n\nThe `user token` is an FT (fungible token).\n\n##### Pattern\n\nThe `user token` and `reference NFT` MUST have an identical name, preceded by the `asset_name_label` prefix.\n\nExample:\\\n`user token`: `(333)Test123`\\\n`reference NFT`: `(100)Test123`\n\n##### Metadata\n\nThis is a low-level representation of the metadata, following closely the structure of the Cardano foundation off-chain\nmetadata registry. All UTF-8 encoded keys and values need to be converted into their respective byte's representation\nwhen creating the datum on-chain.\n\n```\n; Explanation here: https://developers.cardano.org/docs/native-tokens/token-registry/cardano-token-registry/\n\nmetadata =\n  {\n    name : bounded_bytes, ; UTF-8\n    description : bounded_bytes, ; UTF-8\n    ? ticker: bounded_bytes, ; UTF-8\n    ? url: bounded_bytes, ; UTF-8\n    ? decimals: int\n\n    ; 'logo' does not follow the explanation of the token-registry, it needs to be a valid URI and not a plain bytestring.\n    ; The logo URI must point to a resource with media type (mime type) `image/png`, `image/jpeg` or `image/svg+xml`.\n    ? logo: uri,\n\n    ; ... Additional properties are allowed\n  }\n\n; A valid Uniform Resource Identifier (URI) as a UTF-8 encoded bytestring.\n; The URI scheme must be one of `https` (HTTP), `ipfs` (IPFS), `ar` (Arweave) or `data` (on-chain).\n; Data URLs (on-chain data) must comply to RFC2397.\nuri = bounded_bytes / [ * bounded_bytes ] ; UTF-8\n\n; Custom user defined plutus data.\n; Setting data is optional, but the field is required\n; and needs to be at least Unit/Void: #6.121([])\nextra = plutus_data\n\ndatum = #6.121([metadata, version, extra])\n\nversion = 1 / 2 / 3\n```\n\nExample datum as JSON:\n\n```json\n{\n  \"constructor\": 0,\n  \"fields\": [\n    {\n      \"map\": [\n        {\n          \"k\": {\n            \"bytes\": \"6E616D65\"\n          },\n          \"v\": {\n            \"bytes\": \"5370616365427564\"\n          }\n        },\n        {\n          \"k\": {\n            \"bytes\": \"6465736372697074696F6E\"\n          },\n          \"v\": {\n            \"bytes\": \"54686973206973206D79207465737420746F6B656E\"\n          }\n        }\n      ]\n    },\n    {\n      \"int\": 1\n    }\n  ]\n}\n```\n\n##### Retrieve metadata as 3rd party\n\nA third party has the following FT `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(333)TestToken` they want\nto lookup. The steps are\n\n1. Construct `reference NFT` from `user token`: `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(100)TestToken`\n2. Look up `reference NFT` and find the output it's locked in.\n3. Get the datum from the output and lookup metadata by going into the first field of constructor 0.\n4. Convert to JSON and encode all string entries to UTF-8 if possible, otherwise leave them in hex.\n\n##### Retrieve metadata from a Plutus validator\n\nWe want to bring the metadata of the FT `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(333)TestToken` in the\nPlutus validator context. To do this we\n\n1. Construct `reference NFT`\n   from `user token`: `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(100)TestToken` (off-chain)\n2. Look up `reference NFT` and find the output it's locked in. (off-chain)\n3. Reference the output in the transaction. (off-chain)\n4. Verify validity of datum of the referenced output by checking if policy ID of `reference NFT` and `user token` and\n   their asset names without the `asset_name_label` prefix match. (on-chain)\n\n#### 444 RFT Standard\n\n> **Warning** Since `version >= 2`\n\nThe third introduced standard is the `444` Rich-FT standard with the registered `asset_name_label` prefix value\n\n| asset_name_label | class | description                                                                                                                                     |\n|------------------|-------|-------------------------------------------------------------------------------------------------------------------------------------------------|\n| 444              | RFT   | RFT hold by the user's wallet making use of the union of CIP-0025 inner structure AND the Cardano foundation off-chain registry inner structure |\n\nRich-Fungible tokens don't fit cleanly into the other two FT/NFT classes of tokens and thus need their own standard. An\nexample of an RFT would be a fractionalized NFT. The single reference NFT `(100)` represents the NFT itself, and the\nmany `(444)` tokens represent the fractionalized shares. Minting 100 tokens and setting decimals to 2 would represent a\nsingle NFT that is split into 100 fractions.\n\n##### Class\n\nThe `user token` is an RFT (rich-fungible token).\n\n##### Pattern\n\nThe `user token` and `reference NFT` MUST have an identical name, preceded by the `asset_name_label` prefix.\n\nExample:\\\n`user token`: `(444)Test123`\\\n`reference NFT`: `(100)Test123`\n\n##### Metadata\n\nThis is a low-level representation of the metadata, following closely the structure of CIP-0025 with the optional\ndecimals field added. All UTF-8 encoded keys and values need to be converted into their respective byte's representation\nwhen creating the datum on-chain.\n\n```\nfiles_details =\n  {\n    ? name : bounded_bytes, ; UTF-8\n    mediaType : bounded_bytes, ; UTF-8\n    src : uri,\n    ; ... Additional properties are allowed\n  }\n\nmetadata =\n  {\n    name : bounded_bytes, ; UTF-8\n\n    ; The image URI must point to a resource with media type (mime type) `image/*`\n    ; (for example `image/png`, `image/jpeg`, `image/svg+xml`, etc.)\n    image : uri,\n\n    ? description : bounded_bytes, ; UTF-8\n    ? decimals: int,\n    ? files : [* files_details]\n    ; ... Additional properties are allowed\n  }\n\n; A valid Uniform Resource Identifier (URI) as a UTF-8 encoded bytestring.\n; The URI scheme must be one of `https` (HTTP), `ipfs` (IPFS), `ar` (Arweave) or `data` (on-chain).\n; Data URLs (on-chain data) must comply to RFC2397.\nuri = bounded_bytes ; UTF-8\n\n; Custom user defined plutus data.\n; Setting data is optional, but the field is required\n; and needs to be at least Unit/Void: #6.121([])\nextra = plutus_data\n\ndatum = #6.121([metadata, version, extra])\n\nversion = 3\n```\n\nExample datum as JSON:\n\n```json\n{\n  \"constructor\": 0,\n  \"fields\": [\n    {\n      \"map\": [\n        {\n          \"k\": {\n            \"bytes\": \"6E616D65\"\n          },\n          \"v\": {\n            \"bytes\": \"5370616365427564\"\n          }\n        },\n        {\n          \"k\": {\n            \"bytes\": \"6465736372697074696F6E\"\n          },\n          \"v\": {\n            \"bytes\": \"54686973206973206D79207465737420746F6B656E\"\n          }\n        },\n        {\n          \"k\": {\n            \"bytes\": \"696D616765\"\n          },\n          \"v\": {\n            \"bytes\": \"697066733A2F2F74657374\"\n          }\n        },\n        {\n          \"k\": {\n            \"bytes\": \"646563696D616C73\"\n          },\n          \"v\": {\n            \"int\": 2\n          }\n        }\n      ]\n    },\n    {\n      \"int\": 1\n    }\n  ]\n}\n```\n\n##### Retrieve metadata as 3rd party\n\nA third party has the following RFT `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(444)TestToken` they want\nto lookup. The steps are\n\n1. Construct `reference NFT` from `user token`: `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(100)TestToken`\n2. Look up `reference NFT` and find the output it's locked in.\n3. Get the datum from the output and lookup metadata by going into the first field of constructor 0.\n4. Convert to JSON and encode all string entries to UTF-8 if possible, otherwise leave them in hex.\n\n##### Retrieve metadata from a Plutus validator\n\nWe want to bring the metadata of the RFT `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(444)TestToken` in\nthe Plutus validator context. To do this we\n\n1. Construct `reference NFT`\n   from `user token`: `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(100)TestToken` (off-chain)\n2. Look up `reference NFT` and find the output it's locked in. (off-chain)\n3. Reference the output in the transaction. (off-chain)\n4. Verify validity of datum of the referenced output by checking if policy ID of `reference NFT` and `user token` and\n   their asset names without the `asset_name_label` prefix match. (on-chain)\n\n### Extending & Modifying this CIP\n\n> The keywords \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL\n> NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\",  \"MAY\", and\n> \"OPTIONAL\" in this section are to be interpreted as described in\n> [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).\n\nAll CIPs proposing to modify or extend this standard **MUST** include the language or a reference link to the extension\nand modification language found in the \n[Extension Boilerplate](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0068/extension_boilerplate.md).\n\nIn order to prevent conflicting updates in the future; the addition of new asset classes following, or as part of, this\nstandard **MUST** be submitted as a new CIP providing their own justification, implementation, rationale, and community\nreview prior to official acceptance. Newly proposed `asset_name_labels` **SHOULD NOT** be added to\n[CIP-0067](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0067) until the accompanying CIP has matured\nthrough the community review and feedback stage to a point that it is considered in the `Under Review` status and is\nassigned a tentative CIP number by the CIP Editors panel.\n\nA brief reference to new asset classes **MAY** be added to this document after the accompanying CIP achieves\nthe `accepted` status. Documentation describing these token asset classes **MUST** be fully encapsulated within their\nindividual CIPs and a link **MUST** be provided to that CIP within this document.\n\nIf a modification or change is deemed necessary to one of the asset classes contained within this document: namely Asset\nName Labels: 100, 222, 333, or 444; which do not fundamentally change the nature, use, or reference of the tokens; it\n**MAY** be made as a modification of this document. However, any change proposed that presents a non-backwards\ncompatible change **MUST** include an accompanying `version` field iteration and both specifications for the proposed,\ncurrent, and historical versions of the format **MUST** be maintained to assist future implementors who may encounter a\nversion of these tokens from any point in time with the following format:\n\n```\n#### Versions\n\n1. [6d897eb](https://github.com/cardano-foundation/CIPs/tree/6d897eb60805a58a3e54821fe61284d5c5903764/CIP-XXXX)\n2. [45fa23b](https://github.com/cardano-foundation/CIPs/tree/45fa23b60806367a3e52231e552c4d7654237678/CIP-XXXX)\n3. [bfc6fde](https://github.com/cardano-foundation/CIPs/tree/bfc6fde340280d8b51f5a7131b57f4cc6cc5f260/CIP-XXXX)\n4. **Current**\n```\n\nEach time a new version is introduced the previous version's link MUST be updated to match the last commit corresponding\nto the previous version.\n\nIf a change is proposed that would fundamentally alter the nature of one or more of the `asset_name_labels` and their\nassociated tokens contained within this document, namely Asset Name Labels: 100, 222, 333, or 444; these changes\n**MUST** be submitted via a new, separate CIP with its own justification, implementation, rationale, and community\nreview prior to official acceptance. These separate CIPs **MUST** include a plan for the obsolescence of any previous\nversions of the affected tokens. `asset_name_labels` **MUST** only be marked obsolete once a modifying CIP achieves the\n`accepted` status.\n\n### Changelog\n\n#### version 1\n\n- NFT (222) & FT (333) asset classes\n\n#### version 2\n\n- Added new RFT asset class (444)\n\n#### version 3\n\n- Added [* bounded_bytes] support to the image and src tags on the metadata \n\n## Rationale: how does this CIP achieve its goals?\n\nWithout separation of `reference NFT` and `user token` you lose all flexibility and moving the `user token` would be\nquite cumbersome as you would need to add the metadata everytime to the new output where the `user token` is sent to.\nHence, you separate metadata and `user token` and lock the metadata inside another UTxO, so you can freely move\nthe `user token` around.\n\nIn order to reference the correct UTxO containing the metadata, it needs to be authenticated, otherwise metadata\nspoofing attacks become possible. One way to achieve that is by adding an NFT (`reference NFT`) to the UTxO. This NFT\nneeds to under the same Policy ID as the `user token`, followed by an asset name pattern defined in the standard. This\nway you create a secure link between `reference NFT` and `user token` without the need for any extra data, and you can\nmake use of this off-chain and on-chain.\n\nThe security for the link is derived from the minting policy itself, so it's important to write the validator with the\nright constraints and rules since this CIP solely defines the interface to keep flexibility as high as possible.\n\n### Backward Compatibility\n\nTo keep metadata compatibility with changes coming in the future, we introduce a `version` field in the datum.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [X] Open-source more practical implementations/projects which make use of this CIP.\n- [X] Introduce a `version` integer datum field to increment for new asset classes or\nchanges to the on-chain format.\n\n### Implementation Plan\n\n- [X] Agree on a binary encoding for asset name labels\n  in [CIP-0067](https://github.com/cardano-foundation/CIPs/pull/298).\n- [X] Get support for this CIP by wallets, explorers, tools, minting platforms and other 3rd parties.\n- [X] Minimal reference implementation making use of [Lucid](https://github.com/spacebudz/lucid) (\n  off-chain), [PlutusTx](https://github.com/input-output-hk/plutus) (on-chain): [Implementation](./ref_impl)\n\n## References\n\n- [CIP 25 - Media NFT Metadata Standard](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0025)\n- [CIP 31 - Reference inputs](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0031)\n- [CIP 67 - Asset Name Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0067)\n- [RFC 3986 - Uniform Resource Identifier (URI)](https://www.rfc-editor.org/rfc/rfc3986)\n- [RFC 2397 - The \"data\" URL scheme](https://datatracker.ietf.org/doc/html/rfc2397)\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0068/extension_boilerplate.md",
    "content": "### Extending & Modifying this CIP\n\n> The keywords \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL\n> NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\",  \"MAY\", and\n> \"OPTIONAL\" in this section are to be interpreted as described in\n> [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).\n\nIn order to prevent conflicting updates in the future; the addition of new asset classes following, or as part of, this\nstandard **MUST** be submitted as a new CIP providing their own justification, implementation, rationale, and community\nreview prior to official acceptance.\n\nNewly proposed `asset_name_labels` **SHOULD NOT** be added to\n[CIP-0067](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0067) until the accompanying CIP has matured\nthrough the community review and feedback stage to a point that it is considered in the `Under Review` status and is\nassigned a tentative CIP number by the CIP Editors panel.\n\nIf a modification or change is deemed necessary to the asset class contained within this document which do not\nfundamentally change the nature, use, or reference of the tokens; it **MAY** be submitted as a modification of this\ndocument.\n\nHowever, any change proposed that presents a non-backwards compatible change **MUST** include an accompanying `version`\nfield iteration and both specifications for the proposed, current, and historical versions of the format **MUST** be\nmaintained to assist future implementors who may encounter a version of these tokens from any point in time with the\nfollowing format:\n\n```\n#### Versions\n\n1. [6d897eb](https://github.com/cardano-foundation/CIPs/tree/6d897eb60805a58a3e54821fe61284d5c5903764/CIP-XXXX)\n2. [45fa23b](https://github.com/cardano-foundation/CIPs/tree/45fa23b60806367a3e52231e552c4d7654237678/CIP-XXXX)\n3. **Current**\n```\n\nEach time a new version is introduced the previous version's link MUST be updated to match the last commit corresponding\nto the previous version.\n\nIf a change is proposed that would fundamentally alter the nature of one or more of the existing\n[CIP-0067](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0067) `asset_name_labels` and their\nassociated tokens; these changes **MUST** be submitted via a new, separate CIP with its own justification, \nimplementation, rationale, and community review prior to official acceptance. These separate CIPs **MUST** include a\nplan for the obsolescence of any previous versions of the affected tokens. `asset_name_labels` **MUST** only be marked\nobsolete once a modifying CIP achieves the `accepted` status.\n"
  },
  {
    "path": "CIP-0068/ref_impl/README.md",
    "content": "# Minimal implementation of CIP-0068\n\n## Concept\n\nThe minting policy is a one-shot policy. Only single NFT (pair of `reference NFT` and `user token`) can be minted. When deciding to burn the NFT the whole pair must be burned, otherwise the validator will throw an error.\nPlutusTx was used to create the [on-chain code](onchain.hs) and [Lucid](https://github.com/spacebudz/lucid) for the [off-chain part](offchain.ts). It can be run in [Deno](https://deno.land/) and with a few modifications also in [Node.js](https://nodejs.org/) and Browser.\n\n## Api\n\n- mintNFT(assetName : string, metadata: Metadata)\n- burnNFT(assetName : string)\n- viewNFT(assetName : string)\n\n## Run\n\n```\ndeno run -A offchain.ts\n```\n"
  },
  {
    "path": "CIP-0068/ref_impl/offchain.ts",
    "content": "// Lucid off-chain code: Mint an 222 NFT according to CIP-0068 standard\nimport {\n  Blockfrost,\n  Constr,\n  Data,\n  Lucid,\n  MintingPolicy,\n  PlutusData,\n  SpendingValidator,\n  TxHash,\n  utf8ToHex,\n} from \"https://deno.land/x/lucid@0.6.5/mod.ts\";\n\nconst lucid = await Lucid.new(\n  new Blockfrost(\n    \"https://cardano-preview.blockfrost.io/api/v0\",\n    \"<project_id>\",\n  ),\n  \"Preview\",\n);\n\nlucid.selectWalletFromSeed(\n  \"<seed_phrase>\",\n);\n\ntype FilesDetails = {\n  name?: string;\n  mediaType: string;\n  src: string;\n};\n\ntype Metadata = {\n  name: string;\n  image: string;\n  mediaType?: string;\n  description?: string;\n  files?: FilesDetails[];\n  [key: string]: unknown;\n};\n\n// onchain.hs: mintingPolicy\nconst mintingPolicy: MintingPolicy = {\n  type: \"PlutusV2\",\n  script:\n    \"590e19590e160100003332323233223322323232323232323232323232323232323232323232323233223232323232323232323232323232332232323222232232325335332232323232323232533500913323355001350375035235001222333573466e2000520000430423018120013031301b5007133035323232350032222222222223335530271200135025502825335333573466e3c03cd400488d4008880081381344ccd5cd19b8700e3500122350022200104e04d104d00c35011220013501022002500733035323233355301a120013503850362350012233355301d120013503b50392350012233350012330264800000488cc09c0080048cc0980052000001330130020013232323350433355045003335043335504500200150445044500850065004323233553019120012350012233550460023355301c1200123500122335504900233350012330434800000488cc1100080048cc10c0052000001330130020013233553019120012350012233550460023355301c1200123500122335504900233704900080080080099a82019aa82102199a82019aa821021981e000a820a8209aa99a99199aa980a0900091299a9a8011111299a9a80b911a803111919a802919a8021299a999ab9a3371e0040020980962a00620964096466a00840964a66a666ae68cdc78010008260258a80188258a99a80190a99a8011099a801119a801119a801119a8011198158010009027119a801102711981580100091102711119a8021027111299a999ab9a3370e00c0060a20a02a66a666ae68cdc38028010288280998180020008828082808248a99a80090824882489a81619aa8240010018a8159099a8218008010800a8209a80091111111111100528038b1109a80111299a8018891800801110b10009981a9980e9aa803111111002240046606a6603aa00a90011981a9980d1aa80311111100328009981a9980d2801a8009981a9980d1980e01ca80124505283232322900330353301a3301c03950044881052831303029003301a33038039500233038039500413500722333350012326320313357389201024c680003120012326320313357389201024c68000312326320313357389201024c6800031135500422222200513550032222220031355002222222002135500122222200115335302b3015500116221350022225335004162213500222253350041123333330010090080070040030022216135001220023333573466e1d40112002212200223333573466e1d40152000212200123263202833573805205004c04a6666ae68cdc39aab9d5002480008cc8848cc00400c008c8c8c8c8c8c8c8c8c8c8c8c8c8cccd5cd19b8735573aa018900011999999999999111111111110919999999999980080680600580500480400380300280200180119a8120129aba1500c33502402535742a01666a04804c6ae854028ccd540a1d728139aba150093335502875ca04e6ae854020cd40900bcd5d0a803999aa8140183ad35742a00c6464646666ae68cdc39aab9d5002480008cc8848cc00400c008c8c8c8cccd5cd19b8735573aa004900011991091980080180119a81d3ad35742a00460766ae84d5d1280111931901e99ab9c03e03d03b135573ca00226ea8004d5d0a8011919191999ab9a3370e6aae754009200023322123300100300233503a75a6ae854008c0ecd5d09aba2500223263203d33573807c07a07626aae7940044dd50009aba135744a004464c6407266ae700e80e40dc4d55cf280089baa00135742a00a66a048eb8d5d0a802199aa81401610009aba150033335502875c40026ae854008c0b8d5d09aba2500223263203533573806c06a06626ae8940044d5d1280089aba25001135744a00226ae8940044d5d1280089aba25001135744a00226ae8940044d5d1280089aab9e5001137540026ae854008c078d5d09aba2500223263202733573805004e04a204c264c6404c66ae7124010350543500026135573ca00226ea80044d55ce9baa001223355300812001235001223355035002333500123355300c1200123500122335503900235500d0010012233355500801000200123355300c1200123500122335503900235500c00100133355500300b002001111222333553004120015030335530081200123500122335503500235500900133355300412001223500222533533355300d120013500b500e235001223300a002005006100313350340040035031001335530081200123500122323355036003300100532001355037225335001135500a003221350022253353300c002008112223300200a004130060030023200135503022112225335001100222133005002333553007120010050040011121222300300411212223001004123350222233350032200200200135001220013200135502c22112253350011502d22133502e300400233553006120010040013200135502b2211222533500113500322001221333500522002300400233355300712001005004001112330012253350021028100102522333573466e3c0080040980948d400488888888888802088ccdc62400000400244666ae68cdc38010008118110919118011bac001320013550262233335573e0024a04c466a04a60086ae84008c00cd5d100100a119191999ab9a3370e6aae7540092000233221233001003002300c35742a004600a6ae84d5d1280111931900a19ab9c015014012135573ca00226ea80048c8c8c8c8cccd5cd19b8735573aa00890001199991110919998008028020018011919191999ab9a3370e6aae7540092000233221233001003002301535742a00466a01a0286ae84d5d1280111931900c99ab9c01a019017135573ca00226ea8004d5d0a802199aa8043ae500735742a0066464646666ae68cdc3a800a4008464244460040086ae84d55cf280191999ab9a3370ea0049001119091118008021bae357426aae7940108cccd5cd19b875003480008488800c8c98c806ccd5ce00e00d80c80c00b89aab9d5001137540026ae854008cd4025d71aba135744a004464c6402a66ae7005805404c4d5d1280089aba25001135573ca00226ea80044cd54005d73ad112232230023756002640026aa04644646666aae7c008940908cd408ccd54094c018d55cea80118029aab9e500230043574400602426ae84004488c8c8cccd5cd19b875001480008d401cc014d5d09aab9e500323333573466e1d400920022500723263201233573802602402001e26aae7540044dd50008909118010018891000919191999ab9a3370ea002900311909111180200298039aba135573ca00646666ae68cdc3a8012400846424444600400a60126ae84d55cf280211999ab9a3370ea006900111909111180080298039aba135573ca00a46666ae68cdc3a8022400046424444600600a6eb8d5d09aab9e500623263201033573802202001c01a01801626aae7540044dd5000919191999ab9a3370e6aae7540092000233221233001003002300535742a0046eb4d5d09aba2500223263200c33573801a01801426aae7940044dd50009191999ab9a3370e6aae75400520002375c6ae84d55cf280111931900519ab9c00b00a00813754002464646464646666ae68cdc3a800a401842444444400646666ae68cdc3a8012401442444444400846666ae68cdc3a801a40104664424444444660020120106eb8d5d0a8029bad357426ae8940148cccd5cd19b875004480188cc8848888888cc008024020dd71aba15007375c6ae84d5d1280391999ab9a3370ea00a900211991091111111980300480418061aba15009375c6ae84d5d1280491999ab9a3370ea00c900111909111111180380418069aba135573ca01646666ae68cdc3a803a400046424444444600a010601c6ae84d55cf280611931900999ab9c01401301101000f00e00d00c00b135573aa00826aae79400c4d55cf280109aab9e5001137540024646464646666ae68cdc3a800a4004466644424466600200a0080066eb4d5d0a8021bad35742a0066eb4d5d09aba2500323333573466e1d4009200023212230020033008357426aae7940188c98c8030cd5ce00680600500489aab9d5003135744a00226aae7940044dd5000919191999ab9a3370ea002900111909118008019bae357426aae79400c8cccd5cd19b875002480008c8488c00800cdd71aba135573ca008464c6401266ae7002802401c0184d55cea80089baa00112232323333573466e1d400520042122200123333573466e1d40092002232122230030043006357426aae7940108cccd5cd19b87500348000848880088c98c8028cd5ce00580500400380309aab9d5001137540024646666ae68cdc3a800a4004402846666ae68cdc3a801240004028464c6400c66ae7001c01801000c4d55ce9baa001498480052410350543100233002501000132001355011222533500110022213500222330073330080020060010033200135501022225335001100222135002225335333573466e1c005200001301213330080070060031333008007335014123330010080030020060031123300100200b2253350021001100a1233500222333500322002002001350012200112212330010030022233371800466e04dc6800801000a40144466e00008004c8004d5402088cd400520002235002225335333573466e3c0080340240204c01c0044c01800cc8004d5401c88cd400520002235002225335333573466e3c00803002001c40044c01800c4880084880044488008488488cc00401000c448848cc00400c009221001123230010012233003300200200133351222513335122233512233002300448811cddf65cd8272fca8ee6ef4ae72019f01e134eaf5c7b7f9bac8940696300500722123300100300220012122300200321223001003200112122300200311220011200133512233002488120568ea530dfe90b2a0890b340eac46b3c58ce298eb67cee047e2463ea105f4cdd00480008848cc00400c0088005\",\n};\n\nconst policyId = lucid.utils.mintingPolicyToId(mintingPolicy);\n\n// onchain.hs: refValidator\nconst refScript: SpendingValidator = {\n  type: \"PlutusV2\",\n  script:\n    \"590c36590c330100003232323322332232323232323232323232323232323232323232323233223232323232323232323232332232322323222323253353332223232323232330303332001503148004d54014888888010cc0c0ccc800540c5200135500522222200133030330175001355005222222006330303301750013550052222220033303033017330180325003488105283232322900330303301733018032500448810528313030290033030330173302f03250033302f03250043301735500222001500413550012200215335302a3232335530141200123500122335503d0023355301712001235001223355040002333500123303a4800000488cc0ec0080048cc0e80052000001335530141200123500122335503d00233350012335530181200123500122335504100235501a0010012233355501501c0020012335530181200123500122335504100235501900100133355501001700200132335530141200123500122335503d002335530171200123500122335504000233704900080080080099a81b99aa81c81d19a81b99aa81c81d1819800a81c281c191a8009111001991a800910009aa99a9a802111a8011111111111111999a8069281612816128161199aa98110900099a81191299a801108018800a81611a80091299aa99a999ab9a3371e6a004440046a0084400408e08c2666ae68cdc39a801110009a80211000823823082309a8180018a817806908918008010b10008b1109a801111299a802099aa81e801801110b09aa80111111100289aa8009111110010a99a9813991a8009111111111110041a800910010b1109a801111299a8020b1109a801111299a802089199999800804804003802001801110b1999ab9a3370e6aae7540192000233221233001003002333550162001200135742a00c6eb4d5d09aba250062326320233357380480460426666ae68cdc39aab9d37540089000101191931901199ab9c0240230213333573466e1cd55cea80124000466442466002006004646464646464646464646464646666ae68cdc39aab9d500c480008cccccccccccc88888888888848cccccccccccc00403403002c02802402001c01801401000c008cd4080084d5d0a80619a8100109aba1500b33502002235742a014666aa048eb9408cd5d0a804999aa8123ae502335742a01066a0400566ae85401cccd540900b1d69aba150063232323333573466e1cd55cea801240004664424660020060046464646666ae68cdc39aab9d5002480008cc8848cc00400c008cd40d9d69aba150023037357426ae8940088c98c80e4cd5ce01d01c81b89aab9e5001137540026ae854008c8c8c8cccd5cd19b8735573aa004900011991091980080180119a81b3ad35742a004606e6ae84d5d1280111931901c99ab9c03a039037135573ca00226ea8004d5d09aba2500223263203533573806c06a06626aae7940044dd50009aba1500533502075c6ae854010ccd540900a08004d5d0a801999aa8123ae200135742a00460546ae84d5d1280111931901899ab9c03203102f135744a00226ae8940044d5d1280089aba25001135744a00226ae8940044d5d1280089aba25001135744a00226ae8940044d55cf280089baa00135742a00460346ae84d5d1280111931901199ab9c024023021102213263202233573892010350543500022135573ca00226ea80044d55cf280089baa00111122233355300412001502b335530071200123500122335503000235500900133355300412001223500222533533355300c120013233500e22333500322002002001350012200112330012253350021031100102e235001223300a0020050061003133502f004003502c001335530071200123500122323355031003300100532001355032225335001135500a003221350022253353300c002008112223300200a004130060030023200135502b221122253350011002221330050023335530071200100500400111212223003004112122230010043200135502822112253350011502922133502a30040023355300612001004001320013550272211222533500113500322001221333500522002300400233355300712001005004001122123300100300222333573466e3c00800408808488ccdc6240000040022464460046eb0004c8004d5409088cccd55cf80092812119a81198021aba1002300335744004028464646666ae68cdc39aab9d5002480008cc8848cc00400c008c030d5d0a80118029aba135744a004464c6402866ae700540500484d55cf280089baa0012323232323333573466e1cd55cea8022400046666444424666600200a0080060046464646666ae68cdc39aab9d5002480008cc8848cc00400c008c054d5d0a80119a80680a1aba135744a004464c6403266ae7006806405c4d55cf280089baa00135742a008666aa010eb9401cd5d0a8019919191999ab9a3370ea0029002119091118010021aba135573ca00646666ae68cdc3a80124004464244460020086eb8d5d09aab9e500423333573466e1d400d20002122200323263201b33573803803603203002e26aae7540044dd50009aba1500233500975c6ae84d5d1280111931900a99ab9c016015013135744a00226ae8940044d55cf280089baa0011335500175ceb44488c88c008dd5800990009aa81091191999aab9f0022502223350213355023300635573aa004600a6aae794008c010d5d100180909aba100112232323333573466e1d400520002350073005357426aae79400c8cccd5cd19b875002480089401c8c98c8048cd5ce00980900800789aab9d5001137540022424460040062244002464646666ae68cdc3a800a400c46424444600800a600e6ae84d55cf280191999ab9a3370ea004900211909111180100298049aba135573ca00846666ae68cdc3a801a400446424444600200a600e6ae84d55cf280291999ab9a3370ea00890001190911118018029bae357426aae7940188c98c8040cd5ce00880800700680600589aab9d500113754002464646666ae68cdc39aab9d5002480008cc8848cc00400c008c014d5d0a8011bad357426ae8940088c98c8030cd5ce00680600509aab9e5001137540024646666ae68cdc39aab9d5001480008dd71aba135573ca004464c6401466ae7002c0280204dd5000919191919191999ab9a3370ea002900610911111100191999ab9a3370ea004900510911111100211999ab9a3370ea00690041199109111111198008048041bae35742a00a6eb4d5d09aba2500523333573466e1d40112006233221222222233002009008375c6ae85401cdd71aba135744a00e46666ae68cdc3a802a400846644244444446600c01201060186ae854024dd71aba135744a01246666ae68cdc3a8032400446424444444600e010601a6ae84d55cf280591999ab9a3370ea00e900011909111111180280418071aba135573ca018464c6402666ae7005004c04404003c03803403002c4d55cea80209aab9e5003135573ca00426aae7940044dd50009191919191999ab9a3370ea002900111999110911998008028020019bad35742a0086eb4d5d0a8019bad357426ae89400c8cccd5cd19b875002480008c8488c00800cc020d5d09aab9e500623263200c33573801a01801401226aae75400c4d5d1280089aab9e500113754002464646666ae68cdc3a800a400446424460020066eb8d5d09aab9e500323333573466e1d400920002321223002003375c6ae84d55cf280211931900499ab9c00a009007006135573aa00226ea8004488c8c8cccd5cd19b87500148010848880048cccd5cd19b875002480088c84888c00c010c018d5d09aab9e500423333573466e1d400d20002122200223263200a33573801601401000e00c26aae7540044dd50009191999ab9a3370ea0029001100911999ab9a3370ea0049000100911931900319ab9c007006004003135573a6ea800526120014910350543100233002500e0013200135500f222533500110022213500222330073330080020060010033200135500e22225335001100222135002225335333573466e1c005200001101013330080070060031333008007335012123330010080030020060032233371800466e04dc680080100091299a80108008804091199ab9a3370e00400201000e90051119b8000200132001355008223350014800088d4008894cd4ccd5cd19b8f00200d009008130070011300600332001355007223350014800088d4008894cd4ccd5cd19b8f00200c0080071001130060031220021220011122002122122330010040031122123300100300248900112323001001223300330020020011\",\n};\n\nconst refAddress = lucid.utils.validatorToAddress(refScript);\n\nexport async function mintNFT(\n  assetName: string,\n  metadata: Metadata,\n): Promise<TxHash> {\n  const refNft = policyId + utf8ToHex(\"(100)\") + utf8ToHex(assetName); // The label is not finalized yet!\n  const userToken = policyId + utf8ToHex(\"(222)\") + utf8ToHex(assetName); // The label is not finalized yet!\n\n  const [requiredUtxo] = await lucid.utxosByOutRef([{\n    txHash: \"568ea530dfe90b2a0890b340eac46b3c58ce298eb67cee047e2463ea105f4cdd\",\n    outputIndex: 0,\n  }]);\n\n  const mintRedeemer = Data.to(new Constr(0, []));\n\n  const datumMetadata = Data.to(new Constr(0, [Data.fromJson(metadata), 1n])); // datum will be appended to witness set; only datum hash in reference output\n\n  const tx = await lucid.newTx()\n    .collectFrom([requiredUtxo])\n    .mintAssets({ [refNft]: 1n, [userToken]: 1n }, mintRedeemer) // mint refNft and user token pair\n    .payToContract(refAddress, datumMetadata, { [refNft]: 1n }) // send refNft to reference script address\n    .payToAddress(await lucid.wallet.address(), { [userToken]: 1n }) // send userToken to user wallet address\n    .attachMintingPolicy(mintingPolicy)\n    .complete();\n\n  const signedTx = await tx.sign().complete();\n  return signedTx.submit();\n}\n\nexport async function burnNFT(assetName: string): Promise<TxHash> {\n  const refNft = policyId + utf8ToHex(\"(100)\") + utf8ToHex(assetName); // The label is not finalized yet!\n  const userToken = policyId + utf8ToHex(\"(222)\") + utf8ToHex(assetName); // The label is not finalized yet!\n\n  const [refUtxo] = await lucid.utxosAtWithUnit(refAddress, refNft);\n\n  const burnRedeemer = Data.to(new Constr(1, []));\n\n  const tx = await lucid.newTx()\n    .collectFrom([refUtxo], Data.empty())\n    .mintAssets({ [refNft]: -1n, [userToken]: -1n }, burnRedeemer) // burn refNft and user token pair\n    .attachSpendingValidator(refScript)\n    .attachMintingPolicy(mintingPolicy)\n    .complete();\n\n  const signedTx = await tx.sign().complete();\n  return signedTx.submit();\n}\n\nexport async function viewNFT(assetName: string): Promise<Metadata> {\n  const refNft = policyId + utf8ToHex(\"(100)\") + utf8ToHex(assetName); // The label is not finalized yet!\n  const [refUtxo] = await lucid.utxosAtWithUnit(refAddress, refNft);\n\n  if (!refUtxo) return {} as Metadata;\n\n  const datum = Data.from(await lucid.datumOf(refUtxo)) as Constr<PlutusData>;\n  const metadata: Metadata = Data.toJson(datum.fields[0]);\n\n  return metadata;\n}\n\n/*\n  Example:\n\n  // Mint\n  const txHash = await mintNFT(\"cip68\", { name: \"CIP-0068 NFT\", image: \"ipfs://<hash>\" });\n  console.log(txHash);\n\n  // Burn\n  const txHash = await burnNFT(\"cip68\", { name: \"CIP-0068 NFT\", image: \"ipfs://<hash>\" });\n  console.log(txHash);\n\n  // View\n  const metadata = await viewNFT(\"cip68\")\n  console.log(metadata);\n\n*/\n"
  },
  {
    "path": "CIP-0068/ref_impl/onchain.hs",
    "content": "-- PlutusTx on-chain code (PlutusV2)\n-- NOTE: The asset name labels are not finalized yet. This is only a proof of concept\n\ntype Metadata = Map BuiltinData BuiltinData\ndata DatumMetadata = DatumMetadata {\n                        metadata    :: Metadata\n                    ,   version     :: Integer\n                    }\n\ndata Action = Mint | Burn\n\nPlutusTx.makeLift ''Action\nPlutusTx.makeIsDataIndexed ''Action [('Mint, 0), ('Burn, 1)]\n\n\ntxOutRef :: TxOutRef\ntxOutRef = TxOutRef \"568ea530dfe90b2a0890b340eac46b3c58ce298eb67cee047e2463ea105f4cdd\" 0 -- Example out ref (required to mint NFT)\n\n\n-- | Minting policy (mints user token and reference NFT as pair). It is a one-shot policy.\n-- Minting policy depends on reference validator \n{-# INLINEABLE mintValidatorControl #-}\nmintingPolicy :: Address -> TxOutRef -> Action -> ScriptContext -> Bool\nmintingPolicy refAddress oref action ctx = case action of\n    Mint    -> checkMint\n    Burn -> checkBurn\n  where\n    txInfo :: TxInfo\n    txInfo = scriptContextTxInfo ctx\n\n    txMint :: Value\n    txMint = txInfoMint txInfo\n\n    ownSymbol :: CurrencySymbol\n    ownSymbol = ownCurrencySymbol ctx\n\n    prefixLength :: Integer\n    prefixLength = 5\n\n    checkMint :: Bool\n    checkMint =\n            let\n                [(_, refOutValue)] = scriptOutputsAtAddress refAddress txInfo\n                [(refOutCs, TokenName refOutName,refOutAm)] = flattenValue (noAdaValue refOutValue)\n                -- | Mint value (reference NFT and user token).\n                [(userCs, TokenName userName, userAm), (refCs, TokenName refName, refAm)] = flattenValue txMint\n            in\n                -- | One shot policy\n                spendsOutput txInfo (txOutRefId oref) (txOutRefIdx oref)                                            &&\n                -- | Check if minted reference NFT is sent to reference address\n                noAdaValue refOutValue == V.singleton refCs (TokenName refName) refAm                               &&\n                -- | Check quantity and policy ids\n                userAm == 1 && refAm == 1 && userCs == ownSymbol && refCs == ownSymbol                              &&\n                -- | Check naming\n                takeByteString prefixLength userName == \"(222)\" && takeByteString prefixLength refName == \"(100)\"   &&\n                dropByteString prefixLength userName == dropByteString prefixLength refName\n\n                \n\n    checkBurn :: Bool\n    checkBurn = all (\\(_,_,am) -> am < 0) (flattenValue txMint)\n\n\n-- | Reference validator (holds the reference NFT with metadata)\n{-# INLINEABLE refValidator #-}\nrefValidator :: DatumMetadata -> () -> ScriptContext -> Bool\nrefValidator datumMetadata () ctx = checkBurn\n  where\n    txInfo :: TxInfo\n    txInfo = scriptContextTxInfo ctx\n\n    txMint :: Value\n    txMint = txInfoMint txInfo\n\n    ownValue :: Value\n    ownValue =  let Just i = findOwnInput ctx\n                    out = txInInfoResolved i\n                in txOutValue out\n\n    prefixLength :: Integer\n    prefixLength = 5\n\n    providesUserToken :: CurrencySymbol -> TokenName -> Integer -> Bool\n    providesUserToken cs tn am = any (\\(TxInInfo _ out) -> valueOf (txOutValue out) cs tn == am) (txInfoInputs txInfo)\n\n    checkBurn :: Bool\n    checkBurn = \n            let\n                -- | Allow burning only one pair (reference NFT and user token) at once.\n                [(userCs, TokenName userName, userAm), (refCs, TokenName refName, refAm)] = flattenValue txMint\n                [(ownCs, TokenName ownName, _)] = flattenValue (noAdaValue ownValue)\n            in\n                -- | Matching policy ids and quantities.\n                -1 == userAm && -1 == refAm &&\n                ownCs == userCs && ownCs == refCs && \n                -- | Matching asset names.\n                takeByteString prefixLength userName == \"(222)\" && takeByteString prefixLength refName == \"(100)\" &&\n                dropByteString prefixLength userName == dropByteString prefixLength refName                       &&\n                -- | Burned reference NFT needs to match the one in the own script UTxO\n                ownName == refName\n\n\n\n{-# INLINEABLE scriptOutputsAtAddress #-}\nscriptOutputsAtAddress :: Address -> TxInfo -> [(OutputDatum, Value)]\nscriptOutputsAtAddress address p =\n    let flt TxOut{txOutDatum=d, txOutAddress=address', txOutValue} | address == address' = Just (d, txOutValue)\n        flt _ = Nothing\n    in mapMaybe flt (txInfoOutputs p)"
  },
  {
    "path": "CIP-0069/README.md",
    "content": "---\nCIP: 69\nTitle: Script Signature Unification\nCategory: Plutus\nAuthors:\n  - Maksymilian 'zygomeb' Brodowicz <zygomeb@gmail.com>\nImplementors: N/A\nStatus: Active\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/321\nCreated: 2022-08-23\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP unifies the arguments given to all types of Plutus scripts currently available (spending, certifying, rewarding, minting) by removing the argument of a datum.\n\nFor a while now every builder, myself included have struggled with the mutual dependency issue (two validators that need to know each other's hash) when designing dapps and it is widely considered a substantial barrier to safe protocols and one that limits our design space considerably.\n\nThe exact change would be to have every validator take as argument the redeemer and then the script context. Datums, only relevant to locking validators would be able to be provided by either looking them up in the ScriptContext or by extending the `Spending` constructor of `TxInfo` to carry `(TxOutRef, Datum)`.\n\n## Motivation: why is this CIP necessary?\n\n### Multi-purpose Scripts\n\nAs it stands the scripts being made on cardano often suffer this problem, and the tokens usually are made to be able to be minted at any time. This leads to further checks being made on the frontend and further fragilitiy of the systems we create. When a mutual dependency arises we are forced to choose which script gets to statically know what's the hash of the other, and which has to be provided 'during runtime'.\n\n- Use Case 1: Minting validator checks datum given to spending validator. The spending validator requires the token be present as witness of the datum's correctness.\n\n- Use Case 2 (taken from Optim's Liquidity Bonds): Unique NFT is minted to give a unique identifier to a loan, that then gets reused by Bond Tokens. The spending validators require that NFT be present.\n\n- Use Case 3 (taken from Minswap's Dex V1): NFT is minted for the same reason as above. It allows a minting policy to later mint LP tokens with that unique id token name.\n\nWe see a similar pattern repeating over and over again as witnessed by dapp developers and auditors alike. By allowing the multi-purpose scripts (spending and any other) we increase the security of Cardano by giving us more confidence and allowing to design protocols that have their architecture driven by Cardano's features, not limited by Cardano's language.\n\nThis primarily manifests in the ability to use a single validator for both minting and spending but the proposed solution makes it possible to use one validator for any and all purposes at once.\n\n### No Datum Spend Purpose\n\nOne of the major footguns of Plutus scripts is if a user sends to the script with a wrong or missing datum. This has happened in the case of the Nami wallet having a bug that caused the wrong address to be chosen. There are other instances of user error where they send from a CEX to a script address. A wrong datum can be handled by the Plutus scripts themselves by having an alternative execution branch if type does not match the expected datum type. But in the case of no datum the script is not run and fails in phase 1 validation. The other motivation of this CIP is to be able to create spend scripts that can handle the no datum case.\n\nI see three major use cases when it comes to running spend scripts without datums:\n\n- Use Case 1: A script that acts as a wallet for users. By having no datum spending the user can send directly from exchanges or have friends send to their smart contract wallet with no datum needed.\n\n- Use Case 2: As a DAO treasury. The funds in this script would be controlled by a DAO and anyone can donate/contribute to the DAO without a datum.\n\n- Use Case 3: Allow dApp protocols to have a claim or withdraw mechanism (similar to Ethereum for tokens sent to a contract without call) for claiming tokens sent without a datum.\n\nI'd be remiss if I didn't mention CIP-0112 which has been expanded to improve native script capabilities to provide an alternative solution for use case 1 and 2. But for use case 3, CIP-0112 does not enable a \"claim or withdraw mechanism\" for contracts.\n\n## Specification\n\n### Removing the datum argument\n\nAll the script purposes have a form of ```Redeemer -> ScriptContext -> a``` except the Spending one. It has the following form: ```Datum -> Redeemer -> ScriptContext -> a```. This is enforced by the Cardano ledger.\n\nWe propose to make the following modification:\n\nThe signature of all scripts will be ```ScriptContext -> a```.\nThe `ScriptInfo` type is a union type with a variant for each script purpose.\nIt is the same as `ScriptPurpose`, except for the additional optional datum in spending scripts.\n\n```haskell\n-- | The context that the currently-executing script can access.\ndata ScriptContext = ScriptContext\n  { scriptContextTxInfo     :: TxInfo\n  -- ^ information about the transaction the currently-executing script is included in\n  , scriptContextRedeemer   :: V2.Redeemer\n  -- ^ Redeemer for the currently-executing script\n  , scriptContextScriptInfo :: ScriptInfo\n  -- ^ the purpose of the currently-executing script, along with information associated\n  -- with the purpose\n  }\n\n-- | Like `ScriptPurpose` but with an optional datum for spending scripts.\ndata ScriptInfo\n  = MintingScript V2.CurrencySymbol\n  | SpendingScript V3.TxOutRef (Haskell.Maybe V2.Datum)\n  | RewardingScript V2.Credential\n  | CertifyingScript\n      Haskell.Integer\n      -- ^ 0-based index of the given `TxCert` in `txInfoTxCerts`\n      TxCert\n  | VotingScript Voter\n  | ProposingScript\n      Haskell.Integer\n      -- ^ 0-based index of the given `ProposalProcedure` in `txInfoProposalProcedures`\n      ProposalProcedure\n```\n\nThe datum in `SpendingScript` is optional, which will allow the execution of spending scripts without a datum.\nOne more change will be needed on the ledger side in order to make the Datum optional for spending scripts.\nThe ledger UTXOW rule needs to be relaxed, this ledger rule checks if a utxo has an existing datum if the address's payment credential is a phase 2 validation script.\n\nThe ScriptPurpose type used in the Redeemers Map is left the same.\nIt is used to uniquely identify a Plutus script within a transaction.\n\n\n## Rationale: how does this CIP achieve its goals?\n\nUnifying of the script signature is a very elegant solution to the problem, streamlining the experience of developing on cardano.\nIt begs the question if it should be added as an argument to all validators, to further emphasize that fact.\n\n\nThis CIP turns all scripts into 1 arg scripts with a Script Context union type for each purpose.\n\n## Backwards compatibility\n\nThis change is not backwards compatible; it must be introduced in a new Plutus language version.\nNode code must be modified.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] The change has been implemented in the Plutus codebase, integrated in the ledger and released through a hard-fork.\n  - Included within the Chang #1 hardfork\n\n### Implementation Plan\n\nThe Cardano Ledger and Cardano Plutus teams would need to implement this in following repositories:\n  IntersectMBO/plutus\n  IntersectMBO/cardano-ledger\n\nThe following languages that compile to uplc would need to update to support the new ScriptContext argument that\nis passed in for the next Plutus Version:\nAiken\nHelios\nOpshin\nPlu-ts\nPlutarch\nScalus\n\n## Copyright\n\nThis CIP is licensed under Apache-2.0\n"
  },
  {
    "path": "CIP-0071/README.md",
    "content": "---\nCIP: 71\nTitle: Non-Fungible Token (NFT) Proxy Voting Standard\nStatus: Proposed\nCategory: Tools\nAuthors:\n  - Thaddeus Diamond <support@wildtangz.com>\nImplementors: []\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/351\nCreated: 2022-10-11\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis proposal uses plutus minting policies to create valid \"ballots\" that are sent alongside datum \"votes\" to a centralized smart contract \"ballot box\" in order to perform verifiable on-chain voting in NFT projects that do not have a governance token.\n\n## Motivation: why is this CIP necessary?\n\nThis proposal is intended to provide a standard mechanism for non-fungible token (NFT) projects to perform on-chain verifiable votes using only their NFT assets. There are several proposed solutions for governance that involve using either a service provider (e.g., Summon) with native assets or the issuance of proprietary native assets.  However, there are several issues with these approaches:\n- Airdrops of governance tokens require minUTxO ada attached, costing the NFT project ada out of pocket\n- Fungible tokens do not have a 1:1 mechanism for tracking votes against specific assets with voting power\n- Sale of the underlying NFT is not tied to sale of the governance token, creating separate asset classes and leaving voting power potentially with those who are no longer holders of the NFT\n\nThis standard provides a simple solution for this by using the underlying NFT to mint a one-time \"ballot\" token that can be used only for a specific voting topic. Projects that adopt this standard will be able to integrate with web viewers that track projects' governance votes and will also receive the benefits of verifiable on-chain voting without requiring issuance of a new native token.\n\nWe anticipate some potential use cases:\n- Enforcing an exact 1:1 vote based on a user's existing NFT project holdings\n- Enforcing vote validity by rejecting invalid vote options (e.g., disallowing write-ins)\n- Creating \"super-votes\" based on an NFT serial number (e.g., rare NFTs in the 9,000-10,000 serial range get 2x votes)\n\n> **Warning**\n> This specification is not intended for for governance against fungible tokens that cannot be labeled individually.\n\n## Specification\n\n### A Simple Analogy\n\nThe basic analogy here is that of a traditional state or federal vote.  Imagine a citizen who has a state ID (e.g., Driver's License) and wants to vote, as well as a central voting authority that counts all the ballots.\n1. Citizens go to to a precinct and show their ID to the appropriate authority\n2. Citizens receive a ballot with choices for the current vote\n3. Citizens mark their selections on the ballot\n4. Citizens sign their ballot with their name\n5. Citizens submit their ballot into a single \"ballot box\"\n6. Central voting authorities process the vote after polls close\n7. Citizens await the election results through a trusted news outlet\n\nThis specification follows the same process, but using tokens:\n1. A holder of a project validates their NFT by sending it to self\n2. The holder signs a Plutus minting policy to create a \"ballot\" NFT linked to their unique NFT\n3. The holder marks their desired vote selections on the ballot\n4. The holder signs a tx that sends the \"ballot\" NFT to a \"ballot box\" (smart contract) with their \"vote\" (datum)\n5. Authorized vote counting wallets process UTxOs and their datums in the \"ballot box\" smart contract after polls close\n6. Authorized vote counters report the results in a human-readable off-chain format to holders\n\n> **Note**\n> Because of the efficient UTxO model Cardano employs, steps #1 through #4 occur in a single transaction.\n\n### The Vote Casting Process\n\n#### \"Ballot\" -> Plutus Minting Policy\n\nEvery holder that participates in the vote will have their project NFT in a wallet that can be spent from (either hardware or software, typically accessed via [CIP-30](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030)).  To create a ballot, the voting authority will create a Plutus minting policy with a specific combination of:\n\n```ts\ntype BallotMintingPolicy = {\n  referencePolicyId: MintingPolicyHash,             // Reference policy ID of the original NFT project\n  pollsClose: Time,                                 // Polls close (as a Unix timestamp in milliseconds)\n  assetNameMapping: func(ByteArray) -> ByteArray    // Some function (potentially identity) to map reference NFT name 1-for-1 to ballot NFT name\n};\n```\n\nThis Plutus minting policy will perform the following checks:\n1. Polls are still open during the Tx validFrom/validTo interval\n2. The ballot NFTs were validly minted (at the least, the user sent-to-self the reference assets and the vote weight/choices are correct)\n3. The minted assets are sent directly to the ballot box smart contract in the minting transaction (see [the potential attack below](#Creation-of-Ballot-Without-Casting-a-Vote))\n\nFor the voter, each vote they wish to cast will require creating a separate \"ballot\" NFT.  In the process, their reference NFT never leaves the original wallet.  Sample [Helios language](https://github.com/Hyperion-BT/Helios) pseudocode (functions elided for space) is as follows:\n\n```ts\nfunc main(redeemer: Redeemer, ctx: ScriptContext) -> Bool {\n  tx: Tx = ctx.tx;\n  minted_policy: MintingPolicyHash = ctx.get_current_minting_policy_hash();\n  redeemer.switch {\n    Mint => {\n      polls_are_still_open(tx.time_range)\n        && ballots_are_validly_minted(tx.minted, minted_policy, tx.outputs)\n        && assets_locked_in_ballot_box(tx, tx.minted)\n    },\n    // Burn code elided for space...\n  }\n}\n```\n\n> **Note**\n> `ballots_are_validly_minted()` includes all required and custom checks (e.g., the holder has sent the reference NFT to themselves in `tx.outputs`) to validate newly minted ballots\n\n#### \"Vote\" -> eUTxO Datum\n\nTo cast the vote, the user sends the ballot NFT just created to a \"ballot box\".  Note that for reasons specified in [the \"attacks\" section below](#Creation-of-Ballot-Without-Casting-a-Vote) this needs to occur during the same transaction that the ballot was minted in.\n\nThe datum is a simple object representing the voter who cast the vote and the vote itself:\n\n```ts\ntype VoteDatum = {\n  voter: PubKeyHash,\n  vote: object\n};\n```\n\nThe `voter` element is extremely important in this datum so that we know who minted the ballot NFT and who we should return it to.  At the end of the ballot counting process, this user will receive their ballot NFT back.\n\nNote that we are trying to avoid being overly prescriptive here with the specific vote type as we want the only limitations on the vote type to be those imposed by Cardano.  Further iterations of this standard should discuss the potential for how to implement ranked-choice voting (RCV) inside of this `vote` object, support multiple-choice vote selection, and more.\n\n#### \"Ballot Box\" -> Smart Contract\n\nEssentially, the \"ballot box\" is a smart contract with arbitrary logic decided upon by the authorized vote counter.  Some examples include:\n\n1. A ballot box that can be redeemed at any time by a tx signed by the authorized vote counter\n2. A ballot box that can be redeemed only after polls close\n3. A ballot box that can be redeemed once a majority of voters have sent in a ballot\n4. A ballot box that can be redeemed only by the specific wallet specified in the `voter` datum of each UTxO\n5. A ballot box that can be redeemed only after polls close, has to burn the ballots it redeems, and has to send the minUTxO back to the voter address\n\nBecause the ballot creation and vote casting process has already occurred on-chain we want to provide the maximum flexibility in the protocol here so that each project can decide what is best for their own community.  Helios code for the simple case enumerated as #1 above would be:\n\n```ts\nconst EXPECTED_SIGNER: PubKeyHash = PubKeyHash::new(#0123456789abcdef)\n\nfunc main(ctx: ScriptContext) -> Bool {\n  ctx.tx.is_signed_by(EXPECTED_SIGNER)\n}\n```\n\n### The Vote Counting Process\n\n#### \"Ballot Counter\" -> Authorized Wallet\n\nGiven the flexible nature of the [\"ballot box\" smart contract](#Ballot-Box---Smart-Contract) enumerated above, we propose a simple algorithm for counting votes and returning the ballots to the user:\n\n1. Ensure the polls are closed (can be either on or off-chain)\n2. Iterate through all UTxOs in forward-time-order locked in the \"ballot box\" and for each:\n\t* Determine which assets are inside of that UTxO\n\t* Mark their most recent vote to match the `vote` object in the UTxOs datum\n3. Ensure any required quorums or thresholds were reached\n4. Report on the final ballot outcome\n\nJavascript-like pseudocode using the [Lucid library](https://github.com/spacebudz/lucid) for the above algorithm would be as follows:\n\n```js\nfunction countVotes(ballotPolicyId, ballotBox) {\n  var votesByAsset = {};\n  const votes = await lucid.utxosAt(ballotBox);\n  for (const vote of votes) {\n    const voteResult = Data.toJson(Data.from(vote.datum));\n    for (const unit in vote.assets) {\n      if (!unit.startsWith(ballotPolicyId)) {\n        continue;\n      }\n      const voteCount = Number(vote.assets[unit]);         // Should always be 1\n      votesByAsset[unit] = {\n        voter: voteResult.voter,\n        vote: voteResult.vote,\n        count: voteCount\n      }\n    }\n  }\n  return votesByAsset;\n}\n```\n\nThere is no requirement that the \"ballot counter\" redeem all \"ballots\" from the \"ballot box\" and send them back to the respective voters, but we anticipate that this is what will happen in practice.  We encourage further open-sourced code versions that enforce this requirement at the smart contract level.\n\n### Reclaiming Ada Locked by the Ballot NFTs\n\nEven if the ballot NFT is returned to the user, this will leave users with ada locked alongside these newly created assets, which can impose a financial hardship for certain project users.\n\nWe can add burn-specific code to our Plutus minting policy so that ballot creation does not impose a major financial burden on users:\n\n```ts\nfunc main(redeemer: Redeemer, ctx: ScriptContext) -> Bool {\n  tx: Tx = ctx.tx;\n  minted_policy: MintingPolicyHash = ctx.get_current_minting_policy_hash();\n  redeemer.switch {\n    // Minting code elided for space...\n    Burn => {\n      tx.minted.get_policy(minted_policy).all((asset_id: ByteArray, amount: Int) -> Bool {\n        if (amount > 0) {\n          print(asset_id.show() + \" asset ID was minted not burned (quantity \" + amount.show() + \")\");\n          false\n        } else {\n          true\n        }\n      })\n    }\n  }\n}\n```\n\nThe Helios code above simply checks that during a burn (as indicated by the Plutus minting policy's `redeemer`), the user is not attempting to mint a positive number of any assets.  With this code, *any Cardano wallet* can burn *any ballot* minted as part of this protocol.  Why so permissive? We want to ensure that each vote is bringing the minimal costs possible to the user.  In providing this native burning mechanism we can free up the minUTxO that had been locked with the ballot, and enable the user to potentially participate in more votes they might not have otherwise.  In addition, users who really do not like the specific commemorative NFTs or projects that choose to skip the \"commemorative\" aspect of ballot creation now have an easy way to dispose of \"junk\" assets.\n\n## Rationale: how does this CIP achieve its goals?\n\n### Using Inline Datums (On-Chain) Instead of Metadata (Off-Chain)\n\nThere are several existing open-source protocols (e.g., [VoteAire](https://github.com/voteaire/voteaire-onchain-spec)) that use metadata to record votes in Cardano transactions without requiring any additional minting or smart contracts.  However, since the vote counting occurs off-chain by validating metadata the vote counter is the ultimate arbiter of what is a \"valid\" vote.  In this specification, the validity of the vote is ensured in the Ballot creation process, so that any vote in the ballot box is guaranteed to be valid.  We strongly believe that moving the entire process into flexible on-chain logic will improve the transparency of the voting process and meet the needs of the use cases discussed in [\"Motivation\"](#Motivation) and [\"Ballot Box\"](#Ballot-Box---Smart-Contract).\n\n### Commemorative NFTs with Optional Token Burning\n\nThere is a question as to whether we should enforce the requirement that votes be burned when they are counted by the vote counter.  However, we do not want that to be a standard as many users of NFT communities have expressed an interest in receiving commemorative NFTs (similar to an \"I Voted\" sticker).  Instead, we propose that the ballot Plutus minting policy be burn-able by anyone who holds the NFT in their wallet.  This way, locked ada can be reclaimed if the user has no further use for the commemorative NFT (see an example of this in the [Implementation](./example/)).\n\n### Potential Attacks and Mitigations\n\n#### Creation of Ballot Without Casting a Vote\n\nImagine a user who decides to create ballots for the current vote, but not actually cast the vote by sending it to the ballot box.  According to checks #1 and #2 in [the Plutus Minting Policy](#Ballot---Plutus-Minting-Policy), this would be possible.  After the ballot was created, the user could sell the reference NFT and wait until just before the polls close to surreptitiously cast a vote over the wishes of the new project owner.  Check #3 in the minting policy during the mint transaction itself prevents this attack.\n\n#### Double Voting in Multiple Transactions\n\nA user could wait until their first vote casting transaction completes, then create more ballots and resubmit to the ballot box.  The result would be the creation of more assets that count toward the ultimate vote.  However, Cardano helps us here by identifying tokens based on the concatenation of policy ID and asset identifier.  So long as the mapping function in the [Plutus minting policy for ballots](#Ballot---Plutus-Minting-Policy) is idempotent, each subsequent time the user votes the policy will create an additional fungible token with the same asset identifier.  Then, the ballot counter can ignore any prior votes based on each unique asset identifier to avoid duplicate votes (see [\"'Ballot Counter' -> Authorized Wallet\"](#Ballot-Counter---Authorized-Wallet)).\n\n#### Double Creation of the Same Ballot\n\nA user could attempt to create multiple ballots of the same name for a given reference NFT.  If the reference NFT is actually a fungible token and not an NFT, then our assumptions will have been broken and this is an unsupported use case.  But if our assumption that this is an NFT project are correct, then simply checking that the quantity minted is equal to the quantity spent inside of the Plutus minting policy will prevent this.  The [example code](./example/voting.js) attached does just that.\n\n#### Returning the \"Ballot\" NFTs to the Wrong User\n\nDuring the construction of the ballot NFTs we allow the user to specify their vote alongside a `voter` field indicating where their \"ballot\" NFT should be returned to once the vote is fully counted.  Unfortunately, this is not strictly checked inside the Plutus minting policy's code (largely due to CPU/memory constraints).  So, we rely on the user to provide an accurate return address, which means that there is the potential for someone who has not actually voted to receive a commemorative NFT.  This does not impact the protocol though, as the \"ballot\" NFT was legally minted, just returned to the incorrect location.  That user actually received a gift, as they can now burn the ballot and receive some small amount of dust.\n\n### Potential Disadvantages\n\nThere are several potential disadvantages to this proposal that may be avoided by the use of a native token or other voting mechanism.  We enumerate some here explicitly so projects can understand where this protocol may or may not be appropriate to use:\n\n- Projects concerned with token proliferation and confusing their user base with the creation of multiple new assets might want to avoid this standard as it requires one new token policy per vote/initiative\n- Projects wishing to create a \"secret ballot\" that will not be revealed until after polls close should not use this because the datum votes appear on-chain (and typically inline)\n  - Performing an encrypted vote on-chain with verifiable post-vote results is an exercise left to the standard's implementer\n- Projects wishing for anonymity in their votes should not use this standard as each vote can be traced to a reference asset\n\n### Optional Recommendations\n\nIn no particular order, we recommend the following implementation details that do not impact the protocol, but may impact user experience:\n\n- The mapping function described in the [Plutus minting policy for ballots](#Ballot---Plutus-Minting-Policy) should likely be some sort of prefixing or suffixing (e.g., \"Ballot #1 - <REFERENCE NFT>\"), and NOT the identity function.  Although the asset will be different than the reference NFT due to its differing policy ID, users are likely to be confused when viewing these assets in a token viewer.\n- The \"ballot\" NFT should have some sort of unique metadata (if using [CIP-25](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025)), datum (if using [CIP-68](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0068)) or other identification so that the users can engage with the ballot in a fun, exciting way and to ensure there is no confusion with the reference NFT.\n- The \"vote\" represented by a datum will be easier to debug and analyze in real-time if it uses the new \"inline datum\" feature from Vasil, but the protocol will still work on Alonzo era transactions.\n- The \"ballot box\" smart contract should likely enforce that the datum's \"voter\" field is respected when returning the ballots to users after voting has ended to provide greater transparency and trust for project participants.\n\n### Backward Compatibility\n\nDue to the nature of Plutus minting policies and smart contracts, which derive policy identifiers and payment addresses from the actual source code, once a vote has been started it cannot change versions or code implementations. However, because the mechanism we propose here is just a reference architecture, between votes projects are free to change either the \"ballot\" Plutus minting policy or the \"ballot box\" smart contract as they see fit.  There are no prior CIPs with which to conform with for backward interoperability.\n\n### References\n\n- [CIP-0025](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025): NFT Metadata Standard\n- [CIP-0030](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030): Cardano dApp-Wallet Web Bridge\n- [CIP-0068](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0068): Datum Metadata Standard\n- [Helios Language](https://github.com/Hyperion-BT/Helios): On-Chain Cardano Smart Contract language used in example code\n- [Lucid](https://github.com/spacebudz/lucid): Transaction construction library used in code samples and pseudocode\n- [VoteAire Specification](https://github.com/voteaire/voteaire-onchain-spec): Open-source voting specification using metadata off-chain\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] Presentation to, and adoption by, projects that may benefit from ranked-choice voting\n- [ ] Open-source implementations from other NFT projects that make use of this CIP\n\n### Implementation Plan\n\n- [x] Minimal reference implementation making use of [Lucid](https://github.com/spacebudz/lucid) (off-chain), [Plutus Core](https://github.com/input-output-hk/plutus) [using Helios](https://github.com/Hyperion-BT/Helios) (on-chain): [Implementation](./example/)\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0071/example/voting.html",
    "content": "<html>\n  <head>\n    <script src=\"https://cdn.jsdelivr.net/npm/bootstrap@4.2.1/dist/js/bootstrap.min.js\" integrity=\"sha384-B0UglyR+jN6CkvvICOB2joaf5I4l3gm9GU6Hc1og6Ls7i6U/mkkaduKaBhlAXv9k\" crossorigin=\"anonymous\"></script>\n\n    <link href=\"https://cdn.jsdelivr.net/npm/bootstrap@5.2.0-beta1/dist/css/bootstrap.min.css\" rel=\"stylesheet\" integrity=\"sha384-0evHe/X+R7YkIZDRvuzKMRqM+OrBnVFBL6DOitfPri4tjfHxaWutUpFmBp4vmVor\" crossorigin=\"anonymous\">\n    <link href=\"https://cdn.jsdelivr.net/npm/cardano-dapp-js@1.0.5/dist/cardano-wallet-picker.css\" rel=\"stylesheet\" integrity=\"sha384-jeqm08LTVeNbS97UWy4EXaCioonM70aAFwSpoQITuPKgc53EI0+XfxoG+0hwMLqj\" crossorigin=\"anonymous\">\n    <link href=\"https://cdn.jsdelivr.net/npm/toastify-js/src/toastify.min.css\" rel=\"stylesheet\" integrity=\"sha384-1txFwJFikBxvmOF4oqBQdSBJQzEUrMDB2MMmedDaFGsjXYStJKO7JkwyAWPDXlkk\" crossorigin=\"anonymous\">\n\n    <script type=\"text/javascript\" src=\"voting.js\"></script>\n    <link rel=\"stylesheet\" href=\"voting.css\" />\n  </head>\n\n  <body>\n    <div class=\"container\">\n      <div id=\"wallet-container\"></div>\n\n      <div id=\"wallet-voting-power\">\n        <h4>Connect your wallet to display eligible votes...</h4>\n      </div>\n\n      <div id=\"vote-ballot\">\n        <form id=\"vote-ballot-form\" class=\"bordered\">\n          <legend>Please vote on the question posed below (1 answer only)</legend>\n          <p><em>If you were to choose only one letter from the first 5 in the alphabet, what would it be?</em></p>\n\n          <div>\n            <input type=\"radio\" id=\"vote-ballot-choice-a\" name=\"vote-ballot-choice\" value=\"A\" disabled />\n            <label for=\"vote-ballot-choice-a\">A</label>\n          </div>\n\n          <div>\n            <input type=\"radio\" id=\"vote-ballot-choice-b\" name=\"vote-ballot-choice\" value=\"B\" disabled />\n            <label for=\"vote-ballot-choice-b\">B</label>\n          </div>\n\n          <div>\n            <input type=\"radio\" id=\"vote-ballot-choice-c\" name=\"vote-ballot-choice\" value=\"C\" disabled />\n            <label for=\"vote-ballot-choice-c\">C</label>\n          </div>\n\n          <div>\n            <input type=\"radio\" id=\"vote-ballot-choice-d\" name=\"vote-ballot-choice\" value=\"D\" disabled />\n            <label for=\"vote-ballot-choice-d\">D</label>\n          </div>\n\n          <div>\n            <input type=\"radio\" id=\"vote-ballot-choice-e\" name=\"vote-ballot-choice\" value=\"E\" disabled />\n            <label for=\"vote-ballot-choice-e\">E</label>\n          </div>\n        </form>\n      </div>\n\n      <div id=\"vote-container\" class=\"row padded\">\n          <div class=\"col-12 centered\">\n            <input id=\"vote-now\" type=\"submit\" value=\"VOTE NOW!\" />\n          </div>\n      </div>\n\n      <div id=\"vote-count-container\" class=\"row padded\">\n          <div class=\"col-12 centered\">\n            <h4>Administrative Use Only</h4>\n            <input id=\"vote-count\" type=\"submit\" value=\"COUNT VOTES!\" />\n            <input id=\"vote-redeemer\" type=\"submit\" value=\"REDEEM BALLOTS!\" disabled />\n          </div>\n      </div>\n\n      <div id=\"vote-count-output\" class=\"row padded\">\n          Vote results will appear here...\n      </div>\n\n      <div id=\"vote-burn-container\" class=\"row padded\">\n          <div class=\"col-12 centered\">\n            <h4>Done With Your Ballots? Want to Reclaim Your Ada?</h4>\n            <input id=\"vote-burn\" type=\"submit\" value=\"BURN YOUR COUNTED VOTES!\" />\n          </div>\n      </div>\n    </div>\n  </body>\n\n  <script type=\"module\">\n    NftToolkit.then(NftToolkit => {\n      NftToolkit.CardanoDAppJs.initializeCardanoDApp('wallet-container');\n\n      const blockfrostKey = \"<A VALID BLOCKFROST KEY GOES HERE>\";\n      const policyId = \"<THE POLICY ID OF THE PROJECT'S NFT GOES HERE>\";\n      const pollsClose = -1; // THE UNIX TIMESTAMP (MS) POLLS CLOSE GOES HERE\n      const ballotPrefix = '<THE BALLOT LABEL PREFIX GOES HERE>';\n      const pubKeyHash = '<THE PUBLIC KEY HASH OF THE VOTE COUNTER GOES HERE>';\n      const ballotMetadata = {\n        \"image\": \"ipfs://\",\n        \"mediaType\": \"image/png\",\n        \"description\": [\n          \"Commemorative NFT for on-chain vote \",\n          \"(Metadata for convenience, final votes recorded using datums)\"\n        ],\n        \"project\": \"Sample Ballot - NFT Project\"\n      }\n\n      const ballotDomName = 'vote-ballot-choice';\n      const voteOutputDom = 'vote-count-output';\n\n      document.getElementById(\"vote-ballot-form\").addEventListener('submit', e => false);\n\n      document.getElementById('vote-now').addEventListener('click', async e => {\n        e && e.preventDefault();\n        await NftToolkit.Voting.mintBallot(blockfrostKey, pubKeyHash, policyId, pollsClose, ballotDomName, ballotPrefix, ballotMetadata);\n      });\n\n      document.getElementById('vote-count').addEventListener('click', async e => {\n        e && e.preventDefault();\n        const ballots = await NftToolkit.Voting.countBallots(blockfrostKey, pubKeyHash, policyId, pollsClose, voteOutputDom, ballotPrefix);\n        if (ballots) {\n          window.open(`data:application/txt,${encodeURIComponent(ballots)}`);\n          document.getElementById('vote-redeemer').disabled = false;\n        }\n      });\n\n      document.getElementById('vote-redeemer').addEventListener('click', async e => {\n        e && e.preventDefault();\n        const ballots = await NftToolkit.Voting.redeemBallots(blockfrostKey, pubKeyHash, policyId, pollsClose, voteOutputDom, ballotPrefix);\n      });\n\n      document.getElementById('vote-burn').addEventListener('click', async e => {\n        e && e.preventDefault();\n        await NftToolkit.Voting.burnBallots(blockfrostKey, pubKeyHash, policyId, pollsClose, ballotPrefix);\n      });\n\n      window.addEventListener(\"message\", async (event) => {\n        // We only accept messages from ourselves\n        if (event.source != window || !event.data.type) {\n          return;\n        }\n        switch (event.data.type) {\n          case \"CARDANO_DAPP_JS_CONNECT\":\n            document.getElementById(\"wallet-voting-power\").innerHTML = 'Loading voting power from your wallet, please wait...';\n            const votingPower = await NftToolkit.Voting.votingAssetsAvailable(blockfrostKey, [policyId], []);\n            const votingMsg = (votingPower < 0) ? 'Could not calculate voting power due to wallet error.' : `Your ballot choice below will have ${votingPower} votes' power`;\n            document.getElementById(\"wallet-voting-power\").innerHTML = `<h4>${votingMsg}</h4>`;\n            document.querySelectorAll(\"input\").forEach(input => { input.disabled = false});\n            break;\n          default:\n            // Unknown message, return\n            break;\n        }\n      }, false);\n    })\n  </script>\n\n</html>\n"
  },
  {
    "path": "CIP-0071/example/voting.js",
    "content": "import * as helios from '@hyperionbt/helios';\n\nimport {Data, fromHex, toHex, getAddressDetails} from 'lucid-cardano';\n\n// These modules are imported from https://github.com/thaddeusdiamond/cardano-nft-mint-frontend\n// but elided in the source code of the CIP for space\nimport * as CardanoDAppJs from '../third-party/cardano-dapp-js.js';\nimport * as LucidInst from '../third-party/lucid-inst.js';\nimport * as NftPolicy from \"../nft-toolkit/nft-policy.js\";\nimport {shortToast} from '../third-party/toastify-utils.js';\nimport {validate, validated} from '../nft-toolkit/utils.js';\n\nconst BURN_REDEEMER = 'd87a80';\nconst MAX_NFTS_TO_MINT = 20;\nconst MAX_ATTEMPTS = 12;\nconst OPTIMIZE_HELIOS = true;\nconst SINGLE_NFT = 1n;\nconst TEN_MINS = 600000;\nconst TXN_WAIT_TIMEOUT = 15000;\n\nfunction getVoteCounterSourceCode(pubKeyHash) {\n  return `\n    spending vote_counter\n\n    const EXPECTED_SIGNER: PubKeyHash = PubKeyHash::new(#${pubKeyHash})\n\n    func main(ctx: ScriptContext) -> Bool {\n      ctx.tx.is_signed_by(EXPECTED_SIGNER)\n    }\n  `;\n}\n\nfunction getBallotSourceCodeStr(referencePolicyId, pollsClose, pubKeyHash, ballotPrefix) {\n  return `\n    minting voting_ballot\n\n    const BALLOT_BOX_PUBKEY: ValidatorHash = ValidatorHash::new(#${pubKeyHash})\n    const BALLOT_NAME_PREFIX: ByteArray = #${ballotPrefix}\n    const POLLS_CLOSE: Time = Time::new(${pollsClose})\n    const REFERENCE_POLICY_HASH: MintingPolicyHash = MintingPolicyHash::new(#${referencePolicyId})\n\n    enum Redeemer {\n      Mint\n      Burn\n    }\n\n    func assets_locked_in_script(tx: Tx, minted_assets: Value) -> Bool {\n      //print(tx.value_sent_to(BALLOT_BOX_PUBKEY).serialize().show());\n      //print(minted_assets.serialize().show());\n      ballots_sent: Value = tx.value_locked_by(BALLOT_BOX_PUBKEY);\n      assets_locked: Bool = ballots_sent.contains(minted_assets);\n      if (assets_locked) {\n        true\n      } else {\n        print(\"Minted ballots (\" + minted_assets.serialize().show() + \") were not correctly locked in the script: \" + ballots_sent.serialize().show());\n        false\n      }\n    }\n\n    func assets_were_spent(minted: Value, policy: MintingPolicyHash, outputs: []TxOutput) -> Bool {\n      minted_assets: Map[ByteArray]Int = minted.get_policy(policy);\n      reference_assets_names: Map[ByteArray]Int = minted_assets.map_keys((asset_id: ByteArray) -> ByteArray {\n        asset_id.slice(BALLOT_NAME_PREFIX.length, asset_id.length)\n      });\n      reference_assets: Map[MintingPolicyHash]Map[ByteArray]Int = Map[MintingPolicyHash]Map[ByteArray]Int {\n        REFERENCE_POLICY_HASH: reference_assets_names\n      };\n      tx_sends_to_self: Bool = outputs.head.value.contains(Value::from_map(reference_assets));\n      if (tx_sends_to_self) {\n        true\n      } else {\n        print(\"The NFTs with voting power (\" + REFERENCE_POLICY_HASH.serialize().show() + \") for the ballots were never sent-to-self\");\n        false\n      }\n    }\n\n    func polls_are_still_open(time_range: TimeRange) -> Bool {\n      tx_during_polls_open: Bool = time_range.is_before(POLLS_CLOSE);\n      if (tx_during_polls_open) {\n        true\n      } else {\n        print(\"Invalid time range: \" + time_range.serialize().show() + \" (polls close at \" + POLLS_CLOSE.serialize().show() + \")\");\n        false\n      }\n    }\n\n    func main(redeemer: Redeemer, ctx: ScriptContext) -> Bool {\n      tx: Tx = ctx.tx;\n      minted_policy: MintingPolicyHash = ctx.get_current_minting_policy_hash();\n      redeemer.switch {\n        Mint => {\n          polls_are_still_open(tx.time_range)\n            && assets_were_spent(tx.minted, minted_policy, tx.outputs)\n            && assets_locked_in_script(tx, tx.minted)\n        },\n        Burn => {\n          tx.minted.get_policy(minted_policy).all((asset_id: ByteArray, amount: Int) -> Bool {\n            if (amount > 0) {\n              print(asset_id.show() + \" asset ID was minted not burned (quantity \" + amount.show() + \")\");\n              false\n            } else {\n              true\n            }\n          })\n        }\n      }\n    }\n  `;\n}\n\nfunction getCompiledCode(mintingSourceCode) {\n  return helios.Program.new(mintingSourceCode).compile(OPTIMIZE_HELIOS);\n}\n\nfunction getLucidScript(compiledCode) {\n  return {\n    type: \"PlutusV2\",\n    script: JSON.parse(compiledCode.serialize()).cborHex\n  }\n}\n\nfunction getBallotSelection(ballotDomName) {\n  return document.querySelector(`input[name=${ballotDomName}]:checked`)?.value;\n}\n\nasync function waitForTxn(lucid, blockfrostKey, txHash) {\n  for (var attempt = 0; attempt < MAX_ATTEMPTS; attempt++) {\n    const result = await fetch(`${lucid.provider.data.url}/txs/${txHash}`, {\n      headers: { project_id: blockfrostKey }\n    }).then(res => res.json());\n    if (result && !result.error) {\n      return;\n    }\n\n    if (attempt < (MAX_ATTEMPTS - 1)) {\n      await new Promise(resolve => setTimeout(resolve, TXN_WAIT_TIMEOUT));\n    }\n  }\n  throw `Could not retrieve voting txn after ${MAX_ATTEMPTS} attempts`;\n}\n\n\nexport async function mintBallot(blockfrostKey, pubKeyHash, policyId, pollsClose, ballotDomName, ballotPrefix, ballotMetadata) {\n  try {\n    const cardanoDApp = CardanoDAppJs.getCardanoDAppInstance();\n    validate(cardanoDApp.isWalletConnected(), 'Please connect a wallet before voting using \"Connect Wallet\" button');\n    const wallet = await cardanoDApp.getConnectedWallet();\n\n    const lucid = validated(await LucidInst.getLucidInstance(blockfrostKey), 'Please validate that your wallet is on the correct network');\n    lucid.selectWallet(wallet);\n    const voter = await lucid.wallet.address();\n\n    const voteCounterSourceCode = getVoteCounterSourceCode(pubKeyHash);\n    const voteCounterCompiledCode = getCompiledCode(voteCounterSourceCode);\n    const voteCounterScript = getLucidScript(voteCounterCompiledCode)\n    const voteCounter = lucid.utils.validatorToAddress(voteCounterScript);\n    const voteCounterPkh = getAddressDetails(voteCounter).paymentCredential.hash;\n\n    const ballotPrefixHex = toHex(new TextEncoder().encode(ballotPrefix));\n    const mintingSourceCode = getBallotSourceCodeStr(policyId, pollsClose, voteCounterPkh, ballotPrefixHex);\n    const mintingCompiledCode = getCompiledCode(mintingSourceCode);\n    const voteMintingPolicy = getLucidScript(mintingCompiledCode);\n    const voteMintingPolicyId = mintingCompiledCode.mintingPolicyHash.hex;\n\n    const vote = validated(getBallotSelection(ballotDomName), 'Please select your ballot choice!');\n    const voteDatum = {\n      inline: Data.to(Data.fromJson({ voter: voter, vote: vote }))\n    };\n\n    const votingAssets = await getVotingAssets([policyId], [], lucid);\n    const assetIds = Object.keys(votingAssets.assets);\n    var assetIdsChunked = [];\n    for (var i = 0; i < assetIds.length; i += MAX_NFTS_TO_MINT) {\n      assetIdsChunked.push(assetIds.slice(i, i + MAX_NFTS_TO_MINT));\n    }\n    if (assetIdsChunked.length > 1) {\n      validate(\n        confirm(`We will have to split your votes into ${assetIdsChunked.length} different transactions due to blockchain size limits, should we proceed?`),\n        \"Did not agree to submit multiple voting transactions\"\n      );\n    }\n\n    for (var i = 0; i < assetIdsChunked.length; i++) {\n      var mintAssets = {};\n      var referenceAssets = {};\n      var mintingMetadata = { [voteMintingPolicyId]: {}, version: NftPolicy.CIP0025_VERSION }\n      for (const assetId of assetIdsChunked[i]) {\n        const assetName = assetId.slice(56);\n        const ballotNameHex = `${ballotPrefixHex}${assetName}`;\n        const ballotName = new TextDecoder().decode(fromHex(ballotNameHex));\n        mintAssets[`${voteMintingPolicyId}${ballotNameHex}`] = SINGLE_NFT;\n        referenceAssets[`${policyId}${assetName}`] = SINGLE_NFT;\n        mintingMetadata[voteMintingPolicyId][ballotName] = Object.assign({}, ballotMetadata);\n        mintingMetadata[voteMintingPolicyId][ballotName].name = ballotName;\n        mintingMetadata[voteMintingPolicyId][ballotName].vote = vote;\n      }\n\n      const txBuilder = lucid.newTx()\n                             .addSigner(voter)\n                             .mintAssets(mintAssets, Data.empty())\n                             .attachMintingPolicy(voteMintingPolicy)\n                             .attachMetadata(NftPolicy.METADATA_KEY, mintingMetadata)\n                             .payToAddress(voter, referenceAssets)\n                             .payToContract(voteCounter, voteDatum, mintAssets)\n                             .validTo(new Date().getTime() + TEN_MINS);\n\n      const txComplete = await txBuilder.complete({ nativeUplc: false });\n      const txSigned = await txComplete.sign().complete();\n      const txHash = await txSigned.submit();\n      shortToast(`[${i + 1}/${assetIdsChunked.length}] Successfully voted in Tx ${txHash}`);\n      if (i < (assetIdsChunked.length - 1)) {\n        shortToast('Waiting for prior transaction to finish, please wait for pop-ups to complete your vote!');\n        await waitForTxn(lucid, blockfrostKey, txHash);\n      } else {\n        shortToast('Your vote(s) have been successfully recorded!');\n      }\n    }\n    return true;\n  } catch (err) {\n    shortToast(JSON.stringify(err));\n  }\n  return false;\n}\n\nasync function getVotingAssets(votingPolicies, exclusions, lucid) {\n  if (votingPolicies === undefined || votingPolicies === []) {\n    return {};\n  }\n  const votingAssets = {};\n  const utxos = [];\n  for (const utxo of await lucid.wallet.getUtxos()) {\n    var found = false;\n    for (const assetName in utxo.assets) {\n      if (!votingPolicies.includes(assetName.slice(0, 56))) {\n        continue;\n      }\n      if (exclusions.includes(assetName)) {\n        continue;\n      }\n      if (votingAssets[assetName] === undefined) {\n        votingAssets[assetName] = 0n;\n      }\n      votingAssets[assetName] += utxo.assets[assetName];\n      found = true;\n    }\n    if (found) {\n      utxos.push(utxo);\n    }\n  }\n  return { assets: votingAssets, utxos: utxos };\n}\n\nasync function walletVotingAssets(blockfrostKey, votingPolicies, exclusions) {\n  var cardanoDApp = CardanoDAppJs.getCardanoDAppInstance();\n  if (!cardanoDApp.isWalletConnected()) {\n    return {};\n  }\n\n  try {\n    const wallet = await cardanoDApp.getConnectedWallet();\n    const lucidInst = validated(LucidInst.getLucidInstance(blockfrostKey), 'Unable to initialize Lucid, network mismatch detected');\n\n    const lucid = validated(await lucidInst, 'Unable to initialize Lucid, network mismatch detected');\n    lucid.selectWallet(wallet);\n    return await getVotingAssets(votingPolicies, exclusions, lucid);\n  } catch (err) {\n    const msg = (typeof(err) === 'string') ? err : JSON.stringify(err);\n    shortToast(`Voting power retrieval error occurred: ${msg}`);\n    return {};\n  }\n}\n\nexport async function votingAssetsAvailable(blockfrostKey, votingPolicies, exclusions) {\n  const votingAssets = await walletVotingAssets(blockfrostKey, votingPolicies, exclusions);\n  if (votingAssets.assets) {\n    const remainingVotingBigInt =\n      Object.values(votingAssets.assets)\n            .reduce((partialSum, a) => partialSum + a, 0n);\n    return Number(remainingVotingBigInt);\n  }\n  return -1;\n}\n\nexport async function countBallots(blockfrostKey, pubKeyHash, policyId, pollsClose, voteOutputDom, ballotPrefix) {\n  try {\n    const cardanoDApp = CardanoDAppJs.getCardanoDAppInstance();\n    validate(cardanoDApp.isWalletConnected(), 'Please connect a wallet before voting using \"Connect Wallet\" button');\n    const wallet = await cardanoDApp.getConnectedWallet();\n\n    const lucid = validated(await LucidInst.getLucidInstance(blockfrostKey), 'Please validate that your wallet is on the correct network');\n    lucid.selectWallet(wallet);\n    const oracle = await lucid.wallet.address();\n\n    const voteCounterSourceCode = getVoteCounterSourceCode(pubKeyHash);\n    const voteCounterCompiledCode = getCompiledCode(voteCounterSourceCode);\n    const voteCounterScript = getLucidScript(voteCounterCompiledCode)\n    const voteCounter = lucid.utils.validatorToAddress(voteCounterScript);\n    const voteCounterPkh = getAddressDetails(voteCounter).paymentCredential.hash;\n\n    const ballotPrefixHex = toHex(new TextEncoder().encode(ballotPrefix));\n    const mintingSourceCode = getBallotSourceCodeStr(policyId, pollsClose, voteCounterPkh, ballotPrefixHex);\n    const mintingCompiledCode = getCompiledCode(mintingSourceCode);\n    const mintingPolicyId = mintingCompiledCode.mintingPolicyHash.hex;\n\n    var voteAssets = {};\n    const votes = await lucid.utxosAt(voteCounter);\n    for (const vote of votes) {\n      const voteResult = Data.toJson(Data.from(vote.datum));\n      for (const unit in vote.assets) {\n        if (!unit.startsWith(mintingPolicyId)) {\n          continue;\n        }\n        const voteCount = Number(vote.assets[unit]);\n        voteAssets[unit] = {\n          voter: voteResult.voter,\n          vote: voteResult.vote,\n          count: voteCount\n        }\n      }\n    }\n\n    const votePrinted = JSON.stringify(voteAssets, undefined, 4);\n    document.getElementById(voteOutputDom).innerHTML =\n     `<pre style=\"text-align: start\">${JSON.stringify(voteAssets, undefined, 4)}</pre>`;\n    return votePrinted;\n  } catch (err) {\n    shortToast(JSON.stringify(err));\n  }\n}\n\nexport async function redeemBallots(blockfrostKey, pubKeyHash, policyId, pollsClose, voteOutputDom, ballotPrefix) {\n  try {\n    const cardanoDApp = CardanoDAppJs.getCardanoDAppInstance();\n    validate(cardanoDApp.isWalletConnected(), 'Please connect a wallet before voting using \"Connect Wallet\" button');\n    const wallet = await cardanoDApp.getConnectedWallet();\n\n    const lucid = validated(await LucidInst.getLucidInstance(blockfrostKey), 'Please validate that your wallet is on the correct network');\n    lucid.selectWallet(wallet);\n    const oracle = await lucid.wallet.address();\n\n    const voteCounterSourceCode = getVoteCounterSourceCode(pubKeyHash);\n    const voteCounterCompiledCode = getCompiledCode(voteCounterSourceCode);\n    const voteCounterScript = getLucidScript(voteCounterCompiledCode)\n    const voteCounter = lucid.utils.validatorToAddress(voteCounterScript);\n    const voteCounterPkh = getAddressDetails(voteCounter).paymentCredential.hash;\n\n    const ballotPrefixHex = toHex(new TextEncoder().encode(ballotPrefix));\n    const mintingSourceCode = getBallotSourceCodeStr(policyId, pollsClose, voteCounterPkh, ballotPrefixHex);\n    const mintingCompiledCode = getCompiledCode(mintingSourceCode);\n    const mintingPolicyId = mintingCompiledCode.mintingPolicyHash.hex;\n\n    var voterRepayments = {};\n    const votesToCollect = [];\n    const votes = await lucid.utxosAt(voteCounter);\n    for (const vote of votes) {\n      const voteResult = Data.toJson(Data.from(vote.datum));\n      var hasVote = false;\n      for (const unit in vote.assets) {\n        if (!unit.startsWith(mintingPolicyId)) {\n          continue;\n        }\n        hasVote = true;\n        const voteCount = Number(vote.assets[unit]);\n        if (!(voteResult.voter in voterRepayments)) {\n          voterRepayments[voteResult.voter] = {}\n        }\n        voterRepayments[voteResult.voter][unit] = voteCount;\n      }\n\n      if (hasVote) {\n        votesToCollect.push(vote);\n      }\n    }\n\n    const txBuilder = lucid.newTx()\n                           .addSigner(oracle)\n                           .collectFrom(votesToCollect, Data.empty())\n                           .attachSpendingValidator(voteCounterScript);\n    for (const voter in voterRepayments) {\n      txBuilder.payToAddress(voter, voterRepayments[voter]);\n    }\n    const txComplete = await txBuilder.complete({ nativeUplc: false });\n    const txSigned = await txComplete.sign().complete();\n    const txHash = await txSigned.submit();\n    shortToast(`Successfully counted ballots in ${txHash}`);\n  } catch (err) {\n    shortToast(JSON.stringify(err));\n  }\n}\n\nexport async function burnBallots(blockfrostKey, pubKeyHash, policyId, pollsClose, ballotPrefix) {\n  try {\n    const cardanoDApp = CardanoDAppJs.getCardanoDAppInstance();\n    validate(cardanoDApp.isWalletConnected(), 'Please connect a wallet before voting using \"Connect Wallet\" button');\n    const wallet = await cardanoDApp.getConnectedWallet();\n\n    const lucid = validated(await LucidInst.getLucidInstance(blockfrostKey), 'Please validate that your wallet is on the correct network');\n    lucid.selectWallet(wallet);\n    const voter = await lucid.wallet.address();\n\n    const voteCounterSourceCode = getVoteCounterSourceCode(pubKeyHash);\n    const voteCounterCompiledCode = getCompiledCode(voteCounterSourceCode);\n    const voteCounterScript = getLucidScript(voteCounterCompiledCode)\n    const voteCounter = lucid.utils.validatorToAddress(voteCounterScript);\n    const voteCounterPkh = getAddressDetails(voteCounter).paymentCredential.hash;\n\n    const ballotPrefixHex = toHex(new TextEncoder().encode(ballotPrefix));\n    const mintingSourceCode = getBallotSourceCodeStr(policyId, pollsClose, voteCounterPkh, ballotPrefixHex);\n    const mintingCompiledCode = getCompiledCode(mintingSourceCode);\n    const mintingPolicy = getLucidScript(mintingCompiledCode);\n    const mintingPolicyId = mintingCompiledCode.mintingPolicyHash.hex;\n\n    const utxos = await lucid.wallet.getUtxos();\n    const utxosToCollect = [];\n    const mintAssets = {};\n    var hasAlerted = false;\n    for (const utxo of utxos) {\n      var foundAsset = false;\n      for (const unit in utxo.assets) {\n        if (unit.startsWith(mintingPolicyId)) {\n          if (Object.keys(mintAssets).length >= MAX_NFTS_TO_MINT) {\n            if (!hasAlerted) {\n              alert(`Can only burn ${MAX_NFTS_TO_MINT} ballots to burn at a time.  Start with that, then click this button again.`);\n              hasAlerted = true;\n            }\n            break;\n          }\n          foundAsset = true;\n          if (!(unit in mintAssets)) {\n            mintAssets[unit] = 0n;\n          }\n          mintAssets[unit] -= utxo.assets[unit];\n        }\n      }\n\n      if (foundAsset) {\n        utxosToCollect.push(utxo);\n      }\n    }\n\n    const txBuilder = lucid.newTx()\n                           .addSigner(voter)\n                           .collectFrom(utxosToCollect)\n                           .mintAssets(mintAssets, BURN_REDEEMER)\n                           .attachMintingPolicy(mintingPolicy)\n                           .validTo(new Date().getTime() + TEN_MINS);\n    const txComplete = await txBuilder.complete({ nativeUplc: false });\n    const txSigned = await txComplete.sign().complete();\n    const txHash = await txSigned.submit();\n    shortToast(`Successfully burned your ballots in ${txHash}`);\n  } catch (err) {\n    shortToast(JSON.stringify(err));\n  }\n}\n"
  },
  {
    "path": "CIP-0072/README.md",
    "content": "---\nCIP: 72\nTitle: Cardano dApp Registration & Discovery\nStatus: Proposed\nCategory: Metadata\nAuthors: \n  - Bruno Martins <bruno.martins@iohk.io>\n  - Mateusz Czeladka <mateusz.czeladka@cardanofoundation.org>\n  - Daniel Main <daniel.main@iohk.io>\nImplementors: [\"Lace Wallet dApp Store\", \"DappsOnCardano dApp Store\"]\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/355\nCreated: 2022-10-18\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\ndApp developers do not have a standardised method to record immutable, persistent claims about their dApp(s) that their users can verify. A dApp developer needs to \"register\" their dApp by providing a set of claims about their dApp(s) that can be verified by the user. This CIP describes a standardised method for dApp developers to register their dApp(s) on-chain and for users to verify the claims made by dApp developers.\n\nThis proposal aims to standardise the process of dApp registration and verification, and to provide a set of claims that dApp developers can use to register their dApp(s).\n\n## Motivation: why is this CIP necessary?\n\ndApps can express a plethora of information. Some of this information could be claims about who the developer is, what the dApp's associated metadata is, and more. This data lacks standardisation, persistence, and immutability. Data without these features, means that dApp users cannot verify if the dApp's expressed information is consistent across time. The goal of this CIP is to formalise how dApps register their information with a new transaction metadata format that can record the dApp's metadata, ownership, and potentially developer's identity. This formalisation means dApp users can verify if the data expressed by a dApp is consistent with what was registered on-chain.\n\nAlso, having this formalisation facilitates any actor in the ecosystem to index and query this data, and provide a better user experience when it comes to dApp discovery and usage.\n\n## Specification\n\n### **Definitions**\n\n- **anchor** - A hash written on-chain (rootHash) that can be used to verify the integrity (by way of a cryptographic hash) of the data that is found off-chain.\n- **dApp** - A decentralised application that is described by the combination of metadata, certificate and a set of used scripts.\n- **metadata claim** - Generically any attempt to map off-chain metadata to an on-chain subject. This specification looks at dApp specific metadata claims. Caution: it is highly recommended that dApp developers provide links to a specific snapshot (version) without removing all previous snapshots / version links. Some stores may choose not to show a dApp if all off-chain historical versions are not available but instead only latest snapshot. \n- **client** - Any ecosystem participant which follows on-chain data to consume metadata claims (i.e. dApp stores, wallets, auditors, block explorers, etc.).\n- **dApp Store** - A dApp aggregator application which follows on-chain data looking for and verifying dApp metadata claims, serving their users linked dApp metadata.\n- **publishers** - Entities which publish metadata claims on-chain, in the case of dApps the publishers are likely the dApp developer(s). \n\n### **Developers / Publishers**\n\nDevelopers and publishers of dApps can register their dApps by submitting a transaction on-chain that can be indexed and verified by stores, auditors and other ecosystem actors.\n\n### **Stores / Auditors**\n\nStores and auditors should be able to follow the chain and find when a new dApp registration is **anchored** on-chain. They should then perform *integrity* and *trust* validations on the dApp's certificate and metadata.\n\n#### **Suggested Validations**\n\n- **`integrity`**: The dApp's off-chain metadata should match the metadata **anchored** on-chain.\n- **`trust`**: The dApp's certificate should be signed by a trusted entity. It's up to the store/auditor to decide which entities are trusted and they should maintain and publish their own list of trusted entities. Although this entities might be well known, it's not the responsibility of this CIP to maintain this list. These entities could be directly associated with developer/publisher or not.\n\n### **On-chain dApp Registration**\n\n```json\n{\n  \"subject\": \"b37aabd81024c043f53a069c91e51a5b52e4ea399ae17ee1fe3cb9c44db707eb\",\n  \"rootHash\": \"7abcda7de6d883e7570118c1ccc8ee2e911f2e628a41ab0685ffee15f39bba96\",\n  \"metadata\": [\n    \"https://foundation.app/my_dapp_7abcda/tart/\",\n    \"7abcda7de6d883e7570118c1ccc8ee2e91\",\n    \"e4ea399ae17ee1fe3cb9c44db707eb/\",\n    \"offchain.json\"\n  ],\n  \"type\": {\n    \"action\": \"REGISTER\",\n    \"comment\": \"New release adding zapping support.\"\n  }\n}\n```\n\n### Properties\n\n*`subject`*: Identifier of the claim subject (dApp). A UTF-8 encoded string, max 64 chars. The uniqueness of this property cannot be guaranteed by the protocol and multiple claims for the same subject may exist, therefore it is required to exist some mechanism to assert trust in the *veracity* of this property.\n\n*`type`*: The type of the claim. This is a JSON object that contains the following properties: \n\n- *`action`*: The action that the certificate is asserting. It can take the following values: \n  - *`REGISTER`*: The certificate is asserting that the dApp is registered for the first time or is providing an update.\n  - *`DE_REGISTER`*: The certificate is asserting that the dApp is deprecated / archived. So, no further dApp's on-chain update is expected.\n\n*`rootHash`*: The blake2b-256 hash of the entire offchain metadata tree object. This hash is used by clients to verify the integrity of the metadata tree object. When reading a metadata tree object, the client should calculate the hash of the object and compare it with the `rootHash` property. If the two hashes don't match, the client should discard the object. The metadata tree object is a JSON object that contains the dApp's metadata. The metadata tree object is described in the next section. Please note that off-chain JSON must be converted into RFC 8765 canonical form before taking the hash!\n\n*`metadata`*: Chunks of URLs that make up the dApp's metadata are arranged in an array to accommodate the 64-character limit per chunk, allowing for the support of longer URLs. The metadata itself is a JSON object compatible with RFC 8785, containing detailed information about the dApp\n\n### On-chain Schemas\n\n[On-chain CDDL for registration / de-registration (Version 2.0.0)](./version_2.0.0_onchain.cddl)\n\nwhich also can be expressed using JSON schema:\n\n[dApp on-chain certificate JSON Schema (Version 2.0.0)](./version_2.0.0_onchain.json)\n\n### Metadata Label\n\nWhen submitting the transaction metadata pick the following value for `transaction_metadatum_label`:\n\n- `1667`: dApp Registration\n\n### Off-chain Metadata Format\n\nThe dApp Registration certificate itself doesn't enforce a particular structure to the metadata you might fetch off-chain. However, we recommend that you use the following structure:\n\n[Off-chain dApp Registration certificate schema (Version 2)](./version_2.0.0_offchain.json)\n\nThis schema describes the minimum required fields for a store to be able to display and validate your dApp.\n\n### Example\n\n```json\n{\n  \"version\": \"1.0.0\",\n  \"subject\": \"abcdef1234567890\",\n  \"projectName\": \"My dApp\",\n  \"link\": \"https://www.exampledapp.com\",\n  \"companyName\": \"Amazing dApp Inc.\",\n  \"companyEmail\": \"contact@myamazingdapp.com\",\n  \"companyWebsite\": \"https://www.myamazingdapp.com\",\n  \"logo\": \"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAUAAA...\",\n  \"categories\": [\"DeFi\", \"Games\"],\n  \"screenshots\": [\n    \"data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD...\",\n    \"data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEASABIAAD...\"\n  ],\n  \"social\": [\n    {\n      \"name\": \"GitHub\",\n      \"link\": \"https://github.com/exampledapp\"\n    },\n    {\n      \"name\": \"Twitter\",\n      \"link\": \"https://twitter.com/exampledapp\"\n    }\n  ],\n  \"description\": {\n    \"short\": \"This is a short description of the dApp, giving an overview of its features and capabilities.\"\n  },\n  \"releases\": [\n    {\n      \"releaseNumber\": \"1.0.0\",\n      \"releaseName\": \"Initial Release\",\n      \"securityVulnerability\": false,\n      \"comment\": \"First major release with all core features.\",\n      \"scripts\": [\n        {\n          \"id\": \"script1\",\n          \"version\": \"1.0.0\"\n        }\n      ]\n    }\n  ],\n  \"scripts\": [\n    {\n      \"id\": \"script1\",\n      \"name\": \"Example Script\",\n      \"purposes\": [\"SPEND\", \"MINT\"],\n      \"type\": \"PLUTUS\",\n      \"versions\": [\n        {\n          \"version\": \"1.0.0\",\n          \"plutusVersion\": 1,\n          \"scriptHash\": \"abc123\"\n        }\n      ]\n    }\n  ]\n}\n```\n\n### **Stores Custom fields**\n\nEach store might have their own requirements for the metadata. For example, some stores might require a field for logo, or screenshots links. The store's should adviertise what fields they require in their documentation so that developers are aware and they can include them in the metadata. \n\n### **Offchain Metadata Storage**\n\nThere are multiple options to store metadata offchain. The most common options are:\n\n- [CIP-26](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0026) compliant servers\n- [IPFS](https://ipfs.tech/)\n- [Bitbucket](https://bitbucket.org/)\n- Any REST JSON API\n\n## Rationale: how does this CIP achieve its goals?\n\n### Decoupling of dApp Registration From Certifications / Audits\n\nWe quickly reached a conclusion that it is better to separate them and keep scope of CIP smaller. During discussions it became clear that while there is\nsome overlap of certifications / audits with dApp registration, this overlap is small and can be even removed. At one point we wanted to couple \ncertifications CIP to this CIP (e.g. via some link or dApp version) but we analyzed how dApp developers are currently following the process and we noticed\nthat in many cases certification / audit comes before an official dApp release on main-net. Having established it, we removed this link and not only\nthat dApp registration and certifications are different CIPs but they are very loosely coupled. Loose coupling has also disadvantages as it leads to a situation that in order to attest that a dApp is certified / audited, implementators will have to scan for all script hashes belonging to a dApp and check\nwhether those have been certified / explicitly mentioned in the audit.\n\n### Small Metadata Anchor On Chain\n\nThis one is rather obvious but for the sake of completeness worth documenting. We analyzed how much we should put on-chain vs off-chain and we quickly reached the conclusion that it is better to keep small amount of data on-chain and larger chunk off-chain for which is what exactly CIP-26 is meant for.\n\n### CIP-26 as *ONE* of Storage Layers\n\nWe believe that CIP-26 is geared towards storing this type of off-chain metadata format but we don't want by any means to stipulate / police this form of storage. In fact it is possible to use offchain metadata storage alternatives such as CIP-26 compatible server / direct http(s) hosting / IPFS, etc.\n\n### How to Find Off-Chain Data?\n\nWe went back and forth whether we should actually store link (links) to off-chain metadata, eventually we settled on a solution that this is required\nbecause there could be a situation that a dApp registration may have off-chain metadata stored somewhere but some stores have it, others don't have it. Now it is required that a dApp developer points to at least one store that has off-chain metadata (as a reference metadata).\n\n### Optional Release Name?\n\nRelease Name is a field, which dApp developers can use on top of Release Version, it has been debated whether field should be mandatory or optional but eventually it has been agreed that we do not want to enforce this field, Release Name is an optional field, Release Version, however, needs to follow semver and is a mandatory field.\n\n### Canonical JSON\n\nAt the begining neither on-chain, nor off-chain JSON has been following RFC 8785 (canonical JSON) but we reached a point that, due to consistency checks, we need to take hash of both on-chain and off-chain and this forced us to stipulate that both on-chain and off-chain metadata documents need to be converted\naccording to RFC 8785 before taking a blake2b-256 hash of them.\n\n### Transaction Signature Scope\n\nAs any transaction in cardano network has a signature, which has a role to verify that a certain dApp owner made changes.\n\n### Who Is The Owner?\n\nSmart contracts are ownerless, it has been debated that there could be multiple claims to the same dApps from different parties.\n\nThe standard doesn't prevent anyone from making a claim, so it's up to the different operator to their diligence work and make their own choices of whom they trust. The signature should give the most confidence as anyone can collect known public keys from known development companies. Future CIP revisions can include DID's and Verifiable Credentials to tackle this problem in a more elegant way.\n\n### DIDs\n\nSince DIDs / Verifiable Credetials are not yet widely used in Cardano ecosystem, usage of them in this initial CIP version has been de-scoped.\n\n### Categories\n\n`Categories` is a predefined enum with values defined in the CIP / schema, it is *NOT* a free text field, rationale for this is that dApp developers will have no idea what ontology / classification to use, which will likely result in many duplicates of the same thing.\n\n### Purpose Field As an Array or as a Single Item?\n\nIt may have been visible that we have a `purpose` field, which can be: \"SPEND\" or \"MINT\", those fields directly map to what is allowed by a Cardano Smart Contract. As of the time of writing CIP - PlutusTx does not allow a script to be both of type: \"SPEND\" and \"MINT\", however, there are new\nlanguages on Cardano being worked on where they already allow one validator to be both spending UTxOs and minting tokens - all with the same script hash. To be open for the future it has been agreed to turn `purpose` field into `purposes` and make it a JSON array.\n\n### Parametrised Scripts\n\nOn Cardano, there are parametrised scripts, meaning that before compilation takes place, it is possible to pass certain parameters instead of using `Datum`.\nThe consequence of this will be that as we pass different parameters, script hash will be changing. This is especially troublesome for things like certifications / audits but also dApp registration. This topic is being debated as part of CIP: https://github.com/cardano-foundation/CIPs/pull/385, however, it doesn't seem that there has been conclusion how to tackle this problem. For the moment, a new script hash (despite changing only a parameter) requires a re REGISTRATION to the existing dApp with a requirement to add new version(s) in the dApp's off-chain metadata.\n\n### Often Changing Scripts\n\nThere are cases on Cardano main-net that script hashes are changing every day, most probably due to parameterised scripts. It is responsibility of the developers to issue an `REGISTRATION` command and provide on-chain and off-chain metadata following the change, for scripts that are changing daily / hourly it is envisaged that this process be automated by a dApp developer.\n\n### Beacon Tokens Instead of Metadata\n\nIt has been argued that since anybody can make claims to dApps, this CIP instead of using metadata should use tokens. dApp developers\nwould mint token, which would ensure they are the owners of a given dApp. It is a certainly an interesting approach but shortcomings \nof the current solution can also be lifted by moving to DID based system and benefit of metadata is that it is easily queriable off chain\nand currently stores can attest / validate multiple claims for the same dApp. Forcing dApp developers to MINT tokens would complicate this CIP\nand potentially hinder it's adoption.\n\n### Datums Instead of Metadata \n\nIt has been suggested that we do not use metadata but rather Datums. Metadata cannot enforce format and Datums could. It has been rejected as\nusing Datums requires a smart contract and we want to keep this solution as accessible as possible. It is a GUI concern since if there is a \nsome app that can attest validity and conformance to JSON schema - dApp Registration / Update MUST never be done that does not conform to the schema.\n\n### Scripts / Releases Fields Are Not Required\n\nWe made a decision to change the schema so that scripts and releases are no longer required. This could help to get initial registration from dApp developers faster and some stores simply do not require dApps to add their scripts in order to be listed.\n\n### Tags\n\nWe briefly discussed tags and we will likely introduce tags in the future. An array of tags to help stores / dApp developers categories where their dApp should show. This will complement `categories` field.\n\n### DE_REGISTER\n\nWe added DE_REGISTER in additon to already existing `REGISTER`. The idea is that once dApp devs want to deprecate dApp they can now issue DE_REGISTER request.\n\n### Type Field\n\n`Type` field can be `PLUTUS` or `NATIVE`, we made it optional and there are already two dApps at least on Cardano at the time of writing, which are only using NATIVE scripts. This optional field helps to differentiante between NATIVE script based and NON_NATIVE dApps.\n\n### Version Deprecation\n\nWe discussed scenario what to do in case a dApp team wants to deprecate a particular version. Upon a few iteration we settled on doing this in off-chain section.\n\n### Version Security Vulnerability Flagging\n\nIt is not uncommon to see a dApp release a version and then release a fix in the new version and flag the previous version\nas having security vulnerability. We are intoducing an optional field in the offchain json on the release level: `securityVulnerability\": true.\n\n### Comment Field (on-chain JSON)\n\nWe are introducing a field in the on-chain JSON only, which allows dApp development teams to provide a free text field\ncomment about changes they are making in a given (re-)registration request.\n\n## Path to Active\n\nWe will evaluate for a few months if we have not missed any details, collect feedback from dApp developers, stores. We reserve right to make small changes in this time, while the proposal is in the `PROPOSED` status / state.\nOnce `Acceptance Criteria` are met and all comments / feedback from dApp developers is addressed, we will update the proposal to be in `ACTIVE` state.\n\n### Acceptance Criteria\n\n- At least 3 non trivial dApps from 3 different teams register on-chain / off-chain via following this CIP\n- At least one Implementator (main-net) implements the store indexing this CIP metadata from on-chain\n\n### Implementation Plan\n\n- DappsOnCardano dApp Store: https://github.com/Cardano-Fans/crfa-dapp-registration-and-certification-service for DappsOnCardano.com\n- Lace's Wallet dApp Store: https://github.com/input-output-hk/lace\n\n## Copyright\n\n[CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n"
  },
  {
    "path": "CIP-0072/version_2.0.0_offchain.json",
    "content": "{\n    \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n    \"type\":\"object\",\n    \"properties\": {\n      \"version\": {\n        \"type\": \"string\",\n        \"pattern\": \"^(0|[1-9]\\\\d*)\\\\.(0|[1-9]\\\\d*)\\\\.(0|[1-9]\\\\d*)(?:-([0-9A-Za-z-]+(?:\\\\.[0-9A-Za-z-]+)*))?(?:\\\\+([0-9A-Za-z-]+(?:\\\\.[0-9A-Za-z-]+)*))?$\",\n        \"description\": \"Off-chain schema version following Semantic Versioning\"\n      },\n      \"subject\": {\n        \"type\":\"string\",\n        \"minLength\": 1,\n        \"maxLength\": 64,\n        \"pattern\":\"^[0-9a-fA-F]{1,64}$\",\n        \"description\": \"A subject, it must match with subject stored on chain data. A UTF-8 encoded string, 1 - 64 chars.\"\n      },\n      \"projectName\": {\n        \"type\":\"string\",\n        \"description\": \"A project name, e.g. My dApp.\",\n        \"maxLength\": 40\n      },\n      \"link\": {\n        \"type\":\"string\",\n        \"description\": \"A link a dApp or a website presenting a DApp\",\n        \"pattern\": \"((https?|ipfs|ipns):\\/\\/[\\\\u00C0-\\\\u017F-a-zA-Z0-9])\",\n        \"maxLength\": 200\n      },\n      \"companyName\": {\n        \"type\":\"string\",\n        \"description\": \"Company name\",\n        \"maxLength\": 100\n      },\n      \"companyEmail\": {\n        \"type\":\"string\",\n        \"description\": \"Contact email of the company behind the dApp\",\n        \"pattern\": \"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\\\.[a-zA-Z]{2,}$\",\n        \"maxLength\": 200\n      },\n      \"companyWebsite\": {\n        \"type\":\"string\",\n        \"description\": \"Website of the company behind the dApp.\",\n        \"pattern\": \"((https?|ipfs|ipns):\\/\\/[\\\\u00C0-\\\\u017F-a-zA-Z0-9])\",\n        \"maxLength\": 200\n      },\n      \"logo\": {\n        \"description\": \"Logo encoded in base64. Minimum resolution: 512x512px, supported formats: PNG/JPG/SVG, maximum file size: 1 MB\",\n        \"type\": \"string\",\n        \"contentEncoding\": \"base64\",\n        \"oneOf\": [\n          {\n            \"contentMediaType\": \"image/png\"\n          },\n          {\n            \"contentMediaType\": \"image/jpeg\"\n          },\n          {\n            \"contentMediaType\": \"image/svg+xml\"\n          }\n        ],\n        \"maxLength\": 1361000\n      },\n      \"categories\": {\n        \"type\":\"array\",\n        \"items\": {\n          \"type\": \"string\",\n          \"enum\": [\"DeFi\", \"Development\", \"Education\", \"Games\", \"Identity\", \"Marketplace\", \"NFT\", \"Other\", \"Security\"]\n        },\n        \"description\": \"One or more categories. Category MUST be one of the following schema definition.\"\n      },\n      \"screenshots\": {\n        \"type\": \"array\",\n        \"maxItems\": 10,\n        \"items\": {\n          \"description\": \"Screenshots encoded in base64. Minimum resolution for base64 images: 1920x1080px, supported formats: PNG/JPG/SVG, maximum file size: 2 MB for base64.\",\n          \"type\": \"string\",\n          \"contentEncoding\": \"base64\",\n          \"oneOf\": [\n            {\n              \"contentMediaType\": \"image/png\"\n            },\n            {\n              \"contentMediaType\": \"image/jpeg\"\n            },\n            {\n              \"contentMediaType\": \"image/svg+xml\"\n            }\n          ],\n          \"maxLength\": 2722000\n        },\n        \"description\": \"Screenshots of the DApp encoded in base64. We recommend to share screenshots from the dApp usage itself.\"\n      },\n      \"social\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"type\": \"object\",\n          \"properties\": {\n            \"name\": {\n              \"type\": \"string\",\n              \"description\": \"The platform or resource identifier (GitHub, Website, X.com, etc)\"\n            },\n            \"link\": {\n              \"type\": \"string\",\n              \"pattern\": \"((https?|ipfs|ipns):\\/\\/[\\\\u00C0-\\\\u017F-a-zA-Z0-9])\",\n              \"maxLength\": 200\n            }\n          }\n        }\n      },\n      \"description\": {\n        \"type\": \"object\",\n        \"properties\": {\n          \"short\": {\n            \"type\": \"string\",\n            \"description\": \"Short dApp description.\",\n            \"minLength\": 40,\n            \"maxLength\": 168\n          },\n          \"long\": {\n            \"type\": \"string\",\n            \"description\": \"An optional long dApp description.\",\n            \"minLength\": 40,\n            \"maxLength\": 1008\n          }\n        },\n        \"required\": [\n          \"short\",\n          \"long\"\n        ]\n      },\n      \"releases\": {\n        \"type\": \"array\",\n        \"items\": [\n          {\n            \"type\": \"object\",\n            \"properties\": {\n              \"releaseNumber\": {\n                \"type\": \"string\",\n                \"pattern\": \"^(0|[1-9]\\\\d*)\\\\.(0|[1-9]\\\\d*)\\\\.(0|[1-9]\\\\d*)(?:-([0-9A-Za-z-]+(?:\\\\.[0-9A-Za-z-]+)*))?(?:\\\\+([0-9A-Za-z-]+(?:\\\\.[0-9A-Za-z-]+)*))?$\",\n                \"description\": \"Semver compatible release number (major.minor.patch)\"\n              },\n              \"releaseName\": {\n                \"type\": \"string\",\n                \"description\": \"An optional human readable release name, e.g. V1\"\n              },\n              \"securityVulnerability\": {\n                \"type\": \"boolean\",\n                \"description\": \"Indicates that a given version has a security vulnerability.\"\n              },\n              \"comment\": {\n                \"type\": \"string\",\n                \"description\": \"A free text field to provide comment about this particular release, e.g. new features it brings, etc.\"\n              },\n              \"scripts\": {\n                \"type\": \"array\",\n                \"items\": [\n                  {\n                    \"type\": \"object\",\n                    \"properties\": {\n                      \"id\": {\n                        \"type\": \"string\"\n                      },\n                      \"version\": {\n                        \"type\": \"string\",\n                        \"pattern\": \"^(0|[1-9]\\\\d*)\\\\.(0|[1-9]\\\\d*)\\\\.(0|[1-9]\\\\d*)(?:-([0-9A-Za-z-]+(?:\\\\.[0-9A-Za-z-]+)*))?(?:\\\\+([0-9A-Za-z-]+(?:\\\\.[0-9A-Za-z-]+)*))?$\"\n                      }\n                    },\n                    \"required\": [\n                      \"id\",\n                      \"version\"\n                    ]\n                  }\n                ]\n              }\n            },\n            \"required\": [\n              \"releaseNumber\"\n            ]\n          }\n        ]\n      },\n      \"scripts\": {\n        \"type\": \"array\",\n        \"items\": [\n          {\n            \"type\": \"object\",\n            \"properties\":{\n              \"id\": {\n                \"type\":\"string\",\n                \"description\": \"Unique Script ID (across all scripts from this dApp).\"\n              },\n              \"name\":{\n                \"type\":\"string\",\n                \"description\": \"An optional script name usually related to it's function.\"\n              },\n              \"purposes\":{\n                \"type\":\"array\",\n                \"items\": {\n                  \"type\": \"string\",\n                  \"enum\":[\"SPEND\", \"MINT\"]\n                },\n                \"description\": \"Purpouses of the script, SPEND or MINT (notice it can be both for some modern Cardano languages).\"\n              },\n              \"type\":{\n                \"enum\":[\"PLUTUS\", \"NATIVE\"],\n                \"description\": \"Script Type. PLUTUS refers to the typical PlutusV1 or PlutusV2 scripts, where as NATIVE means there has been no Plutus directly used by this is a native script.\"\n              },\n              \"versions\":{\n                \"type\":\"array\",\n                \"items\":[\n                  {\n                    \"type\":\"object\",\n                    \"properties\":{\n                      \"version\": {\n                        \"type\": \"string\",\n                        \"pattern\": \"^(0|[1-9]\\\\d*)\\\\.(0|[1-9]\\\\d*)\\\\.(0|[1-9]\\\\d*)(?:-([0-9A-Za-z-]+(?:\\\\.[0-9A-Za-z-]+)*))?(?:\\\\+([0-9A-Za-z-]+(?:\\\\.[0-9A-Za-z-]+)*))?$\",\n                        \"description\": \"Script version following Semantic Versioning\"\n                      },\n                      \"plutusVersion\":{\n                        \"type\":\"integer\",\n                        \"enum\":[1, 2]\n                      },\n                      \"scriptHash\":{\n                        \"type\":\"string\",\n                        \"description\":\"Full on-chain script hash (hex).\",\n                        \"pattern\":\"[0-9a-fA-F]+\"\n                      },\n                      \"contractAddress\": {\n                        \"type\":\"string\",\n                        \"description\":\"An optional Bech32 contract address matching script's hash.\"\n                      }\n                    },\n                    \"required\": [\n                      \"version\",\n                      \"plutusVersion\",\n                      \"scriptHash\"\n                    ]\n                  }\n                ]\n              }\n            },\n            \"required\": [\n              \"id\",\n              \"purposes\",\n              \"type\",\n              \"versions\"\n            ]\n          }\n        ]\n      }\n    },\n    \"required\": [\n      \"subject\",\n      \"projectName\",\n      \"link\",\n      \"companyName\",\n      \"companyEmail\",\n      \"companyWebsite\",\n      \"social\",\n      \"logo\",\n      \"categories\",\n      \"screenshots\",\n      \"description\",\n      \"version\"\n    ],\n    \"additionalProperties\": false\n}\n"
  },
  {
    "path": "CIP-0072/version_2.0.0_onchain.cddl",
    "content": "string = bstr .size (1..64) ; tstr / string from 1 up to 64 chars only\n\nsig_256 = bstr .size (64..64) ; 256 bytes signature (256 / 64 = 4 bytes)\n\ntransaction_metadata = {\n  1667: on-chain_metadata\n}\n\non-chain_metadata = {\n  subject: string,\n  rootHash: sig_256,\n  metadata: [+ string] / [+ string / [+ string]],\n  type: registration / de-registration,\n}\n\nregistration = {\n  action: \"REGISTER\",\n  ? comment: string,\n}\n\nde-registration = {\n  action: \"DE_REGISTER\",\n  ? comment: string,\n}"
  },
  {
    "path": "CIP-0072/version_2.0.0_onchain.json",
    "content": "{\n    \"$schema\":\"https://json-schema.org/draft/2020-12/schema\",\n    \"$id\":\"https://example.com/dApp.schema.json\",\n    \"title\": \"Cardano dApp Claim\",\n    \"description\": \"Registration of Cardano dApp claim.\",\n    \"type\":\"object\",\n    \"properties\":{\n       \"subject\":{\n          \"type\":\"string\",\n          \"minLength\": 1,\n          \"maxLength\": 64,\n          \"pattern\":\"^[0-9a-fA-F]{1,64}$\",\n          \"description\":\"Identifier of the claim subject (dApp). A UTF-8 encoded string, must be max 64 chars. Typically it is randomly generated hash by the dApp developer.\"\n       },\n       \"rootHash\":{\n          \"type\":\"string\",\n          \"minLength\": 64,\n          \"maxLength\": 64,\n          \"pattern\":\"^[0-9a-fA-F]{64}$\",\n          \"description\":\"blake2b-256 hash of the metadata describing the off-chain part of the dApp.\"\n       },\n       \"metadata\": {\n         \"type\": \"array\",\n         \"description\": \"Chunks of URLs that make up the dApp's metadata (pointing to off-chain CIP-72) are arranged in an array to accommodate the 64-character limit per chunk, allowing for the support of longer URLs\",\n         \"items\": {\n           \"type\": \"string\",\n           \"minLength\": 1,\n           \"maxLength\": 64\n         }\n       },\n       \"type\":{\n          \"type\":\"object\",\n          \"description\":\"Describes the releases, if they are new or an updates.\",\n          \"properties\":{\n             \"action\":{\n               \"type\":\"string\",\n               \"enum\":[\"REGISTER\", \"DE_REGISTER\"],\n               \"description\":\"Describes the action this certificate is claiming; i.e 'REGISTER', for a new dApp or an update, DE_REGISTER for asserting that the dApp's development is stopped, and it is deprecated. So, no further dApp's on-chain update is to be expected.\"\n             },\n             \"comment\": {\n                \"type\": \"string\",\n                \"minLength\": 1,\n                \"maxLength\": 64,\n                \"description\": \"A free text field to provide details about this particular changes (64 chars limited).\"\n             }\n          },\n          \"required\":[\n             \"action\"\n          ]\n       }\n    },\n    \"required\":[\n       \"subject\",\n       \"rootHash\",\n       \"type\"\n    ],\n    \"additionalProperties\": false\n}\n "
  },
  {
    "path": "CIP-0074/README.md",
    "content": "---\nCIP: 74\nTitle: Set minPoolCost to 0\nAuthors:\n - Robin of Loxley <adarobinhood@tutanota.com>\nCategory: Ledger\nStatus: Proposed\nCreated: 2022-10-17\nDiscussions:\n - https://forum.cardano.org/t/cip-69-set-minpoolcost-to-0/109309\n - https://github.com/cardano-foundation/CIPs/pull/358\nImplementors: []\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nA minPoolCost of 340 ADA/epoch makes popularity the basis for pool desirability, causing preferred traits like pledge and performance to be overshadowed. This has promoted stake to centralize with operators who are effective at campaigning, but do not necessarily have any stake in the system of their own. We want to create a fair marketplace for stake pools that allows the network to decentralize with time; minPoolCost is averse to that goal.\n\n## Motivation: why is this CIP necessary?\n\nPopularity is currently the basis for desirability and defines which pools will receive high rewards and which won't. A pool with high popularity, low pledge, and low performance will offer significantly higher rewards than a pool with low popularity, high pledge, and high performance. With equal fee structures, a pool with 19.5MM pledge that is just starting out will be less desirable than a saturated pool with no pledge; a pool with 6MM pledge and perfect performance will be less desirable than a pool with 0 pledge and 90% performance. This makes it apparent we are not incentivizing a secure stable network and the network cannot self-correct if stake ends up in the wrong place.\n\nThe entirety of IOG's research is without a minPoolCost or any other minimum fee. The game theory design relied on stake pool operators (SPOs) having the ability to compete in a fair marketplace of pool desirability by modifying their pledge, cost, and margin in relation to other pools. Adding a minimum value to cost has removed the opportunity for operators to control their desirability outside of first gaining popularity. As a pool gains popularity it disproportionately gains desirability, allowing the operator to lower pledge and raise margin, while still maintaining higher desirability than a less popular pool with better fee structure and higher pledge. Operators can lie about their costs while still gaining utility. As long as the operator can maintain popularity they can exceed K indefinitely by opening more and more pools with a reward bonus instead of penalty. This significantly lowers the cost of a sybille attack, while making sybille behavior highly desirable and profitable. A sybille attacker, or anybody for that matter, should need stake in the system to compete for delegation, not just a rigorous marketing campaign.\n\nThe network is incentivizing the wrong behavior from SPOs which has made the network highly leveraged.\n\n\"The higher the leverage of the system, the worse its security [...] The lower the leverage of a blockchain system, the higher its degree of decentralization.\"\n\nHigh security should always be the priority.\n\n### Desired effects\n\nStake pool desirability will become a function of pledge, performance, cost, and margin instead of only popularity. Operators will need to consolidate and grow pledge while moderating fees to remain competitive with other pools on the market.\n\nSPOs define their cost as an absolute value when submitting their registration.cert. They do not reference minPoolCost. Changing minPoolCost will not change any predefined costs. Pools that wish to leave their cost as-is can do so without any input. Pools that wish to lower their cost below 340 ADA/epoch will have to submit an updated registration.cert.\n\n## Specification\n\n\"minPoolCost\": 0\n\n## Rationale: how does this CIP achieve its goals?\n\n98% of all pools have their cost at 340 ADA/epoch or within + 10. As the price of ADA went from $0.3 to $3, almost no operators modified their cost. As the price of ADA dropped from $3 to $0.3, almost no operators modified their cost. This shows that the minPoolCost is not related to the real cost of operating a pool and the cost of a pool is no longer related to its utility.\n\nWe have a large body of research accompanied by simulations showing that removing minPoolCost will increase decentralization of the network and begin incentivizing the right behavior from SPOs and the delegating community.\n\nA minPoolCost is not in Cardano's design specification. ALL published research is in favor of setting minPoolCost to 0.\n\n### Research and References\n\nDesign Specification for Delegation and Incentives in Cardano\nhttps://github.com/input-output-hk/cardano-ledger/releases/latest/download/shelley-delegation.pdf\n\nReward Sharing Schemes for Stake Pools\nhttps://arxiv.org/pdf/1807.11218.pdf\n\nPreventing Sybil attacks\nhttps://iohk.io/en/blog/posts/2018/10/29/preventing-sybil-attacks/\n\nStake Pools in Cardano\nhttps://iohk.io/en/blog/posts/2018/10/23/stake-pools-in-cardano/\n\nIncentive Paper Lecture Series (Parts 1-7)\nhttps://www.youtube.com/playlist?list=PLFLTrdAG7xRbAqhF3Tg8BeAea7Ard-ttn\n\nThe general perspective on staking in Cardano\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] A protocol parameter update assigning `minPoolCost` to `0`.\n\n### Implementation Plan\n\n- [ ] Agreement by the Ledger team as defined in [CIP-0084](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0084) under _Expectations for ledger CIPs_ including \"expert opinion\" on changes to rewards & incentives.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0075/README.md",
    "content": "---\nCIP: 75\nTitle: Fair Stake Pool Rewards\nStatus: Proposed\nCategory: Ledger\nAuthors:\n    - Tobias Fancee <tobiasfancee@gmail.com>\nImplementors: []\nDiscussions:\n    - https://forum.cardano.org/t/cip-fair-stakepool-rewards/109368\nCreated: 2022-10-21\nLicense: CC-BY-4.0\n---\n\n## Abstract\nThe current reward sharing scheme of Cardano is unfair and anticompetitive. As a result, Cardano has become more centralized over time. The high minimum fixed fee and current pledge benefit favor large stakepools and leave small stakepools at a significant disadvantage. The current scheme allows large pools with low pledge to be more attractive than smaller pools with higher pledge leading to centralization and potential Goldfinger attacks. Furthermore, k, the parameter representing the optimal number of stakepools, is set too low resulting in an ineffective pledge benefit, the formation of multipools, and a low incentive for stakepools to increase pledge over time. Finally, the current setting of a0, the pledge influence parameter, gives an unnecessarily large boost in rewards to fully pledged private pools resulting in significantly less rewards for public pools and their delegators.\n\nThis proposal retains most of the original reward sharing scheme, but makes changes to ensure fairness, increase decentralization, and reduce the viability of Goldfinger attacks. By removing the minimum fixed fee, adjusting the pledge benefit, increasing k, and reducing a0, a more egalitarian network can be achieved.\n\n## Motivation: why is this CIP necessary?\n\n### Definitions\n\n**Minimum Fixed Fee**\n- Protocol parameter minPoolCost.\n\n**Margin**\n- Stakepool parameter PoolRate (percentage fee).\n\n**Public Stakepool**\n- A stakepool with a margin that is less than 100%.\n\n**Private Stakepool**\n- A stakepool that is not seeking delegation with a margin of 100%.\n\n**Stakepool Operator (SPO)**\n- The operator of a stakepool, can be a single person or an entity.\n\n**Multipool**\n- A group or brand of stakepools operated by a single entity or stakepool operator.\n\n**ROS**\n- Return on staking (often annualized and represented as a percentage of the initial investment).\n\n**Leverage**\n- The ratio between a stakepool’s total stake and pledge.\n\n**Stakepool Viability Point**\n- The amount of pledge required for a stakepool with zero delegations to distribute nonzero rewards to delegators (assuming minimum stakepool fees and ignoring luck in VRF block production, i.e., rewards are exactly proportional to stake).\n\n**Stakepool Competitive Point**\n- The amount of pledge required for a stakepool with zero delegations to offer the same ROS as a fully-saturated stakepool with zero pledge (assuming minimum stakepool fees).\n\n**Stakepool Saturation Point**\n- The maximum amount of total stake in a stakepool before total stakepool rewards are capped and ROS diminishes.\n\n**Unsaturated Pledge Benefit Penalty**\n- The amount of potential pledge benefit (in ADA or represented as a percentage) a stakepool loses for being unsaturated. The penalty is larger the smaller the stakepool.\n\n**Minimum Attack Vector (MAV)**\n- Also known as the Nakamoto Coefficient, the MAV is the minimum number of entities required to capture more than 50% of a network. In the context of Cardano, this refers to the minimum number of SPOs required to capture more than 50% of active stake.\n\n**Goldfinger Attack**\n- An attack on a cryptocurrency protocol where the objective is to attack the protocol or network in order to make profit by shorting the native cryptocurrency.\n\n**Sybil Attack**\n- An attack on an online system where an entity tries to take over the network by creating many identities or nodes.\n\n### The Current Rewards Equation\n\nIn section 10.8 Rewards Distribution Calculation of “A Formal Specification of the Cardano Ledger” (git revision 1.1-486-g301fede) the current rewards calculation equation is described by the function $maxPool$:\n\n$$maxPool = \\frac{R}{1 + a0} \\cdot (o + p \\cdot a0 \\cdot \\frac{o - p \\frac{z0 - o}{z0}}{z0})$$\n\nwhere: $maxPool$ = maximum rewards for a stake pool, $R = ((reserve \\cdot rho) + fees) \\cdot (1 - tau), o = min(poolstake / totalstake, z0) = z0$ for fully saturated pool, $p = min(pledge / totalstake, z0)$, and $z0 = 1 / k$\n\nCurrent protocol parameters: $k = 500, rho = 0.003, a0 = 0.3$, and $tau = 0.2$\n\nThe current reward sharing scheme which includes the rewards calculation equation and the minimum fixed fee are inadequate in promoting decentralization as evident by Cardano’s currently low MAV relative to k. This is due to its anticompetitive features which are discussed in this section.\n\n### The Minimum Fixed Fee\n\nThe minimum fixed fee or minPoolCost was apparently included for additional sybil attack protection. However, it’s effect has been the opposite allowing stakepools with low pledge to offer greater rewards than pools with higher pledge in some cases. Moreover, the minimum fixed fee is certainly problematic as it places an unfair burden on small pools by enforcing a disproportionally larger fee than that of larger stakepools, reducing the ROS of small pools and incentivizing delegation to larger stakepools. This leads to centralization of the network around established stakepools, leaving less opportunity for smaller stakepools that may have greater pledge or community presence.\n\n### The Current Pledge Benefit\n\nThe current pledge benefit in the rewards equation is a function of the total stake in a pool that is significantly biased towards large stakepools that are close to saturation. Specifically, the current equation penalizes the pledge benefit of small pools. The smaller the pool, the larger the penalty. This unsaturated pledge benefit penalty combined with the minimum fixed fee leads to illogical rewards where large pools with low pledges can offer delegators higher ROS than smaller pools with significantly higher pledges. As a result, delegators are incentivized to delegate to larger stakepools even if they have lower pledges leading to network centralization.\n\nThe unsaturated pledge benefit penalty is part of the current rewards calculation equation and can be described by the equation:\n\n$$Unsaturated Pledge Benefit Penalty = \\frac{R}{1 + a0} \\cdot p \\cdot a0 \\cdot \\frac{p \\frac{z0 - o}{z0}}{z0}$$\n\nSee [UnsaturatedPledgeBenefitPenalty.xlxs](./UnsaturatedPledgeBenefitPenalty.xlxs) to calculate the current unsaturated pledge benefit penalty for a stakepool.\n\n### Goldfinger Attacks\n\nThe minimum fixed fee and current pledge benefit introduce a potential security threat to the Cardano protocol: Goldfinger attacks. The current reward scheme puts all small stakepools at a disadvantage regardless of pledge centralizing the network around established stakepools rather than pools with the most attractive pledge and fee combination. When SPOs with low stake (pledge) in the protocol are allowed to dominate consensus, they have a potential alternative incentive to attack the network in order make profit by shorting ADA. Because these stakepools have low stake in the protocol (operate with low or even zero pledge), they would be able make profit without any significant loss other than future staking rewards. With leverage, the attackers could make significantly more profit shorting ADA than years of staking.\n\n### The Optimal Number of Stakepools, k\n\nThe current setting of k, the parameter representing the optimal number of stakepools, is set too low to provide an effective pledge benefit leaving little incentive for pools to increase pledge over time. Specifically, with a small k value, a fully pledged pledge benefit is far from achievable for most SPOs. An ineffective pledge benefit leads to the formation of multipools with high leverage, as operators can split their pledge into multiple stakepools without a significant decrease in ROS in the resulting stakepools.\n\n### The Pledge Influence Parameter, a0\n\nThe current setting of a0, the pledge influence parameter, gives an unnecessarily large boost in rewards to very high pledge and fully pledged private pools. Specifically, the current setting of a0 results in approximately 30% greater rewards for fully pledged private pools. This boost in rewards unfortunately results significantly less rewards for public pools that commonly have low pledges relative to the saturation point. Given that most Cardano users are delegators and not SPOs, this exclusive boost for high pledge pools decreases Cardano’s overall attractiveness as a staking protocol. Additionally, having a high a0 setting only accelerates the wealth (ADA) disparity between large entities operating private pools and delegators who make up majority of the ecosystem.\n\n## Specification\n\n### The Proposed Rewards Calculation Equation\n\nThe proposed rewards calculation equation is a modification of the current equation that removes the unsaturated pledge benefit penalty:\n\n$$maxPool = \\frac{R}{1 + a0} \\cdot (o + p \\cdot a0 \\cdot \\frac{o}{z0})$$\n\nwhere: $maxPool$ = maximum rewards for a stake pool, $R = ((reserve \\cdot rho) + fees) \\cdot (1 - tau), o = min(poolstake / totalstake, z0) = z0$ for fully saturated pool, $p = min(pledge / totalstake, z0)$, and $z0 = 1 / k$\n\n### The Proposed Parameter Values\n\nThe proposed parameter values are the following:\n\n| Name of the Parameter | New Parameter (Y/N) | Deleted Parameter (Y/N) | Proposed Value | Summary Rationale for Change |\n|-----------------------|---------------------|-------------------------|----------------|------------------------------|\n| minPoolCost           | N                   | Y                       | N/A            | See Rationale Section.       |\n| stakePoolTargetNum    | N                   | N                       | 1000           | See Rationale Section.       |\n| poolPledgeInfluence   | N                   | N                       | 0.2            | See Rationale Section.       |\n\n## Rationale: how does this CIP achieve its goals?\n\n### Principles\n\nThe main goal of this proposal is to ensure fairness in stakepool rewards. This is achieved by including these principles in the design:\n\n1.\tEliminate all anticompetitive features. These include any parts of the design that treat stakepools differently based on anything other than pledge or declared fees.\n2.\tEnsure that the pledge benefit is fair and corresponds to a consistent boost in ROS no matter pool size. In other words, assuming the same fees, two pools with the same pledge should always offer the same ROS.\n3.\tEnsure that the pledge benefit is effective and incentivizes increasing pledge over time.\n4.\tReduce the large rewards disparity between private pools and delegators and increase Cardano’s overall attractiveness as a staking protocol.\n\n### Explanation\n\nThe current reward sharing scheme includes two notable anticompetitive features. These features are the minimum fixed fee and the unsaturated pledge benefit penalty. This proposal removes these features to ensure fairness and promote adequate competition between stakepools. Removing these anticompetitive features promotes delegation to pools with most attractive pledge and fee combinations rather than established large pools and multipools. This results in fairer competition among stakepools and lower possibility of Goldfinger attacks as the pledge benefit is effective at all stakepool sizes. Greater decentralization is also possible as small stakepools will be able to offer competitive returns and potentially extract delegation from low pledge multipools.\n\nTo ensure a more effective pledge benefit and incentivize increasing pledge over time, this proposal increases the current value of k from 500 to 1000. This allows a fully pledged pledge benefit to be closer for all SPOs and will force multipools to split pledge and reduce pledge benefit if they wish to continue operating with the same leverage. Additionally, a change in the value of k will give many stagnant delegators an incentive to reconsider their delegations giving smaller stakepools an opportunity at increasing delegation.\n\nFinally, to reduce the large rewards disparity between private pools and delegators, this proposal reduces the setting of a0 from 0.3 to 0.2. The current setting of a0 results in approximately 30% greater rewards for fully pledged private pools. This proposal reduces this disparity to 20% to create a fairer rewards distribution. The result is an overall increase in rewards for delegators as most public pools operate with low pledges relative to the saturation point. Given that delegators make up majority of users, this reduction in a0 will make Cardano a much more competitive staking investment in contrast to other blockchains.\n\nThese proposed changes to Cardano’s reward sharing scheme are aimed at ensuring fairness, increasing decentralization, and creating a more egalitarian staking ecosystem.\n\n### Test Cases\n\nStakepool viability and competitive points can give some insight into the fairness of the reward scheme. These points are essentially start-up costs required to run viable and competitive stakepools. These points are very high and out of reach for many SPOs with the current scheme. This proposal effectively minimizes these points.\n\nCurrent stakepool viability point: ~625,000 ADA\n\nCurrent stakepool competitive point: ~19,000,000 ADA\n\nProposal stakepool viability point: 1 ADA\n\nProposal stakepool competitive point: 1 ADA\n\nSee [FairStakepoolRewards.xlxs](./FairStakepoolRewards.xlsx) to compare stakepool ROS between the current and proposed scheme.\n\n### Backward Compatibility\n\nThis proposal includes parameter changes, one parameter removal, and a change to the rewards calculation. Because of the parameter removal and changes to the rewards calculation, a hardfork will be necessary for implementation.\n\n## Path to Active\n\n### Acceptance Criteria\n\nEach stage will be an individual protocol update. The first two updates will be protocol parameter updates. The third and final update will require a hardfork.\n\nBefore implementation, engineering and research teams must review the feasibility and potential consequences of the proposal, create the implementation for each update, and decide on the time interval between updates.\n\n1. The protocol update is created, including all necessary changes.\n2. The raw transaction for the protocol update is built.\n3. Transaction is signed.\n4. Transaction is submitted.\n5. Protocol update is confirmed.\n\n### Implementation Plan\n\nImplementation can be staged to reduce shock to the network:\n\n1.\tDecrease minPoolCost from 340 ADA to 100 ADA and increase k from 500 to 750.\n2.\tIncrease k from 750 to 1000, decrease minPoolCost from 100 ADA to 0 ADA, and decrease a0 from 0.3 to 0.2.\n3.\tRemove minPoolCost from the protocol and implement the new rewards calculation equation.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0080/README.md",
    "content": "---\nCIP: 80\nTitle: Transaction Serialization Deprecation Cycle\nStatus: Active\nCategory: Ledger\nAuthors:\n  - Jared Corduan <jared.corduan@iohk.io>\nImplementors: N/A\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/372\nCreated: 2022-11-09\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP specifies a policy for the backwards compatibility of the serialization scheme of\nCardano transactions.\n\n## Motivation: why is this CIP necessary?\n\nTransactions on Cardano are sent on the wire using CBOR and are specified with CDDL.\nThe first scheme was introduced with the Byron phase.\nThis scheme was changed dramatically with the introduction of the Shelley phase.\nAs of the time of the writing of this CIP, however, every new scheme has been backwards\ncompatible with the original scheme from the Shelley phase.\nThe intention is still to maintain backwards compatibility to the extent reasonable,\nand to make explicit our policy for breaking backwards compatibility when deemed necessary.\n\n## Specification\n\nProblems with serialization fall into two categories:\n* flaws in the implementation\n* flaws is the CDDL specification\n\nNote that at the time of the writing of this CIP, there is only one implementation of the Cardano\nnode, and we do not yet need to consider inconsistencies between different implementations.\n\nThe policy for maintaining backwards compatibility with the transaction serialization will be\nas follows.\n\n### Serious Flaws\n\nA **serious flaw** in the serialization is an issue which could have a large and negative impact\non the network, and which requires a hard fork to fix.\nThese will almost always be problems with the serialization and not the specification.\nIt is up to human discretion to determine what constitutes a serious flaw,\nmostly likely by the core developers.\n\nBackwards compatibility can be abandoned in the case of a serious flaw,\nand **the fix will occur at the next available hard fork**.\n\n### Non-Serious Flaws\n\nA **non-serious flaw** in the serialization is an issue which is not safety critical,\nbut is problematic enough to merit breaking backwards compatibility.\nThis is again a human judgment.\n\nBackwards compatibility can be abandoned in the case of a non-serious flaw,\nbut there must be a deprecation cycle:\n* In the case of a **soft fork** (meaning that the change is backwards incompatible for\n  block producers but *not* block validators),\n  a new format can be introduced at the next major or minor protocol version,\n  at which time the old format can be abandoned.\n* In the case of a **hard fork** (meaning that the change is backwards incompatible for\n  both block producers and block validators),\n  a new format can be introduced at the next major protocol version,\n  but the old format must be supported for at least **six months**.\n  After six months, the old format can be abandoned at the next possible fork.\n\n#### Examples\n\nA good example of a non-serious flaw is the CDDL specification of the transaction output in the\nAlonzo ledger era:\n\n```\nalonzo_transaction_output = [ address, amount : value, ? datum_hash : $hash32 ]\n```\n\nThere is nothing inherently wrong with this scheme, but it caused a problem in the Babbage ledger\nera with the addition of inline datums and script references.\nIn particular, there were two new optional fields, and there was mutual exclusivity.\nIn order to maintain backwards compatibility, Babbage introduced this scheme:\n\n```\ntransaction_output = alonzo_transaction_output / babbage_transaction_output\n\nbabbage_transaction_output =\n  {   0 : address\n  ,   1 : value\n  , ? 2 : [ 0, $hash32 // 1, data ]\n  , ? 3 : script_ref\n  }\n```\n\nIn other words, a new format was created, but the legacy format was still supported.\nThe new format, `babbage_transaction_output`, was introduced 2022-09-22 with the Vasil hard fork,\nThe old format, `alonzo_transaction_output`, can be retired after 2023-03-22.\n\nNote that this example required a **hard fork**.\n\nA good example of a non-serious flaw requiring a **soft fork** is the removal\nof zero-valued multi-assets in the mint field of the transaction body.\n\nIn the Babbage ledger era, a multi-asset value was defined as:\n\n```\nvalue = coin / [coin,multiasset<uint>]\n```\n\nZero values can be confusing inside of things like explorers, so in the Conway era they are removed:\n\n```\nnatNum = 1 .. 4294967295\nvalue = coin / [coin,multiasset<natNum>]\n```\n\nNotice that block validators will not notice this change, though block producers will notice it.\n\n### Summary\n\n* We should strive to maintain backwards compatibility.\n* Serious flaws can be fixed immediately (at the next hard fork), and can break backwards\n  compatibility.\n* Non-Serious flaws can be fixed (at the next hard fork), but the old format\n  must be supported for at least six months with support ending at the next hard fork event after\n  the six months have passed.\n\n## Rationale: how does this CIP achieve its goals?\n\nIt seems clear that security issues merit breaking backwards compatibility and should be fixed\nas soon as possible.\nThe six month compatibility window for non-serious flaws is mostly\narbitrary, but we need to allow enough time for people to migrate.\nIt would be great to have more explicit definitions for \"serious\" and \"non-serious\" flaws,\nbut this seems very difficult.\n\n## Path to Active\n\n### Acceptance criteria\n\n- [x] The proposal is accepted and recognized by the ledger team.\n\n### Implementation plan\n\nN/A\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n"
  },
  {
    "path": "CIP-0082/README.md",
    "content": "---\nCIP: 82\nTitle: Improved Rewards Scheme Parameters\nStatus: Proposed\nCategory: Ledger\nAuthors:\n    - Tobias Fancee <tobiasfancee@gmail.com>\nImplementors: []\nDiscussions:\n    - https://forum.cardano.org/t/cip-improved-rewards-scheme-parameters/112409\nCreated: 2022-01-03\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThe current parameter settings of Cardano's rewards sharing scheme leave much to be desired in terms of fairness and promoting decentralization. minPoolCost puts small stakepools at a significant disadvantage. Replacing minPoolCost with a minPoolRate will ensure a level playing field for stakepools while providing sufficient sybil attack resistance. Additionally, the current setting of k, the optimal number of stakepools, is too low to provide an adequate pledge benefit. Increasing k will make the pledge benefit more effective and get delegations moving in hopes of helping single pool operators gain delegations.\n\nThe parameter changes in this proposal are an optimization of the current settings and are meant to improve the fairness and decentralization of Cardano. Furthermore, all changes suggested in this proposal have been specifically voiced by the Cardano community.\n\n## Motivation: why is this CIP necessary?\n\n### Definitions\n\n**Stakepool Operator (SPO)**\n- The operator of a stakepool, can be a single person or an entity.\n\n**Multipool**\n- A group or brand of stakepools operated by a single entity or stakepool operator.\n\n**ROS**\n- Return on staking (often annualized and represented as a percentage of the initial investment).\n\n**Stakepool Viability Point**\n- The amount of pledge required for a stakepool with zero delegations to distribute nonzero rewards to delegators (assuming minimum stakepool fees and ignoring luck in VRF block production, i.e., rewards are exactly proportional to stake).\n\n**Stakepool Competitive Point**\n- The amount of pledge required for a stakepool with zero delegations to offer the same ROS as a fully-saturated stakepool with zero pledge (assuming minimum stakepool fees).\n\n**Stakepool Saturation Point**\n- The maximum amount of total stake in a stakepool before total stakepool rewards are capped and ROS diminishes.\n\n**Minimum Attack Vector (MAV)**\n- Also known as the Nakamoto Coefficient, the MAV is the minimum number of entities required to capture more than 50% of a network. In the context of Cardano, this refers to the minimum number of SPOs required to capture more than 50% of active stake.\n\n**Sybil Attack**\n- An attack on an online system where an entity tries to take over the network by creating many identities or nodes.\n\n### Cardano’s Declining MAV\n\nCardano’s declining MAV is a real problem as the network matures and gains more users. Ideally MAV should increase or stay consistent over time. However, this is currently not the case. This trend points to potential problems with the parameters set in the rewards sharing scheme. Now that staking on the network has matured, it is time to re-examine the rewards sharing scheme parameters and seek optimization. This proposal suggests changes that aim to increase the fairness and decentralization of the Cardano network.\n\n### minPoolCost\n\nminPoolCost sets a minimum fixed fee that a stakepool must collect from an epoch’s rewards before distributing to delegators. This parameter was added to the rewards sharing scheme to provide additional sybil attack protection. While this parameter has been successful at deterring sybil attacks on the Cardano network, it has been at the expense of fairness and decentralization. minPoolCost imposes a proportionally greater staking fee on small stakepools in contrast to larger pools. This discrepancy results in many small pools being unviable and the network centralizing around established pools. It is not uncommon for small stakepools with higher pledge to offer inferior rewards to that of large stakepools with much lower pledge. In this way, minPoolCost reduces the effectiveness of pledge in the rewards scheme. In order to create a level playing field for stakepools and increase the effectiveness of pledge, minPoolCost must be removed from the protocol.\n\n### minPoolRate\n\nThe current pledge benefit favors established pools close to saturation as a means of sybil attack protection. Specifically, this property combats high pledge sybil pools (~1 mil ADA pledge) that could be set up by large entities such as centralized exchanges. In contrast to minPoolCost, the pledge benefit’s built-in sybil attack protection is significantly less aggressive and does not affect the viability of stakepools. In this way, it is a useful mechanism to combat sybil pools. However, the pledge benefit on its own has no means to combat zero fee sybil pools. Without minPoolCost, zero fee sybil pools could offer greater rewards than that of established stakepools that must set fees to pay for continued operation. In order to combat zero fee sybil pools without minPoolCost, minPoolRate must be added to the protocol. minPoolRate will set a minimum margin or percentage fee that operators can extract from an epoch’s staking rewards. This new parameter will protect established stakepools by ensuring that they collect sufficient revenue from operation while offering a competitive ROS. Additionally, minPoolRate can be updated to reflect current economic conditions. As minPoolRate enforces a proportional minimum fee, it does not affect the viability of stakepools. Unlike minPoolCost, minPoolRate will be able to provide sufficient sybil attack protection with the pledge benefit while maintaining a level playing field for stakepools. minPoolRate was originally proposed in CIP-0023.\n\n### k, the optimal number of stakepools\n\nk represents the optimal number of stakepools that the Cardano network can support. This is achieved through a saturation mechanism where after exceeding a saturation point a stakepool will earn no additional rewards. A stakepool larger than the saturation point will offer lower rewards than a stakepool at the saturation point. The parameter k is used to tune the saturation point. In addition to tuning the saturation point, k also affects the pledge benefit. The maximum pledge benefit exists when a pool is fully saturated. Therefore, increasing k will increase the number of optimal stakepools, decrease the saturation point, and make it easier for stakepools to achieve the maximum pledge benefit. Increasing the effect of the pledge benefit on rewards is imperative, as pledge currently has little effect on rewards allowing low pledge pools to proliferate through marketing alone. Furthermore, increasing k can be used to get stale delegations moving. This is especially useful in the case of saturated multipools, where delegators would have to reconsider their delegation potentially assisting small and medium sized pools. Any delegation flow from multipools to single pool operators will increase the decentralization of Cardano.\n\n## Specification\n\nThis CIP proposes several parameter changes. In order to give SPOs and delegators enough time to react to the changes, this CIP is divided into 4 stages. The proposed time interval between stages is 3 epochs or 15 days. However, it is up to the implementors to determine the best time interval between stages. Parameters are changed in the following stages:\n\n### Stage 1: minPoolCost decreased to 170 ADA\n\n| Name of the Parameter | New Parameter (Y/N) | Deleted Parameter (Y/N) | Proposed Value | Summary Rationale for Change |\n|-----------------------|---------------------|-------------------------|----------------|------------------------------|\n| minPoolCost           | N                   | N                       | 170000000      | See Rationale Section.       |\n\n### Stage 2: minPoolCost deleted, minPoolRate of 3% implemented (requires hardfork)\n\n| Name of the Parameter | New Parameter (Y/N) | Deleted Parameter (Y/N) | Proposed Value | Summary Rationale for Change |\n|-----------------------|---------------------|-------------------------|----------------|------------------------------|\n| minPoolCost           | N                   | Y                       | N/A            | See Rationale Section.       |\n| minPoolRate           | Y                   | N                       | 0.03           | See Rationale Section.       |\n\nIn order to ensure the compatibility of existing stakepool registration certificates with this CIP, the variable poolRateEff must be added to the protocol. This variable will be the effective margin used during stakepool fee calculation. Following the hardfork, poolRate will only be the value set by SPOs. poolRate will be superseded by minPoolRate if its value is lower than minPoolRate. This is demonstrated in the definition of poolRateEff:\n\n$$poolRateEff = max(poolRate, minPoolRate)$$\n\n### Stage 3: k increased to 750\n\n| Name of the Parameter | New Parameter (Y/N) | Deleted Parameter (Y/N) | Proposed Value | Summary Rationale for Change |\n|-----------------------|---------------------|-------------------------|----------------|------------------------------|\n| stakePoolTargetNum    | N                   | N                       | 750            | See Rationale Section.       |\n\n### Stage 4: k increased to 1000\n\n| Name of the Parameter | New Parameter (Y/N) | Deleted Parameter (Y/N) | Proposed Value | Summary Rationale for Change |\n|-----------------------|---------------------|-------------------------|----------------|------------------------------|\n| stakePoolTargetNum    | N                   | N                       | 1000           | See Rationale Section.       |\n\n## Rationale: how does this CIP achieve its goals?\n\n### Principles\n\n1.\tPropose changes voiced by the community.\n2.\tMake Cardano staking fairer by eliminating aggressive anticompetitive features.\n3.\tIncrease the effect of the pledge benefit on staking rewards.\n4.\tGet stale delegations moving and allow users to reconsider their delegation.\n5.\tMaintain sufficient sybil attack protection.\n\n### Explanation\n\n#### Stage 1: minPoolCost is decreased to 170 ADA\n\nStage 1 reduces minPoolCost from 340 ADA to 170 ADA. 170 ADA is proposed because it is half of the current minPoolCost and is close to what the USD value of minPoolCost was during the launch of Shelley. This value is more than sufficient to allow established community pools to stay profitable while enabling smaller pools to be more competitive. This value also maintains sybil attack resistance.\n\n#### Stage 2: minPoolCost is deleted, minPoolRate of 3% is implemented (requires hardfork)\n\nStage 2 introduces the largest change to the network by deleting minPoolCost from the protocol in favor of a minPoolRate of 3%. 3% is proposed, as it allows established community pools to stay profitable when competing against minimum fee pools. This in combination with the pledge benefit provide sufficient sybil attack resistance while leveling the playing field for all stakepools. As pool size is significantly less important following this stage, pledge becomes a more important factor in choice of delegation. In contrast, Lido, Ethereum’s most popular liquid staking DApp, applies a 10% fee on participants' staking rewards.\n\n#### Stage 3: k is increased to 750\n\nStage 3 increases k from 500 to 750. The purpose of stage 3 and stage 4 is two-fold. Firstly, increasing k increases the pledge benefit. The more effective the pledge benefit, the greater Cardano’s sybil attack resistance. Secondly, increasing k may get stale delegations moving again by oversaturating large pools. This will cause many delegators to reconsider their delegation, potentially helping smaller community pools find delegations. Increasing k is split into two stages to give SPOs sufficient time to react to the change. Furthermore, it is imperative that k is increased after stage 2, as small stakepools will only be competitive after minPoolCost has been removed.\n\n#### Stage 4: k is increased to 1000\n\nStage 4 increases k from 750 to 1000. Stage 4 will further improve the pledge benefit and get more delegations moving. This is the final stage of this proposal.\n\n### Test Cases and Sybil Attack Resistance\n\nBelow are test cases for the current rewards scheme and each stage of this proposal. The calculated values assume all pools are operating with minimum fees. Sybil pools are assumed to be small pools with no delegations. Community pools are assumed to be pools with significant delegation. As demonstrated below, this proposal allows community pools to have sufficient revenue (higher than the USD value of minPoolCost at the launch of Shelley) while creating a level playing field for all stakepools. Sybil attack resistance is maintained at every stage, as community pool ROS remains higher than sybil pool ROS. Data used for calculations was approximated from epoch 385. See [ImprovedRewardsSchemeParameters.xlxs](./ImprovedRewardsSchemeParameters.xlsx) for more test cases.\n\n#### Current Rewards Scheme\n\nStakepool Viability Point: ~670,000 ADA\n\nStakepool Competitive Point: ~20,000,000 ADA\n\n| Pool Type | Pool Stake        | Pool Pledge      | Pool Epoch Revenue | Delegator ROS         |\n|-----------|-------------------|------------------|--------------------|-----------------------|\n| Sybil     | 100,000.00 ADA    | 100,000.00 ADA   | 340 ADA            | Below Viability Point |\n| Sybil     | 1,000,000.00 ADA  | 1,000,000.00 ADA | 340 ADA            | 1.2339%               |\n| Community | 10,000,000.00 ADA | 100,000.00 ADA   | 340 ADA            | 3.5213%               |\n| Community | Saturated         | 1,000,000.00 ADA | 340 ADA            | 3.7567%               |\n\n#### Proposed - Stage 1\n\nStakepool Viability Point: ~335,000 ADA\n\nStakepool Competitive Point: ~16,500,000 ADA\n\n| Pool Type | Pool Stake        | Pool Pledge      | Pool Epoch Revenue | Delegator ROS         |\n|-----------|-------------------|------------------|--------------------|-----------------------|\n| Sybil     | 100,000.00 ADA    | 100,000.00 ADA   | 170 ADA            | Below Viability Point |\n| Sybil     | 1,000,000.00 ADA  | 1,000,000.00 ADA | 170 ADA            | 2.4977%               |\n| Community | 10,000,000.00 ADA | 100,000.00 ADA   | 170 ADA            | 3.6498%               |\n| Community | Saturated         | 1,000,000.00 ADA | 170 ADA            | 3.7749%               |\n\n#### Proposed - Stage 2\n\nStakepool Viability Point: 1 ADA\n\nStakepool Competitive Point: 1 ADA\n\n| Pool Type | Pool Stake        | Pool Pledge      | Pool Epoch Revenue | Delegator ROS |\n|-----------|-------------------|------------------|--------------------|---------------|\n| Sybil     | 100,000.00 ADA    | 100,000.00 ADA   | 1.52 ADA           | 3.6615%       |\n| Sybil     | 1,000,000.00 ADA  | 1,000,000.00 ADA | 15.24 ADA          | 3.6617%       |\n| Community | 10,000,000.00 ADA | 100,000.00 ADA   | 152.42 ADA         | 3.6631%       |\n| Community | Saturated         | 1,000,000.00 ADA | 1081.06 ADA        | 3.6773%       |\n\n#### Proposed - Stage 3\n\nStakepool Viability Point: 1 ADA\n\nStakepool Competitive Point: 1 ADA\n\n| Pool Type | Pool Stake        | Pool Pledge      | Pool Epoch Revenue | Delegator ROS |\n|-----------|-------------------|------------------|--------------------|---------------|\n| Sybil     | 100,000.00 ADA    | 100,000.00 ADA   | 1.52 ADA           | 3.6615%       |\n| Sybil     | 1,000,000.00 ADA  | 1,000,000.00 ADA | 15.24 ADA          | 3.6620%       |\n| Community | 10,000,000.00 ADA | 100,000.00 ADA   | 152.49 ADA         | 3.6639%       |\n| Community | Saturated         | 1,000,000.00 ADA | 720.44 ADA         | 3.6853%       |\n\n#### Proposed - Stage 4\n\nStakepool Viability Point: 1 ADA\n\nStakepool Competitive Point: 1 ADA\n\n| Pool Type | Pool Stake        | Pool Pledge      | Pool Epoch Revenue | Delegator ROS |\n|-----------|-------------------|------------------|--------------------|---------------|\n| Sybil     | 100,000.00 ADA    | 100,000.00 ADA   | 1.52 ADA           | 3.6615%       |\n| Sybil     | 1,000,000.00 ADA  | 1,000,000.00 ADA | 15.24 ADA          | 3.6624%       |\n| Community | 10,000,000.00 ADA | 100,000.00 ADA   | 152.52 ADA         | 3.6646%       |\n| Community | Saturated         | 1,000,000.00 ADA | 542.82 ADA         | 3.6932%       |\n\n### Backward Compatibility\n\nThis proposal includes several parameter changes and changes to ledger rules. Specifically, stage 2 of this proposal will require a hardfork to introduce a new parameter, delete a parameter, and modify the stakepool fee calculation equation. As mentioned in the specification section, the stakepool fee calculation equation must be modified in order to ensure current stakepool registration certificates are compatible with this CIP.\n\n## Path to Active\n\n### Acceptance Criteria\n\n#### For Stages 1, 3, and 4\n1. The raw transaction for the parameter update is built.\n2. Transaction is signed.\n3. Transaction is submitted.\n4. Parameter update is accepted by majority of the network.\n5. Parameter update is confirmed.\n\n#### For Stage 2\n\n1. Necessary research and development is completed for the changes to the ledger rules.\n2. New version of cardano-node supporting the changes to the ledger rules is released.\n2. Raw transaction signaling the hardfork is built.\n3. Transaction is signed.\n4. Transaction is submitted.\n5. Hardfork is accepted by majority of the network.\n6. Hardfork and changes to ledger rules are confirmed.\n\n### Implementation Plan\n\nEach stage will be an individual update. Stages 1, 3, and 4 will be parameter updates. Stage 2 will require a hardfork.\n\nBefore implementation, engineering and research teams must review the feasibility and potential consequences of the proposal, create the implementation for each update, and decide on the time interval between updates.\n\nAs previously mentioned, implementation will occur in the following stages:\n\n1. minPoolCost is decreased to 170 ADA\n2. minPoolCost is deleted, minPoolRate of 3% is implemented (requires hardfork)\n3. k is increased to 750\n4. k is increased to 1000\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0083/README.md",
    "content": "---\nCIP: 83\nTitle: Encrypted Transaction message/comment metadata (Addendum to CIP-0020)\nStatus: Active\nCategory: Metadata\nAuthors:\n    - Martin Lang <martin@martinlang.at>\n    - Ola Ahlman <ola@ahlnet.nu>\n    - Andrew Westberg <andrewwestberg@gmail.com>\n    - Adam Dean <adam@crypto2099.io>\nImplementors:\n    - Cardano Explorer <https://cexplorer.io>\n    - StakePoolOperator Scripts <https://github.com/gitmachtl/scripts>\n    - AdaStat.net <https://adastat.net>\n    - Eternl Wallet <https://eternl.io>\n    - CNTools <https://cardano-community.github.io/guild-operators/#/Scripts/cntools>\n    - JorManager <https://bitbucket.org/muamw10/jormanager/>\n    - Cardanoscan.io <https://cardanoscan.io>\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/394\nCreated: 2022-12-08\nLicense: CC-BY-4.0\n---\n\n\n## Abstract\n\nThis CIP is an addendum to the original [CIP-0020](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0020), which is active since mid 2021 and widely used across many entities.\nIt describes the JSON schema to add encrypted messages/comments/memos as transaction metadata. It is fully backwards compatible and requires no changes in existing tools, explorers, wallets. \nTools/Wallets that do not have an implementation to decrypt this format will just show the encrypted base64 as the message, but it will not break any existing processes.\n\n## Motivation: why is this CIP necessary?\n\n### Current state of transaction messages\n\nTransaction messages/comments/memos via CIP-0020 are widely used across the Cardano Blockchain. For example DEXs are using it to comment there payouts to the customers.\nIndividual users are using it to send funds across the network to other users with attached information about it. Users are buying goods and pay directly in ADA, attaching payment informations\nvia an added message.\n\nTheses and many other usecases are actively happening on the blockchain right now and are a valuable addition to the core functions.\n\n### What is the issue with the current implementation?\n\nMetadata is attached as a CBOR bytearray in the auxiliary dataset of a transaction. So the encoding is just done from UTF8-Text to Hex-Code/Bytes and after that it is sent in plaintext over the network/blockchain.\nTo seek further adoption of blockchain usage, privacy features are a must in the future. Having cleartext information in a TCP packet might not be an issue for many things, but it is an issue if you wanna convince \nusers to use the blockchain and their transaction feature like users using it now with bank transfers.\n\nIt is easy for 3rd-party entities like Internet Service Providers, Datacenters or basically any Man-In-The-Middle to collect data that is sent in cleartext. \nData such as bank-account-numbers, email-addresses, telephone numbers, etc. which are parts of transaction messages.\n\n### What benefits/features would this CIP have on transaction messages?\n\nAs pointed out above, everyone that is having access to the datastream and of course the publicly distributed ledger can extract the cleartext data of the transaction messages.\nBecause there must not even be a specific approach to get such transaction message data out of a TCP stream, just a simple filter for email addresses (example) is enough. \nEven with a simple encryption of such messages - and publicly known passphrase - it is much more complicated for the Man-In-The-Middle listener to collect data on the fly. \n\n**Targeted benefits:**\n   - By using a default passphrase, Man-In-The-Middle \"sniffer\" cannot extract/parse data like email-addresses, invoice-numbers on the fly that easily. They would need to search for a cardano-node transmission and decrypt each message. Public explorers like Cexplorer.io, Cardanoscan, etc. can still show the decrypted message content via there https connection to the user. So no cleartext transmission at all.\n   - Different users can transfer funds with encrypted messages attached between each other, using a preshared passphrase. Only theses users need to know the content. Example: A user buys goods from an online-store, the store provides a preshared-passphrase to the user on their website or via email, the user sends the payment with payment-information encrypted with this passphrase to the store.\n   - Keeping the usecase of a transaction private does not only belong to different entities, but to a single user too. Example: If a user sends funds to a Dex or wants to lend some fund to a friend, he just can add information like 'Sent xxx ADA to bob for xxx' to the outgoing transaction as a documentation using an own choosen private passphrase. This information is stored on the chain and so in the wallet, only the user itself can review the use case of these transactions.\n   - Backwards compatible with CIP-0020\n   - Easy implementation by using well known tools like OpenSSL\n\n### What this CIP is not trying to do\n\nThis addition to the original CIP-0020 should not be seen as the end-all-be-all security solution for privacy on the blockchain. There's better options and upcoming Midnight for that. The transaction messages are also not intended to act like chat messages on the chain.\n\n# Specification - Encrypted message\n\nThe specification update for encrypted messages takes advantage of the simple original design, which is leaving room for additional json-keys not affecting the parsing of the content at all. The only outcome if a receiver does not process the encrypted content is, that the encrypted message is shown instead of an maybe autodecrypted one. But even the encrypted base64 strings fit into the max. 64char long string restriction. So it does not break any tools. More on the autodecryption later. \n\n### Format:\n``` json\n{ \n  \"674\":\n         { \n           \"enc\": \"<encryption-method>\",\n           \"msg\": \n                  [ \n                    \"base64-string 1\", \"base64-string 2\", \"base64-string 3\" ...\n                  ]\n         }\n}\n```\nThe format is identical to the original one, with a simple addition of the `enc` (encryptionmode) entry.\n\nThe value given in the `enc` field references the type of encryption is used. Starting with a simple implementation named `basic`. There is room to add additional encryption method in the future like using ChaCha20/Poly1305 or using public/private key encryption. Also there is the possibility to not encode the metadata in the standard JSON format, but using CBOR encoding instead.\n\n  \n### Encryption methods:\n\n#### **plain** - no encryption at all\n  \n  | Parameter | Value |\n  | :--- | :--- |\n  | method | **plain** |\n  |description|plaintext, no encryption|\n\n  This is not really an encryption mode, but included as a backwards compatible entry to signal this message as an unencrypted one. The entry is not needed and fully optional for unencrypted messages.\n\n#### **basic** - aes-256-cbc salted symmetric encryption via passpharse (+default passphrase)\n\n  | Parameter | Value |\n  | :--- | :--- |\n  | method | **basic** |\n  | description | symmetrical encryption via openssl and a passphrase |\n  | default passphrase | cardano |\n  | type | openssl |\n  | cipher | aes-256-cbc (salted) |\n  | digest | pdkdf2 |\n  | padding | PKCS#7 |\n  | iterations | 10000 (default) |\n  | key + iv | 32 bytes key + 16 bytes iv |\n  | salt | 8 bytes |\n  | prefix | `Salted__` |\n  | encoding | base64|\n\nOpenSSL was choosen, because its fast and widely available also for all kind of different platforms, web frontends, etc. Encryption algo is **AES-256-CBC** (salted) using `pdkdf2` to derive the key from the given passphrase. 10000 Iterations is the default value for this encryption method. The format of the encoded output is base64 format.\n\nThe encryption is based on a given passphrase, which can be choosen by the user. However, a default-passphrase \"cardano\" should be used to encrypt/decrypt if no other passphrase is provided or known.\n  \nOpenSSL uses [PKCS#7](https://datatracker.ietf.org/doc/html/rfc5652#section-6.3) as padding. The adopted cipher accepts only multiple of 16-byte blocks. Not fitting messages to be encrypted are filled with the number of padding bytes that are needed to form multiple of 16-bytes. So if 1 byte of padding is required, the padding \"01\" is added. If 2 bytes of padding are needed, \"02 02\" is added. If no padding is required, an extra block of 0x10 bytes is added, meaning sixteen \"10\" bytes. In order to be interoperable with OpenSSL this kind of padding is a requirement.  \n  \n##### Why a default passphrase?\n  \nAs pointed out above, its way harder for man-in-the-middle listeners, to decrypt every single message on the fly. So by using a default passphrase, tools can encrypt messages and explorers/wallets can autodecrypt such messages trying to use the default passphrase. In that way, the displayed message is automatically readable to the user. If a more protected communication is needed, the sender can choose a custom passphrase and communicate that to the receiver as a preshared passphrase.\n\nWhat part is uses for the encryption?\n  \nThe **whole content** of the unencrypted normal transaction **metadata `msg:` key is used**, thats the array with the message string(s). (Example below)\n\n##### Is there sample code?  \n  \nYes, example implementations for node.js, PHP, bash, etc. can be found in the [codesamples](./codesamples/) folder. They are showing how to encrypt/decrypt text with the right parameters set for this basic mode.\n  \n**warning**\n\nMessage decryption should be done on the user frontend if possible, not via server callbacks.**\n\n#### Encryption/Decryption example on the console - basic mode\n\nFirst, generate a normal metadata transaction message. \n\n**normal-message-metadata.json**:\n``` json\n{\n  \"674\": {\n    \"msg\": [\"Invoice-No: 123456789\",\"Order-No: 7654321\",\"Email: john@doe.com\"]\n  }\n}\n```\n\nThe **encryption** is done on the **whole content of the `msg:` key**, so this is\n  \n`[\"Invoice-No: 123456789\",\"Order-No: 7654321\",\"Email: john@doe.com\"]`\n \nin our example.\n  \n**Encrypt** this content via openssl, the default passprase **cardano**, iteration set to 10000 and key-derivation via pbkdf2:\n``` console\necho -n '[\"Invoice-No: 123456789\",\"Order-No: 7654321\",\"Email: john@doe.com\"]' | openssl enc -e -aes-256-cbc -pbkdf2 -iter 10000 -a -k \"cardano\"\n```\n\nThe encrypted result are the **base64 encoded strings**:\n```\nU2FsdGVkX1/5Y0A7l8xK686rvLsmPviTlna2n3P/ADNm89Ynr1UPZ/Q6bynbe28Y\n/zWYOB9PAGt+bq1L0z/W2LNHe92HTN/Fwz16aHa98TOsgM3q8tAR4NSqrLZVu1H7\n```\n\nCompose the JSON by **using the base64 encoded encrypted strings now for the `msg:` part**.\n                                                                \nAlso add the value `basic` for the `enc:` key, to mark this transaction message as encrypted with basic mode. \n\n**encrypted-message-metadata.json**:\n``` json\n{ \n  \"674\":\n         { \n           \"enc\": \"basic\",\n           \"msg\": \n                 [ \n                   \"U2FsdGVkX1/5Y0A7l8xK686rvLsmPviTlna2n3P/ADNm89Ynr1UPZ/Q6bynbe28Y\",\n                   \"/zWYOB9PAGt+bq1L0z/W2LNHe92HTN/Fwz16aHa98TOsgM3q8tAR4NSqrLZVu1H7\"\n                 ]\n         }\n}\n```\n\nConsole one-liner:\n``` console\njq \".\\\"674\\\".msg = [ $(jq -cjrM .\\\"674\\\".msg normal-message-metadata.json | openssl enc -e -aes-256-cbc -pbkdf2 -iter 10000 -a -k \"cardano\" | awk {'print \"\\\"\"$1\"\\\",\"'} | sed '$ s/.$//') ]\" <<< '{\"674\":{\"enc\":\"basic\"}}' | tee encrypted-message-metadata.json | jq\n``` \n\n---\n  \nA **decryption** can be done in a similar way:\n``` console\njq -crM \".\\\"674\\\".msg[]\" encrypted-message-metadata.json | openssl enc -d -aes-256-cbc -pbkdf2 -iter 10000 -a -k \"cardano\"\n```\n\nWhich results in the original content of the **msg** key:\n  \n`[\"Invoice-No: 123456789\",\"Order-No: 7654321\",\"Email: john@doe.com\"]`\n\n## Rationale\n\nThis design is simple, so many tools on the cardano blockchain can adopt it easily and a few have already started to implement it.\nThe original CIP-0020 design allowed the addition of new entries like the `\"enc\":` key for encrypted messages in this CIP. Therefore the encoding format of the encrypted message was choosen to be UTF-8 instead of bytearrays, because it would break the backwards compatibility to CIP-0020. But maybe more important, it gives the user a simple text-format to handle such messages. Users can copy and paste the base64 encoded string(s) using there own tools for creation and verification. For example, a user can simply copy the encrypted format from an explorer and verify it with an external own local tool. Such messages are usally pretty short. Yes, the benefit of using bytearrays is to have less data (around -33% over base64), but the decision was made to sacrifice this benefit in favor of the base64 format for the reasons pointed out before.\n\nThere is also for example [CIP-8](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008), but CIP-8 doesn't really fulfill the simplicity of just providing encrypted messages. CIP-8 is focused on Signing, which is not needed for encryption. The method to generate encrypted messages here is not intended to verify the owner of a message via signing. There is no need that everything on Cardano must be difficult. Also using such CBOR encoded structures would break all currently implemented transaction message solutions. This CIP uses openssl and base64 encoding, and endusers could even copy&paste such text into other tools, etc. Future updates may include the option to mix encrypted and unencrypted messages by adding another key like `msgclear` to support such a mixed message style format.\n\n### Implementation suggestions\n \nWallets/Tools can implement an autodecryption attempt with the default passphrase on such messages, to give the user a more streamlined experience. The communication should be done via https or similar to make sure the message cleartext is not exposed again during the transmission.\nAdditionally the Tools can prompt for an input and decrypt the message once the user has requested it, this decryption should be done on the user frontend for further security.\n\n### Handling ill-formed 674 metadata ##\n\nLike with CIP-0020, it is up to the wallet-/display-/receiver-implementor to parse and check the provided metadata. As for the current state, its not possible to have the same label \"674\" more than once in a cardano transaction. So a check about that can be ignored at the moment. This CIP provides the correct implementation format, the parsing should search for the \"674\" metadata label, the \"msg\" and the \"enc\" key underneath it. There should also be a check, that the provided data within that \"msg\" key is an array. All other implementations like a missing \"msg\" key, or a single string instead of an array, should be marked by the display-implementor as \"invalid\". Additional keys within the \"674\" label should not affect the parsing of the \"msg\" and the \"enc\" key. As written above, we will likely see more entries here in the future like a \"version\" key for example, so additional keys should not harm the parsing of the \"msg\" and \"enc\" key. \n\n### Implementation conclusion ##\n\nAn encrypted transaction message should be considered valid if the following apply:\n\n* Label = 674.\n* has property \"enc\".\n* enc property contains a supported method like `basic`\n* has property \"msg\".\n* msg property contains an array of strings, even for a single-line message.\n* Each line has a maximum length of 64 characters.\n* If there are additional properties, they don't invalidate the message. They can just be ignored.\n\nIf any of the above is not met, ignore the metadata as an encrypted transaction message. Can still be displayed as general metadata to the transaction.\n\nThe implementation format in this CIP should be the ground base for encrypted transaction messages/comments/memos and should be respected by creator-/sender-implementations as well as in wallet-/receiver-/display-implementations.\n\n## Path to Active\n\n### Acceptance Criteria\n\nThe acceptance criteria to be `Active` should already have been met, because the following Implementors using this CIP on the Cardano Blockchain:\n\n* Cardano Explorer (https://cexplorer.io)\n* StakePoolOperator Scripts (https://github.com/gitmachtl/scripts)\n* AdaStat.net (https://adastat.net)\n* Eternl Wallet (https://eternl.io)\n\n#### Integration examples for encrypted messages\n\n**Cexplorer.io**: With the implementation of the **encrypted message decoding**.\n![image](https://user-images.githubusercontent.com/47434720/204560392-f45bbe4f-7f78-48fa-9e47-4d3b104685bf.png)\n\n**StakePool Operator Scripts**: It works on the commandline like any other script of the collection by just adding the `\"enc: basic\"` parameter, you can provide an individual passphrase by using the `\"pass:<passphrase>\"` parameter. This automatically generates the needed metadata.json structure with the encrypted message in it and attaches it to the transaction itself.\n![image](https://user-images.githubusercontent.com/47434720/205442737-748a7fb0-90fc-4cc3-898c-98b06894a900.png)\n\n**Eternl.io**:\n![image](https://user-images.githubusercontent.com/47434720/210166917-8af475fe-5cda-46f5-bd8d-3fc4c2c12482.png)\n    \n**AdaStat.net**: With the implementation of the **encrypted message decoding** using a pure **frontend solution**.\n![image](https://user-images.githubusercontent.com/47434720/206574191-22aa490a-5870-4853-906b-443284458987.png)\n![image](https://user-images.githubusercontent.com/47434720/206574354-5dd81551-efc6-4f69-a2aa-282bb40e5084.png)\n\n\n### Implementation Plan\n\nThe following Projects have committed to also implement it:\n\n* CNTools (https://cardano-community.github.io/guild-operators/#/Scripts/cntools)\n* JorManager (https://bitbucket.org/muamw10/jormanager/)\n* Cardanoscan.io (https://cardanoscan.io)\n\nThe plan is to reach out to other projects - which already supporting the normal transaction messages - too. And of course also to new ones.\n\nThere are various **code samples available** in the [**codesamples**](codesamples/) folder to make it as easy as possible for integrators to implement it.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n"
  },
  {
    "path": "CIP-0083/codesamples/democode-BASH.sh",
    "content": "#!/bin/bash\n\n# --------------------------------------------------------------------------------------------\n# Demonstration implementation of CIP-0020 Transaction Messages Encryption/Decryption via BASH\n# --------------------------------------------------------------------------------------------\n\n#Setting default passphrase\npassphrase=\"cardano\"\n\n\n#Unencrypted Metadata JSON\necho \"Normal unencrpted messages metadata JSON:\"\ncat normal-message-metadata.json | jq\necho\n\n\n#Encrypt the msg array from the JSON\nencrText=$(jq -crM .\\\"674\\\".msg normal-message-metadata.json | openssl enc -e -aes-256-cbc -pbkdf2 -iter 10000 -a -k \"${passphrase}\")\necho \"Encrypted Strings (base64 format):\"\necho \"${encrText}\"\necho\n\n\n#Compose it into a new JSON and add the 'enc' entry\necho \"New encrypted messages metadata JSON:\"\njq \".\\\"674\\\".msg = [ $(awk {'print \"\\\"\"$1\"\\\",\"'} <<< ${encrText} | sed '$ s/.$//') ]\" <<< '{\"674\":{\"enc\":\"basic\"}}' | jq\n\n\necho\necho \"----------------------\"\necho\n\n\n#Encrypted Metadata JSON\necho \"Encrypted messages metadata JSON:\"\ncat encrypted-message-metadata.json | jq\necho\n\n\n#Decrypt the msg array from the JSON\ndecrText=$(jq -crM \".\\\"674\\\".msg[]\" encrypted-message-metadata.json | openssl enc -d -aes-256-cbc -pbkdf2 -iter 10000 -a -k \"${passphrase}\")\necho \"Decrypted Content:\"\necho \"${decrText}\"\necho\n\n\n#Compose it into a new JSON in the standard message format\necho \"New messages metadata JSON:\"\njq \".\\\"674\\\".msg = ${decrText}\" <<< \"{}\"\necho\n"
  },
  {
    "path": "CIP-0083/codesamples/democode-NODEJS.js",
    "content": "// -----------------------------------------------------------------------------------------------\n// Demonstration implementation of CIP-0020 Transaction Messages Encryption/Decryption via NODE-JS\n// -----------------------------------------------------------------------------------------------\n\nconst crypto = require('crypto');\n\n//\n// Calculate the KeyIV via the PasswordBasedKeyDerivedFormat2 pbkdf2 method, 10000 iterations, 48 bytes long, sha256\n//\nfunction calc_KeyIV(passphrase, salt) { //passphrase as utf8 string, salt as hexstring\n\tconst key_IV = crypto.pbkdf2Sync(Buffer.from(passphrase,'utf8'), Buffer.from(salt,'hex'), 10000, 48, 'sha256').toString('hex')\n\tconsole.log(`              keyIV: ${key_IV}`);\n\treturn key_IV;  //hex-string\n}\n\n//\n// Encryption Function\n//\nfunction encryptCardanoMessage(decrypted_msg, passphrase = 'cardano') { //decrypted_msg as utf8 string, passphrase as utf8 string(defaults to cardano)\n\t//Encrypted Message (salted) looks like 'Salted__' + 8 bytes salt + cyphertext\n\t//Build up the encrypted Message as hex string\n\tvar encrypted_hex = Buffer.from('Salted__','utf8').toString('hex');\n\t//Generate the random salt\n\tvar salt = crypto.randomBytes(8).toString('hex');\n\tencrypted_hex += salt; //append the salt\n\tconsole.log(`               salt: ${salt}`);\n\t//Calculate the Key+IV\n\tvar keyIV = calc_KeyIV(passphrase, salt)\n\t//The key itself is the first 32 Bytes (char 0-64 in hex string)\n\tvar key = keyIV.substring(0,64);\n\t//The IV (initialization vector) is 16 Bytes and follows the key\n\tvar iv = keyIV.substring(64);\n\tconsole.log(`                key: ${key}`);\n\tconsole.log(`                 iv: ${iv}`);\n\t//Encrypt the message\n  \tconst cipher = crypto.createCipheriv('aes-256-cbc', Buffer.from(key,'hex'), Buffer.from(iv,'hex'));\n\ttry {\n\t\tvar cyphertext = cipher.update(decrypted_msg, 'utf8', 'hex') + cipher.final('hex');\n\t} catch (error) { console.error(`Could not encrypt the message\\n${error}`); process.exit(1); }\n\tconsole.log(`         cyphertext: ${cyphertext}`);\n\tencrypted_hex += cyphertext; //append the cyphertext\n\tconsole.log(`   Enc-Message(hex): ${encrypted_hex}`);\n\treturn Buffer.from(encrypted_hex,'hex').toString('base64'); //base64 string\n}\n\n\n//\n// Decryption Function\n//\nfunction decryptCardanoMessage(encrypted_msg, passphrase = 'cardano') { //encrypted_msg as base64 string, passphrase as utf8 string(defaults to cardano)\n\t//Encrypted Message is base64 encoded, convert it to hex\n\tconst encrypted_hex = Buffer.from(encrypted_msg, 'base64').toString('hex');\n\tconsole.log(`   Enc-Message(hex): ${encrypted_hex}`);\n\t//Encrypted Message (salted) looks like 'Salted__' + 8 bytes salt + cyphertext\n\t//Salt is byte 9-16 in the Encrypted Message (char 16-32 in a hex string)\n\tvar salt = encrypted_hex.substring(16,32);\n\tconsole.log(`               salt: ${salt}`);\n\t//Cyphertext is all the rest after the salt (starting with char 32 in a hex string)\n\tvar cyphertext = encrypted_hex.substring(32);\n\tconsole.log(`         cyphertext: ${cyphertext}`);\n\t//Calculate the Key+IV\n\tvar keyIV = calc_KeyIV(passphrase, salt)\n\t//The key itself is the first 32 Bytes (char 0-64 in hex string)\n\tvar key = keyIV.substring(0,64);\n\t//The IV (initialization vector) is 16 Bytes and follows the key\n\tvar iv = keyIV.substring(64);\n\tconsole.log(`                key: ${key}`);\n\tconsole.log(`                 iv: ${iv}`);\n\t//Decrypt the cyphertext with the key and the iv\n\tconst decipher = crypto.createDecipheriv('aes-256-cbc', Buffer.from(key,'hex'), Buffer.from(iv,'hex'));\n\ttry {\n\t\tvar decr_msg = decipher.update(cyphertext, 'hex').toString('utf8') + decipher.final('utf8');\n\t} catch (error) { console.error(`Could not decrypt the message\\n${error}`); process.exit(1); }\n\treturn decr_msg; //utf8\n}\n\n//-------------------------\n// DEMO Encrypt and Decrypt\n//-------------------------\n\nconst passphrase = 'cardano'; //Using default passphrase 'cardano'\n\n// Encryption\nconsole.log(`--- Encryption ---`);\nvar decrypted_msg = 'Hi, this is a test-message. Best regards, Martin';\nconsole.log(`  Dec-Message(utf8): ${decrypted_msg}`)\nvar encrypted_msg = encryptCardanoMessage(decrypted_msg, passphrase);\nconsole.log(`Enc-Message(base64): ${encrypted_msg}`);\nconsole.log(`\\n\\n`);\n\n// Decryption\nconsole.log(`--- Decryption ---`);\nvar encrypted_msg = 'U2FsdGVkX18UshV/vpKWoYtutcS2efoloN+okKMY+pYdvUnqi88znUhHPxSSX8t4';\nconsole.log(`Enc-Message(base64): ${encrypted_msg}`);\nvar decrypted_msg = decryptCardanoMessage(encrypted_msg, passphrase);\nconsole.log(`  Dec-Message(utf8): ${decrypted_msg}`)\nconsole.log(`\\n\\n`);\n"
  },
  {
    "path": "CIP-0083/codesamples/democode-PHP.php",
    "content": "// ------------------------------------------------------------------------------------------\n// Demonstration implementation of CIP-0020 Transaction Messages Encryption/Decryption via PHP\n// ------------------------------------------------------------------------------------------\n\n<?php\n\nconst debug = true;\n\nfunction elapsedTime($start) {\n    $elapsed = microtime(true) - $start;\n    if ($elapsed < 1) {\n        return ($elapsed * 1000) . \" milliseconds\";\n    } else if ($elapsed > 60) {\n        return ($elapsed / 60) . \" minutes\";\n    } else {\n        return $elapsed . \" seconds\";\n    }\n}\n\nfunction getPbkdf2($password, $salt, $iterations) {\n    return openssl_pbkdf2($password, $salt, 48, $iterations, 'sha256');\n}\n\nfunction encryptCardanoMessage($msg, $password = 'cardano', $iterations = 10000) {\n    if (debug) {\n        $start = microtime(true);\n    }\n    $salt          = openssl_random_pseudo_bytes(8);\n    $encryptedText = \"Salted__\" . $salt;\n\n    $keyIV = getPbkdf2($password, $salt, $iterations);\n    $key   = substr($keyIV, 0, 32);\n    $iv    = substr($keyIV, 32);\n\n    $encryptedText       .= openssl_encrypt($msg, 'aes-256-cbc', $key, OPENSSL_RAW_DATA, $iv);\n    $hashedEncryptedText = base64_encode($encryptedText);\n\n    if (debug) {\n        echo \"Done encrypting message in \" . elapsedTime($start) . \"\\r\\n\";\n    }\n\n    return $hashedEncryptedText;\n}\n\nfunction decryptCardanoMessage($msg, $password = 'cardano', $iterations = 10000) {\n    if (debug) {\n        $start = microtime(true);\n    }\n\n    $encryptedText = base64_decode($msg);\n    $salt          = substr($encryptedText, 8, 8);\n    $cyphertext    = substr($encryptedText, 16);\n\n    $keyIV = getPbkdf2($password, $salt, $iterations);\n    $key   = substr($keyIV, 0, 32);\n    $iv    = substr($keyIV, 32);\n\n    $decrypted = openssl_decrypt($cyphertext, 'aes-256-cbc', $key, OPENSSL_RAW_DATA, $iv);\n\n    if (debug) {\n        echo \"Done decrypting message in \" . elapsedTime($start) . \"\\r\\n\";\n    }\n\n    return $decrypted;\n}\n\n$payload = \"Testing message signing...\";\n\n// Basic signed/encrypted message w/ default password of \"cardano\"\n$signed = encryptCardanoMessage($payload);\n\n// Basic signed/encrypted message w/ custom password\n$passwordSigned = encryptCardanoMessage($payload, \"You'll never guess it!\");\n\n// Basic signed/encrypted message w/ custom password and fewer iterations\n$shortPasswordSigned = encryptCardanoMessage($payload, \"Please\", 20);\n\n// Basic decoding w/ default password of \"cardano\"\n$unsigned = decryptCardanoMessage($signed);\necho \"\\$signed is: {$unsigned}\\r\\n\";\n\n// Basic decoding w/ custom password\n$unsignedPassword = decryptCardanoMessage($passwordSigned, \"You'll never guess it!\");\necho \"\\$passwordSigned is: {$unsignedPassword}\\r\\n\";\n\n// Basic decoding w/ custom password and fewer iterations\n$shortUnsigned = decryptCardanoMessage($shortPasswordSigned, \"Please\", 20);\necho \"\\$shortPasswordSigned is: {$shortUnsigned}\\r\\n\";\n"
  },
  {
    "path": "CIP-0083/codesamples/democode-WEB.js",
    "content": "// -----------------------------------------------------------------------------------------------\n// Democode for running a Decryption on the Web Frontend - Method BASIC\n// -----------------------------------------------------------------------------------------------\n\n// Library that is used for this codesample: https://www.npmjs.com/package/crypto-js\n// Just import it before using this code\n\nlet encrypted = \"U2FsdGVkX18IJMMB5MDfNmuvvlbu4m5ODGmCrHHtWfYKarTRT4/x790+uhsj7cgRxDFvjxU7dcSPqH5PAXvRtPcaRyqoYBaXOQbm3D78wQCY4wCiLF1/mFOvFHPfpQHeC9jykRfpaVC3rtlJdHCPTw==\"\nlet encryptedWA = cryptoJS.enc.Base64.parse(encrypted);\n\n// Split the encrypted data into the individual pieces\nlet prefixWA = cryptoJS.lib.WordArray.create(encryptedWA.words.slice(0, 8/4)); // Salted__ prefix\nlet saltWA = cryptoJS.lib.WordArray.create(encryptedWA.words.slice(8/4, 16/4)); // 8 bytes salt: 0x0123456789ABCDEF\nlet ciphertextWA = cryptoJS.lib.WordArray.create(encryptedWA.words.slice(16/4, encryptedWA.words.length)); // ciphertext        \n\n// Determine key and IV using PBKDF2\nlet password = 'cardano'\nlet keyIvWA = cryptoJS.PBKDF2(\n  password, \n  saltWA, \n    {\n      keySize: (32+16)/4, // key and IV\n      iterations: 10000,\n      hasher: cryptoJS.algo.SHA256\n    }\n);\nlet keyWA = cryptoJS.lib.WordArray.create(keyIvWA.words.slice(0, 32/4));\nlet ivWA = cryptoJS.lib.WordArray.create(keyIvWA.words.slice(32/4, (32+16)/4));\n\n// Decrypt the data\nlet decryptedWA = cryptoJS.AES.decrypt(\n  {\n    ciphertext: ciphertextWA}, \n                keyWA, \n                {iv: ivWA}\n);\nlet decrypted = decryptedWA.toString(cryptoJS.enc.Utf8)\n\nconsole.log(`Encrypted Data:`)\nconsole.log(encrypted)\nconsole.log(`Decrypted Data:`)\nconsole.log(decrypted)\n"
  },
  {
    "path": "CIP-0083/codesamples/encrypted-message-metadata.json",
    "content": "{ \n  \"674\":\n         { \n           \"enc\": \"basic\",\n           \"msg\": \n                 [ \n                   \"U2FsdGVkX1/5Y0A7l8xK686rvLsmPviTlna2n3P/ADNm89Ynr1UPZ/Q6bynbe28Y\",\n                   \"/zWYOB9PAGt+bq1L0z/W2LNHe92HTN/Fwz16aHa98TOsgM3q8tAR4NSqrLZVu1H7\"\n                 ]\n         }\n}\n"
  },
  {
    "path": "CIP-0083/codesamples/normal-message-metadata.json",
    "content": "{\n  \"674\": {\n    \"msg\": [\"Invoice-No: 123456789\",\"Order-No: 7654321\",\"Email: john@doe.com\"]\n  }\n}\n"
  },
  {
    "path": "CIP-0083/format.cddl",
    "content": "string = text .size (0..64) ; utf-8\n\nmessage_details = \n  {\n    msg : [* string], \n    ? enc : string\n  }\n\n; msg = array of utf-8 encoded strings\n; enc = optional string with the encryption-method\n;       'plain' => no encryption (optional)\n;       'basic' => encryption-method basic\n\nmessagedata = { 674 : uint => label_metadata }\n"
  },
  {
    "path": "CIP-0084/README.md",
    "content": "---\nCIP: 84\nTitle: Cardano Ledger Evolution\nStatus: Active\nCategory: Meta\nAuthors: \n  - Jared Corduan <jared.corduan@iohk.io>\nImplementors: N/A\nCreated: 2023-01-30\nDiscussions: \n  - https://github.com/cardano-foundation/CIPs/pull/456\nLicense: CC-BY-4.0\n---\n\n\n## Abstract\n\nThis CIP provides guidance for future CIPs concerning the Cardano ledger.\n\n## Motivation: why is this CIP necessary?\n\nThe ledger is responsible for processing transactions and updating the shared state of the network.\nIt also processes block headers and handles the state transformation from one epoch to the next\n(e.g. computing the staking rewards).\n\nMost of the state maintained by the ledger relates to the\n[Extended UTxO accounting model](https://iohk.io/en/research/library/papers/the-extended-utxo-model/) and\nsupport for [Ouroboros](https://iohk.io/en/research/library/papers/ouroboros-a-provably-secure-proof-of-stake-blockchain-protocol/),\nthe proof-of-stake consensus mechanism used in Cardano.\n\nThis CIP aims to give guidance for future CIPs related to the ledger,\nmaking it a registered category of the CIP process[^1].\n[^1]: See [CIP-1](https://github.com/cardano-foundation/CIPs/blob/cip-cps-rework/CIP-0001/README.md#categories).\nWhile nothing new is added to the usual CIP process,\nexpectations for ledger CIPs are made explicit and some background information is provided.\n\nMany thanks to Arnaud Bailly and Michael Peyton Jones for all their help reviewing and providing\nfeedback on the first versions of this CIP.\n\n## Specification\n\n### Terminology\n\nContext for the terminology used in this document is given in [CIP-59].\n\n### Specifications\n\nThe ledger is specified as a state transition system using a\n[small step operational semantics](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/small-step-semantics.pdf).\nWe refer to this framework as the *Small Step Semantics for Cardano*, or the *STS* for short.\nAn understanding of the existing STS specifications for the\nexisting ledger eras is often required to fully understand the implications of changes to the ledger\n(though an understanding of the Haskell implementation is a fair substitute).\n\nThe STS framework leaves both cryptographic primitives and the serialization format abstract.\nThe STS specifications need to be complete enough to realize a full implementation of the ledger\ngiven the cryptographic primitives and serialization format.\nThe cryptographic primitives are described as appendices to the STS specifications,\nand the serialization format is given as a\n[CDDL file](https://www.rfc-editor.org/rfc/rfc8610).\nThere SHOULD be one STS specification per ledger era.\n\nFrom the Byron to the Babbage ledger eras, the STS frameworks were written in $\\LaTeX$.\nStarting in the Conway ledger era, literate Agda will be used.\nDuring the transition from $\\LaTeX$ to literate Agda, we will take advantage\nof the ability to substitute $\\LaTeX$ in place of Agda code when needed for expedience.\nWith time, the Agda specification will not only be used to provide PDF specifications,\nbut also reference implementations.\n\n### Ledger eras\n\nA ledger era is a collection of features added to the ledger which are introduced at a hard fork.\nThe existing ledger eras, with very simplistic descriptions, are given below.\n\n|name|new features|link|\n| --- | --- | --- |\n|Byron|initial UTxO ledger|[spec](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/byron-ledger.pdf)|\n|Shelley|decentralized block production, stake delegation|[spec](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/shelley-ledger.pdf)|\n|Allegra|timelock scripts|-|\n|Mary|multi-assets|[spec](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/mary-ledger.pdf)|\n|Alonzo|Plutus scripts|[spec](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/alonzo-ledger.pdf)|\n|Babbage|improved Plutus script contexts|[spec](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/babbage-ledger.pdf)|\n|Conway|governance|[spec WIP](https://github.com/input-output-hk/formal-ledger-specifications)|\n\nNote that there is no Allegra specification.\nThe Allegra era consists entirely of the addition of timelocks to the MultiSig script\nintroduced in the Shelley ledger era\n(See figure 12 of the Mary specification).\n\nNote that small, isolated changes can be made within a ledger era\nby way of an intra-era hard fork. See [CIP-59] for more details.\n\n#### Ledger events\n\nSome provenance about the ledger calculations is provided by ledger events.\nSometimes these events have clear triggers (e.g. Plutus script execution)\nand sometimes they provide intermediate calculations performed by the ledger rules\n(e.g. the reweard calculation).\nThe events come with zero cost to a running node if not used and are not stored in the ledger state.\nDocumentation about the existing events can be found\n[here](https://github.com/input-output-hk/cardano-ledger/blob/master/docs/LedgerEvents.md).\n\n### Soft forks and Hard forks\n\nSince most ledger CIPs will involve backwards incompatible changes,\nthe following two definitions are helpful:\n\n**Hard fork** - A *hard fork* is a change to the protocol (not restricted to the ledger)\nresulting in a single new block definition becoming valid.\n\nAlternatively, a hard fork is a backwards incompatible change for both\nblock producers and block validators.\n\n**Soft fork** - A *soft fork* is a change to the protocol (not restricted to the ledger)\nresulting in fewer blocks being valid.\n\nAlternatively, a soft fork is a backwards incompatible change for\nblock producers, but a backwards compatible change for block validators.\n\n### Serialization\n\nTransactions and blocks are serialized with\n[CBOR](https://www.rfc-editor.org/rfc/rfc7049)\nand specified with\n[CDDL file](https://www.rfc-editor.org/rfc/rfc8610).\n\nSerialization changes to the ledger are discussed in\n[CIP-80](https://github.com/cardano-foundation/CIPs/pull/372).\n\nNote that the serialisation format of the ledger state is unspecified and left as an\nimplementation detail (unlike the format of blocks).\n\n### The ledger-script interface\n\nThe ledger and Plutus scripts have a common interface, described in [CIP-35].\nCIPs relating to this inteface are relevant to both the ledger and to the Plutus CIP categories.\n\nAdditionally, there is significant overlap with the Ledger category around the ledger-script\ninterface and the protocol parameters.\nCIPs which change these parts of Cardano should generally use the Plutus category and not the\nLedger category, although the Editors may ask the Ledger reviewers to comment.\n\n\n### What merits a ledger CIP?\n\nThe criterion for deciding if a change to the ledger merits a CIP is as follows:\nchanges to the ledger require going through the CIP process whenever\nevery implementation of the Cardano ledger needs to be standardized on the details.\n\nBug fixes are an exception to this criterion, they do not merit a CIP except in the case\nthat the fix is substantially complicated.\nA \"bug fix\" is a change to behavior where:\n- The implemented behavior does not match the specification; or\n- The specified behavior is clearly wrong (in the judgment of relevant experts)\n\nSerialization changes are another possible exception to the criterion.\nMany serialization changes can be handled as a part of the normal development process\nwithout the need for a CIP.\nDramatic changes to the serialization, however, may benefit from the CIP process.\n\nThe ledger rules MUST be standardized in order for consensus to be maintained,\nbut things like the ledger events are more open to debate.\n\nChanges to the protocol parameter values do not require a CIP since they are\na governance issue (see [CIP-1694]).\n\n### Expectations for ledger CIPs\n\n* Familiarity with the existing ledger specifications is required to propose changes to the ledger.\n* The CIP specifications for ledger CIPs must be sufficiently detailed for inclusion in\n  a formal ledger specification.\n* Though proposals can be accepted solely on the basis of peer and Ledger team review, some areas (e.g. changes to the incentives model) might only considered ready for implementation if accompanied by an opinion from an expert designated by the implementor (e.g. with a proper game theoretic analysis).\n\n### The Ledger reviewers\n\nThe following table gives the current set of reviewers for Ledger CIPs.\n\n| Name               | Email                      | GitHub username |\n|--------------------|----------------------------|-----------------|\n| Andre Knispel      | andre.knispel@iohk.io      | @WhatisRT       |\n| Alexey Kuleshevich | alexey.kuleshevich@iohk.io | @lehins         |\n\n## Rationale: how does this CIP achieve its goals?\n\n### There is only one implementation, why limit the scope of ledger CIPs in this way?\n\nEven though there is currently only one implementation, this provides us with a clear\ndefinition of what is essential to the ledger.\nIt also provides a clear path for future implementations.\n\n### Why is the specification vague about the role of ledger events in the CIP process?\n\nThis decision should be left to the community as more use cases emerge.\n\n### Why is familiarity with the formal specifications required?\n\nIt is not always clear which seemingly small details can make a large difference\nto the many consumers of the ledger.\nIt is better that the CIP process achieve consensus on all the details than for\nthese decisions to be made during the implementation phase.\n\n## Path to Active\n\n### Acceptance Criteria\n\nThis CIP requires the acceptance of the Ledger team, which it has in virtue of its authorship.\n\n### Implementation Plan\n\nNo implementation is required.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0][].\n\n[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n[CIP-35]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0035\n[CIP-59]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0059\n[CIP-1694]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-1694\n"
  },
  {
    "path": "CIP-0085/README.md",
    "content": "---\nCIP: 85\nTitle: Sums-of-products in Plutus Core\nAuthors: \n  - Michael Peyton Jones <michael.peyton-jones@iohk.io>\nImplementors: \n  - Michael Peyton Jones <michael.peyton-jones@iohk.io>\nStatus: Active\nCategory: Plutus\nCreated: 2023-01-30\nDiscussions: \n  - https://github.com/cardano-foundation/CIPs/pull/455\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nPlutus Core does not contain any native support for datatypes.\nInstead, users who want to use structured data must _encode_ it; a typical approach is to use [Scott encoding][].\nThis CIP proposes to add native support for datatypes to Plutus Core using sums-of-products (SOPs), and to use that support more efficient scripts, and better code-generation for compilers targeting Plutus Core.\n\n## Motivation: why is this CIP necessary?\n\n### Background\n\n#### 1. Datatypes in Plutus Core\n\nThe first designs of Plutus Core had native support for datatypes.\nIn the interest of keeping the language as small and simple as possible, this was removed in favour of encoding datatype values using [Scott encoding][].\n\n[Experiments](https://github.com/input-output-hk/plutus/blob/96fd25649107658fc911c53e347032bedce624e9/doc/notes/fomega/scott-encoding-benchmarks/results/test-results.md) at the time showed that the performance penalty of using Scott encoding over native datatypes was not too large, and so we could realistically use Scott encoding.\nBut we might expect that we should be able to do better with a native implementation, and indeed we can.\n\n#### 2. 'Lifting' and 'Unlifting'\n\nThis section talks about Haskell, but the same problem applies in other languages.\n\nGiven a Haskell value, how do you translate it into the equivalent Plutus Core term ('lifting')?\nIt's clear what to do for a Haskell value of one of the Plutus Core builtin types (just turn it into a constant), but it's much more complicated for a Haskell value that is a datatype value: you have to know how to do all the complicated Scott-encoding work.\n\nFor example:\n- `1` lifts to `(con integer 1)` (easy enough)\n- `Just 1` lifts to `(delay (lam case_Nothing (lam case_Just [case_Just (con integer 1)])))` (much more complicated)\n\nThis means that it's difficult to specify how to do lifting for structured data.\nFor example, if we want users (or the ledger!) to create Plutus Core terms representing structured data, it will be difficult to explain how to do it.\n\nThere is also the opposite direction: how can we turn a Plutus Core term back into a Haskell value ('unlifting)'?\nAgain, it's clear how to do this for builtin types and very unclear how to do it for datatypes. \nDoing anything with a Scott-encoded datatype usually requires applying it to arguments and _evaluating_ it.\nIt's not reasonable to require the Plutus Core evaluator just to work out what a term means.\n\nFor example:\n- `(con integer 1)` clearly unlifts to `1`\n- `(delay (lam case_Nothing (lam case_Just [caseJust (con integer 1)])))` should unlift to `Just `, but this is hard to see. Scott encodings are not even canonical (there can be many terms that represent the same Scott-encoded value), so it is hard to know what they represent in general.\n\nIn practice this makes Plutus Core terms very opaque and difficult to work with.\n\n#### 3. The `Data` Type\n\nThe design of the EUTXO model rests on passing arguments to the script for the redeemer, datum, and script context.\nBut we hit upon the problem of how to _represent_ this information.\n\nThe first design was to encode each argument as a Plutus Core term (using Scott-encoding for structued data), and pass it directly to the script.\nHowever, this had several problems:\n1. At that point, the on-chain form of Plutus Core was typed, and we would ideally want to typecheck the application before peforming it. But this could be expensive.\n2. As we saw above, Plutus Core terms representing structured data are very opaque, so using them for redeemers and datums would make those values very opaque to users.\n3. Creating the script context would require the ledger to take a Haskell value and lift it into a Plutus Core term, which as we've seen is non-trivial.\n\nThe solution that we chose was to pick a single generic structured data type which would be used for data interchange between the ledger and scripts.\nThis is the `Data` type.\n\nHowever, `Data` is not the natural representation of structured values inside a script, that would be as datatypes.\nSo this means we often want a decoding step where the script translates `Data` into its own representation.\n\n### Why change anything?\n\n#### 1. Everything Can Always be Faster\n\nThe Plutus Core interpreter has got a lot faster over the last few years (at least one order of magnitude, possibly two by now).\nHowever, there continues to be relentless pressure on script resource usage.\nThis will always be the case: no matter how fast we make things, things can _always_ be faster or cheaper and it will improve throughput and save people money.\n\nThat means that significant performance gains are always compelling.\n\n#### 2. Creating and Analyzing Plutus Core Terms is Difficult\n\nAs discussed above, both lifting and unlifting are currently very tricky or impossible.\n\n#### 3. Working with Data is Clumsy and Slow\n\nThe `Data` type is used in many places as a representation of structured data:\n1. The script context is represented as `Data`\n2. Some language toolchains that target PLC use `Data` for all structured data, rather than Scott encoding or similar.\n\nHowever, working with `Data` is not very pleasant.\nDeconstructing a datatype encoded as `Data` requires multiple steps, each of which has to go through the builtins machinery, which imposes additional overhead.\nOur benchmarks show that this is very 3x slower even than Scott encoding datatypes.\n\n## Specification\n\n### Plutus Core Changes\n\nThe following new term constructors are added to the Plutus Core language:[^typed-plutus-core]\n```\n\nt ::=\n  ...\n\n  -- Packs the fields into a constructor value tagged with i\n  | (constr i t...)\n  -- Inspects the tag on t and passes its fields to the corresponding case branch\n  | (case t t...)\n```\n\nTags start from 0, with 0 being the first case branch, and so on.\n\n[^typed-plutus-core]: See Appendix 1 for changes to Typed Plutus Core.\n\nThe small-step reduction rules for these terms are:\n\n$$\n\\mathrm{CONSTR\\_{SUB\\_i}}\\frac{i \\in [0, n], t_i \\rightarrow t'_i}{(\\mathrm{constr}\\ e\\ t_0 \\ldots t_n) \\rightarrow (\\mathrm{constr}\\ e\\ t_0 \\ldots t_i' \\ldots t_n)}\n$$\n\n$$\n\\mathrm{CASE\\_SUB}\\frac{t \\rightarrow t'}{(\\mathrm{case}\\ t\\ c_0 \\ldots c_m) \\rightarrow (\\mathrm{case}\\ t'\\ c_0 \\ldots c_m)}\n$$\n\n$$\n\\mathrm{CASE\\_EVAL}\\frac{e \\in [0,m]}{(\\mathrm{case}\\ (\\mathrm{constr}\\ e\\ t_0 \\ldots t_n)\\ c_0 \\ldots c_m) \\rightarrow [c_e\\ t_0 \\ldots t_n]}\n$$\n\n$$\n\\mathrm{CASE\\_NOBRANCH}\\frac{e \\notin [0,m]}{(\\mathrm{case}\\ (\\mathrm{constr}\\ e\\ t_0 \\ldots t_n)\\ c_0 \\ldots c_m) \\rightarrow (\\mathrm{error})}\n$$\n\nNote that `CASE_SUB` does not reduce branches and `CASE_EVAL` preserves only the selected case branch.\nThis means that only the chosen case branch is evaluated, and so `case` is _not_ strict in the other branches.[^strict]\n\n[^strict]: See 'Why is case not strict?' for more discussion.\n\nAlso, note that case branches are arbitrary terms, and can be anything which can be applied.\nThat means that, for example, it is legal to use a builtin as a case branch, or an expression which evaluates to a function.\nHowever, the most typical case will probably be a literal lambda.\n\nA new Plutus Core minor language version 1.1.0 is added to indicate support for these terms.\nThey are illegal before that version.\n\n#### Costing\n\nAll steps in the CEK machine have costs, all of which are constant.\nThere are cost model parameters which set the costs for each step.\nThis will therefore be new cost model paramters governing the costs for the steps for evaluating `constr` and `case`.\n\nThere is a potential problem because `constr` and `case` have a variable number of children, unlike all the existing constructs. The risk is that we could end up doing a linear amount of work but only paying a constant cost.\n\nHowever:\n- `constr`s arguments are all evaluated in turn, so we are sure to pay a linear price.\n- `case`'s branches are _not_ all evaluated, but the only place we could do a linear amount work is in selecting the chosen branch. But this can be avoided in the implementation by storing the cases in a datastructure with constant-time indexing.\n\n## Rationale: how does this CIP achieve its goals?\n\n### Benefits\n\n#### 1. Faster Processing of Structured Data\n\nMost Plutus Core programs spend a significant amount of their time operating on datatypes, so we would expect that a performance improvement here would make a significant difference.\n\nIndeed, this seems to be true.\nOur benchmarks show that this CIP leads to:\n\n1. A 0-30% real-time speedup in example programs that do generic computation work, versus Scott encoding[^scott-vs-data] (the 0% is a primality tester that is mostly doing arithmetic, the 30% is mostly doing data manipulation). \n2. A small global slowdown of 2-4%.\n\nNote that the speedup from point 1 is inclusive of the slowdown from point 2.\n\n[^scott-vs-data]: See \"Can't we just implement datatypes using `Data` itself?\" for comparison with using `Data` directly.\n\n#### 2. Simple Lifting and Unlifting\n\nToday, lifting is complicated, and unlifting is mostly impossible.\nWith this CIP lifting becomes very simple, and unlifting becomes not only possible but simple.\nOur prototype implementation contains code-generation to generate lifting and unlifting code in Haskell, but it is straightforward enough that you could easily do it in any language.\n\nThere are still some limitations, e.g. you cannot lift or unlift structures that contain functions, but this is not that unusual (similarly, you typically can't serialise such structures).\n\n### Costs\n\nThe costs of this proposal are substantial.\n\nPlutus Core today has only 8 kinds of term, this proposal adds 2 more, an increase of 25%.\nAdditionally, the new term types are the first term types which have a variable number of children.\nBoth of these changes increase implementation complexity throughout the system: everything that processes Plutus Core terms must now handle the new cases, and handle the variable numbers of children.\n\nThis change also modestly expends our novelty budget.\nPlutus Core is a deliberately conservative language: for the most part it is just the untyped lambda calculus.\nThe proposed new features for sums-of-products are also conservative, and follow a very typical pattern.\nBut they are not _quite_ as standard as the untyped lambda calculus.\n\nMoreover, a change like this would be very painful to reverse, so we should seriously consider the costs before proceeding.\n\n### Discussion\n\n#### Why is case not strict?\n\nThis makes it different to all other Plutus Core terms, but we believe it is the expected behaviour: _no_ language has strict case destructuring.\n\nConsider e.g.\n\n```haskell\ncase (Just 1) of \n   Just x -> print \"Success!\"\n   Nothing -> error \"Failure!\"\n```\n\nEven in a strict language like Rust, nobody would expect this to evaluate the `Nothing` branch and evaluate to an error.\n\nFurthermore, this additional laziness has significant performance benefits, see Appendix 2 for more discussion.\n\n#### Can't we just implement datatypes using `Data` itself?\n\n`Data` is expressive enough to encode datatypes, indeed this is why it is possible to encode the script context into it.\nIt's performant enough that people who work with the script context as `Data` are able to get by.\nMoreover, lifting and unlifting to `Data` is very easy.\nSo why not just use it to encode _all_ datatypes?[^aiken]\n\n[^aiken]: The Aiken language does this.\n\nThere are two reasons:\n\n1. `Data` cannot contain functions, so it's less expressive than either SOPs or Scott-encoding.\n2. The performance is much worse.\n\nTo justify 2, we benchmarked some list processing using datatypes implemented with SOPs and with `Data`, and the `Data` version is over 3x worse (not accounting for overhead, so the real figure may be higher).\n\n### Alternatives\n\n#### 1. Use Sums _and_ Products Instead\n\nThe current solution is a sums-of-products solution, i.e. we have an introduction and elimination form for objects that have _both_ a tag and a list of fields.\nWe could instead separate these two parts out and have an introduction and elimination form for sums, likewise for products.\n\nThat would look something like this:\n```\nt ::=\n  ...\n\n  -- Tags a term with a tag\n  | (tag i t)\n  -- Inspects a tagged term for the tag, and passes the \n  -- inner term to the case function corresponding to the tag\n  | (case t t...)\n\n  -- Constructs a product with the given fields\n  | (prod t...)\n  -- Accesses the i'th field of the given product\n  | (index i t)\n```\n\nThis is cleaner in some ways, and was the first prototype we implemented, but it has the following problems:\n- It adds two more term constructors to the language\n- It is significantly slower in practice, because the combined operation of processing a sum-of-products is extremely common\n\n#### 2. Bind Case Variables in the Syntax for Case Branches\n\nThe design presented here allows the case branches to be arbitrary terms, which must be evaluated and then applied to the fields.\n\nA more complex design would be to have the bindings for the variables be part of the case expression instead. That is, the current design does this:\n\n```\n(case (constr 1 a b) (\\x -> t1) (\\x y -> t2))\n```\n(the literal lambdas here could be arbitrary terms)\n\nwhereas we could do this:\n\n```\n(case (constr 1 x y) (alt x t1) (alt x y t2))\n```\n\nThe effect of this is that we know statically that we have a function, and we can jump right into evaluating the _body_ of the case branch instead of first having to evaluate it to a function and apply the arguments.\n\nThis saves us a small but meaningful amount of overhead at the cost of making the implementation significantly more complex.\n\nWe prototyped this version and it was noticeably faster (~10%).\nHowever, performance investigations showed that we can realize a significant amount of the performance gain through other means, leaving only about 3% unclaimed.[^see-appendix-2]\nWe think that this is an acceptable cost for a simpler implementation.\n\n[^see-appendix-2]: See Appendix 2 for more details.\n\n#### 3. Unsaturated `constr` and `case`\n\nBoth `constr` and `case` in this proposal are _saturated_, meaning that they have all of the arguments that they need explicitly provided in the AST.\nThis is not the only option. \n\nWe could easily have unsaturated `constr`, by making `(constr i)` a _function_ that then needs to be applied to its arguments. \nThis would be mildly more complicated to implement, since we wouldn't know how _many_ arguments to expect, and so we would need to always be able to add aditional arguments to a `constr` value, but this would be manageable.\n\nUnsaturated `case` is more complicated. \nWhile the tag on the scrutinee `constr` value tells us which branch we are going to take in the end, we don't know how many branches we need in total.\nIn principle we could extend the tags on constructors to include not only the selected tag but also the maximum tag.\nThat would allow us to know how many case branches we need.\nA more serious problem is that we would not be able to be non-strict in the branches any more, as they would be passed as function arguments and hence forced.\n\nThe main advantage of unsaturated `constr` and `case` is that it would avoid the need for n-ary terms in the language, as both would then have a fixed number of children.\nHowever, it makes them more complex to work with, and likely less efficient to implement.\nFinally, this is simply a less common design, and so conservatism suggests sticking to the more standard approach unless there is a compelling reason not to.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] `plutus` changes\n    - [x] Specification \n    - [x] Production implementation\n    - [x] Costing of the new operations\n- [x] `cardano-ledger` changes\n    - [x] Implementation of new ledger language including SOPs\n- [x] Further benchmarking \n    - [x] Ensure that regressions on existing scripts do not occur \n    - [x] Check additional real-world examples\n- [x] Release\n    - [x] New Plutus language version supported in a released node version\n    - [x] New ledger language supported in a released node version\n\n### Implementation Plan\n\nThis plan will be implemented by Michael Peyton Jones and the Plutus Core team with assistance from the Ledger team.\nThe changes will be in the `PlutusV3` ledger language at the earliest, which will probably arrive in the Conway ledger era.\n\n## Appendices\n\n### Appendix 1: Changes to Typed Plutus Core\n\nWhile Typed Plutus Core is not part of the specification of Cardano, it is still interesting and informative to give the changes here.\nPlutus Core was originally conceived of as a typed language, and making sure that we can express the changes cleanly in a typed setting means that we ensure that the semantics make sense and that it will continue to be easy to compile to Plutus Core from typed languages.\n\nWe add one new type constructors and one auxiliary constructor to the type language of Typed Plutus Core:\n```\n-- List of types. This is an auxiliarry syntactic form, not a type!\ntyl ::= [ty...]\n\nty ::= \n  ...\n\n  -- Sum-of-products type, has n children, each of which is a list of types\n  | (sop tyl...)\n```\nThis corresponds to a sum-of-products type, and it has one list of types for each constructor, giving the argument types.\n\nWe add the following new term constructors to the Typed Plutus Core language:\n```\nt ::= \n  ...\n\n  | (constr ty i t...)\n  | (case ty t t...)\n```\n\nThese are identical to their untyped cousins, except that they include a type annotation for the type of the whole term. \nThese make the typing rules much simpler, as otherwise we lack enough information to pin down the whole type.\n\nThe typing rules for the new terms are:\n\n$$\n\\frac{\\Gamma \\vdash t_i : p_i,\\ ty_{\\mathrm{result}} = (\\mathrm{sop}\\ s_0 \\ldots s_e \\ldots s_m), s_e = [p_0 \\ldots p_n]}{\\Gamma \\vdash (\\mathrm{constr}\\ ty_{\\mathrm{result}}\\ e\\ t_0 \\ldots t_n) : ty_{\\mathrm{result}}}\n$$\n\n$$\n\\frac{\\Gamma \\vdash t : ty_{\\mathrm{scrutinee}},\\ ty_{\\mathrm{scrutinee}} = (\\mathrm{sop}\\ s_0 \\ldots s_n), s_i = [p_{i_0} \\ldots p_{i_m}],\\ \\Gamma \\vdash c_i : p_{i_0} \\rightarrow \\ldots \\rightarrow p_{i_m} \\rightarrow ty_{\\mathrm{result}}}{\\Gamma \\vdash (\\mathrm{case}\\ ty_{\\mathrm{result}}\\ t\\ c_0 \\ldots c_n) : ty_{\\mathrm{result}}}\n$$\n\nThe reduction rules are essentially the same since the types do not affect evaluation.\n\n### Appendix 2: Performance Analysis\n\nPerformance testing of the various prototypes revealed the following interesting facts:\n1. Scott encoding is surprisingly performant.\n2. It's tricky to say why sums-of-products is so much better.\n3. Binding case variables makes a modest difference, but we can achieve the same in other ways.\n\nLet's look at these in turn.\n\n#### Why is Scott encoding so good?\n\nTo see why Scott encoding is so good, let's look at what happens when we 1) construct, and 2) destruct a typical datatype value, using sums-of-products but _without_ binding case variables.\nWe'll do this in the typed setting for clarity.\n\nLet’s consider four programs, corresponding to creation and destruction of `data XYZ = MkXY X Y | MkZ Z`.\n\n**P1: Scott-encoded construction**\n\n```\n[\n  -- Scott-encoded constructor for MkXY\n  (\\(x : X) (y : Y) . (/\\ R . \\(xyc : X -> Y -> R) (zc : Z -> R) . xyc x y) \n  xx \n  yy\n]\n```\n\n**P2: Scott-encoded destruction**\n\n```\n[ \n  { P1 r } \n  -- case alternatives\n  (\\(x : X) (y : Y) -> b1) \n  (\\(z : Z) -> b2\n]\n```\n\n**P3: Explicit construction**\n\n```\nconstr 0 xx yy\n```\n\n**P4: Explicit matching**\n\n```\ncase P3 (\\(x : X) (y : Y) . b1) (\\(z : Z) . b2)\n```\n\nP1 vs P3\n\n- P1\n  - Evaluate the function, evaluate the argument, apply the argument (x2 for two arguments)\n  - Return a closure containing the two arguments in the environment\n- P3\n  - Allocate an array\n  - Evaluate the argument and put it into the array (x2 for two arguments)\n  - Return the value containing the tag and the array\n\nP2 vs P4\n\n- P2\n  - Evaluate the scrutinee\n  - Force the scrutinee (type instantiation)\n  - Evaluate the resulting function, evaluate the argument, apply the argument (x2 for two branch arguments)\n  - Evaluate the branch function, evaluate the argument, apply the argument (x2 for two constructor arguments)\n  - Enter the branch body\n- P4\n  - Evaluate the scrutinee\n  - Look at the tag\n  - Evaluate the case branch (x2 for two branch arguments)\n  - Apply the branch function to the constructor arguments (x2 for two constructor arguments)\n  - Enter the branch body\n\nScott encoding isn't doing anything clearly unnecessary: it's quite efficient at constructing values (because it just returns a function closure right away), and it's quite efficient at deconstructing values (because it just loads the constructor arguments into an environment and then applies the branch).\n\nIn particular, both ways we have to do a similar amount of work in a) evaluating the branch function, b) applying it to its arguments.\n\n#### Why is sums-of-products better at all?\n\nThere are a few advantages for sums-of-products.\nThe most important is that it does not evaluate all the case branches, only the one it needs. Whereas Scott-encoding passes the case branches as simple function arguments, so they are always evaluated before we proceed.\n\nThis makes a surprising amount of difference.\nWe are performing so few steps already for each datatype match that adding a few more to evaluate unused case branches makes a difference.\n\n#### What about binding case variables?\n\nBinding case variables allows us to get rid of some of the work identified in the previous sections.\nA `constr` that binds case variables has two differences:\n1. The body of the case branch is _known_, rather than potentially being an arbitrary lambda that we will need to resolve by doing evaluation.\n2. The constructor arguments can be loaded into the environment _all in one go_, rather than taking requiring multiple steps through the evaluator for each evaluation.\n\nIn practice it seems that difference 1 makes a significant amount of difference, because even if the case branch is a literal lambda, we are forced to allocate a value for the lambda.\nOptimizing the evaluator to avoid this allocation removes a significant part of the advantage.\n\nDifference 2 does not seem to make as large a difference. If we did see a big difference here then we might want to investigate adding multi-lambdas to Plutus Core in order to gain this benefit in other places. In practice, however, it does not seem to be that significant, and prototypes of multi-lambdas have not performed well.\n\n### Appendix 3: Benchmark results\n\nThroughout, the following commits are referenced:\n- `master`: `df9b23f59852d11776fde382720df830c6163238`\n- `sums-of-products`: `e98b284204070053b2e64bb66c7aa0832520afec`\n\nThese represent somewhat arbitrary snapshots.\nThe `sums-of-products` branch represents the current prototype, and `master` is it's merge-base with `plutus`'s `master` branch.\nThese may be updated at a future date.\n\n#### Nofib\n\nThese are benchmarks taken from the `nofib` benchmark suite used by GHC.\nThey are defined in `plutus-benchmark/nofib`.\nThey are not totally comprehensive, but they represent a reasonable survey of programs that do various kinds of general computation.\n\nThese benchmarks are re-compiled from Haskell each time, so the comparison does not represent faster evaluation of the same script, but rather than we can now compile datatype operations using the new terms, which are faster overall.\n\n| Script             | `master` | `sums-of-products` | Change |\n|:-------------------|:--------:|:------------------:|:------:|\n| clausify/formula1  | 18.99 ms | 14.07 ms           | -25.9% |\n| clausify/formula2  | 24.33 ms | 18.10 ms           | -25.6% |\n| clausify/formula3  | 66.30 ms | 48.93 ms           | -26.2% |\n| clausify/formula4  | 96.71 ms | 72.88 ms           | -24.6% |\n| clausify/formula5  | 417.8 ms | 302.7 ms           | -27.5% |\n| knights/4x4        | 59.00 ms | 49.18 ms           | -16.6% |\n| knights/6x6        | 152.2 ms | 127.8 ms           | -16.0% |\n| knights/8x8        | 248.4 ms | 207.6 ms           | -16.4% |\n| primetest/05digits | 32.39 ms | 32.33 ms           | -0.2%  |\n| primetest/08digits | 58.97 ms | 59.02 ms           | +0.1%  |\n| primetest/10digits | 82.44 ms | 82.83 ms           | +0.5%  |\n| primetest/20digits | 168.8 ms | 169.3 ms           | +0.3%  |\n| primetest/30digits | 246.7 ms | 248.9 ms           | +0.9%  |\n| primetest/40digits | 338.8 ms | 341.7 ms           | +0.9%  |\n| primetest/50digits | 329.1 ms | 331.1 ms           | +0.6%  |\n| queens4x4/bt       | 10.03 ms | 8.904 ms           | -11.2% |\n| queens4x4/bm       | 14.18 ms | 12.58 ms           | -11.3% |\n| queens4x4/bjbt1    | 12.80 ms | 11.16 ms           | -12.8% |\n| queens4x4/bjbt2    | 13.42 ms | 11.90 ms           | -11.3% |\n| queens4x4/fc       | 31.96 ms | 28.30 ms           | -11.5% |\n| queens5x5/bt       | 132.9 ms | 113.7 ms           | -14.4% |\n| queens5x5/bm       | 167.2 ms | 143.1 ms           | -14.4% |\n| queens5x5/bjbt1    | 160.8 ms | 137.0 ms           | -14.8% |\n| queens5x5/bjbt2    | 167.4 ms | 145.6 ms           | -13.0% |\n| queens5x5/fc       | 398.8 ms | 351.5 ms           | -11.9% |\n\nThe results indicate that the speedup is more associated with programs that do lots of datatype manipulation, rather than those that do a lot of numerical work (which in Plutus Core means calling lots of builtin functions).\nHowever, we don't see any regression even in the primality tester, which is very numerically heavy (the noise threshold for the benchmarks is ~1%).\n\n#### Validation \n\nThese benchmarks are some real-world examples taken from `plutus-use-cases`.\nThey are defined in `plutus-benchmark/validation`.\nThey thus represent real-world workloads.\n\nThe validation benchmarks are _not_ recompiled, they are specific saved Plutus Core programs.\nThese benchmarks thus only show changes in the performance of the Plutus Core evaluator itself.\n\n| Script                   | `master` | `sums-of-products` | Change |\n|:-------------------------|:--------:|:------------------:|:------:|\n| auction_1-1              | 150.3 μs | 158.6 μs           | +5.5%  |\n| auction_1-2              | 652.2 μs | 684.8 μs           | +5.0%  |\n| auction_1-3              | 638.2 μs | 678.7 μs           | +6.3%  |\n| auction_1-4              | 194.9 μs | 205.9 μs           | +5.6%  |\n| auction_2-1              | 153.7 μs | 161.9 μs           | +5.3%  |\n| auction_2-2              | 648.8 μs | 687.2 μs           | +5.9%  |\n| auction_2-3              | 858.0 μs | 895.6 μs           | +4.4%  |\n| auction_2-4              | 638.2 μs | 676.8 μs           | +6.0%  |\n| auction_2-5              | 195.1 μs | 205.1 μs           | +5.1%  |\n| crowdfunding-success-1   | 182.6 μs | 187.6 μs           | +2.7%  |\n| crowdfunding-success-2   | 182.4 μs | 187.9 μs           | +3.0%  |\n| crowdfunding-success-3   | 182.2 μs | 187.8 μs           | +3.1%  |\n| currency-1               | 237.9 μs | 249.5 μs           | +4.9%  |\n| escrow-redeem_1-1        | 331.7 μs | 342.8 μs           | +3.3%  |\n| escrow-redeem_1-2        | 330.5 μs | 343.4 μs           | +3.9%  |\n| escrow-redeem_2-1        | 386.0 μs | 403.0 μs           | +4.4%  |\n| escrow-redeem_2-2        | 385.0 μs | 404.3 μs           | +5.0%  |\n| escrow-redeem_2-3        | 386.4 μs | 403.7 μs           | +4.5%  |\n| escrow-refund-1          | 134.9 μs | 140.9 μs           | +4.4%  |\n| future-increase-margin-1 | 237.8 μs | 250.3 μs           | +5.3%  |\n| future-increase-margin-2 | 522.0 μs | 538.2 μs           | +3.1%  |\n| future-increase-margin-3 | 521.7 μs | 536.5 μs           | +2.8%  |\n| future-increase-margin-4 | 489.9 μs | 508.8 μs           | +3.9%  |\n| future-increase-margin-5 | 859.0 μs | 873.8 μs           | +1.7%  |\n| future-pay-out-1         | 237.7 μs | 248.7 μs           | +4.6%  |\n| future-pay-out-2         | 524.5 μs | 540.3 μs           | +3.0%  |\n| future-pay-out-3         | 525.8 μs | 537.7 μs           | +2.3%  |\n| future-pay-out-4         | 862.0 μs | 878.5 μs           | +1.9%  |\n| future-settle-early-1    | 237.7 μs | 248.6 μs           | +4.6%  |\n| future-settle-early-2    | 521.7 μs | 537.5 μs           | +3.0%  |\n| future-settle-early-3    | 525.5 μs | 537.1 μs           | +2.2%  |\n| future-settle-early-4    | 642.1 μs | 656.0 μs           | +2.2%  |\n| game-sm-success_1-1      | 379.3 μs | 391.5 μs           | +3.2%  |\n| game-sm-success_1-2      | 166.4 μs | 178.3 μs           | +7.2%  |\n| game-sm-success_1-3      | 639.2 μs | 669.1 μs           | +4.7%  |\n| game-sm-success_1-4      | 193.5 μs | 206.6 μs           | +6.8%  |\n| game-sm-success_2-1      | 379.7 μs | 389.6 μs           | +2.6%  |\n| game-sm-success_2-2      | 166.0 μs | 178.5 μs           | +7.5%  |\n| game-sm-success_2-3      | 641.2 μs | 670.1 μs           | +4.5%  |\n| game-sm-success_2-4      | 193.3 μs | 207.1 μs           | +7.1%  |\n| game-sm-success_2-5      | 644.1 μs | 668.8 μs           | +3.8%  |\n| game-sm-success_2-6      | 193.6 μs | 206.5 μs           | +6.7%  |\n| multisig-sm-1            | 394.5 μs | 405.5 μs           | +2.8%  |\n| multisig-sm-2            | 385.2 μs | 392.8 μs           | +2.0%  |\n| multisig-sm-3            | 386.5 μs | 394.5 μs           | +2.1%  |\n| multisig-sm-4            | 385.8 μs | 404.2 μs           | +4.8%  |\n| multisig-sm-5            | 567.7 μs | 583.0 μs           | +2.7%  |\n| multisig-sm-6            | 391.7 μs | 405.5 μs           | +3.5%  |\n| multisig-sm-7            | 382.7 μs | 394.3 μs           | +3.0%  |\n| multisig-sm-8            | 389.3 μs | 395.8 μs           | +1.7%  |\n| multisig-sm-9            | 387.1 μs | 404.4 μs           | +4.5%  |\n| multisig-sm-10           | 567.4 μs | 583.3 μs           | +2.8%  |\n| ping-pong-1              | 320.6 μs | 327.4 μs           | +2.1%  |\n| ping-pong-2              | 319.1 μs | 327.0 μs           | +2.5%  |\n| ping-pong_2-1            | 182.2 μs | 190.6 μs           | +4.6%  |\n| prism-1                  | 139.2 μs | 150.2 μs           | +7.9%  |\n| prism-2                  | 404.5 μs | 412.2 μs           | +1.9%  |\n| prism-3                  | 339.4 μs | 359.4 μs           | +5.9%  |\n| pubkey-1                 | 118.6 μs | 123.7 μs           | +4.3%  |\n| stablecoin_1-1           | 962.4 μs | 976.3 μs           | +1.4%  |\n| stablecoin_1-2           | 163.7 μs | 174.2 μs           | +6.4%  |\n| stablecoin_1-3           | 1.103 ms | 1.120 ms           | +1.5%  |\n| stablecoin_1-4           | 174.0 μs | 185.4 μs           | +6.6%  |\n| stablecoin_1-5           | 1.391 ms | 1.418 ms           | +1.9%  |\n| stablecoin_1-6           | 215.4 μs | 227.5 μs           | +5.6%  |\n| stablecoin_2-1           | 962.4 μs | 981.3 μs           | +2.0%  |\n| stablecoin_2-2           | 163.5 μs | 174.2 μs           | +6.5%  |\n| stablecoin_2-3           | 1.099 ms | 1.117 ms           | +1.6%  |\n| stablecoin_2-4           | 173.6 μs | 184.8 μs           | +6.5%  |\n| token-account-1          | 174.1 μs | 181.2 μs           | +4.1%  |\n| token-account-2          | 312.8 μs | 334.3 μs           | +6.9%  |\n| uniswap-1                | 408.0 μs | 425.4 μs           | +4.3%  |\n| uniswap-2                | 203.9 μs | 211.7 μs           | +3.8%  |\n| uniswap-3                | 1.779 ms | 1.830 ms           | +2.9%  |\n| uniswap-4                | 282.6 μs | 297.6 μs           | +5.3%  |\n| uniswap-5                | 1.139 ms | 1.180 ms           | +3.6%  |\n| uniswap-6                | 276.2 μs | 288.4 μs           | +4.4%  |\n| vesting-1                | 339.8 μs | 356.0 μs           | +4.8%  |\n\nThis is an average slowdown of 4%, which is not good at all. We do not want to have a negative impact on scripts that don't use the new constructs.\n\nHowever, this slowdown is very difficult to avoid.\nThe GHC Core (GHC's intermediate language for Haskell programs) for both versions looks nearly identical, with the only differences being the introduction of new code for the new cases.\nWe believe that this indicates that GHC simply produces slightly slower code when we have more constructs, even if those code paths are not used.\nIn particular, there are some threshold effects when you cross certain numbers of constructors.\n\nWe tested this by doing an experiment that simply adds new unused constructors to the Plutus Core term type and evaluator frame type.\nThis caused a slowdown of on average 2%.\nThat's not enough to completely explain the loss, but we suspect that similar causes account for the rest (investigation is ongoing).\n\nThis is still bad -- a slowdown is still a slowdown -- but it's less bad because it's unavoidable if we ever want to increase the size of the language.\nWe will pay this cost whenever we decide expand the language.\nEspecially if the cost comes from threshold effects, it may be a one-time cost that we just have to pay on some occasion.\n\n#### Datatypes using 'Data'\n\nThis benchmark compares lists implemented three ways: using SOPs, using builtin lists, and using `Data`.\nIt is defined in `plutus-benchmark/lists`.\nThe benchmark task is summing a list of 100 integers.\nAll three versions are using the Plutus Tx compiler, so any overhead is identical, and the only difference is how the list operations are implemented in the end.\nThere almost certainly is a decent amount of overhead (we did not attempt to measure it here), so the proportional difference in the underlying operations may in fact be greater.\n\n| Benchmark     | CPU budget usage | Memory budget usage |\n|:-------------:|:----------------:|:-------------------:|\n| SOP lists     | 136797800        | 505300              |\n| Builtin lists | 165182654        | 524632              |\n| `Data` lists  | 427357685        | 1360262             |\n\nUsing `Data` is much worse.\nThis is not terribly surprising: pattern-matching on a datatype encoded using `Data` requires multiple builtin calls:\n\n- A call to `ChooseData` to identify the type of `Data`\n- A call to `UnConstrData` to get the tag and arguments as a builtin pair\n- A call to `Fst` to get the tag\n- Some number of calls to builtin operations on integers to work out which branch to take given the tag\n- A call to `Snd` to get the args\n- Some number of calls to `Head`/`Tail` to extract the arguments to be used\n\nOn the other hand, for SOPs this is a single machine step.\n\n## Copyright \n\nThis CIP is licensed under [CC-BY-4.0][].\n\n[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n[Scott encoding]: https://en.wikipedia.org/wiki/Mogensen%E2%80%93Scott_encoding\n\n"
  },
  {
    "path": "CIP-0086/README.md",
    "content": "---\nCIP: 86\nTitle: NFT Metadata Update Oracles\nStatus: Proposed\nCategory: Metadata\nAuthors:\n    - Nicolas Ayotte <nick@equine.gg>\n    - George Flerovsky <george@mlabs.city>\n    - Samuel Williams <samuel@mlabs.city>\n    - Nathaniel Lane <nathaniel@mlabs.city>\nImplementors:\n    - Equine <https://www.equine.gg/>\n    - MLabs <https://mlabs.city/>\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/430\nCreated: 2022-11-01\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis proposal extends the CIP-25 standard for defining\nand updating token metadata via transaction metadata,\nby providing a new mechanism to update token metadata\nwithout having to mint or burn tokens,\nwhile maintaining full backward compatibility with CIP-25.\nThe new mechanism is capable of expressing metadata updates\nmore efficiently than CIP-25 updates.\n\n## Motivation: why is this CIP necessary?\n\nOn Cardano’s eUTxO ledger, native tokens exist\nwithout any inherently attached metadata.\nThe ledger does not provide a direct method for\npreserving any information associated with an asset class of native tokens,\nas transactions move the tokens from one UTxO to another.\n\nThe Media NFT Metadata Standard\n([CIP-25](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025))\nproposed an indirect way to attach metadata to an asset class —\nusing the metadata field (CBOR tag 721) of its minting transactions.\nWhen there are multiple minting transactions for the same asset class,\nthe latest minting transaction’s metadata overrides\nall previous metadata defined for that asset class.\n\nCIP-25 is widely supported across the Cardano community by blockchain indexers,\nwallet providers, marketplace applications, and other stakeholders.\nIt has served the community quite well so far,\nin particular for non-fungible tokens (NFTs) with static metadata\n(i.e. intended to be mostly immutable after minting).\n\nHowever, the CIP-25 metadata update mechanism is suboptimal\nbecause it requires tokens of the asset class to be minted or burned\nwhenever its metadata is updated.\nThis is incongruous with the often purely-informational\npurpose of metadata update transactions.\nWhile it may sometimes be convenient\nto combine token minting and metadata updates\nwithin the same transaction (e.g. to save on transaction fees),\nthere is a broad range of applications where\nmetadata updates need to be more frequent and independent from minting events.\n\nIn practice, there are three main drawbacks to the CIP-25 update mechanism:\n\n1. The metadata authority for an asset class must\nretain the ability to mint/burn more tokens of the asset class\nif it wants to retain the ability to post metadata updates/corrections.\nThis compromises the token issuers’ guarantees to token holders\nthat the token supply (or NFT collections) will not be diluted in the future.\nToken holders are being asked to trust\nthat the metadata authority will not abuse its power\nto mint new tokens of the same asset class.\n2. Executing a minting policy script to mint or burn tokens\nevery time that an asset class’ metadata is updated\nincurs script execution fees, particularly if the script is Plutus-based,\nfar exceeding the fees corresponding to\nthe actual informational content of the metadata update.\nThis cost can become severe for large collections of thousands of NFTs,\nand it may be prohibitive for implementing\nany dynamic fields for such large NFT collections.\n3. An asset class’ metadata can only be updated as a whole.\nThis is inefficient (both in terms of transaction fees and ledger bloat)\nwhen only a small subset of the metadata fields needs to be updated\nfor a large collection of NFTs,\nand it can lead to errors\nif the unmodified fields are improperly copied over to the update.\n\nWe encountered these drawbacks during the development\nof an NFT gaming application,\nwhere thousands of NFTs correspond to game assets with properties\n(e.g. horse age, physical and mental abilities)\nthat evolve both over time and as the NFTs participate\nin various game-related events on-chain.\nThese properties do not need to interact with smart contract logic directly,\nwhich makes transaction metadata a more appropriate place to define them,\nrather than UTxO datums with complicated state-evolution logic.\n\nOur NFT gaming application is leveraging the Cardano immutable ledger,\nrather than an off-chain database,\nas the single source of truth to track the evolution\nof the game assets’ most important properties.\nThis reassures users that the history of metadata states for a game NFT\ncannot be retroactively erased or altered by the game admins —\nalthough the game admins have the authority to modify metadata going forward,\nthey are retroactively accountable for all past updates.\n\nWe expect that this proposal will be useful to many other applications\nthat need to track dynamic on-chain metadata for large NFT collections,\nparticularly in the growing NFT gaming sector.\nIt may also be useful for artists to update on-chain metadata\nabout their art NFTs (e.g. royalty payment receiving address)\nwithout having to burn or mint anything.\n\n## Specification\n\nOur proposal extends CIP-25 with a new update mechanism:\n\n-   A metadata oracle can be assigned for a given policy ID.\n-   For a policy with a metadata oracle assigned,\nthe metadata oracle can post CIP-86 updates to add, remove, or modify\nany fields of the token’s CIP-25 metadata,\nwithout needing to mint or burn any tokens in the metadata update transactions.\n-   The current metadata for a token can be deterministically reconstructed\nby starting from the latest CIP-25 update to the token,\nand applying the subsequent CIP-86 metadata updates\nin ascending blockchain transaction order.\n\nBoth CIP-25 and CIP-86 updates affect the token metadata:\n\n-   A CIP-25 update removes all fields in the current metadata state\nand replaces them with a new complete definition of the metadata state.\n-   A CIP-86 update selectively adds, removes, or modifies fields\nrelative to the current metadata state.\nIt does not apply to any asset class that has not had tokens previously minted\nor any asset class that has not had CIP-25 metadata previously defined,\nbefore the CIP-86 update.\n\nHowever, we recommend that CIP-86 adopters use\nthe new metadata update mechanism exclusively\nto manage all updates to their token metadata\nafter the initial CIP-25 metadata is set.\n\nOur proposal only affects the `86` top-level CBOR tag\nof the metadata field in Cardano transactions.\n(Note: we’re using `86` as a stand-in for the CIP number\nthat will eventually be assigned to this proposal.)\n\n### Assigning a metadata oracle for a token policy ID\n\nA token metadata oracle is defined via two addresses:\n\n-   An oracle update address that is authorized to post metadata updates.\nFor example, this address could be controlled by a bot that automatically\nposts token metadata updates as needed to the blockchain.\n-   An oracle main address that is used to update the oracle update address.\nThis address should be controlled via private keys\nheld in cold storage or hardware wallets.\n\nA metadata oracle can be explicitly assigned to a policy ID\nby setting the following metadata in a transaction\nthat mints or burns tokens for that policy:\n\n```json\n{\n  \"86\": {\n    \"assign_metadata_oracle\": {\n      \"<policyId>\": {\n        \"main_address\": \"<Shelley_address>\",\n        \"update_address\": \"<Shelley_address>\"\n      }\n    }\n  }\n}\n```\n\nWhile a metadata oracle is not explicitly assigned\nto a native-script-based policy ID,\nthe policy ID is implicitly assigned a metadata oracle\nwith both addresses set to an address derived from the native script.\nSpecifically, they are both set to an Enterprise address constructed\nby setting the payment key to the verification key from the native script\nand keeping the staking key empty.\n\n### Updating an oracle assignment\n\nThe metadata oracle assignment for a policy ID can be updated\nvia a transaction signed by the oracle main address key.\nThe oracle assignment transaction must be signed\nby the signing key of the main oracle address,\nbut it may contain any inputs and outputs, \nas these are ignored for the purposes of metadata oracle assignment.\n\nThe schema for updating an oracle assignment is the same as\nfor the initial assignment in the minting transaction:\n\n```json\n{\n  \"86\": {\n    \"assign_metadata_oracle\": {\n      \"<policyId>\": {\n        \"main_address\": \"<Shelley_address>\",\n        \"update_address\": \"<Shelley_address>\"\n      }\n    }\n  }\n}\n```\n\nThe `main_address` or the `update_address` fields for a `<policyID>`\ncan be omitted, in which case the addresses for the omitted fields\nremain the same for that policy ID.\n\nIf a metadata oracle was implicitly assigned to a policy ID\nbefore the assignment update,\nthen the implicit assignment is replaced\nby the new explicit assignment.\n\n### Simple metadata updates\n\nA simple metadata update transaction must be signed\nby the signing key of the oracle update address,\nbut it may contain any inputs and outputs,\nas these are ignored for the purposes of updating token metadata.\n\nThe schema for simple metadata updates in CIP-86\nis similar to the CIP-25 schema,\nbut it is nested under `86.simple_metadata_update`\nin the transaction metadata object.\n\n```json\n{\n  \"86\": {\n    \"simple_metadata_update\": {\n      \"<policyId>\": {\n        \"<tokenName>\": {\n          \"<metadataField>\": \"<metadataValue>\"\n        }\n      }\n    }\n  }\n}\n```\n\nTo remove a metadata field,\nset its value explicitly to `null` in the metadata update.\n\n### Regex metadata updates\n\nThe schema for regex metadata updates is as follows:\n\n```json\n{\n  \"86\": {\n    \"regex_metadata_update\": {\n      \"<policyId>\": {\n        \"<tokenNameRegex>\": {\n          \"<metadataField>\": \"<metadataValue>\"\n        }\n      }\n    }\n  }\n}\n```\n\nA regex metadata update transaction must be signed\nby the signing key of the oracle update address,\nbut it may contain any inputs and outputs,\nas these are ignored for the purposes of updating token metadata.\n\nThe only difference from the simple metadata update is that\nhere the token names are defined in terms of PCRE regular expressions (regex).\nThe regex metadata update applies to any previously minted token\nwhose policy ID matches `<policyID>`\nand whose token name matches the `<tokenNameRegex>` regular expression.\n\nFor example, the following metadata update would apply\nto every Equine pioneer horse\nbetween `EquinePioneerHorse05000` and `EquinePioneerHorse05999`:\n\n```json\n{\n  \"86\": {\n    \"regex_metadata_update\": {\n      \"30ed3d95db1d6bb2c12fc5228a2986eab4553f192a12a4607780e15b\": {\n        \"^EquinePioneerHorse05\\\\d{3}$\": {\n          \"age\": 2\n        }\n      }\n    }\n  }\n}\n```\n\nThe regular expression pattern in `<tokenNameRegex>`\nis defined according to the grammar in:\n\n-   European Computer Manufacturers Association,\n\"ECMAScript Language Specification 5.1 Edition\",\nECMA Standard ECMA-262, June 2011. Section 15.10.\n[https://www.ecma-international.org/wp-content/uploads/ECMA-262_5.1_edition_june_2011.pdf](https://www.ecma-international.org/wp-content/uploads/ECMA-262_5.1_edition_june_2011.pdf)\n\n### Tabular metadata updates\n\nTabular metadata updates use a condensed rectangular format\nto specify new values for a fixed set of fields for a large number of assets.\nSpecifically, for each policy ID we provide an object\nwith the following three fields:\n\n-   `field_paths` contains an array of paths pointing\nto possibly-nested fields within a token metadata object.\nEach of these field paths is a dot-separated list of field names\n(e.g. `\"images.background.sunset.url\"`)\nthat lead from the top of the metadata object (for asset classes of the policy)\ninto a targeted field within that object.\n-   `token_names` contains an array of token names.\n-   `values` contains a table of values, represented by an array of arrays.\nFor each token name in `token_names`,\nthe outer array in `values` contains one element (an inner array)\nof metadata values to which the fields targeted by `field_paths`\nshould be updated for that token name under the policy ID.\nThe outer array of `values` must be equal in length to `token_names`\nand each inner array of `values` must be equal in length to `field_paths`.\n\n```json\n{\n  \"86\": {\n    \"tabular_metadata_update\": {\n      \"<policyId>\": {\n        \"field_paths\": [\n          \"<fieldPath>\"\n        ],\n        \"token_names\": [\n          \"<tokenName>\"\n        ],\n        \"values\": [\n          [\"<metadataValue>\"]\n        ]\n      }\n    }\n  }\n}\n```\n\nA tabular metadata update transaction must be signed\nby the signing key of the oracle update address,\nbut it may contain any inputs and outputs,\nas these are ignored for the purposes of updating token metadata.\n\nFor example, the following update would apply updates to six metadata fields\nof five Equine horse NFTs:\n\n```json\n{\n  \"86\": {\n    \"tabular_metadata_update\": {\n      \"<policyId>\": {\n        \"field_paths\": [\n          \"age\",\n          \"stats.acceleration\",\n          \"stats.agility\",\n          \"stats.endurance\",\n          \"stats.speed\",\n          \"stats.stamina\"\n        ],\n        \"token_names\": [\n          \"EquinePioneerHorse00000\",\n          \"EquinePioneerHorse00012\",\n          \"EquinePioneerHorse00315\",\n          \"EquinePioneerHorse01040\",\n          \"EquinePioneerHorse09175\"\n        ],\n        \"values\": [\n          [3,34,16,18,51,33],\n          [2,24,48,12,32,18],\n          [3,33,34,41,14,31],\n          [4,19,22,21,21,50],\n          [1,24,11,36,22,14]\n        ]\n      }\n    }\n  }\n}\n```\n\nIt is equivalent to the following simple metadata update:\n\n```json\n{\n  \"86\": {\n    \"simple_metadata_update\": {\n      \"<policyId>\": {\n        \"EquinePioneerHorse00000\": {\n          \"age\": 3,\n          \"stats\": {\n            \"acceleration\": 34,\n            \"agility\": 16,\n            \"endurance\": 18,\n            \"speed\": 51,\n            \"stamina\": 33\n          }\n        },\n        \"EquinePioneerHorse00012\": {\n          \"age\": 2,\n          \"stats\": {\n            \"acceleration\": 24,\n            \"agility\": 48,\n            \"endurance\": 12,\n            \"speed\": 32,\n            \"stamina\": 18\n          }\n        },\n        \"EquinePioneerHorse00315\": {\n          \"age\": 3,\n          \"stats\": {\n            \"acceleration\": 33,\n            \"agility\": 34,\n            \"endurance\": 41,\n            \"speed\": 14,\n            \"stamina\": 31\n          }\n        },\n        \"EquinePioneerHorse01040\": {\n          \"age\": 4,\n          \"stats\": {\n            \"acceleration\": 19,\n            \"agility\": 22,\n            \"endurance\": 21,\n            \"speed\": 21,\n            \"stamina\": 50\n          }\n        },\n        \"EquinePioneerHorse09175\": {\n          \"age\": 1,\n          \"stats\": {\n            \"acceleration\": 24,\n            \"agility\": 11,\n            \"endurance\": 36,\n            \"speed\": 22,\n            \"stamina\": 14\n          }\n        }\n      }\n    }\n  }\n}\n```\n\n### Versions 1 and 2\nLike CIP-25, CIP-86 supports two different methods of\nrepresenting policy IDs and token name:\n\n-   In version 1,\npolicy IDs and token names must be expressed as text\n(see [cddl/version_1.cddl](./cddl/version_1.cddl)).\n-   In version 2,\npolicy IDs and token names must be expressed as raw bytes\n(see [cddl/version_2.cddl](./cddl/version_2.cddl)).\n\nBy default, all CIP-86 metadata updates use version 1.\nHowever, version 2 can be used if the `version` field of the object\nunder the top-level `\"86\"` CBOR tag is set to `2`.\n\nFor example:\n\n```json\n{\n  \"86\": {\n    \"version\": 2,\n    \"simple_metadata_update\": {\n      \"<policyIdRawBytes>\": {\n        \"<tokenNameRawBytes>\": {\n          \"<metadataField>\": \"<metadataValue>\"\n        }\n      }\n    }\n  }\n}\n```\n\nRegex updates are disallowed in version 2, because it is unclear\nhow to apply regular expressions to non-UTF-8 bytestrings (or their\ncorresponding hex encodings).\n\n### Order of application for updates\n\nUp to network consensus, the Cardano blockchain imposes\na total ordering on transactions added to the chain —\neach transaction can be indexed by the slot number\nof the block that added it to the chain,\nand the transaction’s index within that block.\nNetwork nodes may disagree about\nwhich blocks have been added most recently to the blockchain;\nhowever, the disagreement about whether a particular transaction was added\nat a particular position in the total order\ndecreases exponentially as more and more blocks are added to the chain.\n\nTo reconstruct the metadata state for a given asset class,\nscan through the sequence of transactions in a Cardano node’s blockchain,\napplying the CIP-25 and CIP-86 updates\nin the order that they are encountered in this sequence.\nShould a transaction contain both CIP-25 and CIP-86 updates,\nthen the CIP-25 updates should be applied first, \nfollowed by the CIP-86 updates.\nIf a transaction contains both a CIP-25 update\nand a CIP-86 explicit oracle assignment,\nthen the CIP-25 update will be applied as usual\nand the oracle addresses (main and/or update) will be set to\nthose of the explicit CIP-86 oracle assignment.\nIf the Cardano node rolls back some blocks from the chain tip,\nthen roll back the updates from those blocks as well.\n\nWe recommend that token metadata oracle operators wait for\ntheir metadata update transactions to be confirmed at a sufficient block depth\nbefore submitting any subsequent metadata updates for the same asset classes.\nDoing so should minimize any confusion about\nthe order of simultaneous pending metadata updates\nwhile the Cardano network settles toward consensus.\n\nA transaction can contain CIP-86 token metadata updates of different types,\nplus oracle assignment updates.\nIn this case, apply the updates in the following sequence:\n\n1. Apply the CIP-86 regex update.\n2. Apply the CIP-86 tabular update.\n3. Apply the CIP-86 simple update.\n4. Apply the CIP-86 oracle assignment update.\n\nWe recommend that token metadata oracle operators not mix multiple update types\nin the same transaction, unless they have a clear understanding of\nthe outcome of applying the updates in the above sequence.\n\n### Token metadata indexer\n\nThe CIP-86 token metadata indexer begins with\na configuration of the policy IDs for which it will be tracking metadata.\nOptionally, it can be configured to track metadata for all tokens on Cardano.\n\nThe indexer monitors the blockchain for minting transactions.\nIf such a minting transaction mints tokens of a tracked policy ID and contains\nan explicit oracle assignment and/or CIP-25 metadata for that policy ID,\nthen the indexer caches that assignment and metadata in its database.\nIf the transaction does not contain\nan explicit oracle assignment for the policy ID,\nand there is no prior oracle assignment,\nthen the indexer caches the implicit oracle assignment\nfor the policy ID in its database.\n\nThe indexer continues to monitor minting transactions for the policy IDs\nthat it’s tracking, applying oracle assignment updates\nand CIP-25 metadata updates accordingly in its database.\nA CIP-25 metadata update is applied as a wholesale replacement of the metadata\ncached in the indexer database for the respective asset classes.\n\nFor each oracle main address currently assigned to a policy ID,\nthe indexer monitors the blockchain for transactions\nthat contain oracle assignment updates in their metadata\nand are signed by the signing key of the main address.\nThe indexer updates its database to reflect these explicit oracle assignments\nand removes any implicit assignments that were replaced by explicit assignments.\n\nFor each oracle update address currently assigned to a policy ID,\nthe indexer monitors the blockchain for transactions\nthat contain CIP-86 token metadata updates\nand are signed by the signing key of the update address.\nThe indexer applies these metadata updates in the order defined in\n[Order of application for updates](#order-of-application-for-updates).\nCIP-86 metadata updates are applied to the asset classes and metadata fields\nthat they target, while keeping all other fields the same.\n\nTo be able to handle blockchain rollbacks, the indexer keeps track of\npast metadata states for its policy IDs,\ngoing back 2160 blocks (~12 hours) from the current blockchain tip.\nCardano’s `securityParam` Shelley Genesis parameter prevents nodes\nfrom rolling back more than 2160 blocks.\nIf the Cardano node informs the indexer of a rollback,\nthe indexer restores the past metadata state that existed immediately before\nall the metadata updates in the rolled-back blocks were applied.\n\nFor compatibility with existing applications\nthat are already relying on CIP-25 metadata indexers,\nthe CIP-86 indexer provides a similar API\nso that those applications can get and display\nthe current CIP-86 token metadata\nin the same way that they have been for CIP-25 metadata.\nThe indexer indicates that it is following the CIP-86 standard.\n\n## Rationale: how does this CIP achieve its goals?\n\nWe pursued the following design goals in our solution:\n\n1. Maintain backward compatibility with CIP-25 —\ntokens that only use CIP-25 updates should have token metadata displayed\nidentically by CIP-25 indexers and CIP-86 indexers.\n2. Ensure that the current token metadata can be reconstructed\nby only looking at the blockchain, without accessing any external resources.\n3. Allow token metadata to be updated\nby designated authorities without minting or burning tokens.\n4. Allow existing token issuers to opt into and out of\nthe CIP-86 update mechanism\nwithout having to remint all of their existing tokens.\n5. Allow designated authorities to securely rotate any keys that they use\nin their automated and networked processes\n(e.g. oracle update address used by a bot to update token metadata).\n6. Allow token metadata to be updated more efficiently than\nby a wholesale replacement of the entire metadata object for an asset class.\n7. Minimize the time and resource usage required\nfor an indexer to apply CIP-25 and CIP-86 updates\nfor an asset class and then serve the resulting token metadata to applications.\n8. Gracefully handle blockchain rollbacks that modify\nthe sequence of CIP-25 and CIP-86 metadata updates for an asset class.\n\n### Backward compatibility\n\nWe maintain full backward compatibility with CIP-25:\n\n-   CIP-25 updates are respected and applied in the same way\nas before by the CIP-86 indexer.\n-   CIP-86 updates are namespaced under a different top-level CBOR tag\nthan CIP-25, in order to prevent any clashes between\nfield names, policy IDs, and token names.\n-   The CIP-86 indexer provides the accumulated CIP-25\nand CIP-86 metadata via the same API as the CIP-25 indexer.\n\n### Using an assigned oracle for token metadata updates\n\nWe recognize CIP-86 updates only if they are issued\nby an oracle currently assigned for the corresponding policy IDs.\nThis assignment is either directly authorized\nby the token issuer (explicitly or implicitly)\nor else indirectly authorized by the token issuer\nvia the delegated authority that the token issuer placed\nin the originally assigned oracle to transfer the assignment to other oracles.\nTherefore, all authority to post valid CIP-86 updates about a token\noriginates from the token issuer.\n\nAn alternative design could have oracles that declare themselves\nas sources of metadata for tokens, without authorization from anyone,\nand then users could voluntarily subscribe to\nthe metadata oracles that they wish to follow.\nHowever, such an approach would make it very difficult for the Cardano ecosystem\nto converge on a single objective metadata state for a token,\nas each user would have his own subjective view of token metadata\nbased on his oracles subscriptions.\nThis alternative approach could be interesting to allow\nsecondary/auxiliary metadata to be defined for tokens,\nbut it is unsuitable for the primary metadata\nthat CIP-25 and CIP-86 seek to manage.\n\n### Identifying oracles by addresses\n\nWe use two addresses to identify an oracle when assigning it to a policy ID.\nIt would be simpler to use a single oracle address,\nbut we chose to separate the main address (authorized to reassign the oracle)\nfrom the update address (authorized to post updates) for an oracle.\nWe did this to mitigate the risk of using the update address\nin an automated process on a network machine,\nand to allow the update address to be safely rotated\nvia a transaction that can only be signed on\na cold storage or hardware wallet device using the main address.\n\nInstead of using addresses to identify oracles,\nwe could have identified oracles by minting policies\n(not the minting policies to which oracles are assigned).\nIn this alternative design, a minting policy `X` could have\nan assigned oracle identified by minting policy `A`.\nUnder such an assignment, a CIP-86 update for a token under `X`\nwould be valid if the update transaction consumed a utxo\nthat contained a token of minting policy `A`.\nIn other words, the holder of an `A` token would be allowed\nto post metadata updates about any `X` tokens.\n\nThis minting-policy-based alternative for identifying oracles may be\nmore advantageous for more flexibly managing oracle authorization\n(including rate-limiting, time-boxing, etc.)\nand proving data provenance to on-chain scripts.\nThese advantages are relevant for oracles that provide information\nin utxo datums meant for use in smart contracts,\nbut they are not as relevant for this CIP,\nwhere we seek to provide a method to provide updateable token metadata\nvia transaction metadata (as a direct extension of CIP-25).\nFurthermore, it is easier to track transactions originating\nfrom a given address in an indexer\nthan to keep track of all the people who control various authorization tokens,\nat a given time.\n\n### Removing the original CIP-86 update transaction restriction\n\nIn the first draft of this proposal,\nwe prohibited CIP-86 oracle assignment updates and metadata updates\nfrom occurring in transactions that mint tokens,\nin order to avoid awkward clashes with CIP-25 metadata transactions.\nThis was removed because, while it likely does not make sense \nto create CIP-25 and CIP-86 metadata for the same token in one transaction,\nit could feasibly make sense to want to update the metadata \nfor other tokens while minting another one.\n\nWe also originally required CIP-86 updates to occur in transactions\nthat only send ADA from an oracle address (main or update, as appropriate),\nto prevent unforeseen interactions with other mechanisms\nthat may have negative consequences.\nThis requirement was removed for two reasons.\nFirst, the reasoning above does not establish any specific issues \nwith other transaction types. Second, it is too restrictive \nand creates unnecessary additional transactions for long sequences of updates,\ncausing the update issuer to spend unnecessary transaction fees.\nTherefore, we decided to remove these unnecessary restrictions \non CIP-86 update transactions.\n\n### Implicit oracle assignment\n\nThe implicit method of assigning a metadata oracle is needed\nto allow existing token issuers to opt into the CIP-86 update mechanism.\nTheir minting policies may no longer allow any more token minting or burning,\nwhich would prevent the token issuers from being able to\nexplicitly assign an oracle via a CIP-25 update for those policies.\nThe implicit assignment method bootstraps\nthe CIP-86 update mechanism for these policies.\n\nThe implicit address is of the Enterprise address type,\nto avoid having to deal with staking keys.\nIf needed, the metadata oracle operator can send ADA to the Enterprise address,\nand then spend it if the operator still controls\nthe payment key of that Enterprise address.\n\n### Opting out of CIP-86\n\nOpting out of the CIP-86 update mechanism can be done\nby explicitly assigning an oracle with addresses\nfrom which ADA cannot be spent (e.g. Plutus AlwaysFails).\nIf the minting policy does not allow any more minting or burning,\nthen this is an irreversible opt-out.\n\n### Regex metadata updates\n\nWhen managing large collections of thousands of NFTs,\none often needs to set a given field to the same value for many NFTs.\nDoing this individually for each NFT\nvia CIP-25 updates or CIP-86 simple updates is inefficient,\nso we have proposed the regex metadata update as a succinct way\nto specify a mapping from multiple token names to a single metadata update.\n\n### Tabular metadata updates\n\nAnother common use case for dynamic token metadata involves\nhaving a set of volatile fields that should receive relatively frequent updates,\nbut where those updates should be different for each NFT.\nLabeling each field value update with its field name\nfor each NFT is very verbose,\nespecially if the field is deeply nested within the metadata schema for the NFT.\nFor this use case, we have proposed the tabular metadata update format\nas a way to avoid this repetition —\nfield names/paths are defined once in the column names of a rectangular table\nand applied consistently for each row of updated metadata field values.\n\nRectangular tables are a standard format used in the data analytics field\nfor these situations.\n\n## Path to Active\n\n### Acceptance Criteria\n\nThis proposal may be considered active if:\n\n1. The solution meets the design goals listed in the\n[Rationale](#rationale) section to a satisfactory degree.\n2. The indexer and simple tools to construct CIP-86 update transactions\n(as described in the [Specification](#specification) section)\nare fully implemented and provided in an open-source (Apache 2.0 licensed)\nrepository with sufficient documentation.\n3. The CIP-86 metadata format, indexer, and/or indexer API\nare used by several stakeholders in the Cardano ecosystem,\nincluding dApps, blockchain explorers, analytics platforms, etc.\n\n### Implementation Plan\n\nEquine and MLabs are collaborating on\ndeveloping the indexer described in this CIP\nand the Equine NFT gaming application will be\nusing CIP-86 updates to manage metadata updates\nfor its large collection of thousands of NFTs under multiple minting policies.\n\nWe will include detailed documentation, example configurations,\nand tutorials on how to adapt the tools to new projects.\n\nWe are actively engaged in discussions with other stakeholders\nin the Cardano ecosystem that are interested in adopting this CIP\nto their projects, platforms, and tools.\n\n## Copyright\n\nThis CIP is licensed under\nthe Creative Commons Attribution 4.0 International Public License\n ([CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)).\n\n---\n"
  },
  {
    "path": "CIP-0086/cddl/version_1.cddl",
    "content": "metadata = { \"86\" => action }\n\n; =========================================================================\n; CIP-86 actions\n\naction =\n  {\n    ? assign_metadata_oracle : action_oracle,\n    ? simple_metadata_update : action_simple,\n    ? regex_metadata_update : action_regex,\n    ? tabular_metadata_update : action_tabular\n  }\n\naction_oracle = { * policy_id => oracle_assignment }\n\noracle_assignment =\n  {\n    ? main_address : address,\n    ? update_address : address\n  }\n\naction_simple = { * policy_id => { * asset_name => metadata_details } }\n\naction_regex = { * policy_id => { * asset_regex => metadata_details } }\n\naction_tabular = { * policy_id => tabular_metadata }\n\n; Technically, both policy IDs and asset names should be 32 bytes long.\n; However, this isn't enforced for asset names, and CIP-25v1 already treats\n; these as `text_64`, so we don't enforce the more narrow `bytes_32` type\n; here.\npolicy_id = text_64\nasset_name = text_64\n\nasset_regex = text_regex_extendable\n\n; =========================================================================\n; Backwards compatibility with CIP-25 (simple and regex metadata updates)\n; Definitions for the following fields in `metadata_details` should follow\n; the same schema as in CIP-25, except that `name` and `image` are optional.\n; Other fields can have arbitrary `transaction_metadatum` values.\nmetadata_details =\n  {\n    ? name : text_64,\n    ? image : text_extendable,\n    ? mediaType : text_64,\n    ? description : text_extendable,\n    ? files : [ * files_details],\n    * ( label_64 => transaction_metadatum )\n  }\n\nfiles_details =\n  {\n    name : text_64,\n    mediaType : text_64,\n    src : text_extendable\n  }\n\n; =========================================================================\n; Tabular format\n\n; The length of `token_names` must be equal to the length of the outer\n; array of `values`, and the length of `field_paths` must be equal to\n; the length of each inner array of `values`.\ntabular_metadata =\n  {\n    field_paths: [ * field_path],\n    token_names: [ * asset_name],\n    values: [ * [ * transaction_metadatum ] ]\n  }\n\n; Each field path is a dot-separated list of field names (text_64 values).\n; E.g. \"images.background.sunset.url\"\nfield_path = text_64\n\n; =========================================================================\n; Imported from cardano-ledger/.../babbage.cddl\ntransaction_metadatum =\n    { * transaction_metadatum => transaction_metadatum }\n  / [ * transaction_metadatum ]\n  / int\n  / bytes_64\n  / text_64\n\naddress = bytes\n\n; =========================================================================\n; Convenient type aliases\n\n; Fixed-size text and bytes\nlabel_32 = bytes_32 / text_32\nbytes_32 = bytes .size (0..32)\ntext_32 = text .size (0..32)\n\nlabel_64 = bytes_64 / text_64\nbytes_64 = bytes .size (0..64)\ntext_64 = text .size (0..64)\n\n; Extendable text and bytes\ntext_extendable = text_64 / [ * text_64 ]\nbytes_extendable = bytes_64 / [ * bytes 64 ]\n\n; Regex (fixed-size)\n; Tag 35 is for regular expressions in Perl Compatible Regular\n; Expressions (PCRE) / JavaScript syntax [ECMA262].\n; https://www.rfc-editor.org/rfc/rfc7049#section-2.4.4.3\n; https://www.ecma-international.org/publications-and-standards/standards/ecma-262/\ntext_regex = #6.35(text_64)\n\n; Regex (extendable size)\n; Technically, CBOR maps can have arrays as keys. This prevents them from being\n; directly convertable to JSON, but we can recover JSON-convertability by\n; concatenating the array-valued key into a single UTF-8 text.\n; The resulting concatenated text should be interpreted as `#6.35(text)`.\ntext_regex_extendable = text_extendable\n"
  },
  {
    "path": "CIP-0086/cddl/version_2.cddl",
    "content": "metadata = { \"86\" => action }\n\n; =========================================================================\n; CIP-86 actions\n\n; When version 2 mode is enabled for a CIP-86 action, all `policy_id` and\n; `asset_name` values are interpreted as `bytes_64`, similar to CIP-25v2.\naction =\n  {\n    version = 2,\n    ? assign_metadata_oracle : action_oracle,\n    ? simple_metadata_update : action_simple,\n    ? tabular_metadata_update : action_tabular\n  }\n\n; Regex updates are disallowed in version 2, because it is unclear\n; how to apply regular expressions to non-UTF-8 bytestrings (or their\n; corresponding hex encodings).\n\naction_oracle = { * policy_id => oracle_assignment }\n\noracle_assignment =\n  {\n    ? main_address : address,\n    ? update_address : address\n  }\n\naction_simple = { * policy_id => { * asset_name => metadata_details } }\n\naction_tabular = { * policy_id => tabular_metadata }\n\n; Technically, both policy IDs and asset names should be 32 bytes long.\n; However, this isn't enforced for asset names, and CIP-25v2 already treats\n; these as `bytes_64`, so we don't enforce the more narrow `bytes_32` type\n; here.\npolicy_id = bytes_64\nasset_name = bytes_64\n\n; =========================================================================\n; Backwards compatibility with CIP-25 (simple and regex metadata updates)\n; Definitions for the following fields in `metadata_details` should follow\n; the same schema as in CIP-25, except that `name` and `image` are optional.\n; Other fields can have arbitrary `transaction_metadatum` values.\nmetadata_details =\n  {\n    ? name : text_64,\n    ? image : text_extendable,\n    ? mediaType : text_64,\n    ? description : text_extendable,\n    ? files : [* files_details],\n    * ( label_64 => transaction_metadatum )\n  }\n\nfiles_details =\n  {\n    name : text_64,\n    mediaType : text_64,\n    src : text_extendable\n  }\n\n; =========================================================================\n; Tabular format\n\n; The length of `token_names` must be equal to the length of the outer\n; array of `values`, and the length of `field_paths` must be equal to\n; the length of each inner array of `values`.\ntabular_metadata =\n  {\n    field_paths: [ * field_path],\n    token_names: [ * asset_name],\n    values: [ * [ * transaction_metadatum ] ]\n  }\n\n; Each field path is a dot-separated list of field names (text_64 values).\n; E.g. \"images.background.sunset.url\"\nfield_path = text_64\n\n; =========================================================================\n; Imported from cardano-ledger/.../babbage.cddl\ntransaction_metadatum =\n    { * transaction_metadatum => transaction_metadatum }\n  / [ * transaction_metadatum ]\n  / int\n  / bytes_64\n  / text_64\n\naddress = bytes\n\n; =========================================================================\n; Convenient type aliases\n\n; Fixed-size text and bytes\nlabel_32 = bytes_32 / text_32\nbytes_32 = bytes .size (0..32)\ntext_32 = text .size (0..32)\n\nlabel_64 = bytes_64 / text_64\nbytes_64 = bytes .size (0..64)\ntext_64 = text .size (0..64)\n\n; Extendable text and bytes\ntext_extendable = text_64 / [ * text_64 ]\nbytes_extendable = bytes_64 / [ * bytes 64 ]\n"
  },
  {
    "path": "CIP-0088/CIPs/0025/CIP25_v1.cddl",
    "content": "; CIP-0025: Token Metadata Standard\n; Version: 1\n\ncip25-details = {\n    ? 0 : uint,               ; version\n    1 : token-project-details   ; [CIP-0025 Token Project Details](../common/token-project-details.cddl)\n}"
  },
  {
    "path": "CIP-0088/CIPs/0025/CIP25_v1.json",
    "content": "{\n  \"25\": {\n    \"0\": 1,\n    \"1\": {\n      \"0\": \"SpaceBudz\",\n      \"1\": [\n        \"10,000 SpaceBudz are out there.\",\n        \"Where will your SpaceBudz take you?\"\n      ],\n      \"2\": [\n        \"https://\",\n        \"static.spacebudz.io\",\n        \"/images/logo.png\"\n      ],\n      \"3\": [\n        \"https://\",\n        \"static.spacebudz.io\",\n        \"/images/banner.jpg\"\n      ],\n      \"4\": 0,\n      \"5\": [\n        [\n          \"twitter\",\n          [\n            \"https://\",\n            \"twitter.com/spacebudzNFT\"\n          ]\n        ],\n        [\n          \"discord\",\n          [\n            \"https://\",\n            \"discord.gg/spacebudz\"\n          ]\n        ]\n      ],\n      \"6\": \"SpaceBudz\"\n    }\n  }\n}"
  },
  {
    "path": "CIP-0088/CIPs/0025/CIP25_v1.schema.json",
    "content": "{\n  \"$id\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/main/CIP-0088/CIPs/0025/CIP25_v1.schema.json\",\n  \"title\": \"CIP-25: Token Project Details\",\n  \"description\": \"Additional context for token policy declaring support for CIP-25 token metadata standards\",\n  \"type\": \"object\",\n  \"properties\": {\n    \"25\": {\n      \"type\": \"object\",\n      \"properties\": {\n        \"0\": {\n          \"type\": \"integer\",\n          \"title\": \"Version\",\n          \"description\": \"The version of the standard in use\",\n          \"minimum\": 1\n        },\n        \"1\": {\n          \"title\": \"Project Details\",\n          \"description\": \"Describe top-level details about the Token Project\",\n          \"$ref\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/main/CIP-0088/common/token-project-details_v1.schema.json\"\n        }\n      },\n      \"required\": [\n        \"1\"\n      ]\n    }\n  },\n  \"required\": [\n    \"25\"\n  ]\n}"
  },
  {
    "path": "CIP-0088/CIPs/0025/README.md",
    "content": "# CIP-88 Extension: CIP-0025 | Token Project Information\n\n`Version: 1`\n\n## Top-Level Fields\n\nBoth CIP-25 and CIP-68 are specifications describing a standard for storing and retrieving token metadata from the\nchain. To this end, we have given them the same data structure although each will utilize their own numerical index in\nthe feature set and CIP-Specific details section of the registration.\n\nThese sections may be separated in the future if the respective CIPs diverge in terms of the data or information that\nmay be useful to provide about one format or the other in the future.\n\n| index | name                     | type             | required | notes                                                                                                       |\n|-------|--------------------------|------------------|----------|-------------------------------------------------------------------------------------------------------------|\n| 0     | Version                  | Unsigned Integer | No       | Default: 1, which version of this specification is in use                                                   |\n| 1     | Token Collection Details | Object           | Yes      | Provide additional context about this \"Collection\" for consumption by marketplaces, explorers, and wallets. |\n\nThe information registered here is helpful to aggregator services and marketplaces, it applies equally to both CIP-25\nand CIP-68 metadata standards. A project utilizing one or the other should reference this documentation and include the\nrelevant information under index #6, prefixed by the number of the CIP (25 or 68) depending upon the metadata format.\n\n## Token Collection Details Fields\n\n| index | name                | type     | required |\n|-------|---------------------|----------|----------|\n| 0     | Collection Name     | String   | Yes      |\n| 1     | Description         | Array    | No       |\n| 2     | Project Image       | UriArray | No       |\n| 3     | Project Banner      | UriArray | No       |\n| 4     | NSFW Flag           | 0 or 1   | No       |\n| 5     | Social Media        | Array    | No       |\n| 6     | Project/Artist Name | String   | No       |\n\nFor details on what these fields represent and how they should be structured in the metadata, please refer to\n[Token Project Details](../common/Token-Project-Details_v1.md)\n\n## CIP-25 Example\n\n```cbor \n{\n  25: {\n    0: 1,\n    1: {\n      0: \"Cool NFT Project\",\n      1: [\n        \"This is a description of my project\",\n        \"longer than 64 characters so broken up into a string array\"\n      ],\n      2: [\n        \"https://\",\n        \"static.coolnftproject.io\",\n        \"/images/icon.png\"\n      ],\n      3: [\n        \"https://\",\n        \"static.coolnftproject.io\",\n        \"/images/banner1.jpg\"\n      ],\n      4: 0,\n      5: [\n        [\n          \"twitter\",\n          [\n            \"https://\",\n            \"twitter.com/spacebudzNFT\"\n          ]\n        ],\n        [\n          \"discord\",\n          [\n            \"https://\",\n            \"discord.gg/spacebudz\"\n          ]\n        ]\n      ],\n      6: \"Virtua Metaverse\"\n    }\n  }\n}\n```"
  },
  {
    "path": "CIP-0088/CIPs/0026/CIP26_v1.cddl",
    "content": "; CIP-0026: Fungible Token Registration Standard\n; Version: 1\n\nstring = text .size (0..64)\n\n; A uri should consist of a scheme and one or more path strings describing the path to the resource\n; The first entry should contain the URI \"Scheme\" (e.g. \"https://\", \"ftp://\", \"ar://\", \"ipfs://\")\n; One or more subsequent entries should describe the path of the URI\n\nuri.scheme = text .size (5..64)\nuri.path = text .size (1..64)\nuri = {\n    uri.scheme,\n    + uri.path\n}\n\npolicy_id = bytes .size(28)\nasset_name = bytes .size (0..32)\n\ntoken-asset = {\n    policy_id,\n    asset_name\n}\n\nfungible-details = {\n      0 : token-asset,           ; asset identifier\n      1 : string,                ; token name\n      2 : [* string],            ; description\n    ? 3 : string,                ; token ticker\n    ? 4 : uint,                  ; token decimals\n    ? 5 : uri,                   ; uri of token website\n    ? 6 : uri,                   ; uri of token image\n    ? 7 : token-asset            ; beacon token identifier\n}\n\ncip26-details = {\n    ? 0 : uint,                  ; version\n      1 : [+ fungible-details]   ; CIP-0026 Fungible Token Registration(s)\n}"
  },
  {
    "path": "CIP-0088/CIPs/0026/CIP26_v1.json",
    "content": "{\n  \"26\": {\n    \"0\": 1,\n    \"1\": [\n      {\n        \"0\": [\n          \"d894897411707efa755a76deb66d26dfd50593f2e70863e1661e98a0\",\n          \"7370616365636f696e73\"\n        ],\n        \"1\": \"spacecoins\",\n        \"2\": \"SPACE\",\n        \"3\": [\n          \"the OG Cardano community token\",\n          \"-\",\n          \"whatever you do, your did it!\",\n          \"\",\n          \"Learn more at https://spacecoins.io!\"\n        ],\n        \"4\": 0,\n        \"5\": [\n          \"https://\",\n          \"spacecoins.io\"\n        ],\n        \"6\": [\n          \"ipfs://\",\n          \"bafkreib3e5u4am2btduu5s76rdznmqgmmrd4l6xf2vpi4vzldxe25fqapy\"\n        ],\n        \"7\": [\n          \"d894897411707efa755a76deb66d26dfd50593f2e70863e1661e98a0\",\n          \"\"\n        ]\n      }\n    ]\n  }\n}"
  },
  {
    "path": "CIP-0088/CIPs/0026/CIP26_v1.schema.json",
    "content": "{\n  \"$id\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/main/CIP-0088/CIPs/0026/CIP26_v1.schema.json\",\n  \"title\": \"CIP-26: Fungible Token\",\n  \"description\": \"Additional context for a policy declaring support for fungible token standards\",\n  \"type\": \"object\",\n  \"properties\": {\n    \"26\": {\n      \"type\": \"object\",\n      \"properties\": {\n        \"0\": {\n          \"type\": \"integer\",\n          \"title\": \"Version\",\n          \"description\": \"The version of the standard in use\",\n          \"minimum\": 1\n        },\n        \"1\": {\n          \"type\": \"array\",\n          \"minItems\": 1,\n          \"items\": {\n            \"title\": \"Fungible Token Details\",\n            \"description\": \"Describes details about a particular fungible token under this policy\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"0\": {\n                \"title\": \"Subject\",\n                \"description\": \"The hex-encoded Policy ID and Asset ID of the token\",\n                \"$ref\": \"#/$defs/tokenAsset\"\n              },\n              \"1\": {\n                \"title\": \"Name\",\n                \"description\": \"The full display name of the token\",\n                \"type\": \"string\",\n                \"example\": \"spacecoins\"\n              },\n              \"2\": {\n                \"title\": \"Symbol/Ticker\",\n                \"description\": \"The ticker or listing symbol for the token\",\n                \"type\": \"string\",\n                \"example\": \"SPACE\"\n              },\n              \"3\": {\n                \"title\": \"Description\",\n                \"description\": \"A short description for the token\",\n                \"type\": \"array\",\n                \"items\": {\n                  \"type\": \"string\",\n                  \"maxLength\": 64\n                },\n                \"example\": [\n                  \"The OG Cardano Community Token\",\"- whatever you do, your did it!\"\n                ]\n              },\n              \"4\": {\n                \"title\": \"Decimals\",\n                \"description\": \"How many decimal places this token should be rendered with\",\n                \"type\": \"integer\",\n                \"example\": 0,\n                \"default\": 0\n              },\n              \"5\": {\n                \"title\": \"URL\",\n                \"description\": \"A URL to the project's web page\",\n                \"$ref\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/main/CIP-0088/common/uri-array.schema.json\"\n              },\n              \"6\": {\n                \"title\": \"Logo\",\n                \"description\": \"A URI to the token's logo\",\n                \"$ref\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/main/CIP-0088/common/uri-array.schema.json\"\n              },\n              \"7\": {\n                \"title\": \"Reference Token\",\n                \"description\": \"A reference to a 'Beacon Token' that can provide additional context via inline datum to smart contracts\",\n                \"$ref\": \"#/$defs/tokenAsset\"\n              }\n            },\n            \"required\": [\n              \"0\",\n              \"1\",\n              \"2\"\n            ]\n          }\n        }\n      },\n      \"required\": [\n        \"1\"\n      ]\n    }\n  },\n  \"required\": [\n    \"26\"\n  ],\n  \"$defs\": {\n    \"tokenAsset\": {\n      \"title\": \"Token Asset\",\n      \"description\": \"The hex-encoded Policy ID and hex-encoded Asset ID of the token\",\n      \"type\": \"array\",\n      \"minItems\": 2,\n      \"maxItems\": 2,\n      \"items\": [\n        {\n          \"title\": \"Policy ID\",\n          \"description\": \"The hex-encoded Policy ID of the token\",\n          \"type\": \"string\",\n          \"maxLength\": 56,\n          \"minLength\": 56\n        },\n        {\n          \"title\": \"Asset ID\",\n          \"description\": \"The hex-encoded Asset ID of the token\",\n          \"type\": \"string\",\n          \"minLength\": 0,\n          \"maxLength\": 64\n        }\n      ],\n      \"additionalItems\": false\n    }\n  }\n}"
  },
  {
    "path": "CIP-0088/CIPs/0026/README.md",
    "content": "# CIP-88 Extension:  CIP-0026 | Fungible Tokens / Monetary Policy\n\n`Version: 1`\n\n## Top-Level Fields\n\n| index | name            | type                   | required | notes                                                                                     |\n|-------|-----------------|------------------------|----------|-------------------------------------------------------------------------------------------|\n| 0     | Version         | Unsigned Integer       | No       | Default: 1, which version of this specification is in use                                 |\n| 1     | Fungible Tokens | Array\\<Token Details\\> | No       | An array of one or more fungible token registration objects covered by this registration. |\n\nSee [CIP26_v1.cddl](./CIP26_v1.cddl) for a full CBOR CDDL spec, [CIP26_v1.json](./CIP26_v1.json) as an example, and\n[CIP26_v1.schema.json](./CIP26_v1.schema.json) for schema documentation. This information can replace the information\ncurrently housed in the [Cardano Token Registry](https://github.com/cardano-foundation/cardano-token-registry) and is\nbased on the format currently used in those registrations along with a few additional fields.\n\nBecause it is possible that multiple fungible tokens could be minted under a single Policy ID, the format for CIP-26\ntokens is slightly different. Here we include an array of fungible token details inside an array to enable multiple\ntokens under the same policy to be registered in a single transaction.\n\n**Example:**\n\n```cbor\n{\n    867: {\n        0: 1,\n        1: {\n            6: {\n                26: {\n                    0: 1,\n                    1: [\n                        [...Fungible Token 1 Details...],\n                        [...Fungible Token 2 Details...]\n                    ]\n                }\n            }\n        },\n        2: [...]\n    }\n}\n```\n\n## Fungible Token Details Fields\n\n| index | name                                 | type                                  | required |\n|-------|--------------------------------------|---------------------------------------|----------|\n| 0     | [Subject](#0--subject)               | [Token Identifier](#token-identifier) | Yes      |\n| 1     | [Token Name](#1--token-name)         | String                                | Yes      |\n| 2     | [Description](#2--description)       | Array                                 | Yes      |\n| 3     | [Token Ticker](#3--token-ticker)     | String                                | No       |\n| 4     | [Token Decimals](#4--token-decimals) | Unsigned Integer                      | No       |\n| 5     | [Token Website](#5--token-website)   | [URI Array](#uri-array)               | No       |\n| 6     | [Token Image](#6--token-image)       | [URI Array](#uri-array)               | No       |\n| 7     | [Beacon Token](#7--beacon-token)     | [Token Identifier](#token-identifier) | No       |\n\n### Field Notes\n\n#### 0: Subject\n\n***Type: [Token Identifier](#token-identifier) | Required: Yes***\n\nA Token Identifier identifying the specific token being registered.\n\n**Example:** `[h'd894897411707efa755a76deb66d26dfd50593f2e70863e1661e98a0',h'7370616365636f696e73']`\n\n#### 1: Token Name\n\n***Type: String | Required: Yes***\n\nThis is the full \"display name\" of the token.\n\n**Example:** `\"spacecoins\"`\n\n#### 2: Description\n\n***Type: Array | Required: Yes***\n\nA plain-text description for the token. This should be an array of zero or more strings.\n\n**Example:** `[\n\"the OG Cardano community token\",\n\"-\",\n\"whatever you do, your did it!\",\n\"\",\n\"Learn more at https://spacecoins.io!\"\n]`\n\n#### 3: Token Ticker\n\n***Type: String | Required: No | Default: [Token Name](#1--token-name)***\n\nA short \"ticker\" identifier for the token. Usually 1 to 5 characters.\n\n**Example:** `\"SPACE\"`\n\n#### 4: Token Decimals\n\n***Type: Unsigned Integer | Required: No | Default: 0***\n\nHow many decimal places this token should be treated as having to create a \"whole unit\". Default is 0 (no decimals).\nLovelace has 6 decimal places (1.000001)\n\n**Example:** `6`\n\n#### 5: Token Website\n\n**Type: [URI Array](#uri-array) | Required: No | default: Null**\n\nA valid [URI Array](#uri-array) object describing the URI to the token website.\n\n**Example:** `[\"https://\",\"www.spacecoins.io\"]`\n\n#### 6: Token Image\n\n**Type: [URI Array](#uri-array) | Required: No | Default: Null**\n\nA valid [URI Array](#uri-array) describing the URI to a thumbnail image to be used for the token. Recommended 64px by\n64px resolution, transparent background PNG file.\n\n**Example:** `[\"ipfs://\",\"bafkreibva6x6dwxqksmnozg44vpixja6jlhm2w7ueydkyk4lpxbowdbqly\"]`\n\n#### 7: Beacon Token\n\n**Type: [Token Identifier](#token-identifier) | Required: No | Default: Null**\n\nA valid [Token Identifier](#token-identifier) to be used as a _\"beacon token\"_ for the project. Purposes and format\nTBD. This token could be used as a reference input in smart contracts and provide context and data via inline datum.\n\n#### Token Identifier\n\nA token identifier is an array that MUST contain two entries. The first entry MUST be the byte-encoded Policy ID. The\nsecond entry MUST be the byte-encoded Asset ID.\n\n**Example:** `[h'<policy_id>',h'<asset_id>']`\n\n#### URI Array\n\nA URI Array ([Schema Definition](../common/uri-array.schema.json)) is an array of two or more strings that can be\nconcatenated to create a valid URI. The first entry of the URI Array must define the _URI\nscheme_ (`https://, ar://, ipfs://, etc`) and subsequent entries define the path and any arguments that may be required\n(`www.spacecoins.io`).\n\n**Example:**\n`[\"https://\", \"www.spacecoins.io\"]`, `[\"ar://\", \"abc123\"]`, `[\"ipfs://\", \"bafkreibva6x6dwxqksmnozg44vpixja6jlhm2w7ueydkyk4lpxbowdbqly\"]`\n\n## CIP-26 Example\n\n```cbor\n{\n  26: {\n    0: 1,\n    1: [\n      {\n        0: [\n          h'd894897411707efa755a76deb66d26dfd50593f2e70863e1661e98a0',\n          h'7370616365636f696e73'\n        ],\n        1: \"spacecoins\",\n        2: [\n          \"the OG Cardano community token\",\n          \"-\",\n          \"whatever you do, your did it!\",\n          \"\",\n          \"Learn more at https://spacecoins.io!\"\n        ],\n        3: \"SPACE\",\n        4: 0,\n        5: [\"https://\",\"spacecoins.io\"],\n        6: [\n          \"ipfs://\",\n          \"bafkreib3e5u4am2btduu5s76rdznmqgmmrd4l6xf2vpi4vzldxe25fqapy\"\n        ],\n        7: [\n          [\n            \"ipfs://\",\n            \"bafkreibva6x6dwxqksmnozg44vpixja6jlhm2w7ueydkyk4lpxbowdbqly\"\n          ],\n          \"3507afe1daf05498d764dce55e8ba41e4acecd5bf42606ac2b8b7dc2eb0c305e\"\n        ],\n        8: [\n          h'd894897411707efa755a76deb66d26dfd50593f2e70863e1661e98a0',\n          h'7370616365636f696e74'\n        ]\n      }\n    ]\n  }\n}\n```"
  },
  {
    "path": "CIP-0088/CIPs/0027/CIP27_v1.cddl",
    "content": "; CIP-0027: NFT Royalty Standard\n; Version: 1\n\naddress = [+ string]        ; The address to receive royalties in BECH32 format\nstring = text .size (0..64)\n\nroyalty-details = {\n    1 : string              ; Rate as floating point string (\"0.000001\" .. \"1.000000\")\n    2 : address             ; Royalty receipt address\n}\n\ncip27-details = {\n    ? 0 : string,           ; Version\n    1 : royalty-details     ; Royalty detail information\n}"
  },
  {
    "path": "CIP-0088/CIPs/0027/CIP27_v1.json",
    "content": "{\n  \"27\": {\n    \"0\": 1,\n    \"1\": {\n      \"0\": \"0.05\",\n      \"1\": [\n        \"addr_test1qqp7uedmne8vjzue66hknx87jspg56qhkm4gp6ahyw7kaahevmtcux\",\n        \"lpy25nqhaljc70094vfu8q4knqyv6668cvwhsq64gt89\"\n      ]\n    }\n  }\n}"
  },
  {
    "path": "CIP-0088/CIPs/0027/CIP27_v1.schema.json",
    "content": "{\n  \"$id\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/main/CIP-0088/CIPs/0027/CIP27_v1.schema.json\",\n  \"title\": \"CIP-27: Token Royalty Details\",\n  \"description\": \"Additional context for token policy declaring support for CIP-27 royalty standards\",\n  \"type\": \"object\",\n  \"properties\": {\n    \"27\": {\n      \"type\": \"object\",\n      \"properties\": {\n        \"0\": {\n          \"type\": \"integer\",\n          \"title\": \"Version\",\n          \"description\": \"The version of the standard in use\",\n          \"minimum\": 1\n        },\n        \"1\": {\n          \"title\": \"Royalty Details\",\n          \"description\": \"Describe top-level details about the Token Project\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"0\": {\n              \"type\": \"string\",\n              \"title\": \"Royalty Rate\",\n              \"description\": \"Rate of royalties to charge as represented by a floating point number between 1.000000 and 0.000000\"\n            },\n            \"1\": {\n              \"type\": \"array\",\n              \"title\": \"Recipient Address\",\n              \"description\": \"The recipient address to receive royalties in BECH32 format.\",\n              \"items\": {\n                \"type\": \"string\",\n                \"maxLength\": 64\n              }\n            }\n          },\n          \"required\": [\n            \"0\",\n            \"1\"\n          ]\n        }\n      },\n      \"required\": [\n        \"1\"\n      ]\n    }\n  },\n  \"required\": [\n    \"27\"\n  ]\n}"
  },
  {
    "path": "CIP-0088/CIPs/0027/README.md",
    "content": "# CIP-88 Extension: CIP-0027 | Cardano Token Royalty Information\n\n`Version: 1`\n\n## Top Level Fields\n\n| index | name            | type   | required | notes                                                          |\n|-------|-----------------|--------|----------|----------------------------------------------------------------|\n| 0     | Version         | UInt   | No       | Default: 1, which version of this specification is in use      |\n| 1     | Royalty Details | Object | Yes      | An object detailing the project royalties as defined in CIP-27 |\n\n## Royalty Details Fields\n\n| index | name              | type              | required |\n|-------|-------------------|-------------------|----------|\n| 0     | Rate              | String            | Yes      |\n| 1     | Recipient Address | Array             | Yes      |\n\n### Field Notes\n\n#### 0: Rate\n\n***Type: String | Required: Yes***\n\nThis should be a floating point number between 0.000000 - 1.000000 representing the rate of royalties requested\n\n**Example:** `\"0.05\"`\n\n#### 1: Recipient Address\n\n***Type: Array | Required: Yes***\n\nThis should be an array containing a single Cardano Shelley-era address in BECH32 format to receive royalties\n\n**Example:** `[\n\"addr_test1qqp7uedmne8vjzue66hknx87jspg56qhkm4gp6ahyw7kaahevmtcux\",\n\"lpy25nqhaljc70094vfu8q4knqyv6668cvwhsq64gt89\"\n]`\n\n## CIP-27 Example\n\n```cbor \n{\n  27: {\n    0: 1,\n    1: {\n      0: \"0.05\",\n      1: [\n        \"addr_test1qqp7uedmne8vjzue66hknx87jspg56qhkm4gp6ahyw7kaahevmtcux\",\n        \"lpy25nqhaljc70094vfu8q4knqyv6668cvwhsq64gt89\"\n      ]\n    }\n  }\n}\n```"
  },
  {
    "path": "CIP-0088/CIPs/0048/CIP48_v1.cddl",
    "content": "; CIP-0048: Metadata References Standard\n; Version: 1\n\nstring = text .size (0..64)\n\nreference-payload = {\n    0 : \"content\" / \"pointer\"  ; Payload Type: Is the payload a direct content replacement or a pointer\n    1 :\n}\n\nreference = {\n    0 : string,                ; reference name (case sensitive)\n    1 : reference-payload      ; The payload of the reference\n}\n\nreference-details = {\n    1 : [+ reference]\n}\n\ncip48-details = {\n    ? 0 : uint,               ; version\n      1 : reference-details   ; CIP-0068 NFT Project Details\n}"
  },
  {
    "path": "CIP-0088/CIPs/0048/README.md",
    "content": "# CIP-88 Extension: CIP-48 | Metadata References Standard\n\n`Version: 1`\n\nCIP-48 has been proposed to extend on-chain metadata formats to support \"references\" which could be:\n\n1. Shared/Repeated pieces of content\n2. Pointers or References to other on-chain information\n\nCIP-88 could help support the definition and standardization of the reference definitions at a top-level, allowing\nreferences declared within individual token metadata to be easily identified and replaced.\n\n## Top Level Fields\n\n| index | name              | type   | required | notes                                                      |\n|-------|-------------------|--------|----------|------------------------------------------------------------|\n| 0     | Version           | UInt   | No       | Default \"1\", which version of this specification is in use |\n| 1     | Reference Details | Object | Yes      | An object detailing CIP-48 references in use               |\n\n## Reference Details Fields\n\n| index | name       | type              | required | notes                  |\n|-------|------------|-------------------|----------|------------------------|\n| 1     | References | Array\\<Reference> | No       | An array of References |\n\n\n## Reference Fields\n\n| index | name    | type   | required | notes                                                                                                                 |\n|-------|---------|--------|----------|-----------------------------------------------------------------------------------------------------------------------|\n| 0     | Name    | String | Yes      | A case sensitive path identifier for this reference                                                                   |\n| 1     | Type    | Enum   | Yes      | An enum of accepted types of references which may include direct payloads or pointers to other sources of information |\n| 2     | Payload | Object | Yes      | A \"Reference Payload\" object containing the information to be substituted in place of the reference                   |\n\n**TODO: Expand Support for CIP-48**\n\n## CIP-48 Example\n\n```cbor\n{\n    48: {\n        0: 1,\n        1: {\n            0: '',\n            1: '',\n            2: {}\n        }\n    }\n}\n```"
  },
  {
    "path": "CIP-0088/CIPs/0060/CIP60_v1.cddl",
    "content": "; CIP-0060: Music Token Metadata Standard\n; Version: 1\n\nstring = text .size (0..64)\n\nmusic-token-details = {\n    ; TBD\n}\n\ncip60-details = {\n    ? 0 : uint                    ; version\n      1 : music-token-details     ; CIP-0060 Music NFT Details\n}"
  },
  {
    "path": "CIP-0088/CIPs/0060/README.md",
    "content": "# CIP-88 Extension: CIP-60 | Music Token Metadata Standard\n\n`Version: 1`\n\n**TODO: Expand Support for CIP-60**"
  },
  {
    "path": "CIP-0088/CIPs/0068/CIP68_v1.cddl",
    "content": "; CIP-0068: Token Metadata Standard\n; Version: 1\n\ncip68-details = {\n    ? 0 : uint,               ; version\n    1 : token-project-details   ; [CIP-0068 Token Project Details](../common/token-project-details.cddl)\n}"
  },
  {
    "path": "CIP-0088/CIPs/0068/CIP68_v1.json",
    "content": "{\n  \"68\": {\n    \"0\": 1,\n    \"1\": {\n      \"0\": \"SpaceBudz\",\n      \"1\": [\n        \"10,000 SpaceBudz are out there.\",\n        \"Where will your SpaceBudz take you?\"\n      ],\n      \"2\": [\n        \"https://\",\n        \"static.spacebudz.io\",\n        \"/images/logo.png\"\n      ],\n      \"3\": [\n        \"https://\",\n        \"static.spacebudz.io\",\n        \"/images/banner.jpg\"\n      ],\n      \"4\": 0,\n      \"5\": [\n        [\n          \"twitter\",\n          [\n            \"https://\",\n            \"twitter.com/spacebudzNFT\"\n          ]\n        ],\n        [\n          \"discord\",\n          [\n            \"https://\",\n            \"discord.gg/spacebudz\"\n          ]\n        ]\n      ],\n      \"6\": \"SpaceBudz\"\n    }\n  }\n}"
  },
  {
    "path": "CIP-0088/CIPs/0068/CIP68_v1.schema.json",
    "content": "{\n  \"$id\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/main/CIP-0088/CIPs/0068/CIP68_v1.schema.json\",\n  \"title\": \"CIP-68: Token Project Details\",\n  \"description\": \"Additional context for token policy declaring support for CIP-68 token metadata standards\",\n  \"type\": \"object\",\n  \"properties\": {\n    \"68\": {\n      \"type\": \"object\",\n      \"properties\": {\n        \"0\": {\n          \"type\": \"integer\",\n          \"title\": \"Version\",\n          \"description\": \"The version of the standard in use\",\n          \"minimum\": 1\n        },\n        \"1\": {\n          \"title\": \"Project Details\",\n          \"description\": \"Describe top-level details about the Token Project\",\n          \"$ref\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/main/CIP-0088/common/token-project-details_v1.schema.json\"\n        }\n      },\n      \"required\": [\n        \"1\"\n      ]\n    }\n  },\n  \"required\": [\n    \"68\"\n  ]\n}"
  },
  {
    "path": "CIP-0088/CIPs/0068/README.md",
    "content": "# CIP-88 Extension: CIP-0066 | Datum Token Project Information\n\n`Version: 1`\n\n## Top-Level Fields\n\nBoth CIP-25 and CIP-68 are specifications describing a standard for storing and retrieving token metadata from the\nchain. To this end, we have given them the same data structure although each will utilize their own numerical index in\nthe feature set and CIP-Specific details section of the registration.\n\nThese sections may be separated in the future if the respective CIPs diverge in terms of the data or information that\nmay be useful to provide about one format or the other in the future.\n\n| index | name                     | type             | required | notes                                                                                                       |\n|-------|--------------------------|------------------|----------|-------------------------------------------------------------------------------------------------------------|\n| 0     | Version                  | Unsigned Integer | No       | Default: 1, which version of this specification is in use                                                   |\n| 1     | Token Collection Details | Object           | Yes      | Provide additional context about this \"Collection\" for consumption by marketplaces, explorers, and wallets. |\n\nThe information registered here is helpful to aggregator services and marketplaces, it applies equally to both CIP-25\nand CIP-68 metadata standards. A project utilizing one or the other should reference this documentation and include the\nrelevant information under index #6, prefixed by the number of the CIP (25 or 68) depending upon the metadata format.\n\n## Token Collection Details Fields\n\n| index | name                | type     | required |\n|-------|---------------------|----------|----------|\n| 0     | Collection Name     | String   | Yes      |\n| 1     | Description         | Array    | No       |\n| 2     | Project Image       | UriArray | No       |\n| 3     | Project Banner      | UriArray | No       |\n| 4     | NSFW Flag           | 0 or 1   | No       |\n| 5     | Social Media        | Array    | No       |\n| 6     | Project/Artist Name | String   | No       |\n\nFor details on what these fields represent and how they should be structured in the metadata, please refer to\n[Token Project Details](../common/Token-Project-Details_v1.md)\n\n## CIP-68 Example\n\n```cbor \n{\n  68: {\n    0: 1,\n    1: {\n      0: \"SpaceBudz v2\",\n      1: [\n        \"This is a description of my project\",\n        \"longer than 64 characters so broken up into a string array\"\n      ],\n      2: [\n        \"https://\",\n        \"static.coolnftproject.io\",\n        \"/images/icon.png\"\n      ],\n      3: [\n        \"https://\",\n        \"static.coolnftproject.io\",\n        \"/images/banner1.jpg\"\n      ],\n      4: 0,\n      5: [\n        [\n          \"twitter\",\n          [\n            \"https://\",\n            \"twitter.com/spacebudzNFT\"\n          ]\n        ],\n        [\n          \"discord\",\n          [\n            \"https://\",\n            \"discord.gg/spacebudz\"\n          ]\n        ]\n      ],\n      6: \"SpaceBudz\"\n    }\n  }\n}\n```"
  },
  {
    "path": "CIP-0088/CIPs/0086/CIP86_v1.cddl",
    "content": "; CIP-86: Token Metadata Update Oracles Standard\n; Version: 1\n\naddress = bytes\n\ncip86-details = {\n    ? 0: uint,     ; version\n      1: address   ; main address (an address capable of providing a new address to be used for updates per CIP-0086)\n      2: address   ; update address (the address to monitor for metadata updates per CIP-0086)\n}"
  },
  {
    "path": "CIP-0088/CIPs/0086/README.md",
    "content": "# CIP-88 Extension: CIP-0086 | Token Metadata Update Oracles\n\n`Version: 1`\n\n## Top Level Fields\n\n| index | name           | type                | required |\n|-------|----------------|---------------------|----------|\n| 0     | version        | Unsigned Integer    | No       |\n| 1     | main address   | [Address](#address) | Yes      |\n| 2     | update address | [Address](#address) | Yes      |\n\n### Field Notes\n\n#### 0: Version\n\n***Type: Unsigned Integer | Required: No | Default: 1***\n\nThe version of this standard being used\n\n#### 1: Main Address\n\n***Type: [Address](#address) | Required: Yes***\n\nAn address capable of providing a new address to be used for updates\nper [CIP-0086](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0086).\n\n#### 2: Update Address\n\n***Type: [Address](#address) | Required: Yes***\n\nThe address to monitor for metadata updates\nper [CIP-0086](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0086).\n\n## Address\n\n**Type: Array\\<String>**\n\nAn address should be represented in the metadata (JSON) as an array of strings using the hex-encoded address value.\n\nIn CBOR, the Address should be represented as a byte-encoded string.\n\n### Examples\n\n#### Enterprise Address\n\n**JSON**\n```json\n{\n  \"1\": [\"613d4d8113505bc64686c7baf802b4ce14c9e203f8a3cd4377babfb3a3\"]\n}\n```\n\n**CBOR**\n```cbor\n{\n    1: h'613d4d8113505bc64686c7baf802b4ce14c9e203f8a3cd4377babfb3a3'\n}\n```\n\n#### Staking Address\n\n**JSON**\n```json\n{\n  \"1\": [\"01640020a2dafc5f336104f78afe924637c06f269b207ed44782a105f0\", \"8910cb650afd1bd6cf3fc1480887bfe5d211a0770d0d3fd70fc8e6b9\"]\n}\n```\n\n**CBOR**\n```cbor \n{\n    1: h'01640020a2dafc5f336104f78afe924637c06f269b207ed44782a105f08910cb650afd1bd6cf3fc1480887bfe5d211a0770d0d3fd70fc8e6b9'\n}\n```\n\n## CIP-86 Example\n\n```cbor\n{\n    86: {\n        0: 1,                                                                                                                       ; Version\n        1: h'613d4d8113505bc64686c7baf802b4ce14c9e203f8a3cd4377babfb3a3',                                                           ; Main Address\n        2: h'01640020a2dafc5f336104f78afe924637c06f269b207ed44782a105f08910cb650afd1bd6cf3fc1480887bfe5d211a0770d0d3fd70fc8e6b9'    ; Update Address\n    }\n}\n```"
  },
  {
    "path": "CIP-0088/CIPs/README.md",
    "content": "# CIP-0088: CIP-Specific Details\n\nThis document describes the format and standards to be used when adding a CIP-specific extension to CIP-88.\n\n## Why CIP-Specific Extensions?\n\nThe CIP-88 Standard was developed to be future-proof and extensible from the beginning and is the primary rationale for\nincluding CIP-Specific fields and information in a separately versioned and documented format to allow individual \ncomponents of the standard to expand and develop at their own pace while keeping the core functionality of the standard\nunchanged.\n\nThe hope is that this method will provide for ultimate flexibility while making it easy for downstream integrators to\nprovide functionality for the pieces of information that they choose to explicitly accept.\n\n## Documentation Format\n\nEach CIP-Specific Extension to CIP-88 MUST include a readme documentation of the specified fields as well as a CBOR\nCDDL file describing the on-ledger format of the metadata. A JSON example and schema document SHOULD also be included.\n\nCIP-Specific Extensions to CIP-88 SHOULD only be added after the referenced CIP has achieved `Active` status following\ncommunity review and CIP-88 Extensions MUST be added as separate pull requests to further undergo community review and\nfeedback prior to acceptance as part of the CIP-88 standard.\n\nCIP-Specific Extensions documentation MUST be placed within a zero-prefixed directory with the CIP numerical ID within\nthis directory.\n\nAll documents SHOULD follow the format and naming examples found in the [Templates](./template) directory.\n\n\n\n\n\n"
  },
  {
    "path": "CIP-0088/CIPs/common/CIP88_Master_v1.cddl",
    "content": "; CIP-0088 Cardano Registration Certificates\n; Version: 1\n\n; Definitions\nstring = text .size (0..64)\n\n; A token-asset is a reference to a specific token\n\npolicy-id = bytes .size (28) ; Policy ID bytes\nasset-id = bytes .size (0..32) ; Asset ID bytes\n\ntoken-asset = {\n    policy-id,\n    asset-id\n}\n\n; A uri should consist of a scheme and one or more path strings describing the path to the resource\n; The first entry should contain the URI \"Scheme\" (e.g. \"https://\", \"ftp://\", \"ar://\", \"ipfs://\")\n; One or more subsequent entries should describe the path of the URI\n\nuri.scheme = text .size (5..64)\nuri.path = text .size (1..64)\nuri = {\n    uri.scheme,\n    + uri.path\n}\n\n; CIP Details\n;\n; CIP-Specific details should each be documented in their own versioned file for historic compatibility and future-proofing\n; against changes to the specification. Wherever possible, future specs should honor previous fields and be only additive\n; where possible. Previously used numeric indexes should never be repurposed.\n\ncip-details = {\n    ? 25 : cip25-details, ; ./cip/CIP-25_v1.cddl\n    ? 26 : cip26-details, ; ./cip/CIP-26_v1.cddl\n    ? 27 : cip27-details, ; ./cip/CIP-27_v1.cddl\n    ? 48 : cip48-details, ; ./cip/CIP-48_v1.cddl\n    ? 60 : cip60-details, ; ./cip/CIP-60_v1.cddl\n    ? 68 : cip68-details  ; ./cip/CIP-68_v1.cddl\n    ? 86 : cip86-details  ; ./cip/CIP-86_v1.cddl\n}\n\n; Registration Scopes\n;\n; Each registration should begin with a scope declaring the type of object being registered\n\ntoken-scope = {\n    0,                      ; scope identifier\n    bytes .size (28),       ; Token Policy ID\n    [+ bytes .size (1..64)] ; Token Policy Hex\n}\n\n; Validation Methods\n; 0 = Ed25519 Key Signature\n; 1 = \"Beacon\" or Reference Token Mint (CIP-27 \"Nameless\" Token)\n\nvalidation.method = uint;\nvalidation.context = string;\n\nvalidation-details = {\n    validation.method,\n    * validation.context\n}\n\nscope-details = {\n    1 : token-scope         ; Registration scope\n    2 : [* uint],           ; Feature Set\n    3 : validation-details, ; Signature Method\n    4 : uint,               ; Nonce\n    ? 5 : uri,              ; Oracle URI\n    ? 6 : cip-details       ; CIP-specific details\n}\n\nwitness = {\n    bytes .size (32), ; Public Key\n    bytes .size (64)  ; Signature\n}\n\nwitnesses = [+ witness]\n\ncip88-registration = {\n    ? 0 : uint, ; version\n    1 : scope-details,\n    ? 2 : witnesses\n}\n\nmetadata = { 867 : uint => cip88-registration }"
  },
  {
    "path": "CIP-0088/CIPs/common/CIP88_Master_v2.cddl",
    "content": "; CIP-0088 Cardano Registration Certificates\n; Version: 2\n\n; Definitions\nstring = text .size (0..64)\n\n; A token-asset is a reference to a specific token\n\npolicy-id = bytes .size (28) ; Policy ID bytes\nasset-id = bytes .size (0..32) ; Asset ID bytes\npool-id = bytes .size (28) ; Pool ID bytes\n\ntoken-asset = [\n    policy-id,\n    asset-id,\n]\n\n; A uri should consist of a scheme and one or more path strings describing the path to the resource\n; The first entry should contain the URI \"Scheme\" (e.g. \"https://\", \"ftp://\", \"ar://\", \"ipfs://\")\n; One or more subsequent entries should describe the path of the URI\n\nuri.scheme = text .size (5..64)\nuri.path = text .size (1..64)\nuri = [\n    uri.scheme,\n    + uri.path,\n]\n\n; CIP Details\n;\n; CIP-Specific details should each be documented in their own versioned file for historic compatibility and future-proofing\n; against changes to the specification. Wherever possible, future specs should honor previous fields and be only additive\n; where possible. Previously used numeric indexes should never be repurposed.\n\ncip-details = {\n    ? 25 : cip25-details,  ; ./cip/CIP-25_v1.cddl\n    ? 26 : cip26-details,  ; ./cip/CIP-26_v1.cddl\n    ? 27 : cip27-details,  ; ./cip/CIP-27_v1.cddl\n    ? 48 : cip48-details,  ; ./cip/CIP-48_v1.cddl\n    ? 60 : cip60-details,  ; ./cip/CIP-60_v1.cddl\n    ? 68 : cip68-details,  ; ./cip/CIP-68_v1.cddl\n    ? 86 : cip86-details,  ; ./cip/CIP-86_v1.cddl\n}\n\n; Registration Scopes\n;\n; Each registration should begin with a scope declaring the type of object being registered\n\ntoken-scope = [\n    0,                       ; scope identifier\n    bytes .size (28),        ; Token Policy ID\n    [+ bytes .size (1..64)], ; Token Policy Hex\n]\n\npool-scope = [\n    1,                       ; scope identifier\n    pool-id,                 ; Stake Pool ID\n]\n\n; Validation Methods\n; 0 = Ed25519 Key Signature\n; 1 = \"Beacon\" or Reference Token Mint (CIP-27 \"Nameless\" Token)\n; 2 = \"CIP-0008\" COSE Signature\n\nvalidation.method = uint;\nvalidation.context = string;\n\nvalidation-details = [\n    validation.method,\n    * validation.context,\n]\n\ncalidus-key = bytes .size (32) ; An Ed25519 public key that can be used to provide future updates/authentication\n\nregistration-scope = token-scope / pool-scope\n\nscope-details = {\n      1 : registration-scope,   ; Registration scope\n      2 : [* uint],             ; Feature Set\n      3 : validation-details,   ; Signature Method\n      4 : uint,                 ; Nonce\n    ? 5 : uri,                  ; Oracle URI\n    ? 6 : cip-details,          ; CIP-specific details\n    ? 7 : calidus-key,           ; An Ed25519 public key that is authorized for future updates/authentication\n}\n\n; Witness is changed to a map in v2 to support more dynamic types and identification in the future w/o guessing at\n; array length. It is recommended to only use v2 witnesses with v2+ registrations\nv1_witness = [\n    bytes .size (32),  ; Public Key\n    bytes .size (64),  ; Signature\n]\n\n; In v2 witnesses are changed to a map with an optional type identifier.\n; A default of 0 for \"Witness Type Identifier\" should be considered a COSE Signature from CIP-0008\n\nCOSE_Headers = {\n     1 : uint,              ; COSE Key Type\n     3 : int,               ; COSE Key Algorithm\n    -1 : uint,              ; EC Identifier\n    -2 : bytes .size (32),  ; Public Key\n}\n\nCOSE_Payload = [\n    bytes .size (41),\n    uint,\n    bytes .size (32),\n    bytes .size (64),\n]\n\nCOSE_Witness = {\n  ? 0 : uint,           ; Witness Type Identifier (optional or 0)\n    1 : COSE_Headers,   ; COSE Header Object\n    2 : COSE_Payload,   ; COSE Signature Payload\n}\n\nv2_witness = {\n    0 : uint,   ; Witness Type Identifier (Must be set)\n    1 : bytes,  ; Witness Public Key\n    2 : bytes,  ; Witness Signature\n}\n\nwitness = v1_witness / COSE_Witness / v2_witness;\n\nwitnesses = [+ witness]\n\ncip88-registration = {\n    ? 0 : uint, ; version\n      1 : scope-details,\n    ? 2 : witnesses\n}\n\nmetadata = { 867 : uint => cip88-registration }"
  },
  {
    "path": "CIP-0088/CIPs/common/CIP88_Master_v2.example.json",
    "content": "{\n  \"867\": {\n    \"0\": 2,\n    \"1\": {\n      \"1\": [\n        1,\n        \"0x4a930ad12820627500fbd68b071a22ef558acbdfbff53699f21152ce\"\n      ],\n      \"2\": [],\n      \"3\": [\n        2\n      ],\n      \"4\": 147897723,\n      \"7\": \"0x57758911253f6b31df2a87c10eb08a2c9b8450768cb8dd0d378d93f7c2e220f0\"\n    },\n    \"2\": [\n      {\n        \"1\": {\n          \"1\": 1,\n          \"3\": -8,\n          \"-1\": 6,\n          \"-2\": \"0x64e7344b00dcde14e6a498d79d96bfd72d73e2138802c41e6dd9b46662013f30\"\n        },\n        \"2\": [\n          \"0xa201276761646472657373581c4a930ad12820627500fbd68b071a22ef558acbdfbff53699f21152ce\",\n          0,\n          \"0x9fbfa7da5a94f7de7fd9eb6976a3c72fa39e8d909b10fff8e83b7a6b238df9e0\",\n          \"0x6b0ee625102b1e254698987f079e51f43585c45f837d408ce23b35619ed97c5a371c52834ba4a588e76d02bdccd9d368077a85bbfd7935588730300686ecec06\"\n        ]\n      }\n    ]\n  }\n}"
  },
  {
    "path": "CIP-0088/CIPs/common/README.md",
    "content": "# CIP-88: Common Properties\n\nWe use this common directory to declare some definitions that are shared across multiple points of the standard to\ndecrease redundant declarations and hopefully minify errors.\n\n## CIP-88 Master CDDL Specification\n\nThe master, top-level CIP-88 CDDL specification is declared in [CIP-88 Master CDDL](./CIP88_Master_v1.cddl).\n\n## URI Array Schema\n\nCIP-88 defines a \"URI Array\" as a well-formed array that can be used to declare URIs in metadata in a standardized way\nthat is easy to reconstruct when the length of a URI may exceed the string length available to on-chain metadata objects.\n\nView [URI Array Schema](./uri-array.schema.json) for details.\n\n## Token Project Details Schema\n\nCIP-25 and CIP-68 share commonality in that both represent token project \"collections\" that have many frequent/recurring\ndefinitions that must be shared with explorers and marketplaces. We declare a common and shared structure for this \n\"collection data\" that is documented further at [Token Project Details v1](./Token-Project-Details_v1.md)."
  },
  {
    "path": "CIP-0088/CIPs/common/Token-Project-Details_v1.md",
    "content": "# CIP-88: NFT Project Details Specification\n\n`Version: 1`\n\nThe Token Project Details specification attempts to provide top-level information about Token Projects for consumption\nby wallets, blockchain explorers, and marketplaces to help avoid the hassle of project creators and maintainers needing\nto notify and update all potential consumers about the details (name, description, etc) of their project.\n\nIt is broken out as a CIP-88 \"Common\" element as it is shared by at least CIP-25 and CIP-68 projects and potentially\nother standards in the future.\n\n***NFT Project Details Fields***\n\n| Index | Name                                          | Type   | Required |\n|-------|-----------------------------------------------|--------|----------|\n| 0     | [Collection Name](#0--Collection-Name)        | String | Yes      |\n| 1     | [Description](#1--Description)                | Array  | No       |\n| 2     | [Project Image](#2--Project-Image)            | URI    | No       |\n| 3     | [Project Banner](#3--Project-Banner)          | URI    | No       |\n| 4     | [NSFW Flag](#4--NSFW-Flag)                    | 0 or 1 | No       |\n| 5     | [Social Media](#5--Social-Media)              | Array  | No       |\n| 6     | [Project/Artist Name](#6--ProjectArtist-Name) | String | No       |\n\n**CBOR CDDL Specification**\n\nA dedicated CDDL file can be found at: [token-project-details_v1.cddl](./token-project-details_v1.cddl)\n\n```cbor \n; Token Project Details CDDL\n; Version: 1\n\nstring = text .size (0..64)\n\n; A uri should consist of a scheme and one or more path strings describing the path to the resource\n; The first entry should contain the URI \"Scheme\" (e.g. \"https://\", \"ftp://\", \"ar://\", \"ipfs://\")\n; One or more subsequent entries should describe the path of the URI\n\nuri.scheme = text .size (5..64)\nuri.path = text .size (1..64)\nuri = {\n    uri.scheme,\n    + uri.path\n}\n\n; NFT Project Details\n;\n; Provide top-level information about NFT projects that can be useful to marketplaces and explorers\n\nsocial-media-uri = {\n    string,                      ; social media channel name\n    uri                          ; social media URI\n}\n\ntoken-project-details = {\n    0 : string,                  ; Collection Name\n    ? 1 : [* string],            ; Description\n    ? 2 : uri,                   ; Project Image\n    ? 3 : uri,                   ; Project Banner\n    ? 4 : 0 / 1,                 ; NSFW Flag (1 = true, 0 = false)\n    ? 5 : [* social-media-uri],  ; Project social media\n    ? 6 : string                 ; Project/Artist Name\n}\n```\n\n## Field Notes\n\n### 0: Collection Name\n\n***Type: String | Required: Yes***\n\nThe \"Collection\" name that applies specifically to the tokens minted under this policy.\n\n**Example:** `\"SpaceBudz\"`\n\n### 1: Description\n\n***Type: Array | Required: No***\n\nAn array of strings containing a brief \"description\" of this project\n\n**Example:** `[\"10,000 SpaceBudz are out there.\",\"Where will your SpaceBudz take you?\"]`\n\n### 2: Project Image\n\n***Type: URI | Required: No***\n\nAn array of strings describing a URI to a \"profile image\" that may be used for this project.\n\n**Example:** `[\"ipfs://\", \"\"]`\n\n### 3: Project Banner\n\n***Type: URI | Required: No***\n\nAn array of strings describing a URI to a \"banner image\" that may be used for this project.\n\n**Example:** `[\"ar://\",\"\"]`\n\n### 4: NSFW Flag\n\n***Type: 0 or 1 | Required: No | Default: 0***\n\n\"Not Safe for Work\" flag. Do the assets within this project contain sensitive material that may not be suitable for all\naudiences and should potentially be obfuscated or hidden. 0 = no sensitive content, \"Safe for Work\"; 1 = sensitive\ncontent, \"Not Safe for Work\"\n\n**Example:** `0`\n\n### 5: Social Media\n\n***Type: Array | Required: No***\n\nAn array of zero or more [social media handles](#social-media-handle) for the project. Each entry of the array should be\nitself an array. The first entry should be a string containing the \"name\" of the social media platform. The second entry\nshould be an array describing the URI to the social media site.\n\n### 6: Project/Artist Name\n\n***Type: String | Required: No***\n\n#### Social Media Handle\n\n***Type: Array | Required: No***\n\nA social media handle must be an array consisting of two entries. The first entry should be the string social media\nplatform identifier (i.e. `Twitter, Discord, etc`) while the second entry must be a _URI\nArray_ ([Schema Definition](./uri-array.schema.json)) consisting of two or more elements. The first element of the URI\narray MUST contain the URI Scheme as a string, while one or more subsequent string entries represent the URI path.\n\n**Specification (CBOR)**\n\n```cbor\nsocial-media-title = text .size (1..64)\nuri.scheme = text .size (5..64)\nuri.path = text .size (1..64)\n\nsocial-media-handle = {\n  social-media-title,    ; Name of the social media platform (for labelling purposes)\n  {                      ; URI Definition\n    uri.scheme,          ; URI Scheme (i.e. https://, ar://, ipfs://, ftp://)\n    + uri.path           ; One or more strings describing the path to the resource\n  }\n}\n```\n\n**Example:**\n\n```cbor \n[\n  [\n    \"Twitter\",\n    [\n      \"https://\",\n      \"twitter.com\"\n    ]\n  ],\n  [\n    \"Discord\",\n    [\n      \"https://\",\n      \"discord.gg/\",\n      \"buffybot\"\n    ]\n  ]\n]\n```\n\n### 6: Project/Artist Name\n\n***Type: String | Required: No***\n\nIf this policy is part of a larger project or series from a specific artist or project, this field can be used to\ncontain that name.\n\n**Example:** `\"Alessandro Konrad\"`\n\n## Complete Example\n\n```cbor\n{\n  0: \"Cool NFT Project\",\n  1: [\n    \"This is a description of my project\",\n    \"longer than 64 characters so broken up into a string array\"\n  ],\n  2: [\n    \"https://\",\n    \"static.coolnftproject.io\",\n    \"/images/icon.png\"\n  ],\n  3: [\n    \"https://\",\n    \"static.coolnftproject.io\",\n    \"/images/banner1.jpg\"\n  ],\n  4: 0,\n  5: [\n    [\n      \"twitter\",\n      [\n        \"https://\",\n        \"twitter.com/spacebudzNFT\"\n      ]\n    ],\n    [\n      \"discord\",\n      [\n        \"https://\",\n        \"discord.gg/spacebudz\"\n      ]\n    ]\n  ],\n  6: \"Virtua Metaverse\"\n}\n```"
  },
  {
    "path": "CIP-0088/CIPs/common/token-project-details_v1.cddl",
    "content": "; Token Project Details CDDL\n; Version: 1\n\nstring = text .size (0..64)\n\n; A uri should consist of a scheme and one or more path strings describing the path to the resource\n; The first entry should contain the URI \"Scheme\" (e.g. \"https://\", \"ftp://\", \"ar://\", \"ipfs://\")\n; One or more subsequent entries should describe the path of the URI\n\nuri.scheme = text .size (5..64)\nuri.path = text .size (1..64)\nuri = {\n    uri.scheme,\n    + uri.path\n}\n\n; NFT Project Details\n;\n; Provide top-level information about NFT projects that can be useful to marketplaces and explorers\n\nsocial-media-uri = {\n    string,                      ; social media channel name\n    uri                          ; social media URI\n}\n\ntoken-project-details = {\n    0 : string,                  ; Collection Name\n    ? 1 : [* string],            ; Description\n    ? 2 : uri,                   ; Project Image\n    ? 3 : uri,                   ; Project Banner\n    ? 4 : 0 / 1,                 ; NSFW Flag (1 = true, 0 = false)\n    ? 5 : [* social-media-uri],  ; Project social media\n    ? 6 : string                 ; Project/Artist Name\n}"
  },
  {
    "path": "CIP-0088/CIPs/common/token-project-details_v1.schema.json",
    "content": "{\n  \"title\": \"Project Details\",\n  \"description\": \"Describe top-level details about the NFT Project\",\n  \"type\": \"object\",\n  \"properties\": {\n    \"0\": {\n      \"title\": \"Policy Name\",\n      \"description\": \"The collection name for NFTs minted under this policy\",\n      \"type\": \"string\",\n      \"maxLength\": 64\n    },\n    \"1\": {\n      \"title\": \"Policy Description\",\n      \"description\": \"Description for the NFT project\",\n      \"type\": \"array\",\n      \"items\": {\n        \"type\": \"string\",\n        \"maxLength\": 64\n      }\n    },\n    \"2\": {\n      \"title\": \"Project Image\",\n      \"description\": \"Project icon image URI\",\n      \"$ref\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/main/CIP-0088/common/uri-array.schema.json\"\n    },\n    \"3\": {\n      \"title\": \"Project Banner Image\",\n      \"description\": \"Project banner image URI\",\n      \"$ref\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/main/CIP-0088/common/uri-array.schema.json\"\n    },\n    \"4\": {\n      \"title\": \"Not Safe for Work Flag\",\n      \"description\": \"Flag whether the NFTs in the policy contain sensitive content that may not be suitable for all audiences\",\n      \"type\": \"integer\",\n      \"enum\": [\n        0,\n        1\n      ]\n    },\n    \"5\": {\n      \"title\": \"Social Media URIs\",\n      \"description\": \"An object containing links to social media profiles for the project\",\n      \"type\": \"array\",\n      \"items\": {\n        \"title\": \"Project Social Network URI\",\n        \"$ref\": \"#/$defs/socialMediaUri\"\n      }\n    },\n    \"6\": {\n      \"title\": \"Project Name\",\n      \"description\": \"The name of the project creating this collection\",\n      \"type\": \"string\",\n      \"maxLength\": 64\n    }\n  },\n  \"required\": [\n    \"0\"\n  ],\n  \"$defs\": {\n    \"socialMediaUri\": {\n      \"title\": \"Social Media URI\",\n      \"type\": \"array\",\n      \"minItems\": 2,\n      \"items\": [\n        {\n          \"title\": \"Social Network Name\",\n          \"description\": \"The name of the social network\",\n          \"type\": \"string\",\n          \"minLength\": 1,\n          \"maxLength\": 64,\n          \"examples\": [\n            \"Twitter\",\n            \"X\",\n            \"Discord\",\n            \"Website\"\n          ]\n        },\n        {\n          \"title\": \"Social Network Link\",\n          \"description\": \"A URI Array pointing to the social network resource\",\n          \"$ref\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/main/CIP-0088/common/uri-array.schema.json\"\n        }\n      ]\n    }\n  }\n}"
  },
  {
    "path": "CIP-0088/CIPs/common/uri-array.schema.json",
    "content": "{\n  \"$id\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/main/CIP-0088/common/uri-array.schema.json\",\n  \"title\": \"URI Array\",\n  \"$comment\": \"Because Cardano has a 64-character per string limit in on-chain JSON. Long strings should be broken up into an array of string parts. Particularly helpful for URIs that point to a resource on the internet is breaking URIs by scheme and path. This allows explorers to quickly and easily identify the type of resource before proceeding.\",\n  \"type\": \"array\",\n  \"minItems\": 2,\n  \"items\": [\n    {\n      \"title\": \"URI Scheme\",\n      \"description\": \"The protocol schema definition\",\n      \"type\": \"string\",\n      \"examples\": [\n        \"https://\",\n        \"ar://\",\n        \"ipfs://\"\n      ],\n      \"minLength\": 4,\n      \"maxLength\": 64\n    },\n    {\n      \"title\": \"URI Path\",\n      \"description\": \"One or more strings (64-character limit) to compose the URI\",\n      \"type\": \"string\",\n      \"minLength\": 1,\n      \"maxLength\": 64,\n      \"examples\": [\n        \"faucet.spacecoins.io\",\n        \"bafkreibva6x6dwxqksmnozg44vpixja6jlhm2w7ueydkyk4lpxbowdbqly\",\n        \"WRi9jboeKx1fbjcvO5q0kshaMmdaYgDnYlMEy-loZeY\"\n      ]\n    }\n  ],\n  \"additionalItems\": {\n    \"title\": \"Path (Cont.)\",\n    \"type\": \"string\",\n    \"minLength\": 1,\n    \"maxLength\": 64\n  },\n  \"examples\": [\n    [\n      \"ar://\",\n      \"WRi9jboeKx1fbjcvO5q0kshaMmdaYgDnYlMEy-loZeY\"\n    ],\n    [\n      \"https://\",\n      \"spacecoins.io\"\n    ],\n    [\n      \"ipfs://\",\n      \"bafkreibva6x6dwxqksmnozg44vpixja6jlhm2w7ueydkyk4lpxbowdbqly\"\n    ]\n  ]\n}"
  },
  {
    "path": "CIP-0088/CIPs/template/CIPXXXX_v1.cddl",
    "content": "; CIP-XXXX: CIP-Descriptor\n; Version: 1\n\n; Define any common or reusable pieces such as strings, URIs, etc\n\nstring = text .size (0..64)\n\n; Define any nested objects before the top-level object\n\ndetails-object = {\n  0 : string            ; Something\n  ? 1 : uint            ; Foo\n  ? 2 : [+ string]      ; Stuff\n}\n\n; Define the top-level CIP object\n\ncip-xxxx-details = {\n  ? 0 : uint            ; optional version number\n  ? 1 : details-object  ; optional details object\n}"
  },
  {
    "path": "CIP-0088/CIPs/template/CIPXXXX_v1.json",
    "content": "{\n  \"XXXX\": {\n    \"0\": 1,\n    \"1\": {\n      \"0\": \"Blah!\",\n      \"1\": 492,\n      \"2\": [\n        \"Thing #1\",\n        \"Thing #2\"\n      ]\n    }\n  }\n}"
  },
  {
    "path": "CIP-0088/CIPs/template/CIPXXXX_v1.schema.json",
    "content": "{\n  \"$id\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/main/CIP-0088/CIPs/XXXX/CIPXXXX_v1.schema.json\",\n  \"title\": \"CIP-XXXX: CIP-Descriptor\",\n  \"description\": \"Describe what we're declaring in this JSON object here...\",\n  \"type\": \"object\",\n  \"properties\": {\n    \"XXXX\": {\n      \"type\": \"object\",\n      \"properties\": {\n        \"0\": {\n          \"title\": \"Version\",\n          \"description\": \"The version of this standard being used\",\n          \"type\": \"integer\",\n          \"minimum\": 1\n        },\n        \"1\": {\n          \"type\": \"object\",\n          \"title\": \"CIP-XXXX Details\",\n          \"description\": \"What's going on here?\",\n          \"properties\": {\n            \"0\": {\n              \"type\": \"string\",\n              \"maxLength\": 64,\n              \"title\": \"Something\",\n              \"description\": \"Probably nothing\"\n            },\n            \"1\": {\n              \"type\": \"integer\",\n              \"title\": \"Foo\",\n              \"description\": \"Number of Bars\"\n            },\n            \"2\": {\n              \"type\": \"array\",\n              \"title\": \"Stuff\",\n              \"description\": \"Array of things\",\n              \"items\": {\n                \"type\": \"string\",\n                \"maxLength\": 64,\n                \"title\": \"Stuff Item\",\n                \"description\": \"Stuff can be things but are all things stuff?\"\n              }\n            }\n          },\n          \"required\": [\"0\"]\n        }\n      },\n      \"required\": [\"1\"]\n    }\n  },\n  \"required\": [\"XXXX\"]\n}"
  },
  {
    "path": "CIP-0088/CIPs/template/README.md",
    "content": "# CIP-88 Extension: CIP-XXXX | CIP-Descriptor\n\n`Version: 1`\n\n## Top-Level Fields\n\n| index | name              | type   | required | notes                                                     |                                                     \n|-------|-------------------|--------|----------|-----------------------------------------------------------|\n| 0     | Version           | UInt   | No       | Default: 1, which version of this specification is in use |\n| 1     | Details Object #1 | Object | No       | An object describing the CIP-Specific fields              |\n\n**Note: The Details Object can and SHOULD be renamed to match the needs of the CIP in question.\nAdditional indices and detail structures may be added at the top level of a CIP-Specific Extension.\nPlease remove this line prior to publication.**\n\n## Details Object #1 Fields\n\n| index | name      | type   | required | notes                             |\n|-------|-----------|--------|----------|-----------------------------------|\n| 0     | Something | String | Yes      | This is a note about Something... |\n| 1     | Foo       | UInt   | No       | The number of bars                |\n| 2     | Stuff     | Array  | No       | Can contain things                |\n\n### Field Notes\n\n#### 0: Something\n\n***Type: String | Required: Yes***\n\nDescribe what something is and what it does here...\n\n**Example:** `\"Things\"`\n\n#### 1: Foo\n\n***Type: Unsigned Integer | Required: No | Default: 0***\n\nDescribe the Foo field and what it's for here...\n\n**Example:** `7`\n\n#### 2: Stuff\n\n***Type: Array | Required: No | Default: Null***\n\nUse a table and/or prose to describe the contents of the Stuff array here...\n\n**Example:** `[\n'Thing #1',\n'Thing #2'\n]`\n\n## CIP-XXXX Example\n\n```cbor\n{\n    XXXX: {                  ; CIP-Specific Identifier\n        0: 1,                ; version\n        1: {                 ; details object #1\n            0: 'Blah!'       ; Something\n            1: 492           ; Foo\n            2: [             ; Stuff\n                'Thing #1',  ; Things...\n                'Thing #2'   ; More things...\n            ]\n        }\n    }\n}  \n```\n\n\n"
  },
  {
    "path": "CIP-0088/README.md",
    "content": "---\nCIP: 88\nTitle: Token Policy Registration\nCategory: Tokens\nStatus: Active\nAuthors:\n    - Adam Dean <adam@crypto2099.io>\nImplementors: \n    - VeriGlyph Nexus: https://nexus.veriglyph.io\n    - VeriGlyph Seninel: https://seninel.veriglyph.io\n    - Cardano Signer: https://github.com/gitmachtl/cardano-signer?tab=readme-ov-file#cip-88v2-calidus-pool-key-mode\nDiscussions:\n    - https://github.com/cardano-foundation/cips/pull/467\nCreated: 2023-02-27\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nCurrently, token projects (NFT or FT) have no mechanism to register the intent, details, or feature set of their minting\npolicy on-chain. This CIP will aim to create a method that is backwards compatible and enable projects to declare, and\nupdate over time, the supported feature set and metadata details pertaining to their tokens.\n\nThis CIP will aim to make use of a hybrid (on and off-chain) information schema to enable maximum flexibility and\nadaptability as new and novel use cases for native assets expand and grow over time.\n\n## Motivation: Why is this CIP necessary?\n\nThis CIP was borne out of a distaste for the lack of on-chain token policy intent registration that has been cited as\nboth a centralization and security concern at various points over the preceding two years of native asset history on\nCardano.\n\n***Example 1: The Cardano Token Registry***\n\nMany Fungible Token (FT) projects require special treatment of their native assets such as decimal places for proper\ndisplay and formatting, project information, and token logo. As it stands, these projects must currently register via a\nGitHub repository ([Cardano Token Registry](https://github.com/cardano-foundation/cardano-token-registry)) in order to\nhave their token properly appear in wallets. This GitHub repository is currently managed by the Cardano Foundation (CF).\nWhile there is no reason to believe that the CF would take any malicious or nefarious action, forcing token projects to\nregister in this fashion introduces a point of centralization, _potential_ gate keeping, and ultimately reliance on the\ninteraction of a 3rd party (the human at CF responsible for merging pull requests) in order for projects to register, or\nupdate, their information.\n\n***Note:*** The original intent of the *CIP-26 Cardano Token Registry* was never to have a sole provider or\ncontroller of the repository. However, time has shown that there is little interest from the community or various\nservice providers to contribute or participate in this or alternative solutions.\n\nThis CIP attempts to provide a decentralized solution to this problem.\n\n***Example 2: Token Metadata Insecurity***\n\nOne of the stated rationales for [CIP-68](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0068) was that the\n\"original\" Cardano NFT Metadata Standard ([CIP-25](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025)) was\ninsecure in some example use cases. This is due to the link between the transactional metadata and the minting of native\nassets. For example, a smart contract that cannot/does not validate against transaction metadata (i.e. Liquidity Pool\ntokens) could have a malicious user inject CIP-25 metadata into the transaction, potentially inserting illicit, illegal,\nor otherwise nefarious metadata information tied to the tokens which may be picked up and displayed to end users\nunwittingly by explorers and wallets.\n\n***Example 3: De-duplication of Data***\n\nSimilar to **Example 1** above, when it comes to Non-Fungible Token (NFT) projects\ncurrently operating on the chain there is usually a desire to provide some level of information that pertains to all\ntokens under the given policy. Examples include project/collection names, social media handles, and miscellaneous\nproject registration information. At current, this is generally solved by adding \"static\" fields in the metadata of\nevery token. By moving this project-specific information a layer higher, not only do we achieve a path to dynamism\nbut also reduce ledger bloat size by de-duplicating data.\n\nSimilarly, there are currently multiple marketplaces and decentralized exchanges (DEXes) in operation in the Cardano\necosystem. At current, most DEXes pull information from the _Cardano Token Registry_ but there is no similar function\nfor NFT projects. As such, much information must be manually provided to individual marketplaces by the token projects\ncreating an undue burden on the project creators to provide a largely static amount of information via different web\nforms and authentication schemes rather than simply publishing this information to the blockchain directly.\n\n### CPS-0001: Metadata Discoverability and Trust\n\n[CPS-0001](https://github.com/cardano-foundation/CIPs/pull/371) presents a problem of metadata discoverability and\ntrust.\nThis CIP attempts to address and solve several of the issues proposed in CPS-0001 but is most likely not a \"complete\"\nsolution and is rather narrowed (for the time being) to the scope of token projects although with some refinement to\nthe schema could potentially be expanded to support additional scopes.\n\n#### Discoverability\n\nThe primary purpose of this CIP is to enhance discoverability of token projects utilizing and parsing only the\ninformation contained on-chain. In the first version of this CIP we address the discoverability of top-level information\nrelated to \"Token Projects\" such as NFT and FT projects needing to provide social media handles, human-friendly names,\netc.\n\nThe goal of both minimizing redundant data stored on-chain and enhancing discoverability of projects for platforms\nlike DExes and NFT Marketplaces is specifically referenced in Example #3 above.\n\nNote that while some external chain indexing and validation will ultimately be required, there is no off-chain,\ncentralized or decentralized trusted repository of additional information required (although aspects of the metadata\nprovided may rely on off-chain storage solutions).\n\n#### Correctness\n\nThis CIP aims to ensure metadata \"correctness\" on two different fronts.\n\n1. **Actual Data Correctness**\n    - This CIP utilizes a strongly-typed, numerically indexed data structure that should minimize common errors and\n      omissions observed in less strictly-typed standards. Parsers of the data presented within the scope of this\n      standard should ignore any non-specified or non-conforming data.\n2. **Data Provenance**\n    - Specifically in the context of correctness via proving provenance of the metadata, this CIP aims to address\n      correctness via the same data witness standards utilized by CIP-26 although with a slightly modified data\n      structure.\n      Currently existing solutions for things like NFT Project verification standards rely on trust methods such as\n      publishing a special message on your website, send us a DM from your Twitter account, and other less secure means\n      of validating provenance of the data.\n\n#### Trust\n\nAs mentioned in the *Data Provenance* note on Data Correctness above, this CIP minimizes the trust required by relying\non a verifiable witness signature versus currently existing solutions which largely rely on off-chain trust mechanisms\nfor proof of provenance. Therefore, we increase trust in the data by describing a relatively simple means of data\nvalidation while decreasing the need for trust outside the scope of the on-chain metadata.\n\n## Specification\n\nWhere applicable the 0 (zero) index of all specification documents is reserved for an optional integer version\nidentifier to enable future extensions to this and CIP-specific sub-standards.\n\nA numeric-indexed structure is used to support required and optional fields in a format that is compatible with both\nCBOR and JSON transport formats with minimal changes to the data structure and to minimize the possibility of\nmisspelling or capitalization issues.\n\n### Modification and Extension of This Standard\n\nThis standard is likely to need frequent extension and modification, particularly relating to\n[CIP-Specific Information](#6-cip-specific-information). Any group or individual wishing to extend or modify this\nstandard MUST comply to the following criteria:\n\n- [ ] New CIPs SHOULD achieve the `Active` status prior to being included and documented in this directory after\n  undergoing the\n  regular community feedback and review process.\n- [ ] Any change or modification to `required` fields in the root standard or a CIP's specific details MUST be written\n  as a new `version`, MUST increment the version number by `1`, and MUST include new, versioned documentation for\n  the CIP while leaving previous version documentation intact for backwards compatibility.\n- [ ] Submissions for addition to this CIP MUST be made via a separate, dedicated pull request against this repository\n  so that the format and documentation pertaining to CIP-88 specifically can undergo community review and feedback\n  prior to inclusion here.\n- [ ] Whenever possible, extensions to this CIP SHOULD attempt to introduce new indices and object definitions without\n  changing or modifying existing data structures to enable new functionality and existing implementations to operate\n  until newer standards can be adopted and enhance functionality rather than change it.\n- [ ] New CIP submissions MUST follow the same paradigms and documentation examples as those found within the\n  [CIPs](./CIPs) directory including:\n    - [ ] a README.md document describing the fields, values, and rationale\n    - [ ] a CBOR CDDL specification file\n    - [ ] a JSON format schema file (_optional_)\n    - [ ] a JSON example file showing all defined fields (_optional_)\n\n### Registration Metadata Format\n\n`Version: 1`\n\n| Index | Name                                                 | Type  | Required | Notes                                                        |\n|-------|------------------------------------------------------|-------|----------|--------------------------------------------------------------|\n| 0     | Version                                              | UInt  | Yes      |                                                              |\n| 1     | [Registration Payload](#registration-payload-object) | Map   | Yes      | Object describing and providing details for the token policy | \n| 2     | [Registration Witness](#registration-witness-array)  | Array | Yes      | Array of witness signatures used to validate the payload     |\n\n### Registration Payload Object\n\nThe Token Registration Payload Object (TRPO) consists of 4 required fields and optional additional fields to\nprovide context and information. The top-level metadata label of **867** has been chosen for the purposes of this\nstandard.\n\n#### Fields\n\n| Index | Name                                        | Type   | Required | Notes/Examples                                                                                                                                                                                                                                    |\n|-------|---------------------------------------------|--------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 1     | Scope                                       | Array  | Yes      | An array defining the scope of this registration (for greater compatibility with CPS-0001). The first entry should be an unsigned integer value identifying the type of scope while the second entry addresses the specific scope of registration |\n| 2     | Feature Set                                 | Array  | Yes      | An array of unsigned integers specifying none or more CIP standards utilized by the tokens of this project. Should reference the assigned CIP number.                                                                                             |\n| 3     | Validation Method                           | Array  | Yes      | How should this payload be validated.                                                                                                                                                                                                             |\n| 4     | Nonce                                       | UInt   | Yes      | A simple cache-busting nonce. Recommend to use the blockchain slot height at the time of submission. Only the highest observed nonce value should be honored by explorers.                                                                        |\n| 5     | Oracle URI                                  | Array  | No       | Reserved for future use, URI to an informational oracle API for this policy                                                                                                                                                                       |\n| 6     | [CIP Details](#6--cip-specific-information) | Object | No       | If one or more of the CIPs addressed in the Feature Set have additionally defined metadata, it may be added here                                                                                                                                  |\n\nThe following fields are required in all token registration submissions.\n\n##### 1. Scope\n\nCurrently, this CIP concerns itself with the scope of *Tokens* with relation to CPS-0001 as described in the Motivation\nsection. However, the specification is left flexible to encapsulate additional scopes and contexts (Stake Pools, dApps,\netc.) should the specification become adopted and the community desire to expand the scope of this CIP.\n\n**Scopes**\n\n| ID  | Scope         | Format                             |\n|-----|---------------|------------------------------------|\n| 0   | Native Script | `[0, h'policyID', [h'policyHex']]` |\n\n0. **Native Scripts**: Native scripts should be specified as an array with the first entry indicating the type (Native\nScript), the second entry indicating the script hash (Policy ID) and the third entry consisting of an array with one or\nmore 64-byte strings constituting the hex-encoded CBOR representation of the Native Script itself. In this way, CIP-88\nregistration may be submitted on-chain prior to any tokens being minted and can be used by validators to confirm the\nlegitimacy of the certificate without any secondary information source.\n\n**Example:**\n\n`[0, h'3668b628d7bd0cbdc4b7a60fe9bd327b56a1902e89fd01251a34c8be', h'8200581c4bdb4c5017cdcb50c001af21d2488ed2e741df55b252dd3ab2482050']`\n\n#### 2. Feature Set\n\nThe _Feature Set_ is a simple array of unsigned integer values representing the CIP standards that should be applied to\nthe subject scope.\n\n**Example:**\n\n`[25, 27]`\n\n#### 3. Validation Method\n\nIn order to minimize issues relating to capitalization and misspellings, we should use a well-defined map of integer\nvalues for validation methods that will be utilized by third party observers and processors to authenticate the payload.\nThe validation method entry should always be provided as an array with the first element being an unsigned integer\nrepresenting the method and additional entries providing additional context to the validation as required.\n\n***Proposed Validation Methods***\n\n| ID  | Type                   | Format                              | Notes                                                                                                                                                                                                                                                                                                                                                                                                                                      |\n|-----|------------------------|-------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 0   | Ed25519 Key Signature  | `[0]`                               | The most basic and simplistic approach to signing and validation. In this case the Registration Witness object could contain one or more pubkey + signed witness objects. The payload to be signed should be the hex-encoded CBOR representation of the Registration Payload object.                                                                                                                                                       |\n| 1   | Beacon/Reference Token | `[1, [h'<policyId>',h'<assetId>']]` | Similar to the approach utilized by [CIP-27](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0027). We could attach this metadata during a mint transaction for a specially formatted token under the policy ID in question. CIP-27 uses a \"nameless\" token that has an empty \"Asset ID\" for example. This may be a validation method that lends itself better to supporting token projects that are minted via Smart Contract. |\n\n**Examples:**\n\n`[0]`,\n`[1, [h'<policyId>',h'<assetId>']]`\n\n#### 4. Nonce\n\nThe nonce value is utilized to prevent a replay attack vector. The nonce value should be an unsigned integer value that\nis always at least one greater than the previously registered value.\n\n**Example:**\n\n`12345`\n\n#### 5. Data Oracle URI\n\nTo be utilized and expanded upon in a separate CIP, this should be a valid URI pointing to a source of additional,\npotentially dynamic information relating to the project and/or the tokens minted under it.\n\n**Example:**\n\n`[\n\"https://\",\n\"oracle.mytokenproject.io/\"\n]`\n\n#### 6. CIP-Specific Information\n\nThis entry, if present, should be a CIP ID indexed object containing additional information pertaining to that CIP.\nWhen and where possible the CIP-Specific registration should follow the CBOR-like declaration syntax to ensure that\nthe content is well-formed and easily parseable.\n\n| CIP | Name                          | Version | Status | CDDL                                       | Rationale             |\n|-----|-------------------------------|---------|--------|--------------------------------------------|-----------------------|\n| 25  | Token Metadata                | 1       | Active | [CIP25_v1.cddl](./CIPs/0025/CIP25_v1.cddl) | [CIP-25](./CIPs/0025) |\n| 26  | Fungible Token Information    | 1       | Active | [CIP26_v1.cddl](./CIPs/0026/CIP26_v1.cddl) | [CIP-26](./CIPs/0026) |\n| 27  | Token Royalties               | 1       | Active | [CIP27_v1.cddl](./CIPs/0027/CIP27_v1.cddl) | [CIP-27](./CIPs/0027) |\n| 48  | Metadata References           | 1       | Draft  | [CIP48_v1.cddl](./CIPs/0048/CIP48_v1.cddl) | [CIP-48](./CIPs/0048) |\n| 60  | Music Token Metadata          | 1       | Draft  | [CIP60_v1.cddl](./CIPs/0060/CIP60_v1.cddl) | [CIP-60](./CIPs/0060) |\n| 68  | Datum Token Metadata          | 1       | Active | [CIP68_v1.cddl](./CIPs/0068/CIP68_v1.cddl) | [CIP-68](./CIPs/0068) |\n| 86  | Token Metadata Update Oracles | 1       | Active | [CIP86_v1.cddl](./CIPs/0086/CIP86_v1.cddl) | [CIP-86](./CIPs/0086) |\n\n***Note: CIP-0068 Tokens***\n\nDue to a lack of clarity in the original language of CIP-0068, standards for fungible, non-fungible, and \"rich\" fungible\ntokens have been added to the core standard. To accommodate for this, projects should use the CIP-68 data when using the\n`222` (NFT) or `444` (RFT) tokens for top-level project information. Projects utilizing the `333` (FT) style tokens\nshould utilize the CIP-26 data structure to provide fungible token context.\n\n***Beacon Token Registration***\n\nWhere applicable to a specific CIP, the CIP-specific registration may refer to a \"beacon token\". This is standardized\nin this CIP as a two-element array consisting of the hex-encoded policy ID and asset ID of the token to be used as a\nbeacon token for the purposes of smart contract interactions. e.g. `[\nh'<policy_id>',\nh'<asset_id>'\n]`\n\n**Multiple Feature Set Example (CBOR):**\n\n```cbor \n{\n  25: {\n    0: 1,\n    1: {\n      0: \"Cool NFT Project\",\n      1: [\n        \"This is a description of my project\",\n        \"longer than 64 characters so broken up into a string array\"\n      ],\n      2: [\n        \"https://\",\n        \"static.coolnftproject.io\",\n        \"/images/icon.png\"\n      ],\n      3: [\n        \"https://\",\n        \"static.coolnftproject.io\",\n        \"/images/banner1.jpg\"\n      ],\n      4: 0,\n      5: [\n        [\n          \"twitter\",\n          [\n            \"https://\",\n            \"twitter.com/spacebudzNFT\"\n          ]\n        ],\n        [\n          \"discord\",\n          [\n            \"https://\",\n            \"discord.gg/spacebudz\"\n          ]\n        ]\n      ],\n      6: \"Virtua Metaverse\"\n    }\n  },\n  27: {\n    0: 1,\n    1: {\n      1: \"0.05\",\n      2: [\n        \"addr_test1qqp7uedmne8vjzue66hknx87jspg56qhkm4gp6ahyw7kaahevmtcux\",\n        \"lpy25nqhaljc70094vfu8q4knqyv6668cvwhsq64gt89\"\n      ]\n    }\n  }\n}\n```\n\n### Registration Witness Array\n\n#### (Native Scripts)\n\nThe Witness Array included in the on-chain metadata should consist of an array of arrays with two elements, the public\nkey of the signing key and the signed key witness. If a script requires multiple signatures, enough signatures to meet\nthe criteria of the script should be included and required for proper validation of an updated token registration.\n\nThe signing payload should be the hex-encoded Token Registration Payload Object.\n\n**Example**\n\n```cbor\n[\n  [\n    h'02b76ae694ce6549d4a20dce308bc7af7fa5a00c7d82b70001e044e596a35deb',\n    h'23d0614301b0d554def300388c2e36b702a66e85432940f703a5ba93bfb1659a0717962b40d87523c507ebe24efbb12a2024bb8b14441785a93af00276a32e08'\n  ],\n  [\n    h'26bacc7b88e2b40701387c521cd0c50d5c0cfa4c6c6d7f0901395757',\n    h'secondSignatureByteString'\n  ]\n]\n```\n\n### Example NFT Token Registration Metadata\n\nBelow is a complete example of the hypothetical metadata payload for an NFT project registering their policy on-chain.\n\n```cbor\n{\n  867: {\n    0: 1,\n    1: {\n      1: [\n        0, \n        h'3668b628d7bd0cbdc4b7a60fe9bd327b56a1902e89fd01251a34c8be', \n        h'8200581c4bdb4c5017cdcb50c001af21d2488ed2e741df55b252dd3ab2482050'\n      ],\n      2: [\n        25,\n        27\n      ],\n      3: [0],\n      4: 12345,\n      5: [\n        \"https://\",\n        \"oracle.mycoolnftproject.io/\"\n      ],\n      6: {\n        25: {\n          0: 1,\n          1: {\n            0: \"Cool NFT Project\",\n            1: [\n              \"This is a description of my project\",\n              \"longer than 64 characters so broken up into a string array\"\n            ],\n            2: [\n              \"https://\",\n              \"static.coolnftproject.io\",\n              \"/images/icon.png\"\n            ],\n            3: [\n              \"https://\",\n              \"static.coolnftproject.io\",\n              \"/images/banner1.jpg\"\n            ],\n            4: 0,\n            5: [\n              [\n                \"twitter\",\n                [\n                  \"https://\",\n                  \"twitter.com/spacebudzNFT\"\n                ]\n              ],\n              [\n                \"discord\",\n                [\n                  \"https://\",\n                  \"discord.gg/spacebudz\"\n                ]\n              ]\n            ],\n            6: \"Virtua Metaverse\"\n          }\n        },\n        27: {\n          0: 1,\n          1: {\n            1: \"0.05\",\n            2: [\n              \"addr_test1qqp7uedmne8vjzue66hknx87jspg56qhkm4gp6ahyw7kaahevmtcux\",\n              \"lpy25nqhaljc70094vfu8q4knqyv6668cvwhsq64gt89\"\n            ]\n          }\n        }\n      }\n    },\n    2: [\n      [\n        h'02b76ae694ce6549d4a20dce308bc7af7fa5a00c7d82b70001e044e596a35deb',\n        h'23d0614301b0d554def300388c2e36b702a66e85432940f703a5ba93bfb1659a0717962b40d87523c507ebe24efbb12a2024bb8b14441785a93af00276a32e08'\n      ],\n      [\n        h'26bacc7b88e2b40701387c521cd0c50d5c0cfa4c6c6d7f0901395757',\n        h'secondWitnessByteString'\n      ]\n    ]\n  }\n}\n```\n\n### Example Fungible Token Registration Metadata\n\n```cbor\n{\n  867: {\n    0: 1,\n    1: {\n      1: [\n        0, \n        h'3668b628d7bd0cbdc4b7a60fe9bd327b56a1902e89fd01251a34c8be', \n        h'8200581c4bdb4c5017cdcb50c001af21d2488ed2e741df55b252dd3ab2482050'\n      ],\n      2: [\n        26\n      ],\n      3: [0],\n      4: 12345,\n      5: [\n        \"https://\",\n        \"oracle.tokenproject.io/\"\n      ],\n      6: {\n        26: {\n          0: 1,\n          1: [\n            {\n              0: [\n                h\"d894897411707efa755a76deb66d26dfd50593f2e70863e1661e98a0\",\n                h\"7370616365636f696e73\"\n              ],\n              1: \"spacecoins\",\n              2: [\n                \"the OG Cardano community token\",\n                \"-\",\n                \"whatever you do, your did it!\",\n                \"\",\n                \"Learn more at https://spacecoins.io!\"\n              ],\n              3: \"SPACE\",\n              4: 0,\n              5: [\n                \"https://\",\n                \"spacecoins.io\"\n              ],\n              6: [\n                \"ipfs://\",\n                \"bafkreib3e5u4am2btduu5s76rdznmqgmmrd4l6xf2vpi4vzldxe25fqapy\"\n              ],\n              7: [\n                [\n                  \"ipfs://\",\n                  \"bafkreibva6x6dwxqksmnozg44vpixja6jlhm2w7ueydkyk4lpxbowdbqly\"\n                ],\n                \"3507afe1daf05498d764dce55e8ba41e4acecd5bf42606ac2b8b7dc2eb0c305e\"\n              ],\n              8: [\n                h\"d894897411707efa755a76deb66d26dfd50593f2e70863e1661e98a0\",\n                h\"7370616365636f696e74\"\n              ]\n            }\n          ]\n        }\n      }\n    },\n    2: [\n      [\n        h'02b76ae694ce6549d4a20dce308bc7af7fa5a00c7d82b70001e044e596a35deb',\n        h'23d0614301b0d554def300388c2e36b702a66e85432940f703a5ba93bfb1659a0717962b40d87523c507ebe24efbb12a2024bb8b14441785a93af00276a32e08'\n      ]\n    ]\n  }\n}\n```\n\n## Rationale: how does this CIP achieve its goals?\n\nFor this specification, I have drawn inspiration from\n[CIP-36: Catalyst/Voltaire Registration Metadata Format](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0036)\nwhich succinctly and canonically publishes data to the main chain (L1) via a metadata transaction and without any\nrequired modification or customization to the underlying ledger.\n\nBy leveraging the existing signing keys present in native asset scripts from the beginning of the Mary Era on Cardano we\ncan enable all projects to update and provide additional, verified information about their project in a canonical,\nverifiable, and on-chain way while also providing for additional off-chain information.\n\nThis makes this CIP backwards compatible with all existing standards (CIP-25, 26, 27, 68, etc) while also providing the\nflexibility for future-proofing and adding additional context and information in the future as additional use cases,\nutility, and standards evolve.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [X] This CIP should receive feedback, criticism, and refinement from: CIP Editors and the community of people involved\n  with token projects (both NFT and FT) to review any weaknesses or areas of improvement.\n- [x] Guidelines and examples of publication of data as well as discovery and validation should be included as part of\n  criteria for acceptance.\n- [X] Specifications should be updated to be written in both JSON Schema and CBOR CDDL format for maximum compatibility.\n- [x] Implementation and use demonstrated by the community: Token Projects, Blockchain Explorers, Wallets,\n  Marketplaces/DEXes.\n\n#### TO-DO ACCEPTANCE ACTIONS ####\n\n- [x] Publish instructions and tooling for publication and verification of certificates\n- [ ] Develop standard for validation of Smart Contract minted tokens\n\n### Implementation Plan\n\n1. Publish open source tooling and instructions related to the publication and verification of data utilizing this\n   standard.\n2. Achieve \"buy in\" from existing community actors and implementors such as: blockchain explorers, token marketplaces,\n   decentralized exchanges, wallets.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0089/README.md",
    "content": "---\nCIP: 89\nTitle: Distributed DApps & Beacon Tokens\nCategory: Tools\nStatus: Active\nAuthors:\n    - fallen-icarus <modern.daidalos@gmail.com>\n    - zhekson1 <zhekson@nomadpool.io>\nImplementors: []\nDiscussions: []\nCreated: 2023-02-21\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP describes a general design pattern for creating DApps where all users are given their own\npersonal DApp addresses. These DApps are called distributed-DApps (dDApps) because assets are\ndistributed across all of the user addresses. By giving everyone their own DApp address, users are\nable to maintain custody *and* delegation control of their assets at all times. In other words, this\nCIP describes how to design DeFi so that it does *not* centralize Proof-of-Stake blockchains like\nCardano. And by using beacon tokens, users are able to interact fully peer-to-peer - no third-party\nindexing system is required. As a result, dDApps are essentially just extensions to a cardano node.\n\n## Motivation: why is this CIP necessary?\n\nTo date, there are very few DeFi Dapps in which users maintain full delegation control of their\nassets. In fact, sacrificing delegation control is so common in the blockchain space that many\nProof-of-Work proponents argue that DeFi will ultimately kill Proof-of-Stake blockchains. But this\nactually isn't the fault of DeFi; **it's entirely the fault of how DeFi DApps are designed**.\n\nThe problem is that DApps are consistently designed as *concentrated-DApps*. Concentrated-DApps have\nall users share a smart contract address; any assets than must be locked up for the DApp, are locked\nup inside this shared smart contract address. But Cardano's delegation is by address, so sharing a\nsmart contract address fundamentally requires users to sacrifice delegation control of any assets\nthey lock up. In order for DeFi to not destroy Cardano's Proof-of-Stake and its on-chain government,\nusers **must** get their own addresses for DeFi DApps. \n\nSome DeFi DApps have already switched to giving everyone their own DApp addresses, but then the\nindexing piece is still an issue. At a high-level, the problem is: *if users are spread out across\nmany different addresses, how do they find each other?* So far, most DApps that have tried the\ndistributed approach have relied on a third-party for this (e.g., centralized indexers or a\ndata-availability layer).\n\nThis CIP describes a general design to distributed-DApps **that does not required a third-party\nindexing system.** Users can find and interact with each other *directly*. No middlemen/middlebots\nare required. The only thing users need is the current UTxO set which all nodes should already have.\nAnd this design is generalizable enough to be used for all kinds of DeFi Dapps: DEXs, p2p lending,\noptions trading, etc.\n\n## Specification\n\n> [!IMPORTANT]\n> All dDApps are essentially standards - all users of the DApp must use the same smart contracts\n> despite getting their own DApp addresses.\n\n### Personal DApp Addresses\n\nAll Cardano addresses have two parts:\n\n1. A payment credential\n2. An optional staking credential\n\nFor dDApps, the payment credential is the DeFi DApp's spending smart contract. But the staking\ncredential is the user's staking credential. The staking credential can be anything: a pubkey,\nnative script, or a plutus script.\n\nThe spending smart contract *must delegate owner-related spending authorization to the DApp address'\nstaking credential*. So if Alice wants to close her limit orders that are locked at her personal DEX\naddress, the staking credential she used for the DEX address must approve the transaction:\n\n- Pubkeys must sign the transaction.\n- Scripts must be successfully executed in the transaction (the withdraw 0 trick can be used for\nthis).\n\n### Peer-to-Peer Discoverability\n\nFinding each other can be done using *Beacon Tokens*.\n\nThe main idea is that the current UTxO set can be easily filtered for UTxOs that contain a specific\nnative asset. All Cardano database/API services support this ability. Beacon tokens are native\nassets whose main purpose it to tag UTxOs. \n\n> [!NOTE]\n> The concept is the same as categorizing CIPs so that they can be filtered later. In essence, the\n> UTxO set is used as a public message board and beacon tokens allow users to easily find the\n> messages relevant to them.\n\nAt a high-level, when Alice creates a limit order, she will store a beacon token *with* the limit\norder. It is the DApp's responsibility to ensure that beacon tokens are only ever found with\n**valid** DApp UTxOs. For example, the DApp should not allow Alice to store a beacon token with an\ninvalid limit order (e.g., it must have a price).\n\nBeacon tokens **should never be circulating**. They should only ever be found inside valid DApp\nUTxOs. This means beacons must be minted whenever DApp UTxOs are created, and burned whenever they\nare spent. It is fine if the net change is zero, like when updating a limit order's price, but the\ndDApp must still ensure beacon tokens are properly stored.\n\nAt a low-level, this requires the DApp's spending smart contract to work together with a set of\nminting policies. Some dDApps may only require one minting policy while others may require several.\nGenerally, the pattern is to pass the spending script's hash into the minting policies as an extra\nparameter. The minting policies must ensure that new beacon tokens are only stored with valid DApp\nUTxOs. Valid DApp UTxOs are:\n\n- Properly configured for the DApp. The minting policy ID should be included in the DApp UTxOs' datums.\n- Only ever created at addresses using the DApp's spending script and a valid staking credential.\n**Creating DApp UTxOs at a DApp address without a staking credential should not be allowed.**\n\nThe first bullet will depend on the DeFi DApp. For example, a valid limit order should have a\npositive price and have the asset in question. But all DApps should include the required minting\npolicy IDs so that the spending script can ensure beacons are burned whenever DApp UTxOs are spent.\n\nThe second bullet is required so that all DApp UTxOs discovered with the beacon tokens are\nguaranteed to be governed by the same spending conditions. In other words, users know exactly what\nbehavior to expect.\n\nDApp UTxOs must go to addresses with staking credentials because, if there is no staking credential,\nthere is technically no address owner. There is no one to contol assets locked at this address.\nTherefore, there is never a reason for users to store assets in this address.\n\n> [!TIP]\n> In order to secure DApp UTxO updates where beacons can be re-used (e.g., updating a limit order's\n> price), the minting policies can be executed as staking/observer scripts.\n\n### Sharing Reference Scripts\n\nSince all users use the same spending smart contract and minting policies, they can all use the same\nreference script UTxOs. **These reference scripts must always be available.** To make them\npermanently available, they should be deliberately locked forever inside the DApp address *without*\na staking credential. The reference script UTxOs can be deliberately stored with an invalid datum to\npermanently lock them.\n\nDoing this allows frontends to hard-code the reference script UTxOs and prevents any possible\nservice disruptions due to the reference script UTxOs being spent. By storing it inside the DApp\naddress without a staking credential, the dDApp standard is effectively \"batteries-included\".\n\n### Upgrades\n\nDistributed-DApp upgrades occur like with cardano-node:\n  \n    Users must decide when and if to upgrade their DApp addresses.\n    No DAO or multisig is needed.\n\nFor example, if Alice has v1 limit orders, she must personally decide to close these limit orders\nand create equivalent v2 limit orders. No one can force her to upgrade if she doesn't want to.\n\n> [!IMPORTANT]\n> dDApps should take care to ensure backwards compatibility. For example, it should still be\n> possible to construct the full order book even if some users are using v1 while others are now\n> using v2.\n\n## Rationale: how does this CIP achieve its goals?\n\nBy giving all users their own personal DApp addresses, DeFi no longer undermines Cardano's\nOuroboros. And by using beacon tokens to enable easy filtering of the current UTxO set, users can\nfind and interact with each other fully peer-to-peer. There is absolutely no need for a third-party\nindexing system to facilitate interactions.\n\n> [!IMPORTANT]\n> In order for the dDApp to work properly, all users must agree on which beacon tokens to use.\n> Otherwise, filtering the UTxO set will be very complicated. This is why dDApps are effectively\n> standards.\n\n### Censorship Resistant\n\ndDApps, as described in this CIP, use on-chain intents meaning limit orders are directly posted\non-chain. Because of this, on-chain intents are as censorship resistant as the Cardano's base layer.\nHowever, this censorship resistance only applies when it comes to processing intents.\n\nAnother possible avenue for censorship is when trying to find the current on-chain intents.\nThird-party indexing systems make it possible to censor users by *hiding intents*. For example, the\nindexing system can refuse to tell Alice about particular limit orders. By using beacon tokens\ninstead, no one can stop Alice from finding out about all current on-chain intents.\n\n**dDApps are maximally censorship resistant.**\n\n### Easy Address Recovery\n\nWhile only knowing the user's staking credential, the user's DApp address can easily be discovered.\nThis means there is no extra burden on users and wallets. The user's seed phrase is enough to\nrecover all of their assets in the dDApp.\n\n### Extensions to a Cardano Node\n\nSince dDApps only require filtering the current UTxO set, dDApps are essentially **extensions to a\ncardano node**. They do not require any DApp connector. Instead, they are meant to be built directly\ninto frontends similar to how WiFi support is built into all devices.\n\n> [!IMPORTANT]\n> Even light nodes should be able to integrate them.\n\n### Zero Operating Costs\n\nFiltering the current UTxO set can be done client side by nodes. For example,\n[kupo](https://github.com/CardanoSolutions/kupo) is a light-weight version of db-sync that can use\nnative assets to decide what information to add to a local database. This means wallets can support\nfeatures like *Trading Pair Watchlists* where users can keep track of the current order book for\ntheir favorite trading pairs. **This is possible without relying on any third-parties.**\n\nBecause of how easy it is to filter the UTxO set, there are no operating expenses for dDApps.\n\n### Naturally DDos Resistant\n\nSince all DApp UTxOs must be stored with beacon tokens which are native assets, the Cardano\nblockchain requires each UTxO to be stored with a minimum amount of ADA. This minimum amount of ADA\nhelps prevent creating valid dust DApp UTxOs that would make local filtering of the UTxO set hard.\n\n> [!IMPORTANT]\n> The beacon tokens themselves prevent creating *invalid* DApp UTxOs. The minimum UTxO value\n> requirement helps prevent creating absurd amounts of *valid* DApp UTxOs.\n\n### Other CIPs for Discoverability\n\nThe main difference between beacon tokens and CIPs like\n[CIP-68](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0068/README.md) is the\nscenarios they were designed to operate in. There are effectively two scenarios:\n\n    Scenario 1: only a single entity can mint a tag for a given use case.\n    Scenario 2: anyone can mint a tag for a given use case.\n\nThis simple difference results in completely different game theories for each scenario. CIP-68 was\ndesigned for scenario 1 where the business owner (or owners) are the only ones that can mint the\nreference NFT. Since the business itself depends on the reference NFT being properly used, proper\nusage is naturally incentivized.\n\nFor scenario 2, there is no natural incentive for proper usage of the tag. Consider Cardano-Swaps, a\ndistributed DEX that would be competing with several other DEXs. The value of any activity that\noccurs through Cardano-Swaps does not go to the other DEX entities. Therefore, the other DEXs have\nan incentive to destroy Cardano-Swaps in a kind of goldfinger attack. Since anyone can mint a tag,\nthe easiest way to destroy Cardano-Swaps would be to denial-of-service attack it by creating a lot\nof mis-tagged UTxOs. Then, when users try to interact with each other, there would be too much noise\nin the filtering results to find each other.\n\nCIP-68 does not defend against this kind of attack; it doesn't need to since it operates in\nscenario 1. Distributed-DApps operate in scenario 2 and therefore need more assurances than what\nCIP-68 can offer.\n\n## Path to Active\n\nThis CIP is already active.\n\n- [Cardano-Swaps](https://github.com/fallen-icarus/cardano-swaps) is a distributed order book DEX.\n- [Cardano-Loans](https://github.com/fallen-icarus/cardano-loans) is a distributed credit market.\n- [Cardano-Options](https://github.com/fallen-icarus/cardano-options) is a distributed options trading\nprotocol.\n- [Cardano-Aftermarket](https://github.com/fallen-icarus/cardano-aftermarket) is a distributed secondary\nmarket for financial assets.\n\nFinally, the above four protocols were built into a prototype desktop light wallet called\n[p2p-wallet](https://github.com/fallen-icarus/p2p-wallet) which showcase how easy it is to integrate\ndDApps directly into wallets *without* using a DApp connector.\n\n## Copyright\n[CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n"
  },
  {
    "path": "CIP-0091/README.md",
    "content": "---\nCIP: 91\nTitle: Don't force Built-In functions\nCategory: Plutus\nStatus: Proposed\nAuthors:\n    - Niels Mündler <n.muendler@posteo.de>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/cips/pulls/459\nCreated: 2023-02-05\nLicense: CC-BY-4.0\n---\n\n## Abstract\nThe Untyped Plutus Language Core (UPLC) has established itself as the target language for a host of emerging Smart Contract Languages. These languages implement type safety by checking the types of variables at compile time. In the compiled output, type information is absent and no longer required or checked. This proposal suggests replacing or enhancing the set of builtin functions with untyped builtin functions, whose arguments are devoid of any type instantiations. This change aims to improve performance and reduce resource costs.\n\n## Motivation: why is this CIP necessary?\nMany currently available UPLC builtin functions require forcing between 1 and 3 times to eliminate type instantiations checked at a higher level language of the toolstack (PLC), which most third-party tools do not use. These forces only burn cycles of nodes that evaluate contracts, since there is no actual type instantiation happening internally. By removing the need for these no-op force operations, this proposal aims to enhance performance and reduce resource costs.\n\nThere is one data point as to how much performance improvement this may bring in the non-optimized case [here](https://github.com/input-output-hk/plutus/issues/4183#issuecomment-957934430). However, the performance improvement in the optimized case is generally constant: One can bind the forced builtins to a variable at the outermost layer of the UPLC program and from there on just use the forced builtins.\n\n## Specification\n\nFor all existing UPLC Builtin Functions _x_ that require _n > 0_ forces for evaluation, this proposal suggests to implement the builtin function _x'_\nwithout any required forces.\n\nThis proposal suggests that all existing UPLC Builtin Functions _x_ be *replaced* by _x'_. Generally, this proposal also suggests that no further Builtin Functions be defined that require `force`.\n\n## Rationale: how does this CIP achieve its goals?\n\nThis proposal reduces the resources needed to evaluate builtin functions by removing the need to apply no-op force operations to them. However, the actual performance impact might be negligible, and the main impact could be on simplifying the language and making it easier for compiler writers. These are weaker reasons than widespread performance improvements. Implementing this proposal may also require a new Plutus ledger language, as described in CIP-35, due to the non-backwards-compatible changes.\n\nThe implementation will break the backward compatibility for future Plutus Smart Contracts.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] `plutus` changes\n    - [ ] Specification \n    - [ ] Production implementation\n    - [ ] Costing of the new operations\n- [ ] `cardano-ledger` changes\n    - [ ] Specification, _including_ specification of the script context translation to a Plutus Core term\n    - [ ] Implementation of new ledger language, including new ledger-script interface\n- [ ] Further benchmarking \n    - [ ] Check additional real-world examples\n- [ ] Release\n    - [ ] New Plutus language version supported in a released node version\n    - [ ] New ledger language supported in a released node version\n\n### Implementation Plan\n\nIt is currently not planned to implement this proposal.\n\n## Copyright\nThis CIP is licensed under [CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n"
  },
  {
    "path": "CIP-0093/README.md",
    "content": "---\nCIP: 93\nTitle: Authenticated Web3 HTTP requests\nCategory: Tools\nStatus: Proposed\nAuthors:\n    - Juan Salvador Magán Valero <jmaganvalero@gmail.com>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/cips/pulls/442\nCreated: 2022-12-27\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThe proposed Cardano Improvement Proposal (CIP) outlines a conventional structure for data payloads that are signed by wallets, which can be used by decentralized application (dApp) servers to authenticate user requests. By leveraging the Cardano blockchain as an identity provider, dApp servers can securely and trustlessly verify user identities without relying on centralized servers or third-party services. This CIP aims to provide a standard approach for implementing wallet signature authentication in dApps, improving the security and reliability of user interactions with decentralized systems.\n\n## Motivation\n\nThe cardano wallets have the ability to sign arbitrary piece of data as we can see in the [Message signing CIP-0008](./CIP-0008/README.md). All wallets implement the method ```api.signData(addr: Address, payload: Bytes): Promise<DataSignature>``` defined in [Cardano dApp-Wallet Web Bridge CIP-0030](./CIP-0030/README.md).\n\ndApps generate arbritary payloads as byte arrays. These payloads are signed and included in the protected headers of the signatures. The wallets are responsible for showing the payload data to the user, who will proceed to sign or reject the payload. It's a common practice to encode a string or a JSON string but there isn't any standard for the way to construct and to show this data.\n\nThe current implementations for web3 applications use static strings. This is dangerous because if a bad actor intercepts the signed message then it can be used in a replay attack by the bad actor. That's why it is very important to produce a dynamic payload rather a static string.\n\nAnother problem with the current approach is how the wallets show the information contained in the payload. The payload is a encoded byte array and it could contain anything. If Alice want to call an endpoint and Bob has the ability to change the message before Alice gets it. Alice must be notified somehow that she is signing a potentially malicious payload. A simple hex-encoded representation of the payload isn't enough to ensure a safe interaction.\n\n## Specification\n\nThis specification involves multiple parties: Wallet/Client, dApp Server and Blockchain. \n\n1. **Wallet/Client**: The Wallet/Client is responsible for managing the user's cryptographic keys. Anyone can create a wallet using the CIP-0030 API interface, but it may produce invalid or malicious data sent to the dApp. This CIP aims to validate the ownership and veracity of the data provided by wallets. Additionally, it establishes guidelines for mitigating common wallet attacks, improving security for user interaction.\n\n2. **dApp Server**: The dApp Server represents the server-side infraestructure that supports decentralized applications (dApps). It communicates with the blockchain to retrieve stored data and validate wallet status. It must enforce minimum payload requirements to ensure authenticity and protect users from malicious actors.\n\n3. **Blockchain**: The Blockchain is the underlying distributed ledger technology that forms the foundation of decentralized systems. It is a decentralized and immutable ledger that securely records all transactions and data in a chronological and transparent manner. The Blockchain can be utilized for authentication, providing user identity, and for authorization, tracking user history and current status.\n\n```\n+-----------+               +---------------+              +----------------+\n|  Wallet/  |               |  dApp Server  |              |   Blockchain   |\n|  Client   |               |               |              |                |\n+-----------+               +---------------+              +----------------+\n      |                              |                               |\n      |                              |                               |\n      | 1. Create payload            |                               |\n      |------------+                 |                               |\n      |            |                 |                               |\n      |<-----------+                 |                               |\n      |                              |                               |\n      | 2. Request signature         |                               |\n      |------------+                 |                               |\n      |            |                 |                               |\n      |<-----------+                 |                               |\n      |                              |                               |\n      | 3. Send signed payload       |                               |\n      |----------------------------->|                               |\n      |                              |                               |\n      |                              | 4. Verify signature           |   \n      |                              |------------+                  |\n      |                              |            |                  |\n      |                              |<-----------+                  |\n      |                              |                               |\n      |                              | 5. Check blockchain (optional)|\n      |                              |------------------------------>|\n      |                              |                               |\n```\n\n### Requirement Levels \n\nThe key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"NOT RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).\n\n### Payload structure\n\nThe payload MUST be encoded as a JSON string. JSON strings are semi-structured data that are human-readable. So that with a straightforward decoding into text, it will be understandable for the readers. This feature also allows the users to debug it in an easy manner, for example, with the browser debugger tools.\n\nThe content of the payload will be included in the protected header of the COSESign1 signature, hence the content effects directly the behavior and security of the system. The payload MUST have the following fields: \n\n1. The field `uri` MUST contain the full path to the endpoint, where the payload will be processed.\n\n2. Sometimes, the endpoint `uri` field is not enough to determine its purpose. The user should understand perfectly the objective of the payload which he or she is signing. That's why the payload MUST contain an `action` field with a descriptive text containing the purpose of the payload. For example, if someone calls the endpoint `/users` without an action field, they can create or delete users. However, by including the action field in the payload, it not only provides additional clarity but also effectively limits the scope of the payload.\n\n3. In order to improve globalization, the payload MAY include an `actionText` field that represents the action in the locale of the user. When present, the wallet MUST display this field to the user. By including the `actionText` field, the wallet facilitates the processing of the action field, eliminating the need for the server to be aware of the user's locale and the possible variants of the action text.\n\n4. The payload MUST include either a UNIX `timestamp` or a `slot` number. The `slot` field represents a specific time in the blockchain and serves as a reference for synchronization between the client and the server. The `timestamp` or `slot` number is also used as a nonce and serves as an indicator for payload expiration in case the payload is compromised.\n\nAdditional fields MAY be included in the payload, and these fields can be string fields or objects. Depending on the specific process or use case, including additional fields in the protected header of the signature can provide valuable functionality and security enhancements. For example, in a registration request, it may be useful to include the email information as an additional field in the protected header. By doing so, the payload can be uniquely associated with that specific email, ensuring its integrity and preventing tampering.\n\n#### JSON Schema\n```JSON\n{\n  \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n  \"type\": \"object\",\n  \"properties\": {\n    \"uri\": {\n      \"type\": \"string\",\n      \"format\": \"uri\"\n    },\n    \"action\": {\n      \"type\": \"string\"\n    },\n    \"actionText\": {\n      \"type\": \"string\"\n    },\n    \"timestamp\": {\n      \"anyOf\": [\n        {\n          \"type\": \"integer\"\n        },\n        { \"type\": \"string\", \"pattern\": \"^\\\\d+$\" }\n      ]\n    },\n    \"slot\": {\n      \"anyOf\": [\n        {\n          \"type\": \"integer\"\n        },\n        { \"type\": \"string\", \"pattern\": \"^\\\\d+$\" }\n      ]\n    }\n  },\n  \"required\": [\"uri\", \"action\"],\n  \"oneOf\": [{ \"required\": [\"timestamp\"] }, { \"required\": [\"slot\"] }],\n  \"additionalProperties\": {\n    \"type\": [\"string\", \"object\"]\n  }\n}\n```\n#### Minimum payload:\n\n```JSON\n{\n    \"uri\": \"http://example.com/signin\",\n    \"action\": \"Sign in\",\n    \"timestamp\": 1673261248,\n}\n```\n#### Sign up payload examples:\n```JSON\n{\n    \"uri\": \"http://example.com/signup\",\n    \"action\": \"Sign up\",\n    \"timestamp\": \"1673261248\",\n    \"email\": \"email@example.com\"\n}\n\n{\n    \"uri\": \"http://example.com/signup\",\n    \"action\": \"SIGN_UP\",\n    \"actionText\": \"Registrar\",\n    \"slot\": 94941399\n}\n```\n\n### Wallet specification\n\nThe wallets can improve the overall security implementing the following guidelines. We RECOMMEND to show in a structured way the payload information for sake of clarity. This information should be well understood by the users before the payload is signed.  \n\nThe `uri` field provides information about the hostname of the application. This hostname MUST be included in the wallet allow list. If a known domain A tries to sign a payload for an unknown domain B, you will be prompted with permission popup making more obvious the cross-domain interaction. When possible, the wallet SHOULD warn the user if a payload is for a different domain.\n\nThe wallet SHOULD update the `timestamp` field to the current time just before the signature. This field ideally should match the moment just before the signature such that the server receives fresh payload. \n\n### dApp Server processing\n\nThe server has ultimate responsibility of processing correctly the requests. We use the content to validate the payload. The request will be processed with the following steps:\n\n1. The server MUST check the action and the endpoint included in the request. Each route to an endpoint MUST have an associated action and a URI. The first step is to check that they match with the parameterized action.\n\n2. The server MUST check the expiration of the payload. The expiration SHOULD be enough to give time to the user to introduce the wallet password but it SHOULD NOT be too long, we RECOMMEND not more than 5 minutes.\n\n3. The server MUST validate the COSESign1 signature and check that the address inside the protected map of the signature corresponds to the public key in the COSEKey. \n\nAdditionally the server COULD extract the payload content and pass it through the server logic.\n\n## Rationale: how does this CIP achieve its goals?\n\nCIP-0008 enhances authentication by enabling individuals to prove ownership of addresses, identities, and off-chain data through message signing. It provides a reliable means of authentication by allowing individuals to attach a public key to their data and sign messages associated with that data, thereby establishing ownership and ensuring the integrity of the authentication process.\n\nAdditionally, This specification provides the general guidelines and necessary recommendations for performing secure authenticated web3 requests in the Cardano ecosystem. It covers the two main desired characteristics for a secure payload: It must expire and it must be non-static. Moreover, the signature method proposed in this CIP does not require users to spend funds in a transaction, which further lowers the cost and barriers to entry for users.\n\nAnother important aspect for security is how wallets process the payload. They can improve the security using the data inside the payload to warn the users about possible malicious interactions. This specification emphasizes the importance of informing users clearly about the purpose of the payloads and how wallets can use the URI field to apply allow-lists and/or cross-domain policies. It establishes also the requirements and recommendations for server side processing. The server must also ensure the validity of the signature and the payload, as well as of its purpose in order to accomplish the authentication. \n\nIn addition to the aforementioned aspects, this CIP also aims to promote decentralization and enhance security and privacy by enabling users to sign and verify transactions without relying on external servers or third parties. By allowing users to create and sign their own payloads, this specification reduces the dependency on centralized authorities and enhances the security and privacy of the transactions.\n\n### Alternative implementations\n\nDuring discussions about this specification, the possibility of modifying CIP-0008 to incorporate the standards defined here was considered. However, a thorough evaluation revealed that this approach would require extensive modifications to CIP-0008 and CIP-0030, leading to significant changes in the Cardano wallet API. Moreover, it would result in a lengthy waiting period for browser wallet developers to implement the necessary requirements. This could potentially bypass important security measures outlined in this CIP, such as the requirement for human readability.\n\nWhile this alternative approach brings advantages, such as defining the payload in CBOR, which aligns well with Cardano, it also presents challenges. JSON and CBOR offer different levels of expressiveness, and the choice between the two depends on the specific needs of the application. JSON provides a more flexible and widely supported data format, whereas CBOR offers a more compact and efficient representation, particularly beneficial when working with the blockchain.\n\nConsidering these factors, it was concluded that deploying this standard as it currently stands, while coexisting with a future version that allows users to choose between JSON and CBOR payloads, would be the most practical approach. This would provide sufficient time for modifying CIP-0008 and CIP-0030, enabling browser wallet developers to fulfill the requirements for human readability and make necessary adjustments to the wallet API. Consequently, a version 2 of this CIP can be introduced, incorporating COSESign and CBOR, accommodating both realms, and ensuring broad support.\n\n### Common usage\n\nThe payload signature ensures wallet ownership without incurring transaction fees. However, requiring the user to enter their spending password for every authenticated request can be inconvenient for the user experience. To address this, it is recommended to restrict the use of the payload signature to only important requests such as login, sign up, or other critical operations depending on the dApp requirements.\n\nA common practice is to request the user's signature for the login process, and once authenticated, the dApp can issue a session token, such as a JSON Web Token (JWT), to manage the session. By implementing this approach, future non-critical requests can be performed using standard web 2.0 methods, eliminating the need to enter the spending password for each step. This significantly enhances the usability of the application, providing a smoother user experience.\n\n\n### Version history\n\n| Version | Date      | Author                         | Rationale              |   \n|:-------:|-----------|--------------------------------|------------------------|\n| v1      |2022-12-27 | Juan Salvador Magán Valero     | Initial release        |\n\n\n### Reference implementation\n\n* [jmagan/passport-cardano-web3](https://github.com/jmagan/passport-cardano-web3)\n* [jmagan/cardano-express-web3-skeleton](https://github.com/jmagan/cardano-express-web3-skeleton)\n* [jmagan/cardano-nextjs-web3-skeleton](https://github.com/jmagan/cardano-nextjs-web3-skeleton)\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [X] At least one library should implement this authentication method.\n- [ ] The 80% users should have wallets implementing the following requirements:\n    1. It MUST detect when the payload is formatted using this specification.\n    2. The information contained in the payload MUST be parsed and formatted in the signing pop-up.\n    3. The wallet SHOULD update the timestamp just before the payload is signed.\n    4. The wallet MUST detect if the URI is in the allow list.\n    5. The wallet SHOULD warn the user against cross-domain requests.\n- [ ] A detailed documentation about web3 standards should be published. This documentation will include this standard and further best practices for web3 technologies.\n\n### Implementation Plan\n\n- [X] Create a library for processing payload according to this specification.\n- [X] Open a conversation about this specification and its possible improvements.\n- [X] Talk about further web3 standards and new specifications. \n- [ ] Write the documentation for web3 developers.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0093/json/payload-schema-v1.json",
    "content": "{\n  \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n  \"type\": \"object\",\n  \"properties\": {\n    \"uri\": {\n      \"type\": \"string\",\n      \"format\": \"uri\"\n    },\n    \"action\": {\n      \"type\": \"string\"\n    },\n    \"actionText\": {\n      \"type\": \"string\"\n    },\n    \"timestamp\": {\n      \"anyOf\": [\n        {\n          \"type\": \"integer\"\n        },\n        { \"type\": \"string\", \"pattern\": \"^\\\\d+$\" }\n      ]\n    },\n    \"slot\": {\n      \"anyOf\": [\n        {\n          \"type\": \"integer\"\n        },\n        { \"type\": \"string\", \"pattern\": \"^\\\\d+$\" }\n      ]\n    }\n  },\n  \"required\": [\"uri\", \"action\"],\n  \"oneOf\": [{ \"required\": [\"timestamp\"] }, { \"required\": [\"slot\"] }],\n  \"additionalProperties\": {\n    \"type\": [\"string\", \"object\"]\n  }\n}\n"
  },
  {
    "path": "CIP-0094/README.md",
    "content": "---\nCIP: 94\nTitle: On-chain SPO polls\nCategory: Tools\nStatus: Active\nAuthors:\n    - Matthias Benkort <matthias.benkort@cardanofoundation.org>\n    - Markus Gufler <markus.gufler-ext@cardanofoundation.org>\nImplementors:\n    - Matthias Benkort <matthias.benkort@cardanofoundation.org>\n    - Ashish Prajapati <https://cardanoscan.io/contactUs>\n    - Dmytro Stashenko <https://preprod.adastat.net/about>\nDiscussions:\n    - https://github.com/cardano-foundation/cips/pull/496\n    - https://github.com/cardano-foundation/cips/pull/102\n    - https://github.com/input-output-hk/cardano-node/pull/5050\n    - https://github.com/input-output-hk/cardano-node/pull/5132\n    - https://forum.cardano.org/t/entering-voltaire-on-chain-poll-for-spos/117330\n    - https://forum.cardano.org/t/entering-voltaire-poll-experiment-live-on-mainnet/117879\nCreated: 2023-03-21\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThe Cardano Foundation proposes a mechanism for polling Cardano stake pool operators on specific topics. Polls are done on-chain through transaction metadata and authenticated through stake pool credentials (Ed25519 cold key). The goal is to gather opinions on governance matters such as protocol parameter updates. This standard is an inclusive interim solution while the work on a larger governance framework such as [CIP-1694][] continues.\n\n## Motivation: why is this CIP necessary?\n<!-- A clear explanation that introduces the reason for a proposal, its use cases and stakeholders. If the CIP changes an established design, then it must outline design issues that motivate a rework. For complex proposals, authors must write a Cardano Problem Statement (CPS) as defined in CIP-9999 and link to it as the `Motivation`. -->\n\nGovernance is difficult. Discussions on CIP-1694 can attest to that quite clearly. There are constant debates within the Cardano community about changing protocol parameters, and the decision ultimately falls -- at this stage still -- onto the three genesis entities: Input Output, The Cardano Foundation and Emurgo. Yet, at this stage, few governance tools are at their disposal to make educated decisions. Besides Twitter polls, newsletter surveys, and SPO town halls on Discord, we have identified a gap and an opportunity to engage with the Cardano community through means currently at our disposal.\n\nConducting an on-chain poll between SPOs can also be seen as an experiment and an evaluation of the network's participation and engagement in the governance questions. Even though we only propose to poll one particular group of the Cardano community (the SPOs), such events can help to provide actual data to fuel the conversations around CIP-1694.\n\nIn summary, the goals are:\n\n1. [x] to make some first experimental baby steps in the realm of governance;\n1. [x] to be achievable _now_ (or an in immediate future);\n1. [x] to capture participation data from SPOs;\n1. [x] to raise awareness amongst SPOs regarding their future role in governance;\n1. [x] to keep the Voltaire dynamics up in the ecosystem while other efforts are being pursued;\n1. [x] to improve relations between the Cardano Foundation & SPOs for better mutual understanding and fruitful conversations.\n\n\n## Specification\n\n### Overview\n\nPolls will be multiple-choice questions by The Cardano Foundation with pre-defined answers to choose from.\n\nHere's an example of a question and answers:\n\n- _Pineapples on pizza?_\n  - [ ] yes\n  - [ ] no\n\nThe serialised question and answers will be posted on-chain and signed by one of the delegate genesis keys owned by The Cardano Foundation. Answers will be provided on-chain by participating SPOs via transaction metadata referring to:\n\n- The question and answers\n- The index of the chosen answer from the available choices\n- A digital signature (EdDSA) from the SPO's current cold key\n\n> **Note**\n> In this document, every time we refer to a _serialized object_, we refer to its **canonical** CBOR representation. In particular, keys in a map are always ordered alphabetically.\n\n### Question structure\n\nA question is posted in a transaction's metadata using the metadata label `94` and the following metadata structure:\n\n```cbor\nquestion =\n  { 0: prompt\n  , 1: [ * choice ]\n  , ? \"_\": nonce\n  }\n\nprompt =\n  [ * text .size (0..64) ]\n\nchoice =\n  [ * text .size (0..64) ]\n\nnonce =\n  uint\n```\n\nA nonce is optionally included to provide non-replayability should the same question and answers be asked multiple times over different periods. The transaction carrying a question **must** be signed by one of the genesis delegate keys to be considered valid. This genesis key signature isn't captured in the metadata but in the transaction itself as an extra signatory.\n\nFor example:\n\n<table>\n<thead>\n  <th>CBOR diagnostic</td>\n  <th>Base16-encoded</th>\n</thead>\n<tbody>\n <tr>\n  <td>\n<pre>\n{ 94:\n  { 0: [ \"Pineapples on pizza?\" ]\n  , 1:\n    [ [ \"yes\" ]\n    , [ \"no\" ]\n    ]\n  }\n}\n</pre>\n  </td>\n  <td>\n   <a target=\"_blank\" href=\"https://cbor.me/?bytes=A1185EA200817450696E656170706C6573206F6E2070697A7A613F0182816379657381626E6F\">\n<pre>\nA1185EA200817450696E656170706C6573206F\n6E2070697A7A613F0182816379657381626E6F\n</pre>\n   </a>\n  </td>\n </tr>\n</tbody>\n</table>\n\n### Answer structure\n\nSimilarly, an answer to a question is posted as transaction's metadata using the label `94` and the following metadata structure:\n\n```cbor\nanswer =\n  { 2: question_hash\n  , 3: choice\n  }\n\nquestion_hash =\n  bytes .size 32\n```\n\nSome remarks:\n\n1. The field `2` (`question_hash`) is a blake2b-256 hash digest, whose preimage is the entire serialised question metadata payload (with the `94` top-level label).\n1. The field `3` represents the 0-based index of the chosen answer from the available choices (from field `1` of the target poll).\n\nFor example:\n\n<table>\n<thead>\n  <th>CBOR diagnostic</td>\n  <th>Base16</th>\n</thead>\n<tbody>\n <tr>\n  <td>\n<pre>\n{\n  94: {\n    2: h'29093fd43fc30ba31e306af06ce8537390e1668ae7496fe53d53684683c3762c',\n    3: 0\n  }\n}\n</pre>\n  </td>\n  <td>\n   <a target=\"_blank\" href=\"https://cbor.me/?bytes=A1185EA202582029093FD43FC30BA31E306AF06CE8537390E1668AE7496FE53D53684683C3762C0300\">\n<pre>\nA1185EA202582029093FD43FC30BA31E306AF06CE\n8537390E1668AE7496FE53D53684683C3762C0300\n</pre>\n   </a>\n  </td>\n </tr>\n</tbody>\n</table>\n\nThe transaction carrying the answer metadata must then **be signed using a stake pool operator cold key**. Because cold key are not payment keys, it is required to specify an extra required signer on the transaction (transaction's field number 14 as per [Babbage's CDDL](https://github.com/input-output-hk/cardano-ledger/blob/cffa75fdbd800cda60997791e51bf02f2af0c42b/eras/babbage/test-suite/cddl-files/babbage.cddl#L66)) to prevent malicious nodes from potentially propagating transactions without the necessary key witnesses.\n\nAlternatively, operators that are unable to sign arbitrary transactions due to hardware limitations can opt for stake pool update-registration certificate and attach the transaction metadata to it. Because an update-registration requires a signature from the cold key, the extra required signer field is redundant in that situation.\n\nRegardless of the method, the signature shall be produced in an air-gapped environment only.\n\n> **Warning**\n>\n> Only the first answer to a poll for each credential shall be considered. If multiple answers are found, only the first answer submitted (transaction & block ordering tallying) shall be considered.\n\n### Adding context\n\nIt is possible to optionally attach extra context to the transaction as metadata following the procedure described in [CIP-0020](../CIP-0020/). Beside the structure specified in CIP-0020, such extra metadata is free-form and can be used to signal an intention behind a choice, or to voice a concern, or simply to give extra context. This is totally optional though we encourage SPOs to use this to inform their delegators of their choices.\n\n### Procedure & Duration\n\nA poll starts when a valid transaction with a question is posted on-chain. Answers can be submitted until the end of the following epoch, so there is always at least one whole epoch to answer the poll.\n\nAfter one or more epochs in which the Stake Pool Operators have cast their answers, there follows a period of one or more epochs in which Cardano delegators may respond: If they disagree with the choice of their current stake pool, they can delegate to another pool. This changes the stake weight and thus influences the result. At the current state, the epochs for the answer and redelegation phase are only defined off-chain. In the future, they could also be defined as part of the signed question.\n\n![process diagram](./CIP-0094_procedure-duration.png \"Epoch poll phases example\")\n\nIndirectly, this results in the possibility of participation for all Ada holders.\n\n### Outcome\n\nThe outcome of a poll will depend on its level of participation (in **terms of stake**). It is essential to understand that we explicitly call this a _poll_ / _survey_ and not a _vote_ to dispel any possible confusion. So it is akin to `1 Lovelace = 1 Voice` although we may chose to interpret data using different equations (e.g. giving more weight to pledged stake). How the data is interpret is deemed out of the scope of this proposal which aims mainly at producing the data-points. Further conversations and debates will be needed regarding interpretation of the data-points.\n\n\nThis proposal does not introduce a change in the current governance scheme: it is still up to the three genesis entities to make a final call based on the poll results. Poll results will provide new data points to feed into the conversation. But, regardless of the outcome, any decision will be explained and motivated by other auditable sources of information. And on-chain polls will provide such an auditable source.\n\n## Rationale: how does this CIP achieve its goals?\n\n### Recording question & answers\n\nThe proposed process will permanently record questions and their answers on-chain by leveraging existing transaction metadata. Note that we consciously do not record any element as datums. There are several reasons for this:\n\n1. Datums offer extra programmability (for being available in Plutus script context); this is not needed at this stage.\n1. Following a _keep-it-simple_ strategy, we propose relying on well-known and well-supported transaction features (a.k.a metadata) for producers and consumers.\n1. Storing data in datums / UTxO has a non-negligible cost; naive datum storage would create thousands of new dummy UTxO on each poll. Transactions are cheaper to store and consume.\n1. Polls rely on slot order when tallying answers, which means that chain sync is needed anyway, and there's no strong argument for having this information readily available in the UTxO graph.\n\n### Cold key signing vs VRF proving\n\nThere have been several (on-and-off-the-record) discussions regarding using the cold key (Ed25519) vs the VRF key as authentication instruments; and arguments for both.\n\nOn the one hand, some prefer the use of the cold key because:\n\n- The cold key is meant to authenticate stake-pools activity (e.g. certificate registrations/updates).\n- It is ultimately the cold key that identifies a pool; its hash is the _pool id_.\n- The VRF is more likely to be compromised, hence granting rights to participate in a poll to potential adversaries.\n- Cold keys are Ed25519 keys, which allows piggybacking on the existing protocol's capabilities for transaction witnesses (extra required signer + verification key witnesses).\n\nOn the other hand, arguments for using the VRF key were already discussed as part of [CIP-0022][]:\n\n- Because it's a hotkey, the VRF is usually more accessible, so it is more likely to lead to higher participation in surveys and no exposure of the cold key is needed.\n- Blocks contain VRF proofs, which serve as explicit pool identifiers.\n- It is only necessary to check that a key is correct at the moment of the poll, making VRF keys perfectly suitable.\n\nWe originally opted for a hybrid solution (as visible in input-output-hk#5050) but later decided to drop the VRF option to rely solely on cold key signing (see input-output-hk#5132). The reason for that regards the possible uncertainty of promoting (ab)use of VRF proving in the cardano-cli on such a short time period (see also [Insecurity of secret key re-usage](https://www.essentialcardano.io/article/insecurity-of-secret-key-re-usage)).\n\nThis has the unfortunate effect of making this participation procedure harder for SPOs relying on cold storage but we are open to the idea of proxy-keys authenticated off-chain through a challenge similar to [CIP-0022][].\n\n#### KES Signing\n\nThere's a third on-chain element which we could use for identifying SPOs which is a digital signature from their KES credentials. It is however a bit more annoying to leverage mainly because KES are meant to expire and are only loosely tied to pools by operational certificate. Thus, verifying KES signatures on a survey requires a more complex setup and monitoring to keep track of operational certificates and their validity at the time of the survey.\n\nIf this CIP was meant to NOT be an interim solution, this is something we would likely consider. However, given the timeframe we're looking at and the overall trade-offs in complexity, we have opted out of using the KES as an authentication mechanism in this iteration.\n\n#### Proxy keys\n\nAnother possible alternative to what's described in the CIP would be to have SPOs register a proxy Ed25519 key and use that proxy key onward. The validity of the proxy key registration would be conditionned to the production of an associated VRF proof or a digital signature from the cold key (very much like it's done for operational certificate).\n\nYet, like the KES alternative, this option is in conflict with some of the design goals of this CIP: simplicity. All the more so given that we want to maximise participation of SPOs to the various surveys. We aim to make the process of participating to the survey as simple as possible, without compromising on security.\n\n> **Note** Both alternative options for KES Signing and Proxy Keys may be re-considered in a future version of the survey. Especially if the solution turns out to be not _as temporary as intended_. Fortunately, the current design decisions do not preclude this from happening as it shall be possible to introduce two new witness types `6` and `7` for those purpose. The KES registration can be handled through a separate on-chain event.\n\n### Security\n\n#### Replayability\n\nQuestions are meant to be unique, achieved using an optional nonce. It is up to the genesis entity conducting the poll to ensure the formulated question is unique. If the same question is asked several times, the nonce provides non-replayable protection.\n\nThen, because every answer contains a (unique) hash of the question, answers are unique too. Yet, it still means that the same answer can be recast multiple times (possibly, by another system actor), so we do not allow answers to be changed/cast multiple times. The only exception is when answers are authenticated again using a cold key.\n\n#### Credentials exposure\n\nExposure to SPOs' secret credentials must be limited, and their manipulation shall be done carefully. This potential attack vector is why we propose to extend the `cardano-cli` and have support for these features scrutinised by existing core maintainers and other open source actors.\n\nOther tools are then free to replicate the approach taken in the cardano-cli, but we recommend that SPOs proceed with extreme caution when using third-party tools. In particular, any tool should be able to work fully offline to produce the required metadata. Final transaction construction and submission shall be made in any suitable environment, yet the metadata's production shall be done only in air-gapped systems.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] The Cardano Foundation has conducted a first trial poll on mainnet ([CardanoScan](https://cardanoscan.io/spo-polls/96861fe7da8d45ba5db95071ed3889ed1412929f33610636c072a4b5ab550211) / [AdaStat](https://preprod.adastat.net/polls/62c6be72bdf0b5b16e37e4f55cf87e46bd1281ee358b25b8006358bf25e71798))\n- [x] Visible agreement and engagement from a large set of SPOs\n  - [x] Multiple SPOs workshops\n  - [x] ~800 stake pools participating on the first mainnet poll\n  - [x] ~11B stake answered the first mainnet poll\n\n### Implementation Plan\n\n- [x] Provide a reference implementation for the signing method\n  - [x] [`cardano-cli`](https://github.com/input-output-hk/cardano-node/tree/master/cardano-cli#readme) [has been updated](https://github.com/input-output-hk/cardano-node/pull/5050) to provide support for constructing and signing relevant transactions.\n  - [x] Created [scripts to crawl the chain](https://github.com/cardano-foundation/CIP-0094-polls/tree/main/crawler#cip-0094-chain-crawler) for results.\n\n- [ ] Possibly add support for KES signing as an alternative to EdDSA from the cold key and the VRF proving.\n\n#### Tools Support\n\n- [x] [`cncli`](https://github.com/cardano-community/cncli) has been updated with similar support\n- [x] [`CardanoScan`](https://cardanoscan.io/spo-polls) now lists available and past polls directly on their web UI.\n- [x] [`AdaStat`](https://preprod.adastat.net/polls) now lists available and past polls directly on their web UI.\n- [ ] [`cardano-signer`](https://github.com/gitmachtl/cardano-signer) might be updated with similar support\n\n#### Test runs\n\n- [x] Announce a testnet run (on Preprod) and invite SPOs to a workshop session to conduct a testnet poll.\n  - See the [Preprod poll on AdaStat](https://preprod.adastat.net/polls/62c6be72bdf0b5b16e37e4f55cf87e46bd1281ee358b25b8006358bf25e71798).\n- [ ] ~~Possibly do a second test run, but on mainnet this time.~~\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0][].\n\n[CIP-1694]: https://github.com/cardano-foundation/CIPs/pull/380\n[CIP-0022]: https://github.com/cardano-foundation/CIPs/pull/102\n[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n[Apache-2.0]: http://www.apache.org/licenses/LICENSE-2.0\n"
  },
  {
    "path": "CIP-0095/README.md",
    "content": "---\nCIP: 95\nTitle: Web-Wallet Bridge - Conway ledger era\nCategory: Wallets\nStatus: Active\nAuthors:\n  - Ryan Williams <ryan.williams@intersectmbo.org>\nImplementors:\n  - Eternl <https://eternl.io/>\n  - GeroWallet <https://gerowallet.io>\n  - Lace <https://www.lace.io/>\n  - Mesh <https://meshjs.dev/>\n  - mLabs <https://mlabs.city/>\n  - NuFi <https://nu.fi/>\n  - Ryan Williams <ryan.williams@intersectmbo.org>\n  - Typhon <https://typhonwallet.io/>\n  - Lido Nation <https://www.lidonation.com/>\n  - Vespr <https://vespr.xyz/>\n  - Yoroi <https://yoroi-wallet.com/>\nDiscussions:\n  - https://github.com/cardano-foundation/cips/pulls/509\n  - https://discord.com/channels/826816523368005654/1101547251903504474/1101548279277309983\n  - https://discord.com/channels/826816523368005654/1143258005354328156/1143272934966837309\nCreated: 2022-02-24\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis document describes an interface between webpage/web-based stacks and\nCardano wallets. This specification defines the API of the javascript object\nthat needs to be injected into web applications.\n\nThese definitions extend\n[CIP-30 | Cardano dApp-Wallet Web Bridge](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030/README.md)\nto provide support for\n[CIP-1694 | A First Step Towards On-Chain Decentralized Governance](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md)\nfocussed web-based stacks. Here we aim to support the requirements of Ada\nholders and DReps in the Conway Ledger era, this specification is based on the\n[Conway Ledger Era Specification](https://github.com/IntersectMBO/cardano-ledger/blob/dcacf044c8d38362edc57a761e027953aab3f335/eras/conway/impl/cddl-files/conway.cddl).\n\nFor the many contributors to this proposal, see [Acknowledgements](#acknowledgements).\n\n## Motivation: why is this CIP necessary?\n\nCIP-1694 introduces many new concepts, entities and actors to Cardano;\ndescribing their implementation at the ledger level. This creates the need for\nnew tooling with respect to governance. For the average ecosystem participant,\nthe details should be abstracted away, enabling them to leverage the new ledger\nfeatures more effectively. This specification allows for creation of web-based\ntools for the utilization of CIP-1694's governance features.\n\nWhilst CIP-30 facilitated the launch of dApp development on Cardano, it's\nfunctionality is limited in scope. It was written well before the emergence of\nthe Conway Ledger Era and thus lacks the required methods to support full user\ninteraction. We believe that expecting existing CIP-30 implementors to upgrade\nimplementations is unfeasible, thus we must extend it's functionality with this\nAPI.\n\nThis proposal enables Ada holders, and DReps to engage web-based tooling through\nwallets. Thus the primary stakeholders for this proposal are tool developers and\nwallet providers. Here we aim to outline all endpoints needed to be exposed to\nweb based tools to support all the needs Ada holders and DReps to engage with\nCIP-1694's governance design.\n\n## Specification\n\nWe define the following section as an extension to the specification described\nwithin CIP-30. Although currently CIP-30 acts as the defacto Cardano dApp-wallet\nconnector, this specification could be applied to similar standards.\n\n> **Note** This specification will evolve as the proposed ledger governance\n> model is finalized.\n\n### Data Types\n\n#### CIP-30 Inherited Data Types\n\nFrom\n[CIP-30's Data Types](https://github.com/cardano-foundation/CIPs/tree/master/CIP-003/README.md#data-types)\nwe inherit:\n\n##### [Address](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0030/README.md#address)\n\nA string representing an address in either bech32 format, or hex-encoded bytes.\nAll return types containing `Address` must return the hex-encoded bytes format,\nbut must accept either format for inputs.\n\n##### [Bytes](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0030/README.md#bytes)\n\nA hex-encoded string of the corresponding bytes.\n\n##### [cbor\\<T>](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030#cbort)\n\nA hex-encoded string representing [CBOR](https://tools.ietf.org/html/rfc7049)\ncorresponding to `T` defined via [CDDL](https://tools.ietf.org/html/rfc8610)\neither inside of the\n[Shelley Multi-asset binary spec](https://github.com/IntersectMBO/cardano-ledger-specs/blob/0738804155245062f05e2f355fadd1d16f04cd56/shelley-ma/shelley-ma-test/cddl-files/shelley-ma.cddl)\nor, if not present there, from the\n[CIP-0008 signing spec](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0008/CIP-0008.md).\nThis representation was chosen when possible as it is consistent across the\nCardano ecosystem and widely used by other tools, such as\n[cardano-serialization-lib](https://github.com/Emurgo/cardano-serialization-lib),\nwhich has support to encode every type in the binary spec as CBOR bytes.\n\n##### [DataSignature](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0030/README.md#datasignature)\n\n```ts\ntype DataSignature = {|\n  signature: cbor<COSE_Sign1>,\n  key: cbor<COSE_Key>,\n|};\n```\n\n##### [Extension](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0030/README.md#extension)\n\nAn extension is an object with a single field `\"cip\"` that describe a CIP number\nextending the API (as a plain integer, without padding). For example:\n\n```ts\n{ \"cip\": 30 }\n```\n\n#### CIP-95 Data Types\n\n##### PubDRepKey\n\n```ts\ntype PubDRepKey = string;\n```\n\nA hex-encoded string representing 32 byte Ed25519 DRep public key, as described\nin [CIP-0105 | Conway Era Key Chains for HD Wallets](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/README.md).\n\n#### DRepID\n\n```ts\ntype DRepID = string;\n```\n\nA hex-encoded string representing a registered DRep's ID which is a Blake2b-224\nhash digest of the above mentioned 32 byte Ed25519 public key, as described in\n[CIP-1694 Registered DReps](https://github.com/cardano-foundation/CIPs/blob/430f64d3e86dd67903a6bf1e611c06e5343072f3/CIP-1694/README.md#registered-dreps).\n\n##### PubStakeKey\n\n```ts\ntype PubStakeKey = string;\n```\n\nA hex-encoded string representing 32 byte Ed25519 public key used as a staking\ncredential.\n\n### Error Types\n\nFor the methods described in\n[Governance Extension API](#governance-extension-api), we inherit APIError,\nDataSignError and TxSignError from\n[CIP-30's Error Types](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030#error-types).\n\n> **Note** We choose to reword some descriptions from CIP-30, to improve\n> clarity.\n\n#### [APIError](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030#apierror)\n\nWe repurpose this error type from CIP-30, extending it's functionality. We\nextend the `Refused` error code to also include the case of the extension no\nlonger being enabled.\n\n```ts\nAPIErrorCode {\n\tInvalidRequest: -1,\n\tInternalError: -2,\n\tRefused: -3,\n\tAccountChange: -4,\n}\ntype APIError {\n\tcode: APIErrorCode,\n\tinfo: string\n}\n```\n\n- `InvalidRequest` - Inputs do not conform to this specification or are\n  otherwise invalid.\n- `InternalError` - An internal wallet error occurred during execution of this\n  API call.\n- `Refused` - The request was refused due to lack of access - e.g. wallet\n  disconnects or extension is no longer enabled.\n- `AccountChange` - The account has changed. The client application should call\n  `wallet.enable()` to reestablish connection to the new account. The wallet\n  should not ask for confirmation as the user was the one who initiated the\n  account change in the first place.\n\n#### [TxSignError](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030#txsignerror)\n\nWe repurpose this error type from CIP-30, extending it's functionality. We\nextend the `ProofGeneration` error code to also include cases where DRep secret\nkey is not available. We also add one new error code `DeprecatedCertificate`.\n\n```ts\nTxSignErrorCode = {\n  ProofGeneration: 1,\n  UserDeclined: 2,\n  DeprecatedCertificate: 3,\n};\ntype TxSignError = {\n  code: TxSignErrorCode;\n  info: String;\n};\n```\n\n- `ProofGeneration` - User has accepted the transaction sign, but the wallet was\n  unable to sign the transaction. This is because the wallet does have some of\n  the private keys required.\n- `UserDeclined` - User declined to sign the transaction.\n- `DeprecatedCertificate` - Returned regardless of user consent if the\n  transaction contains a deprecated certificate.\n\n#### [DataSignError](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030#datasignerror)\n\nWe repurpose this error type from CIP-30, extending it's functionality. We\nextend the `ProofGeneration` error code to also include cases where DRep secret\nkey is not available.\n\n```ts\nDataSignErrorCode {\n\tProofGeneration: 1,\n\tAddressNotPK: 2,\n\tUserDeclined: 3,\n}\ntype DataSignError = {\n\tcode: DataSignErrorCode,\n\tinfo: String\n}\n```\n\n- `ProofGeneration` - Wallet could not sign the data; because the wallet does\n  not have the secret key to the associated with the address or DRep ID.\n- `AddressNotPK` - Address was not a P2PK address and thus had no SK associated\n  with it.\n- `UserDeclined` - User declined to sign the data.\n\n### Governance Extension API\n\nThese are the CIP-95 methods that should be returned as part of the API object,\nnamespaced by `cip95` without any leading zeros.\n\nFor example: `api.cip95.getPubDRepKey()`\n\nTo access these functionalities a client application must present this CIP-95\nextension object, as part of the extensions object passed at enable time:\n\n```ts\ncardano.{wallet-name}.enable({ extensions: [{ cip : 95 }]})\n```\n\n#### `api.cip95.getPubDRepKey(): Promise<PubDRepKey>`\n\nThe connected wallet account provides the account's public DRep Key, derivation\nas described in [CIP-0105](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/README.md).\n\nThese are used by the client to identify the user's on-chain CIP-1694\ninteractions, i.e. if a user has registered to be a DRep.\n\n##### Returns\n\nThe wallet account's public DRep Key.\n\n##### Errors\n\n<!-- prettier-ignore-start -->\n| Error Type   | Error Code       | Return Condition                                                                          |\n| ------------ | ---------------- | ----------------------------------------------------------------------------------------- |\n| `APIError`   | `InvalidRequest` | Returned if a input parameter is passed.                                                  |\n| `APIError`   | `InternalError`  | Returned if there is a generic internal error occurred during execution of this API call. |\n| `APIError`   | `Refused`        | Returned if there is a refusal, could be wallet disconnection or extension is revoked.    |\n| `APIError`   | `AccountChange`  | Returned if wallet has changed account, meaning connection should be reestablished.       |\n<!-- prettier-ignore-stop -->\n\n#### `api.getRegisteredPubStakeKeys(): Promise<PubStakeKey[]>`\n\nThe connected wallet account's registered public stake keys. These keys may or may not control any Ada, but they must all have been registered via a stake key registration certificate. This includes keys which the wallet knows are in the process of being registered (already included in a pending stake key registration certificate).\n\nIf none of the wallets stake keys are registered then an empty array is returned.\n\nThese keys can then be used by the client to identify the user's on-chain CIP-1694\ninteractions, and also create vote delegation certificates which can be signed via `.signTx()`.\n\n##### Returns\n\nAn array of the connected user's registered public stake keys.\n\n##### Errors\n\n<!-- prettier-ignore-start -->\n| Error Type   | Error Code       | Return Condition                                                                          |\n| ------------ | ---------------- | ----------------------------------------------------------------------------------------- |\n| `APIError`   | `InvalidRequest` | Returned if a input parameter is passed.                                                  |\n| `APIError`   | `InternalError`  | Returned if there is a generic internal error occurred during execution of this API call. |\n| `APIError`   | `Refused`        | Returned if there is a refusal, could be wallet disconnection or extension is revoked.    |\n| `APIError`   | `AccountChange`  | Returned if wallet has changed account, meaning connection should be reestablished.       |\n<!-- prettier-ignore-stop -->\n\n#### `api.cip95.getUnregisteredPubStakeKeys(): Promise<PubStakeKey[]>`\n\nThe connected wallet account's unregistered public stake keys. These keys may or may not control any Ada. This includes keys which the wallet knows are in the process of becoming unregistered (already included in a pending stake key unregistration certificate).\n\nIf the wallet does not know the registration status of it's stake keys then it should return them as part of this call. If all of the wallets stake keys are registered then an empty array is returned.\n\nThese keys can then be used by the client to identify the user's on-chain CIP-1694\ninteractions, i.e if a user has delegated to a DRep.\n\n##### Returns\n\nAn array of the connected user's unregistered stake keys.\n\n##### Errors\n\n<!-- prettier-ignore-start -->\n| Error Type   | Error Code       | Return Condition                                                                          |\n| ------------ | ---------------- | ----------------------------------------------------------------------------------------- |\n| `APIError`   | `InvalidRequest` | Returned if a input parameter is passed.                                                  |\n| `APIError`   | `InternalError`  | Returned if there is a generic internal error occurred during execution of this API call. |\n| `APIError`   | `Refused`        | Returned if there is a refusal, could be wallet disconnection or extension is revoked.    |\n| `APIError`   | `AccountChange`  | Returned if wallet has changed account, meaning connection should be reestablished.       |\n<!-- prettier-ignore-stop -->\n\n#### `api.signTx(tx: cbor<transaction>, partialSign: bool = false): Promise<cbor<transaction_witness_set>>`\n\nThis endpoint requests the wallet to inspect and provide appropriate witnesses\nfor a supplied transaction. The wallet should articulate this request from\nclient application in a explicit and highly informative way.\n\nHere we extend the capabilities of\n[CIP-30's `.signTx()`](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0030/README.md#apisigntxtx-cbortransaction-partialsign-bool--false-promisecbortransaction_witness_set).\nTo allow signatures with `drep_credential` and recognition of Conway ledger\nera transaction fields and certificates.\n\n##### Expected Inspection Support\n\nAs read from\n[cardano-ledger Conway _draft_ specification](https://github.com/IntersectMBO/cardano-ledger/blob/dcacf044c8d38362edc57a761e027953aab3f335/eras/conway/impl/cddl-files/conway.cddl).\n\nSupporting wallets should be able to recognize and inspect\nall the following certificates and data contained in transaction bodies, in any\ncombination.\n\n| Index | Supported Pre-Conway Certificates |\n| ----- | --------------------------------- |\n|   0   | `stake_registration`              |\n|   1   | `stake_deregistration`            |\n|   2   | `stake_delegation`                |\n|   3   | `pool_registration`               |\n|   4   | `pool_retirement`                 |\n\n| Index | Supported Conway Certificates   |\n| ----- | ------------------------------- |\n|   5   | `reg_cert`                      |\n|   6   | `unreg_cert`                    |\n|   7   | `vote_deleg_cert`               |\n|   8   | `stake_vote_deleg_cert`         |\n|   9   | `stake_reg_deleg_cert`          |\n|  10   | `vote_reg_deleg_cert`           |\n|  11   | `stake_vote_reg_deleg_cert`     |\n|  12   | `auth_committee_hot_cert`       |\n|  13   | `resign_committee_cold_cert`    |\n|  14   | `reg_drep_cert`                 |\n|  15   | `unreg_drep_cert`               |\n|  16   | `update_drep_cert`              |\n\n| Transaction Index | Supported Conway Transaction Field Data |\n| ----------------- | --------------------------------------- |\n|        19         | `voting_procedure`                      |\n|        20         | `proposal_procedure`                    |\n|        21         | `coin`         (current treasury value) |\n|        22         | `positive_coin`          (new donation) |\n\nAll other potential transaction field inclusions\n[0-18](https://github.com/IntersectMBO/cardano-ledger/blob/master/eras/conway/test-suite/cddl-files/conway.cddl#L54-#L69),\nshould be able to be recognized by supporting wallets.\n\n##### Unsupported Inspection\n\nIn the Conway ledger era two certificate types are deprecated `genesis_key_delegation` and `move_instantaneous_rewards_cert`.\nIf the wallet receives a transaction containing a deprecated certificate it should return a `TxSignError` with an error code of `DeprecatedCertificate`.\n\n| Index | Unsupported Pre-Conway Certificates |\n| ----- | ----------------------------------- |\n|   5   | `genesis_key_delegation`            |\n|   6   | `move_instantaneous_rewards_cert`   |\n\n##### Expected Witness Support\n\nAlthough constitutional committee certificates and stake pool certificates should be able to be recognized they should not be able to be correctly witnessed by wallets following this API.\nWallet's should only support witnesses using payment, stake and DRep keys.\n\n##### Returns\n\nThe portions of the witness set that were signed as a result of this call are\nreturned. This encourages client apps to verify the contents returned by this\nendpoint before building the final transaction.\n\n##### Errors\n\n<!-- prettier-ignore-start -->\n| Error Type    | Error Code               | `partialSign`     | Return Condition                                                                                                                  |\n| ------------- | ------------------------ | ----------------- | --------------------------------------------------------------------------------------------------------------------------------- |\n| `APIError`    | `InvalidRequest`         | `true` or `false` | Returned if an erroneous parameter is passed, wrong type or too many etc.                                                         |\n| `APIError`    | `InternalError`          | `true` or `false` | Returned if there is a generic internal error occurred during execution of this API call.                                         |\n| `APIError`    | `Refused`                | `true` or `false` | Returned if there is a refusal, could be wallet disconnection or the extension is revoked.                                        |\n| `APIError`    | `AccountChange`          | `true` or `false` | Returned if wallet has changed account, meaning connection should be reestablished.                                               |\n| `TxSignError` | `ProofGeneration`        | `false`           | Returned if user has accepted transaction to sign, but the wallet is unable to sign because it does not have the required key(s). |\n| `TxSignError` | `UserDeclined`           | `true` or `false` | Returned if user has declined to sign the transaction.                                                                            |\n| `TxSignError` | `DeprecatedCertificate` | `true` or `false` | Returned regardless of user consent if the transaction contains a deprecated certificate.                                        |\n<!-- prettier-ignore-stop -->\n\nIf `partialSign` is `true`, the wallet only tries to sign what it can. If\n`partialSign` is `false` and the wallet could not sign the entire transaction,\n`TxSignError` shall be returned with the `ProofGeneration` code.\n\n#### `api.cip95.signData(addr: Address | DRepID, payload: Bytes): Promise<DataSignature>`\n\nErrors: `APIError`, `DataSignError`\n\nThis endpoint requests the wallet to inspect and provide a DataSignature for the supplied data. The wallet should articulate this request from client application\nin a explicit and highly informative way.\n\nHere we extend the capabilities of\n[CIP-30's `.signData()`](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0030/README.md#apisigndataaddr-address-payload-bytes-promisedatasignaturet).\nTo allow for signatures using DRep keys. \n\nThis endpoint utilizes the\n[CIP-0008 | Message Signing](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0008/README.md)\nfor standardization/safety reasons. It allows the client app to request the user to\nsign a payload conforming to said spec.\n\n##### Supported Credentials\n\nHere we define how each key is identified by an `Address` in relation to\n[CIP-0019 | Cardano Addresses](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0019/README.md),\nthese are all Shelley key-hash-based addresses.\n\nWe allow for `DRepID` to be passed in the `addr` field to signal signature using the associated DRep key.\n\nTo construct an address for DRep Key, the client application should construct a\n[type 6 address](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0019/CIP-0019-cardano-addresses.abnf#L7C8-L7C93).\nUsing an appropriate\n[Network Tag](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0019/CIP-0019-cardano-addresses.abnf#L13)\nand a hash of a public DRep Key.\n\n<!-- prettier-ignore-start -->\n| Key         | Identifying `addr` |\n| ----------- | ------------------ |\n| Payment Key | Address types: [0](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0019/CIP-0019-cardano-addresses.abnf#L1), [2](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0019/CIP-0019-cardano-addresses.abnf#L3), [4](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0019/CIP-0019-cardano-addresses.abnf#L5), [6](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0019/CIP-0019-cardano-addresses.abnf#L7C27-L7C72). |\n| Stake Key   | Address type: [14](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0019/CIP-0019-cardano-addresses.abnf#L10). |\n| DRep Key | [`DRepID`](#drepid) |\n<!-- prettier-ignore-end -->\n\nThese keys will be used to sign the `COSE_Sign1`'s `Sig_structure` with the\nfollowing headers set:\n\n- `alg` (1) - must be set to `EdDSA` (-8)\n- `kid` (4) - Optional, if present must be set to the same value as in the\n  `COSE_key` specified below. It is recommended to be set to the same value as\n  in the `\"address\"` header.\n- `\"address\"` - must be set to the raw binary bytes of the address as per the\n  binary spec, without the CBOR binary wrapper tag\n\nThe payload is not hashed and no `external_aad` is used.\n\n##### Returns\n\nThe return shall be a `DataSignature` with `signature` set to the hex-encoded\nCBOR bytes of the `COSE_Sign1` object specified above and `key` shall be the\nhex-encoded CBOR bytes of a `COSE_Key` structure with the following headers set:\n\n- `kty` (1) - must be set to `OKP` (1).\n- `kid` (2) - Optional, if present must be set to the same value as in the\n  `COSE_Sign1` specified above.\n- `alg` (3) - must be set to `EdDSA` (-8).\n- `crv` (-1) - must be set to `Ed25519` (6).\n- `x` (-2) - must be set to the public key bytes of the key used to sign the\n  `Sig_structure`.\n\n##### Errors\n\n<!-- prettier-ignore-start -->\n\n| Error Type      | Error Code        | Return Condition                                                                                                               |\n| --------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------ |\n| `APIError`      | `InvalidRequest`  | Returned if a input parameter is passed.                                                                                       |\n| `APIError`      | `InternalError`   | Returned if there is a generic internal error occurred during execution of this API call.                                      |\n| `APIError`      | `Refused`         | Returned if there is a refusal, could be wallet disconnection or extension is revoked.                                         |\n| `APIError`      | `AccountChange`   | Returned if wallet has changed account, meaning connection should be reestablished.                                            |\n| `DataSignError` | `ProofGeneration` | Returned if user has accepted to sign, but wallet could not sign the data; because the wallet does not have the required keys. |\n| `DataSignError` | `AddressNotPK`    | Returned if Address was not a P2PK address and thus had no SK associated with it.                                              |\n| `DataSignError` | `UserDeclined`    | Returned if the user declined to sign the data.                                                                                |\n\n<!-- prettier-ignore-stop -->\n\n### Versioning\n\nWhilst this CIP is in it's unmerged proposed state, it remains very fluid and\nsubstantial changes can happen, so we would advise against any implementation.\nOnce more feedback is received, maturing this design, implementations can safely\nemerge, alongside this proposal's merger into the CIPs repository. Once merged\nonly small necessary changes should be made, ideally in backwards compatible\nfashion.\n\nThis, in tandem with, maturing implementations should move this proposal to an\nactive state where only small backwards compatible changes can be made. If any\nlarge changes are needed once active then a new proposal should be made to\nreplace this one. This we believe aligns with the (new) extendibility design of\nCIP-0030.\n\n### Examples of Flows\n\n#### Connection and Login\n\nThis describes a potential flow of connection between CIP-95 compatible client\napplication and wallet, then a subsequent _login_.\n\n1. **Connection:** User indicates to the client their intent to connect, causing\n   client offer a list of supported wallets, user selects their desired wallet.\n   The client will then invoke\n   `.{wallet-name}.enable({extensions: [{ \"cip\": 95 }]})` from the shared\n   `cardano` namespace, ensuring to pass in the CIP-95 extension object.\n2. **Wallet Confirmation:** The wallet indicates through its UI the clients\n   intent to connect, the user should then grant permission.\n3. **Share Credentials:** The client invokes both `.getRegisteredPubStakeKeys()`\n   and `.getPubDRepKey()`, causing the connected wallet to share relevant\n   credentials.\n4. **Chain Lookup:** The client uses a chain indexer to work out the governance\n   state of the provided credentials. The results of the lookup are then shown\n   to the user, acting as a `login`.\n\n#### Vote Delegation\n\nAssume a _DRep Aggregator and Delegation_ specialized client app, that\naggregates DRep metadata from DRep registration certificates and renders this\nmetadata to show prospective delegators. Assume that connection to a users\nwallet has already been made via\n`cardano.{wallet-name}.enable({extensions: [{ cip: 95 }]})`.\n\n1. **Choose DRep:** User browses DReps and selects one which align's with their\n   values to delegate too. It is up to the client application to choose and\n   manage which stake key should be used for this delegation, this could be with\n   or without user input.\n2. **Construct Delegation:** The client application uses CIP-30 endpoints to\n   query the wallet's UTxO set and payment address. A DRep delegation\n   certificate\n   ([`vote_deleg_cert`](https://github.com/IntersectMBO/cardano-ledger/blob/1beddd3d9f10d8fcb163b5e83985c4bac6b74be7/eras/conway/test-suite/cddl-files/conway.cddl#L303))\n   is constructed by the app using the chosen DRep's ID and wallet's stake\n   credential. A transaction is constructed to send 1 ADA to the wallet's\n   payment address with the certificate included in the transaction body.\n3. **Inspect and Sign:** The app passes the transaction to the wallet via\n   `.signTx()`. The wallet inspects the content of the transaction, informing\n   the user of the client app's intension. If the user confirms that they are\n   willing to sign, the wallet returns the appropriate witnesses, of payment key\n   and stake key.\n4. **Submit:** The app will add the provided witnesses into the transaction body\n   and then pass the witnessed transaction back to the wallet for submission via\n   `.submitTx()`.\n5. **Feedback to user:** The wallet returns the submitted transaction's hash,\n   the app can use this to track the status of the transaction on-chain and\n   provide feedback to the user.\n\n#### DRep Registration\n\nAssume a _DRep Registration_ specialized client app, that allows people to\nregister as a DRep. Assume that connection to a users wallet has already been\nmade via `cardano.{wallet-name}.enable({extensions: [{ cip: 95 }]})` and that\nthe user is not a registered DRep.\n\n1. **User Indicates Intent:** User indicates to the client that they wish to\n   register as a DRep. The client asks the user to provide metadata anchor, this\n   is bundled with DRepID the client generates from the wallet's public DRep Key\n   provided via `.getPubDRepKey()`.\n2. **Construct Registration**: The client application uses CIP-30 endpoints to\n   query the wallet's UTxO set and payment address. A DRep registration\n   certificate\n   ([`reg_drep_cert`](https://github.com/IntersectMBO/cardano-ledger/blob/1beddd3d9f10d8fcb163b5e83985c4bac6b74be7/eras/conway/test-suite/cddl-files/conway.cddl#L312))\n   is constructed by the app using the wallet's DRep ID and the provided\n   metadata anchor. A transaction is constructed to send 1 ADA to the wallet's\n   payment address with the certificate included in the transaction body.\n3. **Inspect and sign:** The app passes the transaction to the wallet via\n   `.signTx()`. The wallet inspects the content of the transaction, informing\n   the user of the client app's intension. If the user confirms that they are\n   happy to sign, the wallet returns the appropriate witnesses, of payment key\n   and DRep key (`drep_credential`).\n4. **Submit:** The app will add the provided witnesses into the transaction body\n   and then pass the witnessed transaction back to the wallet for submission via\n   `.submitTx()`.\n5. **Feedback to user:** The wallet returns the submitted transaction's hash,\n   the app can use this to track the status of the transaction on-chain and\n   provide feedback to the user.\n\n## Rationale: how does this CIP achieve its goals?\n\nThe principle aim for this design is to reduce the complexity for wallet\nimplementors whilst maintaining backwards compatibility with CIP-30\nimplementations. This is motivated by the necessity for users to be able to\ninteract with the age of Voltaire promptly, by keeping the wallet's providers\nask small we aim to reduce implementation time.\n\nThis design aims to make the tracking of a user's governance state an optional\nendeavour for wallet providers. This is achieved by placing the responsibility\non clients to track a user's governance state, i.e. if a wallet user is a DRep,\nwhat DRep a wallet user has delegated to, etc.\n\nDespite only defining the minimal set of endpoints required, we do not wish to\ndiscourage the creation of subsequent CIPs with a wider range of governance\nfunctionality. Nor does this specification aim to discourage wallet providers\nfrom fully integrating governance features, side-stepping the necessity for this\nAPI (matching how staking is achieved).\n\n### Why Web-based Stacks?\n\nWeb-based stacks, with wallet connectivity, are a familiar place for users to be\nable to interact with Cardano. These tools lower the technical bar to engage\nwith the ecosystem. Thus we believe encouraging further adoption of this\napproach is beneficial.\n\nThe primary alternative approach is for wallet providers to integrate this\nfunctionality fully inside of wallet software, matching how staking is often\nimplemented. We deem this approach as preferable from a security standpoint, we\nwould encourage wallet providers to pursue this. But we understand that this\nadds significant overhead to wallet designs, so we offer this API as an\nalternative.\n\n### Why DReps and Ada Holders?\n\nThis proposal only caters to two types of governance actor described in\nCIP-1694; Ada holders and DReps, this decision was three fold. Primarily, this\nis to allow these groups to utilize a web-based client to participate in\nCardano's governance. These groups are likely less comfortable utilizing\ncommand-line interfaces than other groups, thus making alternatives from them is\na priority. Secondly, the other types of actor (constitutional committee members\nand SPOs) are identified by different credentials than Ada holders and DReps,\nmaking their integration in this specification more complex. These alternative\ncredentials are unlikely to be stored within standard wallet software which may\ninterface with this API. Thirdly, Ada holders and DReps likely represent the\nmajority of participants thus we aim to cast a wide net with this specification.\n\n#### Unsupported Items\n\nIn this specification we have placed explicit boundaries on what should not be\nsupported with `.signTx()`. Those being not witnessing\n[stake pool](https://github.com/IntersectMBO/cardano-ledger/blob/1beddd3d9f10d8fcb163b5e83985c4bac6b74be7/eras/conway/test-suite/cddl-files/conway.cddl#L294C1-L295C43)\nor\n[constitutional committee](https://github.com/IntersectMBO/cardano-ledger/blob/1beddd3d9f10d8fcb163b5e83985c4bac6b74be7/eras/conway/test-suite/cddl-files/conway.cddl#L310C1-L311C61),\ncertificates and not inspecting genesis key delegation or MIR certificates.\n\nFrom speaking to CIP-30 implementors it seems reasonable that there does not\nexist implementations or motivation to support witnessing stake pool\ncertificates via wallet web bridges. This is because stake pool operators much\nprefer the utility and security advantages not operating via light wallets. Due\nto the [Lack of Specificity](#lack-of-specificity) of CIP-30 we felt it\nnecessary to explicitly state the lack of support in this extension.\n\n[Constitutional committee certificates](https://github.com/IntersectMBO/cardano-ledger/blob/1beddd3d9f10d8fcb163b5e83985c4bac6b74be7/eras/conway/test-suite/cddl-files/conway.cddl#L310C1-L311C61)\nare not supported by this specification's `.signTx()` for two reasons. First,\nthis specification is only focussed on the need's of Ada holders and DReps.\nSecondly, the credentials used by the constitutional committee, are a hot and\ncold key setup. Hot and cold keys are not suited for standard light wallets.\n\nGenesis key delegation and move instantaneous reward certificates (see in\n[Shelley spec](https://github.com/IntersectMBO/cardano-ledger/blob/0738804155245062f05e2f355fadd1d16f04cd56/shelley-ma/shelley-ma-test/cddl-files/shelley-ma.cddl#L117#L118))\nare not supported here because they have been deprecated in the Conway ledger\nera. Furthermore, due to the lack of accessibility (require access to genesis\nkeys) for these certificates it is extremely unlikely any CIP-30 implementations\nsupported these.\n\n### The Role of the Wallet\n\nThe endpoints specified here aim to maintain the role of the wallet as: sharing\npublic keys, transaction inspecting, transaction signing and transaction\nsubmission.\n\n#### Transaction Inspection\n\nIn a previous design we had stipulated the precise information that must be\nshown to user by wallets at signature time. This was discussed during the\nwallets and tooling hackathon and consensus was reached that is not the place of\nthese APIs to prescribe such details to wallets. Rather this specification\nshould be describing the interface between web-based stacks and wallets and not\ntelling wallets what UI elements should be used. It is in a wallet's best\ninterest to always adequately inform the user, with varying levels of detail\nbased on the wallet's discretion.\n\n#### Transaction Construction\n\nBy not placing the burden of transaction construction onto the wallet, we move\nthe application specific complexity from wallet implementations and onto\napplications. This has a number of benefits, primarily this should lower the bar\nfor wallet adoption. But this also helps in the creation of iterative updates,\nall wallet implementers do not need to update if the format of these\ntransactions is adjusted during development.\n\nHere we also benefit from imitating the existing flows which have been utilized\nby CIP-30 compliant systems. Reusing existing flows is beneficial for developer\nadoption as it enables straight forward code reuse.\n\nOne argument against this design is that, if wallets are required to be able to\ninspect and thus understand these application specific transactions then they\nmay as well build the transaction. Ultimately, we have taken the design decision\nto leave transaction construction to the applications.\n\n### CIP-30 Reuse\n\nWhilst CIP-30 facilitated the launch of dApp client development on Cardano, it's\nfunctionality is limited in scope. Although it does offer generic functions,\nthese cannot satisfy the problem that this proposal tackles in a backwards\ncompatible manner. Thus extending it's functionality is a necessity.\n\n#### Lack of Specificity\n\nThe CIP-30 specification has required amendments to add clarification to it's\nambiguity. There is further ambiguity around what is and is not supported via\n`.signTx()`. The specification does not explicitly list the transaction\nartifacts wallets has to be able to inspect and witness. Whilst for most use\ncases this is likely fine and has served the community well. We forsee issues\naround large ledger upgrades which introduce new types of transaction fields and\ncertificate. Without explicit mention of what is and is not supported deltas\nbetween expected and actual functionality become common and hazardous. This is\nwhy we choose to explicitly list those items that wallet have to support when\ncomplying with this API.\n\n#### Extension Design\n\nWith this specification we chose to extend CIP-30's functionalities. There would\nbe two competing designs to this approach. One; move to have this specification\nincluded within CIP-30. Two; deploy this specification as it's own standalone\nweb-bridge.\n\nIt would be undesirable to include this functionality within the base CIP-30 API\nbecause it would force all wallets supporting CIP-30 to support this API. This\nis undesirable because not all client apps or wallets will have the need or\ndesire to support this specification.\n\nThe reason we chose to not deploy this specification on its own is because it is\nunlikely that clients implementing this API will not want to also use the\nfunctionality offered by CIP-30. Additionally, CIP-30 offers a extensibility\nmechanism meaning that the initial handshake connection is defined and thus wont\nbe needed to be defined within this specification.\n\nFurthermore, another benefit of utilizing the CIP-30 extensibility mechanism is\nthe potential for siloing of wallet capabilities between client apps. By having\nto request access to each extension wallets and users are able to silo which\nextensions they allow to each client application. An example of this could be\nonly allowing the CIP-95 API with governance related applications and not\ndecentralized extensions.\n\n#### Backwards Compatibility\n\nThe primary issue with just using CIP-30 to inspect, sign and submit Conway\ntransactions/certificates is that wallet implementations are likely\nincompatible. This is because such certificates/transactions were not part of\nthe ledger design at time of original CIP-30 implementation. Furthermore, CIP-30\nwas written and implemented before voting credentials were defined and thus it\nwould be impossible to provide signatures with this credential to votes, DRep\nregistrations and DRep retirements.\n\nAlthough it is likely that some of the capabilities of this API can be achieved\nby existing CIP-30 implementations it is not certain how much. We would like to\navoid the potential mismatching of capabilities between CIP-30 implementations,\nas this creates unpredictable wallet behavior for client applications. Such\nbehavior was a primary motivator to introduce such an extendability mechanism to\nCIP-30.\n\n#### Namespacing\n\nIn this specification we have chosen to explicitly namespace all endpoint except\n`.signTx()` where we omit the namespacing. By not namespacing `.signTx()` we\nintend to offer client apps an override of the CIP-30 `.signTx()`. We chose to\ndo this because this `.signTx()` extends the CIP-30 functionality in a backwards\ncompatible way. All other endpoints are namespaced to avoid possible collisions\nwith other future extensions.\n\n#### Inheriting Endpoints\n\nIn this design we chose to extend the capabilities of CIP-30's `.signTx()` and\n`.signData()` rather than introducing new endpoints for signing and submission.\nThis was a result of community discussion at the wallets and tooling hackathon,\nleading to a more straight forward design. Originally we had individual\nendpoints for sign and submitting of DRep registration, DRep retirement, votes,\ngovernance actions and vote delegations.\n\nWhilst individual endpoints seem like a simpler solution they would likely\nintroduce more complexities for wallet implementors. As constraining what\ntransactions an endpoint would require additional validation complexities and\nerror handling from wallets. For example; what should a wallet do if it is\npassed a DRep registration certificate via `.signTx()`? should it witness or\nreject and only witness with a dedicated DRep registration endpoint?\n\nFurthermore individual restrictive endpoints limit how much can be done in a\nsingle transaction. These methods would not allow multiple certificates to be\nsupplied at once. Thus client apps would be limited to a single governance\nartifact per transaction. This is limiting as it means users have to submit\nmultiple transactions to achieve what is possible in one.\n\n#### CIP-95 as a Conway Flag\n\nBy providing _updated_ CIP-30 endpoints we essentially use the CIP-95 extension\nobject as a flag to signal to apps at connection time a wallet's compatibility\nwith Conway leger era. This goes against how past ledger feature upgrades have\nrolled out. Rather in the past, existing CIP-30 implementors have just updated\ntheir implementations, we believe this to be an error prone approach. This\nundoubted introduces deltas between what a client application expects a wallet\nto be able to do and what it can do. There is no way for a client application to\nknow what a wallet is capable of.\n\nDespite this we do not discourage CIP-30 implementors from updating their\nimplementations to support Conway artifacts to `.signData()` and `.signTx()`.\nBut if so they must support the CIP-95 object flag at connection time, so that\nclients are aware of this functionality.\n\n### Multi-stake Key Support\n\nAlthough\n[multi-stake key wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0018)\nare not widely adopted across Cardano, we make an effort to support them here.\nThis is because a single stake key can delegate to a single DRep. By allowing\nusers to spread stake across multiple stake keys it allows different weighted\ndelegation to different DReps, this could be a very desirable feature.\n\n### Types of credential\n\nThis specification does not cater for wallets who manage non-key-based stake\ncredentials and those who wish to handle non-key-based DRep credentials. This\ndoes limit the usefulness of this specification. But the complexities that would\nbe introduced by generalization this specification to these credentials is\nunlikely to yield much benefit since these types of wallet are not prevalent in\nCardano.\n\nAlthough this means that we are likely excluding tooling for DAOs from being\nsupported through this standard. The argument could be made that such entities\ngenerally prefer to use more advanced wallet tooling rather than relying on\ninteraction with web-based stacks, thus it is not even certain DAOs would want\nto use such a standard.\n\n#### Encoding\n\nUnlike the CIP-30 specification we have made an decision, where possible to\nrepresent keys as raw hex rather than encoded representations. We believe that\nit is not the role of the wallet to encode such credentials, encoding needs\nshould be at the application's discretion. Introducing different encodings into\nthis API would add unneeded complexity.\n\nFurthermore, in this API we chose to return public keys over key-hashes or\naddresses. Again we believe wallets should just serve public key information and\nit is up to the application to encode and derive addresses as needed. This\nsimplifies the overall design and makes implementations easier for wallets.\n\n### Splitting of Stake Key endpoint\n\nFor stake keys we have chosen to implement two endpoints where wallets can share\nregistered and unregistered stake keys. Originally we had a single endpoint\nwhich only allowed sharing of registered stake keys. This was problematic for\nwallets which had no registered stake keys, and thus the second endpoint was\nintroduced.\n\nWe chose to keep a single endpoint for DRep keys, although it would have been\npossible to introduce a second to allow for wallets to activity of their DRep\nkeys. This was just for the simplicity of the API. Furthermore, due to the\ndesign of this proposal it is unlikely that wallets will implement methods to\ntrack a user's DRep state.\n\n### Backwards Compatibility\n\nThis proposal should not effect the backwards compatibility of either clients or\nwallet implementors.\n\n#### CIP-62?\n\n[CIP-62? | Cardano dApp-Wallet Web Bridge Catalyst Extension](https://github.com/cardano-foundation/CIPs/pull/296)\nis another extension to the CIP-30 API, this proposal is independent of CIP-95.\nThe CIP-95 specification does not rely on any of the implementation defined in\nCIP-62?. We have attempted to avoid any collisions of naming between these\nproposals, this was motivated by a desire to make wallet implementations more\nstraight forward for wallets implementing both APIs.\n\n### Open Questions\n\n- <s>The burden of transaction building to be placed on dApps or wallets?</s>\n  - As we are replacing CIP-30's signTx it makes sense to follow the same flow\n    and place the burden on the client applications.\n- <s>Does supporting governance action submission a necessary burden for the\n  scope of this proposal?</s>\n  - Since moving burden of transaction construction from wallet to app, this\n    becomes much less of an issue as the complex error checking should now be\n    done by the application.\n- <s>should provide support for combination certificates?</s>\n  - Yes we will support ALL conway ledger era Tx/Certs, this will allow for\n    CIP95 to be \"the Conway compatible\" wallet web bridge.\n- <s>Is it necessary to provide a method to prove ownership of DRep key?</s>\n  - Yes, this will be a useful add.\n- <s>Is it sensible to place multi-stake key burden onto clients?</s>\n  - Yes, seems like a reasonable approach. If wallets want to manage it, they\n    can only provide the keys they wish.\n- <s>Do we need to share stake keys or can we just reuse reward addresses?</s>\n  - Reusing CIP30's `.getRewardAddresses()` may act as an alternative, but it is\n    unclear how implementors have supported this function and thus its reuse\n    maybe a mistake.\n  - It is a more reasonable approach to share public key material instead of\n    addresses as it gives the client application more freedom.\n- <s>Should this proposal cater for non-key-based stake credential?</s>\n  - We can leave this for a future iteration.\n- <s>Move DRep key definitions be moved into another CIP?</s>\n  - Yes, this is a cleaner approach, as we keep the purity of this proposal to\n    being a wallet web bridge.\n- <s>Should there be a way for the optional sharing of governance state, from\n  wallet to client?</s>\n  - We leave this for future CIPs.\n- <s>Should DRep key be moved into CIP-1852?</s>\n  - Yes it will be moved to it's own CIP with reference added to\n    CIP-1852.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] The interface is supported by three wallet providers.\n  - [Nufi](https://assets.nu.fi/extension/sanchonet/nufi-cwe-sanchonet-latest.zip)\n  - [Lace](https://github.com/input-output-hk/lace)\n  - [Yoroi](https://github.com/Emurgo/yoroi)\n  - [demos wallet](https://github.com/Ryun1/cip95-demos-wallet)\n- [x] The interface is used by one web application to allow users to engage with\n      the Conway ledger design.\n  - [SanchoNet GovTool](https://sanchogov.tools)\n  - [GovTool](https://gov.tools)\n  - [cip95-cardano-wallet-connector](https://github.com/Ryun1/cip95-cardano-wallet-connector/tree/master)\n  - [drep-campaign-platform](https://github.com/IntersectMBO/drep-campaign-platform)\n- [x] The interface is supported via libraries.\n  - [Cardano JS-SDK](https://github.com/input-output-hk/cardano-js-sdk)\n  - [purescript-cip95](https://github.com/mlabs-haskell/purescript-cip95)\n  - [Mesh SDK](https://github.com/MeshJS/mesh)\n\n### Implementation Plan\n\n- [x] Provide a public Discord channel for open discussion of this\n      specification.\n  - See\n    [`wallets-sanchonet`](https://discord.com/channels/826816523368005654/1143258005354328156/1143272934966837309)\n    channel in the [IOG Technical Discord](https://discord.gg/inputoutput) under\n    (to view you have to opt-in to the Sanchonet group in the start-here\n    channel).\n- [x] Author to engage with wallet providers for feedback.\n- [x] Author to run a hackathon workshop with wallet providers.\n  - In person and online hackathon run 2023.07.13, outcomes presented here:\n    [CIP-95 pull request comment](https://github.com/cardano-foundation/CIPs/pull/509#issuecomment-1636103821).\n- [x] Resolve all [Open Questions](#open-questions).\n- [x] Author to provide test dApp to test against.\n  - See\n    [cip95-cardano-wallet-connector](https://github.com/Ryun1/cip95-cardano-wallet-connector/tree/master).\n- [x] Author to provide a reference wallet implementation.\n  - See [cip95-demos-wallet](https://github.com/Ryun1/cip95-demos-wallet/).\n- [ ] Author to produce a set of test vectors for wallets to test against.\n- [x] Author to move DRep key definitions to a separate CIP.\n  - via the addition of [CIP-105 | Conway era Key Chains for HD Wallets](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/README.md) via [CIPs PR #597](https://github.com/cardano-foundation/CIPs/pull/597). \n\n## Acknowledgments\n\n<details>\n  <summary><strong>Wallets and Tooling Hackathon</strong></summary>\n\n  On 2023.07.13 a online and in person community hackathon took place, aims of\n  this event included maturation of the design of this specification.\n\n  We would like to thank the following attendees for providing their valuable\n  insights:\n\n  - Piotr Czeglik - Lace\n  - Mircea Hasegan - Lace\n  - Alex Apeldoorn - Lace\n  - Michal Szorad - Yoroi\n  - Javier Bueno - Yoroi\n  - Ed Eykholt - Blocktrust\n  - Vladimir Volek - Five Binaries\n  - Marek Mahut - Five Binaries\n  - Markus Gufler - Cardano Foundation\n  - Michal Ciborowski - BinarApps\n\n</details>\n\n## Copyright\n\nThis CIP is licensed under\n[CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0099/README.md",
    "content": "---\nCIP: 99\nTitle: Proof of Onboarding\nStatus: Active\nCategory: Wallets\nAuthors:\n- Adam Dean <adam@crypto2099.io>\n- Carl <vegas@hosky.io>\n- Alex Dochioiu <alex@dochioiu.com>\nImplementors:\n- VESPR Wallet <https://www.vespr.xyz/>\n- Yoroi Wallet <https://yoroi-wallet.com/>\nDiscussions:\n- https://github.com/cardano-foundation/CIPs/pull/546\nCreated: 2023-06-20\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nSince at least 2021 when Cardano entered the Mary Era and implemented Native Assets, projects and creators building on\nthe network have sought a means to distribute their tokens efficiently to users. Of particular frustration has been the\nability to onboard new users at real-world events. Solutions for this historically have been to create and preload\n\"paper wallets\" where a seed phrase and accompanying password is generated by the project, pre-populated with tokens and\nADA, and then delivered over to attendees of said event.\n\nThe creation of this addendum to the [CIP-13 Cardano URI scheme](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/README.md) seeks to minimize this friction and take advantage of\nexisting technology to enable a new era of user onboarding, particularly at real world events through the use of a\ndefined URI scheme enabling instant and frictionless communication between a project's \"token fountain\" and the user's\nwallet to reward, incentivize, and onboard new users easier than ever.\n\nThis CIP defines an extension to the CIP-13 URI Scheme as well as an API specification to facilitate and streamline\ncommunications between wallets and project servers.\n\n## Motivation: Why is this CIP necessary?\n\nBy leveraging the power of Cardano-specific URIs (CIP-13) and the modern technological advances of mobile devices and\nwallets we can provide a framework for Cardano projects to attend real world events, incentivize or reward attendees via\ntheir Native Assets, and have facts and figures to help support and analyze the impact that their attendance had (Proof\nof Onboarding).\n\n## Specification\n\n### CIP-13 Cardano URI Extensions\n\nDistributing Native Assets (and/or ADA) to attendees of IRL events has historically been a pain point in the ecosystem.\nSome implemented solutions have included: Pre-generating wallet seed phrases and pre-populating these wallets with a\nminimum amount of ADA as well as the desired Native Assets, (re)creating token fountain/faucet designs which can be\ncumbersome and not user-friendly to instruct individuals to install a wallet, visit a website, enter a code and claim\ntokens.\n\nThe Cardano Token Claim URI schema is proposed to allow wallets (particularly mobile wallets) to implement a QR-friendly\nURI structure allowing for easy onboarding and distribution of Native Assets and/or ADA to individuals in a variety of\nsituations but not least of which being at IRL events specifically tailored and geared to onboarding new users to the\necosystem.\n\nExamples:\n```html\n<!-- Token Claim URIs -->\n<a href=\"web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.hosky.io&code=consensus2023\">Claim $HOSKY</a>\n<a href=\"web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.hosky.io%2Fconsensus23&code=ABC123\">Claim $HOSKY</a>\n<a href=\"web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=ABC123&invoice=123456\">Claim NFTxLV Commermorative NFT!</a>\n```\n\n#### ABNF Grammar\n\n* For a token claim URI (authority = `claim`), a versioning path, a `faucet_url` and a required `code`.\n* Additional query parameters may be provided and should be passed through to the provided `faucet_url` without modification.\n\n``` \ncardanourn = \"web+cardano:\" claimtokenref\n\nclaimtokenref = \"//claim\" claimversion claimquery\nclaimversion = \"/v1\"\nclaimquery = ( \"?\" claimurl) ( \"&\" claimcode)\nclaimurl = \"faucet_url=\" text\nclaimcode = \"code=\" text\n```\n\n#### Token Claim URI Queries\n\n**All arguments for Token Claim URIs should be URL-encoded**\n\n***Version 1 URIs***\n\nVersion 1 URIs must include a `faucet_url` and a `code` as required parameters. \n\nURIs may include additional arguments to suit the needs of the project's faucet API.\n\n#### Handling Token Claim URI Queries\n\nThe token claim URI should consist of a required versioning `path` (i.e. `/v1`) as well as one or more required\nor optional URL-encoded arguments.\n\nAll Token Claim URIs must include a URL-encoded `faucet_url` argument as well as a `code` argument.\n\nThe wallet provider should send a POST request to the provided `Faucet URL` that includes:\n* The change/receipt wallet address of the user\n* Any additional arguments specified in the URI as key: value pairs\n\n**Example:**\n\n```\nURI: web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.hosky.io%2Fconsensus23&code=ABC123\nVersion: 1\nURL: https://claim.hosky.io/consensus23\nCODE: ABC123\nJSON POST Data:\n```\n```json\n{\n  \"address\": \"addr1abc...xyz\",\n  \"code\": \"ABC123\"\n}\n```\n\n##### Note on the `address` field\n\nThe wallet should always send the recipient address in bech32 format. If a particular token faucet implementation wishes\nto restrict or limit access to their faucet based on staking key or individual wallet address, this should be handled at\nthe server end.\n\n**Supported Addresses**\n\n* Shelley-era `enterprise` address consisting of only a payment key\n* Shelley-era `staking` address consisting of a payment and staking key\n\n##### Note on the `code` field\n\nThe code is required. Specifying a `code` allows for reliable tracking and/or limiting of claims to the faucet host. \nCodes can be used to identify attendees of particular events (i.e. CODE = `consensus2023`) or can be a unique, one-time\ncode per user (i.e. CODE = `abc123xyz987`). In this way we leave the code to be flexible to match a variety of\nanalytical use cases depending upon the needs of the implementing project.\n\n#### Security Considerations\n\n1. Wallets should prompt/warn users prior to sending potentially sensitive information (wallet address + code) via the\n   token claim URI. An informational pop-up or confirmation modal should be displayed to users such as:\n   `We are about to send your address and code 123456 to https://claim.hosky.io. Are you sure you want to proceed?`\n\n### Process Flow\n\nThe envisioned process flow for the POO Protocol is as follows:\n1. The project set asides some amount of budget (tokens + Lovelace [minUTxO]) for a given marketing push or IRL event\n2. If desired, one or more `codes` are generated to help track and analyze claiming figures\n3. QR Code(s) may be generated, printed, and otherwise displayed or given to users during the course of events\n4. Users scan the code with their mobile light wallet\n5. The light wallet makes a POST request to the API endpoint specified in the Cardano URI containing the user's wallet address and the included code (if present)\n6. The project API returns a documented status code indicating the success or failure of the operation\n7. If a successful status is detected and returned, the project issues tokens to the specified address per their campaign settings\n\n### URI Format\n\nThe URI format consists of the CIP-13 `web+cardano://` scheme, followed by the `claim` authority, then a `version` path.\n\n***NOTE: ALL ARGUMENTS SHOULD BE URL-ENCODED***\n\n#### Version 1\n\nVersion 1 URIs must include `/v1` as the path of the URI.\n\nVersion 1 URIs must include two required arguments:\n\n* `faucet_url` as a fully-typed URL (i.e. https://claim.hosky.io)\n* `code` as either a campaign identifier or unique, one-time use code\n\nVersion 1 URIs may include additional query parameters that should be passed through to the api server.\n\n_Version 1 Examples:_\n\n```html\n<!-- A Cardano Claim URI with campaign identifier code -->\n<a href=\"web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.hosky.io&code=consensus2023\">Thanks for attending Consensus 2023!</a>\n\n<!-- A Cardano Claim URI with unique, one-time use code -->\n<a href=\"web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.hosky.io&code=dff6508d8dfb4e128fd67e9ff54af147\">Claim your $HOSKY now!</a>\n\n<!-- A Cardano Claim URI with a campaign-specific code and optional user_id argument -->\n<a href=\"web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.hosky.io&code=NFTxLV2023&user_id=Idjiot1337\">Get your $HOSKY!</a>\n```\n\n### Wallet Requests\n\nLight wallets that detect and support `web+cardano` URIs as well as mobile wallets who detect either a QR code or other\nlink with this format should parse the URI and send a `POST` request to the specified URL containing a JSON payload\nincluding:\n\n* The user's wallet receive address\n* The code\n* Additional URI query parameters passed through\n\n#### Examples\n\n##### _Faucet URL + Campaign Code_\n- URI: ```web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023```\n- Faucet URL: ```https://claim.nftxlv.com```\n- POST JSON Data:\n```json\n{\n  \"address\": \"addr1abc...xyz\",\n  \"code\": \"NFTxLV2023\"\n}\n```\n\n##### _Faucet URL + Unique Code_\n- URI: ```web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023```\n- Faucet URL: ```https://claim.hosky.io```\n- POST JSON Data:\n```json\n{\n  \"address\": \"addr1abc...xyz\",\n  \"code\": \"ABC123\"\n}\n```\n\n##### _Faucet URL + Campaign Code + Custom User ID_\n- URI: ```web+cardano://claim/v1?faucet_url=https%3A%2F%2Fclaim.nftxlv.com&code=NFTxLV2023&user_id=Adam1337```\n- Faucet URL: ```https://claim.nftxlv.com```\n- POST JSON Data:\n```json\n{\n  \"address\": \"addr1abc...xyz\",\n  \"code\": \"NFTxLV2023\",\n  \"user_id\": \"Adam1337\"\n}\n```\n\n### API Server Response Codes\n\nThe API server is expected to return one of the following defined status blocks in `application/json` format. Any other\nresponses from the API server should be considered invalid and discarded or display an error.\n\nThe expected API that any token fountain implementation should follow and wallet integrators should expect is documented\non Swagger!\n\n* [Version 1](https://app.swaggerhub.com/apis/CatastrophicCardano/FaucetAPI/1)\n\n#### Successful Responses\n\n##### Valid (200)\n\nFirst Successful Request\n\n```json\n{\n  \"code\": 200,\n  \"lovelaces\": \"2000000\",\n  \"queue_position\": 23,\n  \"status\": \"accepted\",\n  \"tokens\": {\n    \"a0028f350aaabe0545fdcb56b039bfb08e4bb4d8c4d7c3c7d481c235.484f534b59\": \"29433292000000\"\n  }\n}\n```\n\n##### Valid Queued (201)\n\nSubsequent Successful Request (Address + Code Match) prior to token distribution\n\n```json\n{\n  \"code\": 201,\n  \"lovelaces\": \"2000000\",\n  \"queue_position\": 1,\n  \"status\": \"queued\",\n  \"tokens\": {\n    \"a0028f350aaabe0545fdcb56b039bfb08e4bb4d8c4d7c3c7d481c235.484f534b59\": \"29433292000000\"\n  }\n}\n```\n\n##### Valid Complete (202)\n\nSubsequent Successful Request (Address + Code Match) after token(s) are distributed\n\n```json\n{\n  \"code\": 202,\n  \"lovelaces\": \"2000000\",\n  \"status\": \"claimed\",\n  \"tokens\": {\n    \"a0028f350aaabe0545fdcb56b039bfb08e4bb4d8c4d7c3c7d481c235.484f534b59\": \"29433292000000\"\n  },\n  \"tx_hash\": \"TX1234\"\n}\n```\n\n#### Error Responses\n\n##### Bad Request - Invalid Address (400)\n\nThe provided address is not a valid Cardano address\n\n```json\n{\n   \"code\": 400,\n   \"status\": \"invalidaddress\"\n}\n```\n\n##### Bad Request - Missing Code (400)\n\nNo code was provided in the request\n\n```json\n{\n   \"code\": 400,\n   \"status\": \"missingcode\"\n}\n```\n\n##### Bad Request - Invalid Network (400)\n\nThe wallet provided is from the wrong network (testnet/mainnet)\n\n```json\n{\n   \"code\": 400,\n   \"status\": \"invalidnetwork\"\n}\n```\n\n##### Invalid - Not Known (404)\n\nThe specified code does not exist\n\n```json\n{\n  \"code\": 404,\n  \"status\": \"notfound\"\n}\n```\n\n##### Invalid - Already Claimed (409)\n\nAn address was already used (if not code present) or the code presented was found but the address did not match\n\n```json\n{\n  \"code\": 409,\n  \"status\": \"alreadyclaimed\"\n}\n```\n\n##### Invalid - Expired (410)\n\nFor time-limited fountains, a code of 410 means that the period for redemption has expired\n\n```json \n{\n  \"code\": 410,\n  \"status\": \"expired\"\n}\n```\n\n##### Invalid - Too Early (425)\n\nFor time-limited fountains, a code of 425 means that the period for redemption has not begun yet\n\n```json\n{\n  \"code\": 425,\n  \"status\": \"tooearly\"\n}\n```\n\n##### Invalid - Rate Limited (429)\n\nRate limiting settings and details are left to the discretion and implementation of individual projects. A status code\nof 429 or this status response should be considered as a rate limiting response.\n\n```json\n{\n  \"code\": 429,\n  \"status\": \"ratelimited\"\n}\n```\n\n##### Server Error (500)\n\nImplementations should of course be prepared to handle situations where a server is non-responsive for any reason and\nbe prepared to handle any other, non-specified error codes including 500 codes.\n\n### Versioning & Modification Rules\n\nIf there is sufficient justification in the future for modification of this standard to the point that a \"Version 2\"\nwould be necessary, those changes MUST be submitted as a new, separate CIP to this repository and follow all applicable\nCIP standards for acceptance. Examples of \"major\" changes that might justify a new version of this CIP include:\nfundamentally altering the URI structure, adding or removing a **required** field, or any other non-backwards compatible\nchanges to the [Process Flow](#process-flow).\n\nMinor changes for grammar, clarity, or functionality that fall within the scope of \"Version 1\" of this document may be\nmade by editing this document directly. Such changes include: grammatical or exposition changes to improve readability\nor clarity of communication, improvements to documented code examples, additional or optional server response information,\netc.\n\n## Rationale: How does this CIP achieve its goals?\n\nBy creating a well-defined standard for both a CIP-13 URI scheme and the expected API response(s) we can create a\nframework that both wallets and projects can utilize to encourage and onboard new users into the ecosystem via Native\nAsset incentive models without needlessly and constantly reinventing the wheel for each product or project.\n\nFurthermore, the aforementioned \"paper wallet\" technique has many drawbacks including:\n* The person(s) responsible for generating the paper wallets at some point have access to the seed phrases generated, leading to a potential security vulnerability\n* Projects would need to preload these wallets with funds/tokens; this makes it difficult and/or impossible to reliably know how many of the paper wallets were ever actually claimed\n* For those wallets that go forever unclaimed, this essentially creates a permanent \"burn\" of both Lovelace and the native assets of the project; less than ideal\n\nBy utilizing this framework, projects can have accurate, measurable analytics into the success of various real-world\nmarketing and event efforts: Proof of Onboarding.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [X] Demonstrate a working MVP\n- [X] Open source an MVP example of token faucet [server-side code](https://github.com/HOSKYToken/poo-genericClaim)\n- [X] Receive feedback and iterate based on community feedback\n\n### Implementation Plan\n\n- [X] VESPR Mobile Wallet supports the Proof of Onboarding Protocol.\n- [X] Yoroi Mobile Wallet supports the Proof of Onboarding Protocol.\n- [X] HOSKY Project has released an open source server-side implementation software that may be used as a proof of concept for any interested projects.\n- [X] Multiple projects at multiple, global events have successfully deployed Proof of Onboarding.\n- [X] Onboard additional wallet providers, server/service providers, and redemption methods.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0100/README.md",
    "content": "---\nCIP: 100\nTitle: Governance Metadata\nCategory: Metadata\nStatus: Active\nAuthors:\n    - Pi Lanningham <pi@sundaeswap.finance>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/cips/pulls/556\nCreated: 2023-04-09\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis Cardano Improvement Proposal (CIP) introduces a standardized and flexible metadata format for governance events in the Cardano ecosystem. While the ledger does not enforce the structure of metadata, providing a standard for metadata will enable better tooling, improved interoperability, and more consistent display across wallets, blockchain explorers, and other tools. This CIP aims to strike a balance between flexibility and structure to facilitate high-quality tooling, without limiting expressivity with regards to user expression.\n\nFor the many contributors to this proposal, see [Acknowledgements](#acknowledgements).\n\n## Motivation\n\nWith the advent of the Voltaire era, Cardano is moving towards a decentralized governance model. CIP-1694 addresses a potential technical implementation of ledger rules for creating, voting on, and ratifying proposed changes to the ledger. The ledger has no mechanism or desire to validate this metadata, and as a result, the official specification leaves the format of this metadata unspecified.\n\nTo facilitate rich user experiences for the various governance actors, however, it would be beneficial to have a suggested universal format for this metadata, allowing deep and interconnected discovery and exploration of this metadata. This CIP seeks to provide that standard format, and a minimal set of fields for various governance actions, leaving the true depth of metadata to be defined later through the extensibility mechanism outlined below.\n\nWhile this specification is written with CIP-1694 in mind, many of the ideas should be equally suitable for any other governance proposal, provided that proposal has a mechanism for attaching metadata to a governance action.\n\nExplicitly, here are the goals this CIP is trying to satisfy:\n - Standardize a format for rich metadata related to cardano governance\n - Standardize a minimal and uncontroversial set of fields to support \"Minimal Viable Governance\"\n - Leave that format open to extension and experimentation\n - Enable tooling and ecosystem developers to build the best user experiences possible\n - Provide a set of best practices that tooling and ecosystem developers can rely on for the health and integrity of this data\n\n## Specification\n\nThis section outlines the high level format and requirements of this standard.\n\n      The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL\n      NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\",  \"MAY\", and\n      \"OPTIONAL\" in this document are to be interpreted as described in\n      [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119).\n\n- On chain metadata actions in CIP-1694 (and likely any alternative proposals) have the notion of an \"Anchor\"; this is the URL and a hash for additional, non-ledger metadata about the action.\n- Tools which publish governance related transactions SHOULD publish metadata via these fields.\n- While that content MAY be in any format, following any standard or non-standard, for the remainder of this document SHOULD/MUST will refer to documents that are following this specification.\n- The content hosted at the anchor URL MUST be a JSON-LD document according to the rest of this specification.\n- This document SHOULD include `@context` and `@type` fields below to aid in interpretation of the document.  \n- The JSON document SHOULD be formatted for human readability, for the sake of anyone who is manually perusing the metadata.\n- That content SHOULD be hosted on a content addressable storage medium, such as IPFS or Arweave, to ensure immutability and long term archival.\n- The hash in the anchor MUST be the hash of the the raw bytes of the content, using the hashing algorithm specified in the `hashAlgorithm` field. Currently only blake2b-256 is supported.\n- For the purposes of hashing and signature validation, we should use the [canonical RDF triplet representation](https://www.w3.org/TR/rdf-canon/), as outlined in the JSON-LD specification.\n\n### Versioning\n\n[JSON-LD](https://json-ld.org/) is a standard for describing interconnected JSON documents that use a shared vocabulary.\n\nIn a JSON-LD document, every field is uniquely tied to some globally unique identifier by means of an Internationalized Resource Identifier (IRI). Different machine-consumers can then know that they agree on the interpretation of these fields.\n\nThe shared vocabulary of fields is standardized within the scope of a document via a `@context` field. This allows a compositional / extensible approach to versioning, similar to the recent changes to [CIP-0030](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0030/README.md). Rather than specifying a version number and forcing competing standards to compete for what the \"next\" version number will include, instead a wide variety of standards are allowed and encouraged. Tool authors MAY support those which are the most beneficial or common. This creates an organic, collaborative evolution of the standard.\n\nNote: Any URI's in the @context field SHOULD be content-addressable and robustly hosted; losing access to the schema is less dangerous than losing access to the metadata itself, but should still prefer strong and immutable storage options for the preservation of context.\n\n - A governance metadata document MAY include a `@context` field.\n - A governance metadata document MAY include a `@type` field, referring to a specific type of document from the included `@context`s. \n - The `@context` field, if included, MUST be a valid JSON-LD @context field; the basics are described below. \n   - It MAY be a string, in which case it MUST be the IRI of a jsonld document describing the shared vocabulary to assume when interpreting the document.\n   - It MAY be an object, where each key refers to a property name, and the value is either an IRI to a schema describing that field, or an object with that definition inlined.\n   - It MAY be an array, including multiple contexts, which are merged in order with a \"most-recently-defined-wins\" mechanism.\n   - For a full understanding of the @context field, refer to the [JSON-LD specification](https://www.w3.org/TR/json-ld/).\n - Each IRI in the `@context` field SHOULD refer to a schema hosted via a robust, content addressable, and immutable storage medium such as IPFS, Arweave, etc.\n - If the metadata document is missing the `@context` field, it will be assumed to refer to [./cip-0100.common.jsonld]\n - Future CIPs may standardize common contexts, and SHOULD attempt to reuse common terminology and SHOULD avoid naming collisions.\n - Tool authors MAY choose which contexts to support, but MUST make a best effort to display the metadata in the presence of unrecognized context, up to and including gracefully falling back to a raw display of the JSON document.\n\n**Extensions to the governance metadata standard can take one of two forms**:\n- CIP-0100 itself can be updated through the normal CIP process to provide additional clarity on any concepts that are giving people trouble with adoption, or to correct inaccuracies.\n- A new CIP, which defines new JSON-LD vocabulary to extend this one, which seeks broad adoption.\n- A new context document, used in the wild, but not officially standardized, and which doesn't seek broad adoption.\n\n### Hosting\n\nIn CIP-1694 (and likely any alternative or future evolution of it), there are a number of certificates that can be attached to a transaction pertaining to governance; each of these is equipped with an \"anchor\", which is a URI at which can be found additional metadata.\n\nWhile this metadata can be published anywhere, external hosting may be unavailable to some users. Therefore, we recognize the transaction metadata as an effective tool for a \"common town square\" for hosting and discoverability, and reserve [metadatum label 1694](../CIP-0010) for publishing governance related metadata on-chain.\n\nWith the help of [CIP-?](https://github.com/cardano-foundation/CIPs/pull/635), the anchor can then refer to the metadata of another transaction, or even the metadata of the transaction being published itself.\n\nWhen published on-chain, the CBOR encoding of this metadata, when published on-chain, follows [the standard convention](https://developers.cardano.org/docs/get-started/cardano-serialization-lib/transaction-metadata/#json-conversion) used for converting JSON to CBOR in transaction metadata.\n\n### Augmentations\n\nAdditionally, someone may wish to augment a previous piece of metadata with new information, divorced from the transaction that initially published it; this may be useful, for example, provide additional arguments in favor of or against a proposal, provide translations to other languages, provide a layman's explanation of a highly technical document, etc.\n\nThese use the same format, but leverage the `references` field to point to the documents that they wish to extend.\n\nThese can, in theory, be published anywhere, but the use of metadatum label 1694 mentioned above is particularly useful in this case.\n\n### Context and Schema\n\nWe expect a rich ecosystem of CIPs to emerge defining different extensions, so this CIP provides only an initial base-line MVP of fields, defined in the following JSON-LD and JSON Schema files:\n\n - [JSON-LD Context](./cip-0100.common.jsonld)\n - [JSON Schema](./cip-0100.common.schema.json)\n\nThe rest of this document will provide a high level description of how these fields should be interpreted\n\n### High level description\n\nThe following properties are considered common to all types of transactions, and the minimal set needed for \"minimum viable governance\":\n\n- `hashAlgorithm`: The algorithm used to hash the document for the purposes of the on-chain anchor; currently only supports blake2b-256\n- `authors`: The primary contributors and authors for this metadata document\n  - An array of objects\n  - Each object MAY have a `name` property, which serves as a display name\n  - Each object MUST have a `witness` field, which contains a signature of the `body` of the document\n  - The witness may define a `@context`, describing the manner in which the document has been witnessed\n  - A default witness scheme context is described in a later section\n  - Tooling authors SHOULD validate witnesses they understand\n  - If witnesses aren't validated, tooling authors SHOULD emphasize this to the user\n  - If absent or invalid, tooling authors SHOULD make this clear to the user\n- `body`: The material contents of the document, separate for the purposes of signing\n  - `references`\n    - An array of objects\n    - Each object specifies a `@type`, which is either \"GovernanceMetadata\" or \"Other\"\n    - Each object specifies a `label`, which serves as a human readable display name\n    - Each object specifies a `uri`; when the type is set to \"GovernanceMetadata\", the URI should point to another CIP-0100 compliant document\n  - `comment`\n    - Freeform text attached to the metadata; richer structures for justifying the transaction this is attached to is left to future CIPs\n    - Tooling authors SHOULD emphasize that these comments represent the *authors* views, and may contain bias.\n  - `externalUpdates`\n    - A array of objects\n    - Each object can have a `@context` defining how to interpret it\n    - by default, assumed to just be an object with a `title` and `uri` field\n    - The purpose is to allow \"additional updates\", that aren't written yet, such as a blog or RSS feed\n    - Tooling authors MAY fetch and parse this metadata according to this standard,\n    - If so, Tooling authors MUST emphasize that this information is second-class, given that it might have changed\n\nAdditionally, we highlight the following concepts native to json-ld that are useful in the context of governance metadata:\n - [@language](https://www.w3.org/TR/json-ld11/#string-internationalization)\n   - The `@context` field SHOULD specify a `@language` property, which is an ISO 639-1 language string, to define a default language for the whole document\n   - Specific sub-fields can specify different languages\n   - The `@context` field may specify a `@container` property set to `@language`, in which case the property becomes a map with different translations of the property\n   - Tooling authors MAY provide automatic translation, but SHOULD make the original prose easily available\n\n### Hashing and Signatures\n\nWhen publishing a governance action, the certificate has an \"anchor\", defined as a URI and a hash of the content at the URI.\n\nFor CIP-0100 compliant metadata, the hash in the anchor should be the blake2b-256 hash of the raw bytes received from the wire.\nHashing directly the original bytes ensures that there are no ambiguities, since the process doesn't depend on parsing the metadata, which can be the source of conflicts in different implementations.\n\nA metadata has a number of authors, each of which MUST authenticate their endorsement of the document in some way.\n\nThis is left extensible, through the use of a new context, but for the purposes of this CIP, we provide a simple scheme.\n\nEach author should have a witness. The witness will be an object with an `witnessAlgorithm` (set to ed25519), a `publicKey` (set to a base-16 encoded ed25519 public key), and a `signature`, set to the base-16 encoded signature of the body field.\n\nBecause the overall document may change, it is neccesary to hash a subset of the document that is known before any signatures are collected. This is the motivation behind the `body` field.\n\nThe signature is an ed25519 signature using the attached public key, and the payload set to the blake2b-256 hash of the `body` field. Specifically, this field is canonicalized in the following way.\n- Canonicalize the whole document according to [this](https://w3c-ccg.github.io/rdf-dataset-canonicalization/spec/) specification.\n- Identify the node-ID of the `body` node\n- Filter the canonicalized document to include the body node, and all its descendents\n- Ensure the file ends in a newline\n- Hash the resulting file with blake2b-256\n\n### Best Practices\n\nThis section outlines a number of other best practices for tools and user experiences built on top of this standard, as brainstormed by the Cardano community.\n\n - If the hash in the anchor doesn't match the computed hash of the content, it is imperative to make that obvious to the user.\n   - Without this being obvious, there are severe and dramatic attack vectors for manipulating user votes, delegators, etc.\n   - NOTE: The term \"MUST\" in the RFC-2119 sense isn't used here because it's unenforcable anyway, but if these hashes *aren't* checked, you **SHOULD** inform the user that you are not checking the integrity of the data.\n   - You MAY do this by displaying a prominent warning, or potentially fully barring access to the content.\n - You SHOULD provide a way to access the raw underlying data for advanced or diligent users.\n   - This MAY be in the form of a JSON viewer, or a simple link to the content.\n - You SHOULD gracefully degrade to a simple raw content view if the metadata is malformed in some way, or not understood.\n   - For example, a proposal has added an extra unexpected field, in addition to expected ones. The tool SHOULD gracefully render expected fields and show users a raw view of unexpected fields. \n - You SHOULD provide links and cross references whenever the metadata refers to another object in some way\n   - For example, a proposal may link to the sponsoring DReps, which may have their own view within the tool you're building\n - If you are hosting the content for the user, you SHOULD use a content-addressable hosting platform such as IPFS or Arweave\n - If the content is self-hosted, you SHOULD take care to warn the user about changing the content\n   - For example, you CAN detect well-known content-addressable file storage platforms such as IPFS or Arweave, and display an extra warning if the content is not hosted on one of those\n\n## Rationale: how does this CIP achieve its goals?\n\nHere are the goals this CIP seeks to achieve, and the rationale for how this specific solution accomplishes them:\n\n - Standardize a format for rich metadata related to cardano governance\n   - Standardizing on JSON-LD provides an industry standard, yet highly flexible format for effectively arbitrary structured data\n - Standardize a minimal and uncontroversial set of fields to support \"Minimal Viable Governance\"\n   - This CIP specifies a minimal number of fields: hash-algorithm, authors, justification, external-updates, and @language\n   - Each of these fields is essential for the global accessibility of this data, and enables tooling that promotes a well-informed voting populace\n - Leave that format open to extension and experimentation\n   - JSON-LD has, built in, a mechanism for extending and experimenting with new field types\n   - Anyone can extend this metadata, even independent of the CIP process, with their own field definitions\n   - Tooling authors can, independently, choose which extensions to support natively, while also surfacing fields they don't recognize in more generic ways.\n - Enable tooling and ecosystem developers to build the best user experiences possible\n   - The `@context` field of a JSON-LD document allows tooling authors to confidently and consistently interpret a known field within the metadata, with reduced risk of misinterpreting or misrepresenting the authors intent\n   - This metadata can also reference other objects and documents in the ecosystem, providing for rich exploration needed for an informed voting populace.\n - Provide a set of best practices that tooling and ecosystem developers can rely on for the health and integrity of this data\n   - This CIP has an explicit section of best practices, brainstormed with attendees of a workshop dedicated to the purpose.\n\nThe following alternatives were considered, and rejected:\n - Plain JSON documents\n   - While ultimately flexible and simple, there is a risk that with no way to structure what is *officially* supported, and the interpretation of each field, tooling authors would have one hand tied behind their back, and would be limited to a minimum common denominator.\n - Canonicalising the whole document before hashing it\n   - Canonicalising requires initially parsing the file as a json, which can by itself cause ambiguities\n - A custom JSON format, with reference to CIPs\n  - An initial draft of this proposal had an `extensions` field that operated very similar to `@context`\n  - Instead, this CIP chose to go with an industry standard format to leverage the existing tooling and thought that went into JSON-LD\n - CBOR or other machine encoding\n  - The metadata in question, despite being proliferous, is not expected to to be an undue storage burden; It's not, for example, video data, or storing billions of records.\n  - It is more important, then, that the metadata be human readable, so that tooling authors have the option to show this data in its raw format to a user, and for it to be loosely understandable even by non-technical users.\n\n### Test Vectors\n\nSee [test-vector.md](./test-vector.md) for example.\n\n## Path to Active\n\nThe path for this proposal to be considered active within the community focuses on 4 key stages: Feedback, Implementation, Adoption, and Extension.\n\n### Acceptance Criteria\n\nIn order for this standard to be active, the following should be true:\n\n - [x] At least 1 month of feedback has been solicited, and any relevant changes with broad consensus to the proposal made\n - [ ] At least 2 client libraries in existence that support reading an arbitrary JSON file, and returning strongly typed representations of these documents\n   - [cardano-governance-metadata-lib](https://github.com/SundaeSwap-finance/cardano-governance-metadata)\n - [x] At least 1 widely used *producer* of governance metadata (such as a wallet, or the cardano-cli)\n   - [1694.io](https://www.1694.io)\n   - [GovTool](https://gov.tools)\n   - [Tempo.vote](https://tempo.vote)\n - [x] At least 1 widely used *consumer* of governance metadata (such as a blockchain explorer, governance explorer, voting dashboard, etc)\n   - [1694.io](https://www.1694.io)\n   - [Adastat](https://adastat.net)\n   - [Cardanoscan](https://cardanoscan.io)\n   - [GovTool](https://gov.tools)\n   - [Tempo.vote](https://tempo.vote)\n - [x] At least 1 CIP in the \"Proposed\" status that outlines additional fields to extend this metadata\n   - [CIP-108 | Governance Metadata - Governance Actions](../CIP-0108/README.md)\n   - [CIP-119 | Governance metadata - DReps](../CIP-0119/README.md)\n   - [CIP-136 | Governance metadata - Constitutional Committee votes](../CIP-0136/README.md)\n\n### Community Tooling\n\nBelow you can find a growing list of community tools which let you sign / verify / canonize / manipulate governance metadata JSON-LD data:\n- [cardano-signer](https://github.com/gitmachtl/cardano-signer?tab=readme-ov-file#cip-100--cip-108--cip-119-mode) : A tool to sign with author secret keys, verify signatures, canonize the body content (Linux/Arm/Win/Mac)\n- [cardano-governance-metadata-lib](https://github.com/SundaeSwap-finance/cardano-governance-metadata) : A rust library for interacting with Cardano Governance Metadata conforming to CIP-100 (rust)\n- [verifycardanomessage.cardanofoundation.org](https://verifycardanomessage.cardanofoundation.org/method=cip100) : A tool to verify CIP-100 compliance of metadata.\n\n### Implementation Plan\n\nThe key stages to get this proposal to active, and the motivation for why each stage is valuable, is outlined below:\n\n- Solicitation of feedback\n  - While this proposal represents the input of many prominent community members, it is by no means exhaustive\n  - This CIP should receive a moderate, but not egregious, amount of scrutiny and feedback within it's initial goals\n- Implementation\n  - The effectiveness of this standard is greatly amplified if tools and SDKs are built which allow parsing arbitrary data according to this standard\n  - Sundae Labs has offered to build Rust and Golang libraries that capture the types outlined above, and implementations in other languages are welcome\n  <!-- In particular, I would love to find someone to own the Haskell implementation for easy integration into the cardano-cli -->\n- Adoption\n  - This standard is most effective if it receives widespread adoption\n  - Therefore, a path to active includes engaging prominent members of the ecosystem, such as wallets and explorers, to begin producing and consuming documents in accordance with the standard.\n- Extension\n  - Finally, this standard chooses to fully specify very little of the total surface area of what could be expressed in governance metadata\n  - Therefore, to prove the extensibility of the standard, at least one follow-up CIP should be drafted, extending the set of fields beyond \"Minimum Viable Governance\"\n\n## Acknowledgements\n\n<details>\n  <summary><strong>First draft/workshop</strong></summary>\n\n  I would like to thank those that contributed to this first draft during the online workshop that was held on 2023-04-12.\n\n - CHIL Pool\n - Alex Djuric\n - Cody Butz\n - Felix Weber\n - Leo Pienasola\n - Markus Gufler\n - Michael Madoff\n - Mohamed Mahmoud\n - Thomas Upfield\n - William Ryan\n - Santiago Carmuega\n\n</details>\n\n<details>\n  <summary><strong>Second draft</strong></summary>\n\n  The following people helped with the second draft, out of band at at the Edinburgh workshop on 2023-07-12.\n\n  - Ryan Williams\n  - Matthias Benkort\n  - All Edinburgh Workshop attendees\n\n</details>\n<details>\n  <summary><strong>Second Workshop</strong></summary>\n\n  The following people helped with the third draft during the online workshop held on 2023-11-02.\n\n  - Mike Susko\n  - Thomas Upfield\n  - Lorenzo Bruno\n  - Ryan Williams\n  - Nils Peuser\n  - Santiago Carmuega\n  - Nick Ulrich\n  - Ep Ep\n\n</details>\n\n<details>\n  <summary><strong>Third Workshop</strong></summary>\n\n  The following people helped with the third draft during the online workshop held on 2023-11-10.\n\n  - Adam Dean\n  - Rhys Morgan\n  - Thomas Upfield\n  - Marcel Baumberg\n\n</details>\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0100/cip-0100.common.jsonld",
    "content": "{\n    \"@context\": {\n        \"hashAlgorithm\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#hashAlgorithm\",\n        \"body\": {\n            \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#body\",\n            \"@context\": {\n                \"references\": {\n                    \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#references\",\n                    \"@container\": \"@set\",\n                    \"@context\": {\n                        \"governanceMetadata\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#GovernanceMetadataReference\",\n                        \"other\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#OtherReference\",\n                        \"label\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-label\",\n                        \"uri\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-uri\"\n                    }\n                },\n                \"comment\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#comment\",\n                \"externalUpdates\": {\n                    \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#externalUpdates\",\n                    \"@context\": {\n                        \"title\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#update-title\",\n                        \"uri\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#update-uri\"\n                    }\n                }\n            }\n        },\n        \"authors\": {\n            \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#authors\",\n            \"@container\": \"@set\",\n            \"@context\": {\n                \"did\": \"@id\",\n                \"name\": \"http://xmlns.com/foaf/0.1/name\",\n                \"witness\": {\n                    \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#witness\",\n                    \"@context\": {\n                        \"witnessAlgorithm\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#witnessAlgorithm\",\n                        \"publicKey\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#publicKey\",\n                        \"signature\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#signature\"\n                    }\n                }\n            }\n        }\n    }\n}"
  },
  {
    "path": "CIP-0100/cip-0100.common.schema.json",
    "content": "{\n    \"title\": \"CIP-100 Common\",\n    \"description\": \"A base-line CIP-100 governance metadata document\",\n    \"type\": \"object\",\n    \"required\": [\n        \"hashAlgorithm\",\n        \"authors\",\n        \"body\"\n    ],\n    \"properties\": {\n        \"hashAlgorithm\": {\n            \"$ref\": \"#/definitions/hashAlgorithm\"\n        },\n        \"authors\": {\n            \"title\": \"Authors\",\n            \"description\": \"The authors of this governance metadata\",\n            \"type\": \"array\",\n            \"items\": {\n                \"$ref\": \"#/definitions/Author\"\n            }\n        },\n        \"body\": {\n            \"$ref\": \"#/definitions/Body\"\n        }\n    },\n    \"definitions\": {\n        \"hashAlgorithm\": {\n            \"title\": \"Hash Algorithm\",\n            \"description\": \"The hash algorithm used to authenticate this document externally\",\n            \"type\": \"string\",\n            \"enum\": [\n                \"blake2b-256\"\n            ]\n        },\n        \"Author\": {\n            \"title\": \"Author\",\n            \"description\": \"An author endorsing the content of a metadata document\",\n            \"type\": \"object\",\n            \"required\": [\n                \"witness\"\n            ],\n            \"properties\": {\n                \"name\": {\n                    \"title\": \"Name\",\n                    \"type\": \"string\"\n                },\n                \"witness\": {\n                    \"$ref\": \"#/definitions/Witness\"\n                }\n            }\n        },\n        \"Witness\": {\n            \"title\": \"Witness\",\n            \"description\": \"A witness proving that the author endorses the content of the metadata\",\n            \"type\": \"object\",\n            \"properties\": {\n                \"witnessAlgorithm\": {\n                    \"title\": \"WitnessAlgorithm\",\n                    \"type\": \"string\",\n                    \"enum\": [\n                        \"ed25519\"\n                    ]\n                },\n                \"publicKey\": {\n                    \"title\": \"PublicKey\",\n                    \"type\": \"string\"\n                },\n                \"signature\": {\n                    \"title\": \"Signature\",\n                    \"type\": \"string\"\n                }\n            }\n        },\n        \"Body\": {\n            \"title\": \"Body\",\n            \"description\": \"The body of the metadata document that is hashed to produce a signature\",\n            \"properties\": {\n                \"references\": {\n                    \"title\": \"References\",\n                    \"type\": \"array\",\n                    \"items\": {\n                        \"$ref\": \"#/definitions/Reference\"\n                    }\n                },\n                \"comment\": {\n                    \"title\": \"Comment\",\n                    \"type\": \"string\"\n                },\n                \"externalUpdates\": {\n                    \"title\": \"ExternalUpdates\",\n                    \"type\": \"array\",\n                    \"items\": {\n                        \"$ref\": \"#/definitions/ExternalUpdate\"\n                    }\n                }\n            }\n        },\n        \"Reference\": {\n            \"title\": \"Reference\",\n            \"description\": \"A reference to a document\",\n            \"type\": \"object\",\n            \"required\": [\n                \"@type\",\n                \"label\",\n                \"uri\"\n            ],\n            \"properties\": {\n                \"@type\": {\n                    \"title\": \"Type\",\n                    \"type\": \"string\",\n                    \"enum\": [\n                        \"GovernanceMetadata\",\n                        \"Other\"\n                    ]\n                },\n                \"label\": {\n                    \"title\": \"Label\",\n                    \"type\": \"string\"\n                },\n                \"uri\": {\n                    \"title\": \"URI\",\n                    \"type\": \"string\"\n                }\n            }\n        },\n        \"ExternalUpdate\": {\n            \"title\": \"ExternalUpdate\",\n            \"type\": \"object\",\n            \"description\": \"An source for updates *after* the metadata is published\",\n            \"required\": [\n                \"title\",\n                \"uri\"\n            ],\n            \"properties\": {\n                \"title\": {\n                    \"title\": \"Title\",\n                    \"type\": \"string\"\n                },\n                \"uri\": {\n                    \"title\": \"URI\",\n                    \"type\": \"string\"\n                }\n            }\n        }\n    }\n}"
  },
  {
    "path": "CIP-0100/example.body.json",
    "content": "{\n    \"@context\": {\n        \"@language\": \"en-us\",\n        \"hashAlgorithm\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#hashAlgorithm\",\n        \"body\": {\n            \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#body\",\n            \"@context\": {\n                \"references\": {\n                    \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#references\",\n                    \"@container\": \"@set\",\n                    \"@context\": {\n                        \"governanceMetadata\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#GovernanceMetadataReference\",\n                        \"other\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#OtherReference\",\n                        \"label\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-label\",\n                        \"uri\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-uri\"\n                    }\n                },\n                \"comment\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#comment\",\n                \"externalUpdates\": {\n                    \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#externalUpdates\",\n                    \"@context\": {\n                        \"title\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#update-title\",\n                        \"uri\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#update-uri\"\n                    }\n                }\n            }\n        },\n        \"authors\": {\n            \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#authors\",\n            \"@container\": \"@set\",\n            \"@context\": {\n                \"did\": \"@id\",\n                \"name\": \"http://xmlns.com/foaf/0.1/name\",\n                \"witness\": {\n                    \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#witness\",\n                    \"@context\": {\n                        \"witnessAlgorithm\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#witnessAlgorithm\",\n                        \"publicKey\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#publicKey\",\n                        \"signature\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#signature\"\n                    }\n                }\n            }\n        }\n    },\n    \"body\": {\n      \"references\": [\n        { \"@type\": \"Other\", \"label\": \"CIP-100\", \"uri\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md\" }\n      ],\n      \"comment\": \"This is a test vector for CIP-100\",\n      \"externalUpdates\": [\n        { \"title\": \"Blog\", \"uri\": \"https://314pool.com\" }\n      ]\n    }\n  }"
  },
  {
    "path": "CIP-0100/example.body.nq",
    "content": "_:c14n0 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#body> _:c14n2 .\n_:c14n1 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-label> \"CIP-100\"@en-us .\n_:c14n1 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-uri> \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md\"@en-us .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#comment> \"This is a test vector for CIP-100\"@en-us .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#externalUpdates> _:c14n3 .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#references> _:c14n1 .\n_:c14n3 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#update-title> \"Blog\"@en-us .\n_:c14n3 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#update-uri> \"https://314pool.com\"@en-us .\n"
  },
  {
    "path": "CIP-0100/example.json",
    "content": "{\n    \"@context\": {\n        \"@language\": \"en-us\",\n        \"hashAlgorithm\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#hashAlgorithm\",\n        \"body\": {\n            \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#body\",\n            \"@context\": {\n                \"references\": {\n                    \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#references\",\n                    \"@container\": \"@set\",\n                    \"@context\": {\n                        \"governanceMetadata\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#GovernanceMetadataReference\",\n                        \"other\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#OtherReference\",\n                        \"label\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-label\",\n                        \"uri\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-uri\"\n                    }\n                },\n                \"comment\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#comment\",\n                \"externalUpdates\": {\n                    \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#externalUpdates\",\n                    \"@context\": {\n                        \"title\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#update-title\",\n                        \"uri\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#update-uri\"\n                    }\n                }\n            }\n        },\n        \"authors\": {\n            \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#authors\",\n            \"@container\": \"@set\",\n            \"@context\": {\n                \"did\": \"@id\",\n                \"name\": \"http://xmlns.com/foaf/0.1/name\",\n                \"witness\": {\n                    \"@id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#witness\",\n                    \"@context\": {\n                        \"witnessAlgorithm\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#witnessAlgorithm\",\n                        \"publicKey\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#publicKey\",\n                        \"signature\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#signature\"\n                    }\n                }\n            }\n        }\n    },\n    \"hashAlgorithm\": \"blake2b-256\",\n    \"authors\": [\n      { \"name\": \"Pi Lanningham\", \"witness\": { \"witnessAlgorithm\": \"ed25519\", \"publicKey\": \"7ea09a34aebb13c9841c71397b1cabfec5ddf950405293dee496cac2f437480a\", \"signature\": \"68078efeff90970d2320a2bb5021d1aea81bc4907bf33d54fd17989f020719f3f5c4da3dccf7aa61d51c1e6fececd95309c37e7eef331b199cd5f8e78992ea0d\"}}\n    ],\n    \"body\": {\n      \"references\": [\n        { \"@type\": \"Other\", \"label\": \"CIP-100\", \"uri\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md\" }\n      ],\n      \"comment\": \"This is a test vector for CIP-100\",\n      \"externalUpdates\": [\n        { \"title\": \"Blog\", \"uri\": \"https://314pool.com\" }\n      ]\n    }\n  }"
  },
  {
    "path": "CIP-0100/test-vector.md",
    "content": "# Test Vector for CIP-0100\n\nHere we give some supporting files, give an example and explain how the [example.json](./example.json) was created.\n\n## Common Context\n\n### Common Fields\n\nThe context fields which could be added to CIP-100 compliant jsonld metadata.\nSee [cip-0100.common.jsonld](./cip-0100.common.jsonld).\n\n### Common Fields Schema\n\nA json schema for the common context fields.\nSee [cip-0100.common.schema.json](./cip-0100.common.schema.json).\n\n## Example\n\nCIP-100 off-chain metadata json example: [example.json](./example.json)\n\nBlake2b-256 hash of the file (to go on-chain): `7b7d4a28a599bbb8c08b239be2645fa82d63a848320bf4760b07d86fcf1aabdc`\n\n### Intermediate files\n\nFiles produced to articulate the process of author witnessing;\nthese are not necessary in implementations.\n\nBody files, used to correctly generate author's witness:\n- [example.body.json](./example.body.json)\n- [example.body.nq](./example.body.nq)\n\nBlake2b-256 hash digest of canonicalized body: `6d17e71c5793ed5945f58bf48e13bb1b3543187ab9c2afbd280a21afb4a90d35`\n\n### How-to Recreate\n\nThis tutorial creates additional intermediate files ([example.body.json](./example.body.json), [example.body.nq](./example.body.nq));\nthese are not required in implementations but are shown here to articulate the process.\n\n#### Author\n\nPrivate extended signing key (hex):\n`105d2ef2192150655a926bca9cccf5e2f6e496efa9580508192e1f4a790e6f53de06529129511d1cacb0664bcf04853fdc0055a47cc6d2c6d205127020760652`\n\nPublic verification key (hex):\n`7ea09a34aebb13c9841c71397b1cabfec5ddf950405293dee496cac2f437480a`\n\n#### 1. Create the example.json's `body`\n\nCreate the `example.json` file adding in all available values i.e. `comment`, `references`.\n\nThen remove any top-level fields that are not `@context` or `body`:\nThis creates a intermediate file of [example.body.json](./example.body.json).\n\n#### 2. Canonicalize the `body`\n\nUsing a tool which complies with the [RDF Dataset Canonicalization](https://w3c-ccg.github.io/rdf-dataset-canonicalization/spec/),\ncreate a canonicalized representation of [example.body.json](./example.body.json).\n\nOne such tool is the [JSON-LD Playground](https://json-ld.org/playground/).\nEnsure the result ends in an empty line.\n\nThis creates a intermediate file of [example.body.nq](./example.body.nq).\n\n#### 3. Hash the canonicalized `body`\n\nUse a tool to create a Blake2b-256 hash digest of the canonicalized [example.body.nq](./example.body.nq).\nOne such tool is the [ToolKit Bay](https://toolkitbay.com/tkb/tool/BLAKE2b_256).\n\nFor our example ([example.body.nq](./example.body.nq)) this will result in: `6d17e71c5793ed5945f58bf48e13bb1b3543187ab9c2afbd280a21afb4a90d35`.\n\n#### 4. Authors witness over the hash of canonicalized `body`\n\nUse the hash produced in [3.](#3-hash-the-canonicalized-body) as the payload for the witness as described in [Hashing and Signatures](./README.md#hashing-and-signatures) for the chosen `witnessAlgorithm`.\n\nOne tool for Ed25519 signatures is [Ed25519 Online Tool](https://cyphr.me/ed25519_tool/ed.html).\n\nFor the provided [example.json](./example.json), we use the keys described in [Author](#author) resulting in a `signature` of: `68078efeff90970d2320a2bb5021d1aea81bc4907bf33d54fd17989f020719f3f5c4da3dccf7aa61d51c1e6fececd95309c37e7eef331b199cd5f8e78992ea0d`\n\n#### 5. Add `authors` and `hashAlgorithm` to example.json\n\nWe can go back to our [example.json](./example.json) and now add in properties from outside of `body`.\n- Adding the `hashAlgorithm` of `blake2b-256`.\n- Adding the `authors`, including information of our `witness` produced via [4.](#4-authors-witness-over-the-hash-of-canonicalized-body).\n\nBy adding this information we create our [example.json](example.json).\n\n#### 6. Hash example.json\n\nTo be able to create a final metadata hash which can be attached on-chain we simply hash the content of the file [example.json](example.json) as is.\n\nThis results in: `7b7d4a28a599bbb8c08b239be2645fa82d63a848320bf4760b07d86fcf1aabdc`.\n\n#### 7. Submit to chain\n\nWe can then host [example.json](./example.json) somewhere easily accessible following [Best Practices](./README.md#best-practices).\n\nThen at submission time of the governance metadata anchor we can provide the on-chain transaction both the URI to the hosted [example.json](./example.json) but also the hash generated via [6.](#6-hash-examplejson).\n"
  },
  {
    "path": "CIP-0101/README.md",
    "content": "---\nCIP: 101\nTitle: Integration of keccak256 into Plutus\nStatus: Proposed\nCategory: Plutus\nAuthors: \n  - Sergei Patrikeev <so.patrikeev@gmail.com>\n  - Iñigo Querejeta-Azurmendi <inigo.querejeta@iohk.io>\nImplementors:\n  - Michael Peyton Jones <michael.peyton-jones@iohk.io>\nDiscussions: \n  - https://github.com/cardano-foundation/CIPs/pull/524\nCreated: 2023-06-13\nLicense: Apache-2.0\n---\n\n## Abstract\nThis CIP proposes an extension of the current Plutus functions to provide support for the [`keccak256`](https://keccak.team/files/Keccak-submission-3.pdf) hashing algorithm,\nprimarily to ensure compatibility with Ethereum's cryptographic infrastructure.\n\n## Motivation: why is this CIP necessary?\n\nThe [integration](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0049/README.md) of the ECDSA and Schnorr signatures over the secp256k1 curve into Plutus was a significant \nstep towards interoperability with Ethereum and Bitcoin ecosystems. However, full compatibility is still impossible \ndue to the absence of the `keccak256` hashing algorithm in Plutus interpreter, \nwhich is a fundamental component of Ethereum's cryptographic framework:\n- data signing standard [EIP-712](https://eips.ethereum.org/EIPS/eip-712), \n- `keccak256` is the hashing algorithm underlying Ethereum's ECDSA signatures. \n- EVM heavily [depends](https://ethereum.github.io/yellowpaper/paper.pdf) on `keccak256` for internal state management\n\nAdding `keccak256` to Plutus would enhance the potential for cross-chain solutions between Cardano and EVM-based blockchains.\n\nA compelling integration that would greatly benefit from `keccak256` support on the Cardano blockchain is [Hyperlane](https://hyperlane.xyz/).\nHyperlane is a permissionless interoperability layer that facilitates communication of arbitrary data between smart contracts across multiple blockchains. Hyperlane's [interchain security modules](https://docs.hyperlane.xyz/docs/protocol/sovereign-consensus)\nrely on the verification of specific cryptographic proofs from one chain to another. These proofs utilize the `keccak256` hash to calculate consistent cross-chain message IDs.\nThe multi-signature module verifies that a majority of off-chain validators have signed an ECDSA signature over a `keccak256` digest, a common practice in EVM.\n\nWhile Hyperlane [can support](https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2399) different cryptographic primitives for non-EVM chains, doing so could compromise censorship resistance, resulting in only limited support for Cardano in Hyperlane. By implementing this CIP, Cardano could fully integrate with Hyperlane's security modules, enabling Cardano smart contracts to communicate with any blockchain supported by Hyperlane.\n\n## Specification\nThis proposal aims to introduce a new built-in hash function `keccak_256`.\n\nThis function will be developed following the [`keccak256`](https://keccak.team/files/Keccak-submission-3.pdf) specification \nand will utilize the [cryptonite](https://github.com/haskell-crypto/cryptonite/blob/master/Crypto/Hash/Keccak.hs) implementation. \nSince `cryptonite` is already a part of the [`cardano-base`](https://github.com/input-output-hk/cardano-base/blob/master/cardano-crypto-class/src/Cardano/Crypto/Hash/Keccak256.hs), \nthis simplifies its integration into Plutus. The cost of the `keccak_256` operation will scale linearly with the length of the message.\n\nMore specifically, Plutus will gain the following primitive operation:\n\n* `keccak_256` :: ByteString -> ByteString\n\nThe input to this function can be a `ByteString` of arbitrary size, and the output will be a `ByteString` of 32 bytes. \nNote that this function aligns with the format of existing hash functions in Plutus, such as [blake2b_256](https://github.com/input-output-hk/plutus/blob/75267027f157f1312964e7126280920d1245c52d/plutus-core/plutus-core/src/Data/ByteString/Hash.hs#L25)\n\n## Rationale: how does this CIP achieve its goals?\nWhile the `keccak256` function might be implemented in on-chain scripts, doing so would be computationally unfeasible. \n\nThe library, cryptonite, is not implemented by and under control of the Plutus team. However, \n* It is a library already used in the Cardano stack to expose SHA3, and can be considered as a trustworthy implementation. \n* The function does not throw any exceptions as hash functions are defined to work with any ByteString input. It does not expect a particular particular structure. \n* It's behaviour is predictable. As mentioned above, the cost of the function is linear with respect to the size of the message provided as input. This is the same behaviour that other hash functions exposed in plutus (blake, sha3) have.\n## Path to Active\nThis CIP may transition to active status once the Plutus version containing the `keccak_256` function is introduced \nin a node release and becomes available on Mainnet.\n\n### Acceptance Criteria\n* A Plutus binding is created for the `keccak256` function and included in a new version of Plutus.\n* Integration tests, similar to those of the existing Plutus hash functions, are added to the testing infrastructure.\n* The function is benchmarked to assess its cost. As for other hash functions available in Plutus (blake2b and sha256), we expect the cost of keccak to be linear with respect to the size of the message. The Plutus team determines the exact costing functions empirically.\n* The ledger is updated to include new protocol parameters to control costing of the new builtins.\n\n### Implementation Plan\nThe Plutus team will develop the binding, integration tests, and benchmarks. The E2E tests will be designed and implemented \ncollaboratively by the testing team, the Plutus team, and community members planning to use this primitive.\n\n## Copyright\nThis CIP is licensed under [Apache-2.0][https://www.apache.org/licenses/LICENSE-2.0]. \n"
  },
  {
    "path": "CIP-0102/README.md",
    "content": "---\nCIP: 102\nTitle: Royalty Datum Metadata\nAuthors: \n - Sam Delaney <sdelaney@ikigaitech.org>\nImplementors: \n- Grabbit <https://grabbit.market/>\n- Nebula <https://github.com/spacebudz/nebula/>\nDiscussions:\n - https://github.com/ikigai-github/CIPs/pull/1\n - https://github.com/cardano-foundation/CIPs/pull/551\nStatus: Proposed\nCategory: Tokens\nCreated: 2023-08-08\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis proposal makes use of the onchain metadata pattern established in [CIP-0068][] to provide a way to store royalties with greater assurance and customizability.\n\n## Motivation: why is this CIP necessary?\n\nThe inability to create trustless onchain royalty validation with [CIP-0027][] is a major drawback to Cardano NFTs. The pattern defined in CIP-68 represents an opportunity to upgrade the standard to support onchain validation. This CIP aims to eliminate that drawback and demonstrate better support for developers, NFT creators, and NFT collectors, ultimately attracting dapps & NFT projects that would otherwise have taken their talents to another blockchain.\n\nIn addition, this standard allows royalties to be split between multiple addresses, another limitation of the CIP-27 royalty schema. Future versions of this standard could  also easily support multiple royalty policies defined for a single collection, applied at the level of individual tokens.\n\n## Specification\n\n### 500 Royalty Datum Standard\n\nThe following defines the `500` Royalty NFT standard with the registered `asset_name_label` prefix value\n\n| asset_name_label            | class        | description                                                          |\n| --------------------------- | ------------ | -------------------------------------------------------------------- |\n| 500                         | NFT          | Royalty NFT stored in a UTxO containing a datum with royalty information |\n\n#### Class\n\nThe `royalty NFT` is an NFT (non-fungible token).\n\n#### Pattern\n\nThe `royalty NFT` **must** have an identical `policy id` as the collection.\n\nThe `asset name` **must** be `001f4d70526f79616c7479` (hex encoded), it contains the [CIP-0067][] label `500` followed by the word \"Royalty\".\n\nExample:\\\n`royalty NFT`: `(500)Royalty`\\\n`reference NFT`: `(100)Test123`\n\n#### 500 Datum Metadata\n\nThe royalty info datum is specified as follows (CDDL):\n\n```cddl\nbig_int = int / big_uint / big_nint\nbig_uint = #6.2(bounded_bytes)\nbig_nint = #6.3(bounded_bytes)\n\noptional_big_int = #6.121([big_int]) / #6.122([])\n\nroyalty_recipient = #6.121([\n              address,                    ; definition can be derived from: \n                                          ; https://github.com/input-output-hk/plutus/blob/master/plutus-ledger-api/src/PlutusLedgerApi/V1/Address.hs#L31\n              int,                        ; variable fee ( calculation: ⌊1 / (fee / 10)⌋ ); integer division with precision 10\n              optional_big_int,           ; min fee (absolute value in lovelace)\n              optional_big_int,           ; max fee (absolute value in lovelace)\n            ])\n\nroyalty_recipients = [ * royalty_recipient ]\n\n; version is of type int, we start with version 1\nversion = 1  \n\n; Custom user defined plutus data.\n; Setting data is optional, but the field is required\n; and needs to be at least Unit/Void: #6.121([])\nextra = plutus_data\n\nroyalty_info = #6.121([royalty_recipients, version, extra])\n```\n\n#### Example of onchain variable fee calculation:\n\n```cddl\n; Given a royalty fee of 1.6% (0.016)\n\n; To store this in the royalty datum\n1 / (0.016 / 10) => 625\n\n; To read it back\n10 / 625 => 0.016\n```\nBecause the computational complexity of Plutus primitives scales with size, this approach significantly minimizes resource consumption.\n\nTo prevent abuse, it is **recommended** that the `royalty NFT` is stored at the script address of a validator that ensures the specified fees are not arbitrarily changed, such as an always-fails validator.\n\n### Reference Datum Royalty Flag\n\nIf not specified elsewhere in the token's datums, a malicious user could send transactions to a protocol which do not reference the royalty datum. For full assurances, a new optional flag should be added to the reference datum\n\n```cddl\nextra = \n\t{\n\t\t...\n\n\t\t? royalty_included : big_int\n\t}\n```\n\n- If the field is present and > 1 the validators must require a royalty input.\n- If the field is present and set to 0 the validators don't need to search for a royalty input.\n- If the field is not present, validators should accept a royalty input, but not require one.\n\n### Examples\n\nIn-code examples can be found in the [reference implementation](https://github.com/SamDelaney/CIP_102_Reference).\n\n#### Retrieve metadata as 3rd party\n\nA third party has the following NFT `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(222)TestToken` and they want to look up the royalties. The steps are\n\n1. Construct `royalty NFT` from `user token`: `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(500)Royalty`\n2. Look up `royalty NFT` and find the output it's locked in.\n3. Get the datum from the output and look up metadata by going into the first field of constructor 0.\n4. Convert to JSON and encode all string entries to UTF-8 if possible, otherwise leave them in hex.\n\n#### Retrieve metadata from a Plutus validator\n\nWe want to bring the royalty metadata of the NFT `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(222)TestToken` in the Plutus validator context. To do this we\n\n1. Construct `royalty NFT` from `user token`: `d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc.(500)Royalty` (off-chain)\n2. Look up `royalty NFT` and find the output it's locked in. (off-chain)\n3. Reference the output in the transaction. (off-chain)\n4. Verify validity of datum of the referenced output by checking if policy ID of `royalty NFT` and `user token` and their asset names without the `asset_name_label` prefix match. (on-chain)\n\n## Rationale: how does this CIP achieve its goals?\n\nThe specification here is made to be as minimal as possible. This is done with expediency in mind and the expectation that additional changes to the specification may be made in the future. The sooner we have a standard established, the sooner we can make use of it. Rather than attempting to anticipate all use cases, we specify with forward-compatibility in mind.\n\n### 500 Royalty Token Datum\n\nThis specification is largely based on [the royalty specification in Nebula](https://github.com/spacebudz/nebula/tree/main#royalty-info-specification), with a couple key departures:\n\n- The royalty token is recommended to be locked at a script address, rather than stored in the user's wallet. This encourages projects to guarantee royalties won't change by sending their royalties to an always-fails (or similar) script address, but still allows for creative royalty schemes and minimizes disruption to existing projects.\n\n- The policyId of the royalty NFT must match that of the reference NFT. This enables lookups based on the user token in the same way as is done for the tokens specified in the original CIP-68 standard.\n\n### Reference Datum Flag\n\nIn addition to providing a way to create guaranteed royalties, this has several advantages:\n\n- Backwards Compatibility - Existing royalty implementations will still work, just not have the same assurances.\n- Minimal Storage Requirement - An optional boolean has about the smallest memory impact possible. This is especially important because it's attached to the - Reference NFT and will be set for each individual NFT.\n- Intra-Collection Utility - This already allows for minting a collection with some NFTs with royalties and some without. A future version of this standard will likely make use of this field to allow for multiple versions of royalties for even more granular control.\n\n### Backward Compatibility\n\nTo keep metadata compatibility with changes coming in the future, we introduce a `version` field in the datum.\n## Extending & Modifying this CIP\nSee the [CIP-0068 Extension Boilerplate](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0068/extension_boilerplate.md)\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] This CIP should receive feedback, criticism, and refinement from: CIP Editors and the community of people involved with NFT projects to review any weaknesses or areas of improvement.\n- [x] Guidelines and examples of publication of data as well as discovery and validation should be included as part of of criteria for acceptance.\n- [x] Minimal reference implementation making use of [Lucid](https://github.com/spacebudz/lucid) (off-chain), [PlutusTx](https://github.com/input-output-hk/plutus) (on-chain): [Reference Implementation](https://github.com/SamDelaney/CIP_102_Reference).\n- [ ] Implementation and use demonstrated by the community: NFT Projects, Blockchain Explorers, Wallets, Marketplaces.\n\n### Implementation Plan\n\n- [x] Publish open source reference implementation and instructions related to the creation, storage and reading of royalty utxos.\n- [ ] Implement in open source libraries and tooling such as [Lucid](https://github.com/spacebudz/lucid), [Blockfrost](https://github.com/blockfrost/blockfrost-backend-ryo), etc.\n- [ ] Achieve additional \"buy in\" from existing community actors and implementors such as: blockchain explorers, token marketplaces, minting platforms, wallets.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[CIP-0027]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0027\n[CIP-0067]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0067\n[CIP-0068]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0068\n"
  },
  {
    "path": "CIP-0103/README.md",
    "content": "---\nCIP: 103\nTitle: Web-Wallet Bridge - Bulk transaction signing\nCategory: Wallets\nStatus: Active\nAuthors:\n    - Martín Schere\n    - Ola Ahlman <ola.ahlman@tastenkunst.io>\nImplementors: \n    - JPG Store <https://www.jpg.store>\n    - Eternl <https://eternl.io/>\n    - Typhon <https://typhonwallet.io/>\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/443\n    - https://github.com/cardano-foundation/CIPs/pull/587\nCreated: 2023-09-03\nLicense: CC-BY-4.0\n---\n\n## Abstract\nThis CIP extends [CIP-30 (Cardano dApp-Wallet Web Bridge)](https://cips.cardano.org/cips/cip30/) to provide an additional endpoint for dApp to sign multiple transactions in bulk.\n\n## Motivation: why is this CIP necessary?\nCurrently, there is no way to sign multiple transactions in bulk, and the experience of signing a chain of transactions is suboptimal. We propose the addition of a signTxs endpoint that enable wallets to create an array of interconnected transactions and sign them all at once.\n\n## Specification\n\n### Data Types\n#### TransactionSignatureRequest\n\n```ts\ntype TransactionSignatureRequest = {|\n  cbor: cbor<transaction>,\n  partialSign: bool = false,\n|};\n```\n\nUsed to represent a single transaction awaiting a user's signature. More details on {partialSign} can be found in [api.signTx](https://cips.cardano.org/cips/cip30/#apisigntxtxcbortransactionpartialsignboolfalsepromisecbortransactionwitnessset) defined in CIP-30.\n\n### Error Types\n\n#### APIError\nSee [CIP-30 (Cardano dApp-Wallet Web Bridge) APIError](https://cips.cardano.org/cips/cip30/#apierror)\n\n#### TxSignError\nSee [CIP-30 (Cardano dApp-Wallet Web Bridge) TxSignError](https://cips.cardano.org/cips/cip30/#txsignerror)\n\n#### TxSendError\nSee [CIP-30 (Cardano dApp-Wallet Web Bridge) TxSendError](https://cips.cardano.org/cips/cip30/#txsignerror)\n\n### `api.cip103.signTxs(txs: TransactionSignatureRequest[]): Promise<cbor<transaction_witness_set>[]>`\n\nErrors: `APIError`, `TxSignError`\n\nSigns a list of transactions where each transaction can either be independent and/or as a sequence of interconnected transactions where a subsequent transaction depends on a previous one. The returned array of witness sets directly correspond to the elements in the `txs` parameter, aligning the witness set at index 0 with the transaction at index 0, and so forth.\n\nOn sign error for any transaction in the array, no witnesses are to be returned. Instead a `TxSignError` is to be thrown. The error message thrown should include a reference to the transaction that caused the sign error, by including the index for failing transaction that map to the input array transaction list.\n\nThere are certain things that should be considered by wallets implementing this CIP, namely user visibility of what is signed. Though not explicitly specified in this CIP, as it would be up to the wallet to find a good solution, the wallet should make it clear to the user that multiple transactions are to be signed, and to give a clear overview/summary of what is signed. In addition to visibility, the wallet shall process the input transaction array in the same order as input parameter to allow transactions to be chained by accepting a previous transaction in the array to be used as input in a following transaction.\n\n### `api.cip103.submitTxs(txs: cbor<transaction>[]): Promise<hash32[]>`\n\nErrors: `APIError`, `TxSendError`\n\nExtends [CIP-30 (Cardano dApp-Wallet Web Bridge) submitTx](https://cips.cardano.org/cips/cip30/#apisubmittxtxcbortransactionpromisehash32) with the ability to submit transactions in bulk. Transactions are to be submitted in the same order as provided as inputs. All transactions provided as input should be attempted to be submitted even in case of error. If all transactions are successfully submitted, an array of transaction ids is to be returned. In the case of one or multiple `Refused | Failure`, a `TxSendError | hash32` array is thrown. Each entry in the array represents either a successful submit with `hash32` (transaction id), or in the case of `Refused | Failure`, a `TxSendError` object. In both cases, the response array directly corresponds to the elements in the `txs` parameter.\n\n### Versioning\nOnce approved and final, the proposal must be superseded by another if changes break the specification. Minor adjustments are allowed if needed to improve readability and resolve uncertainties. \n\n## Rationale: how does this CIP achieve its goals?\nAllowing for bulk signing and submission of transactions can greatly improve the user experience by reducing the amount of steps needed to sign more than one transaction. Allowing multiple transactions to be provided in the same API call also reduces the burden for transaction chaining that was previously mainly possible by keeping track of node mempool to know if input utxo's are available to be spent. Submitting multiple transactions would still be possible without `submitTxs` addition using the already defined [CIP-30 (Cardano dApp-Wallet Web Bridge) submitTx](https://cips.cardano.org/cips/cip30/#apisubmittxtxcbortransactionpromisehash32) endpoint by calling it multiple times. However, allowing a bulk submit endpoint speeds up submission when many transactions are to be submitted at once as you wouldn't have to await each individual submission. \n\n## Path to Active\n\n### Acceptance Criteria\nIn order for this standard to be active, the following should be true:\n- [x] Implemented by at least two wallets.\n- [x] Adopted and used by at least one dApp or infrastructure tool to prove usability.\n\n### Implementation Plan\nN/A\n\n## Copyright\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n\n"
  },
  {
    "path": "CIP-0104/README.md",
    "content": "---\nCIP: 104\nTitle: Web-Wallet Bridge - Account public key\nCategory: Wallets\nStatus: Proposed\nAuthors:\n    - Ola Ahlman <ola.ahlman@tastenkunst.io>\n    - Andrew Westberg <andrewwestberg@gmail.com>\nImplementors:\n- Eternl <https://eternl.io/>\n- newm-chain <https://newm.io/>\n- Gero <https://gerowallet.io/>\nDiscussions:\n    - https://github.com/cardano-foundation/cips/pulls/588\nCreated: 2023-09-03\nLicense: CC-BY-4.0\n---\n\n## Abstract\nThis CIP extends [CIP-30 (Cardano dApp-Wallet Web Bridge)](https://cips.cardano.org/cips/cip30/) to provide an additional endpoint for dApp to get the extended account public key from a connected wallet.\n\n## Motivation: why is this CIP necessary?\nNormally it's up to the wallet to handle the logic for utxo selection, derived addresses etc through the established CIP-30 api. Sometimes however, dApp needs greater control due to subpar utxo selection or other specific needs that can only be handled by chain lookup from derived address(es). This moves the control and complexity from wallet to dApp for those dApps that prefer this setup. A dApp has better control and can make a more uniform user experience. By exporting only the account public key, this gives read-only access to the dApp.\n\n## Specification\nA new endpoint is added namespaced according to this cip extension number that returns the connected account extended public key as [`cbor<T>`](https://cips.cardano.org/cips/cip30/#cbort) defined in CIP30.\n\n### 1. `api.cip104.getAccountPub(): Promise<cbor<Bip32PublicKey>>`\n\nErrors: APIError\n\nReturns hex-encoded string representing cbor of extended account public key. Throws APIError if needed as defined by CIP30.\n\nWallets implementing this CIP should, but not enforced, request additional access from the user to access this endpoint as it allows for complete read access to account history and derivation paths.\n\n## Rationale: how does this CIP achieve its goals?\nRaw cbor is returned instead of bech32 encoding to follow specification of other CIP30 endpoints.\n\n## Path to Active\n\n### Acceptance Criteria\nIn order for this standard to be active, the following should be true:\n - Implemented by at least two wallets.\n - Adopted and used by at least one dApp or infrastructure tool to prove usability.\n\n### Implementation Plan\nCommunication with additional wallets established to widen availability\n\n## Copyright\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n"
  },
  {
    "path": "CIP-0105/README.md",
    "content": "---\nCIP: 105\nTitle: Conway era Key Chains for HD Wallets\nStatus: Active\nCategory: Wallets\nAuthors:\n  - Ryan Williams <ryan.williams@intersectmbo.org>\nImplementors:\n  - Eternl <https://eternl.io/>\n  - Lace <https://www.lace.io/>\n  - Mesh <https://meshjs.dev/>\n  - NuFi <https://nu.fi/>\n  - Ryan Williams <ryan.williams@intersectmbo.org>\n  - Pawel Jakubas <pawel.jakubas-ext@cardanofoundation.org>\n  - Typhon <https://typhonwallet.io/>\n  - Vespr <https://vespr.xyz/>\n  - Yoroi <https://yoroi-wallet.com/>\n  - Gero <https://gerowallet.io/>\nDiscussions:\n  - https://github.com/cardano-foundation/cips/pulls/597\nCreated: 2023-09-22\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThe Conway Ledger era introduces many new features to Cardano, notably features to support community governance via CIP-1694.\nThis includes the introduction of the new first class credentials; `drep_credential`, `committee_cold_credential` and `committee_hot_credential`.\n\nWe propose a HD wallet key derivation paths for registered DReps and constitutional committee members to deterministically derive keys from which credentials can be generated.\nSuch keys are to be known as DRep keys, constitutional committee cold keys and constitutional committee hot keys.\nHere we define some accompanying tooling standards.\n\n> **Note** this proposal assumes knowledge of the Conway ledger design (see\n> [draft ledger specification](https://github.com/IntersectMBO/cardano-ledger/blob/d2d37f706b93ae9c63bff0ff3825d349d0bd15df/eras/conway/impl/cddl-files/conway.cddl))\n> and\n> [CIP-1694](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md).\n\n## Motivation: why is this CIP necessary?\n\nIn the Conway ledger era, DRep credentials allow registered DReps to be identified on-chain, in DRep registrations, retirements, votes, and in vote delegations from ada holders.\nWhilst constitutional committee members can be recognized by their cold credentials within update committee governance actions, authorize hot credential certificate and resign cold key certificates.\nConstitutional committee hot credential can be observed within the authorize hot key certificate and votes.\n\nCIP-1694 terms these DRep credentials as DRep IDs, which are either generated from blake2b-224 hash digests of Ed25519 public keys owned by the DRep, or are script hash-based.\nSimilarly, both the hot and cold credentials for constitutional committee members can be generated from public key digests or script hashes.\n\nThis CIP defines a standard way for wallets to derive DRep and constitutional committee keys.\n\nSince it is best practice to use a single cryptographic key for a single purpose, we opt to keep DRep and committee keys separate from other keys in Cardano.\n\nBy adding three paths to the [CIP-1852 | HD (Hierarchy for Deterministic) Wallets for Cardano](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852/README.md), we create an ecosystem standard for wallets to be able to derive DRep and constitutional committee keys.\nThis enables DRep and constitutional committee credential restorability from a wallet seed phrase.\n\nStakeholders for this proposal are wallets that follow the CIP-1852 standard and tool makers wishing to support DReps and or constitutional committee members.\nThis standard allows DReps and constitutional committee members to use alternative wallets whilst being able to be correctly identified.\nBy defining tooling standards, we enable greater interoperability between governance-focussed tools.\n\n## Specification\n\n### Derivation\n\n#### DRep Keys\n\nHere we describe DRep key derivation as it pertains to Cardano wallets that follow the CIP-1852 standard.\n\nTo differentiate DRep keys from other Cardano keys, we define a new `role` index of `3`:\n\n`m / 1852' / 1815' / account' / 3 / address_index`\n\nWe strongly recommend that a maximum of one set of DRep keys should be associated with one wallet account, which can be achieved by setting `address_index=0`.\n\n#### DRep ID\n\nTools and wallets can generate a DRep ID (`drep_credential`) from the Ed25519 public DRep key (without chaincode) by creating a blake2b-224 hash digest of the key.\nAs this is key-based credential it should be marked as entry `0` in a credential array. DRep Identifier is further specified in [CIP-0129](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0129/README.md).\n\n#### Constitutional Committee Cold Keys\n\nHere we describe constitutional committee cold key derivation as it pertains to Cardano wallets that follow the CIP-1852 standard.\n\nTo differentiate constitutional committee cold keys from other Cardano keys, we define a new `role` index of `4`:\n\n`m / 1852' / 1815' / account' / 4 / address_index`\n\nWe strongly recommend that a maximum of one set of constitutional committee cold keys should be associated with one wallet account, which can be achieved by setting `address_index=0`.\n\n#### Constitutional Committee Cold Credential\n\nTools and wallets can generate a constitutional committee cold credential (`committee_cold_credential`) from the Ed25519 public constitutional committee cold key (without chaincode) by creating a blake2b-224 hash digest of the key.\nAs this is key-based credential it should be marked as entry `0` in a credential array.\n\n#### Constitutional Committee Hot Keys\n\nHere we describe constitutional committee hot key derivation as it pertains to Cardano wallets that follow the CIP-1852 standard.\n\nTo differentiate constitutional committee hot keys from other Cardano keys, we define a new `role` index of `5`:\n\n`m / 1852' / 1815' / account' / 5 / address_index`\n\nWe strongly recommend that a maximum of one set of constitutional committee hot keys should be associated with one wallet account, which can be achieved by setting `address_index=0`.\n\n#### Constitutional Committee Hot Credential\n\nTools and wallets can generate a constitutional committee hot credential (`committee_hot_credential`) from the Ed25519 public constitutional committee hot key (without chaincode) by creating a blake2b-224 hash digest of the key.\nAs this is key-based credential it should be marked as entry `0` in a credential array.\n\n### Bech32 Encoding\n\nThese are also described in [CIP-0005 | Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0005/README.md), but we include them here for completeness.\n\n> **Note** we also include the prefixes for script-based credentials in the following subsections, for completeness.\n\n#### DRep Keys\n\nDRep keys and DRep IDs should be encoded in Bech32 with the following prefixes:\n\n| Prefix        | Meaning                                                 | Contents                                                           |\n| ------------- | --------------------------------------------------------| ------------------------------------------------------------------ |\n| `drep_sk`     | CIP-1852’s DRep signing key                             | Ed25519 private key                                                |\n| `drep_vk`     | CIP-1852’s DRep verification key                        | Ed25519 public key                                                 |\n| `drep_xsk`    | CIP-1852’s DRep extended signing key                    | Ed25519-bip32 extended private key                                 |\n| `drep_xvk`    | CIP-1852’s DRep extended verification key               | Ed25519 public key with chain code                                 |\n| `drep`        | [DEPRECATED] DRep verification key hash (DRep ID)       | blake2b\\_224 digest of a delegate representative verification key  |\n| `drep_vkh`    | Delegate representative verification key hash           | blake2b\\_224 digest of a delegate representative verification key  |\n| `drep_script` | Delegate representative script hash                     | blake2b\\_224 digest of a serialized delegate representative script |\n\n#### Constitutional Committee Cold Keys\n\nConstitutional cold keys and credential should be encoded in Bech32 with the following prefixes:\n\n| Prefix           | Meaning                                                               | Contents                                                               |\n| ---------------- | --------------------------------------------------------------------- | ---------------------------------------------------------------------  |\n| `cc_cold_sk`     | CIP-1852’s constitutional committee cold signing key                  | Ed25519 private key                                                    |\n| `cc_cold_vk`     | CIP-1852’s constitutional committee verification signing key          | Ed25519 private key                                                    |\n| `cc_cold_xsk`    | CIP-1852’s constitutional committee cold extended signing key         | Ed25519-bip32 extended private key                                     |\n| `cc_cold_xvk`    | CIP-1852’s constitutional committee extended verification signing key | Ed25519 public key with chain code                                     |\n| `cc_cold`        | [DEPRECATED] Constitutional committee cold verification key hash (cold credential) | blake2b\\_224 digest of a consitutional committee cold verification key |\n| `cc_cold_vkh`    | Constitutional committee cold verification key hash (cold credential) | blake2b\\_224 digest of a consitutional committee cold verification key |\n| `cc_cold_script` | Constitutional committee cold script hash (cold credential)           | blake2b\\_224 digest of a serialized constitutional committee cold script |\n\n#### Constitutional Committee Hot Keys\n\nConstitutional hot keys and credential should be encoded in Bech32 with the following prefixes:\n\n| Prefix          | Meaning                                                               | Contents                                                              |\n| --------------- | --------------------------------------------------------------------- | --------------------------------------------------------------------- |\n| `cc_hot_sk`     | CIP-1852’s constitutional committee hot signing key                   | Ed25519 private key                                                   |\n| `cc_hot_vk`     | CIP-1852’s constitutional committee verification signing key          | Ed25519 private key                                                   |\n| `cc_hot_xsk`    | CIP-1852’s constitutional committee hot extended signing key          | Ed25519-bip32 extended private key                                    |\n| `cc_hot_xvk`    | CIP-1852’s constitutional committee extended verification signing key | Ed25519 public key with chain code                                    |\n| `cc_hot`        | [DEPRECATED] Constitutional committee hot verification key hash (hot credential) | blake2b\\_224 digest of a consitutional committee hot verification key |\n| `cc_hot_vkh`    | Constitutional committee hot verification key hash (hot credential)   | blake2b\\_224 digest of a consitutional committee hot verification key |\n| `cc_hot_script` | Constitutional committee hot script hash (hot credential)             | blake2b\\_224 digest of a serialized constitutional committee hot script |\n\n### Tooling Definitions\n\n#### DRep Keys\n\nSupporting tooling should clearly label these key pairs as \"DRep Keys\".\n\nExamples of acceptable `keyType`s for supporting tools:\n\n| `keyType`                                   | Description                                       |\n| ------------------------------------------- | ------------------------------------------------- |\n| `DRepSigningKey_ed25519`                    | Delegate Representative Signing Key               |\n| `DRepExtendedSigningKey_ed25519_bip32`      | Delegate Representative Extended Signing Key      |\n| `DRepVerificationKey_ed25519`               | Delegate Representative Verification Key          |\n| `DRepExtendedVerificationKey_ed25519_bip32` | Delegate Representative Extended Verification Key |\n\nFor hardware implementations:\n\n| `keyType`                     | Description                                       |\n| ----------------------------- | ------------------------------------------------- |\n| `DRepHWSigningFile_ed25519`   | Hardware Delegate Representative Signing File     |\n| `DRepVerificationKey_ed25519` | Hardware Delegate Representative Verification Key |\n\n#### Constitutional Committee Cold Keys\n\nSupporting tooling should clearly label these key pairs as \"Constitutional Committee Cold Keys\".\n\nExamples of acceptable `keyType`s for supporting tools:\n\n| `keyType`                                                          | Description                                             |\n| ------------------------------------------------------------------ | ------------------------------------------------------- |\n| `ConstitutionalCommitteeColdSigningKey_ed25519`                    | Constitutional Committee Cold Signing Key               |\n| `ConstitutionalCommitteeColdExtendedSigningKey_ed25519_bip32`      | Constitutional Committee Cold Extended Signing Key      |\n| `ConstitutionalCommitteeColdVerificationKey_ed25519`               | Constitutional Committee Cold Verification Key          |\n| `ConstitutionalCommitteeColdExtendedVerificationKey_ed25519_bip32` | Constitutional Committee Cold Extended Verification Key |\n\nFor hardware implementations:\n\n| `keyType`                                            | Description                                             |\n| ---------------------------------------------------- | ------------------------------------------------------- |\n| `ConstitutionalCommitteeColdHWSigningFile_ed25519`   | Hardware Constitutional Committee Cold Signing File     |\n| `ConstitutionalCommitteeColdVerificationKey_ed25519` | Hardware Constitutional Committee Cold Verification Key |\n\n#### Constitutional Committee Hot Keys\n\nSupporting tooling should clearly label these key pairs as \"Constitutional Committee Hot Keys\".\n\n| `keyType`                                                         | Description                                            |\n| ----------------------------------------------------------------- | ------------------------------------------------------ |\n| `ConstitutionalCommitteeHotSigningKey_ed25519`                    | Constitutional Committee Hot Signing Key               |\n| `ConstitutionalCommitteeHotExtendedSigningKey_ed25519_bip32`      | Constitutional Committee Hot Extended Signing Key      |\n| `ConstitutionalCommitteeHotVerificationKey_ed25519`               | Constitutional Committee Hot Verification Key          |\n| `ConstitutionalCommitteeHotExtendedVerificationKey_ed25519_bip32` | Constitutional Committee Hot Extended Verification Key |\n\nFor hardware implementations:\n\n| `keyType`                                           | Description                                            |\n| --------------------------------------------------- | ------------------------------------------------------ |\n| `ConstitutionalCommitteeHotHWSigningFile_ed25519`   | Hardware Constitutional Committee Hot Signing File     |\n| `ConstitutionalCommitteeHotVerificationKey_ed25519` | Hardware Constitutional Committee Hot Verification Key |\n\n### Deprecated Governance ID Definition\nThe previous governance key IDs defined by this standard have been superseded by the definitions provided in [CIP-0129]. Tools implementing this standard are encouraged to consider adopting [CIP-0129]. Tools that already support [CIP-0129] maintain backward compatibility with the legacy formats specified below but should consider fully transitioning to [CIP-0129] to standardize key formats across the ecosystem. This will help avoid multiple formats and ensure consistency.\n\nThis CIP previously also lacked `_vkh` key definitions, which are now added above possible due to the upgrades defined in [CIP-0129]. For detailed information on the new specification and the rationale behind the upgrade, please refer to [CIP-0129].\n\n#### DRep Keys\n\n| Prefix          | Meaning                                                               | Contents                                                              |\n| --------------- | --------------------------------------------------------------------- | --------------------------------------------------------------------- |\n| `drep`        | Delegate representative verification key hash (DRep ID) | blake2b\\_224 digest of a delegate representative verification key  |\n| `drep_script` | Delegate representative script hash (DRep ID)           | blake2b\\_224 digest of a serialized delegate representative script |\n\n#### Constitutional Committee Cold Keys\n\n| Prefix          | Meaning                                                               | Contents                                                              |\n| --------------- | --------------------------------------------------------------------- | --------------------------------------------------------------------- |\n| `cc_cold`        | Constitutional committee cold verification key hash (cold credential) | blake2b\\_224 digest of a consitutional committee cold verification key   |\n| `cc_cold_script` | Constitutional committee cold script hash (cold credential)           | blake2b\\_224 digest of a serialized constitutional committee cold script |\n\n#### Constitutional Committee Hot Keys\n\n| Prefix          | Meaning                                                               | Contents                                                              |\n| --------------- | --------------------------------------------------------------------- | --------------------------------------------------------------------- |\n| `cc_hot`        | Constitutional committee hot verification key hash (hot credential) | blake2b\\_224 digest of a consitutional committee hot verification key   |\n| `cc_hot_script` | Constitutional committee hot script hash (hot credential)           | blake2b\\_224 digest of a serialized constitutional committee hot script |\n\n### Versioning\n\nThis CIP is not to be versioned using a traditional scheme, rather if any large technical changes are required then a new proposal must replace this one.\nSmall changes can be made if they are completely backwards compatible with implementations, but this should be avoided.\n\n## Rationale: how does this CIP achieve its goals?\n\n### Derivation\n\nBy standardizing derivation, naming, and tooling conventions we primarily aim to enable wallet interoperability.\nBy having a standard to generate DRep and constitutional committee credentials from mnemonics, we allow wallets to always be able to discover a user’s governance activities.\n\n#### Why add a new roles to the 1852 path?\n\nThis approach mirrors how stake keys were rolled out, see [CIP-0011 | Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0011/README.md).\nWe deem this necessary since these credentials sit alongside each other in the Conway ledger design.\n\nThe alternative would be to define a completely different derivation paths, using a different index in the purpose field, similar to the specification outlined within [CIP-0036](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0036/README.md#derivation-path), but this could introduce complications with HW wallet implementations.\n\n#### Why not multi-DRep/CC wallet accounts?\n\nWe believe the overhead that would be introduced by multi-DRep accounts or multi-constitutional-committee is an unjustified expense.\nFuture iterations of this specification may expand on this, but at present this is seen as unnecessary.\nThis avoids the need for DRep, cc hot or cc cold key discovery.\n\nWe model this on how stake keys are generally handled by wallets.\nIf required, another CIP could, of course, introduce a multi-DRep/CC method.\n\n### Encoding\n\n#### Why not allow network tags?\n\nFor simplicity, we have omitted network tags within the encoding.\nThis is because we have modeled DRep IDs and CC credentials on stake pool operator IDs, which similarly do not include a network tag.\n\nThe advantage of including a network tag would be to reduce the likelihood of mislabelling a DRep’s network of operation (eg Preview v Cardano mainnet).\n\n### Test vectors\n\nSee [Test Vectors File](./test-vectors.md).\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] The DRep derivation path is used by three wallet/tooling implementations.\n  - [Nufi](https://assets.nu.fi/extension/sanchonet/nufi-cwe-sanchonet-latest.zip)\n  - [Lace](https://chromewebstore.google.com/detail/lace-sanchonet/djcdfchkaijggdjokfomholkalbffgil?hl=en)\n  - [Yoroi](https://chrome.google.com/webstore/detail/yoroi-nightly/poonlenmfdfbjfeeballhiibknlknepo/related)\n  - [demos wallet](https://github.com/Ryun1/cip95-demos-wallet)\n- [x] The constitutional committee derivation paths are used by two implementations.\n  - [csl-examples](https://github.com/Ryun1/csl-examples/)\n  - [cardano-addresses](https://github.com/IntersectMBO/cardano-addresses/)\n\n### Implementation Plan\n\n- [x] Author to provide an example implementation inside a HD wallet.\n  - [csl-examples/cip-1852-keys.js](https://github.com/Ryun1/csl-examples/blob/main/examples/CIP-1852/cip-1852-keys.js)\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[CIP-0129]: (https://github.com/cardano-foundation/CIPs/blob/master/CIP-0129/README.md)\n[DEPRECATED]: #deprecated-governance-id-definition\n"
  },
  {
    "path": "CIP-0105/test-vectors/test-vector-1.md",
    "content": "## Test vector 1\n\nTwelve word mnemonic, with account index of zero.\n\n**Mnemonic:** `test walk nut penalty hip pave soap entry language right filter choice`\n\n**Account index:** `0x80000000`\n\n#### Scripts\n\nScripts were constructed according to the following native script templates:\n\n**Script 1:** `all [$vKeyhash, active_from 5001]`\n\n**Script 2:** `any [$vKeyhash, all [active_from 5001, active_until 6001]]`\n\nWhere `$vKeyhash` is the Verification key hash aka `{drep_vkh1... | cc_cold_vkh1... | cc_hot_vkh1...}`.\n\n### DRep Keys\n\n#### DRep signing key\n\nHex: `a8e57a8e0a68b7ab50c6cd13e8e0811718f506d34fca674e12740fdf73e1a45e612fa30b7e4bbe9883958dcf365de1e6c1607c33172c5d3d7754f3294e450925`\n\nBech32: `drep_sk14rjh4rs2dzm6k5xxe5f73cypzuv02pknfl9xwnsjws8a7ulp530xztarpdlyh05csw2cmnekths7dstq0se3wtza84m4fueffezsjfglsqmad`\n\n#### DRep verification key\n\nHex: `f74d7ac30513ac1825715fd0196769761fca6e7f69de33d04ef09a0c417a752b`\n\nBech32: `drep_vk17axh4sc9zwkpsft3tlgpjemfwc0u5mnld80r85zw7zdqcst6w54sdv4a4e`\n\n#### DRep extended signing key\n\nHex: `a8e57a8e0a68b7ab50c6cd13e8e0811718f506d34fca674e12740fdf73e1a45e612fa30b7e4bbe9883958dcf365de1e6c1607c33172c5d3d7754f3294e4509251d8411029969123371cde99fb075730f1da4fd41ee7acefba7e211f0e20c91ca`\n\nBech32: `drep_xsk14rjh4rs2dzm6k5xxe5f73cypzuv02pknfl9xwnsjws8a7ulp530xztarpdlyh05csw2cmnekths7dstq0se3wtza84m4fueffezsjfgassgs9xtfzgehrn0fn7c82uc0rkj06s0w0t80hflzz8cwyry3eg9066uj`\n\n#### DRep extended verification key\n\nHex: `f74d7ac30513ac1825715fd0196769761fca6e7f69de33d04ef09a0c417a752b1d8411029969123371cde99fb075730f1da4fd41ee7acefba7e211f0e20c91ca`\n\nBech32: `drep_xvk17axh4sc9zwkpsft3tlgpjemfwc0u5mnld80r85zw7zdqcst6w543mpq3q2vkjy3nw8x7n8asw4es78dyl4q7u7kwlwn7yy0sugxfrjs6z25qe`\n\n#### [DEPRECATED] Verification key hash (DRep ID)\n\nHex: `a5b45515a3ff8cb7c02ce351834da324eb6dfc41b5779cb5e6b832aa`\n\nBech32: `drep15k6929drl7xt0spvudgcxndryn4kmlzpk4meed0xhqe25nle07s`\n\n#### Verification key hash (DRep VKH)\n\nHex: `a5b45515a3ff8cb7c02ce351834da324eb6dfc41b5779cb5e6b832aa`\n\nBech32: `drep_vkh15k6929drl7xt0spvudgcxndryn4kmlzpk4meed0xhqe254czjh2`\n\n#### [CIP-0129 compliant] Verification key hash appended with  '22' hex-encoded byte (DRep key hash credential)\n\nHex: `22a5b45515a3ff8cb7c02ce351834da324eb6dfc41b5779cb5e6b832aa`\n\nBech32: `drep1y2jmg4g450lced7q9n34rq6d5vjwkm0ugx6h0894u6ur92s9txn3a`\n\n#### Script 1 hash (DRep Script Hash)\n\nHex: `d0657126dbf0c135a7224d91ca068f5bf769af6d1f1df0bce5170ec5`\n\nBech32: `drep_script16pjhzfkm7rqntfezfkgu5p50t0mkntmdruwlp089zu8v29l95rg`\n\n#### [CIP-0129] Script 1 hash appended with '23' hex-encoded byte (DRep script hash credential)\n\nHex: `23d0657126dbf0c135a7224d91ca068f5bf769af6d1f1df0bce5170ec5`\n\nBech32: `drep1y0gx2ufxm0cvzdd8yfxerjsx3adlw6d0d503mu9uu5tsa3gtkvwpe`\n\n#### Script 2 hash (DRep Script Hash)\n\nHex: `ae5acf0511255d647c84b3184a2d522bf5f6c5b76b989f49bd383bdd`\n\nBech32: `drep_script14edv7pg3y4wkglyykvvy5t2j906ld3dhdwvf7jda8qaa63d5kf4`\n\n#### [CIP-0129] Script 2 hash appended with '23' hex-encoded byte (DRep script hash credential)\n\nHex: `23ae5acf0511255d647c84b3184a2d522bf5f6c5b76b989f49bd383bdd`\n\nBech32: `drep1ywh94nc9zyj46erusje3sj3d2g4ltak9ka4e386fh5urhhga37qxs`\n\n\n### Constitutional Committee Cold\n\n#### Constitutional Committee Signing Key\n\nHex: `684f5b480507755f387e7e544cb44b3e55eb3b88b9f6976bd41e5f746ce1a45e28b4aa8bf129088417c0fade65a98a056cbcda96c0a8874cfcbef0bf53932a12`\n\nBech32: `cc_cold_sk1dp84kjq9qa647wr70e2yedzt8e27kwugh8mfw675re0hgm8p530z3d9230cjjzyyzlq04hn94x9q2m9um2tvp2y8fn7tau9l2wfj5yslmdl88`\n\n#### Constitutional Committee Cold Verification Key\n\nHex: `a9781abfc1604a18ebff6fc35062c000a7a66fdca1323710ed38c1dfc3315bea`\n\nBech32: `cc_cold_vk149up407pvp9p36lldlp4qckqqzn6vm7u5yerwy8d8rqalse3t04q7qsvwl`\n\n#### Constitutional Committee Extended Cold Signing Key\n\nHex: `684f5b480507755f387e7e544cb44b3e55eb3b88b9f6976bd41e5f746ce1a45e28b4aa8bf129088417c0fade65a98a056cbcda96c0a8874cfcbef0bf53932a12c601968e75ff3052ffa675aedaaea49ff36cb23036df105e28e1d32b4527e6cf`\n\nBech32: `cc_cold_xsk1dp84kjq9qa647wr70e2yedzt8e27kwugh8mfw675re0hgm8p530z3d9230cjjzyyzlq04hn94x9q2m9um2tvp2y8fn7tau9l2wfj5ykxqxtgua0lxpf0lfn44md2afyl7dktyvpkmug9u28p6v452flxeuca0v7w`\n\n#### Constitutional Committee Cold Extended Verification Key\n\nHex: `a9781abfc1604a18ebff6fc35062c000a7a66fdca1323710ed38c1dfc3315beac601968e75ff3052ffa675aedaaea49ff36cb23036df105e28e1d32b4527e6cf`\n\nBech32: `cc_cold_xvk149up407pvp9p36lldlp4qckqqzn6vm7u5yerwy8d8rqalse3t04vvqvk3e6l7vzjl7n8ttk646jflumvkgcrdhcstc5wr5etg5n7dnc8nqv5d`\n\n#### [DEPRECATED] Constitutional Committee Cold Verification Key Hash\n\nHex: `fefb9596ed670ad2c9978d78fe4eb36ba24cbba0a62fa4cdd0c2dcf5`\n\nBech32: `cc_cold1lmaet9hdvu9d9jvh34u0un4ndw3yewaq5ch6fnwsctw02xxwylj`\n\n#### Constitutional Committee Cold Verification key hash (Constitutional Committee Cold VKH)\n\nHex: `fefb9596ed670ad2c9978d78fe4eb36ba24cbba0a62fa4cdd0c2dcf5`\n\nBech32: `cc_cold_vkh1lmaet9hdvu9d9jvh34u0un4ndw3yewaq5ch6fnwsctw0243cw47`\n\n#### [CIP-0129 compliant] Constitutional Committee Cold Verification key hash appended with  '12' hex-encoded byte (Constitutional Committee Cold key hash credential)\n\nHex: `12fefb9596ed670ad2c9978d78fe4eb36ba24cbba0a62fa4cdd0c2dcf5`\n\nBech32: `cc_cold1ztl0h9vka4ns45kfj7xh3ljwkd46yn9m5znzlfxd6rpdeagw6p59q`\n\n#### Constitutional Committee Cold Script 1 Hash\n\nHex: `ae6f2a27554d5e6971ef3e933e4f0be7ed7aeb60f6f93dfb81cd6e1c`\n\nBech32: `cc_cold_script14ehj5f64f40xju0086fnunctulkh46mq7munm7upe4hpcwpcatv`\n\n#### [CIP-0129] Constitutional Committee Cold Script 1 hash appended with '13' hex-encoded byte (Constitutional Committee Cold script hash credential)\n\nHex: `13ae6f2a27554d5e6971ef3e933e4f0be7ed7aeb60f6f93dfb81cd6e1c`\n\nBech32: `cc_cold1zwhx723824x4u6t3aulfx0j0p0n767htvrm0j00ms8xku8q30p2xd`\n\n#### Constitutional Committee Cold Script 2 Hash\n\nHex: `119c20cecfedfdba057292f76bb110afa3ab472f9c35a85daf492316`\n\nBech32: `cc_cold_script1zxwzpnk0ah7m5ptjjtmkhvgs4736k3e0ns66shd0fy33vdauq3j`\n\n#### [CIP-0129] Constitutional Committee Cold Script 2 hash appended with '13' hex-encoded byte (Constitutional Committee Cold script hash credential)\n\nHex: `13119c20cecfedfdba057292f76bb110afa3ab472f9c35a85daf492316`\n\nBech32: `cc_cold1zvgecgxwelklmws9w2f0w6a3zzh6826897wrt2za4ayjx9swtgkr6`\n\n\n### Constitutional Committee Hot\n\n#### Constitutional Committee Hot Signing Key\n\nHex: `d85717921e6289606e15c1e2ee65b3bd6ec247e357889ba16178eedb74e1a45ef955aa17bd002971b05e750048b766eb6df4d855c54dd2ec7ad8850e2fe35ebe`\n\nBech32: `cc_hot_sk1mpt30ys7v2ykqms4c83wuednh4hvy3lr27yfhgtp0rhdka8p5300j4d2z77sq2t3kp082qzgkanwkm05mp2u2nwja3ad3pgw9l34a0sdh7u7e`\n\n#### Constitutional Committee Hot Verification Key\n\nHex: `792a7f83cab90261f72ef57ee94a65ca9b0c71c1be2c8fdd5318c3643b20b52f`\n\nBech32: `cc_hot_vk10y48lq72hypxraew74lwjjn9e2dscuwphckglh2nrrpkgweqk5hschnzv5`\n\n#### Constitutional Committee Hot Extended Signing Key\n\nHex: `d85717921e6289606e15c1e2ee65b3bd6ec247e357889ba16178eedb74e1a45ef955aa17bd002971b05e750048b766eb6df4d855c54dd2ec7ad8850e2fe35ebe5487e846e9a708b27681d6835fa2dac968108b3c845e379597491e6b476aa0b2`\n\nBech32: `cc_hot_xsk1mpt30ys7v2ykqms4c83wuednh4hvy3lr27yfhgtp0rhdka8p5300j4d2z77sq2t3kp082qzgkanwkm05mp2u2nwja3ad3pgw9l34a0j5sl5yd6d8pze8dqwksd069kkfdqggk0yytcmet96fre45w64qkgyxl0dt`\n\n#### Constitutional Committee Hot Extended Verification Key\n\nHex: `792a7f83cab90261f72ef57ee94a65ca9b0c71c1be2c8fdd5318c3643b20b52f5487e846e9a708b27681d6835fa2dac968108b3c845e379597491e6b476aa0b2`\n\nBech32: `cc_hot_xvk10y48lq72hypxraew74lwjjn9e2dscuwphckglh2nrrpkgweqk5h4fplggm56wz9jw6qadq6l5tdvj6qs3v7ggh3hjkt5j8ntga42pvs5rvh0a`\n\n#### [DEPRECATED] Constitutional Committee Hot Verification Key Hash\n\nHex: `f6d29c0f7164d37610cbf67b126a993beb24a076d0653f1fa069588f`\n\nBech32: `cc_hot17mffcrm3vnfhvyxt7ea3y65e804jfgrk6pjn78aqd9vg7xpq8dv`\n\n#### Constitutional Committee Hot Verification key hash (Constitutional Committee Hot VKH)\n\nHex: `f6d29c0f7164d37610cbf67b126a993beb24a076d0653f1fa069588f`\n\nBech32: `cc_hot_vkh17mffcrm3vnfhvyxt7ea3y65e804jfgrk6pjn78aqd9vg7vk5akz`\n\n#### [CIP-0129 compliant] Constitutional Committee Hot Verification key hash appended with  '02' hex-encoded byte (Constitutional Committee Hot key hash credential)\n\nHex: `02f6d29c0f7164d37610cbf67b126a993beb24a076d0653f1fa069588f`\n\nBech32: `cc_hot1qtmd98q0w9jdxasse0m8kyn2nya7kf9qwmgx20cl5p543rcdtr4dz`\n\n#### Constitutional Committee Hot Script 1 Hash\n\nHex: `d27a4229c92ec8961b6bfd32a87380dcee4a08c77b0d6c8b33f180e8`\n\nBech32: `cc_hot_script16fayy2wf9myfvxmtl5e2suuqmnhy5zx80vxkezen7xqwskncf40`\n\n#### [CIP-0129] Constitutional Committee Hot Script 1 hash appended with '03' hex-encoded byte (Constitutional Committee Hot script hash credential)\n\nHex: `03d27a4229c92ec8961b6bfd32a87380dcee4a08c77b0d6c8b33f180e8`\n\nBech32: `cc_hot1q0f85s3feyhv39smd07n92rnsrwwujsgcaas6mytx0ccp6q7ak53g`\n\n#### Constitutional Committee Hot Script 2 Hash\n\nHex: `62e0798c7036ff35862cf42f4e7ada06f7fb5b6465390082a691be14`\n\nBech32: `cc_hot_script1vts8nrrsxmlntp3v7sh5u7k6qmmlkkmyv5uspq4xjxlpg6u229p`\n\n#### [CIP-0129] Constitutional Committee Hot Script 2 hash appended with '03' hex-encoded byte (Constitutional Committee Hot script hash credential)\n\nHex: `0362e0798c7036ff35862cf42f4e7ada06f7fb5b6465390082a691be14`\n\nBech32: `cc_hot1qd3wq7vvwqm07dvx9n6z7nn6mgr0076mv3jnjqyz56gmu9qaj7nrc`\n"
  },
  {
    "path": "CIP-0105/test-vectors/test-vector-2.md",
    "content": "\n## Test vector 2\n\n**Mnemonic:** `test walk nut penalty hip pave soap entry language right filter choice`\n\n**Account index:** `0x80000100`\n\n#### Scripts\n\nScripts were constructed according to the following native script templates:\n\n**Script 1:** `all [$vKeyhash, active_from 5001]`\n\n**Script 2:** `any [$vKeyhash, all [active_from 5001, active_until 6001]]`\n\nWhere `$vKeyhash` is the Verification key hash aka `{drep_vkh1... | cc_cold_vkh1... | cc_hot_vkh1...}`.\n\n### DRep Keys\n\n#### DRep signing key\n\nHex: `10fb8436bb02e2a4d3127860f771a9f1f9aff362f202346e3238b38a76e1a45eec82a22f492d48528c7e191f52b59489adf383db4811cbce4c6cdd8cef91c408`\n\nBech32: `drep_sk1zracgd4mqt32f5cj0ps0wudf78u6lumz7gprgm3j8zec5ahp530weq4z9ayj6jzj33lpj86jkk2gnt0ns0d5sywteexxehvva7gugzqjur0zk`\n\n#### DRep verification key\n\nHex: `70344fe0329bbacbb33921e945daed181bd66889333eb73f3bb10ad8e4669976`\n\nBech32: `drep_vk1wq6ylcpjnwavhveey855tkhdrqdav6yfxvltw0emky9d3erxn9mqdrlerg`\n\n#### DRep extended signing key\n\nHex: `10fb8436bb02e2a4d3127860f771a9f1f9aff362f202346e3238b38a76e1a45eec82a22f492d48528c7e191f52b59489adf383db4811cbce4c6cdd8cef91c408a523761cec4182672a9592638e7017aa82ae6c1508377f4068d000a8cef56a30`\n\nBech32: `drep_xsk1zracgd4mqt32f5cj0ps0wudf78u6lumz7gprgm3j8zec5ahp530weq4z9ayj6jzj33lpj86jkk2gnt0ns0d5sywteexxehvva7gugz99ydmpemzpsfnj49vjvw88q9a2s2hxc9ggxal5q6xsqz5vaat2xqsha72w`\n\n#### DRep extended verification key\n\nHex: `70344fe0329bbacbb33921e945daed181bd66889333eb73f3bb10ad8e4669976a523761cec4182672a9592638e7017aa82ae6c1508377f4068d000a8cef56a30`\n\nBech32: `drep_xvk1wq6ylcpjnwavhveey855tkhdrqdav6yfxvltw0emky9d3erxn9m22gmkrnkyrqn8922eycuwwqt64q4wds2ssdmlgp5dqq9gem6k5vq23ph3c`\n\n#### [DEPRECATED] Verification key hash (DRep ID)\n\nHex: `1ed314af7d3ff8fcd320c73eb58524d774ca38733ee00ebca81bd63a`\n\nBech32: `drep1rmf3ftma8lu0e5eqculttpfy6a6v5wrn8msqa09gr0tr5rgcuy9`\n\n#### Verification key hash (DRep VKH)\n\nHex: `1ed314af7d3ff8fcd320c73eb58524d774ca38733ee00ebca81bd63a`\n\nBech32: `drep_vkh1rmf3ftma8lu0e5eqculttpfy6a6v5wrn8msqa09gr0tr590rpdl`\n\n#### [CIP-0129 compliant] Verification key hash appended with  '22' hex-encoded byte (DRep key hash credential)\n\nHex: `221ed314af7d3ff8fcd320c73eb58524d774ca38733ee00ebca81bd63a`\n\nBech32: `drep1yg0dx99005ll3lxnyrrnadv9ynthfj3cwvlwqr4u4qdavwshx0yl0`\n\n#### Script 1 hash (DRep Script Hash)\n\nHex: `3e11f3d9b39639fbb9d59c6efec7b7c1e9dbcb104523c7a4b194c45c`\n\nBech32: `drep_script18cgl8kdnjculhww4n3h0a3ahc85ahjcsg53u0f93jnz9c0339av`\n\n#### [CIP-0129] Script 1 hash appended with '23' hex-encoded byte (DRep script hash credential)\n\nHex: `233e11f3d9b39639fbb9d59c6efec7b7c1e9dbcb104523c7a4b194c45c`\n\nBech32: `drep1yvlpru7ekwtrn7ae6kwxalk8klq7nk7tzpzj83aykx2vghq0nyenc`\n\n#### Script 2 hash (DRep Script Hash)\n\nHex: `bba45271823634a8ba9fdb981ad76df02cd2384a4e1b43c41b2734a9`\n\nBech32: `drep_script1hwj9yuvzxc623w5lmwvp44md7qkdywz2fcd583qmyu62jvjnz69`\n\n#### [CIP-0129] Script 2 hash appended with '23' hex-encoded byte (DRep script hash credential)\n\nHex: `23bba45271823634a8ba9fdb981ad76df02cd2384a4e1b43c41b2734a9`\n\nBech32: `drep1ywa6g5n3sgmrf296nldesxkhdhcze53cff8pks7yrvnnf2g5w625r`\n\n\n### Constitutional Committee Cold\n\n#### Constitutional Committee Cold Signing Key\n\nHex: `684261ca0130e52a66861eefa275da745fd1c3f4f83100bca49904e773e1a45e0aafece23c531b52ec7915278591087a87591cb62ee96e1f716d96c9834388f4`\n\nBech32: `cc_cold_sk1dppxrjspxrjj5e5xrmh6yaw6w30arsl5lqcsp09ynyzwwulp530q4tlvug79xx6ja3u32fu9jyy84p6erjmza6twrackm9kfsdpc3aqr79jja`\n\n#### Constitutional Committee Cold Verification Key\n\nHex: `cab60e3b880ba64b252b942bb645d5e58ef4d6f243542fc28ce4051170171f91`\n\nBech32: `cc_cold_vk1e2mquwugpwnykfftjs4mv3w4uk80f4hjgd2zls5vusz3zuqhr7gs3qg4hr`\n\n#### Constitutional Committee Cold Extended Signing Key\n\nHex: `684261ca0130e52a66861eefa275da745fd1c3f4f83100bca49904e773e1a45e0aafece23c531b52ec7915278591087a87591cb62ee96e1f716d96c9834388f43ee1839d84124acdea81c69ee7e6e828387e51067878f30cab414ec5f2e36b42`\n\nBech32: `cc_cold_xsk1dppxrjspxrjj5e5xrmh6yaw6w30arsl5lqcsp09ynyzwwulp530q4tlvug79xx6ja3u32fu9jyy84p6erjmza6twrackm9kfsdpc3ap7uxpempqjftx74qwxnmn7d6pg8pl9zpnc0rese26pfmzl9cmtgg8xsxvu`\n\n#### Constitutional Committee Cold Extended Verification Key\n\nHex: `cab60e3b880ba64b252b942bb645d5e58ef4d6f243542fc28ce4051170171f913ee1839d84124acdea81c69ee7e6e828387e51067878f30cab414ec5f2e36b42`\n\nBech32: `cc_cold_xvk1e2mquwugpwnykfftjs4mv3w4uk80f4hjgd2zls5vusz3zuqhr7gnacvrnkzpyjkda2qud8h8um5zswr72yr8s78npj45znk97t3kkssryhkyv`\n\n#### [DEPRECATED] Constitutional Committee Cold Verification Key Hash\n\nHex: `e93734fae718e91bbf45c86f8cd81e7f9687e6cffe4c910dd1a4c360`\n\nBech32: `cc_cold1aymnf7h8rr53h069ephcekq707tg0ek0lexfzrw35npkq02wke0`\n\n#### Constitutional Committee Cold Verification key hash (Constitutional Committee Cold VKH)\n\nHex: `e93734fae718e91bbf45c86f8cd81e7f9687e6cffe4c910dd1a4c360`\n\nBech32: `cc_cold_vkh1aymnf7h8rr53h069ephcekq707tg0ek0lexfzrw35npkquacunr`\n\n#### [CIP-0129 compliant] Constitutional Committee Cold Verification key hash appended with  '12' hex-encoded byte (Constitutional Committee Cold key hash credential)\n\nHex: `12e93734fae718e91bbf45c86f8cd81e7f9687e6cffe4c910dd1a4c360`\n\nBech32: `cc_cold1zt5nwd86uuvwjxalghyxlrxcreledplxellyeygd6xjvxcqy66a7t`\n\n#### Constitutional Committee Cold Script 1 Hash\n\nHex: `08d78337fcf51a2a9fe93dee7d21679a3c28948cd90184155040b3e4`\n\nBech32: `cc_cold_script1prtcxdlu75dz48lf8hh86gt8ng7z39yvmyqcg92sgze7g6m8dtq`\n\n#### [CIP-0129] Constitutional Committee Cold Script 1 hash appended with '13' hex-encoded byte (Constitutional Committee Cold script hash credential)\n\nHex: `1308d78337fcf51a2a9fe93dee7d21679a3c28948cd90184155040b3e4`\n\nBech32: `cc_cold1zvyd0qehln63525lay77ulfpv7drc2y53nvsrpq42pqt8eq6u9w33`\n\n#### Constitutional Committee Cold Script 2 Hash\n\nHex: `2e8b77ecaa9f003978dea86515cee6b97df4dff52298e60198d5b387`\n\nBech32: `cc_cold_script1969h0m92nuqrj7x74pj3tnhxh97lfhl4y2vwvqvc6kecwdshr6f`\n\n#### [CIP-0129] Constitutional Committee Cold Script 2 hash appended with '13' hex-encoded byte (Constitutional Committee Cold script hash credential)\n\nHex: `132e8b77ecaa9f003978dea86515cee6b97df4dff52298e60198d5b387`\n\nBech32: `cc_cold1zvhgkalv420sqwtcm65x29wwu6uhmaxl753f3espnr2m8pcul7pjs`\n\n\n### Constitutional Committee Hot\n\n#### Constitutional Committee Hot Signing Key\n\nHex: `a05672b82125c65c811ba4e7cf2e7d8b53b01baae5699aa3d618825e78e1a45e1c8a3ab1ec59bd0e79ef3d3466fb8c6823159433266aecc4ecdf21b111af0587`\n\nBech32: `cc_hot_sk15pt89wppyhr9eqgm5nnu7tna3dfmqxa2u45e4g7krzp9u78p530pez36k8k9n0gw08hn6drxlwxxsgc4jsejv6hvcnkd7gd3zxhstpc7gujxf`\n\n#### Constitutional Committee Hot Verification Key\n\nHex: `783ae09be2f648b59483a9bee5cace8d68c7e6e2819bfb5a1a00fbf204bea06e`\n\nBech32: `cc_hot_vk10qawpxlz7eytt9yr4xlwtjkw345v0ehzsxdlkks6qralyp975phqx538xn`\n\n#### Constitutional Committee Hot Extended Signing Key\n\nHex: `a05672b82125c65c811ba4e7cf2e7d8b53b01baae5699aa3d618825e78e1a45e1c8a3ab1ec59bd0e79ef3d3466fb8c6823159433266aecc4ecdf21b111af058731609b9d64a7103fa9ab1bcdadfdea2d2366b3be0268df7f68edc9b36f8d300e`\n\nBech32: `cc_hot_xsk15pt89wppyhr9eqgm5nnu7tna3dfmqxa2u45e4g7krzp9u78p530pez36k8k9n0gw08hn6drxlwxxsgc4jsejv6hvcnkd7gd3zxhstpe3vzde6e98zql6n2cmekklm63dydnt80szdr0h768dexeklrfspc5lznuz`\n\n#### Constitutional Committee Hot Extended Verification Key\n\nHex: `783ae09be2f648b59483a9bee5cace8d68c7e6e2819bfb5a1a00fbf204bea06e31609b9d64a7103fa9ab1bcdadfdea2d2366b3be0268df7f68edc9b36f8d300e`\n\nBech32: `cc_hot_xvk10qawpxlz7eytt9yr4xlwtjkw345v0ehzsxdlkks6qralyp975phrzcymn4j2wypl4x43hnddlh4z6gmxkwlqy6xl0a5wmjdnd7xnqrsvak8ry`\n\n#### [DEPRECATED] Constitutional Committee Hot Verification Key Hash\n\nHex: `d1d4ebdb19689e95e097919bd8712441e89b41ec36de47bf40344f85`\n\nBech32: `cc_hot1682whkcedz0ftcyhjxdasufyg85fks0vxm0y006qx38c2jz0ae0`\n\n#### Constitutional Committee Hot Verification key hash (Constitutional Committee Hot VKH)\n\nHex: `d1d4ebdb19689e95e097919bd8712441e89b41ec36de47bf40344f85`\n\nBech32: `cc_hot_vkh1682whkcedz0ftcyhjxdasufyg85fks0vxm0y006qx38c2c4m8zp`\n\n#### [CIP-0129 compliant] Constitutional Committee Hot Verification key hash appended with  '02' hex-encoded byte (Constitutional Committee Hot key hash credential)\n\nHex: `02d1d4ebdb19689e95e097919bd8712441e89b41ec36de47bf40344f85`\n\nBech32: `cc_hot1qtgaf67mr95fa90qj7gehkr3y3q73x6pasmdu3algq6ylpgfamj02`\n\n#### Constitutional Committee Hot Script 1 Hash\n\nHex: `bdf295c04cac9c78a69bca06cb8f2cffbee76d739759e80ec09a0655`\n\nBech32: `cc_hot_script1hheftszv4jw83f5megrvhrevl7lwwmtnjav7srkqngr92gna52t`\n\n#### [CIP-0129] Constitutional Committee Hot Script 1 hash appended with '03' hex-encoded byte (Constitutional Committee Hot script hash credential)\n\nHex: `03bdf295c04cac9c78a69bca06cb8f2cffbee76d739759e80ec09a0655`\n\nBech32: `cc_hot1qw7l99wqfjkfc79xn09qdju09nlmaemdwwt4n6qwczdqv4gs6fm6e`\n\n#### Constitutional Committee Hot Script 2 Hash\n\nHex: `6a0b26bbf030bb6c2c8e62b0ef77c84494d771e81517ccf1434d5e26`\n\nBech32: `cc_hot_script1dg9jdwlsxzakctywv2cw7a7ggj2dwu0gz5tueu2rf40zvkj8dwc`\n\n#### [CIP-0129] Constitutional Committee Hot Script 2 hash appended with '03' hex-encoded byte (Constitutional Committee Hot script hash credential)\n\nHex: `036a0b26bbf030bb6c2c8e62b0ef77c84494d771e81517ccf1434d5e26`\n\nBech32: `cc_hot1qd4qkf4m7qctkmpv3e3tpmmhepzff4m3aq230n83gdx4ufsalrf9f`\n"
  },
  {
    "path": "CIP-0105/test-vectors/test-vector-3.md",
    "content": "## Test vector 3\n\n**Mnemonic:** `excess behave track soul table wear ocean cash stay nature item turtle palm soccer lunch horror start stumble month panic right must lock dress`\n\n**Account index:** `0x80000000`\n\n#### Scripts\n\nScripts were constructed according to the following native script templates:\n\n**Script 1:** `all [$vKeyhash, active_from 5001]`\n\n**Script 2:** `any [$vKeyhash, all [active_from 5001, active_until 6001]]`\n\nWhere `$vKeyhash` is the Verification key hash aka `{drep_vkh1... | cc_cold_vkh1... | cc_hot_vkh1...}`.\n\n\n### DRep Keys\n\n#### DRep signing key\n\nHex: `f05d3d37c1e3dba82444812d45f786295345b410c2fc212ee8fc88da0a118f45993d7ba4c9eb43935dc1c3d56041e2adb74c846fb8955d438d1ef2ec2496230d`\n\nBech32: `drep_sk17pwn6d7pu0d6sfzysyk5taux99f5tdqsct7zzthgljyd5zs33azej0tm5ny7ksunthqu84tqg832md6vs3hm392agwx3auhvyjtzxrgwyexuy`\n\n#### DRep verification key\n\nHex: `a4a2f459fcc98e7fe0acbea096f4b1fb342cb73aa6c41f62d4d6ca1464179dd6`\n\nBech32: `drep_vk15j30gk0uex88lc9vh6sfda93lv6zede65mzp7ck56m9pgeqhnhtqvs6j8t`\n\n#### DRep extended signing key\n\nHex: `f05d3d37c1e3dba82444812d45f786295345b410c2fc212ee8fc88da0a118f45993d7ba4c9eb43935dc1c3d56041e2adb74c846fb8955d438d1ef2ec2496230d5fd61ed957d6d0b2dfd6c8e2279e3eb2d5538a7399e908ddf12d1b7bfcb4b6a8`\n\nBech32: `drep_xsk17pwn6d7pu0d6sfzysyk5taux99f5tdqsct7zzthgljyd5zs33azej0tm5ny7ksunthqu84tqg832md6vs3hm392agwx3auhvyjtzxr2l6c0dj47k6zedl4kgugneu04j64fc5uueayydmufdrdaled9k4qllaka6`\n\n#### DRep extended verification key\n\nHex: `a4a2f459fcc98e7fe0acbea096f4b1fb342cb73aa6c41f62d4d6ca1464179dd65fd61ed957d6d0b2dfd6c8e2279e3eb2d5538a7399e908ddf12d1b7bfcb4b6a8`\n\nBech32: `drep_xvk15j30gk0uex88lc9vh6sfda93lv6zede65mzp7ck56m9pgeqhnht9l4s7m9tad59jmltv3c38nclt942n3feen6ggmhcj6xmmlj6td2qu4ce82`\n\n#### [DEPRECATED] Verification key hash (DRep ID)\n\nHex: `33e587eb1f44e51f4307eeed7ede619008bc4d1c32c18099d6367329`\n\nBech32: `drep1x0jc06clgnj37sc8amkhahnpjqytcnguxtqcpxwkxeejj4y6sqm`\n\n#### Verification key hash (DRep VKH)\n\nHex: `33e587eb1f44e51f4307eeed7ede619008bc4d1c32c18099d6367329`\n\nBech32: `drep_vkh1x0jc06clgnj37sc8amkhahnpjqytcnguxtqcpxwkxeejjnrpdfp`\n\n#### [CIP-0129 compliant] Verification key hash appended with  '22' hex-encoded byte (DRep key hash credential)\n\nHex: `2233e587eb1f44e51f4307eeed7ede619008bc4d1c32c18099d6367329`\n\nBech32: `drep1yge7tpltrazw286rqlhw6lk7vxgq30zdrsevrqye6cm8x2gf38vlv`\n\n#### Script 1 hash (DRep Script Hash)\n\nHex: `f241fd096625b515f464b2b35ddebe93a2e6e2ec2e7dcac8c8ae5a33`\n\nBech32: `drep_script17fql6ztxyk63taryk2e4mh47jw3wdchv9e7u4jxg4edrx89ym9g`\n\n#### [CIP-0129] Script 1 hash appended with '23' hex-encoded byte (DRep script hash credential)\n\nHex: `23f241fd096625b515f464b2b35ddebe93a2e6e2ec2e7dcac8c8ae5a33`\n\nBech32: `drep1y0eyrlgfvcjm2905vjetxhw7h6f69ehzash8mjkgezh95vc64rzlm`\n\n#### Script 2 hash (DRep Script Hash)\n\nHex: `7802a8b9e80878cc7b17c451e8778dfeef22cb7b2c2031885b881d68`\n\nBech32: `drep_script10qp23w0gppuvc7chc3g7saudlmhj9jmm9ssrrzzm3qwksv3gsq7`\n\n#### [CIP-0129] Script 2 hash appended with '23' hex-encoded byte (DRep script hash credential)\n\nHex: `237802a8b9e80878cc7b17c451e8778dfeef22cb7b2c2031885b881d68`\n\nBech32: `drep1yduq929eaqy83nrmzlz9r6rh3hlw7gkt0vkzqvvgtwyp66q3042hh`\n\n\n### Constitutional Committee Cold\n\n#### Constitutional Committee Cold Signing Key\n\nHex: `b817960c5fbaf08fb98ba0768c2cf0800d1f32524c5dc2342dd27e400d118f45dc743475378ff71be1306899035c16640c22c4f09d7cf57adf6fec8ec68a3234`\n\nBech32: `cc_cold_sk1hqtevrzlhtcglwvt5pmgct8ssqx37vjjf3wuydpd6flyqrg33azacap5w5mclacmuycx3xgrtstxgrpzcncf6l840t0klmywc69rydqvncuyc`\n\n#### Constitutional Committee Cold Verification Key\n\nHex: `8bb15c318356b4ba8cdb2b899fd5b9c80c427d92149b6a3bd5fb3aa36dedb997`\n\nBech32: `cc_cold_vk13wc4cvvr266t4rxm9wyel4deeqxyylvjzjdk5w74lva2xm0dhxtsfpa2qu`\n\n#### Constitutional Committee Cold Extended Signing Key\n\nHex: `b817960c5fbaf08fb98ba0768c2cf0800d1f32524c5dc2342dd27e400d118f45dc743475378ff71be1306899035c16640c22c4f09d7cf57adf6fec8ec68a3234a24968bef7b0cdba5393b6e494fa9e1f9f33672940dd0fbec967efef0ac4f9ce`\n\nBech32: `cc_cold_xsk1hqtevrzlhtcglwvt5pmgct8ssqx37vjjf3wuydpd6flyqrg33azacap5w5mclacmuycx3xgrtstxgrpzcncf6l840t0klmywc69ryd9zf95taaaseka98yakuj2048slnuekw22qm58majt8alhs438eecehquu0`\n\n#### Constitutional Committee Cold Extended Verification Key\n\nHex: `8bb15c318356b4ba8cdb2b899fd5b9c80c427d92149b6a3bd5fb3aa36dedb997a24968bef7b0cdba5393b6e494fa9e1f9f33672940dd0fbec967efef0ac4f9ce`\n\nBech32: `cc_cold_xvk13wc4cvvr266t4rxm9wyel4deeqxyylvjzjdk5w74lva2xm0dhxt6yjtghmmmpnd62wfmdey5l20pl8envu55phg0hmyk0ml0ptz0nns9cqjlk`\n\n#### [DEPRECATED]  Constitutional Committee Cold Verification Key Hash\n\nHex: `f0ab03c6ebd8d1b4515a3dcda3caac0737689dc3c50c5c0dfbc791f2`\n\nBech32: `cc_cold17z4s83htmrgmg5268hx68j4vqumk38wrc5x9cr0mc7glyntw6cl`\n\n#### Constitutional Committee Cold Verification key hash (Constitutional Committee Cold VKH)\n\nHex: `f0ab03c6ebd8d1b4515a3dcda3caac0737689dc3c50c5c0dfbc791f2`\n\nBech32: `cc_cold_vkh17z4s83htmrgmg5268hx68j4vqumk38wrc5x9cr0mc7glyqucsjn`\n\n#### [CIP-0129 compliant] Constitutional Committee Cold Verification key hash appended with  '12' hex-encoded byte (Constitutional Committee Cold key hash credential)\n\nHex: `12f0ab03c6ebd8d1b4515a3dcda3caac0737689dc3c50c5c0dfbc791f2`\n\nBech32: `cc_cold1ztc2kq7xa0vdrdz3tg7umg724srnw6yac0zschqdl0rerushdm3cm`\n\n#### Constitutional Committee Cold Script 1 Hash\n\nHex: `a0bc49cfc9e0394a5ee7a3cba53063479786cf1f3c03392c6694b6fd`\n\nBech32: `cc_cold_script15z7ynn7fuqu55hh850962vrrg7tcdncl8spnjtrxjjm06y3avt9`\n\n#### [CIP-0129] Constitutional Committee Cold Script 1 hash appended with '13' hex-encoded byte (Constitutional Committee Cold script hash credential)\n\nHex: `13a0bc49cfc9e0394a5ee7a3cba53063479786cf1f3c03392c6694b6fd`\n\nBech32: `cc_cold1zwstcjw0e8srjjj7u73uhffsvdre0pk0ru7qxwfvv62tdlg5gx4wt`\n\n#### Constitutional Committee Cold Script 2 Hash\n\nHex: `eddd105e3fcb6e60bd23474bdeb9363078f0416bc967bcede1b80194`\n\nBech32: `cc_cold_script1ahw3qh3ledhxp0frga9aawfkxpu0qstte9nmem0phqqegeeg6zv`\n\n#### [CIP-0129] Constitutional Committee Cold Script 2 hash appended with '13' hex-encoded byte (Constitutional Committee Cold script hash credential)\n\nHex: `13eddd105e3fcb6e60bd23474bdeb9363078f0416bc967bcede1b80194`\n\nBech32: `cc_cold1z0ka6yz78l9kuc9aydr5hh4excc83uzpd0yk008duxuqr9qx43p9u`\n\n\n### Constitutional Committee Hot\n\n#### Constitutional Committee Hot Signing Key\n\nHex: `70bbb162eb97b7e2ee490a2387ab748d788cca9dc3c3182a03cc07e612118f4565ee4cee93fc2c230735badaaead0a6282c98095dba094476729aa2d95ef6453`\n\nBech32: `cc_hot_sk1wzamzchtj7m79mjfpg3c02m534ugej5ac0p3s2sresr7vys33azktmjva6flctprqu6m4k4w459x9qkfsz2ahgy5ganjn23djhhkg5cmwegml`\n\n#### Constitutional Committee Hot Verification Key\n\nHex: `5f44dd7d934ab0591f743df462535ce12f6ce68ad49069289fee4cbfbcdddb6b`\n\nBech32: `cc_hot_vk1tazd6lvnf2c9j8m58h6xy56uuyhkee526jgxj2ylaextl0xamd4swmuygc`\n\n#### Constitutional Committee Hot Extended Signing Key\n\nHex: `70bbb162eb97b7e2ee490a2387ab748d788cca9dc3c3182a03cc07e612118f4565ee4cee93fc2c230735badaaead0a6282c98095dba094476729aa2d95ef645334c92fcf2646fe96132f62bfb2a4af92a811beba1bc7fd0066133e5e1ddcbe14`\n\nBech32: `cc_hot_xsk1wzamzchtj7m79mjfpg3c02m534ugej5ac0p3s2sresr7vys33azktmjva6flctprqu6m4k4w459x9qkfsz2ahgy5ganjn23djhhkg5e5eyhu7fjxl6tpxtmzh7e2ftuj4qgmawsmcl7sqesn8e0pmh97zs3c3fqj`\n\n#### Constitutional Committee Hot Extended Verification Key\n\nHex: `5f44dd7d934ab0591f743df462535ce12f6ce68ad49069289fee4cbfbcdddb6b34c92fcf2646fe96132f62bfb2a4af92a811beba1bc7fd0066133e5e1ddcbe14`\n\nBech32: `cc_hot_xvk1tazd6lvnf2c9j8m58h6xy56uuyhkee526jgxj2ylaextl0xamd4nfjf0eunydl5kzvhk90aj5jhe92q3h6aph3laqpnpx0j7rhwtu9qe7dhsc`\n\n#### [DEPRECATED] Constitutional Committee Hot Verification Key Hash\n\nHex: `c2a74e9bca6240d947f29beb7ded9604974016da2d48e3a7c3644cc4`\n\nBech32: `cc_hot1c2n5ax72vfqdj3ljn04hmmvkqjt5q9k694yw8f7rv3xvgxas90x`\n\n#### Constitutional Committee Hot Verification key hash (Constitutional Committee Hot VKH)\n\nHex: `c2a74e9bca6240d947f29beb7ded9604974016da2d48e3a7c3644cc4`\n\nBech32: `cc_hot_vkh1c2n5ax72vfqdj3ljn04hmmvkqjt5q9k694yw8f7rv3xvgv2yl5g`\n\n#### [CIP-0129 compliant] Constitutional Committee Hot Verification key hash appended with  '02' hex-encoded byte (Constitutional Committee Hot key hash credential)\n\nHex: `02c2a74e9bca6240d947f29beb7ded9604974016da2d48e3a7c3644cc4`\n\nBech32: `cc_hot1qtp2wn5mef3ypk2872d7kl0djczfwsqkmgk53ca8cdjye3qehdsy0`\n\n#### Constitutional Committee Hot Script 1 Hash\n\nHex: `5eddfce1eb7399f516fa0a19975369a8f38819765e58543fc6dc7c96`\n\nBech32: `cc_hot_script1tmwlec0twwvl29h6pgvew5mf4recsxtktev9g07xm37fv46mta9`\n\n#### [CIP-0129] Constitutional Committee Hot Script 1 hash appended with '03' hex-encoded byte (Constitutional Committee Hot script hash credential)\n\nHex: `035eddfce1eb7399f516fa0a19975369a8f38819765e58543fc6dc7c96`\n\nBech32: `cc_hot1qd0dml8padeenagklg9pn96ndx508zqewe09s4plcmw8e9sg8dhav`\n\n#### Constitutional Committee Hot Script 2 Hash\n\nHex: `c7bcbba29f1f6e47df350691f858ec44035a217ea5a2103cad7ab874`\n\nBech32: `cc_hot_script1c77thg5lrahy0he4q6glsk8vgsp45gt75k3pq09d02u8g4s30yx`\n\n#### [CIP-0129] Constitutional Committee Hot Script 2 hash appended with '03' hex-encoded byte (Constitutional Committee Hot script hash credential)\n\nHex: `03c7bcbba29f1f6e47df350691f858ec44035a217ea5a2103cad7ab874`\n\nBech32: `cc_hot1q0rmewaznu0ku37lx5rfr7zca3zqxk3p06j6yypu44atsaqac8nn5`\n"
  },
  {
    "path": "CIP-0105/test-vectors/test-vector-4.md",
    "content": "## Test vector 4\n\n**Mnemonic:** `excess behave track soul table wear ocean cash stay nature item turtle palm soccer lunch horror start stumble month panic right must lock dress`\n\n**Account index:** `0x80000100`\n\n#### Scripts\n\nScripts were constructed according to the following native script templates:\n\n**Script 1:** `all [$vKeyhash, active_from 5001]`\n\n**Script 2:** `any [$vKeyhash, all [active_from 5001, active_until 6001]]`\n\nWhere `$vKeyhash` is the Verification key hash aka `{drep_vkh1... | cc_cold_vkh1... | cc_hot_vhk1...}`.\n\n### DRep Keys\n\n#### DRep signing key\n\nHex: `a8b5df4daa0506f8c2a83407c96285823d4f3000c38d9e62903fab850c118f451f7dd6304ccbd215e96b09e0c1d13dbf4426872d35f90ccaef7e6692b5198a4d`\n\nBech32: `drep_sk14z6a7nd2q5r03s4gxsrujc59sg757vqqcwxeuc5s874c2rq33az37lwkxpxvh5s4a94sncxp6y7m73pxsuknt7gvethhue5jk5vc5ngl9zhrx`\n\n#### DRep verification key\n\nHex: `ab5d2187f2f4419421b0457f7ac8ab0d4b4ec0802af5de21dde64f603248a381`\n\nBech32: `drep_vk14dwjrplj73qeggdsg4lh4j9tp495asyq9t6augwaue8kqvjg5wqskrq5yn`\n\n#### DRep extended signing key\n\nHex: `a8b5df4daa0506f8c2a83407c96285823d4f3000c38d9e62903fab850c118f451f7dd6304ccbd215e96b09e0c1d13dbf4426872d35f90ccaef7e6692b5198a4d571a0b4d927777b6b1c2e61d361b72ac39b5f0edf498a630665e7f1e9ffd09b7`\n\nBech32: `drep_xsk14z6a7nd2q5r03s4gxsrujc59sg757vqqcwxeuc5s874c2rq33az37lwkxpxvh5s4a94sncxp6y7m73pxsuknt7gvethhue5jk5vc5n2hrg95mynhw7mtrshxr5mpku4v8x6lpm05nznrqej70u0fllgfkusexdkv`\n\n#### DRep extended verification key\n\nHex: `ab5d2187f2f4419421b0457f7ac8ab0d4b4ec0802af5de21dde64f603248a381571a0b4d927777b6b1c2e61d361b72ac39b5f0edf498a630665e7f1e9ffd09b7`\n\nBech32: `drep_xvk14dwjrplj73qeggdsg4lh4j9tp495asyq9t6augwaue8kqvjg5wq4wxstfkf8waakk8pwv8fkrde2cwd47rklfx9xxpn9ulc7nl7sndcvdjh2m`\n\n#### [DEPRECATED] Verification key hash (DRep ID)\n\nHex: `c1a342f0dfb82b93ca2e6b406bacb04802f7d56a99d8f95a80a8b6c5`\n\nBech32: `drep1cx359uxlhq4e8j3wddqxht9sfqp004t2n8v0jk5q4zmv27sh0h5`\n\n#### Verification key hash (DRep VKH)\n\nHex: `c1a342f0dfb82b93ca2e6b406bacb04802f7d56a99d8f95a80a8b6c5`\n\nBech32: `drep_vkh1cx359uxlhq4e8j3wddqxht9sfqp004t2n8v0jk5q4zmv2chvj7w`\n\n#### [CIP-0129 compliant] Verification key hash appended with  '22' hex-encoded byte (DRep key hash credential)\n\nHex: `22c1a342f0dfb82b93ca2e6b406bacb04802f7d56a99d8f95a80a8b6c5`\n\nBech32: `drep1ytq6xshsm7uzhy729e45q6avkpyq9a74d2va3726sz5td3gqrgcll`\n\n#### Script 1 hash (DRep Script Hash)\n\nHex: `c5875315458ec9c20a91f15d36debd43df8f1fd75cc4e118db0a6691`\n\nBech32: `drep_script1ckr4x9293myuyz5379wndh4ag00c787htnzwzxxmpfnfzjzk4cq`\n\n#### [CIP-0129] Script 1 hash appended with '23' hex-encoded byte (DRep script hash credential)\n\nHex: `23c5875315458ec9c20a91f15d36debd43df8f1fd75cc4e118db0a6691`\n\nBech32: `drep1y0zcw5c4gk8vnss2j8c46dk7h4palrcl6awvfcgcmv9xdyghfewm4`\n\n#### Script 2 hash (DRep Script Hash)\n\nHex: `723e4a09b4897bddf8861f963312a76df8183b6ee438bdd4157b5d6c`\n\nBech32: `drep_script1wgly5zd539aam7yxr7trxy48dhupswmwusutm4q40dwkcquwecx`\n\n#### [CIP-0129] Script 2 hash appended with '23' hex-encoded byte (DRep script hash credential)\n\nHex: `23723e4a09b4897bddf8861f963312a76df8183b6ee438bdd4157b5d6c`\n\nBech32: `drep1yderujsfkjyhhh0csc0evvcj5aklsxpmdmjr30w5z4a46mqsgv4sm`\n\n\n### Constitutional Committee Cold\n\n#### Constitutional Committee Cold Signing Key\n\nHex: `b8334b6200a1766aacb330f0bdaeef08445437af44c2127ff1b9466c10118f455e123cd02e2e5e5082c58e97ae440caf49feb9ae3b0edaa9fd3611c17f51ad17`\n\nBech32: `cc_cold_sk1hqe5kcsq59mx4t9nxrctmth0ppz9gda0gnppyll3h9rxcyq33az4uy3u6qhzuhjsstzca9awgsx27j07hxhrkrk6487nvywp0ag669c5qtm3p`\n\n#### Constitutional Committee Cold Verification Key\n\nHex: `fec199631209a0d2e3f5e758693e4324be9b5067767637b4f0ef7f52fd6b0aaa`\n\nBech32: `cc_cold_vk1lmqejccjpxsd9cl4uavxj0jryjlfk5r8wemr0d8saal49lttp24q6lw08l`\n\n#### Constitutional Committee Cold Extended Signing Key\n\nHex: `b8334b6200a1766aacb330f0bdaeef08445437af44c2127ff1b9466c10118f455e123cd02e2e5e5082c58e97ae440caf49feb9ae3b0edaa9fd3611c17f51ad177566bf28da60f674137792214fdb4e9935d16ad52b1f321b2f2fbb77eab5a716`\n\nBech32: `cc_cold_xsk1hqe5kcsq59mx4t9nxrctmth0ppz9gda0gnppyll3h9rxcyq33az4uy3u6qhzuhjsstzca9awgsx27j07hxhrkrk6487nvywp0ag669m4v6lj3knq7e6pxaujy98akn5exhgk44ftruepkte0hdm74dd8zceqnk2h`\n\n#### Constitutional Committee Cold Extended Verification Key\n\nHex: `fec199631209a0d2e3f5e758693e4324be9b5067767637b4f0ef7f52fd6b0aaa7566bf28da60f674137792214fdb4e9935d16ad52b1f321b2f2fbb77eab5a716`\n\nBech32: `cc_cold_xvk1lmqejccjpxsd9cl4uavxj0jryjlfk5r8wemr0d8saal49lttp2482e4l9rdxpan5zdmeyg20md8fjdw3dt2jk8ejrvhjlwmha266w9syf55nr`\n\n#### [DEPRECATED] Constitutional Committee Cold Verification Key Hash\n\nHex: `4cb32ae705fb3bba3cac9742356880c912a36a4a7cca74d4956c7f41`\n\nBech32: `cc_cold1fjej4ec9lvam509vjapr26yqeyf2x6j20n98f4y4d3l5zygwxt4`\n\n#### Constitutional Committee Cold Verification key hash (Constitutional Committee Cold VKH)\n\nHex: `4cb32ae705fb3bba3cac9742356880c912a36a4a7cca74d4956c7f41`\n\nBech32: `cc_cold_vkh1fjej4ec9lvam509vjapr26yqeyf2x6j20n98f4y4d3l5zhlcvpe`\n\n#### [CIP-0129 compliant] Constitutional Committee Cold Verification key hash appended with  '12' hex-encoded byte (Constitutional Committee Cold key hash credential)\n\nHex: `124cb32ae705fb3bba3cac9742356880c912a36a4a7cca74d4956c7f41`\n\nBech32: `cc_cold1zfxtx2h8qhanhw3u4jt5ydtgsry39gm2ff7v5ax5j4k87sgmkas3l`\n\n#### Constitutional Committee Cold Script 1 Hash\n\nHex: `07ede1a2cda4f48e9f33759e76397bfdbf71267b92e5f17dd96e94be`\n\nBech32: `cc_cold_script1qlk7rgkd5n6ga8enwk08vwtmlklhzfnmjtjlzlwed62tuycmmh5`\n\n#### [CIP-0129] Constitutional Committee Cold Script 1 hash appended with '13' hex-encoded byte (Constitutional Committee Cold script hash credential)\n\nHex: `1307ede1a2cda4f48e9f33759e76397bfdbf71267b92e5f17dd96e94be`\n\nBech32: `cc_cold1zvr7mcdzekj0fr5lxd6eua3e007m7ufx0wfwtutam9hff0s6qkedk`\n\n#### Constitutional Committee Cold Script 2 Hash\n\nHex: `ed41b6d1b16802132c147639cef6264e4fa3b093aeba965962a73061`\n\nBech32: `cc_cold_script1a4qmd5d3dqppxtq5wcuuaa3xfe868vyn46afvktz5ucxzxvflg4`\n\n#### [CIP-0129] Constitutional Committee Cold Script 2 hash appended with '13' hex-encoded byte (Constitutional Committee Cold script hash credential)\n\nHex: `13ed41b6d1b16802132c147639cef6264e4fa3b093aeba965962a73061`\n\nBech32: `cc_cold1z0k5rdk3k95qyyevz3mrnnhkye8ylgasjwht49jev2nnqcgmwf9vk`\n\n\n### Constitutional Committee Hot\n\n#### Constitutional Committee Hot Signing Key\n\nHex: `a8c57a7d8b6dd9cde9924b2ce0fa3b1151faab5893ea64f5939236d30c118f45c409f62c3364ab28f3fe38d468a771f1d2ac8bc5df78d32d6969e1bb7ff3aff1`\n\nBech32: `cc_hot_sk14rzh5lvtdhvum6vjfvkwp73mz9gl426cj04xfavnjgmdxrq33azugz0k9sekf2eg70lr34rg5aclr54v30za77xn945kncdm0le6lugud8v57`\n\n#### Constitutional Committee Hot Verification Key\n\nHex: `428aaa4d7c9ed7776b5019d7e64419f27f0ad3d47078b8963ac2382b7b7a7553`\n\nBech32: `cc_hot_vk1g2925ntunmthw66sr8t7v3qe7fls4575wput3936cguzk7m6w4fs0zjxf8`\n\n#### Constitutional Committee Hot Extended Signing Key\n\nHex: `a8c57a7d8b6dd9cde9924b2ce0fa3b1151faab5893ea64f5939236d30c118f45c409f62c3364ab28f3fe38d468a771f1d2ac8bc5df78d32d6969e1bb7ff3aff166f8e9d1c694e53ae02d57b6dbc1b2a066ab8d85112880aede4605b333b2da50`\n\nBech32: `cc_hot_xsk14rzh5lvtdhvum6vjfvkwp73mz9gl426cj04xfavnjgmdxrq33azugz0k9sekf2eg70lr34rg5aclr54v30za77xn945kncdm0le6lutxlr5ar355u5awqt2hkmdurv4qv64cmpg39zq2ahjxqken8vk62qunx4hl`\n\n#### Constitutional Committee Hot Extended Verification Key\n\nHex: `428aaa4d7c9ed7776b5019d7e64419f27f0ad3d47078b8963ac2382b7b7a755366f8e9d1c694e53ae02d57b6dbc1b2a066ab8d85112880aede4605b333b2da50`\n\nBech32: `cc_hot_xvk1g2925ntunmthw66sr8t7v3qe7fls4575wput3936cguzk7m6w4fkd78f68rffef6uqk40dkmcxe2qe4t3kz3z2yq4m0yvpdnxwed55q798msd`\n\n#### [DEPRECATED] Constitutional Committee Hot Verification Key Hash\n\nHex: `a9eb44d0aa1ce5559b7c22270ac23d1e61bf2e114dd8e5a44ed3a529`\n\nBech32: `cc_hot14845f592rnj4txmuygns4s3aresm7ts3fhvwtfzw6wjjj3l0520`\n\n#### Constitutional Committee Hot Verification key hash (Constitutional Committee Hot VKH)\n\nHex: `a9eb44d0aa1ce5559b7c22270ac23d1e61bf2e114dd8e5a44ed3a529`\n\nBech32: `cc_hot_vkh14845f592rnj4txmuygns4s3aresm7ts3fhvwtfzw6wjjjmgmw3p`\n\n#### [CIP-0129 compliant] Constitutional Committee Hot Verification key hash appended with  '02' hex-encoded byte (Constitutional Committee Hot key hash credential)\n\nHex: `02a9eb44d0aa1ce5559b7c22270ac23d1e61bf2e114dd8e5a44ed3a529`\n\nBech32: `cc_hot1q257k3xs4gww24vm0s3zwzkz850xr0ewz9xa3edyfmf622g5zjp8w`\n\n#### Constitutional Committee Hot Script 1 Hash\n\nHex: `9d55b1aab952b24807bedbc9af8283b1d798023432f484a2d9160dfe`\n\nBech32: `cc_hot_script1n42mr24e22eyspa7m0y6lq5rk8tesq35xt6gfgkezcxluqysk4n`\n\n#### [CIP-0129] Constitutional Committee Hot Script 1 hash appended with '03' hex-encoded byte (Constitutional Committee Hot script hash credential)\n\nHex: `039d55b1aab952b24807bedbc9af8283b1d798023432f484a2d9160dfe`\n\nBech32: `cc_hot1qww4tvd2h9ftyjq8hmduntuzswca0xqzxse0fp9zmytqmlsve25xm`\n\n#### Constitutional Committee Hot Script 2 Hash\n\nHex: `4241b3550fc0aca9895b50d3d722bbca8f197fce155c9843817c7ac5`\n\nBech32: `cc_hot_script1gfqmx4g0czk2nz2m2rfawg4me283jl7wz4wfssup03av2yzf2kd`\n\n#### [CIP-0129] Constitutional Committee Hot Script 2 hash appended with '03' hex-encoded byte (Constitutional Committee Hot script hash credential)\n\nHex: `034241b3550fc0aca9895b50d3d722bbca8f197fce155c9843817c7ac5`\n\nBech32: `cc_hot1qdpyrv64plq2e2vftdgd84ezh09g7xtlec24exzrs97843g99j85a`\n"
  },
  {
    "path": "CIP-0105/test-vectors.md",
    "content": "# Test Vector for CIP-0105 compliant with CIP-0129\n\nHere we provide a set of test vectors.\n\n### Scripts\n\nScripts were constructed according to the following native script templates:\n\n**Script 1:** `all [$vKeyhash, active_from 5001]`\n\n**Script 2:** `any [$vKeyhash, all [active_from 5001, active_until 6001]]`\n\nWhere `$vKeyhash` is the Verification key hash aka `{drep_vkh1... | cc_cold_vkh1... | cc_hot_vkh1...}`.\n\n## Test vector 1\n\nSee [test vector 1 file](./test-vectors/test-vector-1.md)\n\n## Test vector 2\n\nSee [test vector 2 file](./test-vectors/test-vector-2.md)\n\n## Test vector 3\n\nSee [test vector 3 file](./test-vectors/test-vector-3.md)\n\n## Test vector 4\n\nSee [test vector 4 file](./test-vectors/test-vector-4.md)\n"
  },
  {
    "path": "CIP-0106/README.md",
    "content": "---\nCIP: 106\nTitle: Web-Wallet Bridge - Multisig wallets\nStatus: Proposed\nCategory: Wallets\nAuthors: \n  - Leo\nImplementors: \n  - BroClanWallet \nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/617\nCreated: 2023-10-12\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis document describes a CIP-30 extension allowing webpages (i.e. dApps) to interface with Cardano Multisig-wallets. This document is a work in progress and is not yet finalized. It is expected to be updated as the ecosystem evolves. \n\n## Motivation: why is this CIP necessary?\n\nIn order to facilitate future dApp development, we will need a way for dApps to communicate with multisig wallets, given the unique complexities of native script based addresses. Special provisions need to be made to make the connector compatible with them.  \n\nSpecifically, apps building transactions need to be able to get the following information from the wallet:\n- Script descriptor\n  - Any transaction consuming a UTXO from a Plutus-based address must attach the corresponding script. \n- `ScriptRequirements`\n  - The `TxContext` that is required to be able to validate the transaction. It encompasses all the possible combinations of requirements for the transaction to be valid, as such it is represented by an array of `ScriptRequirement` objects.\n- Change Datum\n  - The datum that will be used as the change output for the transaction. This is required for wallets based on Plutus V2 and before, as the change output must contain a datum to be valid and spendable.\n  \nAdditionally, apps need to be able to submit a transaction to the wallet for signing in an asynchronous manner, as gathering of signatures can take a long time and each wallet provider will have its own way of handling this process. \n\nFinally, the signTx() and signData() endpoints will have to be disabled when using this extension since they are not compatible with native script based addresses.\n\n## Specification\n\n### Data Types\n\n#### KeyHash\n\nA hex-encoded string of the corresponding bytes. This represents the hash of the public key used to sign transactions.\n\n```ts\ntype KeyHash = String\n```\n\n#### ScriptRequirements\n\n```ts\ntype ScriptRequirementsCode = {\n    Signer: 1,\n    Before: 2,\n    After: 3,\n}\ntype ScriptRequirement = {\n    code: ScriptRequirementsCode,\n    value: KeyHash|number,\n}\n```\n\n### Aditional Error Types\n\n#### CompletedTxError\n\n```ts\nCompletedTxErrorCode = {\n\tNotFound: 1,\n\tNotReady: 2\n}\n```\n\n* NotFound - The transaction with the given id was not found.\n* NotReady - The transaction with the given id is not ready yet. \n\n### Additional API Endpoints\n\n#### api.cip106.getCollateralAddress(): Promise\\<Address>\n\nFor Plutus V2 and later, partial collateral is supported. This function returns an address that can be used to add collateral to a transaction. The address returned must be owned by one of the signers in the list of signers returned by `api.getScriptRequirements()`. \n\ndApp developers can choose to use this address to add collateral to a transaction, or they can choose to use the `api.getCollateral()` function to get a list of UTXOs that can be used as collateral. If the dApp chooses to use this address, they must ensure that the address is not used for any other purpose, as the wallet may be using it to track collateral, and that the collateral return address is the same one.\n\n#### api.cip106.getScriptRequirements: Promise\\<ScriptRequirement[]>\n\nErrors: `APIError`\n\nReturns a list of ScriptRequirements that will be used to validate any transaction sent to the wallet.\n\n#### api.cip106.getScript(): Promise\\<cbor\\<nativeScript>>\n\nErrors: `APIError`\n\nReturns the CBOR-encoded native script that controls this wallet. \n\n#### api.cip106.submitUnsignedTx(tx: cbor\\<unsignedTransaction>): Promise\\<hash32>\n\nErrors: `APIError`, `TxError`\n\nSubmits a transaction to the wallet for signing. The wallet should check that the transaction is valid, gather the required signatures, compose the finalized transaction, and submit the transaction to the network. If the transaction is valid and the wallet is able to sign it, the wallet should return the transaction hash. If the transaction is invalid or the wallet is unable to sign it, the wallet should throw a `TxError` with the appropriate error code. The wallet should not submit the transaction to the network if it is invalid or the wallet is unable to sign it.\n\nIf the transaction contains hidden metadata, the wallet should not submit the transaction when it is ready, but return it to the dApp when the dApp calls the `getCompletedTx` function.\n\n#### api.cip106.getCompletedTx(txId: hash32): Promise\\[<cbor\\<transaction>,cbor<transaction_witness_set>>]\n\nErrors: `APIError`, `CompletedTxError`\n\nIf the transaction is not ready, the wallet should throw a `CompletedTxError` with the appropriate error code. If the transaction is ready, the wallet should return the CBOR-encoded transaction and the signatures.\n\n### Altered API endpoints \n\n#### api.getCollateral(params: { amount: cbor\\<Coin> }): Promise\\<TransactionUnspentOutput[] | null>\n\nNative script based addresses cannot provide collateral for transactions. Using this function, dApps can request the wallet to provide collateral for a transaction. The collateral must be a pure ADA UTXO, held by one of the signers in the list of signers returned by `api.getScriptRequirements()`.\n\n### Disabled API endpoints\n\nWhen connecting to a wallet using this extension the following endpoints will be disabled:\n\n#### `api.signTx(tx: cbor<transaction>, partialSign: bool = false): Promise<cbor<transaction_witness_set>>` \n\n\n#### `api.signData(addr: Address, payload: Bytes): Promise<DataSignature>`\n\nThese endpoints should return an error if called when using this extension. \n\n## Rationale: how does this CIP achieve its goals?\n\nSee justification and explanations provided with each API endpoint.\n\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] The interface is implemented and supported by multiple wallet providers.\n- [ ] The interface is used by multiple dApps to interact with wallet providers. \n\t\n### Implementation Plan\n\n- [x] Provide some reference implementation of wallet providers\n\t- [leo42/BroClanWallet](https://github.com/leo42/BroClanWallet)\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0107/README.md",
    "content": "---\nCIP: 107\nTitle: URI Scheme - Block and transaction objects\nStatus: Proposed\nCategory: Tools\nAuthors:\n    - Pi Lanningham <pi@sundaeswap.finance>\nImplementors: N/A\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/556\nCreated: 2020-09-22\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis extends CIP-13, which describes a Cardano URI scheme, with several more objects that would be useful to be able to assign addresses to, in particular blocks, transactions, transaction metadata, and transaction outputs.\n\n## Motivation: why is this CIP necessary?\n\nCIP-13 defined two initial URL authorities, for payment links and delegating to a stakepool.\n\nHowever, in a number of contexts, it would be useful to canonically link to other Cardano objects, such as:\n- Providing links to a transaction, to be opened in a wallet or chain explorer of the users choice\n- To provide richly interconnected metadata, such as in [CIP-100](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0100)\n\nWithout a canonical standard for how to define these URIs, these objects are either unaddressable, not machine-interpretable, or will suffer from a divergence of convention. Similarly, we seek to fit an existing structure, such as CIP-0013, to reduce the number of different conventions that need be supported by the ecosystem.\n\n## Specification\n\nWe extend CIP-13 with 2 new authorities for referencing blocks and transactions.\n\nExamples:\n```\nweb+cardano://block?hash=c6a8976125193dfae11551c5e80a217403d953c08ebbd69bba904d990854011f\nweb+cardano://block?height=12345678890\nweb+cardano://transaction/7704a68404facf7126fa356f1b09f0e4c552aeef454cd0daba4208f3a64372e9\nweb+cardano://transaction/7704a68404facf7126fa356f1b09f0e4c552aeef454cd0daba4208f3a64372e9#1\nweb+cardano://transaction/7704a68404facf7126fa356f1b09f0e4c552aeef454cd0daba4208f3a64372e9/metadata\nweb+cardano://transaction/d3616b772c91f118346e74863d1722810a4858e4d7cc7663dc2eed345d7bca72/metadata/674\nweb+cardano://transaction/self/metadata/1694\n```\n\n### Grammar & interpretation\n\nWe extend the grammar from CIP-0013 with two new authorities:\n\n```\nauthorityref = (... | blockref | transactionref)\n```\n\n#### Block queries\n\nA link referencing a block by either block hash or height.\n\n> WARNING: Referencing blocks by height is provided in the case of extremely tight space requirements, but referencing a recent block (within the rollback horizon of the chain) is unstable.  Due to chain re-orgs, it may refer to different content for different users, or at different times. This should only be used when this is not critical, or for blocks outside of the rollback horizon.\n\n```\nblockref = \"//block\" query\nquery = ( \"?block=\" block_hash | \"?height=\" block_height)\n\nblock_hash = 64HEXDIG\nblock_height = *digit\n```\n\n#### Transaction queries\n\nA link referencing *this* transaction, another transaction, transaction output, the full transaction metadata, or specific tag within the transaction metadata.\n\n```\ntransactionref = \"//transaction/\" (tx_id | utxo_id | tx_metadata | tx_metadata_tag)\n\ntx_id = \"self\" | 64HEXDIG\nutxo_id = tx_id \"#\" *digit\ntx_metadata = tx_id \"/\" metadata\ntx_metadata_tag = tx_id \"/\" metadata \"/\" *digit\n```\n\n> NOTE: tx_id can be set to \"self\", which is useful for making self-referential metadata, before the transaction ID is known.  For example, in CIP-100, you may want to store governance metadata on the transaction which casts the vote. The transaciton hash is not yet known, and so the `anchor` field cannot link to the transaction by transaction ID. \n\nFor grammar reference, see:\n\n  - [Wikipedia > Augmented Backus–Naur form](https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_form)\n  - [RFC 2234: Augmented BNF for Syntax Specifications: ABNF](https://datatracker.ietf.org/doc/html/rfc2234)\n  - [Unicode in ABNF](https://tools.ietf.org/html/draft-seantek-unicode-in-abnf-00)\n\n## Rationale: how does this CIP achieve its goals?\n\nThis CIP defines a canonical format for URIs referencing four new Cardano objects: blocks, transactions, transaction metadata, and specific tags within the transaction metadata. It utilizes existing cardano standards (CIP-0013) and industry standards (URIs), minimizing the number of new concepts that a developer needs to learn. By utilizing URIs, it creates a natural path to integration with existing tools, such as browsers. And finally, it allows a canonical URI for these objects, such as storing CIP-100 metadata on-chain, and referring to it in the anchor field.\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] CIP-100 is standardized utilizing these URI schemes for on-chain references.\n- [ ] At least one governance tool utilizes these URI schemes\n- [ ] At least one explorer or wallet utilizes these URI schemes\n\n### Implementation Plan\n\nThe current community sentiment towards adopting this in CIP-100 is high (it was the original inspiration).\n\nAdvocacy and education about this format should be performed by:\n\n- Implementors of CIP-100 and governance metadata tooling\n- Wallet and Explorer developers\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0108/README.md",
    "content": "---\nCIP: 108\nTitle: Governance Metadata - Governance Actions\nCategory: Metadata\nStatus: Proposed\nAuthors:\n  - Ryan Williams <ryan.williams@intersectmbo.org>\nImplementors: [ ]\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/632\n  - https://github.com/cardano-foundation/CIPs/pull/748\n  - https://github.com/cardano-foundation/CIPs/issues/757\nCreated: 2023-11-23\nLicense: CC-BY-4.0\n---\n\n## Abstract\nThe Conway ledger era ushers in on-chain governance for Cardano via [CIP-1694 | A First Step Towards On-Chain Decentralized Governance](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md), with the addition of many new on-chain governance artifacts.\nSome of these artifacts support the linking off-chain metadata, as a way to provide context.\n\nThe [CIP-100 | Governance Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0100) standard provides a base framework for how all off-chain governance metadata should be formed and handled.\nBut this is intentionally limited in scope, so that it can be expanded upon by more specific subsequent CIPs.\n\nThis proposal aims to provide a specification for off-chain metadata vocabulary that can be used to give context to governance actions.\nWithout a sufficiently detailed standard for governance actions we introduce the possibility to undermine voters ability to adequately assess governance actions.\nFurthermore a lack of such standards risks preventing interoperability between tools, to the detriment of user experiences.\n\nFor the many contributors to this proposal, see [Acknowledgements](#acknowledgements).\n\n## Motivation: why is this CIP necessary?\nBlockchains are poor choices to act as content databases.\nThis is why governance metadata anchors were chosen to provide a way to attach long form metadata content to on-chain events.\nBy only supplying an onchain hash of the off-chain we ensure correctness of data whilst minimizing the amount of data posted to the chain.\n\n### For voters\nWhen observing from the chain level, tooling can only see the content of the governance action and it's anchor.\nThese on-chain components do not give give any context to the motivation nor off-chain discussion of an governance action.\nAlthough this information would likely be desired context for voters.\nBy providing rich contextual metadata we enable voters to make well informed decisions.\n\n### For all participants\nBy standardizing off-chain metadata formats we facilitate interoperability for tooling which creates and/or renders metadata attached to governance actions.\nThis intern promotes a rich user experience between tooling.\nThis is good for all governance participants.\n\n## Specification\nAlthough there are seven types of governance action defined via CIP-1694, we focus this proposal on defining core properties which must be attached to all types.\nWe leave room for future standards to refine and specialize further to cater more specific for each type of governance action.\n\n### New `witness` Type\nHere we extend the potential witnesses, with a `witnessAlgorithm` that can be set to include support for [CIP-08 | Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008) standard, indicated by `CIP-0008`.\nHere we mimic the restrictions as imposed over the CIP-30's implementation in [.signData()](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030#apisigndataaddr-address-payload-bytes-promisedatasignature).\n\n### Markdown Text Styling\nThis standard introduces the possibility of using [Github markdown text styling](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#styling-text) within fields.\n\n### Extended Vocabulary\nThe following properties extend the potential vocabulary of [CIP-100](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0100)'s `body` property.\n\n#### `title`\n- A very short freefrom text field. Limited to `80` characters.\n- This SHOULD NOT support markdown text styling.\n- Authors SHOULD use this field to succinctly describe the governance action and its motivation.\n- Authors SHOULD attempt to make this field unique whilst also avoiding hyperbolic language.\n- i.e; Increase K protocol parameter to `100,000` to increase decentralization of Cardano.\n\n#### `abstract`\n- A short freefrom text field. Limited to `2500` characters.\n- This SHOULD support markdown text styling.\n- Authors SHOULD use this field to expand upon their `title` by describing the contents of the governance action, its motivation and rationale.\n\n#### `motivation`\n- A freeform text field.\n- This SHOULD support markdown text styling.\n- This SHOULD be used by the author to encapsulate all context around the problem that is being solved by the on-chain action.\n- This SHOULD be used to outline the related stakeholders and use cases. \n\n#### `rationale`\n- A freeform text field.\n- This SHOULD support markdown text styling.\n- This SHOULD be used by the author to discuss how the content of the governance action addresses the problem outlined within the `motivation`.\n- This field SHOULD justify the changes being made to Cardano.\n- i.e \"by decreasing X parameter by Y we increase Ada earned by SPOs, thus incentivising more people to become SPOs, leading to a more diverse network\"\n- This SHOULD provide evidence of consensus within the community and discuss significant objections or concerns raised during the discussion.\n- This SHOULD include discussion of alternative solutions and related topics/ governance actions.\n- This SHOULD include any recommendations made by relevant organizations or committees.\n\n#### `references`\n- We extend CIP-100's references field.\n- This SHOULD NOT support markdown text styling.\n- To be an OPTIONAL set of objects, using the `@set` property.\n- Each object MUST have a `label` field to describe the reference, such as; \"blog - Why we must continue to fund Catalyst\".\n- Each object MUST have a `uri` field.\n- Each object MAY have a OPTIONAL `referenceHash` object.\n  - Each object MUST have a `hashDigest` field.\n  - Each object MUST have a `hashAlgorithm` field, which is inherited from CIP-100.\n- This should be used by the author to link related or supporting work via the URI, and reference this via the index within their freefrom text fields.\n\n### Application\nGovernance action metadata must include all compulsory fields to be considered CIP-0108 compliant.\nAs this is an extension to CIP-100, all CIP-100 fields can be included within CIP-108 compliant metadata.\n\n### Test Vector\nSee [test-vector.md](./test-vector.md) for examples.\n\n### Versioning\nThis proposal should not be versioned, to update this standard a new CIP should be proposed.\nAlthough through the JSON-LD mechanism further CIPs can add to the common governance metadata vocabulary,\n\n## Rationale: how does this CIP achieve its goals?\nWe intentionally have kept this proposal brief and uncomplicated.\nThis was to reduce the time to develop and deploy this standard.\nWe think it is better to have a base standard which can be improved, rather than meticulously craft a perfect single standard.\nThis way we enable tooling which depends on this standard to start development.\nFurthermore, it is very difficult to predict future wants/needs now, so by allowing upgrades we build in the ability to improve the standard as new wants/needs arrive.\n\nThe fields which have been chosen for this standard heavily inspired to those used for CIPs.\nWe did this for two reasons; familiarity and competency.\nThose who are involved in Cardano are familiar with the CIP format, meaning they will be intuitively understand these fields being reused here.\nThese fields in combination have also been fairly battle tested via the CIPs process and thus act as a good standard to describe problems and their solutions.\n\n### New `witness` type\nWe introduce a new witness type to be able to reuse existing dApp-Wallet infrastructure.\nThe type as described allows for reuse of the CIP-30 signData standard, which means that governance dApps are able to implement this without needing any alterations to existing wallets.\n\n### Markdown Text Styling\nWe choose to introduce rich text standard here because we see significant value in supporting it.\nRich text styling improves the ability for the author to express themselves.\nFurthermore, most potential voters are use to such standards when reviewing metadata.\n\n### Character Limits\nWith this design, we wanted to allow for quick and easy differentiation between governance actions.\nWe achieve this by facilitating users \"layers of investigation\", where some fields are limited in size.\nThis encourages tooling providers to show users the small fields before allowing deep investigation of the larger fields.\nBy allowing this we aim to improve the experience of prospective voters, when sorting though many governance actions.\n\nThe downside of highlighting some fields over others is that we incentivize hyperbolic and eye catching phrases. \nWhere authors want their governance action to standout in tooling so use overly dramatic phrasing.\nThis creates an environment where there is a race to the bottom on voter's attention.\nOverall this could decrease the perceived legitimacy of the system.\nThe counter argument is that tooling providers should not use metadata to solely highlight proposals, rather other means such as cryptographically verified submitters.\n\n### `title`\nThis should be used by voters to quickly and easily differentiate between two governance actions which may be having the same or similar on-chain effects.\nThis is why we have chosen a short character limit, as longer titles would reduce the ability for quick reading.\n\n### `abstract`\nThis gives voters one step more detail beyond the `title`.\nThis allows for a compact description of the what, why and how without the voter having to read the larger fields.\n\n### `motivation`\nThe `motivation` is a chance for the author to fully describe the problem that is being solved by the governance action.\nThis is important as all governance actions are a solution to a problem and thus this is a universal field.\nBy showing relation to stakeholders the author is able to show that they have performed adequate research on the problem.\nVoters can use this field to determine if the problem is sizable enough to warrant voting on.\n\n### `rationale`\nThis field gives the author the opportunity to explain how the onchain action is addressing the problem outlined in the motivation.\nThis gives the author a place to discuss any alternative designs or completing governance actions.\nVoters should be able to use this field to evaluate the applicability of the solution to the problem.\n\n### `references`\nReferences give the author ability to point to supporting research or related work.\nThese should be used by voters to verify the content of supporting research.\nThe inclusion of a hash allows for the supporting documentation to be cryptographically verified.\n\n### Open Questions\n- <s>Should fields be optional or compulsory?</s>\n  - Title, abstract, motivation and rationale should be compulsory as they should be very important to the ability \n- <s>How much vocabulary can be extended to other onchain governance events?</s>\n  - It is hard to predict how the scope of future standards before they have been developed.\n- <s>How to integrate custom set of HTML tags? to allow formatting of longer text fields.</s>\n  - Since CIP-100 does not intend to support rich text fields such an inclusion would not fit, so we have included such format here.\n\n## Path to Active\n\n### Acceptance Criteria\n- [X] This standard is supported by two different tooling providers used to submit governance actions to chain.\n  - [cardano-signer](https://github.com/gitmachtl/cardano-signer?tab=readme-ov-file#cip-100--cip-108--cip-119-mode) : A tool to sign with author secret keys, verify signatures, canonize the body content (Linux/Arm/Win/Mac)\n  - [spo-scripts](https://github.com/gitmachtl/scripts) : A collection of scripts to interact with governance. Create actions, vote on actions incl. signature verification\n  - [cardano-governance-metadata-lib](https://github.com/SundaeSwap-finance/cardano-governance-metadata) : A rust library for interacting with Cardano Governance Metadata conforming to CIP-100 (rust)\n\n- [ ] This standard is supported by two different chain indexing tools, used to read and render metadata.\n  - DB-Sync via [db-sync-sancho-4.1.0](https://github.com/IntersectMBO/cardano-db-sync/releases/tag/sancho-4.1.0)\n\n### Implementation Plan\nSolicitation of feedback\n- [x] Run two online workshops to gather insights from stakeholders.\n- [x] Seek community answers on all [Open Questions](#open-questions).\nImplementation\n- [x] Author to provide example metadata and schema files.\n\n\n## Acknowledgments\n\n<details>\n  <summary><strong>Governance Metadata Working Group - Workshop #1 2023-12-04</strong></summary>\n\n  I would like to thank those that contributed to the Governance Metadata Working Group Workshop #1 hosted by Ryan Williams ([see presentation slides with notes](https://docs.google.com/presentation/d/18OK3vXexCc8ZXq-dC00RDPPKcy2Zu4DiMo8PeIZ47_4/)).\n\n  Thank you to the co-hosts:\n  - Adam Dean\n  - Thomas Upfield\n\n  Thank you to the participants:\n  - Carlos Lopez de Lara\n  - Igor Veličković\n  - Johnny Kelly\n  - Kenric Nelson\n  - Kevin Hammond\n  - Lorenzo Bruno\n  - Mike Susko\n  - Rhys Morgan\n  - Eric Alton\n  - Samuel Leathers\n  - Vladimir Kalnitsky\n\n</details>\n\n<details>\n  <summary><strong>Governance Metadata Working Group - Workshop #2 2023-12-14</strong></summary>\n\n  I would like to thank those that contributed to the Governance Metadata Working Group Workshop #2 hosted by Ryan Williams ([see presentation slides with notes](https://docs.google.com/presentation/d/1tFsyQnONjwyTm7zKrnxxedzWsoonO6-8vXw5vYzB3qs)).\n\n  Thank you to the co-host:\n  - Adam Dean\n\n  Thank you to the participants:\n  - Mark Byers\n  - Nils Codes\n\n  Thank you to the bots that joined also.\n\n</details>\n\n## Copyright\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0108/cip-0108.common.jsonld",
    "content": "{\n    \"@context\": {\n        \"CIP100\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#\",\n        \"CIP108\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#\",\n        \"hashAlgorithm\": \"CIP100:hashAlgorithm\",\n        \"body\": {\n            \"@id\": \"CIP108:body\",\n            \"@context\": {\n                \"references\": {\n                    \"@id\": \"CIP108:references\",\n                    \"@container\": \"@set\",\n                    \"@context\": {\n                        \"GovernanceMetadata\": \"CIP100:GovernanceMetadataReference\",\n                        \"Other\": \"CIP100:OtherReference\",\n                        \"label\": \"CIP100:reference-label\",\n                        \"uri\": \"CIP100:reference-uri\",\n                        \"referenceHash\": {\n                            \"@id\": \"CIP108:referenceHash\",\n                            \"@context\": {\n                                \"hashDigest\": \"CIP108:hashDigest\",\n                                \"hashAlgorithm\": \"CIP100:hashAlgorithm\"\n                            }\n                        }\n                    }\n                },\n                \"title\": \"CIP108:title\",\n                \"abstract\": \"CIP108:abstract\",\n                \"motivation\": \"CIP108:motivation\",\n                \"rationale\": \"CIP108:rationale\"\n            }\n        },\n        \"authors\": {\n            \"@id\": \"CIP100:authors\",\n            \"@container\": \"@set\",\n            \"@context\": {\n                \"did\": \"@id\",\n                \"name\": \"http://xmlns.com/foaf/0.1/name\",\n                \"witness\": {\n                    \"@id\": \"CIP100:witness\",\n                    \"@context\": {\n                        \"witnessAlgorithm\": \"CIP100:witnessAlgorithm\",\n                        \"publicKey\": \"CIP100:publicKey\",\n                        \"signature\": \"CIP100:signature\"\n                    }\n                }\n            }\n        }\n    }\n}"
  },
  {
    "path": "CIP-0108/cip-0108.common.schema.json",
    "content": "{\n    \"title\": \"CIP-108 Common\",\n    \"description\": \"Metadata document for Cardano governance actions, extending CIP-100\",\n    \"type\": \"object\",\n    \"required\": [\"hashAlgorithm\", \"authors\", \"body\"],\n    \"properties\": {\n        \"hashAlgorithm\": {\n            \"$ref\": \"#/definitions/hashAlgorithm\"\n        },\n        \"authors\": {\n            \"$ref\": \"#/definitions/authors\"\n        },\n        \"body\": {\n            \"$ref\": \"#/definitions/body\"\n        }\n    },\n    \"definitions\": {\n        \"hashAlgorithm\": {\n            \"type\": \"string\",\n            \"enum\": [\"blake2b-256\"],\n            \"title\": \"Hash Algorithm\",\n            \"description\": \"The algorithm used to authenticate this document externally (CIP-100)\"\n        },\n        \"authors\": {\n            \"title\": \"Authors\",\n            \"description\": \"The authors of this governance metadata (CIP-100)\",\n            \"type\": \"array\",\n            \"items\": {\n                \"$ref\": \"#/definitions/author\"\n            }\n        },\n        \"author\": {\n            \"title\": \"Author\",\n            \"description\": \"An author endorsing the content of a metadata document (CIP-100)\",\n            \"type\": \"object\",\n            \"required\": [\"name\", \"witness\"],\n            \"properties\": {\n                \"name\": {\n                    \"type\": \"string\",\n                    \"title\": \"Name\"\n                },\n                \"witness\": {\n                    \"$ref\": \"#/definitions/witness\"\n                }\n            }\n        },\n        \"witness\": {\n            \"title\": \"Witness\",\n            \"description\": \"A witness proving that the author endorses the content of the metadata\",\n            \"type\": \"object\",\n            \"properties\": {\n                \"witnessAlgorithm\": {\n                    \"title\": \"WitnessAlgorithm\",\n                    \"type\": \"string\",\n                    \"enum\": [ \"ed25519\", \"CIP-0008\"]\n                },\n                \"publicKey\": {\n                    \"title\": \"PublicKey\",\n                    \"type\": \"string\"\n                },\n                \"signature\": {\n                    \"title\": \"Signature\",\n                    \"type\": \"string\"\n                }\n            }\n        },\n        \"body\": {\n            \"title\": \"Body\",\n            \"description\": \"The body of the metadata document that is hashed to produce a signature (CIP-100)\",\n            \"type\": \"object\",\n            \"required\": [\"title\", \"abstract\", \"motivation\", \"rationale\"],\n            \"properties\": {\n                \"title\": {\n                    \"type\": \"string\",\n                    \"title\": \"Title\",\n                    \"description\": \"A brief introduction to the motivation for the governance action\"\n                },\n                \"abstract\": {\n                    \"type\": \"string\",\n                    \"title\": \"Abstract\",\n                    \"description\": \"A concise summary of the motivation and rationale for the governance action\"\n                },\n                \"motivation\": {\n                    \"type\": \"string\",\n                    \"title\": \"Motivation\",\n                    \"description\": \"Context around the problem being addressed by the on-chain action\"\n                },\n                \"rationale\": {\n                    \"type\": \"string\",\n                    \"title\": \"Rationale\",\n                    \"description\": \"Explanation of how the governance action addresses the problem outlined in 'motivation'\"\n                },\n                \"references\": {\n                    \"type\": \"array\",\n                    \"title\": \"References\",\n                    \"items\": {\n                        \"$ref\": \"#/definitions/reference\"\n                    }\n                }\n            }\n        },\n        \"reference\": {\n            \"title\": \"Reference\",\n            \"description\": \"A reference to a document\",\n            \"type\": \"object\",\n            \"required\": [\"@type\", \"label\", \"uri\"],\n            \"properties\": {\n                \"@type\": {\n                    \"type\": \"string\",\n                    \"enum\": [\"GovernanceMetadata\", \"Other\"],\n                    \"title\": \"Type\"\n                },\n                \"label\": {\n                    \"type\": \"string\",\n                    \"title\": \"Label\"\n                },\n                \"uri\": {\n                    \"type\": \"string\",\n                    \"title\": \"URI\"\n                },\n                \"referenceHash\": {\n                    \"$ref\": \"#/definitions/referenceHash\"\n                }\n            }\n        },\n        \"referenceHash\": {\n            \"title\": \"Reference Hash\",\n            \"description\": \"A hash of a reference document\",\n            \"type\": \"object\",\n            \"required\": [\"hashDigest\", \"hashAlgorithm\"],\n            \"properties\": {\n                \"hashDigest\": {\n                    \"type\": \"string\",\n                    \"title\": \"Hash\"\n                },\n                \"hashAlgorithm\": {\n                    \"$ref\": \"#/definitions/hashAlgorithm\"\n                }\n            }\n        }\n    }\n}"
  },
  {
    "path": "CIP-0108/examples/no-confidence.body.jsonld",
    "content": "{\n    \"@context\": {\n      \"@language\": \"en-us\",\n      \"CIP100\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#\",\n      \"CIP108\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#\",\n      \"hashAlgorithm\": \"CIP100:hashAlgorithm\",\n      \"body\": {\n        \"@id\": \"CIP108:body\",\n        \"@context\": {\n          \"references\": {\n            \"@id\": \"CIP108:references\",\n            \"@container\": \"@set\",\n            \"@context\": {\n              \"GovernanceMetadata\": \"CIP100:GovernanceMetadataReference\",\n              \"Other\": \"CIP100:OtherReference\",\n              \"label\": \"CIP100:reference-label\",\n              \"uri\": \"CIP100:reference-uri\",\n              \"referenceHash\": {\n                \"@id\": \"CIP108:referenceHash\",\n                \"@context\": {\n                  \"hashDigest\": \"CIP108:hashDigest\",\n                  \"hashAlgorithm\": \"CIP100:hashAlgorithm\"\n                }\n              }\n            }\n          },\n          \"title\": \"CIP108:title\",\n          \"abstract\": \"CIP108:abstract\",\n          \"motivation\": \"CIP108:motivation\",\n          \"rationale\": \"CIP108:rationale\"\n        }\n      },\n      \"authors\": {\n        \"@id\": \"CIP100:authors\",\n        \"@container\": \"@set\",\n        \"@context\": {\n          \"name\": \"http://xmlns.com/foaf/0.1/name\",\n          \"witness\": {\n            \"@id\": \"CIP100:witness\",\n            \"@context\": {\n              \"witnessAlgorithm\": \"CIP100:witnessAlgorithm\",\n              \"publicKey\": \"CIP100:publicKey\",\n              \"signature\": \"CIP100:signature\"\n            }\n          }\n        }\n      }\n    },\n    \"body\": {\n      \"title\": \"We must remove the ineffective Constitutional Committee\",\n      \"abstract\": \"The current constitutional committee have not voted for the last 100 epochs, causing an inability to pass any proposals. This is a waste of resources and must be removed.\",\n      \"motivation\": \"In order for governance to work an __active__ constitutional committee is required, without them the system grinds to a halt and important governance actions cannot be passed.\",\n      \"rationale\": \"By moving into a state of no confidence, **we** the DReps are able to vote in a new constitutional committee.\",\n      \"references\": [\n        {\n          \"@type\": \"Other\",\n          \"label\": \"A governance action that has been unable to pass\",\n          \"uri\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/blob/master/CIP-0108/examples/treasury-withdrawal.jsonld\",\n          \"referenceHash\": {\n            \"hashDigest\": \"70e79c1f12ff3c8c955bc2178a542b5994a21be163dd7655af2c5308d2643323\",\n            \"hashAlgorithm\": \"blake2b-256\"\n          }\n        }\n      ]\n    }\n}\n  "
  },
  {
    "path": "CIP-0108/examples/no-confidence.body.nq",
    "content": "_:c14n0 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#hashAlgorithm> \"blake2b-256\"@en-us .\n_:c14n0 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#hashDigest> \"70e79c1f12ff3c8c955bc2178a542b5994a21be163dd7655af2c5308d2643323\"@en-us .\n_:c14n1 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#abstract> \"The current constitutional committee have not voted for the last 100 epochs, causing an inability to pass any proposals. This is a waste of resources and must be removed.\"@en-us .\n_:c14n1 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#motivation> \"In order for governance to work an __active__ constitutional committee is required, without them the system grinds to a halt and important governance actions cannot be passed.\"@en-us .\n_:c14n1 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#rationale> \"By moving into a state of no confidence, **we** the DReps are able to vote in a new constitutional committee.\"@en-us .\n_:c14n1 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#references> _:c14n3 .\n_:c14n1 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#title> \"We must remove the ineffective Constitutional Committee\"@en-us .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#body> _:c14n1 .\n_:c14n3 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#OtherReference> .\n_:c14n3 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-label> \"A governance action that has been unable to pass\"@en-us .\n_:c14n3 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-uri> \"https://raw.githubusercontent.com/cardano-foundation/CIPs/blob/master/CIP-0108/examples/treasury-withdrawal.jsonld\"@en-us .\n_:c14n3 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#referenceHash> _:c14n0 .\n"
  },
  {
    "path": "CIP-0108/examples/no-confidence.jsonld",
    "content": "{\n    \"@context\": {\n      \"@language\": \"en-us\",\n      \"CIP100\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#\",\n      \"CIP108\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#\",\n      \"hashAlgorithm\": \"CIP100:hashAlgorithm\",\n      \"body\": {\n        \"@id\": \"CIP108:body\",\n        \"@context\": {\n          \"references\": {\n            \"@id\": \"CIP108:references\",\n            \"@container\": \"@set\",\n            \"@context\": {\n              \"GovernanceMetadata\": \"CIP100:GovernanceMetadataReference\",\n              \"Other\": \"CIP100:OtherReference\",\n              \"label\": \"CIP100:reference-label\",\n              \"uri\": \"CIP100:reference-uri\",\n              \"referenceHash\": {\n                \"@id\": \"CIP108:referenceHash\",\n                \"@context\": {\n                  \"hashDigest\": \"CIP108:hashDigest\",\n                  \"hashAlgorithm\": \"CIP100:hashAlgorithm\"\n                }\n              }\n            }\n          },\n          \"title\": \"CIP108:title\",\n          \"abstract\": \"CIP108:abstract\",\n          \"motivation\": \"CIP108:motivation\",\n          \"rationale\": \"CIP108:rationale\"\n        }\n      },\n      \"authors\": {\n        \"@id\": \"CIP100:authors\",\n        \"@container\": \"@set\",\n        \"@context\": {\n          \"name\": \"http://xmlns.com/foaf/0.1/name\",\n          \"witness\": {\n            \"@id\": \"CIP100:witness\",\n            \"@context\": {\n              \"witnessAlgorithm\": \"CIP100:witnessAlgorithm\",\n              \"publicKey\": \"CIP100:publicKey\",\n              \"signature\": \"CIP100:signature\"\n            }\n          }\n        }\n      }\n    },\n    \"hashAlgorithm\": \"blake2b-256\",\n    \"body\": {\n      \"title\": \"We must remove the ineffective Constitutional Committee\",\n      \"abstract\": \"The current constitutional committee have not voted for the last 100 epochs, causing an inability to pass any proposals. This is a waste of resources and must be removed.\",\n      \"motivation\": \"In order for governance to work an __active__ constitutional committee is required, without them the system grinds to a halt and important governance actions cannot be passed.\",\n      \"rationale\": \"By moving into a state of no confidence, **we** the DReps are able to vote in a new constitutional committee.\",\n      \"references\": [\n        {\n          \"@type\": \"Other\",\n          \"label\": \"A governance action that has been unable to pass\",\n          \"uri\": \"https://raw.githubusercontent.com/cardano-foundation/CIPs/blob/master/CIP-0108/examples/treasury-withdrawal.jsonld\",\n          \"referenceHash\": {\n            \"hashDigest\": \"70e79c1f12ff3c8c955bc2178a542b5994a21be163dd7655af2c5308d2643323\",\n            \"hashAlgorithm\": \"blake2b-256\"\n          }\n        }\n      ]\n    },\n    \"authors\": [\n      {\n        \"witness\": {\n          \"witnessAlgorithm\": \"CIP-0008\",\n          \"publicKey\": \"7ea09a34aebb13c9841c71397b1cabfec5ddf950405293dee496cac2f437480a\",\n          \"signature\": \"84582aa201276761646472657373581d610fdc780023d8be7c9ff3a6bdc0d8d3b263bd0cc12448c40948efbf42a166686173686564f458204a7ecc544559df67ece3f7f90f76c4e3e7e329a274c79a06dcfbf28351db600e5840a5dc881ddabdec69e0e4dabdd43a922ef474f7be1029facdbb9106429e17ec61deda22f2778eda21005127f0c6d10f8a4b0210b8177d03d2ae4618d2423d0807\"\n        }\n      }\n    ]\n}\n"
  },
  {
    "path": "CIP-0108/examples/treasury-withdrawal.body.jsonld",
    "content": "{\n  \"@context\": {\n    \"@language\": \"en-us\",\n    \"CIP100\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#\",\n    \"CIP108\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#\",\n    \"hashAlgorithm\": \"CIP100:hashAlgorithm\",\n    \"body\": {\n      \"@id\": \"CIP108:body\",\n      \"@context\": {\n        \"references\": {\n          \"@id\": \"CIP108:references\",\n          \"@container\": \"@set\",\n          \"@context\": {\n            \"GovernanceMetadata\": \"CIP100:GovernanceMetadataReference\",\n            \"Other\": \"CIP100:OtherReference\",\n            \"label\": \"CIP100:reference-label\",\n            \"uri\": \"CIP100:reference-uri\",\n            \"referenceHash\": {\n              \"@id\": \"CIP108:referenceHash\",\n              \"@context\": {\n                \"hashDigest\": \"CIP108:hashDigest\",\n                \"hashAlgorithm\": \"CIP100:hashAlgorithm\"\n              }\n            }\n          }\n        },\n        \"title\": \"CIP108:title\",\n        \"abstract\": \"CIP108:abstract\",\n        \"motivation\": \"CIP108:motivation\",\n        \"rationale\": \"CIP108:rationale\"\n      }\n    },\n    \"authors\": {\n      \"@id\": \"CIP100:authors\",\n      \"@container\": \"@set\",\n      \"@context\": {\n        \"name\": \"http://xmlns.com/foaf/0.1/name\",\n        \"witness\": {\n          \"@id\": \"CIP100:witness\",\n          \"@context\": {\n            \"witnessAlgorithm\": \"CIP100:witnessAlgorithm\",\n            \"publicKey\": \"CIP100:publicKey\",\n            \"signature\": \"CIP100:signature\"\n          }\n        }\n      }\n    }\n  },\n  \"body\": {\n    \"title\": \"Buy Ryan a island\",\n    \"abstract\": \"Withdraw 200000000000 ADA from the treasury so Ryan can buy an island.\",\n    \"motivation\": \"The current problem is that Ryan does not have an island, but he would really like an island.\",\n    \"rationale\": \"With these funds from the treasury will be sold for **cold hard cash**, this cash can then be used to purchase an island for Ryan. An example of this island is provided in the references.\",\n    \"references\": [\n      {\n        \"@type\": \"Other\",\n        \"label\": \"A cool island for Ryan\",\n        \"uri\": \"https://www.google.com/maps/place/World's+only+5th+order+recursive+island/@62.6511465,-97.7946829,15.75z/data=!4m14!1m7!3m6!1s0x5216a167810cee39:0x11431abdfe4c7421!2sWorld's+only+5th+order+recursive+island!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n!3m5!1s0x5216a167810cee39:0x11431abdfe4c7421!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n?authuser=0&entry=ttu\"\n      }\n    ]\n  }\n}\n"
  },
  {
    "path": "CIP-0108/examples/treasury-withdrawal.body.nq",
    "content": "_:c14n0 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#abstract> \"Withdraw 200000000000 ADA from the treasury so Ryan can buy an island.\"@en-us .\n_:c14n0 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#motivation> \"The current problem is that Ryan does not have an island, but he would really like an island.\"@en-us .\n_:c14n0 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#rationale> \"With these funds from the treasury will be sold for **cold hard cash**, this cash can then be used to purchase an island for Ryan. An example of this island is provided in the references.\"@en-us .\n_:c14n0 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#references> _:c14n2 .\n_:c14n0 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#title> \"Buy Ryan a island\"@en-us .\n_:c14n1 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#body> _:c14n0 .\n_:c14n2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#OtherReference> .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-label> \"A cool island for Ryan\"@en-us .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-uri> \"https://www.google.com/maps/place/World's+only+5th+order+recursive+island/@62.6511465,-97.7946829,15.75z/data=!4m14!1m7!3m6!1s0x5216a167810cee39:0x11431abdfe4c7421!2sWorld's+only+5th+order+recursive+island!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n!3m5!1s0x5216a167810cee39:0x11431abdfe4c7421!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n?authuser=0&entry=ttu\"@en-us .\n"
  },
  {
    "path": "CIP-0108/examples/treasury-withdrawal.jsonld",
    "content": "{\n  \"@context\": {\n    \"@language\": \"en-us\",\n    \"CIP100\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#\",\n    \"CIP108\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0108/README.md#\",\n    \"hashAlgorithm\": \"CIP100:hashAlgorithm\",\n    \"body\": {\n      \"@id\": \"CIP108:body\",\n      \"@context\": {\n        \"references\": {\n          \"@id\": \"CIP108:references\",\n          \"@container\": \"@set\",\n          \"@context\": {\n            \"GovernanceMetadata\": \"CIP100:GovernanceMetadataReference\",\n            \"Other\": \"CIP100:OtherReference\",\n            \"label\": \"CIP100:reference-label\",\n            \"uri\": \"CIP100:reference-uri\",\n            \"referenceHash\": {\n              \"@id\": \"CIP108:referenceHash\",\n              \"@context\": {\n                \"hashDigest\": \"CIP108:hashDigest\",\n                \"hashAlgorithm\": \"CIP100:hashAlgorithm\"\n              }\n            }\n          }\n        },\n        \"title\": \"CIP108:title\",\n        \"abstract\": \"CIP108:abstract\",\n        \"motivation\": \"CIP108:motivation\",\n        \"rationale\": \"CIP108:rationale\"\n      }\n    },\n    \"authors\": {\n      \"@id\": \"CIP100:authors\",\n      \"@container\": \"@set\",\n      \"@context\": {\n        \"name\": \"http://xmlns.com/foaf/0.1/name\",\n        \"witness\": {\n          \"@id\": \"CIP100:witness\",\n          \"@context\": {\n            \"witnessAlgorithm\": \"CIP100:witnessAlgorithm\",\n            \"publicKey\": \"CIP100:publicKey\",\n            \"signature\": \"CIP100:signature\"\n          }\n        }\n      }\n    }\n  },\n  \"hashAlgorithm\": \"blake2b-256\",\n  \"body\": {\n    \"title\": \"Buy Ryan a island\",\n    \"abstract\": \"Withdraw 200000000000 ADA from the treasury so Ryan can buy an island.\",\n    \"motivation\": \"The current problem is that Ryan does not have an island, but he would really like an island.\",\n    \"rationale\": \"With these funds from the treasury will be sold for **cold hard cash**, this cash can then be used to purchase an island for Ryan. An example of this island is provided in the references.\",\n    \"references\": [\n      {\n        \"@type\": \"Other\",\n        \"label\": \"A cool island for Ryan\",\n        \"uri\": \"https://www.google.com/maps/place/World's+only+5th+order+recursive+island/@62.6511465,-97.7946829,15.75z/data=!4m14!1m7!3m6!1s0x5216a167810cee39:0x11431abdfe4c7421!2sWorld's+only+5th+order+recursive+island!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n!3m5!1s0x5216a167810cee39:0x11431abdfe4c7421!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n?authuser=0&entry=ttu\"\n      }\n    ]\n  },\n  \"authors\": [\n    {\n      \"name\": \"Ryan Williams\",\n      \"witness\": {\n        \"witnessAlgorithm\": \"ed25519\",\n        \"publicKey\": \"7ea09a34aebb13c9841c71397b1cabfec5ddf950405293dee496cac2f437480a\",\n        \"signature\": \"a476985b4cc0d457f247797611799a6f6a80fc8cb7ec9dcb5a8223888d0618e30de165f3d869c4a0d9107d8a5b612ad7c5e42441907f5b91796f0d7187d64a01\"\n      }\n    }\n  ]\n}\n"
  },
  {
    "path": "CIP-0108/test-vector.md",
    "content": "# Test Vector for CIP-0108\n\nHere we create some useful definitions and some examples.\n\n## Common Context\n\n### Common Fields\n\nThe context fields which could be added to CIP-108 compliant jsonld files.\nSee [cip-0108.common.jsonld](./cip-0108.common.jsonld).\n\n### Common Fields Schema\n\nA json schema for the common context fields.\nSee [cip-0108.common.schema.json](./cip-0108.common.schema.json).\n\n## Examples\n\n### Treasury Withdrawal\n\nExample metadata document file: [treasury-withdrawal.jsonld](./examples/treasury-withdrawal.jsonld).\nBlake2b-256 of the file content (to go onchain): `311b148ca792007a3b1fee75a8698165911e306c3bc2afef6cf0145ecc7d03d4`\n\n#### Intermediate files\n\nFiles produced to articulate process, these are not necessary in implementations.\n\nBody files, used to correctly generate author's witness:\n- [treasury-withdrawal.body.jsonld](./examples/treasury-withdrawal.body.jsonld)\n- [treasury-withdrawal.body.nq](./examples/treasury-withdrawal.body.nq)\n\nBlake2b-256 hash digest of canonicalized body: `68d6fe27087457acf0164e65414238c43573192c99f30341926d1524924d71ca`\n\n### Motion of No-Confidence\n\nExample metadata document file: [no-confidence.jsonld](./examples/no-confidence.jsonld).\nBlake2b-256 of the file content (to go onchain): `87ba5c10c89484c52265b50d669b4acf116aaeb8a6fa35fbf06e5ec67cda9270`\n\n#### Intermediate files\n\nFiles produced to articulate process, these are not necessary in implementations.\n\nBody files, used to correctly generate author's witness:\n- [no-confidence.body.jsonld](./examples/no-confidence.body.jsonld)\n- [no-confidence.body.nq](./examples/no-confidence.body.nq)\n\nBlake2b-256 hash digest of canonicalized body: `4a7ecc544559df67ece3f7f90f76c4e3e7e329a274c79a06dcfbf28351db600e`\n\n## How-to Recreate Examples\n\nThis tutorial creates additional intermediate files, these are not required in implementations but are shown here to articulate the process.\n\n### Author\n\nKeys used for author property, provided here for convenience.\n\nPrivate extended signing key (hex): `105d2ef2192150655a926bca9cccf5e2f6e496efa9580508192e1f4a790e6f53de06529129511d1cacb0664bcf04853fdc0055a47cc6d2c6d205127020760652`\n\nPublic verification key (hex):\n`7ea09a34aebb13c9841c71397b1cabfec5ddf950405293dee496cac2f437480a`\n\n\nPublic verification key hash (hex): `0fdc780023d8be7c9ff3a6bdc0d8d3b263bd0cc12448c40948efbf42`\n\nMainnet public enterprize address (hex):\n`610fdc780023d8be7c9ff3a6bdc0d8d3b263bd0cc12448c40948efbf42`\n\n### 1. Create the example.jsonld's `body`\n\nCreate the `example.jsonld` file adding in all available values.\nThen remove from this document any top-level field that is not `@context` or `body`.\n\nIf recreating the [Treasury Withdrawal](#treasury-withdrawal), this will result in the intermediate file of [treasury-withdrawal.body.jsonld](./examples/treasury-withdrawal.body.jsonld).\n\n### 2. Canonicalize the `body`\n\nUsing a tool which complies with the [RDF Dataset Canonicalization](https://w3c-ccg.github.io/rdf-dataset-canonicalization/spec/), create a canonicalized representation of `example.body.jsonld`.\nOne such tool is the [JSON-LD Playground](https://json-ld.org/playground/).\nEnsure the results ends in a newline.\n\nThis creates `example.body.nq`.\n\nFor [Treasury Withdrawal](#treasury-withdrawal), this will result in the intermediate file of [treasury-withdrawal.body.nq](./examples/treasury-withdrawal.body.nq).\n\n### 3. Hash the canonicalized `body`\n\nUsing a tool create a Blake2b-256 hash of the canonicalized `example.body.nq`.\nOne such tool is the [ToolKit Bay](https://toolkitbay.com/tkb/tool/BLAKE2b_256).\n\nFor [Treasury Withdrawal](#treasury-withdrawal), this will result in: `68d6fe27087457acf0164e65414238c43573192c99f30341926d1524924d71ca`.\n\n### 4. Authors witness over the hash of canonicalized `body`\n\nUse the hash produced in [3.](#3-hash-the-canonicalized-body) as the payload for the witnessing. For a `witnessAlgorithm` of `ed25519` refer to [CIP-100 Hashing and Signatures](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#hashing-and-signatures), for `CIP-0008` refer to [CIP-108 New Witness Type](./README.md#new-witness-type).\n\nOne tool for Ed25519 signatures is [Ed25519 Online Tool](https://cyphr.me/ed25519_tool/ed.html).\n\nFor [Treasury Withdrawal](#treasury-withdrawal), we use the keys described in [Author](#author) resulting in: `a476985b4cc0d457f247797611799a6f6a80fc8cb7ec9dcb5a8223888d0618e30de165f3d869c4a0d9107d8a5b612ad7c5e42441907f5b91796f0d7187d64a01`.\n\n### 5. Add other properties to example.jsonld\n\nWe can go back to our `example.body.jsonld` and now add in all missing properties, from outside of `body`.\n- Adding the `hashAlgorithm` of `blake2b-256`.\n- Adding the `authors` with a single entry, including information of our `witness` goes into the `signature`.\n\nBy adding this information we create our `example.jsonld`.\n\nFor [Treasury Withdrawal](#treasury-withdrawal), this will result in [treasury-withdrawal.jsonld](./examples/treasury-withdrawal.jsonld).\n\n### 6. Hash example.jsonld\n\nTo be able to create a final metadata hash which can be attached on-chain we simply hash the content of the file [Treasury Withdrawal](#treasury-withdrawal.jsonld) as is.\n\nThis results is: `311b148ca792007a3b1fee75a8698165911e306c3bc2afef6cf0145ecc7d03d4`.\n\n### 7. Submit to chain\n\nWe can then host `example.jsonld` somewhere easily accessible following [CIP-100 Best Practices](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#best-practices).\n\nThen at submission time of the governance metadata anchor we can provide the on-chain transaction both the URI to the hosted `example.jsonld` but also the hash generated via [6.](#6-Hash-examplejsonld).\n"
  },
  {
    "path": "CIP-0109/README.md",
    "content": "---\nCIP: 109\nTitle: Modular Exponentiation Built-in for Plutus Core\nStatus: Proposed\nCategory: Plutus\nAuthors:\n    - Kenneth MacKenzie <kenneth.mackenzie@iohk.io>\n    - Michael Peyton Jones <michael.peyton-jones@iohk.io>\n    - Iñigo Querejeta-Azurmendi <inigo.querejeta@iohk.io>\n    - Thomas Vellekoop <thomas.vellekoop@iohk.io>\nImplementors:\n    - Michael Peyton Jones <michael.peyton-jones@iohk.io>\n    - Thomas Vellekoop <thomas.vellekoop@iohk.io>\nCreated: 2023-10-05\nLicense: CC-BY-4.0\n---\n## Abstract\nThis CIP proposes an extension of the current plutus functions to provide support for the efficient calculation of modular exponentiation with inverses.\n\n## Motivation: why is this CIP necessary?\nModular exponentiation is a cornerstone operation in numerous cryptographic protocols. The availability of such a function directly within Plutus will provide a more efficient and reliable means to perform this crucial computation. Therefore, the integration of such a Plutus core built-in is imperative to enhance cryptographic functionalities within the ecosystem.\n\nMore concretely, the key area where this function would contribute is that of finite field arithmetic, which is a basis for elliptic curves. In this context, a finite field is a set of integers modulo a prime number `p`. On this set, we have the basic operations of addition, multiplication, additive inversion (negation) and the multiplicative inversion (reciprocal), all reduced modulo the prime number `p`.\n\nWith the current built-in functions, most of these operations can be implemented relatively cheaply, except the reciprocal. This function can be implemented via either the Extended Euclidean algorithm or using Fermat's little theorem. Using the preliminary cost-model for plutus V3, both implementations still [consume](https://github.com/perturbing/mod-exp-bench/tree/558b6a47cb18d063b6a7324a15087f87fa3da673) around ~5% and ~9% of the CPU budget on mainnet. These benchmarks are performed for the scalar field of the BLS12-381 curve, which has a 255 bit prime modulus.\n\nThe result is that doing such computation in a practical setting on-chain is costly, and other methods should be used to find this multiplicative inverse. A cumbersome method for solving this issue, is calculating the inverse off-chain and bringing it in scope via a redeemer as a claimed inverse of another element. This method works, as one can cheaply check that the claimed inverse is indeed the unique inverse with one multiplication, one modulo reduction and one equality check with the multiplicative identity. In math notation this means that for a field element `a`, we off-chain compute `claimed_inverse_a`, such that on-chain we can check: `claimed_inverse_a * a = id`.\n\nThe drawback of this technique is that by transferring the calculation off-chain, we incur additional fees due to the increased size of the transaction, as CPU units are cheaper. The creator of the transaction is also burdened by this computation, which often precedes more intricate, non-trivial cryptographic calculations. In the application of zero knowledge, this calculation if often implemented in low-level code, and used via bindings, meaning that extracting these intermediary values breaks existing code and interfaces.\n\nIn conclusion, integrating modular exponentiation as a core built-in within Plutus is not only essential for enhancing cryptographic capabilities, but also for optimizing on-chain computations. The current approach, which offloads certain calculations like finding multiplicative inverses to off-chain processes, is inefficient and costly in terms of transaction size and computational burden on the transaction creators. Incorporating this function directly into Plutus will streamline these operations, reduce transaction costs, and maintain the integrity of existing tools, thereby significantly advancing the Plutus ecosystem's functionality and user experience.\n\nA nonexclusive list of cryptographic protocols that use a field and would benefit from having this built-in are:\n\n1. The verification of pairing based zero-knowledge proofs over BLS12-381. This pairing curve has a base field and a scalar field, with primes of size 381 and 255 bits respectively. In, for example, the proof system plonk, a verifier performs one reciprocal for each public input in the 255 bit scalar field.\n2. Onchain public key aggregation for Schnorr over SECP256k1: effectively, this aggregation is the point addition of the two keys on the curve, which requires one reciprocal in the SECP256k1 base field (using a 256 bit prime).\n3. A more interoperable interface for the BLS-12-381 built-ins: currently, the BLS-12-381 built-ins only expose a compressed version of a point, containing the `x` coordinate and some marked bits to describe how one can find the corresponding `y` in the base field. This calculation of finding `y` requires modular exponentiation in the field.\n\n## Specification\nModular exponentiation is mathematically defined as the equivalence relation\n\n$$\na \\equiv b^{e} (\\bmod{m})\n$$\n\nHere we have that the base $b$ is an integer, the exponent $e$ a non-negative integer and the modulus $m$ a positive integer. To be more specific, we want $e$ to be larger or equal to zero, and $m$ is larger than zero. This is because what we are effectively doing, is multiplying $e$ copies of $b$ and a modulo reduction by $m$. In this context, multiplying a negative number of copies of $b$ has no definition.\n\n\n$$\n\\begin{equation}\na \\equiv \\underbrace{(b \\times b \\times ... \\times b)}_{e \\textrm{ times}} (\\bmod{m} )\n\\end{equation}\n$$\n\nThat said, in the context of multiplicative inversion, a negative exponent can be interpreted as taking the exponent of the inverse of the base number. That is\n\n$$\n\\begin{equation}\nb^{-e} (\\bmod{m}) := (b^{-1})^{e} (\\bmod{m})\n\\end{equation}\n$$\n\nWe propose to also include this extension to the plutus built-in, for optimized inversion when this is possible. This is inversion is not guaranteed to exist for all numbers $b$, only when the modulus $m$ is a prime number this is guaranteed. We also propose that the built-in fails if this inverse does not exist, and if a modulus is provided that is smaller than one.\n\n### Function definition\nWith the above, we define a new Plutus built-in function with the following type signature\n\n```hs\nmodularExponentiation :: Integer -> Integer -> Integer -> Integer\n```\nhere the first argument is the base, the second the exponent and the third the modulus. As mentioned above, the behavior of this function is that it fails if the modulus is not a positive integer, or if the inverse of the base does not exist for a negative exponent. For the lower level implementation, we propose the usage of the `integerPowMod` function in the `ghc-bignum` packages. This function has the desired functionality, is optimized, and is easy to integrate in the plutus stack.\n\n### Cost model\nThe computational impact of modular exponentiation is complexified by it having three arguments. That said, observe that the integers used can always be bound by the modulus. Preliminary [benchmarks](https://github.com/perturbing/expFast-bench/tree/cca69b842050de9523493d52c20384bc50c80b22) on the time consumption of this `integerPowMod` function show that it can be costed constant in the size of its first argument (the base) and linear in the other two.\n\n## Rationale: how does this CIP achieve its goals?\nIntegrating this function directly into Plutus will streamline cryptographic operations, reduce transaction costs, and uphold the integrity of existing cryptographic interfaces. It addresses current inefficiencies and enhances the cryptographic capabilities of the Plutus platform.\n\nFor completeness and an historic perspective, the above functionality can also be attained by a new built-in function that performs normal exponentiation, after which one can reduce with the already present built-in function `ModInteger`. In the creation of this CIP, this possibility was discussed but put aside. This method has the flaw that the intermediate value of these integers is not bound. Meaning that memory consumption is not efficient for practical use in this setting.\n\n## Path to Active\n\n### Acceptance Criteria\n\nWe consider the following criteria to be essential for acceptance:\n\n- [ ] The PR for this functionality is merged in the Plutus repository.\n- [ ] This PR must include tests, demonstrating that it behaves as the specification requires in this CIP.\n- [ ] A benchmarked use case is implemented in the Plutus repository, demonstrating that realistic use of this primitive does, in fact, provide major cost savings.\n\n### Implementation Plan\n\n- [x] IOG Plutus team consulted and accept the proposal.\n- [x] Author to provide preliminary benchmarks of time consumption.\n  - https://github.com/perturbing/expFast-bench/tree/cca69b842050de9523493d52c20384bc50c80b22\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0110/README.md",
    "content": "---\nCIP: 110\nTitle: Plutus v1 Script References\nStatus: Active\nCategory: Plutus\nAuthors:\n    - Pi Lanningham <pi@sundaeswap.finance>\nImplementors:\n    - Alexey Kuleshevich <alexey.kuleshevich@iohk.io>\nDiscussions:\n - https://twitter.com/SmaugPool/status/1737454984147390905\n - https://twitter.com/Quantumplation/status/1737704936089985339\n - https://twitter.com/SmaugPool/status/1737814894710231161\n - https://github.com/IntersectMBO/cardano-ledger/issues/3965\nCreated: 2023-12-20\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nDespite making up less than half the transactions on Cardano, Plutus v1 scripts occupy around 40% of the total block space since chain inception, and sometimes higher during periods of peak activity. Increasing the space available to blocks is risky, as it impacts the block propagation time. This proposal puts forth a simple way to reduce this strain.\n\n## Motivation: why is this CIP necessary?\n\nPlutus v2 introduced a way to publish scripts on-chain, and *reference* those scripts to satisfy the witness requirement. However, because this was done via a new field on the transaction (i.e. \"Reference Inputs\"), which shows up in the script context, this feature is not backwards compatible with Plutus v1.\n\nHowever, of the 151gb it takes to represent the 6 year history of the chain, roughly 60 gb of that (nearly 40%) can be attributed to the wasted space from repeating the same scripts in the last 2 years. This analysis was further confirmed by IOG in [this](https://github.com/IntersectMBO/cardano-ledger/issues/3965) issue.\n\nIt would be one thing if this was an issue mostly felt before or shortly after the Babbage hard-fork. It was assumed at the time that Plutus v2 would become a dominant player, and that usage of Plutus v1 contracts would die off. However, looking at recent trends in late 2023, it's clear this isn't happening.\n\nLooking at recent trends [through late 2023](https://twitter.com/SmaugPool/status/1737454984147390905/photo/1), considering all scripts included in transactions, Plutus v1 hovered at or slightly below 50% of all scripts in transactions. However, comparing the size of transactions which execute scripts scripts, [Plutus v1 scripts make up 90% of that space](https://twitter.com/SmaugPool/status/1737454984147390905/photo/2).\n\nLooking at periods of saturation can also help us understand where the limits of the chain are. Periods where activity is low and the chain is underutilized can skew our view of the problem: it largely doesn't matter to end users what percentage of space is occupied by different script versions, because the user experience is largely unimpacted and transactions are able to fit into the next block regardless. However, in periods of high activity, when blocks are nearly full, we get a better picture of where user activity is allocating that space, and where the cost savings would be most beneficial. For example, [epoch 455](https://twitter.com/SmaugPool/status/1737814898648691195) saw nearly 100% block usage for a full epoch, of which an average of 48% (and sometimes as high as 75%) of the space was occupied by scripts, presumably much of that Plutus v1 scripts.\n\nThis problem isn't going away: while protocols may migrate to new Plutus v2 or v3 scripts, these old protocols will exist forever. Liquidity locked in these scripts, sometimes permanently, will mean that there is always an arbitrage opportunity that incentivizes a large portion of the block to be occupied by continually republishing these v1 scripts.\n\nAdditionally, raising the block size is considered incredibly sensitive, as it impacts block propagation times.\n\nA simple, backwards compatible mechanism for plutus v1 protocols to satisfy the script witness requirement, without changing the script context and causing breaking changes for Plutus v1 scripts, would alleviate quite literally millions of dollars worth of storage requirements, user pain, and developer frustration.\n\n## Specification\n\nWe propose relaxing the ledger rule that fails Plutus v1 scripts in transactions that have reference inputs, and to construct a script context that excludes reference inputs.\n\nThe ledger rule shouldn't change in other ways: for example, Plutus v1 scripts should still fail in the presence of inline datums or reference scripts on spent transaction inputs.\n\n## Rationale: how does this CIP achieve its goals?\n\nThe main concern with this relates to backwards compatibility. The ledger makes very strong commitments regarding the behavior of scripts: any observable change represents a risk that there is some script out there that will either be unspendable when it should be, or spendable when it should not be.\n\nBecause of this, any such change which violates this must satisfy a burden of proof with regards to both the benefits and the risks. This was in fact considered [in the original CIP](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0031#how-should-we-present-the-information-to-scripts), and at the time, it was decided that the justification would likely not meet that high bar.\n\nThus, as a rationale for this CIP, we repeat that analysis, hopefully with a different conclusion.\n\nIn terms of benefit, this approach would immediately allow all major plutus v1 dApps to reduce their transaction sizes dramatically. Some napkin math for both Sundae and Minswap shows that this would cut around 85% of the transaction size for each transaction; Considering the portion of block space currently taken up by Plutus v1 scripts, this represents a significant savings.\n\nIt is hard to overstate the long-term positive impact that this change could have for real users of the Cardano blockchain.\n\nIn terms of the risks, there are four main risks to consider:\n\n - Funds that should be spendable are suddenly not spendable;\n \n   In this case, a user could simply continue to use the existing witness mechanism to provide the scripts, and those funds become spendable again.\n\n - Funds that should not be spendable are suddenly spendable;\n \n   In this case, it is very hard to imagine a scenario where this would be true that isn't crafted intentionally. It would have to be some script that was dependent on the transaction fee being above a certain threshold, which is already a dangerous assumption to make given the updatable protocol parameters. In other instances (such as the change to how the minimum UTXO output is calculated) this kind of risk hasn't been an obstacle.\n\n - The execution units change, without changing the outcome, resulting in a different cost for the user;\n\n   In this case, the cost would only go down, and it is again hard to imagine a scenario where this is at material risk of violating some protocols integrity in a way that is not already compromised.\n\nGiven the parallel plans to include reference scripts in the cost of the transaction, outlined [here](https://github.com/IntersectMBO/cardano-ledger/issues/3952), further mitigates these concerns.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Review of this proposal by the relevant subject matter experts\n- [x] Implement the change in the cardano-ledger and cardano-node repositories\n- [x] Include this change in a relevant hard fork\n  - Included within the Chang #1 hardfork\n\n### Implementation Plan\n\n- [x] Update the formal Agda specification\n- [x] Implement [minFeeRefScriptCoinsPerByte] or similar approach, as described [here](https://github.com/IntersectMBO/cardano-ledger/issues/3952)\n- [x] Update the implementation [here](https://github.com/IntersectMBO/cardano-ledger/blob/fdc366df654fc02b1668012342732d41eaa099fe/eras/babbage/impl/src/Cardano/Ledger/Babbage/TxInfo.hs#L94-L97)\n - [x] Update property based tests to cover these scenarios\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0112/README.md",
    "content": "---\nCIP: 112\nTitle: Observe Script Type\nStatus: Proposed\nCategory: Plutus\nAuthors:\n    - Philip DiSarro <info@anastasialabs.com>\nImplementors: []\nDiscussions: \n    - Original PR: https://github.com/cardano-foundation/CIPs/pull/749\nCreated: 2024-01-08\nLicense: CC-BY-4.0\n---\n\n## Abstract\nWe propose to introduce a new Plutus scripts type `Observe` in addition to those currently available (spending, certifying, rewarding, minting, drep). The purpose of this script type is to allow arbitrary validation logic to be decoupled from any ledger action. \nSince observe validators are decoupled from actions, you can run them in a transaction without needing to perform any associated action (ie you don't need to consume a script input, or mint a token, or withdraw from a staking script just to execute this validator). \nAdditionally, we propose to introduce a new assertion to native scripts that they can use to check that a particular script hash is in `required_observers` (which in turn enforces that the script must be executed successfully in the transaction). This addresses a number of technical issues discussed in other CIPs and CPS such as the redundant execution of spending scripts, and the inability to effectively use native scripts in conjunction with Plutus scripts. \n\n## Motivation: why is this CIP necessary?\nOften in a plutus validator you want to check \"a particular (different) Plutus script checked this transaction\", but it's annoying (and wasteful) to have to have to lock an output in a script and then check if that output is consumed, or mint a token, or whatever else just to trigger script validation. \n\nCurrently the main design pattern used to achieve this is a very obscure trick involving staking validators and the fact that you can withdraw 0 from a staking validator to trigger the script validation. A summary of the trick is:\nImplement all the intended validation logic in a Plutus staking validator, we will call this validator `s_v`. To check that this validator was executed in the transaction you check if the credential of `s_v` (`StakingCredential`) is present in `txInfoWdrl`, this guarantees that `s_v` was checked in validation. \nThis relies on the fact that unlike in `txInfoMint` the ledger does not filter out 0 amount entries in `txInfoWdrl`. This means that you are allowed to build transactions that withdraw zero from a staking credential which in-turn triggers the staking script associated with that credential to execute in the transaction,\nwhich makes it available in `txInfoWdrl`. This is a enables a very efficient design pattern for checking logic that is shared across multiple scripts.\n\nFor instance, a common design pattern is a token based forwarding validator in which the validator defers its logic to another validator by checking that a state token is present in one of the transaction inputs:\n```haskell\nforwardNFTValidator :: AssetClass -> BuiltinData -> BuiltinData -> ScriptContext -> () \nforwardNFTValidator stateToken _ _ ctx = assetClassValueOf stateToken (valueSpent (txInfo ctx)) == 1\n```\nThis pattern is common in protocols that use the batcher architecture. Some protocols improve on the pattern by including the index of the input with the state token in the redeemer:\n```haskell\nforwardNFTValidator :: AssetClass -> BuiltinData -> Integer -> ScriptContext -> () \nforwardNFTValidator stateToken _ tkIdx ctx =  assetClassValueOf stateToken (txInInfoResolved (elemAt tkIdx (txInfoInputs (txInfo ctx)))) == 1 \n\nforwardMintPolicy:: AssetClass -> Integer -> ScriptContext -> () \nforwardMintPolicy stateToken tkIdx ctx =  assetClassValueOf stateToken (txInInfoResolved (elemAt tkIdx (txInfoInputs (txInfo ctx)))) == 1 \n```\nThe time complexity of this validator is **O(n)** where n is the number of tx inputs. This logic is executed once per input being unlocked  / currency symbol being minted. \nThe redundant execution of searching the inputs for a token is the largest throughput bottleneck for these DApps; it is **O(n*m)** where n is the number of inputs and m is the number of `forwardValidator` inputs + `forwardValidator` minting policies.\nUsing the stake validator trick, the time complexity of the forwarding logic is improved to **O(1)**. The forwardValidator logic becomes:\n```haskell\nforwardWithStakeTrick:: StakingCredential -> BuiltinData -> BuiltinData -> ScriptContext -> ()\nforwardWithStakeTrick obsScriptCred tkIdx ctx = fst (head stakeCertPairs) == obsScriptCred \n  where \n    info = txInfo ctx \n    stakeCertPairs = AssocMap.toList (txInfoWdrl info)\n\nstakeValidatorWithSharedLogic :: AssetClass -> BuiltinData -> ScriptContext -> () \nstakeValidatorWithSharedLogic stateToken _rdmr ctx = assetClassValueOf stateToken (valueSpent (txInfo ctx)) == 1\n```\nFor the staking validator trick (demonstrated above), we are simply checking that the StakingCredential of the the staking validator containing the shared validation logic is in the first pair in `txInfoWdrl`. If the StakingCredential is present in `txInfoWdrl`, that means the staking validator (with our shared validation logic) successfully executed in the transaction. This script is **O(1)** in the case where you limit it to one shared logic validator (staking validator), or if you don't want to break composability with other staking validator, \nthen it becomes **O(obs_N)** where `obs_N` is the number of Observe validators that are executed in the transaction as you have to verify that the StakingCredential is present in `txInfoWdrl`.\n\nThe proposed changes in this CIP enable this design pattern to exist indepedently from implementation details of stake validators and withdrawals, and improve efficiency and readability for validators that implement it. Furthermore, with the proposed extension to native scripts, we are able to completely get rid of the redundant spending script executions like so:\n```haskell\nobservationValidator ::  AssetClass -> BuiltinData -> ScriptContext -> ()\nobservationValidator stateToken _redeemer ctx = assetClassValueOf stateToken (valueSpent (txInfo ctx)) == 1\n```\nWe simply include the script hash of the above `observationValidator` in the `required_observers` field in the transaction body and we lock\nall the UTxOs that we would like to share the same spending condition into the following native script:\n```json\n{\n  \"type\": \"observer\",\n  \"keyHash\": \"OUR_OBSERVATION_SCRIPT_HASH\"\n}\n```\nThe above solution (enabled by this CIP) is more clear, concise, flexible and efficient than the alternatives discussed above.\n\n## Specification\nThe type signature of this script type will be consistent with the type signature of minting and staking validators, namely:\n```haskell\nRedeemer -> ScriptContext -> () \n```\n\nThe type signature of the newly introduced `Purpose` will be:\n```haskell\nObserve Integer -- ^ where integer is the index into the observations list.\n```\n\n### Script context\n\nScripts are passed information about transactions via the script context.\nWe propose to augment the script context to include information about the observation scripts that are executed in the transaction.\n\nChanging the script context will require a new Plutus language version in the ledger to support the new interface.\nThe change is: a new field is added to the script context which represents the list of observers that must be present in the transaction. \n\nThe interface for old versions of the language will not be changed.\nScripts with old versions cannot be spent in transactions that include observation scripts, attempting to do so will be a phase 1 transaction validation failure.\n\nA new field will be introduced into the script context:\n\n```haskell\n-- | TxInfo for PlutusV3\ndata TxInfo = TxInfo\n  { txInfoInputs                :: [V2.TxInInfo]\n  , txInfoReferenceInputs       :: [V2.TxInInfo]\n  , txInfoOutputs               :: [V2.TxOut]\n  , txInfoFee                   :: V2.Value\n  , txInfoMint                  :: V2.Value\n  , txInfoTxCerts               :: [TxCert]\n  , txInfoWdrl                  :: Map V2.Credential Haskell.Integer\n  , txInfoValidRange            :: V2.POSIXTimeRange\n  , txInfoSignatories           :: [V2.PubKeyHash]\n  , txInfoRedeemers             :: Map ScriptPurpose V2.Redeemer\n  , txInfoData                  :: Map V2.DatumHash V2.Datum\n  , txInfoId                    :: V2.TxId\n  , txInfoVotingProcedures      :: Map Voter (Map GovernanceActionId VotingProcedure)\n  , txInfoProposalProcedures    :: [ProposalProcedure]\n  , txInfoCurrentTreasuryAmount :: Haskell.Maybe V2.Value\n  , txInfoTreasuryDonation      :: Haskell.Maybe V2.Value\n  , txInfoObservations          :: [V2.Credential] -- ^ newly introduced list of observation scripts that executed in this tx. \n  }\n```\n\n### CDDL\n\nThe CDDL for transaction body will change as follows to reflect the new field.\n```\ntransaction_body =\n  { 0 : set<transaction_input>             ; inputs\n  , 1 : [* transaction_output]\n  , 2 : coin                               ; fee\n  , ? 3 : uint                             ; time to live\n  , ? 4 : certificates\n  , ? 5 : withdrawals\n  , ? 7 : auxiliary_data_hash\n  , ? 8 : uint                             ; validity interval start\n  , ? 9 : mint\n  , ? 11 : script_data_hash\n  , ? 13 : nonempty_set<transaction_input> ; collateral inputs\n  , ? 14 : required_observers              ; Upgraded `required_signers`\n  , ? 15 : network_id\n  , ? 16 : transaction_output              ; collateral return\n  , ? 17 : coin                            ; total collateral\n  , ? 18 : nonempty_set<transaction_input> ; reference inputs\n  , ? 19 : voting_procedures               ; Voting procedures\n  , ? 20 : proposal_procedures             ; Proposal procedures\n  , ? 21 : coin                            ; current treasury value\n  , ? 22 : positive_coin                   ; donation\n  }\n; addr_keyhash variant is included for backwards compatibility and will be \n; deprecated in the future era, because `credential` already contains `addr_keyhash`.\nrequired_observers = nonempty_set<credential / addr_keyhash>\n```\n\nWe rename the `required_signers` field to `required_observers`, promoting it from a list of public key hashes to a list of credentials (i.e. either a KeyHash or ScriptHash). This is consistent with other parts of the transaction that are unlocked by a script or a key witness. `required_observers` (field 14) is a set of credentials that must be satisfied by the transaction. For public key credentials, if the corresponding signature is not in the witness set, the transaction will fail in phase 1. For script credentials, if the associated scripts is not present in the witness set or as a reference script and executed in the transaction, the transaction will fail in phase 1 validation. This way Plutus scripts can check the script context to know which observation scripts were executed in the transaction. Similarly, since native script conditions use the `required_observers` field, it is natural that they are now able to require that other scripts observed the transaction (an extension of the ability to check for the presence of key signatures). \n\n### Native Script Extension\n\nThe BNF notation for the abstract syntax of native scripts change as follows to reflect the new field.\n\n```BNF\n<native_script> ::=\n             <RequireSignature>  <vkeyhash>\n           | <RequireObserver>   <scripthash>\n           | <RequireTimeBefore> <slotno>\n           | <RequireTimeAfter>  <slotno>\n\n           | <RequireAllOf>      <native_script>*\n           | <RequireAnyOf>      <native_script>*\n           | <RequireMOf>        <num> <native_script>*\n```\n\nNative scripts are typically represented in JSON syntax. We propose the following JSON representation for the `RequireObserver` constructor:\n```JSON\n{\n  \"type\": \"observer\",\n  \"keyHash\": \"OBSERVATION_SCRIPT_HASH\"\n}\n```\n\n\n## Rationale: how does this CIP achieve its goals?\n\nCurrently Plutus scripts (and native scripts) in a transaction will only execute when the transaction performs the associated ledger action (ie. a Plutus minting policy will only execute if the transaction mints or burns tokens with matching currency symbol). The only exception is the withdraw zero trick which relies on an obscure mechanic where zero amount withdrawals are not filtered by the ledger. Now using `required_observers` we can specify a list of scripts (supports both native and Plutus scripts) to be executed in the transaction independent of any ledger actions. The newly introduced `txInfoObservations` field in the script context provides a straightforward way for scripts to check that \"a particular script validated this transaction\".\n\nThis change is not backwards-compatible and will need to go into a new Plutus language version.\n\n### Alternatives \n\n- We could decide to accept the withdraw-zero staking script trick as an adequate solution, and just preserve the nonsensical withdraw zero case in future language versions. \n- The staking script trick could be abstracted away from the developer by smart contract languages that compile to UPLC. \n    - This can be dangerous since by distancing the developer from what is actually happening you open up the door for the developer to act on misguided assumptions. \n\n## Path to Active\n\n### Acceptance Criteria\n- [ ] These rules included within a official Plutus version, and released via a major hard fork.\n      \n### Implementation Plan\n- [ ] Passes all requirements of both Plutus and Ledger teams as agreed to improve Plutus script efficiency and usability.\n      \n## Copyright\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n[Apache-2.0]: http://www.apache.org/licenses/LICENSE-2.0\n"
  },
  {
    "path": "CIP-0114/README.md",
    "content": "---\nCIP: 114\nTitle: CBOR Tags Registry\nStatus: Proposed\nCategory: Tools\nAuthors:\n  - Steven Johnson <steven.johnson@iohk.io>\nImplementors: N/A\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/752\nCreated: 2020-01-25\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nCardano typically uses CBOR to encode structured data.\nFor example, the Block data and individual transactions are all CBOR encoded.\n\nCIPs define many of the individual data structures used by both the Ledger and Metadata attached to transactions.\nThis CIP defines a set of policies for the creation and maintenance of new CBOR tags for Cardano Data structures.\nIt also collates a list of all currently defined Tags for easy reference.\nFinally, it recommends best practice for registering those Tags with IANA.\n\n## Motivation: why is this CIP necessary?\n\nThis CIP is motivated by the problems outlined in [CPS-0014].\n\n## Specification\n\n[CBOR] defines a schemaless method of encoding data.\nPart of that specification (3.4) defines how generic data can be tagged to assist in the proper interpretation of the encoded data.\nCurrently all Cardano data structures in both the Ledger and metadata do not widely use Tags.\nNor is there any standardized way to create a new tag for a Cardano data structure.\n\n[IANA] maintains a registry of all [CBOR] Tags.\nAnyone can submit a request to register a tag in the range of 32768-18446744073709551615.\nThese are known as *First Come First Served* tags.\nTo register a tag, an applicant must demonstrate where the Tag is defined, and also the format of the data.\nIf the data structure is defined by a CIP, the natural place to define its Tag is also in a CIP.\n\n### Defining Tags\n\nTags can be defined for any data structure defined by a CIP or commonly used by Cardano.\nExamples of commonly used data structures could be those encoded inside the Cardano block or transaction.\nTags should be defined by the following process:\n\n1. If a [CBOR] tag is desired for an application, first the applicant MUST check that one does not already exist.\n   If it does, then the pre-existing TAG must be used, as well as the defined canonical encoding.\n   This is to prevent redundant and wasteful re-tagging of the same data structures.\n2. Otherwise the application may define a [CBOR] Tag for the necessary data structures as follows:\n   1. The CIP which defines the data structure can also define a Tag and its encoding in [CBOR]. **(Preferred)**\n   2. Alternatively, if the data structure is already defined by a CIP, then there are two possibilities.\n      1. The original CIP is edited to add Tags and their canonical representation in [CBOR].\n      2. A supplementary CIP can be made that simply defines the TAG and canonical representation.\n        Such a CIP would reference the original CIP to define the data structure itself.\n   3. CIP authors would select an unused [CBOR] Tag in the [IANA Registry][IANA], and assign it to their data structure.\n      1. The CIP should add to its \"Path to Active\" that the selected Tag/s have been successfully registered with [IANA].\n         This allows the CIP to be edited with the final Tag once [IANA] have accepted and published the registration.\n   4. CIP Authors would include in their PR an addition to the Cardano [CBOR Tag Registry](#tag-registry).\n\n### Registration of TAGS with IANA\n\nRegistration of the Tag with IANA is the sole responsibility of the CIP author.\nCIPs should not proceed to Active if they define unregistered Tags on data structures.\nThis is to prevent abuse of the Tag number space.\n\n*NOTE: Tags defined by any CIP or marked as not registered with IANA in the `registry.json` MUST NOT be used outside of testing.\nTags not registered with IANA are subject to change during the IANA registration process.*\n\n### Usage of Tags within a CIP\n\nCIPs, such as metadata CIPs can freely define when and how tags are used with any CBOR data structure.\nFor example, a CIP may require that a particular field is always tagged.\nThey may also define that a field need not be tagged if it is the typical data structure.\nOnly less common or unusual data structures would be tagged in this case.\nA CIP may also define that Tags are not used, and only the canonical encoding.\n\n### Canonical Encoding\n\nWhen a Tag is defined, its Canonical encoding must also be defined.\nThis is to ensure that all data that is tagged is encoded in a uniform manor.\nEven if a CIP does NOT use a tag, it should preferably use the canonical encoding for the data structure.\nThis is to prevent fragmentation and confusion amongst compliant encoders and decoders of the various data structures.\n\nIf a pre-existing data structure is being tagged, then its most common current encoding should be used as the Canonical encoding.\nIt should not be re-defined.\n\nFor example `ED25519-BIP32` public keys are commonly encoded as a byte array.\nThe array is 32 bytes long with the most significant byte of the key appearing first in the array.\nIf a Tag is defined for this public key, it should simply define the Tag.\nIts Canonical encoding MUST follow this common encoding scheme.\n\nIf a CIP does not refer to a Tag, nor the Canonical encoding specification for the data structure,\nAND it does not define an alternative encoding.\nThen the application implementing the encoding should assume it is encoded canonically.\nThis helps ensure backward compatibility with pre-existing CIPs where Tags are not used.\n\n### Tag Registry\n\nSimilar to [CIP-0010] this CIP defines a registry of all known tags.\nThe format of the registry is defined by the json schema: [CIP Tag Registry Schema].\nNew entries MUST be added to the [CIP Tag Registry] in a PR for a CIP that first defines a new CBOR Tag.\nThey MUST be updated when the Tag is accepted or rejected by IANA.\nThe registry clearly notes if the tag is currently known to be registered or not.\nIf a Tag is not yet registered then any implementor must be aware that its possible the Tag number could change and is not final.\nUnregistered tags MUST not be used in any main net on-chain metadata or data structures.\nThey should only be used for testing purposes until registration is complete.\n\n## Rationale: how does this CIP achieve its goals?\n\nCreating a [registry][CIP Tag Registry] for `CIP Tag` values has the following benefit:\n\n1) It makes it easy for developers to know which `CIP Tags` to use, and if they have been registered or not.\n2) It makes it easy to avoid collisions with other standards that use CIP Tags.\n3) It helps CIP authors to find appropriate CIP tags for their use case, or to define new tags.\n\nThe process for defining and registering Tags should help provide clarity about how a CIP tag can be defined.\nIt also provides clarity on the responsibility CIP authors have to register the tags they create.\nIf a CIP author is not prepared to take on that responsibility they should not create a Tag.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] [CPS-0014] is accepted.\n- [ ] At least 1 CIPs are accepted into the Tag registry for historical tags.\n- [ ] At least 1 CIPs are accepted into the Tag registry for new tags.\n- [ ] At least 3 CIPs of any kind are accepted into the Tag registry.\n\n### Implementation Plan\n\n- [ ] Author to write the first CBOR tag CIP.\n\n## References\n\n- [CPS-0014 -  Register of CBOR Tags for Cardano Data structures][CPS-0014]\n- [RFC8949 - Concise Binary Object Representation (CBOR)][CBOR]\n- [IANA CBOR Tag Registry][IANA]\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n\n[CPS-0014]: https://github.com/cardano-foundation/CIPs/tree/master/CPS-0014\n[CBOR]: https://datatracker.ietf.org/doc/rfc8949/\n[IANA]: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml\n[CIP Tag Registry Schema]: ./registry.schema.json\n[CIP Tag Registry]: ./registry.json\n"
  },
  {
    "path": "CIP-0114/registry.json",
    "content": "[\n  {\n    \"cbor_tag\": 32771,\n    \"iana_registered\": false,\n    \"description\": \"ED25519-BIP32 Private Key\",\n    \"cip\": \"CIP-0115\"\n  },\n  {\n    \"cbor_tag\": 32772,\n    \"iana_registered\": false,\n    \"description\": \"ED25519-BIP32 Extended Private Key\",\n    \"cip\": \"CIP-0115\"\n  },\n  {\n    \"cbor_tag\": 32773,\n    \"iana_registered\": false,\n    \"description\": \"ED25519-BIP32 public-key\",\n    \"cip\": \"CIP-0115\"\n  },\n  {\n    \"cbor_tag\": 32774,\n    \"iana_registered\": false,\n    \"description\": \"ED25519-BIP32 Signature\",\n    \"cip\": \"CIP-0115\"\n  }\n]"
  },
  {
    "path": "CIP-0114/registry.schema.json",
    "content": "{\n    \"$schema\": \"http://json-schema.org/draft-07/schema\",\n    \"$id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0114/registry.schema.json\",\n    \"type\": \"array\",\n    \"title\": \"CBOR Tag Registry\",\n    \"description\": \"JSON schema for CBOR Tag registry\",\n    \"default\": [],\n    \"examples\": [\n        [\n            {\n                \"cbor_tag\": 32773,\n                \"iana_registered\": false,\n                \"description\": \"ED25519-BIP32 public-key\",\n                \"cip\": \"CIP-0115\"\n            },\n            {\n                \"cbor_tag\": 32774,\n                \"iana_registered\": false,\n                \"description\": \"ED25519-BIP32 Signature\",\n                \"cip\": \"CIP-0115\"\n            }\n        ]\n    ],\n    \"additionalItems\": false,\n    \"items\": {\n        \"$id\": \"#/items\",\n        \"anyOf\": [\n            {\n                \"$id\": \"#/items/anyOf/0\",\n                \"type\": \"object\",\n                \"title\": \"The first anyOf schema\",\n                \"description\": \"An entry in the CBOR Tag registry\",\n                \"default\": {},\n                \"examples\": [\n                    {\n                        \"cbor_tag\": 32771,\n                        \"iana_registered\": false,\n                        \"description\": \"ED25519-BIP32 Private Key\",\n                        \"cip\": \"CIP-xxxx\"\n                    }\n                ],\n                \"required\": [\n                    \"cbor_tag\",\n                    \"iana_registered\",\n                    \"description\"\n                ],\n                \"properties\": {\n                    \"cbor_tag\": {\n                        \"$id\": \"#/items/anyOf/0/properties/cbor_tag\",\n                        \"type\": \"integer\",\n                        \"title\": \"The CBOR Tag number\",\n                        \"examples\": [\n                            32771\n                        ]\n                    },\n                    \"iana_registered\": {\n                        \"$id\": \"#/items/anyOf/0/properties/iana_registered\",\n                        \"type\": \"boolean\",\n                        \"title\": \"Is the tag registered with IANA.  Unregistered tags must not be used as they are subject to change.\",\n                        \"default\": false,\n                        \"examples\": [\n                            true\n                        ]\n                    },\n                    \"description\": {\n                        \"$id\": \"#/items/anyOf/0/properties/description\",\n                        \"type\": \"string\",\n                        \"title\": \"The CBOR tag description\",\n                        \"default\": \"\",\n                        \"examples\": [\n                            \"ED25519-BIP32 Private Key\"\n                        ]\n                    },\n                    \"cip\": {\n                        \"$id\": \"#/items/anyOf/0/properties/cip\",\n                        \"type\": \"string\",\n                        \"title\": \"The CIP which defines the Tag and its canonical encoding\",\n                        \"examples\": [\n                            \"CIP-0115\"\n                        ]\n                    }\n                },\n                \"additionalProperties\": true\n            }\n        ]\n    }\n}"
  },
  {
    "path": "CIP-0115/README.md",
    "content": "---\nCIP: 115\nTitle: CBOR tag definition - ED25519-BIP32 Keys\nCategory: Tools\nStatus: Proposed\nAuthors:\n    - Steven Johnson <steven.johnson@iohk.io>\nImplementors: N/A\nDiscussions:\n    - https://github.com/cardano-foundation/cips/pulls/753\nCreated: 2024-01-19\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\n[CIP-0003] defines [ED25519-BIP32] Keys, Key derivation and a signature scheme.\nThis CIP defines CBOR Tags and formalizes the Canonical encoding of data structures for [CIP-0003].\nThe intention is to have these tags registered in the [IANA CBOR Tag Registry].\n\n## Motivation: why is this CIP necessary?\n\nProject Catalyst is in the process of defining new CBOR data structures.\nWe needed a way to reliably disambiguate different 32 byte strings.\nRather than making a non-standard encoding scheme specific to our structures we would like to use standard [CBOR] Tags.\n\nThis CIP is informed by [CPS-0014] and [CIP-0114].\n\nWithout this Tag definition, a metadata CIP which uses [ED25519-BIP32] public keys:\n\n- Is likely to just encode public keys as a byte string of 32 bytes; and\n- Needs to redundantly define how the keys are encoded in the byte string.\n- May encode these keys differently to another CIP, which can lead to confusion and potential error.\n\n[BIP32] also defines `secp256k1` keys which are also 32 bytes long.\nThis CIP would help disambiguate between these keys and inform the decoder which key is being utilized.\n\n## Specification\n\n| Type | [CBOR] Tag | Type | Size | [IANA CBOR Tag Registry] |\n| -- | -- | -- | -- | -- |\n| [ED25519-BIP32 Private Key](#ed25519-bip32-private-key) | 32771 | bstr | 32 | To submit |\n| [ED25519-BIP32 Extended Private Key](#ed25519-bip32-extended-private-key) | 32772 | bstr | 64 | To submit |\n| [ED25519-BIP32 Public Key](#ed25519-bip32-public-key) | 32773 | bstr | 32 | To submit |\n| [ED25519-BIP32 Signature](#ed25519-bip32-signature) | 32774 | bstr | 64 | To submit |\n\n*NOTE: These tags are preliminary and subject to change until IANA registration is complete.\nThey MUST not be used outside of testing purposes.\nThey MUST not be used in any data intended to be posted to main-net.*\n\n### ED25519-BIP32 Private Key\n\nThis key is defined in [ED25519-BIP32].\n\nThis is encoded as a byte string of size 32 bytes.\n\n#### [CDDL]\n\n```cddl\ned25519_private_key = #6.32771(bstr .size 32)\n```\n\nData for the key inside the byte string is encoded in [network byte order].\n\n### ED25519-BIP32 Extended Private Key\n\nThis key is defined in [ED25519-BIP32].\n\nThis is encoded as a byte string of size 64 bytes.\n\n#### [CDDL]\n\n```cddl\ned25519_extended_private_key = #6.32772(bstr .size 64)\n```\n\nData for the key inside the byte string is encoded in [network byte order].\n\n### ED25519-BIP32 Public Key\n\nThis key is defined in [ED25519-BIP32].\n\nThis is encoded as a byte string of size 32 bytes.\n\n#### [CDDL]\n\n```cddl\ned25519_public_key = #6.32773(bstr .size 32)\n```\n\nData for the key inside the byte string is encoded in [network byte order].\n\n### ED25519-BIP32 Signature\n\n[ED25519-BIP32] defines how signatures can be generated on data from private keys.\nThese signatures are defined to be 64 bytes long.\n\nSignatures are encoded as a byte string of size 64 bytes.\n\n#### [CDDL]\n\n```cddl\ned25519_bip32_signature = #6.32774(bstr .size 64)\n```\n\nData for the signature inside the byte string is encoded in [network byte order].\n\n## Rationale: how does this CIP achieve its goals?\n\nBy defining concrete CBOR tags, it is possible for metadata to unambiguously mark the kind of data encoded.\nThis is conformant with the intent of Tags in [CBOR], and aligns with [CIP-CBOR-TAGS].\n\nAn official published spec is required to register these Tags with [IANA][IANA CBOR Tag Registry].\nThis document also serves that purpose.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] These tags to be included in [CIP-CBOR-TAGS].\n- [ ] One downstream CIP uses at least one of the tags defined in this CIP.\n- [ ] IANA register all the tags as defined herein.\n\n### Implementation Plan\n\n- [ ] Tags are to be used by Project Catalyst for CBOR data structure definitions.\n- [ ] Project Catalyst will also make the application to [IANA][IANA CBOR Tag Registry] to register the Tags.\n\n## References\n\n- [CPS-0014 -  Register of CBOR Tags for Cardano Data structures][CPS-0014]\n- [CIP-0003 - Wallet Key Generation][CIP-0003]\n- [CIP-0114 - CBOR Tags Registry][CIP-0114]\n- [RFC8949 - Concise Binary Object Representation (CBOR)][CBOR]\n- [RFC8610 - Concise Data Definition Language (CDDL)][CDDL]\n- [RFC1700 Data Notations (Network Byte Order)][network byte order]\n- [BIP32 - Hierarchical Deterministic Wallets][BIP32]\n- [ED25519-BIP32 - Hierarchical Deterministic Keys over a Non-linear Keyspace][ED25519-BIP32]\n- [IANA CBOR Tag Registry]\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0]\n\nCode samples and reference material are licensed under [Apache 2.0]\n\n[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n[Apache 2.0]: https://www.apache.org/licenses/LICENSE-2.0.html\n[CBOR]: https://www.rfc-editor.org/rfc/rfc8949.html\n[CDDL]: https://www.rfc-editor.org/rfc/rfc8610\n[CIP-0003]: https://cips.cardano.org/cip/CIP-0003\n[BIP32]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki\n[IANA CBOR Tag Registry]: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml\n[network byte order]: https://datatracker.ietf.org/doc/html/rfc1700\n[ED25519-BIP32]: https://github.com/input-output-hk/adrestia/raw/bdf00e4e7791d610d273d227be877bc6dd0dbcfb/user-guide/static/Ed25519_BIP.pdf\n[CPS-0014]: https://github.com/cardano-foundation/CIPs/tree/master/CPS-0014\n[CIP-0114]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0114\n"
  },
  {
    "path": "CIP-0116/README.md",
    "content": "---\nCIP: 116\nTitle: Standard JSON encoding for Domain Types\nCategory: Tools\nStatus: Proposed\nAuthors:\n    - Vladimir Kalnitsky <klntsky@gmail.com>\nImplementors:\n    - Vladimir Kalnitsky <klntsky@gmail.com>\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/742\n    - https://github.com/cardano-foundation/CIPs/pull/766\nCreated: 2024-02-22\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nCanonical JSON encoding for Cardano domain types lets the ecosystem converge on a single way of serializing data to JSON, thus freeing the developers from repeating roughly the same, but slightly different encoding/decoding logic over and over.\n\n## Motivation: why is this CIP necessary?\n\nCardano domain types have canonical CDDL definitions (for every era), but when it comes to use in web apps, where JSON is the universally accepted format, there is no definite standard. This CIP aims to change that.\n\nThe full motivation text is provided in [CPS-11 | Universal JSON Encoding for Domain Types](https://github.com/cardano-foundation/CIPs/tree/master/CPS-0011).\n\n## Specification\n\nThis CIP is expected to contain multiple json-schema definitions for Cardano Eras and breaking intra-era hardforks starting from Babbage.\n\n| Ledger era | Hardfork | Ledger Commit | Schema | Changelog Entry |\n| --- | --- | --- | --- |--- |\n| Babbage | Vasil | [12dc779](https://github.com/IntersectMBO/cardano-ledger/blob/12dc779d7975cbeb69c7c18c1565964a90f50920/eras/babbage/impl/cddl-files/babbage.cddl) | [cardano-babbage.json](./cardano-babbage.json) | N/A |\n\n### Tests & utilities for JSON validation\n\n[`cip-0116-tests`](https://github.com/mlabs-haskell/cip-0116-tests) repo contains utility functions and a test suite for the schema. In particular, there's a `mkValidatorForType` function that builds a validator function for any type defined in the schema.\n\n### Scope of the Schema\n\nThe schemas should cover `Block` type and all of its structural components, which corresponds to the scope of CDDL files located in [the ledger repo](https://github.com/IntersectMBO/cardano-ledger/).\n\n### Schema Design Principles\n\nBelow you can find some principles outlining the process of schema creation / modification. They are intended to be applied when there is a need to create a schema for a new Cardano era.\n\n#### Uniqueness of encoding\n\nEvery transaction (i.e. CBOR-encoded binary) must have exactly one valid JSON encoding, up to entry ordering in mappings (that are represented as key-value pairs).\n\nFor a single JSON fixture, however, there are multiple variants of encoding it as CBOR.\n\n#### Consistency with the previous versions\n\nTo simplify transitions of dApps between eras, the scope of changes introduced to the schemas SHOULD be limited to the scope of CDDL changes.\n\n### Schema Conventions\n\nThese conventions help to keep the schema uniform in style.\n\n#### Encoding of binary types\n\nBinary data MUST be encoded as lower-case hexademical strings. Restricting the character set to lower-case letters (`a-f`) allows for comparisons and equality checks without the need to normalize the values to a uniform case.\n\n#### Encoding of mapping types\n\n`Map`-like container types MUST be encoded as arrays of key-value pairs.\n\n```json\n\"Map\": {\n    \"type\": \"array\",\n    \"items\": {\n        \"type\": \"object\",\n        \"properties\": {\n            \"key\": ...,\n            \"value\": ...\n        },\n        \"required\": [\n          \"key\",\n          \"value\"\n        ],\n        \"additionalProperties\": false\n    }\n}\n```\n\nUniqueness of `\"key\"` objects in a map MUST be preserved (but this property is not expressible via a schema).\n\nImplementations MUST consider mappings with conflicting keys invalid.\n\nSome mapping-like types, specifically `Mint`, allow for duplicate keys. Types like these should not be encoded as maps, instead, `key` and `value` properties should be named differently.\n\n#### Encoding of variant types\n\nEncoding types with variable payloads MUST be done with the use of `oneOf` and an explicit discriminator property: `tag`:\n\n```json\n{\n    \"Credential\": {\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"pubkey_hash\"\n              ]\n            },\n            \"value\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/Ed25519KeyHash\"\n            }\n          },\n          \"required\": [\"tag\", \"value\"],\n          \"additionalProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"script_hash\"\n              ]\n            },\n            \"value\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/ScriptHash\"\n            }\n          },\n          \"required\": [\"tag\", \"value\"],\n          \"additionalProperties\": false\n        }\n      ]\n    }\n}\n```\n\nOther properties of a tagged object MUST be specified in lower-case snake-case.\n\n#### Encoding of enum types\n\nEnums are a special kind of variant types that carry no payloads. These MUST be encoded as string `enum`s.\n\nLowercase snake case identifiers MUST be used for the options, e.g.:\n\n```json\n{\n    \"Language\": {\n      \"title\": \"Language\",\n      \"type\": \"string\",\n      \"enum\": [\n        \"plutus_v1\",\n        \"plutus_v2\"\n      ]\n    }\n}\n```\n\n#### Encoding of record types\n\nAll record types MUST be encoded as objects with explicit list of `required` properties, and `additionalProperties` set to `false` (see \"absence of extensibility\" chapter for the motivation behind this suggestion).\n\n#### Encoding of nominal type synonyms\n\nSome of the types have identical representations, differing only by nominal name. For example, `Slot` domain type is expressed as `uint` in CDDL.\n\nFor these types, their nominal name SHOULD NOT have a separate definition in the json-schema, and the \"representation type\" should be used via a `$ref` instead. The domain type name SHOULD be included as `title` string at the point of usage.\n\n### Additional format types\n\nSome non-standard `format` types are used:\n\n- `hex` - lower-case hex-encoded byte string\n- `bech32` - [bech32](https://en.bitcoin.it/wiki/Bech32) string\n- `base58` - [base58](https://bitcoinwiki.org/wiki/base58) string\n- `uint64` - 64-bit unsigned integer\n- `int128` - 128-bit signed integer\n- `string64` - a unicode string that must not exceed 64 bytes when utf8-encoded.\n- `posint64` - a positive (0 excluded) 64-bit integer. `1 .. 2^64-1`\n\n### Limitations\n\nJSON-schema does not allow to express certain properties of some of the types.\n\n#### Uniqueness of mapping keys\n\nSee the chapter on encoding of mapping types.\n\n#### Bech32 and Base58 formats\n\nValidity of values of these types can't be expressed as a regular expression, so the implementations MAY validate them separately.\n\n#### Address types\n\nBech32 strings are not always valid addresses: even if the prefixes are correct, the [binary layout of the payload](https://github.com/IntersectMBO/cardano-ledger/blob/f754084675a1decceed4f309814b09605f443dd5/libs/cardano-ledger-core/src/Cardano/Ledger/Address.hs#L603) must also be valid.\n\nThe implementations MAY validate it separately.\n\n#### Byte length limits for strings\n\nIn CDDL, the length of a `tstr` value gives the number of bytes, but in `json-schema` there is no way to specify restrictions on byte lengths. So, `maxLength` is not the correct way of specifying the limits, but it is still useful, because no string longer than 64 *characters* satisfies the 64-byte limit.\n\n#### Auxiliary Data encoding\n\n`auxiliary_data` CDDL type is handled specially.\n\n```cddl\nauxiliary_data =\n  metadata ; Shelley\n  / [ transaction_metadata: metadata ; Shelley-ma\n    , auxiliary_scripts: [ * native_script ]\n    ]\n  / #6.259({ ? 0 => metadata         ; Alonzo and beyond\n      , ? 1 => [ * native_script ]\n      , ? 2 => [ * plutus_v1_script ]\n      , ? 3 => [ * plutus_v2_script ]\n      })\n```\n\nInstead of providing all three variants of encoding, we base the schema on the one that is the most general (the last one):\n\n```json\n{\n    \"AuxiliaryData\": {\n      \"properties\": {\n        \"metadata\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/TransactionMetadata\"\n        },\n        \"native_scripts\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/NativeScript\"\n          }\n        },\n        \"plutus_scripts\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/PlutusScript\"\n          }\n        }\n      },\n    }\n}\n```\n\nIt is up to implementors to decide how to serialize the values into CBOR. The property we want to maintain is preserved regardless of the choice: for every block binary there is exactly one JSON encoding.\n\n### Versioning\n\nThis CIP should not follow a conventional versioning scheme, rather it should be altered via pull request before a hardforks to add new a JSON schema to align with new ledger ers. Each schema must be standalone and not reuse definitions between eras. Authors MUST follow the [Schema Scope](#scope-of-the-schema), [Schema Design Principles](#schema-design-principles) and [Schema Conventions](#schema-conventions).\n\nFurthermore, for each subsequent schema, the [changelog](./changelog.md) must be updated. Authors must clearly articulate the deltas between schemas.\n\n## Rationale: how does this CIP achieve its goals?\n\n### Scope\n\nWe keep the scope of this standard to the data types within Cardano blocks. The rationale for this is that block data is by far the most useful for the majority of Cardano actors. There is also one nice benefit that the definitions can map directly from the provided CDDL file from ledger team.\n\n### Strictness\n\nThis CIP lays out strong conventions that future schema authors must follow, along with a large set of design principles. The aim is to minimize the potential for unavoidable deltas between schemas.\n\nBy setting sometimes arbitrary conventions we hope to create a single possible interpretation from CBOR to JSON, alleviating any ambiguity.\n\n### Absence of extensibility\n\nThe schemas MUST NOT be extensible with additional properties. This may sound counter-intuitive and against the spirit of json-schema, but there are some motivations behind that:\n\n- More safety from typos: object fields that are optional may be specified with slightly incorrect names in dApps' code, leading to inability of the decoders to pick up the values, which may go unnoticed.\n- Clear delineation between Cardano domain types and user dApp domain types: forcing the developers to store their dApp domain data separately from Cardano data, or close to it (as opposed to mixing these together in a single object) will indirectly motivate better structured dApp code.\n\n### JSON\n\nJSON was chosen as there is no viable alternative. The majority of Cardano's web tooling is built with Javascript where JSON is the primary object representation format.\n\nFurthermore, even across non-Javascript based stacks, JSON enjoys wide tooling support, this improves the potential for builders to adopt this standard.\n\n### Bech32 for addresses\n\nWe choose to use Bech32 as the representation for Cardano addresses. When compared to the alternative of hexademical encoding, Bech32 gives the advantages of an included checksum and a human readable prefix.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] One future ledger era schema is added\n- [ ] This standard is implemented within three separate tools, libraries, etc. \n\n### Implementation Plan\n\n- [x] Complete the specification for the current Babbage era\n- [ ] Provide a test suite validating JSON fixtures for all the types against the schema \n- [x] Provide an implementation of validating functions that uses this json-schema\n  - [mlabs-haskell/cip-0116-tests](https://github.com/mlabs-haskell/cip-0116-tests)\n- [ ] Collect a list of cardano domain types implementations and negotiate transition to the specified formats with maintainers (if it makes sense and is possible)\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0116/cardano-babbage.json",
    "content": "{\n  \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n  \"$id\": \"cardano-babbage.json\",\n  \"title\": \"Cardano Babbage Era Domain Types\",\n  \"definitions\": {\n    \"BigInt\": {\n      \"title\": \"BigInt\",\n      \"type\": \"string\",\n      \"description\": \"A long integer domain type\",\n      \"pattern\": \"^(0|-?[1-9][0-9]*)$\",\n      \"examples\": [\n        \"0\",\n        \"-123\",\n        \"123\"\n      ]\n    },\n    \"ByteString\": {\n      \"title\": \"ByteString\",\n      \"description\": \"Arbitrary-length byte array\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^([0-9a-f][0-9a-f])*$\"\n    },\n    \"UInt64\": {\n      \"title\": \"UInt64\",\n      \"description\": \"64-bit unsigned integer\",\n      \"type\": \"string\",\n      \"pattern\": \"^(0|[1-9][0-9]*)$\",\n      \"format\": \"uint64\"\n    },\n    \"PosInt64\": {\n      \"title\": \"PosInt64\",\n      \"description\": \"64-bit unsigned integer, zero-excluded. 1-18446744073709551615\",\n      \"type\": \"string\",\n      \"pattern\": \"^([1-9][0-9]*)$\",\n      \"format\": \"posint64\"\n    },\n    \"Int128\": {\n      \"title\": \"Int128\",\n      \"description\": \"128-bit signed integer\",\n      \"type\": \"string\",\n      \"pattern\": \"^-?(0|[1-9][0-9]*)$\",\n      \"format\": \"int128\"\n    },\n    \"NonZeroInt64\": {\n      \"title\": \"NonZeroInt64\",\n      \"description\": \"64-bit signed integer, zero excluded. Ranges: -9223372036854775808..-1 and 1..9223372036854775807\",\n      \"type\": \"string\",\n      \"pattern\": \"^-?([1-9][0-9]*)$\"\n    },\n    \"UInt32\": {\n      \"title\": \"UInt32\",\n      \"description\": \"32-bit unsigned integer\",\n      \"type\": \"integer\",\n      \"minimum\": 0,\n      \"maximum\": 4294967295\n    },\n    \"RewardAddress\": {\n      \"title\": \"RewardAddress\",\n      \"type\": \"string\",\n      \"format\": \"bech32\",\n      \"pattern\": \"^(stake1[02-9ac-hj-np-z]{53}|stake_test1[02-9ac-hj-np-z]{53})$\",\n      \"examples\": [\n        \"stake1u9u5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5egnuvsnm\"\n      ]\n    },\n    \"ByronAddress\": {\n      \"title\": \"ByronAddress\",\n      \"type\": \"string\",\n      \"format\": \"base58\",\n      \"pattern\": \"^[1-9A-HJ-NP-Za-km-z]+$\",\n      \"examples\": [\n        \"37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na\"\n      ]\n    },\n    \"PointerAddress\": {\n      \"title\": \"PointerAddress\",\n      \"type\": \"string\",\n      \"format\": \"bech32\",\n      \"pattern\": \"^(addr1[02-9ac-hj-np-z]{62}|addr_test1[02-9ac-hj-np-z]{62})$\",\n      \"examples\": [\n        \"addr1gx2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer5pnz75xxcrzqf96k\"\n      ]\n    },\n    \"EnterpriseAddress\": {\n      \"title\": \"EnterpriseAddress\",\n      \"type\": \"string\",\n      \"format\": \"bech32\",\n      \"pattern\": \"^(addr1[02-9ac-hj-np-z]{53}|addr_test1[02-9ac-hj-np-z]{53})$\",\n      \"examples\": [\n        \"addr1v9u5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0kvk0f\"\n      ]\n    },\n    \"BaseAddress\": {\n      \"title\": \"BaseAddress\",\n      \"type\": \"string\",\n      \"format\": \"bech32\",\n      \"pattern\": \"^(addr1[02-9ac-hj-np-z]{98}|addr_test1[02-9ac-hj-np-z]{98})$\",\n      \"examples\": [\n        \"addr1q9u5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5etege7xn2dvvc5qzaxsn439wkaf246gkgw7cw6g822xnfjsyzwht9\"\n      ]\n    },\n    \"Address\": {\n      \"title\": \"Address\",\n      \"anyOf\": [\n        {\n          \"$ref\": \"cardano-babbage.json#/definitions/RewardAddress\"\n        },\n        {\n          \"$ref\": \"cardano-babbage.json#/definitions/BaseAddress\"\n        },\n        {\n          \"$ref\": \"cardano-babbage.json#/definitions/PointerAddress\"\n        },\n        {\n          \"$ref\": \"cardano-babbage.json#/definitions/EnterpriseAddress\"\n        },\n        {\n          \"$ref\": \"cardano-babbage.json#/definitions/ByronAddress\"\n        }\n      ]\n    },\n    \"Ed25519KeyHash\": {\n      \"title\": \"Ed25519KeyHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{56}$\"\n    },\n    \"ScriptHash\": {\n      \"title\": \"ScriptHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{56}$\"\n    },\n    \"AssetName\": {\n      \"title\": \"AssetName\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^([0-9a-f][0-9a-f]){0,32}$\",\n      \"examples\": [\n        \"\",\n        \"504154415445\",\n        \"1e349c9bdea19fd6c147626a5260bc44b71635f398b67c59881df209\",\n        \"7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc373\"\n      ]\n    },\n    \"Credential\": {\n      \"title\": \"Credential\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"pubkey_hash\"\n              ]\n            },\n            \"value\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/Ed25519KeyHash\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"value\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"script_hash\"\n              ]\n            },\n            \"value\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/ScriptHash\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"value\"\n          ],\n          \"unevaluatedProperties\": false\n        }\n      ]\n    },\n    \"MultiAsset\": {\n      \"title\": \"MultiAsset\",\n      \"description\": \"A mapping from policy IDs (script hashes) to mappings from asset names to amounts\",\n      \"type\": \"object\",\n      \"patternProperties\": {\n        \"^[0-9a-f]{56}$\": {\n          \"type\": \"object\",\n          \"patternProperties\": {\n            \"^([0-9a-f][0-9a-f]){0,32}$\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/PosInt64\"\n            }\n          },\n          \"unevaluatedProperties\": false\n        }\n      },\n      \"unevaluatedProperties\": false\n    },\n    \"Value\": {\n      \"title\": \"Value\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"coin\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"assets\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/MultiAsset\"\n        }\n      },\n      \"required\": [\n        \"coin\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"TransactionHash\": {\n      \"title\": \"TransactionHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\",\n      \"maxLength\": 64,\n      \"minLength\": 64,\n      \"examples\": [\n        \"eca40340fa6e65d964915ba4bc8bd811a0493d263ffe95875291114cbb2d0686\",\n        \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n        \"fbc1da46d62a431e69855ad48a6b49b0e2aaafc6fd3dc4a066c6851b7bd31a91\",\n        \"c6726192662abeab149098095eabe004ecbec47f5e564748ab0d394affca47d9\"\n      ]\n    },\n    \"TransactionInput\": {\n      \"title\": \"TransactionInput\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"transaction_id\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/TransactionHash\"\n        },\n        \"index\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        }\n      },\n      \"required\": [\n        \"transaction_id\",\n        \"index\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"PlutusScript\": {\n      \"title\": \"PlutusScript\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"language\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/Language\"\n        },\n        \"bytes\": {\n          \"type\": \"string\",\n          \"format\": \"hex\",\n          \"pattern\": \"^([0-9a-f][0-9a-f])+$\"\n        }\n      },\n      \"required\": [\n        \"language\",\n        \"bytes\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"NativeScript\": {\n      \"title\": \"NativeScript\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"title\": \"ScriptPubkey\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"pubkey\"\n              ]\n            },\n            \"pubkey\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/Ed25519KeyHash\"\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"pubkey\"\n          ]\n        },\n        {\n          \"title\": \"ScriptAll\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"all\"\n              ]\n            },\n            \"scripts\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/NativeScript\"\n              }\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"scripts\"\n          ]\n        },\n        {\n          \"title\": \"ScriptAny\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"any\"\n              ]\n            },\n            \"scripts\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/NativeScript\"\n              }\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"scripts\"\n          ]\n        },\n        {\n          \"title\": \"ScriptNOfK\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"n_of_k\"\n              ]\n            },\n            \"scripts\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/NativeScript\"\n              }\n            },\n            \"n\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"scripts\",\n            \"n\"\n          ]\n        },\n        {\n          \"title\": \"TimelockStart\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"timelock_start\"\n              ]\n            },\n            \"slot\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"slot\"\n          ]\n        },\n        {\n          \"title\": \"TimelockExpiry\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"timelock_expiry\"\n              ]\n            },\n            \"slot\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"slot\"\n          ]\n        }\n      ]\n    },\n    \"ScriptRef\": {\n      \"title\": \"ScriptRef\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"title\": \"PlutusScript\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"plutus_script\"\n              ]\n            },\n            \"value\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/PlutusScript\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"value\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"title\": \"NativeScript\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"native_script\"\n              ]\n            },\n            \"value\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/NativeScript\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"value\"\n          ],\n          \"unevaluatedProperties\": false\n        }\n      ]\n    },\n    \"DataHash\": {\n      \"title\": \"DataHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^([0-9a-f][0-9a-f]){32}$\"\n    },\n    \"TransactionOutput\": {\n      \"title\": \"TransactionOutput\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"address\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/Address\"\n        },\n        \"amount\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/Value\"\n        },\n        \"plutus_data\": {\n          \"type\": \"object\",\n          \"discriminator\": {\n            \"propertyName\": \"tag\"\n          },\n          \"oneOf\": [\n            {\n              \"type\": \"object\",\n              \"properties\": {\n                \"tag\": {\n                  \"enum\": [\n                    \"datum\"\n                  ]\n                },\n                \"value\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/PlutusData\"\n                }\n              }\n            },\n            {\n              \"type\": \"object\",\n              \"properties\": {\n                \"tag\": {\n                  \"enum\": [\n                    \"datum_hash\"\n                  ]\n                },\n                \"value\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/DataHash\"\n                }\n              }\n            }\n          ],\n          \"unevaluatedProperties\": false\n        },\n        \"script_ref\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/ScriptRef\"\n        }\n      },\n      \"required\": [\n        \"address\",\n        \"amount\"\n      ]\n    },\n    \"TransactionUnspentOutput\": {\n      \"title\": \"TransactionUnspentOutput\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"input\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/TransactionInput\"\n        },\n        \"output\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/TransactionOutput\"\n        }\n      },\n      \"required\": [\n        \"input\",\n        \"output\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"TransactionMetadatum\": {\n      \"title\": \"TransactionMetadatum\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"map\"\n              ]\n            },\n            \"contents\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"key\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/TransactionMetadatum\"\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/TransactionMetadatum\"\n                  }\n                },\n                \"required\": [\n                  \"key\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              }\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"contents\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"list\"\n              ]\n            },\n            \"contents\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/TransactionMetadatum\"\n              }\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"contents\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"int\"\n              ]\n            },\n            \"value\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/Int128\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"value\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"bytes\"\n              ]\n            },\n            \"value\": {\n              \"type\": \"string\",\n              \"format\": \"hex\",\n              \"pattern\": \"^([0-9a-f][0-9a-f]){0,64}$\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"value\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"title\": \"Metadata String\",\n          \"description\": \"UTF-8 string. Maximum size is 64 bytes, but there is no way to express byte length limit in a json-schema (maxLength limits the number of characters)\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"string\"\n              ]\n            },\n            \"value\": {\n              \"type\": \"string\",\n              \"maxLength\": 64,\n              \"format\": \"string64\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"value\"\n          ],\n          \"unevaluatedProperties\": false\n        }\n      ]\n    },\n    \"PlutusV1CostModel\": {\n      \"title\": \"PlutusV1CostModel\",\n      \"type\": \"array\",\n      \"items\": {\n        \"$ref\": \"cardano-babbage.json#/definitions/Int128\"\n      },\n      \"maxItems\": 166,\n      \"minItems\": 166\n    },\n    \"PlutusV2CostModel\": {\n      \"title\": \"PlutusV2CostModel\",\n      \"type\": \"array\",\n      \"items\": {\n        \"$ref\": \"cardano-babbage.json#/definitions/Int128\"\n      },\n      \"maxItems\": 175,\n      \"minItems\": 175\n    },\n    \"CostModels\": {\n      \"title\": \"CostModels\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"plutus_v1\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/PlutusV1CostModel\"\n        },\n        \"plutus_v2\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/PlutusV2CostModel\"\n        }\n      },\n      \"required\": [],\n      \"unevaluatedProperties\": false\n    },\n    \"ExUnitPrices\": {\n      \"title\": \"ExUnitPrices\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"mem_price\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UnitInterval\"\n        },\n        \"step_price\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UnitInterval\"\n        }\n      },\n      \"unevaluatedProperties\": false,\n      \"required\": [\n        \"mem_price\",\n        \"step_price\"\n      ]\n    },\n    \"ExUnits\": {\n      \"title\": \"ExUnits\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"mem\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"steps\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        }\n      },\n      \"required\": [\n        \"mem\",\n        \"steps\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"ProtocolVersion\": {\n      \"title\": \"ProtocolVersion\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"major\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        },\n        \"minor\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        }\n      },\n      \"required\": [\n        \"major\",\n        \"minor\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"ProtocolParamUpdate\": {\n      \"title\": \"ProtocolParamUpdate\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"ada_per_utxo_byte\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"collateral_percentage\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        },\n        \"cost_models\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/CostModels\"\n        },\n        \"d\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UnitInterval\"\n        },\n        \"execution_costs\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/ExUnitPrices\"\n        },\n        \"expansion_rate\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UnitInterval\"\n        },\n        \"key_deposit\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"max_block_body_size\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        },\n        \"max_block_ex_units\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/ExUnits\"\n        },\n        \"max_block_header_size\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        },\n        \"max_collateral_inputs\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        },\n        \"max_epoch\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        },\n        \"max_tx_ex_units\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/ExUnits\"\n        },\n        \"max_tx_size\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        },\n        \"max_value_size\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        },\n        \"min_pool_cost\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"minfee_a\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"minfee_b\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"n_opt\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"pool_deposit\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"pool_pledge_influence\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UnitInterval\"\n        },\n        \"protocol_version\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/ProtocolVersion\"\n        },\n        \"treasury_growth_rate\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UnitInterval\"\n        }\n      },\n      \"unevaluatedProperties\": false,\n      \"required\": []\n    },\n    \"Update\": {\n      \"title\": \"Update\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"epoch\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        },\n        \"proposed_protocol_parameter_updates\": {\n          \"type\": \"object\",\n          \"title\": \"ProposedProtocolParameterUpdates\",\n          \"description\": \"A mapping from GenesisHash to ProtocolParamUpdate\",\n          \"patternProperties\": {\n            \"^[0-9a-f]{56}$\": {\n              \"title\": \"ProtocolParamUpdate for a given GenesisHash\",\n              \"$ref\": \"cardano-babbage.json#/definitions/ProtocolParamUpdate\"\n            }\n          },\n          \"unevaluatedProperties\": false\n        }\n      },\n      \"required\": [\n        \"epoch\",\n        \"proposed_protocol_parameter_updates\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"ScriptDataHash\": {\n      \"title\": \"ScriptDataHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\"\n    },\n    \"TransactionMetadata\": {\n      \"title\": \"TransactionMetadata\",\n      \"type\": \"array\",\n      \"items\": {\n        \"type\": \"object\",\n        \"properties\": {\n          \"key\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n          },\n          \"value\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/TransactionMetadatum\"\n          }\n        },\n        \"required\": [\n          \"key\",\n          \"value\"\n        ],\n        \"unevaluatedProperties\": false\n      }\n    },\n    \"AuxiliaryDataHash\": {\n      \"title\": \"AuxiliaryDataHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\"\n    },\n    \"AuxiliaryData\": {\n      \"title\": \"AuxiliaryData\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"metadata\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/TransactionMetadata\"\n        },\n        \"native_scripts\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/NativeScript\"\n          }\n        },\n        \"plutus_scripts\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/PlutusScript\"\n          }\n        }\n      },\n      \"required\": [],\n      \"unevaluatedProperties\": false\n    },\n    \"TransactionBody\": {\n      \"title\": \"TransactionBody\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"auxiliary_data_hash\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/AuxiliaryDataHash\"\n        },\n        \"inputs\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/TransactionInput\"\n          }\n        },\n        \"outputs\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/TransactionOutput\"\n          }\n        },\n        \"fee\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"certs\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/Certificate\"\n          }\n        },\n        \"collateral\": {\n          \"title\": \"Collateral Inputs\",\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/TransactionInput\"\n          }\n        },\n        \"collateral_return\": {\n          \"allOf\": [\n            {\n              \"$ref\": \"cardano-babbage.json#/definitions/TransactionOutput\"\n            },\n            {\n              \"title\": \"Collateral Return\",\n              \"description\": \"Collateral return, introduced in CIP-40\"\n            }\n          ]\n        },\n        \"mint\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/Mint\"\n        },\n        \"network_id\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/NetworkId\"\n        },\n        \"reference_inputs\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/TransactionInput\"\n          }\n        },\n        \"required_signers\": {\n          \"title\": \"Required signers\",\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/Ed25519KeyHash\"\n          }\n        },\n        \"script_data_hash\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/ScriptDataHash\"\n        },\n        \"total_collateral\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"ttl\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"update\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/Update\"\n        },\n        \"validity_start_interval\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"withdrawals\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"type\": \"object\",\n            \"properties\": {\n              \"key\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/RewardAddress\"\n              },\n              \"value\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              }\n            },\n            \"unevaluatedProperties\": false\n          }\n        }\n      },\n      \"required\": [\n        \"inputs\",\n        \"outputs\",\n        \"fee\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"NetworkId\": {\n      \"title\": \"NetworkId\",\n      \"type\": \"string\",\n      \"enum\": [\n        \"testnet\",\n        \"mainnet\"\n      ]\n    },\n    \"PlutusData\": {\n      \"title\": \"PlutusData\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"title\": \"PlutusDataList\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"list\"\n              ]\n            },\n            \"contents\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/PlutusData\"\n              }\n            }\n          },\n          \"required\": [\"tag\", \"contents\"],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"title\": \"PlutusDataConstr\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"constr\"\n              ]\n            },\n            \"alternative\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n            },\n            \"data\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/PlutusData\"\n              }\n            }\n          },\n          \"required\": [\"tag\", \"alternative\", \"data\"],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"title\": \"PlutusDataMap\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"map\"\n              ]\n            },\n            \"contents\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"key\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/PlutusData\"\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/PlutusData\"\n                  }\n                },\n                \"unevaluatedProperties\": false\n              }\n            }\n          },\n          \"required\": [\"tag\", \"contents\"],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"title\": \"PlutusDataInteger\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"integer\"\n              ]\n            },\n            \"value\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/BigInt\"\n            }\n          },\n          \"required\": [\"tag\", \"value\"],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"title\": \"PlutusDataBytes\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"bytes\"\n              ]\n            },\n            \"value\": {\n              \"type\": \"string\",\n              \"format\": \"hex\",\n              \"pattern\": \"^([0-9a-f][0-9a-f])*$\"\n            }\n          },\n          \"required\": [\"tag\", \"value\"],\n          \"unevaluatedProperties\": false\n        }\n      ]\n    },\n    \"UnitInterval\": {\n      \"title\": \"UnitInterval\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"numerator\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"denominator\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        }\n      },\n      \"required\": [\"numerator\", \"denominator\"],\n      \"unevaluatedProperties\": false\n    },\n    \"Ipv4\": {\n      \"title\": \"Ipv4\",\n      \"description\": \"IPv4 Address\",\n      \"type\": \"string\",\n      \"pattern\": \"^((25[0-5]|(2[0-4]|1\\\\d|[1-9]|)\\\\d)\\\\.){3}(25[0-5]|(2[0-4]|1\\\\d|[1-9]|)\\\\d)$\"\n    },\n    \"Ipv6\": {\n      \"title\": \"Ipv6\",\n      \"description\": \"IPv6 address\",\n      \"type\": \"string\",\n      \"format\": \"ipv6\"\n    },\n    \"DNSName\": {\n      \"title\": \"DNSName\",\n      \"type\": \"string\",\n      \"maxLength\": 64,\n      \"format\": \"string64\"\n    },\n    \"Relay\": {\n      \"title\": \"Relay\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"type\": \"object\",\n          \"title\": \"SingleHostAddr\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"single_host_addr\"\n              ]\n            },\n            \"port\": {\n              \"type\": \"integer\",\n              \"maximum\": 65535\n            },\n            \"ipv4\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/Ipv4\"\n            },\n            \"ipv6\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/Ipv6\"\n            }\n          },\n          \"required\": [\n            \"tag\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"SingleHostName\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"single_host_name\"\n              ]\n            },\n            \"port\": {\n              \"type\": \"integer\",\n              \"minimum\": 1,\n              \"maximum\": 65535\n            },\n            \"dns_name\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/DNSName\"\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"dns_name\"\n          ]\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"MultiHostName\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"multi_host_name\"\n              ]\n            },\n            \"dns_name\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/DNSName\"\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"dns_name\"\n          ]\n        }\n      ]\n    },\n    \"VRFKeyHash\": {\n      \"title\": \"VRFKeyHash\",\n      \"type\": \"string\",\n      \"description\": \"blake2b_256 digest of a VRF verification key, encoded as bech32\",\n      \"pattern\": \"^vrf_vkh[02-9ac-hj-np-z]*\",\n      \"format\": \"bech32\",\n      \"examples\": [\n        \"vrf_vkh3ak4chlh2xj9tw3jjwxdgs7v2uq6ev86l03vw\"\n      ]\n    },\n    \"URL\": {\n      \"title\": \"URL\",\n      \"description\": \"UTF-8 URL string. Maximum size is 64 bytes, but there is no way to express byte length limit in a json-schema (maxLength limits the number of characters)\",\n      \"type\": \"string\",\n      \"maxLength\": 64,\n      \"format\": \"string64\"\n    },\n    \"PoolMetadataHash\": {\n      \"title\": \"PoolMetadataHash\",\n      \"description\": \"Pool Metadata Hash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\"\n    },\n    \"PoolMetadata\": {\n      \"title\": \"PoolMetadata\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"url\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/URL\"\n        },\n        \"hash\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/PoolMetadataHash\"\n        }\n      },\n      \"unevaluatedProperties\": false,\n      \"required\": [\n        \"url\",\n        \"hash\"\n      ]\n    },\n    \"PoolPubKeyHash\": {\n      \"title\": \"PoolPubKeyHash\",\n      \"type\": \"string\",\n      \"format\": \"bech32\",\n      \"pattern\": \"^(pool1)[02-9ac-hj-np-z]*$\",\n      \"examples\": [\n        \"pool12a39rkzfylvn9wfe8j6y8ucq6g2l4mw4azj70y0gd8ejczznyj2\"\n      ]\n    },\n    \"PoolParams\": {\n      \"title\": \"PoolParams\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"operator\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/PoolPubKeyHash\"\n        },\n        \"vrf_keyhash\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/VRFKeyHash\"\n        },\n        \"pledge\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"cost\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"margin\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UnitInterval\"\n        },\n        \"reward_account\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/RewardAddress\"\n        },\n        \"pool_owners\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/Ed25519KeyHash\"\n          }\n        },\n        \"relays\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/Relay\"\n          }\n        },\n        \"pool_metadata\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/PoolMetadata\"\n        }\n      },\n      \"required\": [\n        \"cost\",\n        \"margin\",\n        \"operator\",\n        \"pledge\",\n        \"pool_owners\",\n        \"relays\",\n        \"reward_account\",\n        \"vrf_keyhash\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"GenesisHash\": {\n      \"title\": \"GenesisHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{56}$\"\n    },\n    \"GenesisDelegateHash\": {\n      \"title\": \"GenesisDelegateHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{56}$\"\n    },\n    \"MIRPot\": {\n      \"title\": \"MIRPot\",\n      \"enum\": [\n        \"reserves\",\n        \"treasury\"\n      ]\n    },\n    \"MoveInstantaneousRewards\": {\n      \"title\": \"MoveInstantaneousRewards\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"type\": \"object\",\n          \"title\": \"Move Instantaneous Rewards to stake credentials\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"to_stake_creds\"\n              ]\n            },\n            \"pot\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/MIRPot\"\n            },\n            \"rewards\": {\n              \"title\": \"MIRToStakeCredentials\",\n              \"description\": \"Distribution of rewards\",\n              \"type\": \"array\",\n              \"items\": {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"key\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/Credential\"\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/Int128\"\n                  }\n                },\n                \"required\": [\n                  \"key\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              }\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"pot\",\n            \"rewards\"\n          ]\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Move Instantaneous Rewards to other Pot (reserves or treasury)\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"to_other_pot\"\n              ]\n            },\n            \"pot\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/MIRPot\"\n            },\n            \"amount\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"pot\",\n            \"amount\"\n          ]\n        }\n      ]\n    },\n    \"Certificate\": {\n      \"title\": \"Certificate\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"type\": \"object\",\n          \"title\": \"Stake Registration Certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"stake_registration\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/Credential\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Stake Deregistration Certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"stake_deregistration\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/Credential\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Stake Delegation Certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"stake_delegation\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/Credential\"\n            },\n            \"pool_keyhash\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/PoolPubKeyHash\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\",\n            \"pool_keyhash\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Pool Registration Certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"pool_registration\"\n              ]\n            },\n            \"pool_params\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/PoolParams\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"pool_params\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Pool Retirement Certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"pool_retirement\"\n              ]\n            },\n            \"pool_keyhash\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/PoolPubKeyHash\"\n            },\n            \"epoch\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"pool_keyhash\",\n            \"epoch\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Genesis Key Delegation Certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"genesis_key_delegation\"\n              ]\n            },\n            \"genesis_hash\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/GenesisHash\"\n            },\n            \"genesis_delegate_hash\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/GenesisDelegateHash\"\n            },\n            \"vrf_keyhash\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/VRFKeyHash\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"genesis_hash\",\n            \"genesis_delegate_hash\",\n            \"vrf_keyhash\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Move Instantaneous Rewards Certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"move_instantaneous_rewards\"\n              ]\n            },\n            \"move_instantaneous_rewards\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/MoveInstantaneousRewards\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"move_instantaneous_rewards\"\n          ],\n          \"unevaluatedProperties\": false\n        }\n      ]\n    },\n    \"Language\": {\n      \"title\": \"Language\",\n      \"type\": \"string\",\n      \"enum\": [\n        \"plutus_v1\",\n        \"plutus_v2\"\n      ]\n    },\n    \"Mint\": {\n      \"title\": \"Mint\",\n      \"description\": \"Minting or burning of assets. A mapping from policy IDs (script hashes) to mappings from asset names to amounts (that can be negative). Allows for duplicate script hash keys.\",\n      \"type\": \"array\",\n      \"items\": {\n        \"type\": \"object\",\n        \"properties\": {\n          \"script_hash\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/ScriptHash\"\n          },\n          \"assets\": {\n            \"type\": \"array\",\n            \"items\": {\n              \"title\": \"Assets\",\n              \"type\": \"object\",\n              \"properties\": {\n                \"asset_name\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/AssetName\"\n                },\n                \"amount\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/NonZeroInt64\"\n                }\n              },\n              \"required\": [\n                \"asset_name\",\n                \"amount\"\n              ],\n              \"unevaluatedProperties\": false\n            }\n          }\n        },\n        \"required\": [\n          \"script_hash\",\n          \"assets\"\n        ],\n        \"unevaluatedProperties\": false\n      }\n    },\n    \"Ed25519Signature\": {\n      \"title\": \"Ed25519Signature\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^([0-9a-f][0-9a-f]){64}$\"\n    },\n    \"Ed25519PublicKey\": {\n      \"title\": \"Ed25519PublicKey\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^([0-9a-f][0-9a-f]){32}$\"\n    },\n    \"BootstrapWitness\": {\n      \"title\": \"BootstrapWitness\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"attributes\": {\n          \"type\": \"string\",\n          \"format\": \"hex\",\n          \"pattern\": \"^([0-9a-f][0-9a-f])*$\"\n        },\n        \"chain_code\": {\n          \"type\": \"string\",\n          \"format\": \"hex\",\n          \"pattern\": \"^([0-9a-f][0-9a-f]){32}$\"\n        },\n        \"signature\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/Ed25519Signature\"\n        },\n        \"vkey\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/Ed25519PublicKey\"\n        }\n      },\n      \"required\": [\n        \"attributes\",\n        \"chain_code\",\n        \"signature\",\n        \"vkey\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"RedeemerTag\": {\n      \"title\": \"RedeemerTag\",\n      \"type\": \"string\",\n      \"enum\": [\n        \"spend\",\n        \"mint\",\n        \"cert\",\n        \"reward\"\n      ]\n    },\n    \"Redeemer\": {\n      \"title\": \"Redeemer\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"data\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/PlutusData\"\n        },\n        \"tag\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/RedeemerTag\"\n        },\n        \"index\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"ex_units\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/ExUnits\"\n        }\n      },\n      \"required\": [\n        \"data\",\n        \"tag\",\n        \"index\",\n        \"ex_units\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"Vkeywitness\": {\n      \"title\": \"Vkeywitness\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"vkey\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/Ed25519PublicKey\"\n        },\n        \"signature\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/Ed25519Signature\"\n        }\n      },\n      \"required\": [\n        \"vkey\",\n        \"signature\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"TransactionWitnessSet\": {\n      \"title\": \"TransactionWitnessSet\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"bootstraps\": {\n          \"title\": \"BootstrapWitnesses\",\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/BootstrapWitness\"\n          }\n        },\n        \"native_scripts\": {\n          \"title\": \"NativeScripts\",\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/NativeScript\"\n          }\n        },\n        \"plutus_data\": {\n          \"type\": \"array\",\n          \"title\": \"PlutusList\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/PlutusData\"\n          }\n        },\n        \"plutus_scripts\": {\n          \"type\": \"array\",\n          \"title\": \"PlutusScripts\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/PlutusScript\"\n          }\n        },\n        \"redeemers\": {\n          \"type\": \"array\",\n          \"title\": \"Redeemers\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/Redeemer\"\n          }\n        },\n        \"vkeywitnesses\": {\n          \"type\": \"array\",\n          \"title\": \"VkeyWitnesses\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/Vkeywitness\"\n          }\n        }\n      },\n      \"required\": []\n    },\n    \"Transaction\": {\n      \"type\": \"object\",\n      \"title\": \"Transaction\",\n      \"properties\": {\n        \"auxiliary_data\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/AuxiliaryData\"\n        },\n        \"body\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/TransactionBody\"\n        },\n        \"is_valid\": {\n          \"type\": \"boolean\"\n        },\n        \"witness_set\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/TransactionWitnessSet\"\n        }\n      },\n      \"required\": [\n        \"body\",\n        \"is_valid\",\n        \"witness_set\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"VRFCert\": {\n      \"title\": \"VRFCert\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"output\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/ByteString\"\n        },\n        \"proof\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/ByteString\",\n          \"type\": \"string\",\n          \"pattern\": \"^[0-9a-f]{160}$\"\n        }\n      },\n      \"required\": [\n        \"output\",\n        \"proof\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"KESVKey\": {\n      \"title\": \"KESVKey\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\",\n      \"maxLength\": 64,\n      \"minLength\": 64\n    },\n    \"BlockHash\": {\n      \"title\": \"BlockHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\",\n      \"maxLength\": 64,\n      \"minLength\": 64\n    },\n    \"VRFVKey\": {\n      \"title\": \"VRFVKey\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\",\n      \"maxLength\": 64,\n      \"minLength\": 64\n    },\n    \"KESSignature\": {\n      \"title\": \"KESSignature\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{896}$\",\n      \"maxLength\": 896,\n      \"minLength\": 896\n    },\n    \"OperationalCert\": {\n      \"title\": \"OperationalCert\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"hot_vkey\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/KESVKey\"\n        },\n        \"kes_period\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        },\n        \"sequence_number\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        },\n        \"sigma\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/Ed25519Signature\"\n        }\n      },\n      \"required\": [\n        \"hot_vkey\",\n        \"kes_period\",\n        \"sequence_number\",\n        \"sigma\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"HeaderBody\": {\n      \"title\": \"HeaderBody\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"block_number\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        },\n        \"slot\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n        },\n        \"prev_hash\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/BlockHash\"\n        },\n        \"issuer_vkey\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/Ed25519PublicKey\"\n        },\n        \"vrf_vkey\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/VRFVKey\"\n        },\n        \"vrf_result\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/VRFCert\"\n        },\n        \"block_body_size\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n        },\n        \"block_body_hash\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/BlockHash\"\n        },\n        \"operational_cert\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/OperationalCert\"\n        },\n        \"protocol_version\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/ProtocolVersion\"\n        }\n      },\n      \"unevaluatedProperties\": false,\n      \"required\": [\n        \"block_number\",\n        \"slot\",\n        \"issuer_vkey\",\n        \"vrf_vkey\",\n        \"vrf_result\",\n        \"block_body_size\",\n        \"block_body_hash\",\n        \"operational_cert\",\n        \"protocol_version\"\n      ]\n    },\n    \"Header\": {\n      \"title\": \"Header\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"body_signature\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/KESSignature\"\n        },\n        \"header_body\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/HeaderBody\"\n        }\n      },\n      \"required\": [\n        \"body_signature\",\n        \"header_body\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"Block\": {\n      \"title\": \"Block\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"auxiliary_data_set\": {\n          \"type\": \"object\",\n          \"title\": \"AuxiliaryDataSet\",\n          \"description\": \"A mapping from transaction indices to AuxiliaryData values\",\n          \"patternProperties\": {\n            \"^(0|[1-9][0-9]*)$\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/AuxiliaryData\"\n            }\n          },\n          \"unevaluatedProperties\": false\n        },\n        \"header\": {\n          \"$ref\": \"cardano-babbage.json#/definitions/Header\"\n        },\n        \"invalid_transactions\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"allOf\": [\n              {\n                \"title\": \"TransactionIndex\"\n              },\n              {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              }\n            ]\n          }\n        },\n        \"transaction_bodies\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/TransactionBody\"\n          }\n        },\n        \"transaction_witness_sets\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-babbage.json#/definitions/TransactionWitnessSet\"\n          }\n        }\n      },\n      \"unevaluatedProperties\": false,\n      \"required\": [\n        \"auxiliary_data_set\",\n        \"header\",\n        \"invalid_transactions\",\n        \"transaction_bodies\",\n        \"transaction_witness_sets\"\n      ]\n    }\n  }\n}\n"
  },
  {
    "path": "CIP-0116/cardano-conway.json",
    "content": "{\n  \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n  \"$id\": \"cardano-conway.json\",\n  \"title\": \"Cardano Conway Era Domain Types\",\n  \"definitions\": {\n    \"BigInt\": {\n      \"title\": \"BigInt\",\n      \"type\": \"string\",\n      \"description\": \"A long integer domain type\",\n      \"pattern\": \"^(0|-?[1-9][0-9]*)$\",\n      \"examples\": [\n        \"0\",\n        \"-123\",\n        \"123\"\n      ]\n    },\n    \"ByteString\": {\n      \"title\": \"ByteString\",\n      \"description\": \"Arbitrary-length byte array\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^([0-9a-f][0-9a-f])*$\"\n    },\n    \"UInt64\": {\n      \"title\": \"UInt64\",\n      \"description\": \"64-bit unsigned integer\",\n      \"type\": \"string\",\n      \"pattern\": \"^(0|[1-9][0-9]*)$\",\n      \"format\": \"uint64\"\n    },\n    \"UInt16\": {\n      \"title\": \"UInt16\",\n      \"description\": \"16-bit unsigned integer\",\n      \"type\": \"string\",\n      \"pattern\": \"^(0|[1-9][0-9]*)$\",\n      \"format\": \"uint16\"\n    },\n    \"PosInt64\": {\n      \"title\": \"PosInt64\",\n      \"description\": \"64-bit unsigned integer, zero-excluded. 1-18446744073709551615\",\n      \"type\": \"string\",\n      \"pattern\": \"^([1-9][0-9]*)$\",\n      \"format\": \"posint64\"\n    },\n    \"Int128\": {\n      \"title\": \"Int128\",\n      \"description\": \"128-bit signed integer\",\n      \"type\": \"string\",\n      \"pattern\": \"^-?(0|[1-9][0-9]*)$\",\n      \"format\": \"int128\"\n    },\n    \"NonZeroInt64\": {\n      \"title\": \"NonZeroInt64\",\n      \"description\": \"64-bit signed integer, zero excluded. Ranges: -9223372036854775808..-1 and 1..9223372036854775807\",\n      \"type\": \"string\",\n      \"pattern\": \"^-?([1-9][0-9]*)$\"\n    },\n    \"UInt32\": {\n      \"title\": \"UInt32\",\n      \"description\": \"32-bit unsigned integer\",\n      \"type\": \"integer\",\n      \"minimum\": 0,\n      \"maximum\": 4294967295\n    },\n    \"RewardAddress\": {\n      \"title\": \"RewardAddress\",\n      \"type\": \"string\",\n      \"format\": \"bech32\",\n      \"pattern\": \"^(stake1[02-9ac-hj-np-z]{53}|stake_test1[02-9ac-hj-np-z]{53})$\",\n      \"examples\": [\n        \"stake1u9u5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5egnuvsnm\"\n      ]\n    },\n    \"ByronAddress\": {\n      \"title\": \"ByronAddress\",\n      \"type\": \"string\",\n      \"format\": \"base58\",\n      \"pattern\": \"^[1-9A-HJ-NP-Za-km-z]+$\",\n      \"examples\": [\n        \"37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na\"\n      ]\n    },\n    \"EnterpriseAddress\": {\n      \"title\": \"EnterpriseAddress\",\n      \"type\": \"string\",\n      \"format\": \"bech32\",\n      \"pattern\": \"^(addr1[02-9ac-hj-np-z]{53}|addr_test1[02-9ac-hj-np-z]{53})$\",\n      \"examples\": [\n        \"addr1v9u5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0kvk0f\"\n      ]\n    },\n    \"BaseAddress\": {\n      \"title\": \"BaseAddress\",\n      \"type\": \"string\",\n      \"format\": \"bech32\",\n      \"pattern\": \"^(addr1[02-9ac-hj-np-z]{98}|addr_test1[02-9ac-hj-np-z]{98})$\",\n      \"examples\": [\n        \"addr1q9u5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5etege7xn2dvvc5qzaxsn439wkaf246gkgw7cw6g822xnfjsyzwht9\"\n      ]\n    },\n    \"Address\": {\n      \"title\": \"Address\",\n      \"anyOf\": [\n        {\n          \"$ref\": \"cardano-conway.json#/definitions/RewardAddress\"\n        },\n        {\n          \"$ref\": \"cardano-conway.json#/definitions/BaseAddress\"\n        },\n        {\n          \"$ref\": \"cardano-conway.json#/definitions/EnterpriseAddress\"\n        },\n        {\n          \"$ref\": \"cardano-conway.json#/definitions/ByronAddress\"\n        }\n      ]\n    },\n    \"Ed25519KeyHash\": {\n      \"title\": \"Ed25519KeyHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{56}$\"\n    },\n    \"ScriptHash\": {\n      \"title\": \"ScriptHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{56}$\"\n    },\n    \"AssetName\": {\n      \"title\": \"AssetName\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^([0-9a-f][0-9a-f]){0,32}$\",\n      \"examples\": [\n        \"\",\n        \"504154415445\",\n        \"1e349c9bdea19fd6c147626a5260bc44b71635f398b67c59881df209\",\n        \"7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc373\"\n      ]\n    },\n    \"ScriptDataHash\": {\n      \"title\": \"ScriptDataHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\"\n    },\n    \"TransactionMetadata\": {\n      \"title\": \"TransactionMetadata\",\n      \"type\": \"array\",\n      \"items\": {\n        \"type\": \"object\",\n        \"properties\": {\n          \"key\": {\n            \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n          },\n          \"value\": {\n            \"$ref\": \"cardano-conway.json#/definitions/TransactionMetadatum\"\n          }\n        },\n        \"required\": [\n          \"key\",\n          \"value\"\n        ],\n        \"unevaluatedProperties\": false\n      }\n    },\n    \"AuxiliaryDataHash\": {\n      \"title\": \"AuxiliaryDataHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\"\n    },\n    \"AuxiliaryData\": {\n      \"unevaluatedProperties\": false,\n      \"properties\": {\n        \"metadata\": {\n          \"$ref\": \"cardano-conway.json#/definitions/TransactionMetadata\"\n        },\n        \"native_scripts\": {\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/NativeScript\"\n          },\n          \"type\": \"array\"\n        },\n        \"plutus_scripts\": {\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/PlutusScript\"\n          },\n          \"type\": \"array\"\n        }\n      },\n      \"required\": [\n      ],\n      \"title\": \"AuxiliaryData\",\n      \"type\": \"object\"\n    },\n    \"Vote\": {\n      \"title\": \"Vote\",\n      \"type\": \"string\",\n      \"enum\": [\n        \"yes\",\n        \"no\",\n        \"abstain\"\n      ]\n    },\n    \"Voter\": {\n      \"type\": \"object\",\n      \"title\": \"Voter\",\n      \"oneOf\": [\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\"cc_credential\"]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            }\n          },\n          \"required\": [\"tag\", \"credential\"],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\"drep_credential\"]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            }\n          },\n          \"required\": [\"tag\", \"credential\"],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\"spo_keyhash\"]\n            },\n            \"pubkey_hash\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Ed25519KeyHash\"\n            }\n          },\n          \"required\": [\"tag\", \"credential\"],\n          \"unevaluatedProperties\": false\n        }\n      ]\n    },\n    \"VotingProcedure\": {\n      \"title\": \"VotingProcedure\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"vote\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Vote\"\n        },\n        \"anchor\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Anchor\"\n        }\n      },\n      \"required\": [\"vote\"],\n      \"unevaluatedProperties\": false\n    },\n    \"VotingProcedures\": {\n      \"title\": \"VotingProcedures\",\n      \"type\": \"array\",\n      \"items\": {\n        \"type\": \"object\",\n        \"properties\": {\n          \"key\": {\n            \"$ref\": \"cardano-conway.json#/definitions/Voter\"\n          },\n          \"value\": {\n            \"type\": \"array\",\n            \"items\": {\n              \"type\": \"object\",\n                \"properties\": {\n                  \"key\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/GovActionId\"\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/VotingProcedure\"\n                  }\n                },\n              \"required\": [\n                \"key\",\n                \"value\"\n              ],\n              \"unevaluatedProperties\": false\n            }\n          }\n        },\n        \"required\": [\n          \"key\",\n          \"value\"\n        ],\n        \"unevaluatedProperties\": false\n      }\n    },\n    \"ProposalProcedure\": {\n      \"title\": \"ProposalProcedure\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"deposit\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"reward_account\": {\n          \"$ref\": \"cardano-conway.json#/definitions/RewardAddress\"\n        },\n        \"gov_action\": {\n          \"$ref\": \"cardano-conway.json#/definitions/GovAction\"\n        },\n        \"anchor\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Anchor\"\n        }\n      },\n      \"required\": [ \"deposit\", \"reward_account\", \"gov_action\", \"anchor\" ],\n      \"unevaluatedProperties\": false\n    },\n    \"ProposalProcedures\": {\n      \"title\": \"ProposalProcedures\",\n      \"type\": \"array\",\n      \"minLength\": 1,\n      \"items\": {\n        \"$ref\": \"cardano-conway.json#/definitions/ProposalProcedure\"\n      }\n    },\n    \"TransactionBody\": {\n      \"title\": \"TransactionBody\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"auxiliary_data_hash\": {\n          \"$ref\": \"cardano-conway.json#/definitions/AuxiliaryDataHash\"\n        },\n        \"inputs\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/TransactionInput\"\n          }\n        },\n        \"outputs\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/TransactionOutput\"\n          }\n        },\n        \"fee\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"certs\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/Certificate\"\n          }\n        },\n        \"collateral\": {\n          \"title\": \"Collateral Inputs\",\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/TransactionInput\"\n          }\n        },\n        \"collateral_return\": {\n          \"allOf\": [\n            {\n              \"$ref\": \"cardano-conway.json#/definitions/TransactionOutput\"\n            },\n            {\n              \"title\": \"Collateral Return\",\n              \"description\": \"Collateral return, introduced in CIP-40\"\n            }\n          ]\n        },\n        \"mint\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Mint\"\n        },\n        \"network_id\": {\n          \"$ref\": \"cardano-conway.json#/definitions/NetworkId\"\n        },\n        \"reference_inputs\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/TransactionInput\"\n          }\n        },\n        \"required_signers\": {\n          \"title\": \"Required signers\",\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/Ed25519KeyHash\"\n          }\n        },\n        \"script_data_hash\": {\n          \"$ref\": \"cardano-conway.json#/definitions/ScriptDataHash\"\n        },\n        \"total_collateral\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"ttl\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"update\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Update\"\n        },\n        \"validity_start_interval\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"withdrawals\": {\n          \"type\": \"array\",\n          \"minLength\": 1,\n          \"items\": {\n            \"type\": \"object\",\n            \"properties\": {\n              \"key\": {\n                \"$ref\": \"cardano-conway.json#/definitions/RewardAddress\"\n              },\n              \"value\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              }\n            },\n            \"unevaluatedProperties\": false\n          }\n        },\n        \"voting_procedures\": {\n          \"$ref\": \"cardano-conway.json#/definitions/VotingProcedures\"\n        },\n        \"proposal_procedures\": {\n          \"$ref\": \"cardano-conway.json#/definitions/ProposalProcedures\"\n        },\n        \"donation\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"current_treasury_value\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        }\n      },\n      \"required\": [\n        \"inputs\",\n        \"outputs\",\n        \"fee\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"Credential\": {\n      \"title\": \"Credential\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"pubkey_hash\"\n              ]\n            },\n            \"value\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Ed25519KeyHash\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"value\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"script_hash\"\n              ]\n            },\n            \"value\": {\n              \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"value\"\n          ],\n          \"unevaluatedProperties\": false\n        }\n      ]\n    },\n    \"MultiAsset\": {\n      \"title\": \"MultiAsset\",\n      \"description\": \"A mapping from policy IDs (script hashes) to mappings from asset names to amounts\",\n      \"type\": \"object\",\n      \"patternProperties\": {\n        \"^[0-9a-f]{56}$\": {\n          \"type\": \"object\",\n          \"patternProperties\": {\n            \"^([0-9a-f][0-9a-f]){0,32}$\": {\n              \"$ref\": \"cardano-conway.json#/definitions/PosInt64\"\n            }\n          },\n          \"unevaluatedProperties\": false\n        }\n      },\n      \"unevaluatedProperties\": false\n    },\n    \"Value\": {\n      \"title\": \"Value\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"coin\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"assets\": {\n          \"$ref\": \"cardano-conway.json#/definitions/MultiAsset\"\n        }\n      },\n      \"required\": [\n        \"coin\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"TransactionHash\": {\n      \"title\": \"TransactionHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\",\n      \"maxLength\": 64,\n      \"minLength\": 64,\n      \"examples\": [\n        \"eca40340fa6e65d964915ba4bc8bd811a0493d263ffe95875291114cbb2d0686\",\n        \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n        \"fbc1da46d62a431e69855ad48a6b49b0e2aaafc6fd3dc4a066c6851b7bd31a91\",\n        \"c6726192662abeab149098095eabe004ecbec47f5e564748ab0d394affca47d9\"\n      ]\n    },\n    \"TransactionInput\": {\n      \"title\": \"TransactionInput\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"transaction_id\": {\n          \"$ref\": \"cardano-conway.json#/definitions/TransactionHash\"\n        },\n        \"index\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        }\n      },\n      \"required\": [\n        \"transaction_id\",\n        \"index\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"PlutusScript\": {\n      \"title\": \"PlutusScript\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"language\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Language\"\n        },\n        \"bytes\": {\n          \"type\": \"string\",\n          \"format\": \"hex\",\n          \"pattern\": \"^([0-9a-f][0-9a-f])+$\"\n        }\n      },\n      \"required\": [\n        \"language\",\n        \"bytes\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"NativeScript\": {\n      \"title\": \"NativeScript\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"title\": \"ScriptPubkey\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"pubkey\"\n              ]\n            },\n            \"pubkey\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Ed25519KeyHash\"\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"pubkey\"\n          ]\n        },\n        {\n          \"title\": \"ScriptAll\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"all\"\n              ]\n            },\n            \"scripts\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"$ref\": \"cardano-conway.json#/definitions/NativeScript\"\n              }\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"scripts\"\n          ]\n        },\n        {\n          \"title\": \"ScriptAny\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"any\"\n              ]\n            },\n            \"scripts\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"$ref\": \"cardano-conway.json#/definitions/NativeScript\"\n              }\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"scripts\"\n          ]\n        },\n        {\n          \"title\": \"ScriptNOfK\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"n_of_k\"\n              ]\n            },\n            \"scripts\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"$ref\": \"cardano-conway.json#/definitions/NativeScript\"\n              }\n            },\n            \"n\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"scripts\",\n            \"n\"\n          ]\n        },\n        {\n          \"title\": \"TimelockStart\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"timelock_start\"\n              ]\n            },\n            \"slot\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"slot\"\n          ]\n        },\n        {\n          \"title\": \"TimelockExpiry\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"timelock_expiry\"\n              ]\n            },\n            \"slot\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"slot\"\n          ]\n        }\n      ]\n    },\n    \"ScriptRef\": {\n      \"title\": \"ScriptRef\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"title\": \"PlutusScript\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"plutus_script\"\n              ]\n            },\n            \"value\": {\n              \"$ref\": \"cardano-conway.json#/definitions/PlutusScript\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"value\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"title\": \"NativeScript\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"native_script\"\n              ]\n            },\n            \"value\": {\n              \"$ref\": \"cardano-conway.json#/definitions/NativeScript\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"value\"\n          ],\n          \"unevaluatedProperties\": false\n        }\n      ]\n    },\n    \"DataHash\": {\n      \"title\": \"DataHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^([0-9a-f][0-9a-f]){32}$\"\n    },\n    \"TransactionOutput\": {\n      \"title\": \"TransactionOutput\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"address\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Address\"\n        },\n        \"amount\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Value\"\n        },\n        \"plutus_data\": {\n          \"type\": \"object\",\n          \"discriminator\": {\n            \"propertyName\": \"tag\"\n          },\n          \"oneOf\": [\n            {\n              \"type\": \"object\",\n              \"properties\": {\n                \"tag\": {\n                  \"enum\": [\n                    \"datum\"\n                  ]\n                },\n                \"value\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n                }\n              }\n            },\n            {\n              \"type\": \"object\",\n              \"properties\": {\n                \"tag\": {\n                  \"enum\": [\n                    \"datum_hash\"\n                  ]\n                },\n                \"value\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/DataHash\"\n                }\n              }\n            }\n          ],\n          \"unevaluatedProperties\": false\n        },\n        \"script_ref\": {\n          \"$ref\": \"cardano-conway.json#/definitions/ScriptRef\"\n        }\n      },\n      \"required\": [\n        \"address\",\n        \"amount\"\n      ]\n    },\n    \"TransactionUnspentOutput\": {\n      \"title\": \"TransactionUnspentOutput\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"input\": {\n          \"$ref\": \"cardano-conway.json#/definitions/TransactionInput\"\n        },\n        \"output\": {\n          \"$ref\": \"cardano-conway.json#/definitions/TransactionOutput\"\n        }\n      },\n      \"required\": [\n        \"input\",\n        \"output\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"TransactionMetadatum\": {\n      \"title\": \"TransactionMetadatum\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"map\"\n              ]\n            },\n            \"contents\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"key\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/TransactionMetadatum\"\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/TransactionMetadatum\"\n                  }\n                },\n                \"required\": [\n                  \"key\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              }\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"contents\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"list\"\n              ]\n            },\n            \"contents\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"$ref\": \"cardano-conway.json#/definitions/TransactionMetadatum\"\n              }\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"contents\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"int\"\n              ]\n            },\n            \"value\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Int128\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"value\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"bytes\"\n              ]\n            },\n            \"value\": {\n              \"type\": \"string\",\n              \"format\": \"hex\",\n              \"pattern\": \"^([0-9a-f][0-9a-f]){0,64}$\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"value\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"title\": \"Metadata String\",\n          \"description\": \"UTF-8 string. Maximum size is 64 bytes, but there is no way to express byte length limit in a json-schema (maxLength limits the number of characters)\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"string\"\n              ]\n            },\n            \"value\": {\n              \"type\": \"string\",\n              \"maxLength\": 64,\n              \"format\": \"string64\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"value\"\n          ],\n          \"unevaluatedProperties\": false\n        }\n      ]\n    },\n    \"PlutusV1CostModel\": {\n      \"title\": \"PlutusV1CostModel\",\n      \"type\": \"array\",\n      \"items\": {\n        \"$ref\": \"cardano-conway.json#/definitions/Int128\"\n      },\n      \"maxItems\": 166,\n      \"minItems\": 166\n    },\n    \"PlutusV2CostModel\": {\n      \"title\": \"PlutusV2CostModel\",\n      \"type\": \"array\",\n      \"items\": {\n        \"$ref\": \"cardano-conway.json#/definitions/Int128\"\n      },\n      \"maxItems\": 175,\n      \"minItems\": 175\n    },\n    \"PlutusV3CostModel\": {\n      \"title\": \"PlutusV3CostModel\",\n      \"type\": \"array\",\n      \"items\": {\n        \"$ref\": \"cardano-conway.json#/definitions/Int128\"\n      },\n      \"maxItems\": 251,\n      \"minItems\": 251\n    },\n    \"CostModels\": {\n      \"title\": \"CostModels\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"plutus_v1\": {\n          \"$ref\": \"cardano-conway.json#/definitions/PlutusV1CostModel\"\n        },\n        \"plutus_v2\": {\n          \"$ref\": \"cardano-conway.json#/definitions/PlutusV2CostModel\"\n        },\n        \"plutus_v3\": {\n          \"$ref\": \"cardano-conway.json#/definitions/PlutusV3CostModel\"\n        }\n      },\n      \"required\": [],\n      \"unevaluatedProperties\": false\n    },\n    \"ExUnitPrices\": {\n      \"title\": \"ExUnitPrices\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"mem_price\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n        },\n        \"step_price\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n        }\n      },\n      \"unevaluatedProperties\": false,\n      \"required\": [\n        \"mem_price\",\n        \"step_price\"\n      ]\n    },\n    \"ExUnits\": {\n      \"title\": \"ExUnits\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"mem\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"steps\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        }\n      },\n      \"required\": [\n        \"mem\",\n        \"steps\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"ProtocolVersion\": {\n      \"title\": \"ProtocolVersion\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"major\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"minor\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        }\n      },\n      \"required\": [\n        \"major\",\n        \"minor\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"NonnegativeInterval\": {\n      \"title\": \"NonnegativeInterval\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"numerator\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"denominator\": {\n          \"$ref\": \"cardano-conway.json#/definitions/PosInt64\"\n        }\n      },\n      \"required\": [\"numerator\", \"denominator\"],\n      \"unevaluatedProperties\": false\n    },\n    \"PoolVotingThresholds\": {\n      \"title\": \"PoolVotingThresholds\",\n      \"type\": \"array\",\n      \"items\": {\n        \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n      },\n      \"minItems\": 5,\n      \"maxItems\": 5\n    },\n    \"DRepVotingThresholds\": {\n      \"title\": \"DRepVotingThresholds\",\n      \"type\": \"array\",\n      \"items\": {\n        \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n      },\n      \"minItems\": 10,\n      \"maxItems\": 10\n    },\n    \"ProtocolParamUpdate\": {\n      \"title\": \"ProtocolParamUpdate\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"ada_per_utxo_byte\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"collateral_percentage\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"cost_models\": {\n          \"$ref\": \"cardano-conway.json#/definitions/CostModels\"\n        },\n        \"d\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n        },\n        \"execution_costs\": {\n          \"$ref\": \"cardano-conway.json#/definitions/ExUnitPrices\"\n        },\n        \"expansion_rate\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n        },\n        \"key_deposit\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"max_block_body_size\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"max_block_ex_units\": {\n          \"$ref\": \"cardano-conway.json#/definitions/ExUnits\"\n        },\n        \"max_block_header_size\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"max_collateral_inputs\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"max_epoch\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"max_tx_ex_units\": {\n          \"$ref\": \"cardano-conway.json#/definitions/ExUnits\"\n        },\n        \"max_tx_size\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"max_value_size\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"min_pool_cost\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"minfee_a\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"minfee_b\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"n_opt\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"pool_deposit\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"pool_pledge_influence\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n        },\n        \"protocol_version\": {\n          \"$ref\": \"cardano-conway.json#/definitions/ProtocolVersion\"\n        },\n        \"treasury_growth_rate\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n        },\n        \"pool_voting_thresholds\": {\n          \"$ref\": \"cardano-conway.json#/definitions/PoolVotingThresholds\"\n        },\n        \"drep_voting_thresholds\": {\n          \"$ref\": \"cardano-conway.json#/definitions/DRepVotingThresholds\"\n        },\n        \"committee_min_size\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt16\"\n        },\n        \"committee_max_term_length\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"gov_action_lifetime\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"gov_action_deposit\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"drep_deposit\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"drep_activity\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"min_fee_ref_script_cost_per_byte\": {\n          \"$ref\": \"cardano-conway.json#/definitions/NonnegativeInterval\"\n        }\n      },\n      \"unevaluatedProperties\": false,\n      \"required\": []\n    },\n    \"Update\": {\n      \"title\": \"Update\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"epoch\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"proposed_protocol_parameter_updates\": {\n          \"type\": \"object\",\n          \"title\": \"ProposedProtocolParameterUpdates\",\n          \"description\": \"A mapping from GenesisHash to ProtocolParamUpdate\",\n          \"patternProperties\": {\n            \"^[0-9a-f]{56}$\": {\n              \"title\": \"ProtocolParamUpdate for a given GenesisHash\",\n              \"$ref\": \"cardano-conway.json#/definitions/ProtocolParamUpdate\"\n            }\n          },\n          \"unevaluatedProperties\": false\n        }\n      },\n      \"required\": [\n        \"epoch\",\n        \"proposed_protocol_parameter_updates\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"NetworkId\": {\n      \"title\": \"NetworkId\",\n      \"type\": \"string\",\n      \"enum\": [\n        \"testnet\",\n        \"mainnet\"\n      ]\n    },\n    \"PlutusData\": {\n      \"title\": \"PlutusData\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"title\": \"PlutusDataList\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"list\"\n              ]\n            },\n            \"contents\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n              }\n            }\n          },\n          \"required\": [\"tag\", \"contents\"],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"title\": \"PlutusDataConstr\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"constr\"\n              ]\n            },\n            \"alternative\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n            },\n            \"data\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n              }\n            }\n          },\n          \"required\": [\"tag\", \"alternative\", \"data\"],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"title\": \"PlutusDataMap\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"map\"\n              ]\n            },\n            \"contents\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"key\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n                  }\n                },\n                \"unevaluatedProperties\": false\n              }\n            }\n          },\n          \"required\": [\"tag\", \"contents\"],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"title\": \"PlutusDataInteger\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"integer\"\n              ]\n            },\n            \"value\": {\n              \"$ref\": \"cardano-conway.json#/definitions/BigInt\"\n            }\n          },\n          \"required\": [\"tag\", \"value\"],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"title\": \"PlutusDataBytes\",\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"bytes\"\n              ]\n            },\n            \"value\": {\n              \"type\": \"string\",\n              \"format\": \"hex\",\n              \"pattern\": \"^([0-9a-f][0-9a-f])*$\"\n            }\n          },\n          \"required\": [\"tag\", \"value\"],\n          \"unevaluatedProperties\": false\n        }\n      ]\n    },\n    \"UnitInterval\": {\n      \"title\": \"UnitInterval\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"numerator\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"denominator\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        }\n      },\n      \"required\": [\"numerator\", \"denominator\"],\n      \"unevaluatedProperties\": false\n    },\n    \"Ipv4\": {\n      \"title\": \"Ipv4\",\n      \"description\": \"IPv4 Address\",\n      \"type\": \"string\",\n      \"pattern\": \"^((25[0-5]|(2[0-4]|1\\\\d|[1-9]|)\\\\d)\\\\.){3}(25[0-5]|(2[0-4]|1\\\\d|[1-9]|)\\\\d)$\"\n    },\n    \"Ipv6\": {\n      \"title\": \"Ipv6\",\n      \"description\": \"IPv6 address\",\n      \"type\": \"string\",\n      \"format\": \"ipv6\"\n    },\n    \"DNSName\": {\n      \"title\": \"DNSName\",\n      \"type\": \"string\",\n      \"maxLength\": 64,\n      \"format\": \"string64\"\n    },\n    \"Relay\": {\n      \"title\": \"Relay\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"type\": \"object\",\n          \"title\": \"SingleHostAddr\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"single_host_addr\"\n              ]\n            },\n            \"port\": {\n              \"type\": \"integer\",\n              \"maximum\": 65535\n            },\n            \"ipv4\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Ipv4\"\n            },\n            \"ipv6\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Ipv6\"\n            }\n          },\n          \"required\": [\n            \"tag\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"SingleHostName\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"single_host_name\"\n              ]\n            },\n            \"port\": {\n              \"type\": \"integer\",\n              \"minimum\": 1,\n              \"maximum\": 65535\n            },\n            \"dns_name\": {\n              \"$ref\": \"cardano-conway.json#/definitions/DNSName\"\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"dns_name\"\n          ]\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"MultiHostName\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"multi_host_name\"\n              ]\n            },\n            \"dns_name\": {\n              \"$ref\": \"cardano-conway.json#/definitions/DNSName\"\n            }\n          },\n          \"unevaluatedProperties\": false,\n          \"required\": [\n            \"tag\",\n            \"dns_name\"\n          ]\n        }\n      ]\n    },\n    \"VRFKeyHash\": {\n      \"title\": \"VRFKeyHash\",\n      \"type\": \"string\",\n      \"description\": \"blake2b_256 digest of a VRF verification key, encoded as bech32\",\n      \"pattern\": \"^vrf_vkh[02-9ac-hj-np-z]*\",\n      \"format\": \"bech32\",\n      \"examples\": [\n        \"vrf_vkh3ak4chlh2xj9tw3jjwxdgs7v2uq6ev86l03vw\"\n      ]\n    },\n    \"URL\": {\n      \"title\": \"URL\",\n      \"description\": \"UTF-8 URL string. Maximum size is 128 bytes, but there is no way to express byte length limit in a json-schema (maxLength limits the number of characters)\",\n      \"type\": \"string\",\n      \"maxLength\": 128,\n      \"format\": \"string128\"\n    },\n    \"PoolMetadataHash\": {\n      \"title\": \"PoolMetadataHash\",\n      \"description\": \"Pool Metadata Hash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\"\n    },\n    \"PoolMetadata\": {\n      \"title\": \"PoolMetadata\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"url\": {\n          \"$ref\": \"cardano-conway.json#/definitions/URL\"\n        },\n        \"hash\": {\n          \"$ref\": \"cardano-conway.json#/definitions/PoolMetadataHash\"\n        }\n      },\n      \"unevaluatedProperties\": false,\n      \"required\": [\n        \"url\",\n        \"hash\"\n      ]\n    },\n    \"PoolPubKeyHash\": {\n      \"title\": \"PoolPubKeyHash\",\n      \"type\": \"string\",\n      \"format\": \"bech32\",\n      \"pattern\": \"^(pool1)[02-9ac-hj-np-z]*$\",\n      \"examples\": [\n        \"pool12a39rkzfylvn9wfe8j6y8ucq6g2l4mw4azj70y0gd8ejczznyj2\"\n      ]\n    },\n    \"PoolParams\": {\n      \"title\": \"PoolParams\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"operator\": {\n          \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n        },\n        \"vrf_keyhash\": {\n          \"$ref\": \"cardano-conway.json#/definitions/VRFKeyHash\"\n        },\n        \"pledge\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"cost\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"margin\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n        },\n        \"reward_account\": {\n          \"$ref\": \"cardano-conway.json#/definitions/RewardAddress\"\n        },\n        \"pool_owners\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/Ed25519KeyHash\"\n          }\n        },\n        \"relays\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/Relay\"\n          }\n        },\n        \"pool_metadata\": {\n          \"$ref\": \"cardano-conway.json#/definitions/PoolMetadata\"\n        }\n      },\n      \"required\": [\n        \"cost\",\n        \"margin\",\n        \"operator\",\n        \"pledge\",\n        \"pool_owners\",\n        \"relays\",\n        \"reward_account\",\n        \"vrf_keyhash\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"GenesisHash\": {\n      \"title\": \"GenesisHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{56}$\"\n    },\n    \"GenesisDelegateHash\": {\n      \"title\": \"GenesisDelegateHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{56}$\"\n    },\n    \"Anchor\": {\n      \"title\": \"Anchor\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"url\": {\n          \"$ref\": \"cardano-conway.json#/definitions/URL\"\n        },\n        \"data_hash\": {\n          \"$ref\": \"cardano-conway.json#/definitions/DataHash\"\n        }\n      },\n      \"required\": [\n        \"url\",\n        \"data_hash\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"DRep\": {\n      \"title\": \"DRep\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\"key_hash\"]\n            },\n            \"key_hash\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Ed25519KeyHash\"\n            }\n          },\n          \"required\": [\"tag\", \"key_hash\"]\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\"script_hash\"]\n            },\n            \"script_hash\": {\n              \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n            }\n          },\n          \"required\": [\"tag\", \"script_hash\"]\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\"always_abstain\"]\n            }\n          },\n          \"required\": [\"tag\"]\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\"always_no_confidence\"]\n            }\n          },\n          \"required\": [\"tag\"]\n        }\n      ]\n    },\n    \"Certificate\": {\n      \"title\": \"Certificate\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"type\": \"object\",\n          \"title\": \"Stake Registration Certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"stake_registration\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Stake Deregistration Certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"stake_deregistration\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Stake Delegation Certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"stake_delegation\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"pool_keyhash\": {\n              \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\",\n            \"pool_keyhash\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Pool Registration Certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"enum\": [\n                \"pool_registration\"\n              ]\n            },\n            \"pool_params\": {\n              \"$ref\": \"cardano-conway.json#/definitions/PoolParams\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"pool_params\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Pool Retirement Certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"pool_retirement\"\n              ]\n            },\n            \"pool_keyhash\": {\n              \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n            },\n            \"epoch\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"pool_keyhash\",\n            \"epoch\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Registration certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"registration\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"coin\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\",\n            \"coin\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Unregistration certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"unregistration\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"coin\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\",\n            \"coin\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Vote delegation certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"vote_delegation\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"drep\": {\n              \"$ref\": \"cardano-conway.json#/definitions/DRep\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\",\n            \"drep\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Stake vote delegation certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"stake_vote_delegation\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"pool_keyhash\": {\n              \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n            },\n            \"drep\": {\n              \"$ref\": \"cardano-conway.json#/definitions/DRep\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\",\n            \"pool_keyhash\",\n            \"drep\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"stake_registration_delegation\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"pool_keyhash\": {\n              \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n            },\n            \"coin\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\",\n            \"pool_keyhash\",\n            \"coin\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"vote_registration_delegation\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"pool_keyhash\": {\n              \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n            },\n            \"drep\": {\n              \"$ref\": \"cardano-conway.json#/definitions/DRep\"\n            },\n            \"coin\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\",\n            \"pool_keyhash\",\n            \"drep\",\n            \"coin\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Stake registration delegation certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"stake_vote_registration_delegation\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"pool_keyhash\": {\n              \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n            },\n            \"drep\": {\n              \"$ref\": \"cardano-conway.json#/definitions/DRep\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\",\n            \"pool_keyhash\",\n            \"drep\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Vote registration delegation certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"vote_registration_delegation\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"drep\": {\n              \"$ref\": \"cardano-conway.json#/definitions/DRep\"\n            },\n            \"coin\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\",\n            \"drep\",\n            \"coin\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Stake vote registration delegation certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"stake_vote_registration_delegation\"\n              ]\n            },\n            \"credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"pool_keyhash\": {\n              \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n            },\n            \"drep\": {\n              \"$ref\": \"cardano-conway.json#/definitions/DRep\"\n            },\n            \"coin\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"credential\",\n            \"pool_keyhash\",\n            \"drep\",\n            \"coin\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Constitutional committee hot certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"auth_committee_hot\"\n              ]\n            },\n            \"committee_cold_credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"committee_hot_credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"committee_cold_credential\",\n            \"committee_hot_credential\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Resign committee cold certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"resign_committee_cold\"\n              ]\n            },\n            \"committee_cold_credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"anchor\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Anchor\"\n            }\n          },\n          \"required\": [\n            \"committee_cold_credential\",\n            \"tag\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Register DRep certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"register_drep\"\n              ]\n            },\n            \"drep_credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"coin\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n            },\n            \"anchor\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Anchor\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"drep_credential\",\n            \"coin\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Unregister DRep certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"unregister_drep\"\n              ]\n            },\n            \"drep_credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"coin\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"drep_credential\",\n            \"coin\"\n          ],\n          \"unevaluatedProperties\": false\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Update DRep certificate\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"update_drep\"\n              ]\n            },\n            \"drep_credential\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            },\n            \"anchor\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Anchor\"\n            }\n          },\n          \"required\": [\n            \"tag\",\n            \"drep_credential\"\n          ],\n          \"unevaluatedProperties\": false\n        }\n      ]\n    },\n    \"Constitution\": {\n      \"title\": \"Constitution\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"anchor\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Anchor\"\n        },\n        \"script_hash\": {\n          \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n        }\n      },\n      \"required\": [ \"anchor\" ]\n    },\n    \"GovActionId\": {\n      \"title\": \"GovActionId\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"transaction_id\": {\n          \"$ref\": \"cardano-conway.json#/definitions/TransactionHash\"\n        },\n        \"gov_action_index\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt16\"\n        }\n      },\n      \"required\": [\"transaction_id\", \"gov_action_index\"],\n      \"unevaluatedProperties\": false\n    },\n    \"GovAction\": {\n      \"title\": \"GovAction\",\n      \"type\": \"object\",\n      \"discriminator\": {\n        \"propertyName\": \"tag\"\n      },\n      \"oneOf\": [\n        {\n          \"type\": \"object\",\n          \"title\": \"Parameter Change Action\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"parameter_change_action\"\n              ]\n            },\n            \"gov_action_id\": {\n              \"$ref\": \"cardano-conway.json#/definitions/GovActionId\"\n            },\n            \"protocol_param_update\": {\n              \"$ref\": \"cardano-conway.json#/definitions/ProtocolParamUpdate\"\n            },\n            \"policy_hash\": {\n              \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n            }\n          },\n          \"required\": [ \"tag\", \"protocol_param_update\" ]\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Hard fork initiation action\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"hard_fork_initiation_action\"\n              ]\n            },\n            \"gov_action_id\": {\n              \"$ref\": \"cardano-conway.json#/definitions/GovActionId\"\n            },\n            \"protocol_version\": {\n              \"$ref\": \"cardano-conway.json#/definitions/ProtocolVersion\"\n            }\n          },\n          \"required\": [ \"tag\", \"protocol_version\" ]\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Trasury withdrawals action\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"treasury_withdrawals_action\"\n              ]\n            },\n            \"rewards\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"key\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/RewardAddress\"\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                  }\n                },\n                \"unevaluatedProperties\": false\n              }\n            },\n            \"policy_hash\": {\n              \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n            }\n          },\n          \"required\": [\"tag\"]\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"No confidence governance action\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"no_confidence\"\n              ]\n            },\n            \"gov_action_id\": {\n              \"$ref\": \"cardano-conway.json#/definitions/GovActionId\"\n            }\n          },\n          \"required\": [ \"tag\" ]\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Update committee\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"update_committee\"\n              ]\n            },\n            \"gov_action_id\": {\n              \"$ref\": \"cardano-conway.json#/definitions/GovActionId\"\n            },\n            \"members_to_remove\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n              }\n            },\n            \"committee\": {\n              \"type\": \"array\",\n              \"items\": {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"key\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                  }\n                },\n                \"unevaluatedProperties\": false\n              }\n            },\n            \"signature_threshold\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n            }\n          },\n          \"required\": [ \"tag\", \"signature_threshold\", \"committee\" ]\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"New constitution\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"new_constitution\"\n              ]\n            },\n            \"gov_action_id\": {\n              \"$ref\": \"cardano-conway.json#/definitions/GovActionId\"\n            },\n            \"constitution\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Constitution\"\n            }\n          },\n          \"required\": [ \"tag\", \"constitution\" ]\n        },\n        {\n          \"type\": \"object\",\n          \"title\": \"Info action\",\n          \"properties\": {\n            \"tag\": {\n              \"type\": \"string\",\n              \"enum\": [\n                \"info_action\"\n              ]\n            }\n          },\n          \"required\": [ \"tag\" ]\n        }\n      ]\n    },\n    \"Language\": {\n      \"title\": \"Language\",\n      \"type\": \"string\",\n      \"enum\": [\n        \"plutus_v1\",\n        \"plutus_v2\",\n        \"plutus_v3\"\n      ]\n    },\n    \"Mint\": {\n      \"title\": \"Mint\",\n      \"description\": \"Minting or burning of assets. A mapping from policy IDs (script hashes) to mappings from asset names to amounts (that can be negative). Allows for duplicate script hash keys.\",\n      \"type\": \"array\",\n      \"items\": {\n        \"type\": \"object\",\n        \"properties\": {\n          \"script_hash\": {\n            \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n          },\n          \"assets\": {\n            \"type\": \"array\",\n            \"items\": {\n              \"title\": \"Assets\",\n              \"type\": \"object\",\n              \"properties\": {\n                \"asset_name\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/AssetName\"\n                },\n                \"amount\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/NonZeroInt64\"\n                }\n              },\n              \"required\": [\n                \"asset_name\",\n                \"amount\"\n              ],\n              \"unevaluatedProperties\": false\n            }\n          }\n        },\n        \"required\": [\n          \"script_hash\",\n          \"assets\"\n        ],\n        \"unevaluatedProperties\": false\n      }\n    },\n    \"Ed25519Signature\": {\n      \"title\": \"Ed25519Signature\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^([0-9a-f][0-9a-f]){64}$\"\n    },\n    \"Ed25519PublicKey\": {\n      \"title\": \"Ed25519PublicKey\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^([0-9a-f][0-9a-f]){32}$\"\n    },\n    \"BootstrapWitness\": {\n      \"title\": \"BootstrapWitness\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"attributes\": {\n          \"type\": \"string\",\n          \"format\": \"hex\",\n          \"pattern\": \"^([0-9a-f][0-9a-f])*$\"\n        },\n        \"chain_code\": {\n          \"type\": \"string\",\n          \"format\": \"hex\",\n          \"pattern\": \"^([0-9a-f][0-9a-f]){32}$\"\n        },\n        \"signature\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Ed25519Signature\"\n        },\n        \"vkey\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Ed25519PublicKey\"\n        }\n      },\n      \"required\": [\n        \"attributes\",\n        \"chain_code\",\n        \"signature\",\n        \"vkey\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"RedeemerTag\": {\n      \"title\": \"RedeemerTag\",\n      \"type\": \"string\",\n      \"enum\": [\n        \"spend\",\n        \"mint\",\n        \"cert\",\n        \"reward\",\n        \"vote\",\n        \"propose\"\n      ]\n    },\n    \"Redeemer\": {\n      \"title\": \"Redeemer\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"data\": {\n          \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n        },\n        \"tag\": {\n          \"$ref\": \"cardano-conway.json#/definitions/RedeemerTag\"\n        },\n        \"index\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"ex_units\": {\n          \"$ref\": \"cardano-conway.json#/definitions/ExUnits\"\n        }\n      },\n      \"required\": [\n        \"data\",\n        \"tag\",\n        \"index\",\n        \"ex_units\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"Vkeywitness\": {\n      \"title\": \"Vkeywitness\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"vkey\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Ed25519PublicKey\"\n        },\n        \"signature\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Ed25519Signature\"\n        }\n      },\n      \"required\": [\n        \"vkey\",\n        \"signature\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"TransactionWitnessSet\": {\n      \"title\": \"TransactionWitnessSet\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"bootstraps\": {\n          \"title\": \"BootstrapWitnesses\",\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/BootstrapWitness\"\n          }\n        },\n        \"native_scripts\": {\n          \"title\": \"NativeScripts\",\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/NativeScript\"\n          }\n        },\n        \"plutus_data\": {\n          \"type\": \"array\",\n          \"title\": \"PlutusList\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n          }\n        },\n        \"plutus_scripts\": {\n          \"type\": \"array\",\n          \"title\": \"PlutusScripts\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/PlutusScript\"\n          }\n        },\n        \"redeemers\": {\n          \"type\": \"array\",\n          \"title\": \"Redeemers\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/Redeemer\"\n          }\n        },\n        \"vkeywitnesses\": {\n          \"type\": \"array\",\n          \"title\": \"VkeyWitnesses\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/Vkeywitness\"\n          }\n        }\n      },\n      \"required\": []\n    },\n    \"Transaction\": {\n      \"type\": \"object\",\n      \"title\": \"Transaction\",\n      \"properties\": {\n        \"auxiliary_data\": {\n          \"$ref\": \"cardano-conway.json#/definitions/AuxiliaryData\"\n        },\n        \"body\": {\n          \"$ref\": \"cardano-conway.json#/definitions/TransactionBody\"\n        },\n        \"is_valid\": {\n          \"type\": \"boolean\"\n        },\n        \"witness_set\": {\n          \"$ref\": \"cardano-conway.json#/definitions/TransactionWitnessSet\"\n        }\n      },\n      \"required\": [\n        \"body\",\n        \"is_valid\",\n        \"witness_set\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"VRFCert\": {\n      \"title\": \"VRFCert\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"output\": {\n          \"$ref\": \"cardano-conway.json#/definitions/ByteString\"\n        },\n        \"proof\": {\n          \"$ref\": \"cardano-conway.json#/definitions/ByteString\",\n          \"type\": \"string\",\n          \"pattern\": \"^[0-9a-f]{160}$\"\n        }\n      },\n      \"required\": [\n        \"output\",\n        \"proof\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"KESVKey\": {\n      \"title\": \"KESVKey\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\",\n      \"maxLength\": 64,\n      \"minLength\": 64\n    },\n    \"BlockHash\": {\n      \"title\": \"BlockHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\",\n      \"maxLength\": 64,\n      \"minLength\": 64\n    },\n    \"VRFVKey\": {\n      \"title\": \"VRFVKey\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\",\n      \"maxLength\": 64,\n      \"minLength\": 64\n    },\n    \"KESSignature\": {\n      \"title\": \"KESSignature\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{896}$\",\n      \"maxLength\": 896,\n      \"minLength\": 896\n    },\n    \"OperationalCert\": {\n      \"title\": \"OperationalCert\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"hot_vkey\": {\n          \"$ref\": \"cardano-conway.json#/definitions/KESVKey\"\n        },\n        \"kes_period\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"sequence_number\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"sigma\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Ed25519Signature\"\n        }\n      },\n      \"required\": [\n        \"hot_vkey\",\n        \"kes_period\",\n        \"sequence_number\",\n        \"sigma\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"HeaderBody\": {\n      \"title\": \"HeaderBody\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"block_number\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"slot\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n        },\n        \"prev_hash\": {\n          \"$ref\": \"cardano-conway.json#/definitions/BlockHash\"\n        },\n        \"issuer_vkey\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Ed25519PublicKey\"\n        },\n        \"vrf_vkey\": {\n          \"$ref\": \"cardano-conway.json#/definitions/VRFVKey\"\n        },\n        \"vrf_result\": {\n          \"$ref\": \"cardano-conway.json#/definitions/VRFCert\"\n        },\n        \"block_body_size\": {\n          \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n        },\n        \"block_body_hash\": {\n          \"$ref\": \"cardano-conway.json#/definitions/BlockHash\"\n        },\n        \"operational_cert\": {\n          \"$ref\": \"cardano-conway.json#/definitions/OperationalCert\"\n        },\n        \"protocol_version\": {\n          \"$ref\": \"cardano-conway.json#/definitions/ProtocolVersion\"\n        }\n      },\n      \"unevaluatedProperties\": false,\n      \"required\": [\n        \"block_number\",\n        \"slot\",\n        \"issuer_vkey\",\n        \"vrf_vkey\",\n        \"vrf_result\",\n        \"block_body_size\",\n        \"block_body_hash\",\n        \"operational_cert\",\n        \"protocol_version\"\n      ]\n    },\n    \"Header\": {\n      \"title\": \"Header\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"body_signature\": {\n          \"$ref\": \"cardano-conway.json#/definitions/KESSignature\"\n        },\n        \"header_body\": {\n          \"$ref\": \"cardano-conway.json#/definitions/HeaderBody\"\n        }\n      },\n      \"required\": [\n        \"body_signature\",\n        \"header_body\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"Block\": {\n      \"title\": \"Block\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"auxiliary_data_set\": {\n          \"type\": \"object\",\n          \"title\": \"AuxiliaryDataSet\",\n          \"description\": \"A mapping from transaction indices to AuxiliaryData values\",\n          \"patternProperties\": {\n            \"^(0|[1-9][0-9]*)$\": {\n              \"$ref\": \"cardano-conway.json#/definitions/AuxiliaryData\"\n            }\n          },\n          \"unevaluatedProperties\": false\n        },\n        \"header\": {\n          \"$ref\": \"cardano-conway.json#/definitions/Header\"\n        },\n        \"invalid_transactions\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"allOf\": [\n              {\n                \"title\": \"TransactionIndex\"\n              },\n              {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              }\n            ]\n          }\n        },\n        \"transaction_bodies\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/TransactionBody\"\n          }\n        },\n        \"transaction_witness_sets\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"cardano-conway.json#/definitions/TransactionWitnessSet\"\n          }\n        }\n      },\n      \"unevaluatedProperties\": false,\n      \"required\": [\n        \"auxiliary_data_set\",\n        \"header\",\n        \"invalid_transactions\",\n        \"transaction_bodies\",\n        \"transaction_witness_sets\"\n      ]\n    }\n  }\n}\n"
  },
  {
    "path": "CIP-0116/changelog.md",
    "content": "\n# CIP-0116 JSON Schema Changelog\n\nThis document aims to catalog the changes between JSON schemas, to be updated as new eras are added.\n\n## Chang Hardfork [Babbage](./cardano-babbage.json) -> [Conway](./cardano-conway.json) (2024-xx-xx)\n\n- [Babbage CDDL (12dc779)](https://github.com/IntersectMBO/cardano-ledger/blob/12dc779d7975cbeb69c7c18c1565964a90f50920/eras/babbage/impl/cddl-files/babbage.cddl)\n- [Conway CDDL (xxxxxxx)]()\n\n### Added\n\n### Changed\n\n### Removed\n\n### Notes\n\n## xxxx Hardfork [Conway](./cardano-conway.json) -> xxxx (202x-xx-xx)\n\n- [Conway CDDL (xxxxxxx)]()\n- \n\n### Added\n\n### Changed\n\n### Removed\n\n### Notes\n"
  },
  {
    "path": "CIP-0117/README.md",
    "content": "---\nCIP: 117\nTitle: Explicit script return values\nCategory: Plutus\nStatus: Active\nAuthors:\n    - Michael Peyton Jones <michael.peyton-jones@iohk.io>\nImplementors: \n    - Michael Peyton Jones <michael.peyton-jones@iohk.io>\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/747\nCreated: 2024-01-22\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nToday, Plutus Core scripts signal success or failure exclusively by whether the script terminates normally or abnormally (with an error).\nThis leads to some false positives, where a script terminates normally, but this was not intended by the author.\nWe propose to additionally look at what the script evaluates to when checking for success or failure.\n\n## Motivation: why is this CIP necessary?\n\nConsider the following Plutus scripts, intended to be used as minting policy scripts:\n\n```\n\\redeemer -> \\datum -> \\script-context -> (builtin error)\n```\n\n```\n\\redeemer -> \\script-context -> (con false)\n```\n\nToday, both of these will unconditionally succeed! \n\n1. Minting policies only receive two arguments, but this script expects three before it does any work. It therefore evaluates successfully to a lambda.\n2. This script evaluates _successfully_ to `(con false)`, but the return value is irrelevant since it terminates successfully.\n\nIn both cases the user has made a mistake, but this result is that the script fails _open_, that is, anyone can spend such an output.\nA variant of the first mistake is for a script to expect too _few_ arguments, but this will almost always result in an error and so fail closed.[^failing-open]\n\n[^failing-open]: It is not universally clear whether it is good to fail open or closed, but generally for systems like this we tend to fail closed, and it is also easier to detect such failures during testing.\n\nHistorically, Plutus Core was going to be a typed language, and at least the first kind of error would have been caught by the typechecker. \nHowever, today there is little stopping people from making such mistakes.\n\nWhile these mistakes are relatively easily avoidable (any good smart contract toolkit should prevent them), it is nonetheless a potential landmine for users.\n\n## Specification\n\nThe specification for checking whether a Plutus Core script accepts a transaction changes as follows (the new part is in brackets):\n\n> A Plutus Core script S with arguments A1...An accepts a transaction if 'eval(S A1 ... An)' succeeds [and evaluates to the builtin constant 'unit'].\n\nThis change is not backwards-compatible and will need to go into a new Plutus ledger language.\n\n## Rationale: how does this CIP achieve its goals?\n\nSince the return value of a script will now be significant, a script will only succeed if the whole thing evaluates to 'unit'.\nThis is very unlikely to happen by accident: mistakes in the number of arguments or in what to return will result in failure.\n\n### Alternatives \n\n- The status quo is not terrible, and we could simply accept it.\n- The return value could be a boolean constant, with 'true' indicating success and 'false' indicating failure.\n    - This is slightly more complicated, and technically we only need a designated success value, since \"anything else\" indicates failure. We don't need to distinguish between \"normal exit indicating rejection of the transaction\" and \"abnormal exit\".\n- We could specifically detect when a script returns a lambda, and say that that is a failure.\n    - This is patching up one particular hole, whereas the proposal here has much more coverage by failing everything that doesn't quite specifically return 'true'.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] The proposal is implemented in the Ledger.\n- [x] The ledger changes are released on Mainnnet.\n\n### Implementation Plan\n\n- [x] The Plutus team will implement the changes to the Ledger.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0][].\n\n[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n"
  },
  {
    "path": "CIP-0118/README.md",
    "content": "---\nCIP: 118\nTitle: Nested Transactions\nCategory: Ledger\nStatus: Proposed\nAuthors:\n    - Polina Vinogradova <polina.vinogradova@iohk.io>\n    - Will Gould <will.gould@iohk.io>\n    - Alexey Kuleshevich <alexey.kuleshevich@iohk.io>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/780\n    - https://github.com/cardano-foundation/CIPs/pull/862\n    - https://github.com/cardano-foundation/CIPs/pull/880\nCreated: 2024-03-11\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nWe propose a set of changes that revolve around nested transactions, a construct for composing\ncertain kinds of _partially valid transactions_, such as unbalanced transactions, or transactions\nwith missing fees. The missing value or data must be provided by a subsequent\ntransaction. Such partially valid transactions, which are called sub-transactions,\nmust be placed into batches by aggregators.\nThe batch must also include a _top-level_ transaction. The completed batch must be fully balanced.\nApplying a complete batch results in a valid ledger update,\nhowever, applying each of the individual transactions would not be possible. This scheme allows users\nto make and accept swap offers without the need for a centralized exchange or two-way communication.\nIt gives non-ADA holders a way to engage with the Cardano ecosystem. It also creates new business opportunities\nfor users willing to make and accept offers, run aggregator services, subsidize the use of their DApps, etc.\n\n## Motivation: why is this CIP necessary?\n\nThis CIP provides a partial solution to the problems described in\n[CPS-15](https://github.com/cardano-foundation/CIPs/pull/779).\nIn particular, it describes some ledger changes that allow settlement\nof intents that require *counterparty irrelevance*, including many of the swap use cases\nand DApp fee sponsorship. *Counterparty irrelevance* is a property of a transaction batching protocol\nwherein a transaction author is not required to approve the batch into which the\ntransaction will be included, and that decision can be made autonomously by the batcher.\nThis property allows batches to be made with one-way communication (i.e. broadcast) only.\n\nOne of the motivations behind designing this solution is _Babel fees_,\nwhich is a requirement to support \"paying transaction fees in non-ADA tokens\".\nThe Babel-fees usecase is a special case of a swap. Supporting swaps is very desirable functionality for cryptocurrency\nledgers.\n\nThere are off-chain solutions being developed for the purpose of achieving the same\n(major) goals, including fee coverage, atomic swaps, DApp fee sponsorship,\ncollateral sponsorship, etc. This gives us indication that it is a worthy pursuit\nto solve this problem at the ledger level, in a way that is cheaper, more convenient,\nmaintains formal guarantees, requires less off-chain communication, and does not require deposits or interaction\nwith smart contracts.\n\n### New functionality\n\nThe ledger changes we describe have been developed as a result of the discussions and\nproposals in previous CIPs, including previous versions of validation zones proposals,\nand Transaction Swaps. The following\nnew functionality are supported by the changes :\n\n1. transactions can be batched\n- batch contains one top-level transaction, with multiple possible sub-transactions ;\n\n2. the batch must be balanced, but individual transactions in it do not have to be, so\n- transactions in a single batch may satisfy each others' fees and minUTxOValue ;\n- unbalanced transactions can be interpreted as swap offers or intents, getting resolved within a complete batch ;\n\n3. scripts are shared across all transactions in a single batch\n- enables script deduplication ;\n\n4. guarding scripts enable sub-transactions to specify properties required of batches in which they may be included\n- allows transaction authors to impose constraints\non the batches into which their transactions are added without knowing the exact contents of the batch ;\n\n5. the top-level transaction must provide collateral for all scripts in its sub-transactions\n- sub-transactions will not be required to cover the collateral for scripts that they will include ;\n\n6. isolation of script context for plutus script execution. Plutus scripts in one sub-transactions do not see other sub-transactions or the top level transaction in their context.\n\n7. ability to mix new features in the same transaction that are incompatible with older Plutus scripts. Historically usage of new features together with older Plutus scripts in a transaction would lead to phase1 validation failure. Isolation of context breaks this incompatibility for newer Plutus versions and partially for the old ones as well.\n\n8. finer control of the order of processing parts of the transaction. For example, today it is not possible to delegate to a DRep and withdraw rewards in the same transaction, since withdrawals are processed before certificates by the ledger. Having ability to break up parts of the transaction into separate sub-transactions gives the user ultimate control of which part of the transaction should be processed first.\n\nWe note that the functionality added by (4) makes it possible to view each sub-transaction as an *intent*\nto perform a specific action (whose fulfillment within the batch is ensured by the validation of the guard script).\nThe types of intents supported by this are ones that *do not require\nthe relaxation of existing ledger rules*. That is, a user can specify any intent the rest of the batch\nmust satisfy without violating existing ledger rules. Adding support for intents that *do require ledger rule relaxations*, such\nthe ones in (2, 3, 5) above, must be done\nmore carefully to ensure secure operation of the ledger program.\n\n### New use cases\n\nAs a result of introducing this new functionality, many new use cases will be supported,\namong which are the following :\n\n**Open (atomic) swaps.** A user wants to swap 10 Ada for 5 tokens `myT`. He creates an unbalanced transaction `tx` that\nhas extra 10 Ada, but is short 5 `myT`.\nAny counterparty that sees this transaction can create a top-level\ntransaction `tx'` that includes `tx` as a sub-transaction. The transaction\n`tx'` would have extra 5 `myT`, and be short (missing) 10 Ada. Implementing nested transactions\nwill allow users to build sub- and top-level-transactions that achieve this swap without\nthe need for interacting with a smart contract.\n\n**DEX aggregators.** A DEX aggregator aggregates multi-party swaps, often using its\nown liquidity to complete favourable trades. The mechanism for achieving this using nested transactions\nis the same as it is for atomic swaps, but a single may include many more transactions in a\ntop-level transaction.\n\n**Babel fees.** A Babel fee-type transaction is a specific instance of the first use case. A user creates a sub-transaction `tx`\nwhere the missing assets are necessarily a\nquantity of Ada. In particular, it does not pay its own fees, collateral, or cover any new `minUTxOValue`s.\nThe counterparty creates a top-level transaction which includes `tx` as a sub-transaction and includes\nextra Ada which goes towards paying transaction fees, collateral, etc.\n\n**DApp fee and min-UTxO sponsorship.** A DApp may choose to subsidize the cost of its use\n(e.g. by paying the cost of ExUnits, paying fees/minUTxO, and providing collateral) for the\npurposes of encouraging users to interact with it. Implementing nested transactions\nwill allow building transaction batches that subsidize\nDApp-using sub-transactions in this way.\n\n## Specification\n\nFor the Agda specification prototype built on top of the current ledger spec,\nsee [Agda spec](https://github.com/IntersectMBO/formal-ledger-specifications/compare/polina-nested-txs).\n\n### Transaction structure changes\n\nWe add the following new field to `TxBody` :\n\n1. `subTxs :: [SubTx]`\n-  sub-transactions in the batch\n\n2. We also need implementation of the [CIP-112 | Observe Script Type](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0112/README.md) in order to allow sub-transactions to require scripts to be executed at the top level with all sub-transactions in their context. \"Observe script type\" is called \"Guard script type in the Ledger implementation, therefore going forward we will use term \"guards\", instead of \"observers\", while referring to the same concept.\n\n### Plutus\n\n#### New version\n\nA new Plutus version, `PlutusV4`, will be required, since the constraints on what it means for\na transaction to be valid, as well as the transaction structure itself, are changed. Top-level transactions with no sub-transactions are still able to interact\nwith prior versions of Plutus scripts, as they will be completely backwards compatible. Transactions that are partially valid and/or using any new features\nintroduced here are not. That is, transactions containing sub-transactions or top-level guards\ncannot run scripts with `PlutusV3` or earlier version.\n\n#### TxInfo\n\nThe `TxInfo` shown to a PlutusV4 script has an added field :\n\n- `txInfoSubTxs :: [SubTxInfo]`, which is populated with the `SubTxInfo` data for all sub-transactions in the batch\nwhenever both hold : (1) the transaction for which info is being constructed is top-level, and (2) the script purpose for\nwhich this info is constructed is `Guard` from [CIP-112 | Observe Script Type](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0112/README.md).\n\n### Changes to Transaction Validity\n\nKey points about transaction validity are as follows :\n\n1. Sub-transactions are not allowed to contain sub-transactions themselves (enforced during deserialization, see [CDDL section](#CDDL)).\n\n2. Sub-transactions are not allowed to contain collateral inputs or collateral return output (enforced during deserialization, see [CDDL section](#CDDL)). Only the top-level transaction is allowed to (furthermore, obligated to)\nprovide sufficient collateral for all scripts that are run as part of validating all sub-transactions in that batch. If any script in a\nbatch fails, none of the transactions in the batch are applied, only the collateral is collected.\n\n3. Sub-transactions are not allowed to specify the fee, since the final fee will depend on the complete batch and the top-level transaction (enforced during deserialization, see [CDDL section](#CDDL)).\n\n4. Transactions using new features are not allowed to run scripts of PlutusV3 or earlier.\n\n5. All scripts are shared across all transactions within a single batch, so attaching one script to either a sub- or a top-level-transaction\nallows other transactions to run it without also including it in its own scripts. This includes references scripts that are sourced from the\noutputs to which reference inputs point in the UTxO. These referenced UTxO entries could be outputs of preceding transactions in the batch.\nDatums (both from reference inputs and ones attached to other transactions) are also shared in this way. As before, only the datums fixed by the\nexecuting transaction are included in the `TxInfo` constructed for its scripts, however, now they don't necessarily have to be attached to\nthat transaction.\n\n6. All inputs of all transactions in a single batch must be contained in the UTxO set before any of the\nbatch transactions are applied. This ensures that operation of scripts is not disrupted, for example, by\ntemporarily duplicating thread tokens, or falsifying access to assets via flash loans.\nIn the future, this may be up for reconsideration.\n\n7. The batch must be balanced (POV holds). The updated `produced` and `consumed` calculations sum up the appropriate\nquantities not for individual transactions, but for the entire batch, including the top-level and its sub-transactions.\n\n8. The total size of the top-level transaction (including all its sub-transactions) must be less than the `maxTxSize`.\nThis constraint is necessary to ensure efficient network operation since batches will be transmitted wholesale across the Cardano network.\n\n### Using older PlutusV1 - PlutusV3 scripts\n\nIt is usually not possible to make new features that are added to a transaction available to older scripts. That is because new changes could affect the invariants that older scripts might rely on and because it is impossible to retroactively change the structure of plutus script context of a script that has been deployed on mainnet. However, it would be very useful if we could provide the property of isolation to existing scripts that are used on-chain today. If we did, this would allow PlutusV1 - PlutusV3 scripts to co-exist in the same transaction with any new feature that would be added in the future.\n\nIn order to make this a reality we propose a special mode for the top level transaction validation. This mode will be enabled automatically when a top level transaction uses any of the older PlutusV1, PlutusV2 or PlutusV3 scripts. This special mode will validate the top level transaction in isolation from all of the sub-transactions that were included in it. In particular:\n* top level transaction will have to balance out by itself and all of the sub-transactions will have to balance each other, without relying on the top level transaction.\n* top level transaction cannot use any of the sub-transactions as the source of actual scripts or datums. They will have to be supplied at the top level through the usual means of reference inputs or through the witness set.\n* top level transaction itself cannot use any of the new features. Eg. guards list cannot contain any script hashes at the top level.\n\nWith this slight modification to the rules we will be able to guarantee backwards compatibility for PlutusV1 - PlutusV3 scripts. The only change visible to the older scripts in the script context would be potentially slightly higher than usual transaction fee, which is not disallowed today.\n\nAn example of this use case came up in the context of [CIP-159 - Account Address Enhancement](https://github.com/cardano-foundation/CIPs/pull/1061). Aforementioned CIP adds a new field called `direct_deposit` to the transaction body, which would normally be unusable together in the same transaction that executes any script older than PlutusV4. As it turns out, however, it is critical for DeFi to be able to mix existing scripts and `direct_deposit` in the same transaction. With addition of this feature it will be possible to add a sub-transaction that uses this new field, while any script that is older than PlutusV4 would be just fine in the top level transaction.\n\n### Collateral and Phase-2 Invalid Transactions\n\nEnough collateral must be provided by the top-level transaction to cover the sum of all the\nexecution units of all Plutus scripts in sub-transactions and top level transaction.\nThe sub-transactions will not be able to supply collateral for their own scripts.\n\nSame as previously, it is important to first perform a phase-1 validation for the full transaction, including all of its sub-transactions, before executing any Plutus scripts. In other words phase-2 validation is performed for the full transaction as the last step of validation, instead of on per sub-transaction basis. This part is critical for the safety of the mempool, in order to prevent an attack where many invalid transactions are submitted with very expensive scripts.\n\n### Required Top Level Guards\n\n[CIP-112 | Observe Script Type](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0112/README.md) introduces Guards, which are arbitrary scripts that can be required by the transaction builder. It seems natural to tap into this functionality to allow sub-transaction builders to require arbitrary scripts to be executed at the top-level as well. In order to achieve that, sub-transactions will have a new field `requiredTopLevelGuards`, which will not be available in the top level transaction. The only enforcement that Ledger will have to do is to make sure that script hashes listed in that field are also present in the list of Guards in the top-level transaction. It will be the responsibility of the top level transaction builder to satisfy this requirement by adding all of the required guards from sub-transactions in the top level transaction. Moreover, in case when required guard is a plutus script, top level transaction builder will have to supply the redeemer for that script.\n\nSub-transaction builders might not have access to the full transaction until their sub-transaction is included on chain, therefore they will not be able to provide executions units for those top level guards they require. However, they will need ability to provide an argument to such scripts. For this reason this field will look like this:\n\n```haskell\n  requiredTopLevelGuards :: [(ScriptHash, Data)]\n```\n\nIn other words, the data, which will be passed when script gets executed, will be supplied by sub-transaction together with the hash of that script.\n\nOne of the properties that is applicable only to the guard scripts in the top level transaction, when comparing to other type of scripts in a transaction, is that they will be able to see the full transaction in their context, including all of the sub-transactions. These are the only scripts that, in their `TxInfo` data, get a non-empty `txInfoSubTxs :: [SubTxInfo]` field, which is populated with the infos of the sub-transactions.\n\nBy taking this approach, we provide the means for sub-transaction builders to require scripts that will have access not only to their own sub-transaction they are building, but also to the top level transaction and all other sub-transactions it will include.\n\n### System Component Changes\n\n#### CDDL\n\nThe changes to the CDDL specification are as follows :\n\n```cddl\n;; CIP-112\nguards = nonempty_set<addr_keyhash>\n       / nonempty_oset<credential>\n\ntransaction_body =\n  {   0  : set<transaction_input>\n  ,   1  : [* transaction_output]\n  ,   2  : coin\n  , ? 3  : slot_no\n  , ? 4  : certificates\n  , ? 5  : withdrawals\n  , ? 7  : auxiliary_data_hash\n  , ? 8  : slot_no\n  , ? 9  : mint\n  , ? 11 : script_data_hash\n  , ? 13 : nonempty_set<transaction_input>\n  , ? 14 : guards\n  , ? 15 : network_id\n  , ? 16 : transaction_output\n  , ? 17 : coin\n  , ? 18 : nonempty_set<transaction_input>\n  , ? 19 : voting_procedures\n  , ? 20 : proposal_procedures\n  , ? 21 : coin\n  , ? 22 : positive_coin\n  , ? 23 : [+ sub_transaction] ;; new field\n  }\n\nsub_transaction =\n  [sub_transaction_body, transaction_witness_set, auxiliary_data / nil]\n\n;; Missing `fee`, `collateral` and `collateral return output`, when comparing to `transaction_body`\nsub_transaction_body =\n  {   0  : set<transaction_input>\n  ,   1  : [* transaction_output]\n  , ? 3  : slot_no\n  , ? 4  : certificates\n  , ? 5  : withdrawals\n  , ? 7  : auxiliary_data_hash\n  , ? 8  : slot_no\n  , ? 9  : mint\n  , ? 11 : script_data_hash\n  , ? 14 : guards\n  , ? 15 : network_id\n  , ? 17 : coin\n  , ? 18 : nonempty_set<transaction_input>\n  , ? 19 : voting_procedures\n  , ? 20 : proposal_procedures\n  , ? 21 : coin\n  , ? 22 : positive_coin\n  , ? 24 : [+ required_top_level_guard] ;; new field\n  }\n\nrequired_top_level_guard = [credential, plutus_data / nil]\n```\n\n### Network and Consensus Changes\n\nWith this design, there are no changes to these components at all.\n\n### Cardano CLI\n\nTools for building transactions will need to introduce ability to build sub-transactions in\nisolation and ability include sub-transactions into the top level transaction.\n\n### Off-Chain Component Architecture\n\nPartially valid transactions cannot be communicated across the Cardano\nnetwork or stored in the mempool. This must be done off-chain.\nThis CIP does not include an off-chain component, even though one would be necessary\nfor\n\n- communicating,\n- storing, and\n- matching\n\nsuch transactions. The reason\nfor this is that different usecases may require different off-chain architecture.\nIn particular, different usecases will have specific configurations of the\nkinds of transactions or requests they are interested in engaging with.\nFor example, an individual user may care only about offers of a specific token.\nAn exchange may care about offers of any popular\nasset at a good price.\n\nMost importantly, off chain component does not have to be open source, nor distributed and can be used to build a for-profit business around it.\n\n\n#### Babel Service\n\nA Babel service is the catch-all name we use here to refer to a service that is interested\nin engaging with partially valid unbalanced transactions. Communication channels between such services and users constructing\nunbalanced transactions are required. Such a service can be run by anyone, probably\nalongside a full node. It would have to have a filter set for the kinds of transactions\nit will engage with. There is no guarantee that every unbalanced sub-transaction\nwill ever make it on chain, since there is no guarantee that it will be eventually balanced by a subsequent incoming sub-transaction. So, each service will have\nto solve this problem for themselves, probably using an appropriate filter.\n\n#### Required Top level Guards\n\nA service processing partially valid transactions (such as the Babel service) may accept incoming transactions\nthat contain non-empty `requiredTopLevelGuards`. This means this service must construct batches containing these\ntransactions and also satisfy the batch-level constraints imposed by these scripts being included in the `guards` field of the top level transaction.\n\nAn additional high-level language may be beneficial to specify what the guard scripts\nactually require of the batch, as Plutus script constraints may be difficult to work with directly.\n\n## Rationale: how does this CIP achieve its goals?\n\nThe primary purpose of this CIP is to enable Cardano node support for a specific kind of transaction\nbatching which we call *nested transactions*. The specification we presented includes the features\ndiscussed in the [Motivation section](#Motivation). In particular, it allows the individual\nsub-transactions inside batches (top-level transactions) to be unbalanced, and to not\nbe obligated to pay fees or provide collateral, while still ensuring the preservation of\nvalue property and a functioning collateral mechanism at the batch level.\nThis is the main property required to securely support the use cases\ndiscussed in the [Motivation section](#Motivation).\n\n**Pseudo-code example**. To give a more detailed illustration of how the specification changes presented\nin this CIP support use cases and features discussed in the [Motivation section](#Motivation), we present the following\npseudocode example :\n\n```\ntx =\n  Body\n  { inputs = [txIn0:FOO 5]\n  , outputs = [txOut:ADA 9]\n  , fee = 1 ADA\n  , subTx =\n     [ Tx\n       { body = Body\n         { inputs = [txIn00:FOO 95]\n         , outputs = [txOut00:ADA 200]\n         , requiredTopLevelGuards = [(scriptHash0, data00)]\n         }\n         Wits {\n          redeemers = [(RedeemerPtr Spending 0, (exUnits000, data000))]\n          scripts = [spendingScript00]\n        }\n       }\n     , Tx\n       { body = Body\n         { inputs = [txIn10:ADA 210]\n         , outputs = [txOut10:FOO 100]\n         , requiredTopLevelGuards = [(scriptHash0, data10), (scriptHash1, data11)]\n         }\n       }\n         Wits {\n          redeemers = [(RedeemerPtr Spending 0, (exUnits100, data100))]\n          scripts = [spendingScript10, guardScript1]\n        }\n     ]\n  , guards = [scriptHash0, scriptHash1]\n  }\n  Wits {\n   redeemers = [ (RedeemerPtr Guard 0, (exUnits0, data0))\n               , (RedeemerPtr Guard 1, (exUnits1, data1))\n               , (RedeemerPtr Spending 0, (exUnits2, data2))\n               ]\n   scripts = [guardScript0, spendingScript0]\n  }\n```\n\nThis example showcases the following use cases and features :\n\n- performing a swap of 95 `FOO` for 200 `ADA` (this amount includes the counterparty paying for the transaction fee of the swap-offer transaction)\n\n- top level transaction builder is paying the fee with a multi asset (aka Babel fee)\n\n- execution of scripts at all levels, i.e. `spendingScript00` and `spendingScript10` for sub-transactions, and `guardScript0`, `guardScript1`, `spendingScript0` for top-level transaction.\n\nThe top-level transaction executes a spending script `spendingScript0`, which is not given `txInfoSubTxs`, and two\nguard scripts, `guardScript0`, `guardScript1`, which do get to see `txInfoSubTxs`. No sub-tx scripts\n(`spendingScript0` and `spendingScript1`) get to see `txInfoSubTxs` or the top level transaction, they only see their own respective sub-transaction in the `TxInfo`.\n\n- Sub-transaction supplies `guardScript1` for the top level execution, while `guardScript0` is supplied in the top level transaction witnesses. This serves as the example of irrelevance of where the scripts are coming from, as long as they are supplied by someone.\n\n- Both sub-transactions require execution of the same `guardScript0` script, which is executed only once with all the arguments supplied to it, instead of executing it as many times as it appears in sub-transactions.\n\n### Comparison with Other Designs\n\n#### CIP-0131 \"[Transaction Swaps](https://github.com/cardano-foundation/CIPs/pull/880)\"\n\nTransaction swaps achieve almost exactly the same goals as this CIP. The main differences\nare :\n\n1. The top-level transaction contains subTxs, which\nare lists of transactions. They are processed as individual transactions, alongside the top-level tx. As a result,\n\n- the `TxIn` of each output can be computed for each output partially valid transaction\nat the time of construction\n\n- the `TxId` of the transaction for each entry in the UTxO set is necessarily\nsigned by all the keys required by that transaction\n\n- the input to (and therefore output of) each script is predictable at the time of (partially valid) tx construction,\nso that it is possible to compute required `ExUnits` for each of the scripts run by every sub-transaction\nat the time of construction\n\n2. Contracts can only view data in the transaction running them, except in the case\nthat a top-level tx is running a guard script\n\n3. In this design, script outputs (except of guards) can be computed by any Babel service receiving an incoming\npartially valid transaction (as well as the author of the transaction), and they do not depend on the top-level transaction.\nThis makes constructing (and determining whether it is even possible to construct)\na valid top-level transactions more straightforward.\n\n\n#### CIP-0118 \"Validation Zones-implicit\"\n\nThe key difference between the Validation Zones-implicit design and this design is that\nthis design does not require any changes to be made to the operation\nof the mempool. This is achieved by building a top-level transaction that includes\na list of sub-transactions, rather than modifying block structure to contain\nsuch lists of transactions directly. Also, this design allows `ExUnits` to be specified by the top-level transaction for\nsub-transactions.\n\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] Formal specification of the ledger changes is available.\n- [ ] Hard fork enabling Nested Transactions is successfully executed across Cardano testnets.\n- [ ] Hard fork enabling Nested Transactions is successfully executed on Cardano mainnet.\n\n### Implementation Plan\n\n- [ ] Update to the formal ledger specification with the changes proposed here\n- [ ] Implement the outlined changes in the Cardano node\n- [ ] Complete a hard fork enabling support for the changes outlined here\n- [ ] Track implementation of this CIP via top level ticket on the Ledger repository, including links to implementations: [Nested Transactions](https://github.com/IntersectMBO/cardano-ledger/issues/5123)\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0119/README.md",
    "content": "---\nCIP: 119\nTitle: Governance metadata - DReps\nCategory: Metadata\nStatus: Proposed\nAuthors:\n    - Thomas Upfield <thomas.upfield@iohk.io>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/788\n    - https://vimeo.com/912374177/0e9299fb5d?share=copy\n    - https://vimeo.com/915297122/c39f4a739b?share=copy\nCreated: 2024-02-07\nLicense: CC-BY-4.0\n---\n\n## Abstract\nThe Conway ledger era ushers in on-chain governance for Cardano via [CIP-1694 | A First Step Towards On-Chain Decentralized Governance](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md), with the addition of many new on-chain governance artefacts. Some of these artefacts support linking to off-chain metadata as a way to provide context.\n\nThe [CIP-100 | Governance Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0100) standard provides a base framework for how all off-chain governance metadata should be formed and handled. But this is intentionally limited in scope, so that it can be expanded upon by more specific subsequent CIPs.\n\nThis proposal aims to provide a specification for off-chain metadata vocabulary that can be used to give context to CIP-100 for DRep registration and updates. Without a sufficiently detailed standard for DRep metadata we introduce the possibility to undermine the ability of DReps to explain their motivations and therefore people looking for someone to represent them with the best possible information available to make that choice. Furthermore a lack of such standards risks preventing interoperability between tools, to the detriment of user experiences.\n\n#### Thank you\nThank you to [everyone who participated in the CIP workshops](#Acknowledgements), and to @ryun1 for creating the JSON-LD schemas for this CIP and for his excellent technical support and invaluble advice. Thank you also to the other CIP editors and attendees of the CIP Editors' Meetings where this CIP was refined, most notably @rphair and @Crypto2099. \n\n## Motivation: why is this CIP necessary?\nCIP-1694 has set forth a model of a blockchain controlled by its community, and in doing so has challenged providers to build apps and tools that will allow users easy access to the governance features currently being built into Cardano.  Minimum viable tools must be ready at the time these governance features are launched.\n\nThe motivation for this CIP therefore is to provide these toolmakers with a simple and easy to accommodate standard which, once adopted, will allow them to read and display the metadata created by anyone who follows this standard when creating their DRep registration or update metadata. Tooling designed for DReps so that they can easily create metadata will also be made possible, because toolmakers will not need to individually innovate over the contents or structure of the metadata that their tool creates.  \n\nMetadata is needed because blockchains are poor choices to act as content databases. This is why governance metadata anchors were chosen to provide a way to attach long form metadata content to on-chain events. By only supplying a url to the off-chain metadata, and a hash of that metadata to the blockchain we ensure correctness of data whilst minimising the amount of data posted on-chain.\n\n### Benefits\nI believed that this CIP would provide a benefit to:\n\n#### Potential delegators\nWhen observing from the chain level, tooling can only see the content and history of DRep registration and update certificates and any associated anchors. These on-chain components do not give any context to the motivation of a DRep, even though this information would likely be the desired context for people who might delegate their voting power. By providing rich contextual metadata we enable people choosing a DRep to delegate their voting power to make well informed decisions.\n\n#### DReps\nDReps will be able to use tools that create metadata in a standard format. This in turn will allow their metadata to be read by apps that will render their words on screen for potential delegating Ada Holders to enjoy, this may lead to greater levels of delegation. \n\n#### All participants\nBy standardising off-chain metadata formats for any tooling which creates and/or renders metadata that is referenced in DRep registration and update transactions we facilitate interoperability. This in turn promotes a rich user experience between tooling. This is good for all governance participants.\n\n## Specification\nThis CIP explains the structure of any metadata referenced in a metadata anchor optionally included in any DRep registration or update transaction. \n\n### Teams\nThis CIP has been written for individuals acting in the capacity of DReps, and not for teams of people collaborating as a single DRep, although this does not preclude teams from using metadata in the structure explained by this CIP.\n\n### Witnesses\nDRep Metadata will not follow the CIP-100 specification related to signing the metadata, the [`authors` property](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#high-level-description) can be left blank without the need for tooling providers to warn their users that the author has not been validated. Instead the author can be derived from the DRep ID associated with the registration or update. The need for an `authors` field will also be discarded in favour of including `givenName`s and `Identity` inside of the `body` field. For the avoidance of doubt this CIP recommends that the entire authors property be left blank, and that tooling ignore it. \n\n### Extended Vocabulary\nLike CIP-108, this CIP also extends the potential vocabulary of CIP-100's `body` property. \n\nFurthermore we extend the Schema.org definition of a [Person](https://schema.org/Person). Any property of Person maybe included within the `body`.\n\n>**Reminder for tooling providers/builders** DRep metadata is user generated content.\n\nThe following are a list of properties tooling should expect to encounter:\n\n#### `paymentAddress`\n- Optional\n- Bech32 encoded payment address, for the same network as the DRep registration is to be submitted to.\n\nDReps may want to receive tokens for a variety of reasons such as:\n- donations\n- expenses\n- any incentive program\n\nTherefore there MAY be a `paymentAddress` field in the metadata where such payments could be sent. This makes such an address public and payments to DReps transparent. \n\nThis SHOULD NOT be confused with the `address` property of a [Person](https://schema.org/Person), `address` in the context of a DRep refers to their location and NOT their payment address.\n\n#### `givenName`\n- Compulsory\n- This is a property inherited from [Person](https://schema.org/Person)\n- It is the only compulsory property\n- A very short freeform text field. Limited to 80 characters.\n- This MUST NOT support markdown text styling.\n- It is intended that authors will use this field for their profile name/ username.\n\n#### `image`\n- Optional\n- This is a property inherited from [Person](https://schema.org/Person)\n- This SHOULD be treated as the profile picture of the individual\n- This MUST contain a fully described [`imageObject`](https://schema.org/ImageObject) property \n \n##### `imageObject`\n- This is to be included in a metadata file as a property of the `image` property, only if the `image` property is included.\n- It explains the image to those (inc. tools) who are viewing it.\n- `imageObject` MUST take one of the following forms:\n  1. base64 encoded image\n  2. URL of image\n\n###### base64 encoded image explained:\n`imageObject` contains a base64 encoded image in its [`contentUrl`](https://github.com/schemaorg/schemaorg/issues/2696) property in a [dataURI](https://en.wikipedia.org/wiki/Data_URI_scheme) format:\n  - i.e. _data:content/type;base64,_ (AND NOT _data:domain.tld_)\n  - e.g. _contentURL:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==_ (AND NOT _contentURL:https://avatars.githubusercontent.com/u/113025685?v=4_)\n\n###### URL of image explained:\nIf the `imageObject` DOES NOT contain a base64 encoded image, the `contentUrl` MUST contain the URL where the image can be found and the `sha256` property MUST be populated with the SHA256 hash of the image file contents found at the `contentUrl`. The SHA256 hash is needed in order for readers to verify that the image has not been altered since the metadata anchor was submitted on-chain.\n\n#### `objectives`\n- Optional\n- A freeform text field with a maximum of 1000 characters\n- A short description of what the person believes and what they want to achieve as a DRep\n\n#### `motivations`\n- Optional\n- A freeform text field with a maximum of 1000 characters\n- A short description of why they want to be a DRep, what personal and professional experiences have they had that have driven them to register \n\n#### `qualifications`\n- Optional\n- A freeform text field with a maximum of 1000 characters \n- A space where the registrant can to list the qualifications they hold that are relevant to their role as a DRep\n- This is distinct from the properties of a Person listed as `knows` and `knowsAbout` because it encompasses things that the DRep has done as well as things that they know that qualify them for this position. \n\n#### `references`\n- Optional\n- This CIP extends the `references` property from [CIP-100](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0100#high-level-description)\n- `references` contain the following sub-properties `@type`, `label`, and `uri`\n- This CIP adds two `@type` identifiers \"Identity\" and \"Link\"\n\n##### `@type`: Link\n- Optional\n- It is expected that these links will be the addresses of the social media/ websites associated with the DRep in order to give a person reviewing this information a fulsome overview of the DRep's online presence.\n- The creator of the metadata SHOULD add a `label`, this `label` SHOULD describe the source of the url, e.g. if it is a link to the DRep's X account then the `label` SHOULD say \"X\". If it is the only personal website provided by the DRep the `label` should say \"Personal Website\" rather than domain_name.com.\n- The `label` of each `Link` SHOULD NOT be left blank\n- Each `Link` MUST have exactly one `uri` (as specified in CIP-100) which SHOULD not be blank.\n\n##### `@type`: Identity\n- Optional\n- The `uri` of a reference with the `@type` \"Identity\" is a way for DReps to prove that they are who they say they are\n- It is expected that the \"Identity\" of a DRep will be the addresses of their most active social media account twitter, linkedin etc. or personal website.\n- The DRep must reference their DRep ID in a prominent place at the location that is specified in the `uri` property of that reference. This will be used by people reviewing this DRep to prove and verify that the person described in the metadata is the same as the person who set up the social media profile.\n\n#### `doNotList`\n- Optional\n- Is a boolean expression that can be given a single value of either `true` or `false`.\n- If not included then the value is assumed to be `false`.\n- A `true` value means that the DRep does **not** want to campaign for delegation via tooling.\n- A `false` value means that the DRep does want to campaign for delegation via tooling and thus be shown via that tooling.\n- e.g. a DRep who does not want to appear in GovTool’s DRep Directory feature creates metadata with `doNotList=true`.\n\n### Application\nOnly the `givenName` property is listed above as compulsory, DRep metadata must include it to be considered CIP-119 compliant. As this is an extension to CIP-100, all CIP-100 fields can be included within CIP-119 compliant metadata.\n\n### Test Vector\nSee [test-vector.md](./test-vector.md) for examples.\n\n### Versioning\nThis proposal should not be versioned, to update this standard a new CIP should be proposed. Although through the JSON-LD mechanism further CIPs can add to the common governance metadata vocabulary.\n\n## Rationale: how does this CIP achieve its goals?\nWe intentionally have kept this proposal brief and uncomplicated. This was to reduce the time to develop and deploy this standard. This way we enable tooling which depends on this standard to start development. \n\n### Rationale for insisting on a compulsory name\nThe compulsory nature of this field was controversial because the `givenName`s cannot be made unique and therefore are open to abuse (by e.g. copycats). However this is not a reason to not include a `givenName`, it a reason for people reviewing a DRep's profile to properly check their whole profile before delegating to them. A `givenName` MUST be included because a person must always have a name. Iit is a human readable identifier, it is the property that people reviewing DReps will most likely identify a given DRep by, even in the presence of copycats.\n\n### Rationale for multiple freeform fields\nIt has been suggested that the `objectives`, `motivations`, and `qualifications` properties ([or at least the latter two](https://github.com/cardano-foundation/CIPs/pull/788#discussion_r1546391918)) could be one freeform property instead of 3. The rationale for having 3 separate properties is to provide structure to DReps so that they have a useful set of prompts about what they can and should write about. The author noticed in research that a single `bio` field in a form typically resulted in lower quality, often single line, responses from respondents than when this `bio` field was split into smaller fields with more highly specified purposes.\n\nIt has also been suggested that the format of the input into these three properties could be more tightly specified for example `qualifications` could require a list of qualifications. Whilst this will probably be needed I have left this up to a future CIP to specify what these specifications should be because at this stage (MVP) I have no concrete examples of how people will end up using these fields and I want to leave it up to the community to experiment with this. \n\n### Rationale for the identity solution that is used\nPKI cryptographic solutions were also considered in the place of the current solution however they were generally considered too complex to implement for minimum viable tooling. There were also other issues with cryptographic forms of identification for MVPs:\n1. solutions that involve a public/private key setup still require people verifying the identity of a DRep to know what their authentic public key is.\n2. specifying the use of a verification service such as [Keybase](https://keybase.io/) would lead to centralisation and therefore reliance on a 3rd party for the identity validation of DReps.\n\n### Rationale for extending the schema.org Person property\nThis CIP is not written to specifically cover the metadata created to describe teams of people collaborating to register as a DRep, but it is written to cover the metadata created by individuals to describe themselves in their capacity as a DRep. Therefore DReps are people. \n\nPeople who want to extend the use of the DRep metadata can now do so in a way that allows tooling providers to use off the peg solutions. Furthermore there may be SEO benefits to using schema.org templates. \n\n### Rationale for decisions made regarding `imageObject` and b64 encoding\nAccording to schema.org The `image` property inherited from [Person](https://schema.org/Person) can either be a URL to a separate location where an image is stored, or it can be an `imageObject`. \n\nFor the following reasons it was originally intended that this CIP would specify the use of an `imageObject` with a b64 encoded image only, because:\n1. The data at the location specified by a URL could be subject to change without the hash in the metadata anchor needing to be changed\n2. Choosing just one way to write and read image data would to limit the amount of tooling options that need to be created to cater to those wishing to create DRep metadata. \n\nHowever it was pointed out that this may quickly lead to relatively massive (multi-megabyte) metadata files that are more difficult to fetch and store without providing substantial value. Even IPFS would take a relatively long time to serve these files, and if there was a need to index them by some chain indexer (such as DB-Sync) then this could massively increase the storage space needed to run the indexer. \n\nIt is also the case that CIP-100 allows for metadata to be saved within a governance transaction, and including b64 encoded images directly within transactions would be troublesome due to their size. This would not be an issue with including an image file URL. \n\nTherefore it was decided to allow a provision for people to submit `imageObject`'s with a URL only if a hash was included OR with a base64 encoded image, and allow them to make the decision as to which was most appropriate for their use case.  \n\n#### Rationale for `doNotList`\n\nThis field was intended for DReps who wish to identify themselves via rich metadata but are not seeking to campaign for delegations.\nBy not being listed via \"DRep aggregation/campaign\" tools the idea is that these DReps are less likely to attract unwanted delegation from ada holders.\nThese DReps could be organizations that want to use their ada to vote in a transparent way on-chain but do not wish to vote on the behalf of others.\n\nIt is expected that tooling such as block explorers will list DReps using `doNotList=true`. Tooling built specifically for DRep campaign and delegation should respect the intent of this field. \n\nThis proposal cannot force tooling to respect this desire from DReps. DReps must be aware that any information anchored on-chain can be found via tooling and may result in delegation.\n\n### A Note on Teams\nCIP-1694 allows for DReps to be registered using a native or Plutus script credential, this implies that individuals could organise to form a team that would have a broad range of expertise, and would perhaps therefore be more attractive to some delegating Ada Holders.\n\nParticipants at the workshop held to debut the first draft of this CIP strongly advocated in favour of including features that would assist a DRep comprised of a team of individuals to properly describe their endeavour.\n\nThis CIP has not included these features, the decision not to include these features was made in order to simplify this CIP so that it became suitable for the minimum viable level of tooling, with the expectation that further CIPs will build on it.\n\n### Open Questions\n|QID |Question |Answer |\n|----|---------|-------|\n|1   |Should we accommodate for profile pictures to be included in metadata? | Yes, furthermore, a future CIP may allow for multiple pictures |\n|2   |Do we need to replace the `bio` field with a more structured set of fields? | Yes, adding structure is intended to guide people to add data which is more interesting to the reader |\n|3   |Can we include and verify an ADA handle to uniquely identify a DRep |[This](#type-identity) is how we verify the identity of a DRep |\n|4   |What do we do about lack of metadata integrity | This is up to the tooling provider|\n|5   |Should we split this CIP up into separate transactions or also add the vote transaction metadata |The scope is fine |\n|6   |Compulsory vs optional for all fields |See the relevant section for each property |\n|7   |types of DRep (script? representing an organisation? want delegations?)| This CIP is optimised for individuals who are DReps, but doesnt exclude teams. It is agnostic as o wherther the DRep is registered via a script or not |\n|8   |How can we verify the information that we are displaying(?) |This CIP adopts provisions from CIP-100 about how to display metadata which is in an unexpected format. Otherwise this CIP leaves questions surrounding the display of data to tooling providers. Identity verification is covered in QID 8. |\n|9   |Should tooling providers displaying data warn people that none of the information is verified and they should DYOR? |This is not specified in this CIP |\n|10  |Should tooling providers making metadata provide some information about best practices such as putting DRep ID in twitter bio? |This is not specified in the CIP |\n|11  |What do we care about when someone is retiring? | Retirement transactions no longer include a metadata anchor|\n|12  |When someone updates do we want a 1 line summary of what has changed? |Possibly future CIPs could include this feature |\n|13  |Should tools inform people of recent changes? |This is up to tooling providers |\n|14  |Should there be an incentives address, where DRep incentives are paid? |See [`paymentAddress`](#paymentAddress) |\n|15  |PKI Public Key, Fingerprint, or DID? | See [`type`: Identity](#type-identity) |\n\n## Path to Active\n\n### Acceptance Criteria\n- Publish JSON-LD schemas & test-vector.md\n- Adoption by at least one community tool\n\n### Implementation Plan\n<!-- How I plan to meet the acceptance criteria -->\n\n## Acknowledgements\nThere have been 3 lively public workshops on this subject, and I would like to thank the following people\n\n<details>\n  <summary><strong>Workshop 1 - 07/02/2024</strong></summary>\n\n- Abhik Nag\n- Adam Dean\n- Adam Rusch\n- Digital Fortress (Rick McCracken)\n- Eduardo Silka\n- Jose Miguel De Gamboa\n- Leonardo Silka\n- Lorenzo Bruno\n- Mike Susko\n- Nicolas Cerny\n- Peter Wolcott\n- Ryan Williams\n- Sheldon Hunt\n- Tyler Wales\n- Upstream SPO\n- Valeria Devaux\n- Дима\n\n[A recording of this meeting can be found here](https://vimeo.com/912374177/0e9299fb5d?share=copy)\n</details>\n\n<details>\n  <summary><strong>Workshop 2 - 20/03/2024</strong></summary>\n    \n- Adam Rusch\n- Aleksandar Djuricic (Aleks)\n- Christopher Hockaday\n- Digital Fortress (Rick McCracken)\n- Eduardo Silka\n- HD5000\n- Igor Velickovic\n- Input Endorsers\n- Konstantinos Dermentzis\n- Leonardo Silka\n- Michael Madoff\n- Michał Szałowski\n- Mike Hornan\n- Peter Wolcott\n- Ryan\n- Ryan (Cerkoryn)\n- Ryan Williams\n- Steve Lockhart \n\n[A recording of this meeting can be found here](https://vimeo.com/915297122/c39f4a739b?share=copy)\n</details>\n\n<details>\n  <summary><strong>Australia and APAC Workshop  - 05/03/2024</strong></summary>\n    \n- Andreas,\n- Linh P,\n- Mark Byers,\n- Mike Hornan,\n- Pedro Lucas,\n- Phil Lewis,\n</details>\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). \n"
  },
  {
    "path": "CIP-0119/cip-0119.common.jsonld",
    "content": "{\n    \"@context\": {\n        \"CIP100\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#\",\n        \"CIP119\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0119/README.md#\",\n        \"hashAlgorithm\": \"CIP100:hashAlgorithm\",\n        \"body\": {\n            \"@id\": \"CIP119:body\",\n            \"@context\": {\n                \"references\": {\n                    \"@id\": \"CIP119:references\",\n                    \"@container\": \"@set\",\n                    \"@context\": {\n                        \"GovernanceMetadata\": \"CIP100:GovernanceMetadataReference\",\n                        \"Other\": \"CIP100:OtherReference\",\n                        \"label\": \"CIP100:reference-label\",\n                        \"uri\": \"CIP100:reference-uri\"\n                    }\n                },\n                \"paymentAddress\": \"CIP119:paymentAddress\",\n                \"givenName\": \"CIP119:givenName\",\n                \"image\": {\n                    \"@id\": \"CIP119:image\",\n                    \"@context\": {\n                        \"ImageObject\": \"https://schema.org/ImageObject\"\n                    }\n                },\n                \"objectives\": \"CIP119:objectives\",\n                \"motivations\": \"CIP119:motivations\",\n                \"qualifications\": \"CIP119:qualifications\"\n            }\n        }\n    }\n}\n"
  },
  {
    "path": "CIP-0119/cip-0119.common.schema.json",
    "content": "{\n    \"title\": \"CIP-119 Common\",\n    \"description\": \"Metadata document for Cardano DReps, extending CIP-100\",\n    \"type\": \"object\",\n    \"required\": [\"hashAlgorithm\", \"body\"],\n    \"properties\": {\n        \"hashAlgorithm\": {\n            \"$ref\": \"#/definitions/hashAlgorithm\"\n        },\n        \"body\": {\n            \"$ref\": \"#/definitions/body\"\n        }\n    },\n    \"definitions\": {\n        \"hashAlgorithm\": {\n            \"type\": \"string\",\n            \"enum\": [\"blake2b-256\"],\n            \"title\": \"Hash Algorithm\",\n            \"description\": \"The algorithm used to authenticate this document externally (CIP-100)\"\n        },\n        \"body\": {\n            \"title\": \"Body\",\n            \"description\": \"The body of the metadata document (CIP-100)\",\n            \"type\": \"object\",\n            \"required\": [\"givenName\"],\n            \"properties\": {\n                \"paymentAddress\": {\n                    \"type\": \"string\",\n                    \"title\": \"Payment Address\",\n                    \"description\": \"A Cardano Bech32 encoded payment address.\"\n                },\n                \"givenName\": {\n                    \"title\": \"Given Name\",\n                    \"$ref\": \"https://schema.org/givenName\"\n                },\n                \"image\": {\n                    \"title\": \"Image\",\n                    \"$ref\": \"https://schema.org/image\"\n                },\n                \"objectives\": {\n                    \"type\": \"string\",\n                    \"title\": \"Objectives\",\n                    \"description\": \"A short description of what the person believes and what they want to achieve as a DRep, maximum of 1000 characters.\"\n                },\n                \"motivations\": {\n                    \"type\": \"string\",\n                    \"title\": \"Motivations\",\n                    \"description\": \"A short description of why they want to be a DRep, what personal and professional experiences have they had that have driven them to register, maximum 1000.\"\n                },\n                \"qualifications\": {\n                    \"type\": \"string\",\n                    \"title\": \"Qualifications\",\n                    \"description\": \"A space where the registrant can to list the qualifications they hold that are relevant to their role as a DRep, maximum 1000.\"\n                },\n                \"doNotList\": {\n                    \"type\": \"string\",\n                    \"enum\": [\"true\", \"false\"],\n                    \"title\": \"Do Not List\",\n                    \"description\": \"A true or false value means that the DRep does not want to show up in tooling that displays DReps.\"\n                },\n                \"references\": {\n                    \"type\": \"array\",\n                    \"title\": \"References\",\n                    \"items\": {\n                        \"$ref\": \"#/definitions/reference\"\n                    }\n                }\n            }\n        },\n        \"reference\": {\n            \"title\": \"Reference\",\n            \"description\": \"A reference to a document\",\n            \"type\": \"object\",\n            \"required\": [\"@type\", \"label\", \"uri\"],\n            \"properties\": {\n                \"@type\": {\n                    \"type\": \"string\",\n                    \"enum\": [\"GovernanceMetadata\", \"Other\", \"Link\", \"Identity\"],\n                    \"title\": \"Type\"\n                },\n                \"label\": {\n                    \"type\": \"string\",\n                    \"title\": \"Label\"\n                },\n                \"uri\": {\n                    \"type\": \"string\",\n                    \"title\": \"URI\"\n                }\n            }\n        }\n    }\n}\n"
  },
  {
    "path": "CIP-0119/examples/drep.jsonld",
    "content": "{\n    \"@context\": {\n        \"CIP100\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#\",\n        \"CIP119\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0119/README.md#\",\n        \"hashAlgorithm\": \"CIP100:hashAlgorithm\",\n        \"body\": {\n            \"@id\": \"CIP119:body\",\n            \"@context\": {\n                \"references\": {\n                    \"@id\": \"CIP119:references\",\n                    \"@container\": \"@set\",\n                    \"@context\": {\n                        \"GovernanceMetadata\": \"CIP100:GovernanceMetadataReference\",\n                        \"Other\": \"CIP100:OtherReference\",\n                        \"label\": \"CIP100:reference-label\",\n                        \"uri\": \"CIP100:reference-uri\"\n                    }\n                },\n                \"paymentAddress\": \"CIP119:paymentAddress\",\n                \"givenName\": \"CIP119:givenName\",\n                \"image\": {\n                    \"@id\": \"CIP119:image\",\n                    \"@context\": {\n                        \"ImageObject\": \"https://schema.org/ImageObject\"\n                    }\n                },\n                \"objectives\": \"CIP119:objectives\",\n                \"motivations\": \"CIP119:motivations\",\n                \"qualifications\": \"CIP119:qualifications\"\n            }\n        }\n    },\n    \"hashAlgorithm\": \"blake2b-256\",\n    \"body\": {\n        \"paymentAddress\": \"addr1q86dnpkva4mm859c8ur7tjxn57zgsu6vg8pdetkdve3fsacnq7twy06u2ev5759vutpjgzfryx0ud8hzedhzerava35qwh3x34\",\n        \"givenName\": \"Ryan Williams\",\n        \"image\": {\n            \"@type\": \"ImageObject\",\n            \"contentUrl\": \"https://avatars.githubusercontent.com/u/44342099?v=4\",\n            \"sha256\": \"2a21e4f7b20c8c72f573707b068fb8fc6d8c64d5035c4e18ecae287947fe2b2e\"\n        },\n        \"objectives\": \"Buy myself an island.\",\n        \"motivations\": \"I really would like to own an island.\",\n        \"qualifications\": \"I have my 100m swimming badge, so I would be qualified to be able to swim around island.\",\n        \"references\": [\n          {\n            \"@type\": \"Other\",\n            \"label\": \"A cool island for Ryan\",\n            \"uri\": \"https://www.google.com/maps/place/World's+only+5th+order+recursive+island/@62.6511465,-97.7946829,15.75z/data=!4m14!1m7!3m6!1s0x5216a167810cee39:0x11431abdfe4c7421!2sWorld's+only+5th+order+recursive+island!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n!3m5!1s0x5216a167810cee39:0x11431abdfe4c7421!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n?authuser=0&entry=ttu\"\n          },\n          {\n            \"@type\": \"Link\",\n            \"label\": \"Ryan's Twitter\",\n            \"uri\": \"https://twitter.com/Ryun1_\"\n          }\n        ]\n    }\n}\n"
  },
  {
    "path": "CIP-0119/test-vector.md",
    "content": "# Test Vector for CIP-0119\n\nHere we give some supporting files, give an example and explain how the [drep.jsonld](./examples/drep.jsonld) was created.\n\n## Common Context\n\n### Common Fields\n\nThe context fields which could be added to CIP-119 compliant jsonld metadata.\nSee [cip-0119.common.jsonld](./cip-0119.common.jsonld).\n\n### Common Fields Schema\n\nA json schema for the common context fields.\nSee [cip-0119.common.schema.json](./cip-0119.common.schema.json).\n\n## Example\n\nCIP-119 off-chain metadata json example: [drep.jsonld](./examples/drep.jsonld)\n\nBlake2b-256 hash of content of the file (to go on-chain): `a14a5ad4f36bddc00f92ddb39fd9ac633c0fd43f8bfa57758f9163d10ef916de`\n"
  },
  {
    "path": "CIP-0120/README.md",
    "content": "---\nCIP: 120\nTitle: Constitution specification\nCategory: Metadata\nStatus: Proposed\nAuthors:\n    - Ryan Williams <ryan.williams@intersectmbo.org>\n    - Danielle Stanko <danielle.stanko@iohk.io>\nImplementors: \n    - Danielle Stanko <danielle.stanko@iohk.io>\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/796\nCreated: 2024-03-19\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nCardano's minimum viable governance model as described within\n[CIP-1694 | A First Step Towards On-Chain Decentralized Governance](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md)\nintroduces the concept of a Cardano constitution.\nAlthough CIP-1694 gives no definition to the constitution's content or form.\n\nThis proposal aims to describe a standardized technical form for the Cardano\nConstitution to enhance the accessibility and safety of the document.\n\n> **Note:** This proposal only covers the technical form of the constitution,\n> this standard is agnostic to the content of the constitution.\n\n## Motivation: why is this CIP necessary?\n\nCIP-1694 defines the on-chain anchor mechanism used to link the off-chain\nConstitution document to on-chain actions.\nThis mechanism was chosen due to its simplicity and cost effectiveness,\nmoving the potentially large Cardano constitution off-chain,\nleaving only a hash digest and URI on-chain.\nThis is the extent to which CIP-1694 outlines the Cardano Constitution:\nCIP-1694 does not provide suggestions around hashing algorithm,\noff-chain storage best practices or use of rich text styling.\n\nBy formalizing the form of the constitution and its iterations,\nwe aim to promote its longevity and accessibility.\nThis is essential to ensure the effectiveness of the CIP-1694 governance model.\n\nThis standard will impact how Ada holders read the Constitution but\nthe main stakeholders for this are the tool makers who wish to read,\nrender and write a constitution.\n\n### Safety\n\nWithout describing best practices for the form and handling of the constitution,\n we risk the constitution document being stored in an insecure manner.\nBy storing the constitution on a decentralized platform,\nwe can ensure its immutability and permissionless access.\nThis is a step to improve the longevity and accessibility of each constitution\niteration.\n\n### Interoperability\n\nBy defining a file extension and formatting rules for the constitution we\nensure that tooling reading and writing the constitution will be interoperable.\nFurthermore we aim to make the role of constitution iteration comparison tools\neasier, by minimizing formatting and style changes between iterations.\nThis will reduce compatibility issues between tools,\npromoting the accessibility of the constitution.\n\n### Usability\n\nRich text formatting greatly enhances the readability of text,\nespecially in large complex documents.\nWithout the ability to format text, it could easily become cumbersome to read,\nnegatively effecting the accessability of the Cardano constitution.\n\n## Specification\n\nThe following specification SHOULD be applied to all constitution iterations.\nThis standard could be augmented in the future via a separate CIP which aims to\nreplace this one.\n\n### Terminology\n\n#### Capitalisation of key terms\n\nTo avoid unnecessary edits, and therefore checksum changes,\nconstitution authors MUST follow the following standard English capitalisation\nrules unless a translation language indicates otherwise:\n\n##### `Constitution` vs. `constitution`\n\n- The Constitution in effect — either the \"initial\" one or any new constitution — is unique and therefore capitalised (\"Constitution\") as a proper noun.\n- Draft or proposed constitutions are not unique & therefore are not capitalised (\"constitution\") as a common noun.\n- \"Cardano Constitution\" is a very specific proper noun phrase (also a title) and so each word is capitalised.\n- The phrase \"the Constitution\", unless used non-specifically (e.g. \"the constitution that voters prefer\"), would generally be assumed to be _the_ Constitution and capitalised as a proper noun.\n\n##### `Ada` vs. `ada` vs. `ADA`\n\n- `Ada` is the currency, while `ada` indicates units of that currency (e.g. \"Ada holders can accumulate more ada to increase their influence.\")\n- `ADA` is the trading symbol (e.g. \"Fluctuations in ADA might influence decisions about the Treasury.\")\n\n### Characters\n\nThe constitution text MUST only contain printable text characters in UTF-8\nencoding.\n\n### Lines\n\nEach line in the constitution text MUST contain at maximum 80 characters,\nincluding spaces and punctuation.\n\nWhile 80 characters is a limit, authors don't have to try and always hit 80.\nLegibility of the raw (unrendered) document SHOULD be kept in mind.\n\n#### Sentences\n\nThe constitution text MUST only contain a maximum of one sentence per line,\nwith each sentence followed by a newline.\nEach new sentence SHOULD start on its own line with a capitalized letter.\n\nLong sentences can be split multiple lines,\nwhen writing the author SHOULD try to split long sentences along natural breaks.\n\nExample:\n\n```md\nThis is a short sentence on one line.\n\nThis is a long sentence and I have valid reasons for it being so long,\nsuch as being an example of a long sentence.\nWhen this sentence is rendered it SHOULD be shown to directly follow the \nsentence above.\n\nThis sentence is the start of a new paragraph.\n```\n\nWhen rendered,\nthese newlines between sentences SHOULD NOT be shown as newlines.\nInstead they SHOULD be rendered as a space character between sentences.\n\nParagraphs are shown by leaving a blank line between text.\n\n### File\n\nConstitution files MUST be `.txt` files.\n\nConstitution files SHOULD be named in sequential whole numbers.\nFollowing the pattern `cardano-constitution-{i}.txt`\nwhere `{i}` is the iteration number.\n\nStarting from an interim constitution named `cardano-constitution-0.txt`,\nthe next constitution SHOULD be named `cardano-constitution-1.txt`.\n\nTo prevent misalignment, constitutions governing networks other than Cardano's\nmainnet, CAN be prefixed with the network name.\nFor example, on the preview network the constitution file COULD be named\n`preview-cardano-constitution-0.txt`.\n\n### Hashing\n\nWhen supplying a constitution hash digest to chain, the algorithm used MUST be\nBlake2b-256.\nBefore creating a hash digest the constitution plain text MUST be in its raw\ntext, including any [Rich Text Formatting](#rich-text-formatting)\nrelated characters.\n\n### Storage\n\nThe each ratified constitution MUST be stored,\nimmutably on a distributed storage mechanism where backups can be easily made\nin a permissionless manner by interested parties.\nThis storage platform SHOULD be easily accessible, with strong tooling support.\n\nWhen generating a URI for the document, authors SHOULD NOT include centralized\ngateways.\n\nWe propose using the\n[InterPlanetary File System (IPFS)](https://www-ipfs-tech.ipns.dweb.link/).\n\n### Rich Text Formatting\n\nThe constitution text MAY include a strict subset of rich text styling as\ndefined in this specification.\nTooling rendering the constitution SHOULD recognize these and render them\nfaithfully.\n\n#### Line Breaks / Paragraphs\n\nTo create paragraphs, use a blank line to separate one or more lines of text.\n\nExamples:\n\n```md\nHere's a line for us to start with.\n\nThis line is separated from the one above by two newlines,\nso it will be a *separate paragraph*.\n\nThis line is also a separate paragraph, but...\nThis line is only separated by a single newline,\nso it's a separate line in the *same paragraph*.\n```\n\n#### Headers\n\nHeaders are denoted via a hashtag character `#` followed by a space ` `.\nThere are six levels of headers, with each lower level set via an added `#`.\nHeaders are ended via a line break.\nHeaders SHOULD be followed below by a blank line.\nHeaders SHOULD not be preceded by whitespace.\n\nThe lower the number of `#` the larger order the text SHOULD be rendered.\n\nExample:\n\n```md\n# H1\n\n## H2\n\nSome non-heading text.\n\n### H3\n\n#### H4\n\n##### H5\n\n###### H6\n\n```\n\nIf text is in a header no other formatting can be applied.\n\nAn empty line SHOULD be left above and below each heading\n\n#### Emphasis\n\nEmphasis is applied to text between single or double asterisks,\nwithout space between asterisks and text.\nItalicized emphasis is shown via single asterisk (`*`).\nBold emphasis is shown via double asterisks (`**`).\n\nEmphasis cannot span multiple lines.\n\nExamples:\n\n```md\nEmphasis, aka italics, with single *asterisks*.\n\nStrong emphasis, aka bold, with double **asterisks**.\n```\n\nBoth italicized and bold cannot be applied to the same text.\n\n#### Code and Syntax Highlighting\n\nTexted can be highlighted as code, when encased without spaces by backticks.\nThis MUST not contain line breaks.\n\nExample:\n\n```md\nInline `code` has `back-ticks around` it.\n```\n\nThe text contained within headings or emphasis cannot be highlighted as code.\n\n#### Ordered Lists\n\nTo create an ordered list,\nadd line items with numbers followed by one period and then one space.\nEach line item is separated by an empty line.\nThe numbers MUST be in numerical order,\nbut the list SHOULD start with the number one.\n\nOrdered lists MUST NOT have indented items.\nOrdered lists MUST NOT include headings.\n\n```md\n1. This is the first item in my ordered list\n\n2. this is the second item in my list\n\n3. the third item\n```\n\n#### Unordered Lists\n\nTo create an unordered list, add dashes (`-`) and one space,\nin front of line items.\nEach line item is separated by an empty line.\n\nUnordered lists MUST NOT have indented items.\nUnordered lists MUST NOT start with a number followed by a period.\n\n```md\n- this is my list\n\n- I like unordered lists\n```\n\nUnordered lists MUST NOT include headings.\n\n### Best Practices\n\n#### Rendering\n\nWhen rendering the raw document tooling COULD use standard markdown rendering\ntools.\n\n#### Hashing\n\nWhen submitting an update constitution governance action,\ntooling SHOULD verify the document hash digest and matches the document.\n\nTooling reading constitution anchors from chain SHOULD always perform a\ncorrectness check using the hash digest on-chain.\nIf the hash provided on-chain does not match the hash produced from\nthe off-chain document, then the tooling SHOULD highlight this in a\nvery obvious way to users.\n\n#### Conformance\n\nTools writing constitutions SHOULD strive to follow this specification.\nIf tooling discovering and rendering constitution documents discovers that\nthe document does not follow the \"MUST\"s in this specification then a small\nwarning SHOULD be given to users.\n\n#### Form\n\nAuthors SHOULD aim to keep the document as clean and consistent as possible.\n\nText SHOULD try to be left aligned, without using unneeded whitespace leading\nor trailing lines.\n\nSpaces SHOULD be used over tab characters.\n\nThe last line in the document SHOULD be empty.\n\n### Test vectors\n\nSee [Test vector file](./test-vector.md).\n\n## Rationale: how does this CIP achieve its goals?\n\n### Line length\n\nWe choose to restrict the maximum number of characters per line in aims of\nimproving readability of the document in plain text and within diff views.\n\nIt SHOULD also be considered that the 80-character limit also helps one find\nrun-on sentences.\nIf your sentence is much longer than 80, it might need breaking down.\nAnd you SHOULD never want to see a sentence that's over two\nlines long in normal text.\n\n### Sentences\n\nBy limiting documents to one sentence per line we hope to improve the\nexperience when comparing documents and commenting on specific sentences.\nConventional document comparison tools such as git diff views, compare\ndocuments on a by line basis.\nBy spreading text across lines,\nit greatly improves tooling's ability to differentiate between documents.\n\nFurthermore, isolating one sentence per line, allows users to more easily\nisolate specific lines to comment upon.\nThis gives each sentence an unambiguous reference point,\nwhich can be very useful for sharing and discussing.\n\n### Versioning\n\nWe chose to only allow replacement of this document rather than including a\nmore conventional versioning scheme.\nThis was done for simplicity to minimize the amount of effort required to\ncreate tooling which reads and writes constitutions.\n\nThe alternative was to add some details of version to the constitution document.\nThis would make changing hashing algorithm, rich text formatting, etc.\nmuch easier.\nBut this makes the standard and subsequent, more complex than necessary.\nWe do not believe the added complexity is justified,\nfor the expected number of future replacement CIPs to this one.\n\n### File\n\nThe text file was chosen, due to its ubiquity across platforms.\nBy choosing a common format,\nwe improve the accessibility of the raw document.\n\nWe choose to add sequential numbering to constitution document iterations to\nimprove differentiation between documents.\n\n### Hashing\n\nBlake2b-256 was chosen for its common use across the Cardano ecosystem.\nThis means that a lot of Cardano tooling already has this algorithm implemented.\nThis lowers the bar to entry for existing tool makers to add\nconstitutional support.\n\nFor simplicity, we decide not to include an easy mechanism for changing of\nhashing algorithms between constitutions.\n\n### Storage\n\nEnsuring the Cardano Constitution and its iterations can be accessed in a\npermissionless manor is paramount.\nPermissionless networks such as IPFS reduce the ability for parties to\ncensor the content.\nWith each interested party able to make copies of constitutions,\nthis improves the resilience of the documents from deletion.\n\nThe primary competing idea to platforms such as IPFS is to store the\nconstitution text on Cardano itself.\nThis would philosophically be superior to storing the document off-chain,\nkeeping the Cardano Constitution on Cardano.\nThe counter point to this is that,\nCardano is not a general data storage system, rather it is a ledger.\nStoring data on Cardano is expensive and difficult, without strong tooling\nsupport.\n\n### Rich Text Formatting\n\nRich text styling will greatly improve the readability of the\nconstitution documents, when rendered.\n\n#### Markdown\n\nMarkdown styling was chosen due to its ubiquity, with strong tooling support.\nFurthermore, markdown has a benefit in that the unrendered documents are\nstill human readable.\nThis is in contrast to other solutions such as HTML.\n\n#### Strict subset\n\nWe chose a strict subset of markdown text styling for two reasons.\nFirstly, markdown contains a very large and varied syntax,\nreducing the scope making implementation easier for all tooling.\nSecondly, some features of markdown may not want to be used in a formal\nconstitution document.\nEmbedded HTML or videos are likely things to be avoided.\n\n## Open Questions\n\n- [x] How can we support multi-languages?\n  - The Cardano constitution will be in English, but we will add best practice guidelines via [Best Practices](#best-practices).\n- [x] Should we specify any standardization for the proposal policy?\n  - Due to lack of interest in this, we will leave it out of this standard.\n- [x] How can we add page breaks?\n  - We wont, instead we will prioritize a minimum set of rich text formatting. We can provide some guidance via [Best Practices](#best-practices).\n- [x] Do we want a mechanism for specifying authors? (similar to CIP-100)\n  - No, as CIP-100 compliant metadata can be supplied at time of constitution update.\n- [x] What SHOULD we name the constitution file? we could embed some nice naming or metadata.\n  - Naming the file `cardano-constitution` seems specific enough, adding iteration numbers is a nice addition too.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] This standard is followed for the interim Cardano Constitution\n- [ ] This standard is utilized by two tools reading constitution data from chain\n  - [constitution.gov.tools](https://constitution.gov.tools/)\n\n### Implementation Plan\n\n#### Solicitation of feedback\n\n- [x] Answer all [Open Questions](#open-questions)\n- [ ] Review from the Civics Committee\n\n#### Test vector\n\n- [x] Author to provide a test vector file with examples.\n\n## Acknowledgements\n\n<details>\n  <summary><strong>First draft</strong></summary>\n  \n  We would like to thank those who reviewed the first draft of this proposal;\n  - Danielle Stanko\n  - Kevin Hammond\n  - Steven Johnson\n\n</details>\n\n<details>\n  <summary><strong>Significant Contributions</strong></summary>\n  \n  We would like to thank Robert Phair ([@rphair](https://github.com/rphair)) for\n  his expert contributions to this proposal.\n\n</details>\n\n## Copyright\n\nThis CIP is licensed under\n[CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0120/examples/malicious-consitution/cardano-constitution-5.txt",
    "content": "# Malicious Constitution\n\nThis document is brought to you by Cardano-more.\nWe wish to see the end of Cardano, so there is no-more Cardano (get it?).\n\n## Aims\n\nReduce the `maxBlockSize` protocol parameter to a value of `1`.\n\nRemove all funds from the treasury.\n\nIncrease the `lovelacePerUTxOWord` to a value of `1000000`.\n\n## Angry face\n\n**>:(**\n"
  },
  {
    "path": "CIP-0120/examples/ryan-consitution/cardano-constitution-0.txt",
    "content": "# Ryan's Constitution\n\n## Preamble\n\nThis is **Ryan's constitution!**\nThis document aims to improve the likelihood of Ryan being able to buy an \nisland.\n\n## Principles\n\n### 1. Governance Actions\n\nAll governance actions should seek to improve the state of the system for the \nbenefit of Ryan.\n\n### 2. Treasury Withdrawals\n\nAll treasury withdrawal actions must go into a wallet that Ryan controls.\n\n## 3. Protocol Parameter Changes\n\nProtocol parameter changes should seek to raise transaction fees and to \nincrease the amount of money that is paid into the treasury.\n\n## Appendix\n\n### Islands Ryan would like to buy\n\nThis is an ordered list of islands that Ryan would like to buy.\n\n1. Australia\n\n### Ryan's favorite plants\n\nThis is a list of Ryan's favorite plants:\n\n- Monstera deliciosa\n- Anthurium veitchii\n- Monstera esqueleto\n- Strawberry\n"
  },
  {
    "path": "CIP-0120/test-vector.md",
    "content": "# Test Vector for CIP-0120\n\nHere we provide some useful examples.\n\nExample hash digests produced using [Toolkit Bay BLAKE2b-256 tool](https://toolkitbay.com/tkb/tool/BLAKE2b_256).\n\n## Examples\n\n### Ryan's Constitution\n\nThis is a fun example for a first constitution from Ryan.\n\nFile: [ryan-constitution](./examples/ryan-consitution/cardano-constitution-0.txt)\n\nHosted at (to go onchain): `ipfs://bafkreida43nd62yu4vl6czo7hcc7wecxgjdsnphzlg2i6daii5q4ai6npi`\n\nBlake2b-256 hash digest (to go onchain): `55b35f81de519b320da15a4f1faf6b9cfe0cf18cf6daa320224ebb1a924d2986`\n\nExample rendered: [ryan-rendered.png](./examples/ryan-consitution/ryan-rendered.png)\n\nHosted document via a IPFS https gateway: https://bafkreiggjdt7kxsohnewkcligixppzkccmsqv4lljpy7d65djtfaxqkzxm.ipfs.w3s.link\n\n### Malicious Constitution\n\nThis is an example 5th generational constitution, which is malicious.\n\nFile: [malicious-constitution](./examples/malicious-consitution/cardano-constitution-5.txt)\n\nHosted at (to go onchain): `ipfs://bafkreiggjdt7kxsohnewkcligixppzkccmsqv4lljpy7d65djtfaxqkzxm`\n\nBlake2b-256 hash digest (to go onchain): `6a246e447f0e03a065666394121696ee5fb61a6289dc20029279622ee2d2622d`\n\nExample rendered: [malicious-rendered.png](./examples/malicious-consitution/malicious-rendered.png)\n\nHosted document via a IPFS https gateway: https://bafkreida43nd62yu4vl6czo7hcc7wecxgjdsnphzlg2i6daii5q4ai6npi.ipfs.dweb.link/"
  },
  {
    "path": "CIP-0121/README.md",
    "content": "---\nCIP: 121\nTitle: Integer-ByteString conversions\nCategory: Plutus\nStatus: Active\nAuthors:\n    - Koz Ross <koz@mlabs.city>\n    - Ilia Rodionov <ilia@mlabs.city>\n    - Jeff Cheah <jeff@mlabs.city>\nImplementors:\n    - Koz Ross <koz@mlabs.city>\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/624\nCreated: 2023-11-17\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nPlutus Core primitive operations to convert `BuiltinInteger` to\n`BuiltinByteString`, and vice-versa. Furthermore, the `BuiltinInteger`\nconversion allows different endianness for the encoding (most-significant-first\nand most-significant-last), as well as padding with zeroes based on a requested\nlength if required.\n\n## Motivation: why is this CIP necessary?\n\nPlutus Core creates a strong abstraction boundary between the concepts of\n'number' (represented by `BuiltinInteger`) and 'blob of bytes' (represented by\n`BuiltinByteString`), defining different sets of (largely non-overlapping)\noperations for each. This is, in principle, a good practice, as these concepts\nare distinct in (most of) the operations that make sense on them. However,\nsometimes, being able to 'move between' these two 'worlds' is important: namely,\nthe ability to represent a given `BuiltinInteger` as a `BuiltinByteString`, as\nwell as to convert between this representation and the `BuiltinInteger` it\nrepresents. Currently, no such capability exists: while [CIP-0058][cip-0058]\nproposed such a capability (among others), to date, this has not been\nimplemented into Plutus Core.\n\nTo see why such a capability would be beneficial, we give two motivating use\ncases.\n\n### Case 1: signing bids\n\nConsider the following code snippet:\n\n```haskell\nvalidBidTerms :: AuctionTerms -> CurrencySymbol -> BidTerms -> Bool\nvalidBidTerms AuctionTerms {..} auctionID BidTerms {..}\n  | BidderInfo {..} <- bt'Bidder =\n  validBidderInfo bt'Bidder &&\n  -- The bidder pubkey hash corresponds to the bidder verification key.\n  verifyEd25519Signature at'SellerVK\n    (sellerSignatureMessage auctionID bi'BidderVK)\n    bt'SellerSignature &&\n  -- The seller authorized the bidder to participate\n  verifyEd25519Signature bi'BidderVK\n    (bidderSignatureMessage auctionID bt'BidPrice bi'bidderPKH)\n    bt'BidderSignature\n  -- The bidder authorized the bid\n\nbidderSignatureMessage\n  :: CurrencySymbol\n  -> Integer\n  -> PubKeyHash\n  -> BuiltinByteString\nbidderSignatureMessage auctionID bidPrice bidderPKH =\n  toByteString auctionID <>\n  toByteString bidPrice <>\n  toByteString bidderPKH\n\nsellerSignatureMessage\n  :: CurrencySymbol\n  -> BuiltinByteString\n  -> BuiltinByteString\nsellerSignatureMessage auctionID bidderVK =\n  toByteString auctionID <>\n  bidderVK\n```\n\nHere, we attempt to verify (using the Curve25519) that a bid at an auction was\nsigned by a particular bidder. The message to verify must include the bid\nplaced, represented using `Integer` here (which translates to `BuiltinInteger`\nonchain). However, the `verifyEd25519Signature` primitive can only accept\n`BuiltinByteString`s as messages to verify. Thus, we have a problem: how to\ninclude the placed bid into the bid message to be verified?\n\nMore generally, constructing messages to sign usually consists of \nconcatenating together some primitives represented as `BuiltinByteString`s. \nWe currently have a way to do this for (some) strings using `encodeUtf8`, \nbut no way to do this for `BuiltinInteger`s.\n\n### Case 2: finite fields\n\n[Finite fields][finite-field], also known as Galois fields, are a common\nalgebraic structure in cryptographic constructions. Many, if not most, common\nconstructions in cryptography use finite fields as their basis, including\n[Curve25519][curve-25519], [Curve448][curve-448] and the [Pasta\ncurves][pasta-curves], to name but a few. Elements in a finite field are\nnaturally representable as `BuiltinInteger`s of bounded size onchain, but for\napplications like the constructions specified above (and indeed, anything built\natop such constructions), we need to be able to perform the following tasks\nefficiently:\n\n* Verify that a particular value belongs to the field; and\n* Perform bitwise (that is, non-numerical) operations on such values, possibly\n  together with numerical ones.\n\nFurthermore, Case 2 presents two further challenges: _endianness_ and\n_padding_. Due to many cryptographic algorithms being designed for use over the\nnetwork, their specifications assume a big-endian byte ordering in their\nimplementations. Likewise, due to the finiteness of a finite field's elements,\nthey can be encoded in a fixed-length form, which implementations make use of, \nboth for convenience and efficiency.\n\n[cip-0058]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0058\n[finite-field]: https://en.wikipedia.org/wiki/Finite_field\n[curve-25519]: https://en.wikipedia.org/wiki/Curve25519\n[curve-448]: https://en.wikipedia.org/wiki/Curve448\n[pasta-curves]: https://electriccoin.co/blog/the-pasta-curves-for-halo-2-and-beyond/\n\n--- \n\nWhile it is not outright impossible to perform conversions from `BuiltinInteger`\nto `BuiltinByteString` currently, it is unreasonably difficult and\nresource-intensive: `BuiltinInteger` to `BuiltinByteString` involves a repeated\ncombination of division-with-remainder in a loop, while `BuiltinByteString` to\n`BuiltinInteger` involves repeated multiplications by large constants and\naccumulations. Aside from these both requiring looping (with the overheads this\nimposes), both of these are effectively quadratic operations with current\nprimitives: the only means we have to accumulate `BuiltinByteString`s is by\nconsing or appending (which are both quadratic due to `BuiltinByteString` being\na counted array), and any `BuiltinInteger` operation is linear in the size of\nits arguments. This makes even Case 1 far more effort, both for the developer and\nthe node, than it should be, and Case 2 ranges from difficult to impossible once\nwe factor in the limited available primitive operations and the endianness and\npadding problems.\n\nWe propose that two primitives be added to Plutus Core: one for converting\n`BuiltinInteger`s to `BuiltinByteString`s, the other for converting\n`BuiltinByteString`s to `BuiltinInteger`s. The first of these primitives would\nallow for specifying an endianness for the result, as well as to perform padding\nto a required length if necessary; the second primitive is able to operate on\npadded or unpadded encodings, in either endianness.\n\nAdditionally, we state the following goals that any implementation of such\nprimitives must have.\n\n### No metadata\n\nThe representation produced by the `BuiltinInteger` to `BuiltinByteString`\nconversion should be 'minimal', representing only the number being given to it,\nand no other information besides. It would be tempting to, for example, encode\nthe endianness requested into the `BuiltinByteString`, but ultimately, this\ninformation could be added later by users if they want it, while removing it\nwould be trickier. Additionally, metadata-related concerns would complicate both\nthe specification and implementation of the primitives, for arguably marginal\nbenefit.\n\n### Internals-independence\n\nUsers of these primitives should not need to know how _exactly_\n`BuiltinInteger`s are represented to use them successfully. This is beneficial\nto both users (as they now don't have to concern themselves with\nplatform-specific implementation issues) and Plutus Core maintainers (as changes\nin the representation of `BuiltinInteger` aren't going to affect these\nprimitives).\n\n### No support for negative numbers\n\nWhile for fixed-size numbers, [two's-complement][twos-complement] is the default\nchoice for negative number representations, for arbitrary-size numbers, there is\nno agreed-upon choice. Furthermore, indicating the 'negativity' of a number\nwould require making representations larger or more complex regardless of which\nrepresentation we chose, while also complicating both the primitives we want to\ndefine, and any user-defined operations on such representations, possibly in\nways that users do not want. Lastly, for our cases, negative values are not\nreally needed, and if the ability to encode negative numbers was necessary,\nusers could still define whichever one(s) they needed themselves, with little\neffort or computational cost.\n\n[twos-complement]: https://en.wikipedia.org/wiki/Two%27s_complement\n\n---\n\nThis CIP partially supercedes [CIP-0058][cip-0058]: specifically, the\nspecifications here replace the `integerToByteString` and `byteStringToInteger`\nprimitives specified in CIP-0058, as improved, and more general, solutions.\n\n## Specification\n\nWe describe the specification of two Plutus Core primitives, which will have the\nfollowing signatures:\n\n* `builtinIntegerToByteString :: BuiltinBool -> BuiltinInteger -> BuiltinInteger\n  -> BuiltinByteString`\n* `builtinByteStringToInteger :: BuiltinBool -> BuiltinByteString ->\n  BuiltinInteger`\n\nTo describe the semantics of these primitives, we first specify how we represent\na `BuiltinInteger` as a `BuiltinByteString`; after that, we describe the two\nprimitives, as well as giving some properties they must follow.\n\n### Representation\n\nOur `BuiltinByteString` representations of non-negative `BuiltinInteger`s treat\nthe `BuiltinInteger` being represented as a sequence of digits in base-256.\nThus, any byte in the `BuiltinByteString` representation corresponds to a single\nbase-256 digit, whose digit value is equal to its value as an 8-bit unsigned\ninteger. For example, the byte `0x80` would have digit value 128, while the byte\n`0x03` would have digit value 3.\n\nTo determine place value, we define two possible arrangements of digits in such\na representation: _most-significant-first_, and _most-significant-last_. In the\nmost-significant-first representation, the first digit (that is, the byte at\nindex 0) has the highest place value; in the most-significant-last\nrepresentation, the first digit instead has the _lowest_ place value. These\ncorrespond to the notions of [big-endian and little-endian][endianness]\nrespectively.\n\nFor any positive `BuiltinInteger` `i`, let \n\n$$i_0 \\times 256^0 + i_1 \\times 256^1 + \\ldots + i_k \\times 256^k$$\n\nbe its [base-256 form][base-256-form]. Then, for the most-significant-first\nrepresentation, the `BuiltinByteString` encoding for `i` is the\n`BuiltinByteString` `b` such that $\\texttt{indexByteString bs j} = i_{k - j}$. For\nthe most-significant-last encoding, we instead have \n$\\texttt{indexByteString bs j} = i_j$.\n\n[base-256-form]: https://en.wikipedia.org/wiki/Numeral_system#Positional_systems_in_detail\n\nFor example, consider the number `123_456`. Its base-256 form is \n\n```\n64 * 256 ^ 0 + 226 * 256 ^ 1 + 1 * 256 ^ 2\n```\n\nTherefore, its most-significant-first representation would be\n\n```\n[ 0x01, 0xE2, 0x40 ]\n```\n\nwhile its most-significant-last representation would be\n\n```\n[ 0x40, 0xE2, 0x01 ]\n```\n\nFor `0`, in line with the above definition, both its most-significant-first and\nmost-significant-last representation is `[]` (that is, the empty\n`BuiltinByteString`).\n\nTo represent any given non-negative `BuiltinInteger` `i` as above, we require \na minimum number of base-256 digits. For positive `i`, this is \n$\\max \\\\{1, \\lceil \\log_{256}(\\texttt{i}) \\rceil \\\\}$; for `i = 0`, we define this to be\n$0$. We can choose to represent `i` with more digits than this minimum, by the\nuse of _padding_. Let $k$ be the minimum number of digits to represent `i`, and\nlet $j$ be a positive number: to represent `i` using $k + j$ digits in the\nmost-significant-first encoding, we set the first $j$ bytes of the encoding as\n`0x0`; for the most-significant-last encoding, we set the _last_ $j$ bytes of\nthe encoding as `0x0` instead.\n\n[endianness]: https://en.wikipedia.org/wiki/Endianness\n\nTo extend our previous example, a five-digit, most-significant-first \nrepresentation of `123_456` is\n\n```\n[ 0x00, 0x00, 0x01, 0xC2, 0x80 ]\n```\n\nwhile the most-significant-last representation would be\n\n```\n[ 0x80, 0xC2, 0x01, 0x00, 0x00 ]\n```\n\nWe observe that these extra digits do not change what exact `BuiltinInteger` is\nrepresented, as any zero digit has zero place value.\n\n### `builtinIntegerToByteString`\n\nWe can now describe the semantics of the `builtinIntegerToByteString` \nprimitive. The `builtinIntegerToByteString` function takes three arguments; we\nspecify (and name) them below:\n\n1. Whether the most-significant-first encoding should be used. This is the\n   _endianness argument_, which has type `BuiltinBool`.\n2. The number of bytes required in the output (if such a requirement exists).\n   This is the _length argument_, which has type `BuiltinInteger`.\n3. The `BuiltinInteger` to convert. This is the _input_.\n\nIf the input is negative, `builtinIntegerToByteString` fails. In this case, the\nresulting error message must specify _at least_ the following information:\n\n* That `builtinIntegerToByteString` failed due to a negative conversion attempt;\n  and\n* What negative `BuiltinInteger` was passed as the input.\n\nIf the length argument is outside the closed interval $(0, 2^{29} - 1)$,\n`builtinIntegerToByteString` fails. In this case, the resulting error message\nmust specify _at least_ the following information:\n\n* That `builtinIntegerToByteString` failed due to an invalid length argument;\n  and\n* What `BuiltinInteger` was passed as the length argument.\n\nIf the input is `0`, `builtinIntegerToByteString` returns the\n`BuiltinByteString` consisting of a number of zero bytes equal to the length\nargument.\n\nIf the input is positive, and the length argument is also positive, let `d` be\nthe minimum number of digits required to represent the input (as per the\nrepresentation described above). If `d` is greater than the length argument,\n`builtinIntegerToByteString` fails. In this case, the resulting error message\nmust specify _at least_ the following information: \n\n* That `builtinIntegerToByteString` failed due to the requested length being\n  insufficient for the input;\n* What `BuiltinInteger` was passed as the length argument; and\n* What `BuiltinInteger` was passed as the input.\n\nIf `d` is equal to, or greater, than the length argument,\n`builtinIntegerToByteString` returns the `BuiltinByteString` encoding the input.\nThis will be the most-significant-first encoding if the endianness argument is\n`True`, or the most-significant-last encoding if the endianness argument is\n`False`. The resulting `BuiltinByteString` will be padded to the length\nspecified by the padding argument if necessary. \n\nIf the input is positive, and the length argument is zero,\n`builtinIntegerToByteString` returns the `BuiltinByteString` encoding the input.\nIts length will be minimal (that is, no padding will be done). If the endianness\nargument is `True`, the result will use the most-significant-first encoding, and\nif the endianness argument is `False`, the result will use the\nmost-significant-last encoding.\n\nWe give some examples of the intended behaviour of `builtinIntegerToByteString`\nbelow:\n\n```haskell\n -- fails due to negative input\nbuiltinIntegerToByteString False 0 (-1) -- => ERROR\n-- endianness argument doesn't affect this case\nbuiltinIntegerToByteString True 0 (-1) -- => ERROR\n-- length argument doesn't affect this case\nbuiltinIntegerToByteString False 100 (-1) -- => ERROR\n-- zero case, no padding\nbuiltinIntegerToByteString False 0 0 -- => []\n-- endianness argument doesn't affect this case\nbuiltinIntegerToByteString True 0 0 -- => []\n-- length argument adds more zeroes, but endianness doesn't matter\nbuiltinIntegerToByteString False 5 0 -- => [ 0x00, 0x00, 0x00, 0x00, 0x00 ]\nbuiltinIntegerToByteString True 5 0 -- => [ 0x00, 0x00, 0x00, 0x00, 0x00 ]\n-- length argument too large (2^29)\nbuiltinIntegerToByteString False 536870912 0 -- => ERROR\n-- endianness doesn't affect this case\nbuiltinIntegerToByteString True 536870912 0 -- => ERROR\n-- fails due to insufficient digits (404 needs 2)\nbuiltinIntegerToByteString False 1 404 -- => ERROR\n-- endianness argument doesn't affect this case\nbuiltinIntegerToByteString True 1 404 -- => ERROR\n-- zero length argument is exactly the same as requesting exactly the right\n-- digit count\nbuiltinIntegerToByteString False 2 404 -- => [ 0x94, 0x01 ] \nbuiltinIntegerToByteString False 0 404 -- => [ 0x94, 0x01 ]\n-- switching endianness argument reverses the result\nbuiltinIntegerToByteString True 2 404 -- => [ 0x01, 0x94 ]\nbuiltinIntegerToByteString True 0 404 -- => [ 0x01, 0x94 ]\n-- padding for most-significant-last goes at the end\nbuiltinIntegerToByteString False 5 404 -- => [ 0x94, 0x01, 0x00, 0x00, 0x00 ]\n-- padding for most-significant-first goes at the start\nbuiltinIntegerToByteString True 5 404 -- => [ 0x00, 0x00, 0x00, 0x01, 0x94 ]\n```\n\nWe also describe properties that any implementation of `builtinIntegerToByteString` must\nhave. Throughout, `q` is not negative, `p` is positive, `d` is in the closed\ninterval $(0, 2^{29} - 1)$, `k` is in the closed interval $(1, 2^{29} - 1)$, \n`0 <= j < k`, and `1 <= r <= 255`. We also define `singleton x = consByteString\nx emptyByteString`.\n\n1. `lengthOfByteString (builtinIntegerToByteString e d 0) = d`\n2. `indexByteString (builtinIntegerToByteString e k 0) j = 0`\n3. `lengthOfByteString (builtinIntegerToByteString e 0 p) > 0`\n4. `builtinIntegerToByteString False 0 (multiplyInteger p 256) = consByteString 0\n   (builtinIntegerToByteString False 0 p)`\n5. `builtinIntegerToByteString True 0 (multiplyInteger p 256) = appendByteString\n   (builtinIntegerToByteString True 0 p) (singleton 0)`\n6. `builtinIntegerToByteString False 0 (plusInteger (multiplyInteger q 256) r) =\n   appendByteString (builtinIntegerToByteString False 0 r)`\n   (builtinIntegerToByteString False 0 q)`\n7. `builtinIntegerToByteString True 0 (plusInteger (multiplyInteger q 256) r) =\n   appendByteString (builtinIntegerToByteString False 0 q)\n   (builtinIntegerToByteString False 0 r)`\n\n### `builtinByteStringToInteger`\n\nThe `builtinByteStringToInteger` primitive takes two arguments. We specify, and\nname, these below:\n\n1. Whether the input uses the most-significant-first encoding. This is the\n   _stated endianness argument_, which has type `BuiltinBool`.\n2. The `BuiltinByteString` to convert. This is the _input_.\n\nIf the input is the empty `BuiltinByteString`, `builtinByteStringToInteger`\nreturns 0. If the input is non-empty, `builtinByteStringToInteger` produces the\n`BuiltinInteger` encoded by the input. The encoding is treated as\nmost-significant-first if the stated endianness argument is `True`, and\nmost-significant-last if the stated endianness argument is `False`. The input\nencoding may be padded or not.\n\nWe give some examples of the intended behaviour of `builtinByteStringToInteger`\nbelow:\n\n```haskell\n-- empty input gives zero\nbuiltinByteStringToInteger False emptyByteString => 0\n-- stated endianness argument doesn't affect this case\nbuiltinByteStringToInteger True emptyByteString => 0\n-- if all the bytes are the same, stated endianness argument doesn't matter\nbuiltinByteStringToInteger False (consByteString 0x01 (consByteString 0x01\nemptyByteString) -- => 257\nbuiltinByteStringToInteger True (consByteString 0x01 (consByteString 0x01\nemptyByteString) -- => 257\n-- most-significant-first padding is at the start\nbuiltinByteStringToInteger True (consByteString 0x00 (consByteString 0x01\n(consByteString 0x01 emptyByteString))) -- => 257\nbuiltinByteStringToInteger False (consByteString 0x00 (consByteString 0x01\n(consByteString 0x01 emptyByteString))) -- => 65792\n-- most-significant-last padding is at the end\nbuiltinByteStringToInteger False (consByteString 0x01 (consByteString 0x01\n(consByteString 0x00 emptyByteString) -- => 257\nbuiltinByteStringToInteger True (consByteString 0x01 (consByteString 0x01\n(consByteString 0x00 emptyByteString) -- => 65792\n```\n\nWe also describe properties that any `builtinByteStringToInteger` implementation \nmust have. Throughout, `q` is not negative and `0 <= w8 <= 255`.\n\n1. `builtinByteStringToInteger b (builtinIntegerToByteString b 0 q) = q`\n2. `builtinByteStringToInteger b (consByteString w8 emptyByteString) = w8`\n3. `builtinIntegerToByteString b (lengthOfByteString bs) (builtinByteStringToInteger b bs) =\n   bs`\n\n## Rationale: how does this CIP achieve its goals?\n\nWe believe that these operations address both of the described cases well, while\nalso meeting the goals stated at the start of this CIP. Our specified primitives\naddress both the problems of endianness and padding specified in Case 2, while\nalso ensuring that use cases like Case 1 (where bounding length isn't important)\nare not made more difficult than necessary. The representation we have chosen is\nmetadata-free, doesn't depend on any representation choices (current or future)\nof `BuiltinInteger`, while also being flexible enough to satisfy both cases\nwhere endianness and padding matter, and when they don't.\n\n### Alternative possibilities\n\nAs part of this proposal, we considered two alternative possibilities:\n\n1. Use the [CIP-0058][cip-0058] versions of these operations; and\n2. Have a uniform treatment of the length argument for\n   `builtinIntegerToByteString` (always minimum or always maximum).\n\n[CIP-0058][cip-0058] defines a sizeable collection of bitwise primitive\noperations for Plutus Core, mostly for use over `BuiltinByteString`s. As part of\nthese, it also defines conversion functions similar to\n`builtinIntegerToByteString` and `builtinByteStringToInteger`, which are named\n`integerToByteString` and `byteStringToInteger` respectively. Unlike the\noperations specified in this CIP, the CIP-0058 operations do not address the\nproblems of either padding or endianness: more precisely, the representations\nconstructed are always minimally-sized, and use a big-endian encoding. While in\nthe context they are being presented in, these choices are defensible, they do\nnot adequately address Case 2, and in\nparticular, many cryptographic constructions used with finite fields. Users of\nthe CIP-0058 primitives who needed to ensure a minimum length of a converted\n`BuiltinInteger` would have to pad manually, which CIP-0058 gives no additional\nsupport for; additionally, if a little-endian representation was required, the\n`BuiltinByteString` result would have to be reversed, which has quadratic cost\nif using only Plutus Core primitives. Thus, we consider these implementations to\nbe a good attempt, but not suited to even their intended use, much less more\ngeneral applications.\n\nAn alternative possibility for the length argument of\n`builtinIntegerToByteString` would be to treat the argument as either a minimum,\nor a maximum, rather than our more hybrid approach. Specifically, for any input\n`i`, let `d` be the minimum number of digits required to represent `i` as per\nthe description of our representation, and let `k` be the length argument.\nThen:\n\n* The _minimum length argument_ approach would produce a result of size \n  $\\min \\\\{ \\texttt{d}, \\texttt{k} \\\\}$; that is, if the length argument is\n  smaller than the minimum required digits, the minimum would be used instead.\n* The _maximum length argument_ approach would produce a result of size `k`,\n  and would error if $\\texttt{d} > \\texttt{k}$.\n\nBoth the minimum length argument, and the maximum length argument, approaches\nhave merits. The maximum length argument approach in particular is useful for Case 2:\nin such a setting, we already know the maximum size of\nany element's representation, and if we somehow ended up with a larger\nrepresentation than this, it would be a mistake, which the maximum length\nargument would catch immediately. For the minimum length argument approach, the\nadvantage would be more for Case 1: where the length of the\nrepresentation is not known (and the user isn't particularly concerned anyway).\nIn such a situation, the user could pass any argument and know that the\nconversion would still work.\n\nHowever, both of these approaches have disadvantages as well. The minimum\nlength argument approach would be more tedious to use with Case 2, as each \nconversion would require a size check of the resulting\n`BuiltinByteString`. While this is not expensive, it is annoying, and given the\ncomplexity of the constructions that would be built atop of any finite field\nimplementations, it feels unreasonable to require this from users. Likewise, the\nmaximum length argument approach is unreasonable for situations like Case 1: the only\nway to establish how many digits would be required involves performing an\ninteger logarithm in base 256, which is inefficient and error-prone. Our hybrid\napproach gives the benefits of both the minimum length argument and maximum\nlength argument approaches, without the downsides of either: we observe that,\nfor situations like Case 1, the length argument would be `0` in practically all\ncases, which is a value that would not be useful in any situation where the maximum \nlength argument approach would be used. This observation allows our approach to work \nequally well for both Case 1 and 2, with minimal friction.\n\n## Path to Active\n\n### Acceptance Criteria\n\nWe consider the following criteria to be essential for acceptance:\n\n* A proof-of-concept implementation of the operation specified here must exist,\n  outside of the Plutus source tree. The implementation must be in Haskell.\n* The proof-of-concept implementation must have tests, demonstrating that it\n  behaves as the specification requires, and that the representations it\n  produces match the described representation in this CIP.\n* The proof-of-concept implementation must demonstrate that it will successfully\n  build, and pass its tests, using all GHC versions currently usable to build\n  Plutus (8.10, 9.2 and 9.6 at the time of writing), across all [Tier 1][tier-1]\n  platforms.\n\nIdeally, the implementation should also demonstrate its performance\ncharacteristics by well-designed benchmarks.\n\n[tier-1]: https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms#tier-1-platforms\n\n### Implementation Plan\n\nMLabs have completed the implementation of the proof of concept as required\n(located [here](https://github.com/mlabs-haskell/plutus-integer-bytestring).\nThis implementation has been merged into Plutus Core, and will be released in\nthe upcoming V3 release.\n\n## Copyright\n\nThis CIP is licensed under the [Apache-2.0][Apache-2.0] license.\n\n[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n[Apache-2.0]: http://www.apache.org/licenses/LICENSE-2.0\n"
  },
  {
    "path": "CIP-0122/README.md",
    "content": "---\nCIP: 122\nTitle: Logical operations over BuiltinByteString\nCategory: Plutus\nStatus: Active\nAuthors: \n    - Koz Ross <koz@mlabs.city>\nImplementors: \n    - Koz Ross <koz@mlabs.city>\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/806\nCreated: 2024-05-03\nLicense: Apache-2.0\n---\n\n## Abstract\n\nWe describe the semantics of a set of logical operations for Plutus\n`BuiltinByteString`s. Specifically, we provide descriptions for:\n\n- Bitwise logical AND, OR, XOR and complement;\n- Reading a bit value at a given index;\n- Setting bits value at given indices; and\n- Replicating a byte a given number of times.\n\nAs part of this, we also describe the bit ordering within a `BuiltinByteString`,\nand provide some laws these operations should obey.\n\n## Motivation: why is this CIP necessary?\n\nBitwise operations, both over fixed-width and variable-width blocks of bits,\nhave a range of uses, including data structures (especially\n[succinct][succinct-data-structures] ones) and cryptography. Currently,\noperations on individual bits in Plutus Core are difficult, or outright\nimpossible, while also keeping within the tight constraints required onchain.\nWhile it is possible to some degree to work with individual _bytes_ over\n`BuiltinByteString`s, this isn't sufficient, or efficient, when bit\nmaniputations are required.\n\nTo demonstrate where bitwise operations would allow onchain possibilities that\nare currently either impractical or impossible, we give the following use cases.\n\n### Case 1: integer set\n\nAn _integer set_ (also known as a bit set, bitmap, or bitvector) is a\n[succinct][succinct-data-structures] data structure for representing a set of\nnumbers in a pre-defined range $[0, n)$ for some $n \\in \\mathbb{N}$. The\nstructure supports the following operations:\n\n* Construction given a fixed number of elements, as well as the bound $n$.\n* Construction of the empty set (contains no elements) and the universe\n  (contains all elements).\n* Set union, intersection, complement and difference (symmetric and asymmetric).\n* Membership testing for a specific element.\n* Inserting or removing elements.\n\nThese structures have a range of uses. In addition to being used as sets of\nbounded natural numbers, an integer set could also represent an array of Boolean\nvalues. These have [a range of applications][bitvector-apps], mostly as\n'backends' for other, more complex structures. Furthermore, by using some index \narithmetic, integer sets can also be used to represent \n[binary matrices][binary-matrix] (in any number of\ndimensions), which have an even wider range of uses:\n\n* Representations of graphs in [adjacency-matrix][adjacency-matrix] form\n* [Checking the rules for a game of Go][go-binary-matrix]\n* [FSM representation][finite-state-machine-4vl]\n* Representation of an arbitrary binary relation between finite sets\n\nThe succinctness of the integer set (and the other succinct data structures it\nenables) is particularly valuable on-chain, due to the limited transaction size\nand memory available.\n\nTypically, such a structure would be represented as a packed array of bytes\n(similar to the Haskell `ByteString`). Essentially, given a bound $n$, the\npacked array has a length in bytes large enough to contain at least $n$ bits,\nwith a bit at position $i$ corresponding to the value $i \\in \\mathbb{N}$. This \nrepresentation ensures the succinctness of the structure (at most 7 bits of \noverhead are required if $n = 8k + 1$ for some $k \\in \\mathbb{N}$), and\nalso allows all the above operations to be implemented efficiently:\n\n* Construction given a fixed number of elements and the bound $n$ involves\n  allocating the packed array, then modifying some bits to be set.\n* Construction of the empty set is a packed array where every byte is `0x00`,\n  while the universe is a packed array where every byte is `0xFF`.\n* Set union is bitwise OR over both arguments.\n* Set intersection is bitwise AND over both arguments.\n* Set complement is bitwise complement over the entire packed array.\n* Symmetric set difference is bitwise XOR over both arguments; asymmetric set\n  difference can be defined using a combination of bitwise complement and\n  bitwise OR.\n* Membership testing is checking whether a bit is set.\n* Inserting an element is setting the corresponding bit.\n* Removing an element is clearing the corresponding bit.\n\nGiven that this is a packed representation, these operations can be implemented\nvery efficiently by relying on the cache-friendly properties of packed array\ntraversals, as well as making use of optimized routines available in many\nlanguages. Thus, this structure can be used to efficiently represent sets of\nnumbers in any bounded range (as ranges not starting from $0$ can be represented\nby storing an offset), while also being minimal in space usage.\n\nCurrently, such a structure cannot be easily implemented in Plutus Core while\npreserving the properties described above. The two options using existing\nprimitives are either to use `[BuiltinInteger]`, or to mimic the above\noperations over `BuiltinByteString`. The first of these is not space _or_\ntime-efficient: each `BuiltinInteger` takes up multiple machine words of space,\nand the list overheads introduced are linear in the number of items stored,\ndestroying succinctness; membership testing, insertion and removal require\neither maintaining an ordered list or forcing linear scans for at least some\noperations, which are inefficient over lists; and 'bulk' operations like union,\nintersection and complement become very difficult and time-consuming. The second\nis not much better: while we preserve succinctness, there is no easy way to\naccess individual bits, only bytes, which would require a division-remainder\nloop for each such operation, with all the overheads this imposes; intersection,\nunion and symmetric difference would have to be simulated byte-by-byte,\nrequiring large lookup tables or complex conditional logic; and construction\nwould require immense amounts of copying and tricky byte construction logic.\nWhile it is not outright impossible to make such a structure using current\nprimitives, it would be so impractical that it could never see real use.\n\nFurthermore, for sparse (or dense) integer sets (that is, where either most\nelements in the range are absent or present respectively), a range of\n[compression techniques][bitmap-index-compression] have been developed. All of\nthese rely on bitwise operations to achieve their goals, and can potentially\nyield significant space savings in many cases. Given the limitations onchain\nthat we have to work within, having such techniques available to implementers\nwould be a huge potential advantage.\n\n### Case 2: hashing\n\n[Hashing][hashing], that is, computing a fixed-length 'fingerprint' or 'digest'\nof a variable-length input (typically viewed as binary) is a common task\nrequired in a range of applications. Most notably, hashing is a key tool in\ncryptographic protocols and applications, either in its own right, or as part of\na larger task. The value of such functionality is such that Plutus Core already\ncontains primitives for certain hash functions, specifically two variants of\n[SHA256][sha256] and [BLAKE2b][blake2b]. At the same time, hash functions\nchoices are often determined by protocol or use case, and providing individual\nprimitives for every possible hash function is not a scalable choice. It is much\npreferrable to give necessary tools to implement such functionality to users of\nPlutus (Core), allowing them to use whichever hash function(s) their\napplications require.\n\nAs an example, we consider the [Argon2][argon2] family of hash functions. In\norder to implement any variant of this family requires the following operations:\n\n1. Conversion of numbers to bytes\n2. Bytestring concatenation\n3. BLAKE2b hashing\n4. Floor division\n5. Indexing bytes in a bytestring\n6. Logical XOR\n\nOperations 1 to 5 are already provided by Plutus Core (with 1 being included [in\nCIP-121][conversion-cip]); however, without logical XOR, no function in the\nArgon2 family could be implemented. While in theory, it could be simulated with\nwhat operations already exist, much as with Case 1, this would be impractical at\nbest, and outright impossible at worst, due to the severe limits imposed\non-chain. This is particularly the case here, as all Argon2 variants call\nlogical XOR in a loop, whose step count is defined by _multiple_ user-specified\n(or protocol-specified) parameters.\n\nWe observe that this requirement for logical XOR is not unique to the Argon2\nfamily of hash functions. Indeed, logical XOR is widely used for [a variety of\ncryptographic applications][xor-crypto], as it is a low-cost mixing\nfunction that happens to be self-inverting, as well as preserving randomness\n(that is, a random bit XORed with a non-random bit will give a random bit).  \n\n## Specification\n\nWe describe the proposed operations in several stages. First, we specify a\nscheme for indexing individual bits (rather than whole bytes) in a\n`BuiltinByteString`. We then specify the semantics of each operation, as well as\ngiving costing expectations and some examples. Lastly, we provide some laws that \nany implementation of these operations is expected to obey.\n\n### Bit indexing scheme\n\nWe begin by observing that a `BuiltinByteString` is a packed array of bytes\n(that is, `BuiltinInteger`s in the range $[0, 255]$) according to the API\nprovided by existing Plutus Core primitives. In particular, we have the ability\nto access individual bytes by index as a primitive operation. Thus, we can view\na `BuiltinByteString` as an indexed collection of bytes; for any\n`BuiltinByteString` $b$ of length $n$, and any $i \\in 0, 1, \\ldots, n - 1$, we\ndefine $b\\\\{i\\\\}$ as the byte at index $i$ in $b$, as defined by the\n`indexByteString` primitive. In essence, for any `BuiltinByteString` of\nlength `n`, we have _byte_ indexes as follows:\n\n```\n| Index | 0  | 1  | ... | n - 1    |\n|-------|----|----| ... |----------|\n| Byte  | w0 | w1 | ... | w(n - 1) |\n```\n\nTo view a `BuiltinByteString` as an indexed collection of _bits_, we must first\nconsider the bit ordering within a byte. Suppose $i \\in 0, 1, \\ldots, 7$ is an\nindex into a byte $w$. We say that the bit at $i$ in $w$ is _set_ when\n\n$$\n\\left \\lfloor \\frac{w}{2^{i}} \\right \\rfloor \\mod 2 \\equiv 1\n$$\n\nOtherwise, the bit at $i$ in $w$ is _clear_. We define $w[i]$ to be $1$ when \nthe bit at $i$ in $w$ is set, and $0$ otherwise; this is the _value_ at index\n$i$ in $w$.\n\nFor example, consider the byte represented by the `BuiltinInteger` 42. By the\nabove scheme, we have the following:\n\n| Bit index | Set or clear? |\n|-----------|---------------|\n| $0$       | Clear         |\n| $1$       | Set           |\n| $2$       | Clear         |\n| $3$       | Set           |\n| $4$       | Clear         |\n| $5$       | Set           |\n| $6$       | Clear         |\n| $7$       | Clear         |\n\nPut another way, we can view $w[i] = 1$ to mean that the $(i + 1)$ th least significant\ndigit in $w$'s binary representation is $1$, and likewise, $w[i] = 0$ would mean\nthat the $i$th least significant digit in $w$'s binary representation is $0$.\nContinuing with the above example, $42$ is represented in binary as `00101010`;\nwe can see that the second-least-significant, fourth-least-significant, and\nsixth-least-significant digits are `1`, and all the others are zero. This\ndescription mirrors the way bytes are represented on machine architectures.\n\nWe now extend the above scheme to `BuiltinByteString`s. Let $b$ be a\n`BuiltinByteString` whose length is $n$, and let $i \\in 0, 1, \\ldots, 8 \\cdot n - 1$. \nFor any $j \\in 0, 1, \\ldots, n - 1$, let $j^{\\prime} = n - j - 1$. We say that the bit \nat $i$ in $b$ is set if\n\n$$\nb\\left\\\\{\\left(\\left\\lfloor \\frac{i}{8} \\right\\rfloor\\right)^{\\prime}\\right\\\\}[i\\mod 8] = 1\n$$\n\nWe define the bit at $i$ in $b$ being clear analogously. Similarly to bits in a\nbyte, we define $b[i]$ to be $1$ when the bit at $i$ in $b$ is set, and $0$\notherwise; similarly to bytes, we term this the _value_ at index $i$ in $b$.\n\nAs an example, consider the `BuiltinByteString` `[42, 57, 133]`: that is, the\n`BuiltinByteString` $b$ such that $b\\\\{0\\\\} = 42$, $b\\\\{1\\\\} = 57$ and $b\\\\{2\\\\}\n= 133$. We observe that the range of 'valid' bit indexes $i$ into $b$ is in \n$[0, 3 \\cdot 8 - 1 = 23]$. Consider $i = 4$; by the definition above, this\ncorresponds to the _byte_ index 2, as $\\left\\lfloor\\frac{4}{8}\\right\\rfloor =\n0$, and $3 - 0 - 1 = 2$ (as $b$ has length $3$). Within the byte $133$, this\nmeans we have $\\left\\lfloor\\frac{133}{2^4}\\right\\rfloor \\mod 2 \\equiv 0$. Thus,\n$b[4] = 0$. Consider instead the index $i = 19$; by the definition above, this\ncorresponds to the _byte_ index 0, as $\\left\\lfloor\\frac{19}{8}\\right\\rfloor =\n2$, and $3 - 2 - 1 = 0$. Within the byte $42$, this means we have\n$\\left\\lfloor\\frac{42}{2^3}\\right\\rfloor\\mod 2 \\equiv 1$. Thus, $b[19] = 1$. \n\nPut another way, our _byte_ indexes run 'the opposite way' to our _bit_ indexes.\nThus, for any `BuiltinByteString` of length $n$, we have _bit_ indexes relative\n_byte_ indexes as follows:\n\n```\n| Byte index | 0                              | 1  | ... | n - 1                         |\n|------------|--------------------------------|----| ... |-------------------------------|\n| Byte       | w0                             | w1 | ... | w(n - 1)                      |\n|------------|--------------------------------|----| ... |-------------------------------|\n| Bit index  | 8n - 1 | 8n - 2 | ... | 8n - 8 |   ...    | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |\n```\n\n### Operation semantics\n\nWe describe precisely the operations we intend to implement, and their\nsemantics. These operations will have the following signatures:\n\n* `bitwiseLogicalAnd :: BuiltinBool -> BuiltinByteString -> BuiltinByteString ->\n  BuiltinByteString`\n* `bitwiseLogicalOr :: BuiltinBool -> BuiltinByteString -> BuiltinByteString ->\n  BuiltinByteString`\n* `bitwiseLogicalXor :: BuiltinBool -> BuiltinByteString -> BuiltinByteString ->\n  BuiltinByteString`\n* `bitwiseLogicalComplement :: BuiltinByteString -> BuiltinByteString`\n* `readBit :: BuiltinByteString -> BuiltinInteger -> BuiltinBool`\n* `writeBits :: BuiltinByteString -> [(BuiltinInteger, BuiltinBool)] ->\n  BuiltinByteString`\n* `replicateByteString :: BuiltinInteger -> BuiltinInteger -> BuiltinByteString`\n\nWe assume the following costing, for both memory and execution time:\n\n| Operation | Cost |\n|-----------|------|\n| `bitwiseLogicalAnd` | Linear in longest `BuiltinByteString` argument |\n| `bitwiseLogicalOr` | Linear in longest `BuiltinByteString` argument |\n| `bitwiseLogicalXor` | Linear in longest `BuiltinByteString` argument |\n| `bitwiseLogicalComplement` | Linear in `BuiltinByteString` argument |\n| `readBit` | Constant |\n| `writeBits` | Additively linear in both arguments |\n| `replicateByteString` | Linear in the _value_ of the first argument |\n\n#### Padding versus truncation semantics\n\nFor the binary logical operations (that is, `bitwiseLogicalAnd`,\n`bitwiseLogicalOr` and `bitwiseLogicalXor`), the we have two choices of\nsemantics when handling `BuiltinByteString` arguments of different lengths. We\ncan either produce a result whose length is the _minimum_ of the two arguments\n(which we call _truncation semantics_), or produce a result whose length is the\n_maximum_ of the two arguments (which we call _padding semantics_). As these can\nboth be useful depending on context, we allow both, controlled by a\n`BuiltinBool` flag, on all the operations listed above. \n\nIn cases where we have arguments of different lengths, in order to produce a\nresult of the appropriate lengths, one of the arguments needs to be either\npadded or truncated. Let `short` and `long` refer to the `BuiltinByteString`\nargument of shorter length, and of longer length, respectively. The following\ntable describes what happens to the arguments before the operation:\n\n| Semantics | `short` | `long` |\n|-----------|---------|--------|\n| Padding   | Pad at high _byte_ indexes | Unchanged |\n| Truncation | Unchanged | Truncate high _byte_ indexes |\n\nWe pad with different bytes depending on operation: for `bitwiseLogicalAnd`, we\npad with `0xFF`, while for `bitwiseLogicalOr` and `bitwiseLogicalXor` we pad\nwith `0x00` instead. We refer to arguments so changed as \n_semantics-modified_ arguments.\n\nFor example, consider the `BuiltinByteString`s `x = [0x00, 0xF0, 0xFF]` and `y =\n[0xFF, 0xF0]`. The following table describes what the semantics-modified\nversions of these arguments would become for each operation and each semantics:\n\n| Operation | Semantics | `x` | `y` |\n|-----------|-----------|-----|-----|\n| `bitwiseLogicalAnd` | Padding | `[0x00, 0xF0, 0xFF]` | `[0xFF, 0xF0, 0xFF]` |\n| `bitwiseLogicalAnd` | Truncation | `[0x00, 0xF0]` | `[0xFF, 0xF0]` |\n| `bitwiseLogicalOr` | Padding | `[0x00, 0xF0, 0xFF]` | `[0xFF, 0xF0, 0x00]` |\n| `bitwiseLogicalor` | Truncation | `[0x00, 0xF0]` | `[0xFF, 0xF0]` |\n| `bitwiseLogicalXor` | Padding | `[0x00, 0xF0, 0xFF]` | `[0xFF, 0xF0, 0x00]` |\n| `bitwiseLogicalXor` | Truncation | `[0x00, 0xF0]` | `[0xFF, 0xF0]` |\n\nBased on the above, we observe that under padding semantics, the result of any\nof the listed operations would have a byte length of 3, while under truncation\nsemantics, the result would have a byte length of 2 instead.\n\n#### `bitwiseLogicalAnd`\n\n`bitwiseLogicalAnd` takes three arguments; we name and describe them below.\n\n1. Whether padding semantics should be used. If this argument is `False`,\n   truncation semantics are used instead. This is the _padding semantics\n   argument_, and has type `BuiltinBool`.\n2. The first input `BuiltinByteString`. This is the _first data argument_.\n3. The second input `BuiltinByteString`. This is the _second data argument_.\n\nLet $b_1, b_2$ refer to the semantics-modified first data argument and\nsemantics-modified second data argument respectively, and let $n$ be either of \ntheir lengths in bytes; see the \n[section on padding versus truncation semantics](#padding-versus-truncation-semantics) \nfor the exact specification of this. Let the result of `bitwiseLogicalAnd`, given \n$b_1, b_2$ and some padding semantics argument, be $b_r$, also of length $n$ \nin bytes. We use $b_1\\\\{i\\\\}$ to refer to the byte at index $i$ in $b_1$ (and\nanalogously for $b_2$, $b_r$); see the [section on the bit indexing\nscheme](#bit-indexing-scheme) for the exact specification of this.\n\nFor all $i \\in 0, 1, \\ldots, n - 1$, we have \n$b_r\\\\{i\\\\} = b_0\\\\{i\\\\} \\text{ }\\\\& \\text{ } b_1\\\\{i\\\\}$, where $\\\\&$ refers to a \n[bitwise AND][bitwise-and].\n\nSome examples of the intended behaviour of `bitwiseLogicalAnd` follow. For\nbrevity, we write `BuiltinByteString` literals as lists of hexadecimal values.\n\n```\n-- truncation semantics\nbitwiseLogicalAnd False [] [0xFF] => []\n\nbitwiseLogicalAnd False [0xFF] [] => []\n\nbitwiseLogicalAnd False [0xFF] [0x00] => [0x00]\n\nbitwiseLogicalAnd False [0x00] [0xFF] => [0x00]\n\nbitwiseLogicalAnd False [0x4F, 0x00] [0xF4] => [0x44]\n\n-- padding semantics\nbitwiseLogicalAnd True [] [0xFF] => [0xFF]\n\nbitwiseLogicalAnd True [0xFF] [] => [0xFF]\n\nbitwiseLogicalAnd True [0xFF] [0x00] => [0x00]\n\nbitwiseLogicalAnd True [0x00] [0xFF] => [0x00]\n\nbitwiseLogicalAnd True [0x4F, 0x00] [0xF4] => [0x44, 0x00]\n```\n\n#### `bitwiseLogicalOr`\n\n`bitwiseLogicalOr` takes three arguments; we name and describe them below.\n\n1. Whether padding semantics should be used. If this argument is `False`,\n   truncation semantics are used instead. This is the _padding semantics\n   argument_, and has type `BuiltinBool`.\n2. The first input `BuiltinByteString`. This is the _first data argument_.\n3. The second input `BuiltinByteString`. This is the _second data argument_.\n\nLet $b_1, b_2$ refer to the semantics-modified first data argument and\nsemantics-modified second data argument respectively, and let $n$ be either of \ntheir lengths in bytes; see the \n[section on padding versus truncation semantics](#padding-versus-truncation-semantics) \nfor the exact specification of this. Let the result of `bitwiseLogicalOr`, given \n$b_1, b_2$ and some padding semantics argument, be $b_r$, also of length $n$ \nin bytes. We use $b_1\\\\{i\\\\}$ to refer to the byte at index $i$ in $b_1$ (and\nanalogously for $b_2$, $b_r$); see the [section on the bit indexing\nscheme](#bit-indexing-scheme) for the exact specification of this.\n\nFor all $i \\in 0, 1, \\ldots, n - 1$, we have \n$b_r\\\\{i\\\\} = b_0\\\\{i\\\\} \\text{ } \\| \\text{ } b_1\\\\{i\\\\}$, where $\\|$ refers to \na [bitwise OR][bitwise-or].\n\n```\n-- truncation semantics\nbitwiseLogicalOr False [] [0xFF] => []\n\nbitwiseLogicalOr False [0xFF] [] => []\n\nbitwiseLogicalOr False [0xFF] [0x00] => [0xFF]\n\nbitwiseLogicalOr False [0x00] [0xFF] => [0xFF]\n\nbitwiseLogicalOr False [0x4F, 0x00] [0xF4] => [0xFF]\n\n-- padding semantics\nbitwiseLogicalOr True [] [0xFF] => [0xFF]\n\nbitwiseLogicalOr True [0xFF] [] => [0xFF]\n\nbitwiseLogicalOr True [0xFF] [0x00] => [0xFF]\n\nbitwiseLogicalOr True [0x00] [0xFF] => [0xFF]\n\nbitwiseLogicalOr True [0x4F, 0x00] [0xF4] => [0xFF, 0x00]\n```\n\n#### `bitwiseLogicalXor`\n\n`bitwiseLogicalXor` takes three arguments; we name and describe them below.\n\n1. Whether padding semantics should be used. If this argument is `False`,\n   truncation semantics are used instead. This is the _padding semantics\n   argument_, and has type `BuiltinBool`.\n2. The first input `BuiltinByteString`. This is the _first data argument_.\n3. The second input `BuiltinByteString`. This is the _second data argument_.\n\nLet $b_1, b_2$ refer to the semantics-modified first data argument and\nsemantics-modified second data argument respectively, and let $n$ be either of \ntheir lengths in bytes; see the \n[section on padding versus truncation semantics](#padding-versus-truncation-semantics) \nfor the exact specification of this. Let the result of `bitwiseLogicalXor`, given \n$b_1, b_2$ and some padding semantics argument, be $b_r$, also of length $n$ \nin bytes. We use $b_1\\\\{i\\\\}$ to refer to the byte at index $i$ in $b_1$ (and\nanalogously for $b_2$, $b_r$); see the [section on the bit indexing\nscheme](#bit-indexing-scheme) for the exact specification of this.\n\nFor all $i \\in 0, 1, \\ldots, n - 1$, we have \n$b_r\\\\{i\\\\} = b_0\\\\{i\\\\} \\text{ } \\wedge \\text{ } b_1\\\\{i\\\\}$, where $\\wedge$ refers to \na [bitwise XOR][bitwise-xor].\n\nSome examples of the intended behaviour of `bitwiseLogicalXor` follow. For\nbrevity, we write `BuiltinByteString` literals as lists of hexadecimal values.\n\n```\n-- truncation semantics\nbitwiseLogicalXor False [] [0xFF] => []\n\nbitwiseLogicalXor False [0xFF] [] => []\n\nbitwiseLogicalXor False [0xFF] [0x00] => [0xFF]\n\nbitwiseLogicalXor False [0x00] [0xFF] => [0xFF]\n\nbitwiseLogicalXor False [0x4F, 0x00] [0xF4] => [0xBB]\n\n-- padding semantics\nbitwiseLogicalOr True [] [0xFF] => [0xFF]\n\nbitwiseLogicalOr True [0xFF] [] => [0xFF]\n\nbitwiseLogicalOr True [0xFF] [0x00] => [0xFF]\n\nbitwiseLogicalOr True [0x00] [0xFF] => [0xFF]\n\nbitwiseLogicalOr True [0x4F, 0x00] [0xF4] => [0xBB, 0x00]\n```\n\n#### `bitwiseLogicalComplement`\n\n`bitwiseLogicalComplement` takes a single argument, of type `BuiltinByteString`;\nlet $b$ refer to that argument, and $n$ its length in bytes. Let $b_r$ be\nthe result of `bitwiseLogicalComplement`; its length in bytes is also $n$. We\nuse $b[i]$ to refer to the value at index $i$ of $b$ (and analogously for $b_r$); \nsee the [section on the bit indexing scheme](#bit-indexing-scheme) for the exact\nspecification of this.\n\nFor all $i \\in 0, 1, \\ldots , 8 \\cdot n - 1$, we have\n\n$$\nb_r[i] = \\begin{cases}\n        0 & \\text{if } b[i] = 1\\\\\n        1 & \\text{otherwise}\\\\\n        \\end{cases}\n$$\n\nSome examples of the intended behaviour of `bitwiseLogicalComplement` follow. For\nbrevity, we write `BuiltinByteString` literals as lists of hexadecimal values.\n\n```\nbitwiseLogicalComplement [] => []\n\nbitwiseLogicalComplement [0x0F] => [0xF0]\n\nbitwiseLogicalComplement [0x4F, 0xF4] => [0xB0, 0x0B]\n```\n\n#### `readBit`\n\n`readBit` takes two arguments; we name and describe them below.\n\n1. The `BuiltinByteString` in which the bit we want to read can be found. This\n   is the _data argument_.\n2. A bit index into the data argument, of type `BuiltinInteger`. This is the\n   _index argument_.\n\nLet $b$ refer to the data argument, of length $n$ in bytes, and let $i$ refer to\nthe index argument. We use $b[i]$ to refer to the value at index $i$ of $b$; see \nthe [section on the bit indexing scheme](#bit-indexing-scheme) for the exact \nspecification of this.\n\nIf $i < 0$ or $i \\geq 8 \\cdot n$, then `readBit`\nfails. In this case, the resulting error message must specify _at least_ the\nfollowing information:\n\n* That `readBit` failed due to an out-of-bounds index argument; and\n* What `BuiltinInteger` was passed as an index argument.\n\nOtherwise, if $b[i] = 0$, `readBit` returns `False`, and if $b[i] = 1$,\n`readBit` returns `True`.\n\nSome examples of the intended behaviour of `readBit` follow. For\nbrevity, we write `BuiltinByteString` literals as lists of hexadecimal values.\n\n```\n-- Indexing an empty BuiltinByteString fails\nreadBit [] 0 => error\n\nreadBit [] 345 => error\n\n-- Negative indexes fail\nreadBit [] (-1) => error\n\nreadBit [0xFF] (-1) => error\n\n-- Indexing reads 'from the end'\nreadBit [0xF4] 0 => False\n\nreadBit [0xF4] 1 => False \n\nreadBit [0xF4] 2 => True \n\nreadBit [0xF4] 3 => False\n\nreadBit [0xF4] 4 => True\n\nreadBit [0xF4] 5 => True\n\nreadBit [0xF4] 6 => True\n\nreadBit [0xF4] 7 => True\n\n-- Out-of-bounds indexes fail\nreadBit [0xF4] 8 => error\n\nreadBit [0xFF, 0xF4] 16 => error\n\n-- Larger indexes read backwards into the bytes from the end\nreadBit [0xF4, 0xFF] 10 => False \n```\n\n#### `writeBits`\n\n`writeBits` takes two arguments: we name and describe them below.\n\n1. The `BuiltinByteString` in which we want to change some bits. This is the\n   _data argument_.\n2. A list of index-value pairs, indicating which positions in the data argument\n   should be changed to which value. This is the _change list argument_. Each\n   index has type `BuiltinInteger`, while each value has type `BuiltinBool`.\n\nLet $b$ refer to the data argument of length $n$ in bytes. We define `writeBits`\nrecursively over the structure of the change list argument. Throughout, we use\n$b_r$ to refer to the result of `writeBits`, whose length is also $n$. We use\n$b[i]$ to refer to the value at index $i$ of $b$ (and analogously, $b_r$); see\nthe [section on the bit indexing scheme](#bit-indexing-scheme) for the exact\nspecification of this.\n\nIf the change list argument is empty, we return the data argument unchanged.\nOtherwise, let $(i, v)$ be the head of the change list argument, and $\\ell$ its\ntail. If $i < 0$ or $i \\geq 8 \\cdot n$, then `writeBits` fails. In this case,\nthe resulting error message must specify at _least_ the following information:\n\n* That `writeBits` failed due to an out-of-bounds index argument; and\n* What `BuiltinInteger` was passed as $i$.\n\nOtherwise, for all $j \\in 0, 1, \\ldots 8 \\cdot n - 1$, we have\n\n$$\nb_r[j] = \\begin{cases}\n         0 & \\text{if } j = i \\text{ and } v = \\texttt{False}\\\\\n         1 & \\text{if } j = i \\text{ and } v = \\texttt{True}\\\\\n         b[j] & \\text{otherwise}\\\\\n         \\end{cases}\n$$\n\nThen, if we did not fail as described above, we repeat the `writeBits`\noperation, but with $b_r$ as the data argument and $\\ell$ as the change list\nargument.\n\nSome examples of the intended behaviour of `writeBits` follow. For\nbrevity, we write `BuiltinByteString` literals as lists of hexadecimal values.\n\n```\n-- Writing an empty BuiltinByteString fails\nwriteBits [] [(0, False)] => error\n\n-- Irrespective of index\nwriteBits [] [(15, False)] => error\n\n-- And value\nwriteBits [] [(0, True)] => error\n\n-- And multiplicity\nwriteBits [] [(0, False), (1, False)] => error\n\n-- Negative indexes fail\nwriteBits [0xFF] [((-1), False)] => error\n\n-- Even when mixed with valid ones\nwriteBits [0xFF] [(0, False), ((-1), True)] => error\n\n-- In any position\nwriteBits [0xFF] [((-1), True), (0, False)] => error\n\n-- Out-of-bounds indexes fail\nwriteBits [0xFF] [(8, False)] => error\n\n-- Even when mixed with valid ones\nwriteBits [0xFF] [(1, False), (8, False)] => error\n\n-- In any position\nwriteBits [0xFF] [(8, False), (1, False)] => error\n\n-- Bits are written 'from the end'\nwriteBits [0xFF] [(0, False)] => [0xFE]\n\nwriteBits [0xFF] [(1, False)] => [0xFD]\n\nwriteBits [0xFF] [(2, False)] => [0xFB]\n\nwriteBits [0xFF] [(3, False)] => [0xF7]\n\nwriteBits [0xFF] [(4, False)] => [0xEF]\n\nwriteBits [0xFF] [(5, False)] => [0xDF]\n\nwriteBits [0xFF] [(6, False)] => [0xBF]\n\nwriteBits [0xFF] [(7, False)] => [0x7F]\n\n-- True value sets the bit\nwriteBits [0x00] [(5, True)] => [0x20]\n\n-- False value clears the bit\nwriteBits [0xFF] [(5, False)] => [0xDF]\n\n-- Larger indexes write backwards into the bytes from the end\nwriteBits [0xF4, 0xFF] [(10, False)] => [0xF0, 0xFF]\n\n-- Multiple items in a change list apply cumulatively\nwriteBits [0xF4, 0xFF] [(10, False), (1, False)] => [0xF0, 0xFD]\n\nwriteBits (writeBits [0xF4, 0xFF] [(10, False)]) [(1, False)] => [0xF0, 0xFD]\n\n-- Order within a change list is unimportant among unique indexes\nwriteBits [0xF4, 0xFF] [(1, False), (10, False)] => [0xF0, 0xFD]\n\n-- But _is_ important for identical indexes\nwriteBits [0x00, 0xFF] [(10, True), (10, False)] => [0x00, 0xFF]\n\nwriteBits [0x00, 0xFF] [(10, False), (10, True)] => [0x04, 0xFF]\n\n-- Setting an already set bit does nothing\nwriteBits [0xFF] [(0, True)] => [0xFF]\n\n-- Clearing an already clear bit does nothing\nwriteBits [0x00] [(0, False)] => [0x00]\n```\n\n#### `replicateByteString`\n\n`replicateByteString` takes two arguments; we name and describe them below.\n\n1. The desired result length, of type `BuiltinInteger`. This is the _length\n   argument_.\n2. The byte to place at each position in the result, represented as a\n   `BuiltinInteger` (corresponding to the unsigned integer this byte encodes).\n   This is the _byte argument_.\n\nLet $n$ be the length argument, and $w$ the byte argument. If $n < 0$, then\n`replicateByteString` fails. In this case, the resulting error message must specify\n_at least_ the following information:\n\n* That `replicateByteString` failed due to a negative length argument; and\n* What `BuiltinInteger` was passed as the length argument.\n\nIf $n \\geq 0$, and $w < 0$ or $w > 255$, then `replicateByteString` fails. In this\ncase, the resulting error message must specify _at least_ the following\ninformation:\n\n* That `replicateByteString` failed due to the byte argument not being a valid\n  byte; and\n* What `BuiltinInteger` was passed as the byte argument.\n\nOtherwise, let $b$ be the result of `replicateByteString`, and let $b\\\\{i\\\\}$ be the\nbyte at position $i$ of $b$, as per [the section describing the bit indexing\nscheme](#bit-indexing-scheme). We have:\n\n* The length (in bytes) of $b$ is $n$; and\n* For all $i \\in 0, 1, \\ldots, n - 1$, $b\\\\{i\\\\} = w$.\n\nSome examples of the intended behaviour of `replicateByteString` follow. For\nbrevity, we write `BuiltinByteString` literals as lists of hexadecimal values.\n\n```\n-- Replicating a negative number of times fails\nreplicateByteString (-1) 0 => error\n\n-- Irrespective of byte argument\nreplicateByteString (-1) 3 => error\n\n-- Out-of-bounds byte arguments fail\nreplicateByteString 1 (-1) => error\n\nreplicateByteString 1 256 => error\n\n-- Irrespective of length argument\nreplicateByteString 4 (-1) => error\n\nreplicateByteString 4 256 => error\n\n-- Length of result matches length argument, and all bytes are the same\nreplicateByteString 0 0xFF => []\n\nreplicateByteString 4 0xFF => [0xFF, 0xFF, 0xFF, 0xFF]\n```\n\n### Laws\n\n#### Binary operations\n\nWe describe laws for all three operations that work over two\n`BuiltinByteStrings`, that is, `bitwiseLogicalAnd`, `bitwiseLogicalOr` and\n`bitwiseLogicalXor`, together, as many of them are similar (and related). We\ndescribe padding semantics and truncation semantics laws, as they are slightly\ndifferent.\n\nAll three operations above, under both padding and truncation semantics, are\n[commutative semigroups][special-semigroups]. Thus, we have:\n\n```haskell\nbitwiseLogicalAnd s x y = bitwiseLogicalAnd s y x\n\nbitwiseLogicalAnd s x (bitwiseLogicalAnd s y z) = bitwiseLogicalAnd s\n(bitwiseLogicalAnd s x y) z\n\n-- and the same for bitwiseLogicalOr and bitwiseLogicalXor\n```\n\nNote that the semantics (designated as `s` above) must be consistent in order\nfor these laws to hold. Furthermore, under padding semantics, all the above\noperations are [commutative monoids][commutative-monoid]:\n\n```haskell\nbitwiseLogicalAnd True x \"\" = bitwiseLogicalAnd True \"\" x = x\n\n-- and the same for bitwiseLogicalOr and bitwiseLogicalXor\n```\n\nUnder truncation semantics, `\"\"` (that is, the empty `BuiltinByteString`) acts\ninstead as an [absorbing element][absorbing-element]:\n\n```haskell\nbitwiseLogicalAnd False x \"\" = bitwiseLogicalAnd False \"\" x = \"\"\n\n-- and the same for bitwiseLogicalOr and bitwiseLogicalXor\n```\n\n`bitwiseLogicalAnd` and `bitwiseLogicalOr` are also [semilattices][semilattice],\ndue to their idempotence:\n\n```haskell\nbitwiseLogicalAnd s x x = x\n\n-- and the same for bitwiseLogicalOr\n```\n\n`bitwiseLogicalXor` is instead involute:\n\n```haskell\nbitwiseLogicalXor s x (bitwiseLogicalXor s x x) = bitwiseLogicalXor s\n(bitwiseLogicalXor s x x) x = x\n```\n\nAdditionally, under padding semantics, `bitwiseLogicalAnd` and\n`bitwiseLogicalOr` are [self-distributive][distributive]:\n\n```haskell\nbitwiseLogicalAnd True x (bitwiseLogicalAnd True y z) = bitwiseLogicalAnd True\n(bitwiseLogicalAnd True x y) (bitwiseLogicalAnd True x z)\n\nbitwiseLogicalAnd True (bitwiseLogicalAnd True x y) z = bitwiseLogicalAnd True\n(bitwiseLogicalAnd True x z) (bitwiseLogicalAnd True y z)\n\n-- and the same for bitwiseLogicalOr\n```\n\nUnder truncation semantics, `bitwiseLogicalAnd` is only left-distributive over\nitself, `bitwiseLogicalOr` and `bitwiseLogicalXor`:\n\n```haskell\nbitwiseLogicalAnd False x (bitwiseLogicalAnd False y z) = bitwiseLogicalAnd\nFalse (bitwiseLogicalAnd False x y) (bitwiseLogicalAnd False x z)\n\nbitwiseLogicalAnd False x (bitwiseLogicalOr False y z) = bitwiseLogicalOr False\n(bitwiseLogicalAnd False x y) (bitwiseLogicalAnd False x z)\n\nbitwiseLogicalAnd False x (bitwiseLogicalXor False y z) = bitwiseLogicalXor\nFalse (bitwiseLogicalAnd False x y) (bitwiseLogicalAnd False x z)\n```\n\n`bitwiseLogicalOr` under truncation semantics is left-distributive over itself\nand `bitwiseLogicalAnd`:\n\n```haskell\nbitwiseLogicalOr False x (bitwiseLogicalOr False y z) = bitwiseLogicalOr False\n(bitwiseLogicalOr False x y) (bitwiseLogicalOr False x z)\n\nbitwiseLogicalOr False x (bitwiseLogicalAnd False y z) = bitwiseLogicalAnd False\n(bitwiseLogicalOr False x y) (bitwiseLogicalOr False x z)\n```\n\nIf the first and second data arguments to these operations have the same length,\nthese operations satisfy several additional laws. We describe these briefly\nbelow, with the added note that, in this case, padding and truncation semantics\ncoincide:\n\n* `bitwiseLogicalAnd` and `bitwiseLogicalOr` form a [bounded lattice][lattice]\n* `bitwiseLogicalAnd` is [distributive][distributive] over itself, `bitwiseLogicalOr` and\n  `bitwiseLogicalXor`\n* `bitwiseLogicalOr` is [distributive][distributive] over itself and `bitwiseLogicalAnd`\n\nWe do not specify these laws here, as they do not hold in general. At the same\ntime, we expect that any implementation of these operations will be subject to\nthese laws.\n\n#### `bitwiseLogicalComplement`\n\nThe main law of `bitwiseLogicalComplement` is involution:\n\n```haskell\nbitwiseLogicalComplement (bitwiseLogicalComplement x) = x\n```\n\nIn combination with `bitwiseLogicalAnd` and `bitwiseLogicalOr`,\n`bitwiseLogicalComplement` gives rise to the famous [De Morgan laws][de-morgan], irrespective of semantics:\n\n```haskell\nbitwiseLogicalComplement (bitwiseLogicalAnd s x y) = bitwiseLogicalOr s\n(bitwiseLogicalComplement x) (bitwiseLogicalComplement y)\n\nbitwiseLogicalComplement (bitwiseLogicalOr s x y) = bitwiseLogicalAnd s\n(bitwiseLogicalComplement x) (bitwiseLogicalComplement y)\n```\n\nFor `bitwiseLogicalXor`, we instead have (again, irrespective of semantics):\n\n```haskell\nbitwiseLogicalXor s x (bitwiseLogicalComplement x) = x\n```\n\n#### Bit reading and modification\n\nThroughout, we assume any index arguments to be 'in-bounds'; that is, all the\nindex arguments used in the statements of any law are such that the operation\nthey are applied to wouldn't produce an error.\n\nThe first law of `writeBits` is similar to the [set-twice law of\nlenses][lens-laws]:\n\n```haskell\nwriteBits bs [(i, b1), (i, b2)] = writeBits bs [(i, b2)]\n```\n\nTogether with `readBit`, we obtain the remaining two analogues to the lens\nlaws:\n\n```haskell\n-- writing to an index, then reading from that index, gets you what you wrote\nreadBit (writeBits bs [(i, b)]) i = b\n\n-- if you read from an index, then write that value to that same index, nothing\n-- happens\nwriteBits bs [(i, readBit bs i)] = bs\n```\n\nFurthermore, given a fixed data argument, `writeBits` acts as a [monoid\nhomomorphism][monoid-homomorphism] lists under concatenation to functions:\n\n```haskell\nwriteBits bs [] = bs\n\nwriteBits bs (is <> js) = writeBits (writeBits bs is) js\n```\n\n#### `replicateByteString`\n\nGiven a fixed byte argument, `replicateByteString` acts as a [monoid\nhomomorphism][monoid-homomorphism] from natural numbers under addition to\n`BuiltinByteString`s under concatenation: \n\n```haskell\nreplicateByteString 0 w = \"\"\n\nreplicateByteString (n + m) w = replicateByteString n w <> replicateByteString m w\n```\n\nAdditionally, for any 'in-bounds' index (that is, any index for which\n`indexByteString` won't error) `i`, we have\n\n```haskell\nindexByteString (replicateByteString n w) i = w\n```\n\nLastly, we have\n\n```haskell\nlengthByteString (replicateByteString n w) = n\n```\n\n## Rationale: how does this CIP achieve its goals?\n\nThe operations, and semantics, described in this CIP provide a set of\nwell-defined bitwise logical operations, as well as bitwise access and\nmodification, to allow cases similar to Case 1 to be performed efficiently and\nconveniently. Furthermore, the semantics we describe would be reasonably\nfamiliar to users of other programming languages (including Haskell) which have\nprovisions for bitwise logical operations of this kind, as well as some way of\nextending these operations to operate on packed byte vectors. At the same time,\nthere are several choices we have made that are somewhat unusual, or could\npotentially have been implemented differently based on existing work: most\nnotably, our choice of bit indexing scheme, the padding-versus-truncation\nsemantics, and the multiplicitous definition of bit modification. Among existing\nwork, a particularly important example is [CIP-58][cip-58], which makes\nprovisions for operations similar to the ones described here, and from which we\ndiffer in several important ways. We clarify the reasoning behind our choices,\nand how they differ from existing work, below.\n\nAside from the issues we list below, we don't consider other operations\ncontroversial. Indeed, `bitwiseLogicalComplement` has a direct parallel to the\nimplementation in [CIP-58][cip-58], and `replicateByteString` is a direct wrapper\naround the `replicate` function in `ByteString`. Thus, we do not discuss them\nfurther here.\n\n### Relationship to CIP-58 and CIP-121\n\nOur work relates to both [CIP-58][cip-58] and [CIP-121][cip-121]. Essentially,\nour goal with both this CIP and CIP-121 is to both break CIP-58 into more\nmanageable (and reviewable) parts, and also address some of the design choices\nin CIP-58 that were not as good (or as clear) as they could have been. In this\nregard, this CIP is a direct continuation of CIP-121; CIP-121 dealt with\nconversions between `BuiltinByteString` and `BuiltinInteger`, while this CIP\nhandles bit indexing more generally, as well as 'parallel' logical operations\nthat operate on all the bits of a `BuiltinByteString` in bulk. \n\nWe describe how our work in this CIP relates to (and in some cases, supercedes)\nCIP-58, as well as how it follows on from CIP-121, in more detail below.\n\n### Bit indexing scheme\n\nThe bit indexing scheme we describe here is designed around two\nconsiderations. Firstly, we want operations on these bits, as well as those\nresults, to be as consistent and as predictable as possible: any individual\nfamiliar with such operations on variable-length bitvectors from another\nlanguage shouldn't be surprised by the semantics. Secondly, we want to\nanticipate future bitwise operation extensions, such as shifts and rotations,\nand have the indexing scheme support efficient implementations (and predictable\nsemantics) for these. \n\nWhile prior art for bit access (and modification) exists\nin almost any programming language, these are typically over types of fixed\nwidth (usually bytes, machine words, or something similar); for variable-width\ntypes, these typically are either not implemented at all, or if they are\nimplemented, this is done in an external library, with varying support for\ncertain operations. An example of the first is Haskell's `ByteString`, which has\nno way to even access, much less modify, individual bits; an example of the\nsecond is the [CRoaring][croaring] library for C, which supports all the\noperations we describe in this CIP, along with multiple others. In the second\ncase, the _exact_ arrangement of bits inside the representation is not something\nusers are exposed to directly: instead, the bitvector type is opaque, and the\nlibrary only guarantees consistency of API. In our case, this is not a viable\nchoice, as we require bit access _and_ byte access to both work on\n`BuiltinByteString`, and thus, some consistency of representation is required.\n\nThe scheme for indexing bits within a byte that we describe in [the relevant\nsection](#bit-indexing-scheme) is the same as the one used by the `Data.Bits`\nAPI in Haskell for `Word8` bit indexing, and mirrors the decisions of most\nlanguages that provide such an API at all, as well as the conventional\ndefinition of such operations as `(w >> i) & 1` for access, `w | (1 << i)` for\nsetting, and `w & ~(1 << i)` for clearing. We could choose to 'flip' this\nindexing, by using a similar operation for 'index flipping' as we currently use\nfor bytes: essentially, instead of \n\n$$\n\\left \\lfloor \\frac{w}{2^{i}} \\right \\rfloor \\mod 2 \\equiv 1\n$$\n\nwe would instead use\n\n$$\n\\left \\lfloor \\frac{w}{2^{8 - i - 1}} \\right \\rfloor \\mod 2 \\equiv 1\n$$\n\nto designate bit $i$ as set (and analogously for clear). Together with the\nability to choose _not_ to flip the _byte_ index, we get four possibilities,\nwhich have [been described previously][too-many-ways-1]. For clarity, we name,\nand describe, them below. Throughout, we use `n` as the length of a given\n`BuiltinByteString` in bytes.\n\nThe first possibility is that we 'flip' neither bit, nor byte, indexes. We call\nthis the _no-flip variant_:\n\n```\n| Byte index | 0                             | 1                 | ... | n - 1                          |\n|------------|-------------------------------|-------------------| ... |--------------------------------|\n| Byte       | w0                            | w1                | ... | w(n - 1)                       |\n|------------|-------------------------------|-------------------| ... |--------------------------------|\n| Bit index  | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 15 | 14 | ... | 8 | ... | 8n - 1 | 8n - 2 | ... | 8n - 8 |\n```\n\nThe second possibility is that we 'flip' _both_ bit and byte indexes. We call\nthis the _both-flip variant_:\n\n```\n| Byte index | 0                              | ... | n - 2            | n - 1                         |\n|------------|--------------------------------| ... |------------------|-------------------------------|\n| Byte       | w0                             | ... | w (n - 2)        | w(n - 1)                      |\n|------------|--------------------------------| ... |------------------|-------------------------------|\n| Bit index  | 8n - 8 | 8n - 7 | ... | 8n - 1 | ... | 8 | 9 | ... | 15 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | \n```\n\nThe third possibility is that we 'flip' _bit_ indexes, but not _byte_ indexes.\nWe call this the _bit-flip variant_:\n\n```\n| Byte index | 0                             | 1            | ... | n - 1                          |\n|------------|-------------------------------|--------------| ... |--------------------------------|\n| Byte       | w0                            | w1           | ... | w(n - 1)                       |\n|------------|-------------------------------|--------------| ... |--------------------------------|\n| Bit index  | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ... | 15 | ... | 8n - 8 | 8n - 7 | ... | 8n - 1 |\n```\n\nThe fourth possibility is the one we describe in the [bit indexing scheme\nsection](#bit-indexing-scheme), which is also the scheme chosen by CIP-58. We\nrepeat it below for clarity:\n\n```\n| Byte index | 0                              | 1  | ... | n - 1                         |\n|------------|--------------------------------|----| ... |-------------------------------|\n| Byte       | w0                             | w1 | ... | w(n - 1)                      |\n|------------|--------------------------------|----| ... |-------------------------------|\n| Bit index  | 8n - 1 | 8n - 2 | ... | 8n - 8 |   ...    | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |\n```\n\nOn the face of it, these schemes appear equivalent: they are all consistent, and\nall have formal descriptions, and quite similar ones at that. However, we\nbelieve that only the one we chose is the correct one. To explain this, we\nintroduce two notions that we consider to be both intuitive and important,\nthen specify why our choice of indexing scheme fits those notions better than\nany other.\n\nThe first notion is _index locality_. Intuitively, this states that if\ntwo indexes are 'close' (in that their absolute difference is small), the values\nat those indexes should be 'close' (in that their positioning in memory should\nbe separated less). We believe this notion to be reasonable, as this is an\nexpectation from array indexing (and indeed, `BuiltinByteString` indexing), as\nwell as the reason why packed array data is efficient on modern memory\nhierarchies. Extending this notion to bits, we can observe that the both-flip\nand no-flip variants of the bit indexing scheme do not preserve index locality:\nthe separation between a bit at index $0$ and index $1$ is _significantly_\ndifferent to the separation between a bit at index $7$ and index $8$ in both\nrepresentations, despite their absolute difference being identical. Thus, we\nbelieve that these two variants are not viable, as they are not only confusing\nfrom the point of view of behaviour, they would also make implementation of\nfuture operations (such as shifts or rotations) significantly harder to both do,\nand also reason about. Thus, only the bit-flip variant, as well as our choice,\nremain contenders.\n\nThe second notion is _most-significant-first conversion agreement_. This notion\nrefers to the [CIP-121 concept of the same name][cip-121-big-endian], and\nensures that (at least for the most-significant-first arrangement), the\nfollowing workflow doesn't produce unexpected results:\n\n1. Convert a `BuiltinInteger` to `BuiltinByteString` using\n   `builtinIntegerToByteString` with the most-significant-first endianness\n   argument.\n2. Manipulate the bits of the result of step 1 using the operations specified \n   here.\n3. Convert the result of step 2 back to a `BuiltinInteger` using\n   `builtinByteStringToInteger` with the most-significant-first endianness\n   argument.\n\nThis workflow is directly relevant to Case 2. The Argon2 family of hashes use\ncertain inputs (which happen to be numbers) both as numbers (meaning, for\narithmetic operatons) and also as blocks of binary (specifically for XOR). This\nis not unique to Argon2, or even hashing, as a range of operations (especially\nin cryptographic applications) use similar approaches, whether for performance,\nsemantics or both. In such cases, users of our primitives (both logical and\nconversion) must be confident that their changes 'translate' in the way they\nexpect between these two 'views' of the data. \n\nThe choice of most-significant-first as the arrangement that we must agree with\nseems somewhat arbitrary at a glance, for two reasons: firstly, it's not clear\nwhy we must pick a single arrangement to be consistent with; secondly, the\nreasoning for the choice of most-significant-first over most-significant-last \nas the arrangement to agree with isn't immediately apparent. To see why this is\nthe only choice that we consider reasonable, we first observe that, according \nto the definition of the bit indexing scheme given [in\nthe corresponding section](#bit-indexing-scheme), as well as the corresponding\ndefinition for the bit-flip variant, we view a `BuiltinByteString` of length $n$\nas a binary natural number with exactly $8n$ digits, and the value at index $i$\ncorresponds to the digits whose place value is either $2^i$ (for the bit-flip\nvariant), or $2^{8n - i - 1}$ (for our chosen method). Put another way, under\nthe specification for the bit-flip variant, the least significant binary digit\nis first, whereas in our chosen specification, the least significant binary\ndigit is last. CIP-121's conversion primitives mirror this reasoning: the\nmost-significant-first arrangement corresponds to our chosen method, while the\nmost-significant-last arrangement corresponds to the bit-flip variant instead.\nThe difference is the digit value: for us, the digit value is (effectively) 2,\nwhile for CIP-121's conversion primitives, it is 256 instead.\n\nWe also observe that, when we index a `BuiltinByteString`'s _bytes_, we get back\na `BuiltinInteger`, whic has a numerical value as a natural number in the range\n$[0, 255]$. Putting these two observations together, we consider it sensible\nthat, given a non-empty `BuiltinByteString`, if we were to get the values at bit\nindexes $0$ through $7$, then sum their corresponding place values (treating\nclear bits as $0$ and set bits as the appropriate place value), we should get\nthe same result as indexing whichever byte those bits came from.\n\nConsider the `BuiltinByteString` whose only byte is $42$, whose representation \nis as follows:\n\n```\n| Byte index | 0        |\n|------------|----------|\n| Byte       | 00101010 |\n```\n\nWe note that, if we index this `BuiltinByteString` at byte position $0$, we get\nback the answer $42$. Furthermore, if we use `builtinByteStringToInteger` from\nCIP-121 with such a `BuiltinByteString`, we get the result $42$ as well,\nregardless of the endianness argument we choose.\n\nUnder the bit-flip variant, the bit indexes of this `BuiltinByteString` would be\nas follows:\n\n```\n| Byte index | 0                             |\n|------------|-------------------------------|\n| Byte       | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |\n|------------|-------------------------------|\n| Bit index  | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |\n```\n\nHowever, we immediately see a problem: under this indexing scheme, the $2^2 = 4$\nplace value is $1$, which would suggest that in the binary representation of\n$42$, the corresponding digit is also $1$. However, this is not the case. Under\nour scheme of choice however, we get the correct answer:\n\n```\n| Byte index | 0                             |\n|------------|-------------------------------|\n| Byte       | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |\n|------------|-------------------------------|\n| Bit index  | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |\n```\n\nHere, the $4$ place value is correctly $0$. This demonstrates that of the two\nindexing scheme possibilities that preserve index locality, only one can be\nconsistent with _any_ choice of byte arrangement, whether most-significant-first\nor most-significant-last: the one we chose. This implies that we cannot be\nconsistent with both arrangements while also preserving index locality.\n\nLet us now consider a larger example `BuiltinByteString`:\n\n```\n| Byte index | 0        | 1        |\n|------------|----------|----------|\n| Byte       | 00101010 | 11011011 |\n```\n\nThis would produce two different results when converted with\n`builtinByteStringToInteger`, depending on the choice of endianness argument:\n\n* For the most-significant-first arrangement, the result is $42 * 256 + 223 =\n  10975$.\n* For the most-significant-last arrangement, the result is $223 * 256 + 42 =\n  57130$.\n\nThese have the following 'breakdowns' in base-2:\n\n* $10975 = 8096 + 2048 + 512 + 256 + 32 + 16 + 8 + 4 + 2 + 1 = 2^13 + 2^11 + 2^9 + 2^8 + 2^5 + 2^4 + 2^3 + 2^2 + 2^1 + 2^0$\n* $57130 = 32768 + 16386 + 4096 + 2048 + 1024 + 512 + 256 + 32 + 8 + 2 = 2^15 + 2^14 + 2^12 + 2^11 + 2^10 + 2^9 + 2^8 + 2^5 + 2^3 + 2^1$\n\nUnder the bit-flip variant, the bit indexes of this `BuiltinByteString` would be\nas follows:\n\n```\n| Byte index | 0                             | 1                                   |\n|------------|-------------------------------|-------------------------------------|\n| Byte       | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 1 | 0  | 1  | 1  | 0  | 1  | 1  |\n|------------|-------------------------------|-------------------------------------|\n| Bit index  | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |\n```\n\nWe immediately see a problem, as in this representation, it suggests that the\n$2^1 = 2$ place value has zero digit value. This is true of _neither_ $10975$\nnor $57130$'s base-2 forms, which have the $2$ place value with a $1$ digit\nvalue. This suggests that the bit-flip variant cannot agree with _either_ choice\nof arrangement in general.\n\nHowever, if we view the bit indexes using our chosen scheme:\n\n```\n| Byte index | 0                                   | 1                             |\n|------------|-------------------------------------|-------------------------------|\n| Byte       | 0  | 0  | 1  | 0  | 1  | 0  | 1 | 0 | 1 | 1 | 0 | 1 | 1 | 0 | 1 | 1 |\n|------------|-------------------------------------|-------------------------------|\n| Bit index  | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |\n```\n\nthe $2$ place value is correctly shown as having a digit value of 1. \n\nCombining these observations, we note that, assuming we value index locality,\nchoosing our scheme gives us consistency with the most-significant-first\narrangement, as well as consistency with byte indexing digit values, but\nchoosing the bit-flip variant gives us _neither_. As we need both index locality\n_and_ consistency with at least one arrangement, our choice is the correct one.\nThe fact that we also get byte indexing digit values being consistent is another\nreason for our choice.\n\n### Padding versus truncation\n\nFor the operations defined in this CIP taking two `BuiltinByteString` arguments\n(that is, `bitwiseLogicalAnd`, `bitwiseLogicalOr`, and `bitwiseLogicalXor`),\nwhen the two arguments have identical lengths, the semantics are natural,\nmirroring the corresponding operations on the \n[Boolean algebra][boolean-algebra-2] $\\textbf{2}^{8n}$, where $n$ is the length \nof either argument in bytes. When the arguments do _not_ have matching lengths,\nhowever, the situation becomes more complex, as there are several ways in which\nwe could define these operations. The most natural possibilities are as follows;\nwe repeat some of the definitions used [in the corresponding\nsection](#padding-versus-truncation-semantics).\n\n* Extend the shorter argument with the identity element (all-1s for\n  `bitwiseLogicalAnd`, all-0s otherwise) to match the length of the longer argument,\n  then perform the operation as if on matching-length arguments. We call this\n  _padding semantics_.\n* Ignore the bytes of the longer argument whose indexes would not be valid for\n  the shorter argument, then perform the operation as if on matching-length\n  arguments. We call this _truncation semantics_.\n* Fail with an error whenever argument lengths don't match. We call this\n  _match semantics_.\n\nFurthermore, for both padding and truncation semantics, we can choose to pad (or\ntruncate) _low_ index bytes or _high_ index bytes. To illustrate the difference,\nconsider the two `BuiltinByteString`s (written as arrays of bytes for\nsimplicity) `[0xFF, 0x0F, 0x00]` and `[0x8F, 0x99]`. Under padding semantics,\npadding low index bytes would give us `[0x00, 0x8F, 0x99]` (or `[0xFF, 0x8F,\n0x99]` depending on operation), while padding high index bytes would give us\n`[0x8F, 0x99, 0x00]` (or `[0x8F, 0x99, 0xFF]` depending on operation). Under\ntruncation semantics, truncating low index bytes would give us `[0x0F, 0x00]`,\nwhile truncating high index bytes would give us `[0xFF, 0x0F]`.\n\nIt is not a priori clear which of these we should choose: they are subject to\ndifferent laws (as evidenced by the [corresponding\nsection](#laws-and-examples)), none of which are strict supersets of each other\n(at least not for _all_ inputs possible). While [CIP-58][cip-58] chose match\nsemantics, we believe this was not the correct decision: we use Case 1 to\njustify the benefit of having other semantics described above available.\n\nConsider the following operation: given a bound $k$, a 'direction' (larger or\nsmaller), and an integer set, remove all elements indicates by the direction and\n$k$ (that is, either smaller than $k$ or larger than $k$, as indicated by the\ndirection). This could be done using a `bitwiseLogicalAnd` and a mask. However,\nunder match semantics, this mask would have to have a length equal to the\ninteger set representation; under padding semantics, the mask would potentially\nonly need $\\Theta(k)$ length, depending on direction. This is noteworthy, as\npadding the mask would require an additional copy operation, only to produce a\nvalue that would be discarded immediately.\n\nConsider instead the following operation: given two integer sets with different\n(upper) bounds, take their intersection, producing an integer set whose size is\nthe minimum of the two. This can once again be done using `bitwiseLogicalAnd`,\nbut under match semantics (or padding semantics for that matter), we would first\nhave to slice the longer argument, while under truncation semantics, we wouldn't\nneed to.\n\nMatch semantics can be useful for Case 1 as well. Consider the case that a \nrepresentation of an integer set is supplied as an\ninput datum (in its `Data` encoding). In order to deserialize it, we need to\nverify at least whether it has the right length in bytes to represent an integer\nset with a given bound. Under padding or truncation semantics, we would have to\ncheck this at deserialization time; under exact match semantics, provided we\nwere sure that at least one argument is of a known size, we could simply perform\nthe necessary operations and let the match semantics error if given something\ninappropriate.\n\nIt is also worth noting that truncation semantics are well-established in the\nHaskell ecosystem. Viewed another way, all of the operations under discussion in\nthis sections are specialized versions of the `zipWith` operation; Haskell\nlibraries provide this type of operation for a range of linear collections,\nincluding lists, `Vector`s, and mostly notably, `ByteString`s. In all of these\ncases, truncation semantics are what is implemented; it would be surprising to\ndevelopers coming from Haskell to find that they have to do additional work to\nreplicate them in Plutus. While we don't anticipate direct use of Plutus Core\nprimitives by developers (although this is not an unheard-of case), we should\nenable library authors to build familiar APIs _on top of_ Plutus Core\nprimitives, which suggests truncation semantics should be available, at least as\nan option.\n\nAll the above suggests that no _single_ choice of semantics will satisfy all\nreasonable needs, if only from the point of view of efficiency. This suggests,\nmuch as for [CIP-121 primitives][conversion-cip] and endianness issues, that\nthe primitive should allow a choice in what semantics get used for any given\ncall. Ideally, we would allow a choice of any of the three options described\nabove (along with a choice of low or high index padding or truncation); \nhowever, this is awkward to do in Plutus Core. While the choice between\n_two_ options is straightforward (pass a `BuiltinBool`), the choice between\nmore than this number would require something like a `BuiltinInteger` argument\nwith 'designated values' ('0 means match', '1 means low-index padding', etc).\nThis is not ideal, as they involve additional checks, argument redundancy, or\nboth. In light of this, we made the following decisions:\n\n1. We would choose only two of the three semantics, and have this choice\n   controlled for any given call be controlled by a `BuiltinBool` flag; and\n2. For padding or truncation semantics, we would _always_ use either low or high\n   index padding (or truncation).\n\nThis leads naturally to two questions: which of the three semantics above we can\nafford to exclude, and whether low or high index padding should be chosen. We\nbelieve that the correct choices are to exclude match semantics, and to use\nhigh index padding and truncation, for several reasons. \n\nFirstly, we can simulate\nmatch semantics with either padding or truncation semantics, together with a\nlength check. While we could also simulate padding semantics via match semantics\nsimilarly, the amount of effort (both developer and computational) required is\nsignificantly more in that case: a length check is a constant-time operation,\nwhile manually padding is linear at best (and even then, it requires operations\nonly this CIP provides, as it would be quadratic otherwise), and on top of that,\nmanual padding is much fiddlier and easier to get wrong. \n\nSecondly, truncation semantics are common enough in Haskell that we believe\nexcluding them as an option is both surprising and wrong. Any developer familiar\nwith Haskell has interacted with various `zipWith` operations, and having our\nprimitives behave differently to this at minimum creates friction for\nimplementers of higher-level abstractions atop the primitives in this CIP. While\nHaskellers are not exclusive users of Plutus primitives (directly or not), there\nare definitely enough of them that _not_ having truncation semantics available\nwould create a lot of unnecessary friction.\n\nThirdly, outside of error checking, match semantics give few benefits,\nperformance or otherwise. The examples above demonstrate cases where padding and\ntruncation semantics lead to better performance, less fiddly implementations, or\nboth: finding such a case for match semantics outside of error checking is\ndifficult at best.\n\nThis combination of reasoning leads us to consider padding and truncation as the\ntwo semantics we should retain, and this guided our implementation choices\naccordingly. With regard to padding (or truncating) low or high indexes, given\nthat we pad (or truncate) whole bytes by necessity, it makes the corresponding\noperations (effectively) operate over bytes, or rather, they view\n`BuiltinByteString`s as linear collections of bytes, rather than bits. When\nviewed this way, the `zipWith` analogy with Haskell suggests that truncating\nhigh is the correct choice: truncating low would be quite surprising to a\nHaskeller familiar with how `zipWith`-style operations behave. Furthermore, as\nhaving padding low and truncating high would be confusing (and arguably quite\nstrange), padding high seems like the correct choice. Thus, we decided to both\npad and truncate high in light of this. \n\n### Bit setting\n\n`writeBits` in our description takes a change list argument, allowing\nchanging multiple bits at once. This is an added complexity, and an argument can\nbe made that something similar to the following operation would be sufficient:\n\n```haskell\nwriteBit :: BuiltinByteString -> BuiltinInteger -> BuiltinBool ->\nBuiltinByteString\n```\n\nEssentially, `writeBit bs i v` would be equivalent to `writeBits bs\n[(i, v)]` as currently defined. This was the choice made by [CIP-58][cip-58],\nwith the consideration of simplicity in mind. \n\nAt the same time, due to the immutability semantics of Plutus Core, each time\n`writeBit` would be called, we would have to copy its `BuiltinByteString` \nargument. Thus, a sequence of $k$ `setBit` calls in a fold over a\n`BuiltinByteString` of length $n$ would require $\\Theta(nk)$ time and\n$\\Theta(nk)$ space. Meanwhile, if we instead used `writeBits`, the time\ndrops to $\\Theta(n + k)$ and the space to $\\Theta(n)$, which is a non-trivial\nimprovement. While we cannot avoid the worst-case copying behaviour of\n`setBit` (if we have a critical path of read-write dependencies of length\n$k$, for example), and 'list packing' carries some cost, we have\n[benchmarks][benchmarks-bits] that show not only that this 'packing cost' is\nessentially zero, but that for `BuiltinByteString`s of 30 bytes or fewer,\ncopying completely overwhelms the work required to modify the bits specified in\nthe change list argument. This alone is good evidence for having `writeBits` instead;\nindeed, there is prior art for doing this [in the `vector` library][vector], for\nthe exact reasons we give here.\n\nThe argument could also be made whether this design should be extended to other\nprimitive operations in this CIP which both take `BuiltinByteString` arguments\nand also produce `BuiltinByteString` results. We believe that this is not as\njustified as in the `writeBits` case, for several reasons. Firstly, for\n`bitwiseLogicalComplement`, it's not clear what benefit this would have at\nall: the only possible signature such an operation would have is\n`[BuiltinByteString] -> [BuiltinByteString]`, which in effect would be a\nspecialized form of mapping. While an argument could be made for a _general_\nform of mapping as a Plutus Core primitive, it wouldn't be reasonable for an\noperation like this to be considered for such.\n\nSecondly, the performance benefits of such an operation aren't nearly as \nsignificant in theory, and likely wouldn't be in practice either. Consider \nthis hypothetical operation (with fold semantics):\n\n```haskell\nbitwiseLogicalXors :: BuiltinBool -> [BuiltinByteString] -> BuiltinByteString\n```\n\nSimulating this operation as a fold using `bitwiseLogicalXor`, in the worst\ncase, irrespective of padding or truncation semantics, requires $\\Theta(nk)$\ntime and space, where $n$ is the size of each `BuiltinByteString` in the\nargument list, and $k$ is the length of the argument list itself. Using\n`bitwiseLogicalXors` instead would reduce the space required to $\\Theta(n)$, \nbut would not affect the time complexity at all. \n\nLastly, it is questionable whether 'bulk' operations like `bitwiseLogicalXors`\nabove would see as much use as `writeBits`. In the context of Case 1,\n`bitwiseLogicalXors` corresponds to taking the symmetric difference of multiple\ninteger sets; it seems unlikely that the number of sets we'd want to do this\nwith would frequently be higher than 2. However, in the same context,\n`writeBits` corresponds to constructing an integer set given a list of\nmembers (or, for that matter, _non_-members): this is an operation that is both\nrequired by the case description, and also much more likely to be used often.\n\nOn the basis of the above, we believe that choosing to implement\n`writeBits` as a 'bulk' operation, but to leave others as 'singular' is the\nright choice.\n\n## Path to Active\n\n### Acceptance Criteria\n\nWe consider the following criteria to be essential for acceptance:\n\n* A proof-of-concept implementation of the operations specified in this\n  document, outside of the Plutus source tree. The implementation must be in\n  GHC Haskell, without relying on the FFI.\n* The proof-of-concept implementation must have tests, demonstrating that it \n  behaves as the specification requires.\n* The proof-of-concept implementation must demonstrate that it will \n  successfully build, and pass its tests, using all GHC versions currently \n  usable to build Plutus (8.10, 9.2 and 9.6 at the time of writing), across all \n  [Tier 1][tier-1-ghc] platforms.\n\nIdeally, the implementation should also demonstrate its performance \ncharacteristics by well-designed benchmarks.\n\n- [x] Included within a major haskell cardano-node release\n  - https://github.com/IntersectMBO/cardano-node/releases/tag/10.1.1  \n- [x] Enabled on Cardano mainnet via a hardfork\n  - Enabled by Plomin hardfork\n\n### Implementation Plan\n\nMLabs has begun the [implementation of the proof-of-concept][mlabs-impl] as \nrequired in the acceptance criteria. Upon completion, we will send a pull \nrequest to Plutus with the implementation of the primitives for Plutus \nCore, mirroring the proof-of-concept.\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0).\n\n[mlabs-impl]: https://github.com/mlabs-haskell/plutus-integer-bytestring\n[tier-1-ghc]: https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms#tier-1-platforms\n[special-semigroups]: https://en.wikipedia.org/wiki/Special_classes_of_semigroups\n[commutative-monoid]: https://en.wikipedia.org/wiki/Monoid#Commutative_monoid\n[absorbing-element]: https://en.wikipedia.org/wiki/Zero_element#Absorbing_elements\n[semilattice]: https://en.wikipedia.org/wiki/Semilattice\n[distributive]: https://en.wikipedia.org/wiki/Distributive_property\n[lattice]: https://en.wikipedia.org/wiki/Lattice_(order)\n[de-morgan]: https://en.wikipedia.org/wiki/De_Morgan%27s_laws\n[lens-laws]: https://oleg.fi/gists/posts/2017-04-18-glassery.html#laws:lens\n[monoid-homomorphism]: https://en.wikipedia.org/wiki/Monoid#Monoid_homomorphisms\n[succinct-data-structures]: https://en.wikipedia.org/wiki/Succinct_data_structure\n[adjacency-matrix]: https://en.wikipedia.org/wiki/Adjacency_matrix\n[binary-matrix]: https://en.wikipedia.org/wiki/Logical_matrix\n[go-binary-matrix]: https://senseis.xmp.net/?BinMatrix\n[finite-state-machine-4vl]: https://en.wikipedia.org/wiki/Four-valued_logic#Matrix_machine\n[bitvector-apps]: https://en.wikipedia.org/wiki/Bit_array#Applications\n[bitmap-index-compression]: https://en.wikipedia.org/wiki/Bitmap_index#Compression\n[cip-58]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0058\n[croaring]: https://github.com/RoaringBitmap/CRoaring\n[too-many-ways-1]: https://fgiesen.wordpress.com/2018/02/19/reading-bits-in-far-too-many-ways-part-1\n[conversion-cip]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0121/README.md\n[benchmarks-bits]: https://github.com/mlabs-haskell/plutus-integer-bytestring/blob/main/bench/naive/Main.hs#L74-L83\n[vector]: https://hackage.haskell.org/package/vector-0.13.1.0/docs/Data-Vector.html#v:-47--47-\n[boolean-algebra-2]: https://en.wikipedia.org/wiki/Two-element_Boolean_algebra\n[hashing]: https://en.wikipedia.org/wiki/Hash_function\n[sha256]: https://en.wikipedia.org/wiki/Secure_Hash_Algorithms\n[blake2b]: https://en.wikipedia.org/wiki/BLAKE_(hash_function)\n[argon2]: https://en.wikipedia.org/wiki/Argon2\n[xor-crypto]: https://en.wikipedia.org/wiki/Exclusive_or#Bitwise_operation\n[cip-121]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0121/README.md\n[cip-121-big-endian]:https://github.com/cardano-foundation/CIPs/blob/master/CIP-0121/README.md/#representation\n[bitwise-and]: https://en.wikipedia.org/wiki/Bitwise_operation#AND\n[bitwise-or]: https://en.wikipedia.org/wiki/Bitwise_operation#OR\n[bitwise-xor]: https://en.wikipedia.org/wiki/Bitwise_operation#XOR\n"
  },
  {
    "path": "CIP-0123/README.md",
    "content": "---\nCIP: 123\nTitle: Bitwise operations over BuiltinByteString\nCategory: Plutus\nStatus: Active\nAuthors:\n    - Koz Ross <koz@mlabs.city>\nImplementors: \n    - Koz Ross <koz@mlabs.city>\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/825\nCreated: 2024-05-16\nLicense: Apache-2.0\n---\n\n## Abstract\n\nWe describe the semantics of a set of bitwise operations for Plutus\n`BuiltinByteString`s. Specifically, we provide descriptions for:\n\n* Bit shifts and rotations\n* Counting the number of set bits (`popcount`)\n* Finding the first set bit\n\nWe base our work on similar operations described in [CIP-58][cip-58], but use\nthe bit indexing scheme from [the logical operations cip][logic-cip] for the\nsemantics. This is intended as follow-on work from both of these.\n\n## Motivation: why is this CIP necessary?\n\nBitwise operations, both over fixed-width and variable-width blocks of bits, \nhave a range of uses. Indeed, we have already proposed [CIP-122][logic-cip],\nwith some example cases, and a range of primitive operations on\n`BuiltinByteString`s designed to allow bitwise operations in the service of\nthose example cases, as well as many others. These operations form a core of\nfunctionality, which is important and necessary, but not complete. We believe\nthat the operations we describe in this CIP form a useful 'completion' of the\nwork in CIP-122, based on similar work done in the [earlier CIP-58][cip-58].\n\nTo demonstrate why our proposed operations are useful, we re-use the cases\nprovided in the [CIP-122][logic-cip], and show why the operations\nwe describe would be beneficial.\n\n### Case 1: integer set\n\nFor integer sets, the [previous description][integer-set] lacks two important,\nand useful, operations:\n\n* Given an integer set, return its cardinality; and\n* Given an integer set, return its minimal member (or specify it is empty).\n\nThese operations have a range of uses. The first corresponds to the notion of\n[Hamming weight][hamming-weight], which can be used for operations ranging from\nrepresenting boards in chess games to exponentiation by squaring to succinct\ndata structures. Together with bitwise XOR, it can also compute the [Hamming\ndistance][hamming-distance]. The second operation also has a [range of\nuses][ffs-uses], ranging from succinct priority queues to integer normalization.\nIt is also useful for [rank-select dictionaries][rank-select-dictionary], a\nsuccinct structure that can act as the basis of a range of others, such as\ndictionaries, multisets and trees of different arity.\n\nIn all of the above, these operations need to be implemented efficiently to be\nuseful. While we could use only bit reading to perform all of these, it is\nextremely inefficient: given an input of length $n$, assuming that any bit\ndistribution is equally probable, we need $\\Theta(8 \\cdot n)$ time in the\naverage case. While it is\nimpossible to do both of these operations in sub-linear time in general, the\nlarge constant factors this imposes (as well as the overhead of looping over\n_bit_ indexes) is a cost we can ill afford on-chain, especially if the goal is\nto use these operations as 'building blocks' for something like a data\nstructure.\n\n### Case 2: hashing\n\nIn our [previously-described][hashing] case, we stated what operations we would\nneed for the Argon2 family of hashes specifically. However, Argon2 has a\nspecific advantage in that the number of operations it requires are both\nrelatively few, and the most complex of which (BLAKE2b hashing) already exists\nin Plutus Core as a primitive. However, other hash functions (and indeed, many\nother cryptographic primitives) rely on two other important instructions: bit\nshifts and bit rotations. As an example, consider SHA512, which is an important\ncomponent in several cryptographic protocols (including Ed25519 signature\nverification): its implementation requires both shifts and rotations to work. \n\nLike with Case 1, we can theoretically simulate both rotations and shifts using\na combination of bit reads and bit writes to an empty `BuiltinByteString`.\nHowever, the cost of this is extreme: we would need to produce a list of\nindex-value pairs of length equal to the Hamming weight of the input, only to\nthen immediately discard it! To put this into some perspective, for an 8-byte\ninput, performing a rotation involves allocating an expected 32 index-value\npairs, using _significantly_ more memory than the result. On-chain, we can't\nreally afford this cost, especially in an operation intended to be used as part\nof larger constructions (as would be necessary here).\n\n## Specification\n\nWe describe the proposed operations in several stages. First, we give an\noverview of the proposed operations' signatures and costings; second, we\ndescribe the semantics of each proposed operation in detail, as well as some\nexamples. Lastly, we provide laws that any implementation of the proposed\noperations should obey.\n\nThroughout, we make use of the [bit indexing scheme][bit-indexing-scheme]\ndescribed in a CIP-122. We also re-use the notation $x[i]$ to refer to the value\nof at bit index $i$ of $x$, and the notation $x\\\\{i\\\\}$ to refer to the byte at\nbyte index $i$ of $x$: both are specified in CIP-122.\n\n### Operation semantics\n\nOur proposed operations will have the following signatures:\n\n* ``bitwiseShift :: BuiltinByteString -> BuiltinInteger -> BuiltinByteString``\n* ``bitwiseRotate :: BuiltinByteString -> BuiltinInteger -> BuiltinByteString``\n* ``countSetBits :: BuiltinByteString -> BuiltinInteger``\n* ``findFirstSetBit :: BuiltinByteString -> BuiltinInteger``\n\nWe assume the following costing, for both memory and execution time:\n\n| Operation | Execution time cost | Memory cost |\n|-----------|---------------------|-------------|\n|`bitwiseShift`| Linear in the `BuiltinByteString` argument | As execution time|\n|`bitwiseRotate` | Linear in the `BuiltinByteString` argument | As execution time |\n|`countSetBits` | Linear in the argument | Constant |\n|`findFirstSetBit` | Linear in the argument | Constant |\n\n#### `bitwiseShift`\n\n`bitwiseShift` takes two arguments; we name and describe them below.\n\n1. The `BuiltinByteString` to be shifted. This is the _data argument_.\n2. The shift, whose sign indicates direction and whose magnitude indicates the\n   size of the shift. This is the _shift argument_, and has type\n   `BuiltinInteger`.\n\nLet $b$ refer to the data argument, whose length in bytes is $n$, and let $i$\nrefer to the shift argument. Let the result of `bitwiseShift` called with $b$\nand $i$ be $b_r$, also of length $n$. \n\nFor all $j \\in 0, 1, \\ldots 8 \\cdot n - 1$, we have\n\n$$\nb_r[j] = \\begin{cases}\n         b[j - i] & \\text{if } j - i \\in 0, 1, \\ldots 8 \\cdot n - 1\\\\\n         0 & \\text{otherwise} \\\\\n         \\end{cases}\n$$\n\nSome examples of the intended behaviour of `bitwiseShift` follow. For\nbrevity, we write `BuiltinByteString` literals as lists of hexadecimal values.\n\n```\n-- Shifting the empty bytestring does nothing\nbitwiseShift [] 3 => []\n-- Regardless of direction\nbitwiseShift [] (-3) => []\n-- Positive shifts move bits to higher indexes, cutting off high indexes and\n-- filling low ones with zeroes\nbitwiseShift [0xEB, 0xFC] 5 => [0x7F, 0x80]\n-- Negative shifts move bits to lower indexes, cutting off low indexes and\n-- filling high ones with zeroes\nbitwiseShift [0xEB, 0xFC] (-5) => [0x07, 0x5F]\n-- Shifting by the total number of bits or more clears all bytes\nbitwiseShift [0xEB, 0xFC] 16 => [0x00, 0x00]\n-- Regardless of direction\nbitwiseShift [0xEB, 0xFC] (-16) => [0x00, 0x00]\n```\n\n#### `bitwiseRotate`\n\n`bitwiseRotate` takes two arguments; we name and describe them below.\n\n1. The `BuiltinByteString` to be rotated. This is the _data argument_.\n2. The rotation, whose sign indicates direction and whose magnitude indicates \n   the size of the rotation. This is the _rotation argument_, and has type\n   `BuiltinInteger`.\n\nLet $b$ refer to the data argument, whose length in bytes is $n$, and let $i$\nrefer to the rotation argument. Let the result of `bitwiseRotate` called with $b$\nand $i$ be $b_r$, also of length $n$. \n\nFor all $j \\in 0, 1, \\ldots 8 \\cdot n - 1$, we have \n$b_r = b[(j - i) \\text{ } \\mathrm{mod} \\text { } (8 \\cdot n)]$.\n\nSome examples of the intended behaviour of `bitwiseRotate` follow. For\nbrevity, we write `BuiltinByteString` literals as lists of hexadecimal values.\n\n```\n-- Rotating the empty bytestring does nothing\nbitwiseRotate [] 3 => []\n-- Regardless of direction\nbitwiseRotate [] (-1) => []\n-- Positive rotations move bits to higher indexes, 'wrapping around' for high\n-- indexes into low indexes\nbitwiseRotate [0xEB, 0xFC] 5 => [0x7F, 0x9D]\n-- Negative rotations move bits to lower indexes, 'wrapping around' for low\n-- indexes into high indexes\nbitwiseRotate [0xEB, 0xFC] (-5) => [0xE7, 0x5F]\n-- Rotation by the total number of bits does nothing\nbitwiseRotate [0xEB, 0xFC] 16 => [0xEB, 0xFC]\n-- Regardless of direction\nbitwiseRotate [0xEB, 0xFC] (-16) => [0xEB, 0xFC]\n-- Rotation by more than the total number of bits is the same as the remainder\n-- after division by number of bits\nbitwiseRotate [0xEB, 0xFC] 21 =>[0x7F, 0x9D]\n-- Regardless of direction, preserving sign\nbitwiseRotate [0xEB, 0xFC] (-21) => [0xE7, 0x5F]\n```\n\n#### `countSetBits`\n\nLet $b$ refer to `countSetBits`' only argument, whose length in bytes is $n$,\nand let $r$ be the result of calling `countSetBits` on $b$. Then we have\n\n$$\nr = \\sum_{i=0}^{8 \\cdot n - 1} b[i]\n$$\n\nSome examples of the intended behaviour of `countSetBits` follow. For\nbrevity, we write `BuiltinByteString` literals as lists of hexadecimal values.\n\n```\n-- The empty bytestring has no set bits\ncountSetBits [] => 0\n-- Bytestrings with only zero bytes have no set bits\ncountSetBits [0x00, 0x00] => 0\n-- Set bits are counted regardless of where they are\ncountSetBits [0x01, 0x00] => 1\ncountSetBits [0x00, 0x01] => 1\n```\n\n#### `findFirstSetBit`\n\nLet $b$ refer to `findFirstSetBit`'s only argument, whose length in bytes is $n$,\nand let $r$ be the result of calling `findFirstSetBit` on $b$. Then we have the\nfollowing:\n\n1. $r \\in -1, 0, 1, \\ldots, 8 \\cdot n - 1$\n2. If for all $i \\in 0, 1, \\ldots n - 1$, $b\\\\{i\\\\} = \\texttt{0x00}$, then $r = -1$;\n   otherwise, $r > -1$.\n3. If $r > -1$, then $b[r] = 1$, and for all $i \\in 0, 1, \\ldots, r - 1$, $b[i]\n   = 0$.\n\nSome examples of the intended behaviour of `findFirstSetBit` follow. For\nbrevity, we write `BuiltinByteString` literals as lists of hexadecimal values.\n\n```\n-- The empty bytestring has no first set bit\nfindFirstSetBit [] => -1\n-- Bytestrings with only zero bytes have no first set bit\nfindFirstSetBit [0x00, 0x00] => -1\n-- Only the first set bit matters, regardless what comes after it\nfindFirstSetBit [0x00, 0x02] => 1\nfindFirstSetBit [0xFF, 0xF2] => 1\n```\n\n### Laws\n\nThroughout, we use `bitLen bs` to indicate the number of bits in `bs`; that is,\n`sizeOfByteString bs * 8`. We also make reference to [logical\noperations][logic-cip] from a previous CIP as part of specifying these laws.\n\n#### Shifts and rotations\n\nWe describe the laws for `bitwiseShift` and `bitwiseRotate` together, as they\nare similar. Firstly, we observe that `bitwiseShift` and `bitwiseRotate` both\nform a [monoid homomorphism][monoid-homomorphism] between natural number \naddition and function composition:\n\n```haskell\nbitwiseShift bs 0 = bitwiseRotate bs 0 = bs\n\nbitwiseShift bs (i + j) = bitwiseShift (bitwiseShift bs i) j\n\nbitwiseRotate bs (i + j) = bitwiseRotate (bitwiseRotate bs i) j\n```\n\nHowever, `bitwiseRotate`'s homomorphism is between _integer_ addition and\nfunction composition: namely, `i` and `j` in the above law are allowed to have\ndifferent signs. `bitwiseShift`'s composition law only holds if `i` and `j`\ndon't have opposite signs: that is, if they're either both non-negative or both\nnon-positive.\n\nShifts by more than the number of bits in the data argument produce an empty\n`BuiltinByteString`:\n\n```haskell\n-- n is non-negative\n\nbitwiseShift bs (bitLen bs + n) = \nbitwiseShift bs (- (bitLen bs + n)) = \nreplicateByteString (sizeOfByteString bs) 0x00\n```\n\nRotations, on the other hand, exhibit 'modular roll-over':\n\n```haskell\n-- n is non-negative\nbitwiseRotate bs (binLen bs + n) = bitwiseRotate bs n\n\nbitwiseRotate bs (- (bitLen bs + n)) = bitwiseRotate bs (- n)\n```\n\nShifts clear bits at low indexes if the shift argument is positive, and at high\nindexes if the shift argument is negative:\n\n```\n-- 0 < n < bitLen bs, and 0 <= i < n\nreadBit (bitwiseShift bs n) i = False\n\nreadBit (bitwiseShift bs (- n)) (bitLen bs - i - 1)  = False\n```\n\nRotations instead preserve all set and clear bits, but move them around:\n\n```\n-- 0 <= i < bitLen bs\nreadBit bs i = readBit (bitwiseRotate bs j) (modInteger (i + j) (bitLen bs))\n```\n\n#### `countSetBits`\n\n`countSetBits` forms a [monoid homomorphism][monoid-homomorphism] between\n`BuiltinByteString` concatenation and natural number addition:\n\n```haskell\ncountSetBits \"\" = 0\n\ncountSetBits (x <> y) = countSetBits x + countSetBits y\n```\n\n`countSetBits` also demonstrates that `bitwiseRotate` indeed preserves the\nnumber of set (and thus clear) bits:\n\n```haskell\ncountSetBits bs = countSetBits (bitwiseRotate bs i)\n```\n\nThere is also a relationship between the result of `countSetBits` on a given\nargument and its complement:\n\n```haskell\ncountSetBits bs = bitLen bs - countSetBits (bitwiseLogicalComplement bs)\n```\n\nFurthermore, `countSetBits` exhibits (or more precisely, gives evidence for) the\n[inclusion-exclusion principle][include-exclude] from combinatorics, but only\nunder truncation semantics:\n\n```haskell\ncountSetBits (bitwiseLogicalXor False x y) = countSetBits (bitwiseLogicalOr\nFalse x y) - countSetBits (bitwiseLogicalAnd False x y)\n```\n\nLastly, `countSetBits` has a relationship to bitwise XOR, regardless \nof semantics:\n\n```haskell\ncountSetBits (bitwiseLogicalXor semantics x x) = 0\n```\n\n#### `findFirstSetBit`\n\n`BuiltinByteString`s where every byte is the same (provided they are not empty)\nhave the same first bit as a singleton of that same byte:\n\n```haskell\n-- 0 <= w8 <= 255, n >= 1\nfindFirstSetBit (replicateByteString n w8) = \nfindFirstSetBit (replicateByteString 1 w8)\n```\n\nAdditionally, `findFirstSet` has a relationship to bitwise XOR, regardless of\nsemantics:\n\n```haskell\nfindFirstSetBit (bitwiseLogicalXor semantics x x) = -1\n```\n\nAny result of a `findFirstSetBit` operation that isn't `-1` gives a valid bit\nindex to a set bit, but any non-negative `BuiltinInteger` less than this will\ngive an index to a clear bit:\n\n```haskell\n-- bs is not all zero bytes or empty\nreadBit bs (findFirstSetBit bs) = True\n\n-- 0 <= i < findFirstSet bs\nreadBit bs i = False\n```\n\n## Rationale: how does this CIP achieve its goals?\n\nOur four operations, along with their semantics, fulfil the requirements of both\nour cases, and are law-abiding, familiar, consistent and straightforward to\nimplement. Furthermore, they relate directly to operations provided by\n[CIP-122][logic-cip], as well as being identical to the equivalent operations in\n[CIP-58][cip-58]. At the same time, some alternative choices could have been\nmade:\n\n* Not implementing these operations at all, instead requiring higher-level APIs\n  to implement them atop CIP-122 primitives;\n* Providing only some of these four operations;\n* Having `findFirstSetBit` return the bit length for an all-zero argument,\n  instead of `-1`;\n* Including a way of finding the _last_ set bit as well.\n\nWe discuss our choices with regards to all the above, and specify why we made\nthe choices that we did.\n\nWhile we chose to provide all of these operations as primitives, we could\ninstead have required higher-level APIs to provide these on the basis\nof [CIP-122][logic-cip] bit reads and writes. This is indeed possible:\n\n* `bitwiseShift` and `bitwiseRotate` is a loop over all bits in the data argument, \n  which is used to construct a change list that sets appropriate bits (with the \n  right offset), which then gets applied to a `BuiltinByteString` of the same\n  length as the data argument, but full of zero bytes.\n* `countSetBits` is a fold over all bit indexes, incrementing an accumulator\n  every time a set bit is found.\n* `findFirstSetBit` is a fold over all bit indexes, returning the first index\n  with a set bit, or (-1) if none can be found.\n\nHowever, especially for `bitwiseShift` and `bitwiseRotate`, this comes at\nsignificant cost. For shifts and rotations, we have to construct a change list\nargument whose length is proportional to the Hamming weight of the data\nargument. Assuming that all inputs are equally likely, this is proportional to\nthe bit length of the data argument: such a change list is likely significantly\nlarger than the result of the shift or rotation, making the memory cost of such\noperations far higher than it needs to be. Given the constraints on memory and\nexecution time on-chain, at minimum, these two operations would have to be\nprimitives to make them viable at all: Case 2-style implementations would have\nintolerably large memory costs otherwise, as such algorithms often make heavy\nuse of both shifts and rotations.\n\nThe case for `countSetBits` and `findFirstSetBit` is less clear here, as they\nwouldn't require nearly as much of a memory cost if implemented atop CIP-122\nprimitives using folds. However, the cost would still be significant:\n`countSetBits` requires looping over every bit index in the argument, and\n`findFirstSetBit` (again, assuming any bit distribution in an argument is\nequally probable) requires looping over about half this many. This would make\nthese operations unreasonable even over smaller inputs, which would make\napplications like rank-select dictionaries (which expect these operations to be\nfast and low-cost) unworkable. As succinct data structures are foremost in our\nminds when considering the current primitives, we believe it is important that\n`countSetBits` and `findFirstSetBit` are as efficient as they could be, hence\ntheir inclusion.\n\nWhen designing our operations, we tried to keep them familiar to Haskellers,\nnamely by having them behave like the similar operations from the `Bits` and\n`FiniteBits` type classes. In particular,\n`bitwiseShift` and `bitwiseRotate` act similarly given the same shift (or\nrotation) argument, as positive values shift left and negative ones shift \nright. The only exception is the choice for `findFirstSetBit` to return `-1`\nwhen no set bits are found, which runs counter to the way `countTrailingZeros`\nfrom `FiniteBits` works, which instead returns the bit length. This is also\ndifferent to how this operations [works in hardware][ctz]. Indeed, having\n`findFirstSetBit` work this way would not only be more familiar, it would also\nprovide additional laws:\n\n```haskell\n-- Not possible under our current definition\n-- bitLen is the bit length of the argument\n0 <= popcount bs <= bitLen bs - findFirstSet bs \n```\n\nUnder both definitions, the intent is the same: if the argument doesn't contain\nany set bits, produce an invalid index. The difference is that we choose to\nproduce a _negative_ invalid index, whereas the consensus is to produce a\n_non-negative_ invalid index instead. However, one task that is likely to come\nup frequently when using `findFirstSetBit` is checking whether the index we were\ngiven was valid or not (essentially, whether the argument has any nonzero bytes\nin it). Under our definition, all that would be required is\n\n```haskell\nlet found = findFirstSetBit bs\n  in if found < 0\n     then weMissed\n     else validIndex\n```\n\nThis is a cheap operation in Plutus Core, requiring only comparing against a\nconstant. However, if we used the more widely-used definition, we would instead\nhave to do this:\n\n```haskell\nlet found = findFirstSetBit bs\n    bitLen = 8 * sizeOfByteString bs\n  in if found >= bitLen\n     then weMissed\n     else validIndex\n```\n\nThis requires us to do considerably more work (finding the length of the\nargument, multiplying by 8, then compare against that result), and is also much\nmore prone to error: users have to remember to use a `>=` comparison, as well as\nto multiply the argument length by 8. This is less of an issue with\nimplementations of this operation in other languages, as their equivalent\noperations are designed for fixed-width arguments (indeed, `FiniteBits`\n_requires_ this), which makes their bit length a constant. In our case, this\nisn't as simple, as `BuiltinByteString`s have variable length, which would make\nthe cost described above unavoidable. Our solution is both more efficient and\nless error-prone: all a user needs to remember is that invalid indexes from\n`findFirstSetBit` are negative. On this basis, we decided to vary from\nconventional approaches.\n\nOne notable omission from our operators is the equivalent of counting _leading_\nzeroes: namely, an operation that would find the _last_ set bit. Typically, both\na count of leading _and_ trailing zeroes is provided in both hardware and\nsoftware: this is the case for `FiniteBits`, as well as [most hardware\nimplementations][ctz]. To relate this to our cases, specifically Case 1, this\nwould allow us to efficiently find the _largest_ element in an integer set. The\nreason we omit this operation is because, when compared with counting trailing\nzeroes, it is far less useful: while it can be used for computing fast integer\nsquare roots, it lacks many other uses. Counting trailing zeroes, on the other\nhand, is essential for rank-select dictionaries (specifically for the `select`\noperation), and also enables a range of other uses, which we have already\nmentioned. In order to limit the number of new primitives, we decided that\ncounting leading zeroes can be omitted for now. However, our design doesn't\npreclude such an operation from being added later if a use case for it is found\nto be useful.\n\n## Path to Active\n\n### Acceptance Criteria\n\nWe consider the following criteria to be essential for acceptance:\n\n* A proof-of-concept implementation of the operations specified in this \n  document, outside of the Plutus source tree. The implementation must be in \n  GHC Haskell, without relying on the FFI.\n* The proof-of-concept implementation must have tests, demonstrating that it \n  behaves as the specification requires.\n* The proof-of-concept implementation must demonstrate that it will \n  successfully build, and pass its tests, using all GHC versions currently \n  usable to build Plutus (8.10, 9.2 and 9.6 at the time of writing), across \n  all [Tier 1][tier-1] platforms.\n\nIdeally, the implementation should also demonstrate its performance \ncharacteristics by well-designed benchmarks.\n\n- [x] Included within a major haskell cardano-node release\n  - https://github.com/IntersectMBO/cardano-node/releases/tag/10.1.1  \n- [x] Enabled on Cardano mainnet via a hardfork\n  - Enabled by Plomin hardfork\n\n### Implementation Plan\n\nMLabs has begun the implementation of the [proof-of-concept][impl] as required in \nthe acceptance criteria. Upon completion, we will send a pull request to \nPlutus with the implementation of the primitives for Plutus Core, mirroring \nthe proof-of-concept.\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0).\n\n[tier-1]: https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms#tier-1-platforms\n[impl]: https://github.com/mlabs-haskell/plutus-integer-bytestring/tree/koz/milestone-2\n[bit-indexing-scheme]: https://github.com/mlabs-haskell/CIPs/blob/koz/logic-ops/CIP-XXX/CIP-XXX.md#bit-indexing-scheme\n[monoid-homomorphism]: https://en.wikipedia.org/wiki/Monoid#Monoid_homomorphisms\n[logic-cip]: https://github.com/mlabs-haskell/CIPs/blob/koz/logic-ops/CIP-0122/CIP-0122.md\n[include-exclude]: https://en.wikipedia.org/wiki/Inclusion%E2%80%93exclusion_principle\n[cip-58]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0058\n[integer-set]: https://github.com/mlabs-haskell/CIPs/blob/koz/logic-ops/CIP-XXX/CIP-XXX.md#case-1-integer-set\n[hamming-weight]: https://en.wikipedia.org/wiki/Hamming_weight#History_and_usage\n[hamming-distance]: https://en.wikipedia.org/wiki/Hamming_distance\n[ffs-uses]: https://en.wikipedia.org/wiki/Find_first_set#Applications\n[rank-select-dictionary]: https://en.wikipedia.org/wiki/Succinct_data_structure#Succinct_indexable_dictionaries\n[hashing]: https://github.com/mlabs-haskell/CIPs/blob/koz/logic-ops/CIP-XXX/CIP-XXX.md#case-2-hashing\n[ctz]: https://en.wikipedia.org/wiki/Find_first_set#Hardware_support\n"
  },
  {
    "path": "CIP-0124/README.md",
    "content": "---\nCIP: 124\nTitle: Extend token metadata for translations\nCategory: Metadata\nStatus: Proposed\nAuthors:\n  - Vito Melchionna <info@granadapool.com>\n  - Aaron Schmid <aaron@entropilabs.io>\n  - Carolina Isler @LaPetiteADA <lapetiteada@granadapool.com>\nImplementors: []\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/488\nCreated: 2023-03-19\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis proposal defines an additional property to the metadata standard for tokens (NFTs and FTs) to support text localization.\n\n## Motivation: why is this CIP necessary?\n\nCurrent token metadata only supports a single hardcoded language (mostly English), which limits the accessibility to a certain culture. To get closer to mass adoption, we need to bring down language barriers by extending the current standard to support translations. This is especially relevant for games, metaverse solutions, and RealFi use cases of NFTs.\n\n## Specification\n\nThis proposal follows the same specifications as [CIP-0025](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0025) (all versions).\n\nThe name of a culture consists of its [[ISO-639]](https://www.iso.org/standard/4767.html) language code with small letters and its [[ISO-3166]](https://www.iso.org/standard/63545.html) country/region code with capital letter separated by a dash \"-\". For instance, this proposal was written in \"en-US\": English with the US culture.\n\nThis convention is compatible with most operative systems (Linux and Windows) and widely used translation software.\n\n### General structure\n\nThe extended JSON metadata standard (CIP-25) allows flexible off- and on-chain string tranlations:\n\n```\n{\n  \"721\": {\n      \"<policy_id>\": {\n        \"<asset_name>\": {\n          \"name\": <string>,\n          \"image\": <uri | array>,\n          \"mediaType\": image/<mime_sub_type>,\n          \"description\": <string | array>,\n          \"files\": [{\n            \"name\": <string>,\n            \"mediaType\": <mime_type>,\n            \"src\": \"<uri | array>\"\n          }],\n\n          <other properties>\n\n          \"strings\": {\n              \"de-CH\": {\n                \"name\": <string in Swiss German>,\n                \"image\": <localized uri for Swiss German | array>,\n                \"description\": <string in Swiss German | array>\n                 <other localized properties>\n              },\n              \"it-IT\": {\n                \"name\": <string in Italian>,\n                \"image\": <localized uri for Italian | array>,\n                \"description\": <string in Italian | array>\n                <other localized properties>\n              },\n\n              <other languages and cultures>\n          }\n        },\n      },\n      \"version\": <version_id>,\n\n      <information about collection>\n\n      \"strings\": {\n              \"de-CH\": {\n                 <localized information about collection in de-CH>\n              },\n              \"it-IT\": {\n                 <localized information about collection in it-IT>\n              },\n\n              <other languages and cultures>\n      }\n  }\n}\n```\n\n### CDDL\n\nExtended versions of CIP-25\n\n[Version 1](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0124/cddl/version_1.cddl)\n\n[Version 2](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0124/cddl/version_2.cddl)\n\n- The new `strings` properties are optional, but if included, they must be valid JSON objects.\n  - The JSON object's keys and structure should match the same keys defined on the `policy_id` level for collection-specific information, or on the `asset_name` level for asset-specific properties, depending which attributes have translations. By doing so, the developer experience to access the localized strings significantly improves.\n\n## Rationale: how does this CIP achieve its goals?\n\n### Access valid localized properties of a token's metadata\n\nAfter fetching the policy's metadata, the procedure stays the same when looking up CIP-25 properties. However, to find culture-based translations, developers have to access the `strings` property located at the same level of the wanted information.\n\nIn case of the ´policy_id´ level (collections):\n\n1. Lookup the 721 key\n2. Lookup the Policy Id of the token\n3. Lookup the strings property\n4. Lookup for the culture\n5. You end up with the translated metadata for the policy\n\nIn case of the ´asset_name´ level (specific assets):\n\n1. Lookup the 721 key\n2. Lookup the Policy Id of the token\n3. Lookup the Asset name of the token\n4. Lookup the strings property\n5. Lookup for the culture\n6. You end up with the translated metadata for the specific asset\n\n> **Note**\n> The metadata's size is a constraint that should be considered as it could eventually push the boundaries of Cardano's transaction limits and scalability in terms of memory resources. The translations under the \"strings\" keys can be stored off-chain on an IPFS server using the proposed JSON structure. Then, the localized texts will be accessible through an URL, similarly to the \"image\" property.\n\n### Code example (JavaScript/TypeScript)\n\nTo access the localized strings from the fetched metadata for a native asset, we can simply access the JSON properties from the front end by using the user's selected culture:\n\n```\nconst response = await fetch(`${<BASE_URL>}/policyId/${<policyId>}`);\n\nconst metadata = response.json();\nconst policy = metadata[\"721\"][<policy_id>];\n\n// This check determines if the translations are stored off-chain on an IPFS url\nfunction isValidURL(url) {\n    try {\n        new URL(url);\n        return true;\n    } catch (e) {\n        return false;\n    }\n}\n\nfunction fetchTranslationStrings(url) {\n  const response = await fetch(url);\n  const translations = await response.json();\n  return translations || null;\n}\n\nfunction getPolicyString(policy, key, culture=\"en\") {\n    // translations are stored off-chain\n    if(isValidURL(policy[\"strings\"])) {\n      const translations = fetchTranslationStrings(policy[\"strings\"]);\n      if(translations) {\n        return translations[culture][key] || policy[key]; // default value (not localized)\n      }\n    }\n\n    // translations are stored on-chain\n    return policy[\"strings\"][culture][key]\n        ? policy[\"strings\"][culture][key]\n        : policy[key]; // default value (not localized)\n}\n\nfunction getAssetString(policy, asset, key, culture=\"en\") {\n    // translations are stored off-chain\n    if(isValidURL(policy[asset][\"strings\"])) {\n      const translations = fetchTranslationStrings(policy[asset][\"strings\"]);\n      if(translations) {\n        return translations[culture][key] || policy[asset][key]; // default value (not localized)\n      }\n    }\n\n    // translations are stored on-chain\n    return policy[asset][\"strings\"][culture][key]\n        ? policy[asset][\"strings\"][culture][key]\n        : policy[asset][key]; // default value (not localized)\n}\n\nconsole.log(`Default policy property: ${getPolicyString(policy, <policy_property>)}`);\nconsole.log(`Localized policy property: ${getPolicyString(policy, <policy_property>, \"it-IT\")}`);\nconsole.log(`Default asset name: ${getAssetString(policy, <asset_name>, \"name\")}`);\nconsole.log(`Localized asset name: ${getAssetString(policy, <asset_name>, \"name\", \"de-CH\")}`);\n```\n\n### Update metadata and translations\n\nFollowing the specifications stated on CIP-25, the strings can be only changed if the policy allows it.\n\n### Backward Compatibility\n\nThis metadata standard extension is backward compatible and it doesn't affect applications using the current standard. Dapps implementing the proposed extended standard can also default on the legacy values if the localized strings are not available on an asset.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Implementation is compliant with JSON conventions.\n- [x] Implementation is compliant with the [[ISO-639]](https://www.iso.org/standard/4767.html) standard for language code, and the [[ISO-3166]](https://www.iso.org/standard/63545.html) standard for country/region code.\n- [ ] Implementations and peer review verify that:\n  - [ ] NFT metadata standard extension covers all existing localization needs and use cases on web2.\n  - [ ] Access to localized strings is easy and logical from a coding perspective.\n\n### Implementation Plan\n\n- [ ] Propose this method in documentation and references for web3 developers.\n- [x] NMKR has supported this CIP with peer feedback.\n- [ ] NMKR has provided a pilot implementation of this localization method.\n\n## References\n\n- CIP about Media Token Metadata Standard [CIP-0025](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0025).\n- [[ISO-639]](https://www.iso.org/standard/4767.html) language code.\n- [[ISO-3166]](https://www.iso.org/standard/63545.html) country/region code.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0].\n\n[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n[Apache-2.0]: http://www.apache.org/licenses/LICENSE-2.0\n"
  },
  {
    "path": "CIP-0124/cddl/version_1.cddl",
    "content": "string = text .size (0..64)\n\npolicy_id = string\nasset_name = string ; utf-8\nculture_key = string ; utf-8\n\nfiles_details = \n  {\n    name : string,\n    mediaType : string,\n    src : string / [* string]\n  }\n\ntranslation_details = \n  {\n    name : string,\n    image : string,\n    description : string\n  }\n\nmetadata_details = \n  {\n    name : string,\n    image : string / [* string], \n    ? mediaType : string,\n    ? description : string / [* string],\n    ? files : [* files_details],\n    ? strings : { * culture_key => translation_details }\n  }\n\nlabel_metadata = { * policy_id => { * asset_name => metadata_details }, strings => { * culture_key => translation_details } }\n\nmetadata = { 721 : uint => label_metadata }"
  },
  {
    "path": "CIP-0124/cddl/version_2.cddl",
    "content": "string = text .size (0..64)\n\npolicy_id = bytes ; no longer in text\nasset_name = bytes ; no longer in text and utf-8\nculture_key = string ; utf-8\n\nfiles_details = \n  {\n    name : string,\n    mediaType : string,\n    src : string / [* string]\n  }\n\ntranslation_details = \n  {\n    name : string,\n    image : string,\n    description : string\n  }\n\nmetadata_details = \n  {\n    name : string,\n    image : string / [* string], \n    ? mediaType : string,\n    ? description : string / [* string],\n    ? files : [* files_details],\n    ? strings : { * culture_key => translation_details }\n  }\n\nlabel_metadata = { * policy_id => { * asset_name => metadata_details }, version: 2, strings => { * culture_key => translation_details } } ; version 2\n\nmetadata = { 721 : uint => label_metadata }"
  },
  {
    "path": "CIP-0127/README.md",
    "content": "---\nCIP: 127\nTitle: ripemd-160 hashing in Plutus Core\nStatus: Active\nCategory: Plutus\nAuthors:\n  - Tomasz Rybarczy <tomasz.rybarczyk@iohk.io>\nImplementors: []\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/826\nCreated: 2024-05-22\nLicense: Apache-2.0\n---\n\n## Abstract\nThis CIP follows closely the (CIP-0101)[^1] and proposes an extension of the current Plutus functions with another hashing primitive [`RIPEMD-160`](https://en.bitcoin.it/wiki/RIPEMD-160). Primary goal is to introduce compatibility with Bitcoin's cryptographic infrastructure.\n\n## Motivation: why is this CIP necessary?\n\nThe [integration](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0049/README.md) of the ECDSA and Schnorr signatures over the secp256k1 curve into Plutus was a significant step towards interoperability with Ethereum and Bitcoin ecosystems. However, full compatibility is still impossible due to the absence of the `RIPEMD-160` hashing algorithm in Plutus interpreter, which is a fundamental component of Bitcoin's cryptographic framework.\nMost of common addresses in Bitcoin are derived from double [hashing procedure](https://learnmeabitcoin.com/technical/cryptography/hash-function/#hash160) involving `SHA-256` followed by `RIPEMD-160` function:\n- [P2KH](https://learnmeabitcoin.com/technical/script/p2pkh/)\n- [P2WPKH](https://learnmeabitcoin.com/technical/script/p2wpkh/)\n- [P2SH](https://learnmeabitcoin.com/technical/script/p2sh/)\n- [P2WSH](https://learnmeabitcoin.com/technical/script/p2wsh/)\n\nAdding `RIPEMD-160` to Plutus would enhance the potential for cross-chain solutions between Cardano and Bitcoin blockchains and complements the set of primitives which we already have in that regard. It would allow for the verification of Bitcoin addresses and transactions on-chain. This addition enables also the verification of signed messages that identify the signer by the public key hash, which has not yet been witnessed on the Bitcoin blockchain.\n\nThe RIPEMD-160 is not only relevant to Bitcoin - other chains like [Cosmos](https://docs.cosmos.network/main/build/architecture/adr-028-public-key-addresses#legacy-public-key-addresses-dont-change) or [BNB](https://docs.bnbchain.org/docs/beaconchain/learn/accounts/#address) also use it for address generation.\n\n## Specification\nThis proposal aims to introduce a new built-in hash function `RIPEMD-160`.\n\nThis function will be developed following the [`RIP-160`](https://homes.esat.kuleuven.be/~bosselae/ripemd160/pdf/AB-9601/AB-9601.pdf) specification and will utilize the [`cryptonite`](https://github.com/haskell-crypto/cryptonite/blob/master/Crypto/Hash/RIPEMD160.hs)\n\nSince `cardano-base` already relies on `cryptonite` in the context of [`keccak-256`](https://github.com/input-output-hk/cardano-base/blob/master/cardano-crypto-class/src/Cardano/Crypto/Hash/Keccak256.hs) we would like to expose `RIPEMD-160` through the same library, to facilitate its integration into Plutus.\n\nMore specifically, Plutus will gain the following primitive operation:\n\n* `ripemd_160` :: ByteString -> ByteString\n\nThe input to this function can be a `ByteString` of arbitrary size, and the output will be a `ByteString` of 20 bytes. \nNote that this function aligns with the format of existing hash functions in Plutus, such as [blake2b_256](https://github.com/input-output-hk/plutus/blob/75267027f157f1312964e7126280920d1245c52d/plutus-core/plutus-core/src/Data/ByteString/Hash.hs#L25)\n\n## Rationale: how does this CIP achieve its goals?\nWhile the `RIPEMD-160` function might be implemented in on-chain scripts, doing so would be computationally unfeasible.\n\nThe library, cryptonite, is not implemented by and under control of the Plutus team. However,\n* It is a library already used in the Plutus stack to expose KECCAK-256, and can be considered as a trustworthy implementation.\n* Its behaviour is predictable and computationally efficient. The cost of the function is linear with respect to the size of the message provided as input. This is the same behaviour that other hash functions exposed in plutus (blake, sha3, keccak-256) have.\n\n### Acceptance Criteria\n- [X] A `cardano-base` binding is created for the `ripemd-160` function and included in a new version of the library.\n- [X] A Plutus binding is created for the `ripemd_160` function and included in a new version of Plutus.\n- [X] Integration tests, similar to those of the existing Plutus hash functions, are added to the testing infrastructure.\n- [X] The function is benchmarked to assess its cost. As for other hash functions available in Plutus (blake2b, sha256 and keccak_256), we expect the cost of `ripemd_160` to be linear with respect to the size of the message. The Plutus team determines the exact costing functions empirically.\n- [x] The ledger is updated to include new protocol parameters to control costing of the new builtins.\n  - Included within the haskell cardano-node implementation from [10.1.1](https://github.com/IntersectMBO/cardano-node/releases/tag/10.1.1).\n- [x] This CIP may transition to active status once the Plutus version containing the `ripemd_160` function is introduced in a node release and becomes available on Mainnet.\n  - Enabled by Plomin hardfork\n\n### Implementation Plan\nThe Plutus team will develop the binding, integration tests, and benchmarks. The E2E tests will be designed and implemented collaboratively by the testing team, the Plutus team, and community members planning to use this primitive.\n\n## Copyright\nThis CIP is licensed under [Apache-2.0][https://www.apache.org/licenses/LICENSE-2.0].\n\n[^1]: I did not hesitate to reuse parts of the original text of (CIP-0101)[../CIP-0101/README.md) without explicit quotations. This approach was approved by the original authors.\n"
  },
  {
    "path": "CIP-0128/README.md",
    "content": "---\nCIP: 128\nTitle: Preserving Order of Transaction Inputs\nCategory: Ledger\nStatus: Proposed\nAuthors:\n  - Jonathan Rodriguez <info@anastasialabs.com>\nImplementors: []\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/758\nCreated: 2024-02-01\nLicense: CC-BY-4.0\n---\n\n\n## Abstract\n\nWe propose the introduction of a new structure for transaction inputs aimed at enhancing the execution efficiency of Plutus contracts.\n\nThis CIP facilitates the preservation of input ordering from a submitted transaction, diverging from the current state where the ledger reorders transaction inputs lexicographically. Preserving the input ordering from a submitted transaction enables a validator to efficiently identify the required inputs in accordance with its validation logic, thus eliminating the need to use unnecessary computation by traversing all transaction inputs or performing sorting within the validator itself.\n\nFurthermore, this implementation offers the potential to enhance existing design patterns already used in production, specifically by improving the ability to group and match inputs and outputs located at the specific index positions.\n\n## Motivation: why is this CIP necessary?\n\nAccording to the Babbage CDDL [transaction_body](https://github.com/IntersectMBO/cardano-ledger/blob/master/eras/babbage/impl/cddl-files/babbage.cddl) , the inputs and reference inputs of a transaction body are represented as a set, which indicates the non-duplicate inputs. However, the ledger not only process the [transaction_inputs](https://github.com/IntersectMBO/cardano-ledger/blob/0274cf65dbb79773122b69dfd36a8299eec2783f/eras/babbage/impl/cddl-files/babbage.cddl#L75-L77) as a set , but also orders them lexicographically, first by `transaction_id` and then by `index`.\n\nThe primary issue with the ledger ordering inputs lexicographically is that validators must traverse all the inputs or sort them within the validator to find the required inputs for the validation logic. This process can lead to inefficiencies and increases the risk of exceeding the execution budget specially when processing a large set of inputs.\n\nFor instance, consider a spending validator that needs to access its own input and output. Each function described below necessitates traversing all inputs and outputs to fulfill such validation:\n\n ```haskell\nfindOwnInput :: ScriptContext -> Maybe TxInInfo\nfindOwnInput ScriptContext{scriptContextTxInfo=TxInfo{txInfoInputs}, scriptContextPurpose=Spending txOutRef} =\n    find (\\TxInInfo{txInInfoOutRef} -> txInInfoOutRef == txOutRef) txInfoInputs\nfindOwnInput _ = Nothing\n ```\n\n ```haskell\ngetContinuingOutputs :: ScriptContext -> [TxOut]\ngetContinuingOutputs ctx\n    | Just TxInInfo{txInInfoResolved=TxOut{txOutAddress}} <- findOwnInput ctx =\n        filter (f txOutAddress) (txInfoOutputs $ scriptContextTxInfo ctx)\n    where\n        f addr TxOut{txOutAddress=otherAddress} = addr == otherAddress\ngetContinuingOutputs _ = traceError \"Lf\" -- \"Can't get any continuing outputs\"\n```\n\n```haskell\nvalidatorA :: BuiltinData -> BuiltinData -> ScriptContext -> Bool\nvalidatorA _datum _redeemer context =\n  validateWithInputOutput input output\n  where\n    Just (TxInInfo {txInInfoResolved = input}) = findOwnInput context\n    [output] = getContinuingOutputs context\n    validateWithInputOutput _ _ = True\n```\n\nFurthermore, preserving the order of inputs from the submitted transaction will facilitate the utilization of index redeemer patterns that many projects are transitioning to, as illustrated below.\n\n```haskell\nvalidatorIndex :: BuiltinData -> Integer -> ScriptContext -> Bool\nvalidatorIndex _datum index ScriptContext {scriptContextTxInfo = txInfo, scriptContextPurpose = Spending txOutRef} =\n  validateInputOutput input output && txOutRef == intxOutRef\n  where\n    inputs = txInfoInputs txInfo\n    outputs = txInfoOutputs txInfo\n    TxInInfo {txInInfoOutRef = intxOutRef, txInInfoResolved = input} = inputs P.!! index\n    output = outputs P.!! index\n    validateWithInputOutput _ _ = True\n```\n\nGiven the deterministic nature of the extended UTXO model, the determination of inputs and outputs can already be achieved through the off-chain code, eliminating the necessity to find or traverse inputs and outputs within the validator.\n\n## Specification\nAs per protocol specifications, the transaction body is structured as follows:\n\n```\ntransaction_body =\n  { 0 : set<transaction_input>    ; inputs\n  , 1 : [* transaction_output]\n  , 2 : coin                      ; fee\n  , ? 3 : uint                    ; time to live\n  , ? 4 : [* certificate]\n  , ? 5 : withdrawals\n  , ? 6 : update\n  , ? 7 : auxiliary_data_hash\n  , ? 8 : uint                    ; validity interval start\n  , ? 9 : mint\n  , ? 11 : script_data_hash\n  , ? 13 : set<transaction_input> ; collateral inputs\n  , ? 14 : required_signers\n  , ? 15 : network_id\n  , ? 16 : transaction_output     ; collateral return; New\n  , ? 17 : coin                   ; total collateral; New\n  , ? 18 : set<transaction_input> ; reference inputs; New\n  }\n```\n\nSpecifically, the inputs and reference inputs are currently represented as a set:\n```\n0 : set<transaction_input>    ; inputs\n```\n```\n18 : set<transaction_input> ; reference inputs; New\n```\n\nThe proposed solution suggests modifying the inputs representation to an `oset` type:\n> An `oset` type behaves much like a `set` but remembers the order in which the elements were originally inserted. \n```\n0 : oset<transaction_input>    ; inputs\n```\n```\n18 : oset<transaction_input> ; reference inputs; New\n```\n\n\n## Rationale: how does this CIP achieve its goals?\nThe motivation behind this CIP stems from observed limitations and inefficiencies associated with the current lexicographical ordering of transaction inputs.\n\nThe strict lexicographical ordering mandated by the ledger requires traversing inputs to locate the appropriate inputs for the validation logic, which can lead to execution inefficiencies.\n\nTo address these issues, the proposed solution suggests transitioning from an `set` based representation of transaction inputs and reference inputs to an `oset` type, which preserves the order of elements.\n\nThis CIP tries to revive the original draft [CIP-0051](https://github.com/cardano-foundation/CIPs/pull/231)\n\n### Alternatives\n#### 1. Retain the existing set-based representation:\n\nThis approach involves maintaining the current set-based representation of transaction inputs and reference inputs.\n\n## Path to Active\n\n### Acceptance Criteria\n- [ ] Included within a Plutus version within a Cardano mainnet hardfork.\n\n### Implementation Plan\n- [ ] Passes all requirements of both Plutus and Ledger teams as agreed to improve Plutus script efficiency.\n\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0129/README.md",
    "content": "---\nCIP: 129\nTitle: Governance Identifiers\nStatus: Proposed\nCategory: Tools\nAuthors:\n  - Ashish Prajapati <ashish@strica.io>\nImplementors: N/A\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/845\n  - https://github.com/cardano-foundation/CIPs/pull/857\nCreated: 2024-07-15\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis Cardano Improvement Proposal (CIP) defines a standardized structure for encoding and representing various governance and credential identifiers, specifically designed for DRep, Constitutional Committee (CC) keys, and Governance Actions within the Conway era. This specification introduces a single-byte header that encapsulates metadata related to the key type and credential type, allowing identifiers to retain critical metadata even when stored as byte arrays. By encoding this metadata directly into the bech32 format, we enhance both usability and interoperability across Cardano infrastructure and tools.\n\n## Motivation: why is this CIP necessary?\n\nThe Conway era on Cardano introduces new governance features, requiring unique and identifiable credentials for roles such as DReps, Constitutional Committee members, and distinct governance actions. Existing infrastructure and tools that process bech32 identifiers often decode and store the raw byte data for efficiency, unintentionally stripping away the metadata embedded in the bech32 prefix. This CIP addresses that limitation by embedding metadata into a structured single-byte header, allowing credentials to be stored in byte form without losing essential metadata. This standardization facilitates seamless linkage, sharing, and compatibility of governance identifiers across the ecosystem, supporting a robust and interoperable governance framework in Cardano.\n\n## Specification\n\n### Introduction\nWe define a bytes representation for the various credentials and identifiers along with the their bech32 prefixes in this CIP. Taking inspiration from the Cardano addresses bytes format, we define an 8 bit header and a payload to define the key, which look similar to the reward address byte format but with a new specification and using the governance credentials.\n\nIn this CIP, We also define a simple bech32 prefix for gov actions, which does not have a credential. Gov actions only contain transaction ID bytes and an index, defined in the Gov Action Section below. The chosen prefixes for each identifier align with Cardano's established naming convention used in ledger specification, ensuring easy recognition and minimizing confusion within the ecosystem.\n\n### Binary format\n\nIn the header-byte, bits [7;4] indicate the type of gov key being used. The remaining four bits [3;0] are used to define the credential type. There are currently 3 types of credentials defined in the Cardano Conway era, this specification will allow us to define a maximum of 16 different types of keys in the future.\n\n```\n  1 byte     variable length   \n <------> <-------------------> \n┌────────┬─────────────────────┐\n│ header │        key      │\n└────────┴─────────────────────┘\n    🔎                          \n    ╎          7 6 5 4 3 2 1 0  \n    ╎         ┌─┬─┬─┬─┬─┬─┬─┬─┐ \n    ╰╌╌╌╌╌╌╌╌ |t│t│t│t│c│c│c│c│ \n              └─┴─┴─┴─┴─┴─┴─┴─┘ \n```\n\n#### Key Type\nThere are currently 3 types of governance keys, and it is defined using the first half (bits [7;4]) of the header. The different types are summarized below,\n\nKey Type (`t t t t . . . .`)      | Key\n---                               | ---\n`0000....`                        | CC Hot \n`0001....`                        | CC Cold\n`0010....`                        | DRep\n\n#### Credential Type\n\nThe second half of the header (bits [3;0]) refers to the credential type which can have the values and types as summarized in the table below,\n\nWe *reserve* the values 0 and 1 to prevent accidental conflicts with Cardano Address Network tags, ensuring that governance identifiers remain distinct and are not inadvertently processed as addresses.\n\nCredential Type (`. . . . c c c c`)   | Semantic\n---                                   | ---\n`....0010`                            | Key Hash \n`....0011`                            | Script Hash\n\n### Governance Action Identifiers\n\nCardano's Conway era introduces proposal procedures to submit governance actions. Governance actions are voted on by different kinds of credentials, and as such it is necessary to be able to share governance action identifiers across communication channels.\n\nGovernance action identifiers are defined via CIP-1694 as combination of a transaction ID it was submitted in and an index within the transaction.\n\nWe define a byte format to combine the transaction ID and the index to form a single valid byte string, as such it can be converted into a hex format and have its own Bech32 prefix.\n\nTransaction ID is always a 32 byte length, hence we can append the index bytes to the transaction id, please see examples below:\n\n#### Example 1\n\nOriginal standard definition - `0000000000000000000000000000000000000000000000000000000000000000#17`\n\nTransaction ID in Hex - `0000000000000000000000000000000000000000000000000000000000000000`\n\nGovernance Action index in Hex - `11` (number 17)\n\n(CIP-129) Governance action ID in Hex - `000000000000000000000000000000000000000000000000000000000000000011`\n\n(CIP-129) Governance action ID in Bech32 - `gov_action1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpzklpgpf`\n\n#### Example 2\n\nOriginal standard definition - `1111111111111111111111111111111111111111111111111111111111111111#0`\n\nTransaction ID in Hex - `1111111111111111111111111111111111111111111111111111111111111111`\n\nGovernance Action index in Hex - `00` (number 0) \n\n(CIP-129) Governance action ID in Hex - `111111111111111111111111111111111111111111111111111111111111111100`\n\n(CIP-129) Governance action ID in Bech32 - `gov_action1zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygsq6dmejn`\n\n### Bech32 Encoding\n\n| Prefix        | Meaning                                                 | Contents                                                          |\n| ------------- | --------------------------------------------------------| ----------------------------------------------------------------- |\n| `drep`        | DRep identifier                                         | DRep Credential                                                   |\n| `cc_hot`      | CC Hot identifier                                       | CC Hot Credential                                                 |\n| `cc_cold`     | CC Cold identifier                                      | CC Cold Credential                                                |\n| `gov_action`  | gov action identifier                                   | gov action tx id concatenated with index                          |\n\n\n### Identifier Test Vector\n\nWe can define a complete identifier as per the spec above by combining the header and the key, see below\n\n#### Constitutional Committee Hot Credential\n\nKey - `00000000000000000000000000000000000000000000000000000000`\nType - `Key Hash`\n\nIdentifier - `0200000000000000000000000000000000000000000000000000000000`\n\nBech32 - `cc_hot1qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqvcdjk7`\n\n#### Constitutional Committee Cold Credential\n\nKey - `00000000000000000000000000000000000000000000000000000000`\nType - `Script Hash`\n\nIdentifier - `1300000000000000000000000000000000000000000000000000000000`\n\nBech32 - `cc_cold1zvqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq6kflvs`\n\n#### DRep Credential\n\nKey - `00000000000000000000000000000000000000000000000000000000`\nType - `Key Hash`\n\nIdentifier - `2200000000000000000000000000000000000000000000000000000000`\n\nBech32 - `drep1ygqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq7vlc9n`\n\n## Rationale: how does this CIP achieve its goals?\n\nThis CIP achieves its objectives by introducing a unified header and payload structure for governance-related keys, allowing for metadata to be directly embedded within the byte-level representation of each identifier. By defining a single-byte header that includes both key type and credential type, the proposal provides a consistent, compact format that retains crucial metadata even when stored or transmitted as raw byte arrays. This specification is designed to be forward-compatible, with a capacity to support up to 16 key types, allowing it to evolve with Cardano’s governance and credential requirements.\n\nThis approach aligns with existing Cardano address encoding practices while adding specificity for governance keys in the Conway era. By also defining distinct bech32 prefixes for each identifier type, the CIP enhances user-friendliness and makes it easier for tooling and infrastructure to recognize, validate, and link these identifiers within the ecosystem. This design ensures governance identifiers are not only interoperable across platforms but also intuitive and accessible, paving the way for streamlined governance interactions within Cardano’s tooling and community.\n\n\n## Path to Active\n\n### Acceptance Criteria\nTools, Wallets, and Explorers to utilize the identifiers and bech32 prefixes defined in this CIP for communication and view purposes.\n\n- [ ] Requires updating Ledger nano app, and Trezor. The changes can be proposed once the CIP is merged.\n- [ ] Tooling\n  - [x] CNTools\n  - [x] SPO Scripts\n  - [x] typhonjs\n  - [x] Gov Tools\n  - [x] cardano-signer\n- [ ] APIs\n  - [x] Koios\n  - [x] Cardanoscan API\n  - [ ] Blockfrost\n- [x] Explorers\n  - [x] Cardanoscan.io\n  - [x] AdaStat.net\n- [ ] Wallets\n  - [x] Eternl\n  - [x] Typhon Wallet\n  - [ ] Lace\n  - [x] Gero\n\n### Implementation Plan\n- This CIP uses some bech32 prefixes which are already defined by CIP105 and ref by CIP005, This PR includes updates to both the CIPs with updated vector spec. The suggested changes align with the design of the original CIP005.\n\n- For key generation tools - To move faster to this CIP, current tools which implement CIP105 based bech32 prefixes do not have to implement this CIP specification. They can change the prefix according to the updates suggested in this CIP, updating bech32 prefix will be a find and replace sort of an updated and it will instantly become compatible with this CIP.\n\n- Tools like explorers and wallets - These tools can potentially support both formats to start with for the purpose of allowing users to search for drep, cold keys, hot keys as these 3 are impacted by this CIP upgrade. And can continue to show only this CIP specification, having an easy backward compatibility as well moving to this CIP standard.\n\n- This CIP does not require a hard fork for implementation, the goal is to use the identifies specified in this CIP for the UI, and as a medium of communication for sharing such keys and IDs.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0132/README.md",
    "content": "---\nCIP: 132\nTitle: New Plutus Builtin dropList\nStatus: Proposed\nCategory: Plutus\nAuthors:\n    - Philip DiSarro <info@anastasialabs.com>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/767\nCreated: 2024-02-25\nLicense: CC-BY-4.0\n---\n\n## Abstract\nThis document describes the addition of a new Plutus builtin `dropList` with the signature `Integer -> List a -> List a` that drops a given number of elements the list. This drastically increases the efficiency of `elemAt` which is currently a huge throughput bottleneck for many DApps. \n\n## Motivation: why is this CIP necessary?\nThe deterministic script evaluation property of the ledger (also stated as \"script interpreter arguments are fixed\") is a unique characteristic of the Cardano ledger that allows us to perform powerful optimizations that are not possible in systems with indeterminstic script evaluation. For instance, searching for elements in a data structure can \nbe done entirely off-chain, and then we simply provide the onchain code with the index (via redeemer) to where the element we want to find is supposed to be, and then check (onchain) that it is indeed the element we were expecting. This design pattern of passing the indices of elements required for validation logic in the redeemer is commonly referred to as redeemer-indexing. \nEven though it is still a very powerful optimization in its current state, it is currently bottlenecked by the lack of a builtin that applies tail a given number of times to a list. Currently, any implementation of `elemAt :: Integer -> List a -> a` or `drop` requires the use of the fixed point combinator (Y combinator) which has a significant cost in onchain code.\n                            \nConsider the naive approach:\n```haskell\n{- | Fixpoint recursion. Used to encode recursive functions.\n     Hopefully this illustrates the overhead that this incurs. \n-}\npfix :: Term s (((a :--> b) :--> a :--> b) :--> a :--> b)\npfix = phoistAcyclic $\n  punsafeCoerce $\n    plam' $ \\f ->\n      plam' (\\(x :: Term s POpaque) -> f # plam' (\\(v :: Term s POpaque) -> punsafeCoerce x # x # v))\n        # punsafeCoerce (plam' $ \\(x :: Term s POpaque) -> f # plam' (\\(v :: Term s POpaque) -> punsafeCoerce x # x # v))\n\n-- | Lazy if-then-else\n-- Two forces + two delays + builtinIfThenElse\npif :: Term s PBool -> Term s a -> Term s a -> Term s a\npif b case_true case_false = pforce $ (pforce $ punsafeBuiltin PLC.IfThenElse) # b # pdelay case_true # pdelay case_false \n     \npelemAt' :: PIsListLike l a => Term s (PInteger :--> l a :--> a)\npelemAt' = phoistAcyclic $\n  pfix #$ plam $ \\self n xs ->\n    pif\n      (n #== 0)\n      (phead # xs)\n      (self # (n - 1) #$ ptail # xs)\n\npelemAt' # 5 # (pconstant [1,2,3,4,5])\n-- the function `self` must be passed as an argument to each recursive call.\n-- each recursive call results in:\n--   uplc Apply operations to apply the arguments `n` and `xs` to `self`\n--   lazy ifThenElse (two forces + two delays + builtinIfThenElse)\n--   builtinEqualsInteger\n--   builtinSubtractInteger\n--   uplc Apply operations to apply the arguments (including `self`, `n` and `xs`) to the fixed-point recursive function\n``` \nAs you can see, the naive `elemAt` implementation is quite inefficient. This is a huge efficiency bottleneck for many DApps which use `elemAt` many times to locate elements at indices specified in the redeemer. In an attempt to address this, many protocols use the following heuristic optimization (where the number of skips is determined through trial and error based on the DApps throughput in testing):\n```\npelemAtFast :: PIsListLike l a => Term s (PInteger :--> l a :--> a)\npelemAtFast = phoistAcyclic $\n  pfix #$ plam $ \\self n xs ->\n    pif\n      (n #> 10)\n      (self # (n - 1) #$ ptail #$ ptail #$ ptail #$ ptail #$ ptail #$ ptail #$ ptail #$ ptail #$ ptail #$ ptail # xs)\n      (pelemAtFast2 # n # xs)\n\npelemAtFast2 :: PIsListLike l a => Term s (PInteger :--> l a :--> a)\npelemAtFast2 = phoistAcyclic $\n  pfix #$ plam $ \\self n xs ->\n      (pif\n         (n #> 5) \n         (self # (n - 5) #$ ptail #$ ptail #$ ptail #$ ptail #$ ptail # xs)\n         (pif (n #== 0) (phead # xs) (pelemAt' # (n - 1) # (ptail # xs))))\n```\nThis drastically reduces the amount of recursion we have to do which greatly increases the efficiency of this function in practice. However, it should be clear to see that there is still a huge degree of inefficiency in this implementation. Also it is difficulty to determine the correct magic numbers to skip, and the performance\nvaries drastically depending on the cut-off values chosen for `n` as-well as the number of different skip-cases (in this case we have skip cases for both `n > 10` and `n > 5`). \n\n## Specification\n\n### Function definition\nWe define a new Plutus built-in function with the following type signature:\n```haskell\nbuiltinDropList :: BuiltinInteger -> BuiltinList a -> BuiltinList a\n```\n\nSimilar to the behavior of the `indexOfByteString` builtin, this new builtin will simply error if the provided index is out of bounds for the list.\n\n\n### Cost Model\nAlthough the `BuiltinList` type is a recursive data-type, costing should be relatively straightforward. \nWe propose to define a cost model linear in the size of `n`, the number of elements to drop. What remains is to find a proper coefficient and offset for that linear model, which should be quite easy. \n\n\n## Rationale: how does this CIP achieve its goals?\n* Easy to implement as it reuses existing code of the Plutus codebase;\n* The built-in is generic enough to cover a wider set of use-cases;\n* The built-in is still relevant even if we get constant lookup index data-structures since there are occasions where BuiltinList would be preferred;\n* This directly addresses the big performance bottleneck that the fixed-point recursion implementation of `elemAt` and `drop` impose on many DApps;\n\n### Alternatives \n\n- We could decide to accept the heuristic `elemAtFast` implementation as  as an adequate solution.\n- We could provide a more generic builtin that applies a function recursively `n` times (seems complicated and bad idea). \n- We could try to reduce the overhead introduced by aspects of the `elemAt` by making the language / compiler more performant (still can't imagine we would be able to get anywhere near the performance of this builtin).\n\n## Path to Active\n\n### Acceptance Criteria\n- [ ] Fully implemented in Cardano with hard fork that includes Plutus V4.\n      \n### Implementation Plan\n- [x] Passes all requirements of both Plutus and Ledger teams as agreed to improve Plutus script efficiency and usability.\n      \n## Copyright\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n[Apache-2.0]: http://www.apache.org/licenses/LICENSE-2.0\n"
  },
  {
    "path": "CIP-0133/README.md",
    "content": "---\nCIP: 133\nTitle: Plutus support for Multi-Scalar Multiplication over BLS12-381\nStatus: Proposed\nCategory: Plutus\nAuthors:\n    - Dmytro Kaidalov <dmytro.kaidalov@iohk.io>\n    - Adam Smolarek <adam.smolarek@iohk.io>\n    - Thomas Vellekoop <thomas.vellekoop@iohk.io>\nImplementors:\n    - IOG Plutus team\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/884\nCreated: 2024-08-22\nLicense: CC-BY-4.0\n---\n## Abstract\nThe CIP proposes an extension of the current Plutus functions to provide support for the efficient computation of the multi-scalar multiplication over the BLS12-381 curve. This operation is crucial in a number of cryptographic protocols that can enhance the capabilities of the Cardano blockchain.\n\n## Motivation: why is this CIP necessary?\nMulti-scalar multiplication (MSM) is an algebraic group operation of the following form. Let $G$ be a group of prime order $p$. Let $g_0, g_1, ..., g_{N-1}$ be elements of $G$ and let $e_0, e_1, ..., e_{N-1}$ be elements of $Z_p$. Then, the multi-scalar multiplication $M$ is calculated as $M=\\sum_{i=0}^{N-1} e_i \\cdot g_i$.\n\nThis operation appears in many cryptographic protocols. Its naive implementation requires $N$ scalar multiplications and $N$ group additions. However, the performance can be significantly improved by employing advanced algorithms, such as the [Pippenger Approach](https://hackmd.io/@tazAymRSQCGXTUKkbh1BAg/Sk27liTW9). Moreover, it can be further optimized for a particular group type (e.g., for elliptic curve groups [[BH22](https://eprint.iacr.org/2022/1400.pdf), [L23](https://dspacemainprd01.lib.uwaterloo.ca/server/api/core/bitstreams/3b15ca4c-9125-4e45-9378-c5474eec6a07/content)]).\n\nMulti-scalar multiplication appears in various cryptographic protocols, such as cryptographic signatures, zero-knowledge proofs, SNARK systems, and others. It is especially important in elliptic-curve-based SNARK proof systems, where large-scale MSMs can become a bottleneck in both proving and verification algorithms.\n\nThe recent Chang upgrade in Cardano included [CIP-0381](https://cips.cardano.org/cip/CIP-0381), which introduced built-in support for operations over the BLS12-381 elliptic curve (the implementation uses [blst](https://github.com/supranational/blst/tree/master) library). It made it feasible to implement various SNARK systems on-chain in Cardano. However, MSM still remains a bottleneck for many use cases. Implementing MSM naively, even using built-in functions for BLS12-381, consumes a significant portion of the computational budget of a transaction. It hinders implementation of such SNARK systems as KZG-based PLONK or Groth16, which require computations of MSM.\n\nOur [benchmarks](https://github.com/input-output-hk/plutus-msm-bench) show that MSM of 10 $G1$ points over BLS12-381 curve consumes 7.74% of the computational budget of a transaction, while MSM of size more than 129 cannot fit into a single transaction at all. It impedes verification of complex circuits which might require much larger MSM.\n\nWe also did preliminary [benchmarks](https://github.com/dkaidalov/bench-blst-msm/) to compare an [optimized blst](https://github.com/supranational/blst/blob/e99f7db0db413e2efefcfd077a4e335766f39c27/src/multi_scalar.c) implementation of MSM with naive implementation using just blst group operations. We used Rust bindings to do these benchmarks (the underlying bindings are the same as used in [cardano-base for bslt](https://github.com/IntersectMBO/cardano-base/blob/master/cardano-crypto-class/src/Cardano/Crypto/EllipticCurve/BLS12_381/Internal.hs#L353), which means we can expect similar behavior for the Haskell stack). The results for G1 group are the following (more results in the [repository](https://github.com/dkaidalov/bench-blst-msm/)):\n\n| MSM Size | MSM Optimized Average Time | MSM Naive Average Time | Ratio Naive/Optimized |\n|---------:|---------------------------:|-----------------------:|----------------------:|\n|       15 |                  728.565µs |                1.263ms |                  1.73 |\n|       20 |                  816.508µs |                1.499ms |                  1.83 |\n|       25 |                  956.735µs |                1.837ms |                  1.92 |\n|       30 |                    1.022ms |                2.055ms |                  2.01 |\n|       35 |                 428.765µs* |                2.715ms |                 6.13* |\n|       40 |                   469.49µs |                2.882ms |                  6.33 |\n|       45 |                  445.014µs |                3.288ms |                  7.37 |\n|       50 |                  533.669µs |                3.933ms |                  7.38 |\n|      100 |                   770.71µs |                7.307ms |                  9.48 |\n|      200 |                    1.065ms |                14.07ms |                  13.2 |\n|      300 |                    1.177ms |               21.605ms |                 18.34 |\n|      400 |                    1.312ms |               27.405ms |                 20.87 |\n|     1000 |                    2.584ms |               65.725ms |                 25.43 |\n|     2000 |                    4.108ms |              131.453ms |                 31.99 |\n|     3000 |                    5.510ms |              195.986ms |                 35.56 |\n|     4000 |                     7.00ms |              263.722ms |                 37.67 |\n\n\\* _the sudden time improvement after 32 points is attributed to the inner workings of the blst library, which may operate differently for the MSM of size less than 32 (this should be carefully analyzed when establishing costing function for MSM built-in)._\n\nAs it can be seen the performance improvement rises quickly with the size of the MSM. Note that the current threshold for Plutus naive implementation is 129 points per transaction. Our [blst benchmarks](https://github.com/dkaidalov/bench-blst-msm/) show that naive MSM of size 129 takes approximately the same time as optimized MSM for more than 4000 points, which gives a hint to what improvements we can expect with a Plutus built-in for MSM. Moreover, these benchmarks do not account for the Plutus overhead to call many built-in BLS12 functions while implementing the naive MSM, so the final improvement may be even larger.\nOn the other hand, it is important to mention that if those points are brought into the script as input, their number would be constrained by the size of the script and by the computational complexity of points decompression. The benchmarks of points decompression in [CIP-0381](https://cips.cardano.org/cip/CIP-0381) shows that up to 300 G1 points can be passed as input to a 16kb script. However, in real cryptographic protocols typically only a part of the points involved in MSM is passed as input, while another part is computed during the execution (e.g., in PLONK-based SNARKs).\n\nThe availability of MSM built-in function in Plutus language will provide more efficient and reliable means to perform this important computation. Implementing an optimized MSM manually in Plutus deemed to be infeasible because of its complexity and because it operates at the level of basic curve operations.\n\nA nonexclusive list of cryptographic protocols that would benefit from having MSM built-in for BLS12-381 curve:\n\n1. The verification of pairing-based SNARKs over BLS12-381. For instance, the size of the MSM in Groth16 verifier depends on the number of public inputs. The size of the MSM in KZG-based PLONK verifier depends on the arithmetization structure.\n2. Public key aggregation in [BLS multi-signature aggregation scheme](https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html). It is a popular scheme that allows to aggregate many signatures into a common message, so that verifying the short multi-signature is fast.\n3. A [cryptographic accumulator](https://github.com/perturbing/plutus-accumulator). It is a cryptographic primitive that allows a prover to succinctly commit to a set of values while being able to provide proofs of (non-)membership. Accumulators have found numerous applications including signature schemes, anonymous credentials, zero-knowledge proof systems, and others.\n\nThe above mentioned cryptographic protocols are used in many Cardano products, for instance:\n\n- **Partner chains** - a crucial component for the scalability of Cardano. Its interoperability with Cardano relies on the ability to construct a secure bridge for message passing. A reliable trustless bridge requires SNARK proofs for efficient proving of the partner chain state.\n- **Hydra** - a prominent layer-2 solution for scalability of Cardano. Hydra relies on a multisignature scheme, where all participants of the side channel need to agree on the new state. Moreover, Hydra tails could benefit from SNARKs for proving correct spending of a set of transactions.\n- **Mithril** - a protocol for helping to scale the adoption of Cardano and its accessibility for users. It creates certified snapshots of the Cardano blockchain allowing to obtain a verified version of the current state without having to download and verify the full history of the blockchain. Mithril utilizes a stake-based threshold multisignature scheme based on elliptic curve pairings. Even though at the moment most use cases of Mithril relies on off-chain computations, eventually the Mithril certificates might also be verified in Plutus smart contracts.\n- **Atala Prism** - a decentralized identification mechanism. One of the properties it can provide is anonymity: users can selectively disclose attributes of their certificate or prove statements without disclosing their identity. Up to date, the most efficient solutions for doing that use pairing-based zero-knowledge protocols.\n\nIn conclusion, integrating multi-scalar multiplication as a core built-in within Plutus is not only essential for enhancing cryptographic capabilities, but also for optimizing on-chain computations. The current approach of naive manual implementation in Plutus is inefficient for large-scale MSMs. Incorporating this function directly will streamline these operations, reduce transaction costs, and maintain the integrity of existing tools, thereby significantly advancing the Plutus ecosystem's functionality and user experience.\n\n## Specification\nThe MSM for BLS12-381 is implemented in [blst](https://github.com/supranational/blst/blob/e99f7db0db413e2efefcfd077a4e335766f39c27/bindings/blst.h#L241) library, which is already a dependency for the [cardano-base](https://github.com/IntersectMBO/cardano-base/blob/master/cardano-crypto-class/src/Cardano/Crypto/EllipticCurve/). This library provides efficient and formally verified implementation of operations over the BLS12-381 elliptic curve. It has been used for implementing [CIP-0381](https://cips.cardano.org/cip/CIP-0381). Basically, we would like to expose several additional functions from this library in Plutus API.\n\n### Function definition\nWe propose to define two new Plutus functions **bls12_381_G1_multiScalarMul** and **bls12_381_G2_multiScalarMul** as follows:\n\n```hs\nbls12_381_G1_multiScalarMul :: [Integer] -> [bls12_381_G1_element] -> bls12_381_G1_element\nbls12_381_G2_multiScalarMul :: [Integer] -> [bls12_381_G2_element] -> bls12_381_G2_element\n```\n\nThe types **bls12_381_G1_element** and **bls12_381_G2_element** are already introduced by [CIP-0381](https://cips.cardano.org/cip/CIP-0381). Given two arrays of scalars and group elements the functions compute multi-scalar multiplication for the corresponding subgroup. The arrays of scalars and group elements must be non-empty and of equal size. If the input arrays are empty or not equal, the functions must fail. These new functions naturally extend a set of operations over BLS12-381 defined by [CIP-0381](https://cips.cardano.org/cip/CIP-0381).\n\n### Cost model\nThe computational impact of multi-scalar multiplication is complicated by it having dynamic-size arguments. Preliminary [benchmarks](https://github.com/dkaidalov/bench-blst-msm/) show that the computational complexity grows linearly with the size of the MSM. This should be reflected in the costing function.\nIt should also be taken into account that the efficiency of the MSM algorithm may vary [depending on the blst setup](https://github.com/supranational/blst/blob/master/src/multi_scalar.c#L61). \n\nThere may be an extra complication in the costing procedure because all scalars have to be reduced modulo the order of the group before being passed to the blst functions (this happens [here](https://github.com/IntersectMBO/cardano-base/blob/6f9c20abdd3010e5a25356580cc968ba430101ad/cardano-crypto-class/src/Cardano/Crypto/EllipticCurve/BLS12_381/Internal.hs#L521) for the existing BLS12-381 scalar multiplication function in `cardano-crypto-class`). Presumably this is almost zero-cost for scalars already in the correct range, but if we pass in a very long list of very large scalars, the aggregated reduction time might be quite significant, and this must be taken into account in the costing function to guard against the possibility of a large amount of computation being done too cheaply.\n\n## Rationale: how does this CIP achieve its goals?\nIntegrating these functions directly into Plutus will streamline cryptographic operations, reduce transaction costs, and uphold the integrity of existing cryptographic interfaces. It addresses current inefficiencies and enhances the cryptographic capabilities of the Plutus platform.\n\nIt will allow the implementation of complex cryptographic protocols on-chain in Plutus smart contracts, significantly expanding the capabilities of the Cardano blockchain.\n\n## Path to Active\n\n### Acceptance Criteria\n\nWe consider the following criteria to be essential for acceptance:\n\n- [ ] The PR for this functionality is merged in the Plutus repository.\n- [ ] This PR must include tests, demonstrating that it behaves as the specification requires in this CIP.\n- [ ] A benchmarked use case is implemented in the Plutus repository, demonstrating that realistic use of this primitive does, in fact, provide major cost savings.\n\n### Implementation Plan\n\n- [x] IOG Plutus team consulted and accept the proposal.\n- [x] Authors to provide preliminary benchmarks of naive MSM implementation in Plutus and blst MSM.\n  - https://github.com/input-output-hk/plutus-msm-bench\n  - https://github.com/dkaidalov/bench-blst-msm/\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)."
  },
  {
    "path": "CIP-0134/README.md",
    "content": "---\nCIP: 134\nTitle: Cardano URIs - Address Representation\nCategory: Wallets\nStatus: Proposed\nAuthors:\n  - Steven Johnson <steven.johnson@iohk.io>\nImplementors: []\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/888\nCreated: 2024-08-23\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP proposes an extension to [CIP-0013] to allow easy and unambiguous encoding of\n[CIP-0019]/[CIP-0105] Addresses into URL's.\n\n## Motivation: why is this CIP necessary?\n\n[CIP-0013] defines encoding for payment addresses and stake pool, however [CIP-0019]\nand [CIP-0105] define numerous other address types.\n\nThese addresses cannot currently be encoded into URIs unambiguously.\nThis extension proposes a simple and forward compatible method of encoding such addresses into the URI scheme defined by [CIP-0013].\n\n[x509] certificates can contain name or alternative name information related to either the issuer of\nthe certificate or its subject.\nIt is desirable to distinguish an Issuer or Subject of a certificate by one or more on-chain keys.\nThis, for example, can facilitate the ability to link off-chain actions authorized with a x509 certificate,\nwith an on-chain identity.\n\nCurrently, there is no standard way to embed a Cardano address, such as a stake address,\nor a dRep address as distinguishing name within a [x509] certificate.\n\nA URI is one of the possible names that can be associated with the Issuer or Subject of a certificate.\nThis URI can be referenced in the alternative name for both the Issuer and Subject of a certificate\nby using the uniformResourceIdentifier in the general name.\n[CIP-0013] does not define a method for stake or dRep addresses, etc., to be encoded in the URI scheme it defines.\n\nAllowing these addresses to be easily encoded as URIs allows them to be 100% interoperable\nwith existing public key infrastructure and certificate creation tools.\n\n## Specification\n\nWe extend [CIP-0013] with a single new authority for referencing Cardano addresses in [CIP-0019] format.\n\n### Grammar & interpretation\n\nWe extend the grammar from [CIP-0013] with the new authority:\n\n```\nauthorityref = (... | addr )\n\naddr = \"//addr/\" cip19-addr\ncip19-addr = *cip19-char\ncip19-char = ALPHA / DIGIT / \"_\"\n```\n\nEffectively, any address string specified by [CIP-0019], [CIP-0105] or future extension to either\nof these specifications can be embedded directly within the URI.\n\n### Examples\n\n#### CIP-19 Addresses\n\n```uri\nweb+cardano://addr/addr1qx2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer3n0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgse35a3x\nweb+cardano://addr/addr_test1gz2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer5pnz75xxcrdw5vky\nweb+cardano://addr/stake1uyehkck0lajq8gr28t9uxnuvgcqrc6070x3k9r8048z8y5gh6ffgw\nweb+cardano://addr/stake_test1uqehkck0lajq8gr28t9uxnuvgcqrc6070x3k9r8048z8y5gssrtvn\n```\n\n#### CIP-105 Addresses\n\n```uri\nweb+cardano://addr/drep_vk17axh4sc9zwkpsft3tlgpjemfwc0u5mnld80r85zw7zdqcst6w54sdv4a4e\nweb+cardano://addr/drep15k6929drl7xt0spvudgcxndryn4kmlzpk4meed0xhqe25nle07s\nweb+cardano://addr/drep_script16pjhzfkm7rqntfezfkgu5p50t0mkntmdruwlp089zu8v29l95rg\nweb+cardano://addr/cc_cold_vk149up407pvp9p36lldlp4qckqqzn6vm7u5yerwy8d8rqalse3t04q7qsvwl\nweb+cardano://addr/cc_cold1lmaet9hdvu9d9jvh34u0un4ndw3yewaq5ch6fnwsctw02xxwylj\nweb+cardano://addr/cc_cold_script14ehj5f64f40xju0086fnunctulkh46mq7munm7upe4hpcwpcat\nweb+cardano://addr/cc_cold_script14ehj5f64f40xju0086fnunctulkh46mq7munm7upe4hpcwpcatv\nweb+cardano://addr/cc_hot_vk10y48lq72hypxraew74lwjjn9e2dscuwphckglh2nrrpkgweqk5hschnzv5\nweb+cardano://addr/cc_hot17mffcrm3vnfhvyxt7ea3y65e804jfgrk6pjn78aqd9vg7xpq8dv\nweb+cardano://addr/cc_hot_script16fayy2wf9myfvxmtl5e2suuqmnhy5zx80vxkezen7xqwskncf40\n```\n\n## Rationale: how does this CIP achieve its goals?\n\nBy extending [CIP-0013] to allow a [CIP-0019] encoded address to be simply embedded in the URI scheme,\nwe enable existing certificate creation tools and public key infrastructure to be used to easily\ncreate certificates that reference Cardano addresses.\n\nIt is envisioned that this extension could have use cases beyond the one presented here.\n\n## Path to Active\n\n### Acceptance Criteria\n\n* [ ] Community Feedback and Review Integrated.\n* [ ] Demonstration of Cardano addresses being embedded in x509 certificates using existing tools.\n* [ ] At least one project utilizing this standard.\n\n### Implementation Plan\n\nProject Catalyst intends to use this standard to facilitate linking of on-chain and off-chain identity\nwith x509 certificates.\nThis specification does not deal with the processes or proofs required, simply the URI scheme that is\nrequired to embed a Cardano address in a x509 certificate.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[CIP-0013]:https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/\n[CIP-0019]:https://github.com/cardano-foundation/CIPs/blob/master/CIP-0019/\n[CIP-0105]:https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/\n[x509]:https://datatracker.ietf.org/doc/html/rfc5280\n"
  },
  {
    "path": "CIP-0135/README.md",
    "content": "---\nCIP: 135\nTitle: Disaster Recovery Plan for Cardano networks\nCategory: Tools\nStatus: Active\nAuthors:\n    - Kevin Hammond <kevin.hammond@iohk.io>\n    - Sam Leathers <samuel.leathers@iohk.io>\n    - Alex Moser <alex.moser@cardanofoundation.org>\n    - Steve Wagendorp <steve.wagendorp@cardanofoundation.org>\n    - Andrew Westberg <andrewwestberg@gmail.com>\n    - Nicholas Clarke <nicholas.clarke@tweag.io>\nImplementors: N/A\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/893\nCreated: 2024-06-17\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nWhile the Cardano mainnet and other networks have proven to be highly resilient, it is necessary to proactively \nconsider the possible recovery mechanisms and procedures that may be required in the unlikely \nevent of a major failure where the network is unable to recover itself. \n\nThis CIP considers three representative scenarios and addresses specific considerations relevant \nin each case:  \n\nScenario 1 - __Long-Lived Network Partition__  \nScenario 2 - __Failure to Make Blocks for an Extended Period of Time__  \nScenario 3 - __Bad Blocks Minted on Chain__  \n\nTo ensure successful recovery in the event of a chain failure, it's crucial to establish effective \ncommunication channels and exercise recovery procedures in advance to familiarize the community and \nstake pool operators (SPOs) with the process.\n\nThis CIP is based on an earlier IOHK technical report that is referenced below, supplemented by internal \ndocumentation and discussions that have not been publicly released. It should be considered to be a living \ndocument that is reviewed and revised on a regular basis.  \n\nNote that although the focus of disaster recovery is on Cardano mainnet, since this is the greatest risk\nof loss of funds, the recovery procedures are generic and apply to other Cardano\nnetworks, including SanchoNet, Preview, PreProd or private networks.\nAppropriate adjustments may need to be made to reflect differences in timing or other concerns.\n\n\n## Motivation: why is this CIP necessary?\n\nThis CIP is needed to familiarize stakeholders with the processes and procedures that should be \nfollowed in the unlikely event that the Cardano mainnet, or another Cardano network, encounters\na situation where the built-in on-chain recovery mechanisms fail.\n\n## Specification\n\nWhile the exact recovery process will depend on the unique nature of the failure, there are three main scenarios we can consider.\n\n### Scenario 1: Long-Lived Network Partition\n\nOuroboros Praos is designed to cope with real-world networking\nconditions, in which some nodes may temporarily be disconnected from\nthe network.  In this case, the network will continue to make blocks,\nperhaps at some lower chain density (reflecting the temporary loss of\nstake to the network as a whole).  As nodes rejoin the network, they\nwill then participate in normal block production once again. In this\nway, the network remains resilient to changes in connectivity.\n\nIf many nodes become disconnected, the network could divide into two\nor more completely disconnected parts.  Each part of the network could\nthen form its own chain, backed by the stake that is participating in\nits own partition.  Under normal conditions, Praos will also deal with\nthis situation.  When the partitioned group of nodes reconnects, the\nlongest chain will dominate, and the shorter chain will be discarded.\nThe nodes on the shorter chain will automatically rollback to the\npoint where the fork occurred, and then rejoin the main chain.  This\nis perfectly normal.  Such forks will typically last only a few\nblocks.\n\nHowever, in an extreme situation, the partition may persist beyond the\nPraos rollback limit of *k* blocks (currently 2,160 blocks on mainnet). \nIn this case, the nodes will not be able to rollback to rejoin the main chain, since this\nwould violate the required Praos guarantees.\n\n\n#### Remediations\n\nDisconnected nodes must be reconnected to the main chain by their operators. This can be done \nby truncating the local block database to a point before the chain fork and then resyncing \nagainst the main network, using the `db-truncator` tool, for example.\n\nFull node wallets can also be recovered in the same way, though this may require technical \nskills that the end users do not possess. It may be easier, if slower, for them to simply \nresynchronize their nodes from the start of the chain (i.e. from the genesis block).\n\nOuroboros Genesis provides additional resilience when recovering from long lived network partitions. \nIn Praos nodes resyncing from a point before the chain fork could still in some cases follow the \nalternative chain (if it is the first one seen) and extra mechanisms may be needed to avoid this \npossibility. In Praos, for example, this may require that all participants on the alternative chain \ntruncate the local block database prior to the partition being resolved. In Ouroboros Genesis \nwhen resyncing from a point before the chain fork, the chain selection rules will ensure \nselection of the correct path for the main chain assuming the partition has been resolved.\n\nAlternative methods to resynchronise the node to the main chain might\ninclude the use of Mithril or other signed snapshots.  These would\nallow faster recovery.  However, in this case, care needs to be taken\nto achieve the correct balance of trust against speed of recovery.\n\n#### Additional Effects on Cardano Users\n\nAlthough block producing nodes will rejoin the main network following the remediation\ndescribed above, the blocks that they have\nminted while they were disconnected will not be included in the main\nchain.  This may have real world effects that will not be\nautomatically remedied when the nodes rejoin the main chain.  For\nexample, transactions may have been processed that have significant\nreal world value, or assumptions may have been made about chains of\nevidence/validity, or the timing of transactions. End users should be\naware of the possibility and include provisions in their contracts to\ncover this eventuality.  It may be necessary to resubmit some or all of the\ntransactions that were processed on the minority chain onto the main chain.\nTo avoid unexpected effects, this should be done by the end users/applications, and not\nby block producers acting on their behalf.\n\nIf they are not observant, stake pools, full node wallets and\nother node users (e.g. explorers) could continue indefinitely on the minority\nchain.  Such users should take care to be aware of this situation and\ntake steps to rejoin the main chain as quickly as possible.\nA reliable and trusted public warning system should be considered that can alert users\nand advise them on how to rejoin the main chain.\n\n\n#### Timing Considerations\n\nOn Cardano mainnet, partitions of less than 2,160 blocks will automatically rejoin the main chain.  With current Cardano mainnet settings, this represents\na period of up to 12 hours during which automatic rollback will occur.  If the partition exceeds 2,160 blocks, then the\nprocedure described above will be necessary to allow nodes to rejoin the main chain.  Other Cardano networks may have different\ntiming characteristics.\n\n\n### Scenario 2: Failure to Make Blocks for an Extended Period of Time\n\nOuroboros Praos requires *at least* one block to be produced every *3k/f* slots.  With the current Cardano mainnet\nsettings, that is a 36 hour period.  Such an event is extremely unlikely, but if it were to happen then the network\nwould be unable to make any further blocks.\n\n#### Mitigation\n\nIt is recommended to monitor the chain for block production.  If a low density period is observed, then block producers\nshould be notified, and efforts made to mint new blocks prior to the expiry of the *3k/f* window.  If this is not possible\nthen the remediation procedures should be followed.\n\n#### Remediation\n\nIdentify a small group of block producing nodes that will be used to recover the chain.  For Cardano mainnet, this group should have\nsufficient delegated stake to be capable of generating at least 9 blocks in a 36 hour window.\nIt should be isolated from the rest of the network.\nThe chain can then be recovered by resetting the wall clocks on the group of block producing nodes,\nrestarting them from the last good block on the Cardano network, playing forward the chain production\nat high speed (10x usual speed is recommended), while inserting new empty blocks at the slots which\nare allocated to the block producers. The recovery nodes can then be restarted with normal settings, including\nconnections to the network.  Ouroboros Genesis then allows other nodes in the network to rapidly resynchronize\nwith the newly restored chain.  This would leave one or more gaps in the chain, interspersed with empty blocks.\n\n##### Rewards Donation by Recovery Block Producers\n\nIn order to avoid allegations of unfair behaviour, block producing nodes that are used to recover the network should\ndonate any rewards that they receive during recovery to the treasury.\n\n\n#### Additional Effects on Cardano Users\n\nUnlike Scenario 1, no transactions will be submitted that need to be resubmitted on the chain.\nUsers will, however, experience an extended period during which the chain is unavailable.\nCardano applications and contracts should be designed with this possibility in mind.\nFull node wallets and other node users should recover quickly once the network is restarted\nbut there may be a period of instability while network connections are re-established\nand the Ouroboros Genesis snapshot is distributed across all nodes.\n\n\n#### Timing Considerations\n\nThe chain will tolerate a gap of up to *3k/f* slots (36 hours with current Cardano mainnet settings).\nA period of low chain density could have security implications that affect dynamic availability \nand leave open the possibility for future long range attacks. This may be particularly \nrelevant should chain recovery be performed as described above (using less stake than is required \nfor an honest majority). To mitigate the presence of an extended period of low chain density we may \nneed to make use of the lightweight checkpointing mechanism in Ouroborus Genesis. Alternatively, Mithril \ncould also be used to provide certified snapshots to stake pools as a means to verify the correct state of the ledger.\n\nThe adoption of Mithril for fast bootstrapping by light clients and edge nodes should help to mitigate risks \nfor the types of users on the network that do not participate in consensus.\n\nAs described below, Ouroboros Genesis snapshots may also be useful as part of the recovery process.\n\n\n### Scenario 3: Bad Blocks Minted on Chain\n\nIn the event that a bad block was to be minted on-chain, then some or all validators might be unable to process the block.\nThey would therefore stop, and be unable to restart.  Wallet and other nodes might be unable to synchronise beyond the\npoint of the bad block.\n\n#### Remediation\n\nDepending on the cause of the issue and its severity, alternative remediations might be possible. \n\n**Scenario 3.1**: if some existing node versions were able to process the block, but others were not, then\nthe chain would continue to grow at a lower chain density.  SPOs would need to be persuaded to upgrade (or downgrade)\nto a suitable node version that would allow the chain to continue.  The chain density would then gradually recover to its normal level.\nOther users would need to upgrade (or downgrade) to a version of the node that could follow the full chain.\n\n**Scenario 3.2**: if no node version was able to process the block and a\ngap of less than *3k/f* slots existed, then the chain could be rolled\nback immediately before the bad block was created, and nodes\nrestarted from this point.  The chain would then grow as normal, with a small gap around the bad block.\nIn this case, care would need to be taken that the rogue transaction was not accidentally reinserted into the chain.  \nThis might involve clearing node mempools, applying filters on the transaction, or developing and deploying a new node version that \nrejected the bad block.\n\n**Scenario 3.3**: an alternative to rolling back would be to develop and deploy a \"hot-fix\" node that could\naccept the bad block, either as an exception, or as new acceptable behaviour.  \nNodes would then be able to incorporate the bad block as part of the chain,\nminting new blocks as usual, or following the chain.\nIn this case, the bad block would persist on-chain indefinitely and future nodes\nwould also need to accept the bad block.  Such an approach is best used when the rejected block has behaviour\nthat was unanticipated, but which is benign in nature.  This will leave no abnormal gaps in the chain.\n\n**Scenario 3.4**: if more than *3k/f* slots have passed since the bad block was minted, then it will be necessary to roll back the chain immediately\nprior to the bad block as in Scenario 3.2, and then proceed as described for Scenario 2.  As with Scenario 2, this will leave\na series of gaps in the chain that are interspersed with empty blocks.\n\n#### Timing Considerations\n\nIf more than *3k/f* slots have passed since the bad block was minted on-chain (36 hours with current Cardano mainnet settings),\nthen a mix of recovery techniques will be needed, as described in Scenario 3.4.  When deciding on the correct recovery\ntechnique for Scenarios 3.1-3.3, consideration should be given as to whether the recovery can be successfully completed before *3k/f* slots\nhave elapsed.  In case of doubt, the procedure for Scenario 3.4 should be followed.\n\n### Using Ouroboros Genesis Snapshots\n\nAny of the above conditions may result in a period of lower chain density. The\nupdated consensus mechanism introduced in Ouroboros Genesis relies on making\nchain density comparisons to assist a node when catching up with the network,\nin order to reduce the reliance on having trusted peers when syncing. As\nsuch, low-density periods pose a potential security risk for the future; they\nare periods where a motivated adversary could perform a long-range attack by\nbuilding a higher density chain.\n\nIn order to mitigate this, Genesis introduces the concepts of lightweight\ncheckpoints. A lightweight checkpoint is effectively a block point - a\ncombination of block number and hash - which can be distributed along with the\nnode. Unlike Mithril Snapshots (see below), Genesis lightweight snapshots are not assured by any committee - rather, they form part of the trusted codebase distributed with the node, or by other parties.\n\nWhen syncing, a Genesis node will refuse to validate past the block number of any lightweight checkpoint if the chain does not contain the correct block at that point.\n\nGenesis snapshots play two potential roles in disaster recovery:\n\n1. In scenarios where the network is split, a lightweight snapshot could guide\n   a node from the abandoned partition in connecting to the main partition. In\n   general this should not be needed, however, since the main partition should win\n   out in any Genesis density comparisons. This usage also falls closer to\n   scenario 2, in that it relies on an external source imposing a chain selection,\n   which must then be trusted by all parties.\n2. Following a disaster recovery procedure, a sufficient number of blocks\n   covering the low density period should be added to the list of lightweight\n   checkpoints. These would serve the purpose of preventing a subsequent\n   long-range attack.\n\nNote that, in this second scenario, concerns about the legitimacy of the\ncheckpoint are much less salient. The checkpoint can be issued post disaster\nrecovery, at such a time where the points it contains are in the past, and are\nboth agreed upon and easy to verify for all honest parties.\n\n\n### Using Mithril Snapshots\n\nMithril is a stake-based threshold multi-signatures scheme. One of the applications of this protocol in Cardano\nis to create certified snapshots of the Cardano blockchain. Mithril snapshots allow nodes or applications\nto obtain a verified copy of the current state of the blockchain without having to download and verify the full history.\n\nSPOs that participate in the Mithril network provide signed snapshots to a Mithril aggregator that \nis responsible for collecting individual signatures from Mithril signers and aggregating them into a multi-signature. \nUsing this capability, the Mithril aggregator can then provide certified snapshots of the Cardano blockchain that\ncan potentially be used as a trusted source for recovery purposes.\n\nProvided that it gains sufficient adoption on the Cardano network and that\nsnapshots continue to be signed by an honest majority of stake pools\nfollowing a chain recovery event, Mithril may therefore provide an\nalternative solution to Ouroboros Genesis checkpoints as a way to\nverify the correct state of the ledger\n\n\n### Recommended Actions for Cardano mainnet\n\n1. Monitor Cardano mainnet for periods of low density and take early action if an extended period is observed.\n2. Identify a collection of block producer nodes that has sufficient stake to mint at least 9 blocks in any 36 hour window.\n3. Set up emergency communication channels with stake pool operators and other community members.\n4. Practice disaster recovery procedures on a regular basis.\n5. Provide signed Mithril snapshots and a way for full node wallet users and others to recover from this snapshot.\n6. Determine how to employ Ouroboros Genesis snapshots as part of the disaster recovery process\n\n#### Community Engagement\n\nOne of the key requirements for successful disaster recovery will be proper engagement with the community.\n\n1. Identify stake pool operators (SPOs) who can assist with disaster recovery\n2. Discuss disaster recovery requirements with Intersect's Technical Working Groups and Security Council\n3. Identify and establish the right communications channels with the community, including Intersect\n4. Set up regular disaster recovery practice sessions\n\n\n## Rationale: how does this CIP achieve its goals?\n\nThis CIP outlines key disaster recovery scenarios that the Cardano community should understand to mitigate\npotential network outages. As a living document, it will be regularly reviewed and updated to inform \nstakeholders and encourage more detailed contingency planning. The CIP aims to facilitate discussions, \nestablish recovery procedures, and encourage regular recovery practice exercises to ensure preparedness \nand validation of recovery actions in the event of an outage.\n\n## Path to Active\n\n### Acceptance criteria\n\n- [x] The proposal has been reviewed by the community and sufficiently advertised on various channels.\n    - [x] Intersect Technical Groups\n    - [x] Intersect Discord Channels\n    - [x] Cardano Forum\n\n- [x] All major concerns or feedback have been addressed.\n\n### Implementation Plan\n\nN/A\n\n## Change Log\n\n| Version | Date | Description |\n| -------- | -------- | ------- |\n| 0.1 | 2024-08-30 | Initial submitted version |\n| 0.2 | 2024-09-10 | Revised version to emphasize genericity of recovery techniques |\n| 0.3 | 2024-09-18 | Revised version following CIP editors meeting |\n\n## References\n\n[Cardano Disaster Recovery Plan (May 2021)](https://iohk.io/en/research/library/papers/cardano-disaster-recovery-plan/)\n\n[Cardano Incident Reports](https://updates.cardano.intersectmbo.org/tags/incident)\n\n[January 2023 Block Production Temporary Outage](https://updates.cardano.intersectmbo.org/2023-04-17-ledger)\n\n[DB Truncator Tool](https://github.com/IntersectMBO/ouroboros-consensus/tree/486753d0b7d6b0d09621d1ef8be85e5117ff3d1e/ouroboros-consensus-cardano/app)\n\n[DB Synthesizer Tool](https://github.com/IntersectMBO/ouroboros-consensus/tree/486753d0b7d6b0d09621d1ef8be85e5117ff3d1e/ouroboros-consensus-cardano/app)\n\n[Ouroboros Genesis](https://iohk.io/en/research/library/papers/ouroboros-genesis-composable-proof-of-stake-blockchains-with-dynamic-availability/)\n\n[Mithril](https://github.com/input-output-hk/mithril)\n\n\n## Copyright\n\n This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0136/README.md",
    "content": "---\nCIP: 136\nTitle: Governance metadata - Constitutional Committee votes\nCategory: Metadata\nStatus: Proposed\nAuthors:\n    - Ryan Williams <ryan.williams@intersectmbo.org>\n    - Eystein Magnus Hansen <eysteinsofus@gmail.com>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/878\nCreated: 2024-07-17\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThe Conway ledger era ushers in on-chain governance for Cardano via [CIP-1694 | A First Step Towards On-Chain Decentralized Governance](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md), with the addition of many new on-chain governance artifacts.\nSome of these artifacts support the linking of off-chain metadata, as a way to provide context to on-chain actions.\n\nThe [CIP-100 | Governance Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0100) standard provides a base framework for how all off-chain governance metadata can be formed and handled.\nThis standard was intentionally limited in scope, so that it can be expanded upon by more specific subsequent CIPs.\n\nThis proposal aims to provide a specification for the off-chain metadata vocabulary that can be used to give context to Constitutional Committee (CC) votes.\n\n## Motivation: why is this CIP necessary?\n\nThe high-level motivation for this proposal is to provide a standard which improves legitimacy of Cardano's governance system.\n\n### Clarity for governance action authors\n\nGovernance action authors are likely to have dedicated a significant amount of time to making their action meaningful and effective (as well as locking a significant deposit).\nIf this action is not able to be ratified by the CC, it is fair for the author to expect a reasonable explanation from the CC.\n\nWithout reasonable context being provided by the CC votes, authors may struggle to iterate upon their actions, until they are deemed constitutional.\nThis situation could decrease perceived legitimacy in Cardano's governance.\n\n### Context for other voting bodies\n\nBy producing a standard we hope to encourage all CC members to attach rich contextual metadata to their votes.\nThis context should show CC member's decision making is fair and reasonable.\n\nThis context allows the other voting bodies to adequately check the power of the CC.\n\n### CC votes are different to other types of vote\n\nThe CC and their votes are fundamentally very different from the other voting bodies.\nThis makes reusing standards from these voting bodies problematic.\n\n### Inclusion within interim constitution\n\nCardano's [Interim Constitution Article VI Section 4](https://github.com/IntersectMBO/interim-constitution/blob/75155526ce850118898bd5eacf460f5d68ceb083/cardano-constitution-0.txt#L330) states:\n\n```txt\nConstitutional Committee processes shall be transparent.\nThe Constitutional Committee shall publish each decision.\nWhen voting no on a proposal, the Committee shall set forth the basis\nfor its decision with reference to specific Articles of this Constitution\nthat are in conflict with a given proposal.\n```\n\nThis section suggests that the CC shall provide rationale documents.\nSpecifying a standard structure and common vocabulary for these documents aids the creation of supporting tooling. \n\n### Tooling\n\nBy creating and implementing these metadata standards we facilitate the creation of tooling that can read and write this data.\nSuch tooling greatly expands the reach and effectiveness of rationales as it allows for rich user interfaces to be created.\ni.e. translation tools, rationale comparison tools.\n\n## Specification\n\nWe define a specification for fields which can be added to CC votes.\n\n### Extended Body Vocabulary\n\nThe following properties extend the potential vocabulary of [CIP-100](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0100)'s `body` property.\n\n#### `summary`\n\n- A short text field. Limited to `300` characters.\n- Authors SHOULD use this field to clearly state their stance on the issue.\n- Authors SHOULD use this field to succinctly describe their rationale.\n- Authors SHOULD give a brief overview of the main arguments will support your position.\n- This SHOULD NOT support markdown text styling.\n- Compulsory.\n\n#### `rationaleStatement`\n\n- A long text field.\n- Authors SHOULD use this field to fully describe their rationale.\n- Authors SHOULD discuss their arguments in full detail.\n- This field SHOULD support markdown text styling.\n- Compulsory.\n\n#### `precedentDiscussion`\n\n- A long text field.\n- The author SHOULD use this field to discuss what they feel is relevant precedent.\n- This field SHOULD support markdown text styling.\n- Optional.\n\n#### `counterargumentDiscussion`\n\n- A long text field.\n- The author SHOULD use this field to discuss significant counter arguments to the position taken.\n- This field SHOULD support markdown text styling.\n- Optional.\n\n#### `conclusion`\n\n- A long text field.\n- The author SHOULD use this field to conclude their rationale.\n- This SHOULD NOT support markdown text styling.\n- Optional.\n\n#### `internalVote`\n\n- A custom object field.\n- This field SHOULD be used to reflect any internal voting decisions within CC member.\n- This field SHOULD be used by members who are constructed from organizations or consortiums.\n- Optional.\n\n##### `constitutional`\n\n- A positive integer.\n- The author SHOULD use this field to represent a number of internal votes for the constitutionality of the action.\n- Optional.\n\n##### `unconstitutional`\n\n- A positive integer.\n- The author SHOULD use this field to represent a number of internal votes against the constitutionality of the action.\n- Optional.\n\n##### `abstain`\n\n- A positive integer.\n- The author SHOULD use this field to represent a number of internal abstain votes for the action.\n- Optional.\n\n##### `didNotVote`\n\n- A positive integer.\n- The author SHOULD use this field to represent a number of unused internal votes.\n- Optional.\n\n##### `againstVote`\n\n- A positive integer.\n- The author SHOULD use this field to represent a number of internal votes to not vote on the action.\n- Optional.\n\n### Extended `references` Vocabulary\n\nHere we extend CIP-100's `references` field.\n\n#### `RelevantArticles`\n\n- We add to CIP-100's `@type`s, with a type of `RelevantArticles`.\n- Authors SHOULD use this field to list the relevant constitution articles to their argument.\n\n### Application\n\nCC must include all compulsory fields to be considered CIP-136 compliant.\nAs this is an extension to CIP-100, all CIP-100 fields can be included within CIP-136 compliant metadata.\n\n### Test Vector\n\nSee [test-vector.md](./test-vector.md) for examples.\n\n### Versioning\n\nThis proposal should not be versioned, to update this standard a new CIP should be proposed.\nAlthough through the JSON-LD mechanism further CIPs can add to the common governance metadata vocabulary.\n\n## Rationale: how does this CIP achieve its goals?\n\nBy providing a peer reviewed structure for CC vote rationale, we encourage detailed voting rationales increasing the legitimacy of CC votes within the governance system.\n\n### `summary`\n\nWe include compulsory summary with limited size to allow for the creation of tooling which layers of inspection to vote rationale.\nThis allows readers to get a summary of a rationale at a high level before reading all the details.\n\n### `rationaleStatement`\n\nThis field allows for a very long-form discussion of their rationale.\nThis is compulsory because it forms the core of their rationale.\n\nBy setting some fields to compulsory we ensure a minimum amount of data for downstream tools to expect to render.\n\n### `precedentDiscussion`\n\nThis is a dedicated field to be able to discuss specific precedent of votes.\nBy separating this from `rationaleStatement` we encourage specific discussion of precedence as well as clear separation in tooling.\n\n### `counterargumentDiscussion`\n\nThis is a dedicated field to be able to discuss counterarguments from those proposed in the other fields.\nBy separating this from `rationaleStatement` we encourage specific discussion of counterarguments as well as clear separation in tooling.\n\n### `internalVote`\n\nThis field, gives the ability for CC members who are operated by multiple individuals to share insights on specific voting choice of the individuals.\nThis could add additional context to the workings and opinions of the individuals who operate the CC member.\n\n### `relevantArticles`\n\nBy providing a new type to CIP-100 `References` we encourage tooling to differentiate clearly `References` to the constitution from other types of `Reference`.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] This standard is supported by two separate tools, which create and submit CC votes.\n- [ ] This standard is supported by two different chain indexing tools, used to read and render metadata.\n\n### Implementation Plan\n\n- [x] Seek feedback from individuals who are members of current Interim Constitutional Committee.\n- [x] Author to provide test vectors, examples, and schema files.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0136/cip-136.common.jsonld",
    "content": "{\n    \"@context\": {\n        \"@language\": \"en-us\",\n        \"CIP100\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#\",\n        \"CIP136\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#\",\n        \"hashAlgorithm\": \"CIP100:hashAlgorithm\",\n        \"body\": {\n            \"@id\": \"CIP136:body\",\n            \"@context\": {\n                \"references\": {\n                    \"@id\": \"CIP100:references\",\n                    \"@container\": \"@set\",\n                    \"@context\": {\n                        \"GovernanceMetadata\": \"CIP100:GovernanceMetadataReference\",\n                        \"Other\": \"CIP100:OtherReference\",\n                        \"label\": \"CIP100:reference-label\",\n                        \"uri\": \"CIP100:reference-uri\",\n                        \"RelevantArticles\": \"CIP136:RelevantArticles\"\n                    }\n                },\n                \"summary\": \"CIP136:summary\",\n                \"rationaleStatement\": \"CIP136:rationaleStatement\",\n                \"precedentDiscussion\": \"CIP136:precedentDiscussion\",\n                \"counterargumentDiscussion\": \"CIP136:counterargumentDiscussion\",\n                \"conclusion\": \"CIP136:conclusion\",\n                \"internalVote\": {\n                    \"@id\": \"CIP136:internalVote\",\n                    \"@context\": {\n                        \"constitutional\": \"CIP136:constitutional\",\n                        \"unconstitutional\": \"CIP136:unconstitutional\",\n                        \"abstain\": \"CIP136:abstain\",\n                        \"didNotVote\": \"CIP136:didNotVote\",\n                        \"againstVote\": \"CIP136:againstVote\"\n                    }\n                }\n            }\n        },\n        \"authors\": {\n            \"@id\": \"CIP100:authors\",\n            \"@container\": \"@set\",\n            \"@context\": {\n                \"did\": \"@id\",\n                \"name\": \"http://xmlns.com/foaf/0.1/name\",\n                \"witness\": {\n                    \"@id\": \"CIP100:witness\",\n                    \"@context\": {\n                        \"witnessAlgorithm\": \"CIP100:witnessAlgorithm\",\n                        \"publicKey\": \"CIP100:publicKey\",\n                        \"signature\": \"CIP100:signature\"\n                    }\n                }\n            }\n        }\n    }\n}"
  },
  {
    "path": "CIP-0136/cip-136.common.schema.json",
    "content": "{\n    \"title\": \"CIP-136 Common\",\n    \"description\": \"Metadata document for Cardano Constitutional Committee vote rationales, extending CIP-100\",\n    \"type\": \"object\",\n    \"required\": [\"hashAlgorithm\", \"authors\", \"body\"],\n    \"properties\": {\n        \"hashAlgorithm\": {\n            \"$ref\": \"#/definitions/hashAlgorithm\"\n        },\n        \"authors\": {\n            \"$ref\": \"#/definitions/authors\"\n        },\n        \"body\": {\n            \"$ref\": \"#/definitions/body\"\n        }\n    },\n    \"definitions\": {\n        \"hashAlgorithm\": {\n            \"type\": \"string\",\n            \"enum\": [\"blake2b-256\"],\n            \"title\": \"Hash Algorithm\",\n            \"description\": \"The algorithm used to authenticate this document externally (CIP-100)\"\n        },\n        \"authors\": {\n            \"title\": \"Authors\",\n            \"description\": \"The authors of this governance metadata (CIP-100)\",\n            \"type\": \"array\",\n            \"items\": {\n                \"$ref\": \"#/definitions/author\"\n            }\n        },\n        \"author\": {\n            \"title\": \"Author\",\n            \"description\": \"An author endorsing the content of a metadata document (CIP-100)\",\n            \"type\": \"object\",\n            \"required\": [\"name\", \"witness\"],\n            \"properties\": {\n                \"name\": {\n                    \"type\": \"string\",\n                    \"title\": \"Name\"\n                },\n                \"witness\": {\n                    \"$ref\": \"#/definitions/witness\"\n                }\n            }\n        },\n        \"witness\": {\n            \"title\": \"Witness\",\n            \"description\": \"A witness proving that the author endorses the content of the metadata\",\n            \"type\": \"object\",\n            \"properties\": {\n                \"witnessAlgorithm\": {\n                    \"title\": \"WitnessAlgorithm\",\n                    \"type\": \"string\",\n                    \"enum\": [\n                        \"ed25519\"\n                    ]\n                },\n                \"publicKey\": {\n                    \"title\": \"PublicKey\",\n                    \"type\": \"string\"\n                },\n                \"signature\": {\n                    \"title\": \"Signature\",\n                    \"type\": \"string\"\n                }\n            }\n        },\n        \"body\": {\n            \"title\": \"Body\",\n            \"description\": \"The body of the metadata document that is hashed to produce a signature (CIP-100)\",\n            \"type\": \"object\",\n            \"required\": [\"summary\", \"rationaleStatement\"],\n            \"properties\": {\n                \"references\": {\n                    \"title\": \"References\",\n                    \"type\": \"array\",\n                    \"items\": {\n                        \"$ref\": \"#/definitions/reference\"\n                    }\n                },\n                \"summary\": {\n                    \"type\": \"string\",\n                    \"title\": \"Summary\",\n                    \"description\": \"The summary of the voting rationale\"\n                },\n                \"rationaleStatement\": {\n                    \"type\": \"string\",\n                    \"title\": \"Rationale Statement\",\n                    \"description\": \"The summary of the voting rationale\"\n                },\n                \"precedentDiscussion\": {\n                    \"type\": \"string\",\n                    \"title\": \"Precedent Discussion\",\n                    \"description\": \"Discussion of existing precedent\"\n                },\n                \"counterargumentDiscussion\": {\n                    \"type\": \"string\",\n                    \"title\": \"Counterargument Discussion\",\n                    \"description\": \"Discussion of counter points to the rationale\"\n                },\n                \"conclusion\": {\n                    \"type\": \"string\",\n                    \"title\": \"conclusion\",\n                    \"description\": \"Closing conclusion of the rationale\"\n                }\n            }\n        },\n        \"reference\": {\n            \"title\": \"Reference\",\n            \"description\": \"A reference to a document\",\n            \"type\": \"object\",\n            \"required\": [\"@type\", \"label\", \"uri\"],\n            \"properties\": {\n                \"@type\": {\n                    \"type\": \"string\",\n                    \"enum\": [\"GovernanceMetadata\", \"Other\", \"RelevantArticles\"],\n                    \"title\": \"Type\"\n                },\n                \"label\": {\n                    \"type\": \"string\",\n                    \"title\": \"Label\"\n                },\n                \"uri\": {\n                    \"type\": \"string\",\n                    \"title\": \"URI\"\n                }\n            }\n        },\n        \"internalVote\": {\n            \"title\": \"Internal Vote\",\n            \"description\": \"Used to reflect voting intents of individuals within the committee member\",\n            \"type\": \"object\",\n            \"properties\": {\n                \"constitutional\": {\n                    \"type\": \"integer\",\n                    \"title\": \"Constitutional Internal Vote Total\"\n                },\n                \"unconstitutional\": {\n                    \"type\": \"integer\",\n                    \"title\": \"Unconstitutional Internal Vote Total\"\n                },\n                \"abstain\": {\n                    \"type\": \"integer\",\n                    \"title\": \"Abstain Internal Vote Total\"\n                },\n                \"didNotVote\": {\n                    \"type\": \"integer\",\n                    \"title\": \"Total of individuals who did not vote\"\n                },\n                \"againstVote\": {\n                    \"type\": \"integer\",\n                    \"title\": \"Total of individuals who did not want the member to vote\"\n                }\n            }\n        }\n    }\n}"
  },
  {
    "path": "CIP-0136/examples/parameter-change-abstain.body.jsonld",
    "content": "{\n  \"@context\": {\n    \"@language\": \"en-us\",\n    \"CIP100\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#\",\n    \"CIP136\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#\",\n    \"body\": {\n        \"@id\": \"CIP136:body\",\n        \"@context\": {\n            \"references\": {\n                \"@id\": \"CIP100:references\",\n                \"@container\": \"@set\",\n                \"@context\": {\n                    \"GovernanceMetadata\": \"CIP100:GovernanceMetadataReference\",\n                    \"Other\": \"CIP100:OtherReference\",\n                    \"label\": \"CIP100:reference-label\",\n                    \"uri\": \"CIP100:reference-uri\",\n                    \"RelevantArticles\": \"CIP136:RelevantArticles\"\n                }\n            },\n            \"summary\": \"CIP136:summary\",\n            \"rationaleStatement\": \"CIP136:rationaleStatement\",\n            \"precedentDiscussion\": \"CIP136:precedentDiscussion\",\n            \"counterargumentDiscussion\": \"CIP136:counterargumentDiscussion\",\n            \"conclusion\": \"CIP136:conclusion\",\n            \"internalVote\": {\n                \"@id\": \"CIP136:internalVote\",\n                \"@container\": \"@set\",\n                \"@context\": {\n                    \"constitutional\": \"CIP136:constitutional\",\n                    \"unconstitutional\": \"CIP136:unconstitutional\",\n                    \"abstain\": \"CIP136:abstain\",\n                    \"didNotVote\": \"CIP136:didNotVote\",\n                    \"againstVote\": \"CIP136:againstVote\"\n                }\n            }\n        }\n    }\n  },\n  \"body\": {\n    \"summary\": \"We believing that the CC should abstain from voting on `committeeMaxTermLength` changes.\",\n    \"rationaleStatement\": \"By changing the `committeeMaxTermLength` we are changing the maximum length of time that a committee member can serve. This is a change that should be made with caution, as it can affect the stability and continuity of the committee. Voting on `committeeMaxTermLength` would be a conflict of interest for us.\",\n    \"internalVote\": {\n      \"constitutional\": 0,\n      \"unconstitutional\": 0,\n      \"abstain\": 1,\n      \"didNotVote\": 0,\n      \"againstVote\": 0\n    },\n    \"references\": [\n      {\n        \"@type\": \"Other\",\n        \"label\": \"A cool island for Ryan\",\n        \"uri\": \"https://www.google.com/maps/place/World's+only+5th+order+recursive+island/@62.6511465,-97.7946829,15.75z/data=!4m14!1m7!3m6!1s0x5216a167810cee39:0x11431abdfe4c7421!2sWorld's+only+5th+order+recursive+island!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n!3m5!1s0x5216a167810cee39:0x11431abdfe4c7421!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n?authuser=0&entry=ttu\"\n      }\n    ]\n  }\n}\n"
  },
  {
    "path": "CIP-0136/examples/parameter-change-abstain.body.nq",
    "content": "_:c14n0 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#body> _:c14n3 .\n_:c14n1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#OtherReference> .\n_:c14n1 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-label> \"A cool island for Ryan\"@en-us .\n_:c14n1 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-uri> \"https://www.google.com/maps/place/World's+only+5th+order+recursive+island/@62.6511465,-97.7946829,15.75z/data=!4m14!1m7!3m6!1s0x5216a167810cee39:0x11431abdfe4c7421!2sWorld's+only+5th+order+recursive+island!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n!3m5!1s0x5216a167810cee39:0x11431abdfe4c7421!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n?authuser=0&entry=ttu\"@en-us .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#abstain> \"1\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#againstVote> \"0\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#constitutional> \"0\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#didNotVote> \"0\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#unconstitutional> \"0\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n_:c14n3 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#references> _:c14n1 .\n_:c14n3 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#internalVote> _:c14n2 .\n_:c14n3 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#rationaleStatement> \"By changing the `committeeMaxTermLength` we are changing the maximum length of time that a committee member can serve. This is a change that should be made with caution, as it can affect the stability and continuity of the committee. Voting on `committeeMaxTermLength` would be a conflict of interest for us.\"@en-us .\n_:c14n3 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#summary> \"We believing that the CC should abstain from voting on `committeeMaxTermLength` changes.\"@en-us .\n"
  },
  {
    "path": "CIP-0136/examples/parameter-change-abstain.jsonld",
    "content": "{\n  \"@context\": {\n    \"@language\": \"en-us\",\n    \"CIP100\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#\",\n    \"CIP136\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#\",\n    \"hashAlgorithm\": \"CIP100:hashAlgorithm\",\n    \"body\": {\n        \"@id\": \"CIP136:body\",\n        \"@context\": {\n            \"references\": {\n                \"@id\": \"CIP100:references\",\n                \"@container\": \"@set\",\n                \"@context\": {\n                    \"GovernanceMetadata\": \"CIP100:GovernanceMetadataReference\",\n                    \"Other\": \"CIP100:OtherReference\",\n                    \"label\": \"CIP100:reference-label\",\n                    \"uri\": \"CIP100:reference-uri\",\n                    \"RelevantArticles\": \"CIP136:RelevantArticles\"\n                }\n            },\n            \"summary\": \"CIP136:summary\",\n            \"rationaleStatement\": \"CIP136:rationaleStatement\",\n            \"precedentDiscussion\": \"CIP136:precedentDiscussion\",\n            \"counterargumentDiscussion\": \"CIP136:counterargumentDiscussion\",\n            \"conclusion\": \"CIP136:conclusion\",\n            \"internalVote\": {\n                \"@id\": \"CIP136:internalVote\",\n                \"@container\": \"@set\",\n                \"@context\": {\n                    \"constitutional\": \"CIP136:constitutional\",\n                    \"unconstitutional\": \"CIP136:unconstitutional\",\n                    \"abstain\": \"CIP136:abstain\",\n                    \"didNotVote\": \"CIP136:didNotVote\",\n                    \"againstVote\": \"CIP136:againstVote\"\n                }\n            }\n        }\n    },\n    \"authors\": {\n        \"@id\": \"CIP100:authors\",\n        \"@container\": \"@set\",\n        \"@context\": {\n            \"did\": \"@id\",\n            \"name\": \"http://xmlns.com/foaf/0.1/name\",\n            \"witness\": {\n                \"@id\": \"CIP100:witness\",\n                \"@context\": {\n                    \"witnessAlgorithm\": \"CIP100:witnessAlgorithm\",\n                    \"publicKey\": \"CIP100:publicKey\",\n                    \"signature\": \"CIP100:signature\"\n                }\n            }\n        }\n    }\n  },\n  \"hashAlgorithm\": \"blake2b-256\",\n  \"body\": {\n    \"summary\": \"We believing that the CC should abstain from voting on `committeeMaxTermLength` changes.\",\n    \"rationaleStatement\": \"By changing the `committeeMaxTermLength` we are changing the maximum length of time that a committee member can serve. This is a change that should be made with caution, as it can affect the stability and continuity of the committee. Voting on `committeeMaxTermLength` would be a conflict of interest for us.\",\n    \"internalVote\": {\n      \"constitutional\": 0,\n      \"unconstitutional\": 0,\n      \"abstain\": 1,\n      \"didNotVote\": 0,\n      \"againstVote\": 0\n    },\n    \"references\": [\n      {\n        \"@type\": \"Other\",\n        \"label\": \"A cool island for Ryan\",\n        \"uri\": \"https://www.google.com/maps/place/World's+only+5th+order+recursive+island/@62.6511465,-97.7946829,15.75z/data=!4m14!1m7!3m6!1s0x5216a167810cee39:0x11431abdfe4c7421!2sWorld's+only+5th+order+recursive+island!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n!3m5!1s0x5216a167810cee39:0x11431abdfe4c7421!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n?authuser=0&entry=ttu\"\n      }\n    ]\n  },\n  \"authors\": [\n    {\n      \"name\": \"Ryan Williams\",\n      \"witness\": {\n        \"witnessAlgorithm\": \"CIP-0008\",\n        \"publicKey\": \"7ea09a34aebb13c9841c71397b1cabfec5ddf950405293dee496cac2f437480a\",\n        \"signature\": \"84582aa201276761646472657373581d600fdc780023d8be7c9ff3a6bdc0d8d3b263bd0cc12448c40948efbf42a166686173686564f45820f1a20900160c3516d9cfb9b6db2d75d8f06bc167b751d285dc8532e45ce29eaf5840418b2f2a7009ee6f4c25aec4e3cf90859a315d51467a82686c112bea340581965b330e218e8820df12de6e821ff2be9cdb4da902f4fcea642e828f426fc71409\"\n      }\n    }\n  ]\n}\n"
  },
  {
    "path": "CIP-0136/examples/treasury-withdrawal-unconstitutional.body.jsonld",
    "content": "{\n  \"@context\": {\n    \"@language\": \"en-us\",\n    \"CIP100\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#\",\n    \"CIP136\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#\",\n    \"body\": {\n        \"@id\": \"CIP136:body\",\n        \"@context\": {\n            \"references\": {\n                \"@id\": \"CIP100:references\",\n                \"@container\": \"@set\",\n                \"@context\": {\n                    \"GovernanceMetadata\": \"CIP100:GovernanceMetadataReference\",\n                    \"Other\": \"CIP100:OtherReference\",\n                    \"label\": \"CIP100:reference-label\",\n                    \"uri\": \"CIP100:reference-uri\",\n                    \"RelevantArticles\": \"CIP136:RelevantArticles\"\n                }\n            },\n            \"summary\": \"CIP136:summary\",\n            \"rationaleStatement\": \"CIP136:rationaleStatement\",\n            \"precedentDiscussion\": \"CIP136:precedentDiscussion\",\n            \"counterargumentDiscussion\": \"CIP136:counterargumentDiscussion\",\n            \"conclusion\": \"CIP136:conclusion\",\n            \"internalVote\": {\n                \"@id\": \"CIP136:internalVote\",\n                \"@container\": \"@set\",\n                \"@context\": {\n                    \"constitutional\": \"CIP136:constitutional\",\n                    \"unconstitutional\": \"CIP136:unconstitutional\",\n                    \"abstain\": \"CIP136:abstain\",\n                    \"didNotVote\": \"CIP136:didNotVote\",\n                    \"againstVote\": \"CIP136:againstVote\"\n                }\n            }\n        }\n    }\n  },\n  \"body\": {\n    \"summary\": \"Ryan using treasury funds to buy an island is unconstitutional!\",\n    \"rationaleStatement\": \"The Cardano treasury is not meant to be used for personal gain, it should be for the benefit of the community.\",\n    \"precedentDiscussion\": \"No precedent\",\n    \"counterargumentDiscussion\": \"It would be pretty cool.\",\n    \"conclusion\": \"In conclusion spending the treasury to benefit a single dude, bad.\",\n    \"internalVote\": {\n      \"constitutional\": 0,\n      \"unconstitutional\": 1,\n      \"abstain\": 0,\n      \"didNotVote\": 0\n    },\n    \"references\": [\n      {\n        \"@type\": \"relevantArticles\",\n        \"label\": \"Article III section 8.\",\n        \"uri\": \"https://github.com/IntersectMBO/interim-constitution/blob/main/cardano-constitution-0.txt#L231\"\n      },\n      {\n        \"@type\": \"Other\",\n        \"label\": \"A cool island for Ryan\",\n        \"uri\": \"https://www.google.com/maps/place/World's+only+5th+order+recursive+island/@62.6511465,-97.7946829,15.75z/data=!4m14!1m7!3m6!1s0x5216a167810cee39:0x11431abdfe4c7421!2sWorld's+only+5th+order+recursive+island!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n!3m5!1s0x5216a167810cee39:0x11431abdfe4c7421!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n?authuser=0&entry=ttu\"\n      }\n    ]\n  }\n}\n"
  },
  {
    "path": "CIP-0136/examples/treasury-withdrawal-unconstitutional.body.nq",
    "content": "_:c14n0 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-label> \"Article III section 8.\"@en-us .\n_:c14n0 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-uri> \"https://github.com/IntersectMBO/interim-constitution/blob/main/cardano-constitution-0.txt#L231\"@en-us .\n_:c14n1 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#body> _:c14n4 .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#abstain> \"0\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#constitutional> \"0\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#didNotVote> \"0\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n_:c14n2 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#unconstitutional> \"1\"^^<http://www.w3.org/2001/XMLSchema#integer> .\n_:c14n3 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#OtherReference> .\n_:c14n3 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-label> \"A cool island for Ryan\"@en-us .\n_:c14n3 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#reference-uri> \"https://www.google.com/maps/place/World's+only+5th+order+recursive+island/@62.6511465,-97.7946829,15.75z/data=!4m14!1m7!3m6!1s0x5216a167810cee39:0x11431abdfe4c7421!2sWorld's+only+5th+order+recursive+island!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n!3m5!1s0x5216a167810cee39:0x11431abdfe4c7421!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n?authuser=0&entry=ttu\"@en-us .\n_:c14n4 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#references> _:c14n0 .\n_:c14n4 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#references> _:c14n3 .\n_:c14n4 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#conclusion> \"In conclusion spending the treasury to benefit a single dude, bad.\"@en-us .\n_:c14n4 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#counterargumentDiscussion> \"It would be pretty cool.\"@en-us .\n_:c14n4 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#internalVote> _:c14n2 .\n_:c14n4 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#precedentDiscussion> \"No precedent\"@en-us .\n_:c14n4 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#rationaleStatement> \"The Cardano treasury is not meant to be used for personal gain, it should be for the benefit of the community.\"@en-us .\n_:c14n4 <https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#summary> \"Ryan using treasury funds to buy an island is unconstitutional!\"@en-us .\n"
  },
  {
    "path": "CIP-0136/examples/treasury-withdrawal-unconstitutional.jsonld",
    "content": "{\n  \"@context\": {\n    \"@language\": \"en-us\",\n    \"CIP100\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#\",\n    \"CIP136\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0136/README.md#\",\n    \"hashAlgorithm\": \"CIP100:hashAlgorithm\",\n    \"body\": {\n        \"@id\": \"CIP136:body\",\n        \"@context\": {\n            \"references\": {\n                \"@id\": \"CIP100:references\",\n                \"@container\": \"@set\",\n                \"@context\": {\n                    \"GovernanceMetadata\": \"CIP100:GovernanceMetadataReference\",\n                    \"Other\": \"CIP100:OtherReference\",\n                    \"label\": \"CIP100:reference-label\",\n                    \"uri\": \"CIP100:reference-uri\",\n                    \"RelevantArticles\": \"CIP136:RelevantArticles\"\n                }\n            },\n            \"summary\": \"CIP136:summary\",\n            \"rationaleStatement\": \"CIP136:rationaleStatement\",\n            \"precedentDiscussion\": \"CIP136:precedentDiscussion\",\n            \"counterargumentDiscussion\": \"CIP136:counterargumentDiscussion\",\n            \"conclusion\": \"CIP136:conclusion\",\n            \"internalVote\": {\n                \"@id\": \"CIP136:internalVote\",\n                \"@container\": \"@set\",\n                \"@context\": {\n                    \"constitutional\": \"CIP136:constitutional\",\n                    \"unconstitutional\": \"CIP136:unconstitutional\",\n                    \"abstain\": \"CIP136:abstain\",\n                    \"didNotVote\": \"CIP136:didNotVote\",\n                    \"againstVote\": \"CIP136:againstVote\"\n                }\n            }\n        }\n    },\n    \"authors\": {\n        \"@id\": \"CIP100:authors\",\n        \"@container\": \"@set\",\n        \"@context\": {\n            \"did\": \"@id\",\n            \"name\": \"http://xmlns.com/foaf/0.1/name\",\n            \"witness\": {\n                \"@id\": \"CIP100:witness\",\n                \"@context\": {\n                    \"witnessAlgorithm\": \"CIP100:witnessAlgorithm\",\n                    \"publicKey\": \"CIP100:publicKey\",\n                    \"signature\": \"CIP100:signature\"\n                }\n            }\n        }\n    }\n  },\n  \"hashAlgorithm\": \"blake2b-256\",\n  \"body\": {\n    \"summary\": \"Ryan using treasury funds to buy an island is unconstitutional!\",\n    \"rationaleStatement\": \"The Cardano treasury is not meant to be used for personal gain, it should be for the benefit of the community.\",\n    \"precedentDiscussion\": \"No precedent\",\n    \"counterargumentDiscussion\": \"It would be pretty cool.\",\n    \"conclusion\": \"In conclusion spending the treasury to benefit a single dude, bad.\",\n    \"internalVote\": {\n      \"constitutional\": 0,\n      \"unconstitutional\": 1,\n      \"abstain\": 0,\n      \"didNotVote\": 0\n    },\n    \"references\": [\n      {\n        \"@type\": \"relevantArticles\",\n        \"label\": \"Article III section 8.\",\n        \"uri\": \"https://github.com/IntersectMBO/interim-constitution/blob/main/cardano-constitution-0.txt#L231\"\n      },\n      {\n        \"@type\": \"Other\",\n        \"label\": \"A cool island for Ryan\",\n        \"uri\": \"https://www.google.com/maps/place/World's+only+5th+order+recursive+island/@62.6511465,-97.7946829,15.75z/data=!4m14!1m7!3m6!1s0x5216a167810cee39:0x11431abdfe4c7421!2sWorld's+only+5th+order+recursive+island!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n!3m5!1s0x5216a167810cee39:0x11431abdfe4c7421!8m2!3d62.651114!4d-97.7872244!16s%2Fg%2F11spwk2b6n?authuser=0&entry=ttu\"\n      }\n    ]\n  },\n  \"authors\": [\n    {\n      \"name\": \"Ryan Williams\",\n      \"witness\": {\n        \"witnessAlgorithm\": \"ed25519\",\n        \"publicKey\": \"7ea09a34aebb13c9841c71397b1cabfec5ddf950405293dee496cac2f437480a\",\n        \"signature\": \"af493e96363237bb9cd6d93ef40dd0ca00912fadefc8c8388ce3bdda1ae928a427f0801c9cc3f68cac4995ac7e137c2405b8c26acd001b55c1b7225d07e54405\"\n      }\n    }\n  ]\n}\n"
  },
  {
    "path": "CIP-0136/test-vector.md",
    "content": "# Test Vector for CIP-136\n\nHere we create some useful definitions and some examples.\n\n## Common Context\n\n### Common Fields\n\nThe context fields which could be added to CIP-136 compliant jsonld files.\nSee [cip-0136.common.jsonld](./cip-136.common.jsonld).\n\n### Common Fields Schema\n\nA json schema for the common context fields.\nSee [cip-0136.common.schema.json](./cip-136.common.schema.json).\n\n## Examples\n\n### Treasury Withdrawal is Unconstitutional\n\nExample metadata document file: [treasury-withdrawal-unconstitutional.jsonld](./examples/treasury-withdrawal-unconstitutional.jsonld).\n\nBlake2b-256 of the file content (to go on-chain): `7065bd1dcdde9c512f973519085ea55872fdf1a78eddb6907149dde1541e8044`\n\n#### Intermediate files\n\nFiles produced to articulate process, these are not necessary in implementations.\n\nBody files, used to correctly generate author's witness:\n\n- [treasury-withdrawal-unconstitutional.body.jsonld](./examples/treasury-withdrawal-unconstitutional.body.jsonld)\n\n- [treasury-withdrawal-unconstitutional.body.nq](./examples/treasury-withdrawal-unconstitutional.body.nq)\n\nBlake2b-256 hash digest of canonicalized body: `7b2c08cafbdf7b524035c1f7face3af9f0370d2df4d5c841ebb83b4e5a843e64`\n\n### Parameter Change Abstain\n\nExample metadata document file: [parameter-change-abstain.jsonld](./examples/parameter-change-abstain.jsonld).\n\nBlake2b-256 of the file content (to go on-chain): `e6eb01af450260deda3cbbdf042b5c33eeb479013680f2db3b24d48801dd05a9`\n\n#### Intermediate files\n\nFiles produced to articulate process; these are not necessary in implementations.\n\nBody files, used to correctly generate author's witness:\n\n- [parameter-change-abstain.body.jsonld](./examples/parameter-change-abstain.body.jsonld)\n\n- [parameter-change-abstain.body.nq](./examples/parameter-change-abstain.body.nq)\n\nBlake2b-256 hash digest of canonicalized body: `f1a20900160c3516d9cfb9b6db2d75d8f06bc167b751d285dc8532e45ce29eaf`\n\n## How-to Recreate Examples\n\nThis tutorial creates additional intermediate files, these are not required in implementations but are shown here to articulate the process.\n\n### Author\n\nKeys used for author property, provided here for convenience.\n\nPrivate extended signing key (hex): `105d2ef2192150655a926bca9cccf5e2f6e496efa9580508192e1f4a790e6f53de06529129511d1cacb0664bcf04853fdc0055a47cc6d2c6d205127020760652`\n\nPublic verification key (hex):\n`7ea09a34aebb13c9841c71397b1cabfec5ddf950405293dee496cac2f437480a`\n\nPublic verification key hash (hex): `0fdc780023d8be7c9ff3a6bdc0d8d3b263bd0cc12448c40948efbf42`\n\nMainnet public enterprize address (hex): `610fdc780023d8be7c9ff3a6bdc0d8d3b263bd0cc12448c40948efbf42`\n\n### 1. Create the example.jsonld's `body`\n\nCreate the `example.jsonld` file adding in all available values.\nThen remove from this document any top-level field that is not `@context` or `body`.\n\nIf recreating the [Treasury Withdrawal Vote](#treasury-withdrawal-is-unconstitutional), this will result in the intermediate file of [treasury-withdrawal-unconstitutional.body.jsonld](./examples/treasury-withdrawal-unconstitutional.body.jsonld).\n\n### 2. Canonicalize the `body`\n\nUsing a tool which complies with the [RDF Dataset Canonicalization](https://w3c-ccg.github.io/rdf-dataset-canonicalization/spec/), create a canonicalized representation of `example.body.jsonld`.\nOne such tool is the [JSON-LD Playground](https://json-ld.org/playground/).\nEnsure the result ends in a newline.\n\nThis creates `example.body.nq`.\n\nFor [Treasury Withdrawal Vote](#treasury-withdrawal-is-unconstitutional), this will result in the intermediate file of [treasury-withdrawal-unconstitutional.body.nq](./examples/treasury-withdrawal-unconstitutional.body.nq).\n\n### 3. Hash the canonicalized `body`\n\nUsing a tool create a Blake2b-256 hash of the canonicalized `example.body.nq`.\nOne such tool is the [ToolKit Bay](https://toolkitbay.com/tkb/tool/BLAKE2b_256).\n\nFor [Treasury Withdrawal Vote](#treasury-withdrawal-is-unconstitutional), this will result in: `7b2c08cafbdf7b524035c1f7face3af9f0370d2df4d5c841ebb83b4e5a843e64`.\n\n### 4. Authors witness over the hash of canonicalized `body`\n\nUse the hash produced in [3.](#3-hash-the-canonicalized-body) as the payload for the witnessing. For a `witnessAlgorithm` of `ed25519` refer to [CIP-100 Hashing and Signatures](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#hashing-and-signatures).\n\nOne tool for Ed25519 signatures is [Ed25519 Online Tool](https://cyphr.me/ed25519_tool/ed.html), although it does not support extended keys.\nOther tooling such as [Cardano Serialization Library](https://github.com/Emurgo/cardano-serialization-lib) is able to support this signing, [see example](https://github.com/Ryun1/csl-examples/blob/main/examples/CIP-0008/cip-8-signing.js).\n\nFor [Treasury Withdrawal Vote](#treasury-withdrawal-is-unconstitutional), we use the keys described in [Author](#author) resulting in: `af493e96363237bb9cd6d93ef40dd0ca00912fadefc8c8388ce3bdda1ae928a427f0801c9cc3f68cac4995ac7e137c2405b8c26acd001b55c1b7225d07e54405`.\n\n### 5. Add other properties to example.jsonld\n\nWe can go back to our `example.body.jsonld` and now add in all missing properties, from outside of `body`.\n\n- Adding the `hashAlgorithm` of `blake2b-256`.\n\n- Adding the `authors` with a single entry, including information of our `witness` goes into the `signature`.\n\nBy adding this information we create our `example.jsonld`.\n\nFor [Treasury Withdrawal Vote](#treasury-withdrawal-is-unconstitutional), this will result in [treasury-withdrawal-unconstitutional.jsonld](./examples/treasury-withdrawal-unconstitutional.jsonld).\n\n### 6. Hash example.jsonld\n\nTo be able to create a final metadata hash which can be attached on-chain we simply hash the content of the file [Treasury Withdrawal Vote](#treasury-withdrawal-is-unconstitutional) as is.\n\nThis results in: `7065bd1dcdde9c512f973519085ea55872fdf1a78eddb6907149dde1541e8044`.\n\n### 7. Submit to chain\n\nWe can then host `example.jsonld` somewhere easily accessible following [CIP-100 Best Practices](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0100/README.md#best-practices).\n\nThen at submission time of the vote we can provide the on-chain transaction both the URI to the hosted `example.jsonld` but also the hash generated via [6.](#6-hash-examplejsonld).\n"
  },
  {
    "path": "CIP-0137/README.md",
    "content": "---\nCIP: 137\nTitle: Decentralized Message Queue\nCategory: Network\nStatus: Proposed\nAuthors:\n    - Jean-Philippe Raynaud <jp.raynaud@gmail.com>\n    - Arnaud Bailly <arnaud.bailly@iohk.io>\n    - Marcin Szamotulski <marcin.szamotulski@iohk.io>\n    - Armando Santos <armando.santos@iohk.io>\n    - Neil Davies <neil.davies@iohk.io>\n    - Sebastian Nagel <sebastian.nagel@ncoding.at>\nImplementors:\n    - Cardano Scaling team <https://github.com/cardano-scaling>\n    - Blink Labs <https://github.com/blinklabs-io>\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/876\nCreated: 2024-08-02\nLicense: Apache-2.0\n---\n\n## Abstract\n\nWe propose to create a decentralized message diffusion protocol leveraging the Cardano network layer. This protocol allows to follow a topic based diffusion of messages from publishers to subscribers in a decentralized way.\n\nThe messages can be sent and received by nodes running in a non intrusive way side by side to the Cardano node in order to enable inter-nodes communications.\n\nIn this way, we can significantly reduce the cost and effort required to build a decentralised network for message diffusion by using Cardano's established infrastructure, with limited impact on the performance and no impact on the security of the Cardano network.\n\n## Motivation: why is this CIP necessary?\n\nMany protocols in the Cardano ecosystem need the capability to diffuse messages in a decentralized manner. However, it is not possible to diffuse any type of message from Cardano block producers to a limited subset of subscribed peers. Nonetheless, the Cardano network has a proven efficient, reliable and secure infrastructure which is used to diffuse a transaction from one peer to all the other peers in the network. This infrastructure can be leveraged to achieve the goal of diffusing other types of messages with the guarantees offered by the Cardano network and a reduced development overhead.\n\nMithril is a protocol based on a [Stake-based Threshold Multi-signature scheme](https://iohk.io/en/research/library/papers/mithril-stake-based-threshold-multisignatures/) which leverages the Cardano SPOs to certify data from the Cardano chain in a trustless way. Mithril is currently used in the Cardano ecosystem in order to enable fast bootstrapping of full nodes and enabling secure light wallets. The Mithril protocol coordinates the collection of individual signatures originating from the signers (run by SPOs) by the aggregators which combine them into Mithril multi-signatures and certificates. In order to be fully decentralized, the protocol needs to rely on a decentralized peer to peer network which, if built from the ground up, would require significant efforts and investment. Furthermore, the majority of SPO's, as the representatives of Cardano's active stake, will have to adopt and operate Mithril nodes alongside their Cardano node. Thus a natural solution is to use the Cardano network layer to significantly facilitate the development of the Mithril protocol without a significant impact on the Cardano network or high maintenance efforts for the SPOs. Mithril will be a fundamental first user of the proposed Decentralized Message Queue and it will be used as an illustrative example throughout this document.\n\nOther protocols in the Cardano ecosystem, such as Leios and Peras (and probably other protocols in the future), also need the capability to diffuse messages originating from block producers in a decentralized fashion. However, in the Leios and Peras cases, the Cardano node itself is a producer and consumer of these messages. We have taken into consideration this need for a generic solution in the design proposed.\n\nThe proposed solution is described in detail below.\n\n## Specification\n\n### Overview\n\n![Overview](./img/overview.jpg)\n\nThis specification proposes to create `3` new mini-protocols in the Cardano network layer:\n\n- `node-2-node`:\n  - [**Message Submission mini-protocol**](#Message-Submission-mini-protocol): Diffusion of the messages on the Cardano network.\n- `node-2-client`:\n  - [**Local Message Submission mini-protocol**](#Local-Message-Submission-mini-protocol): Local submission of a message to be diffused by the Cardano network.\n  - [**Local Message Notification mini-protocol**](#Local-Message-Notification-mini-protocol): Local notification of a message received from the Cardano network.\n\n> [!NOTE]\n> The terms **Message producer**, **Message consumer** and **Network node** may represent different entities depending on the concrete implementation made for a specific protocol:\n>\n> - the **Network node** could be either the **Cardano node** itself or a **Decentralized Message Queue node** or **DMQ node** implementing the mini-protocols described in this document. Opting in for one of these possibilities will depend on a careful analysis of the impact on the security of the Cardano node, impact on the load of the Cardano network, the specific network topology needed by the protocol and the needed level of coupling with the Cardano node itself (access to ledger, consensus, ...). It's worth mentioning that each protocol will implement its own version of the **Network node** by leveraging a common implementation of the mini-protocols.\n> - the message **Message producer** and **Message consumer** could be either the **Cardano node** itself or **another node** able to interact with the **Network node** through the node-to-client mini-protocols detailed in this document.\n>\n> Here is a summary of the meanings of these terms depending on the protocol:\n> | Protocol | Message producer | Message consumer | Network node |\n> |------|------|------|------|\n> | **Mithril** | [Mithril signer](https://mithril.network/doc/mithril/mithril-network/signer) | [Mithril aggregator](https://mithril.network/doc/mithril/mithril-network/architecture) | [DMQ node](#information-diffusion-architecture) |\n\n### Message Submission mini-protocol\n\n#### Description\n\nThe node to node message submission protocol is used to transfer messages between full nodes. It follows a pull-based strategy where the inbound side asks for new messages and the outbound side returns them back. This protocol is designed to guard both sides against resource consumption attacks from the other side in a trustless setting.\n\n> [!NOTE]\n> There exists a local message submission protocol which is used when the server trusts a local client as described in the [following section](#Local-Message-Submission-mini-protocol).\n\n#### State machine\n\n| Agency                   |                                                                   |\n| ------------------------ | ----------------------------------------------------------------- |\n| Outbound side has Agency | StInit, StMessageIdsNonBlocking, StMessageIdsBlocking, StMessages |\n| Inbound side has Agency  | StIdle, StDone                                                    |\n\n```mermaid\nstateDiagram-v2\n\n  classDef White fill:white,stroke:white\n  classDef Black fill:white,stroke:black\n  classDef Blue fill:white,stroke:blue\n  classDef Green fill:white,stroke:green\n\n  start:::White --> StInit:::Green\n  StInit:::Green --> StIdle:::Blue : MsgInit\n  StIdle:::Blue --> StMessageIdsBlocking:::Green : MsgRequestMessageIdsBlocking\n  StMessageIdsBlocking:::Green --> StIdle:::Blue : MsgReplyMessageIds\n  StIdle:::Blue --> StMessageIdsNonBlocking:::Green : MsgRequestMessageIdsNonBlocking\n  StMessageIdsNonBlocking:::Green --> StIdle:::Blue : MsgReplyMessageIds\n  StMessageIdsBlocking:::Green --> StDone:::Black : MsgDone\n  StIdle:::Blue --> StMessages:::Green : MsgRequestMessages\n  StMessages:::Green --> StIdle:::Blue : MsgReplyMessages\n\n```\n\n##### Protocol messages\n\n- **MsgInit**: Initial message of the protocol.\n- **MsgRequestMessageIdsNonBlocking(ack,req)**: The inbound side asks for new message ids and acknowledges old ids. The outbound side immediately replies (possible with an empty list).\n- **MsgRequestMessageIdsBlocking(ack,req)**: The inbound side asks for new messages ids and acknowledges old ids. The outbound side will block until new messages are available.\n- **MsgReplyMessageIds([(id,size)])**: The outbound side replies with a list of available messages. The list contains pairs of message ids and the corresponding size of the message in bytes. In the blocking case the reply is guaranteed to contain at least one message. In the non-blocking case, the reply may contain an empty list.\n- **MsgRequestMessages([id])**: The inbound side requests messages by sending a list of message-ids.\n- **MsgReplyMessages([messages])**: The outbound side replies with a list messages.\n- **MsgDone**: The outbound side terminates the mini-protocol.\n\n##### Transition table\n\n| From state              | Message                         | Parameters  | To State                |\n| ----------------------- | ------------------------------- | ----------- | ----------------------- |\n| StInit                  | MsgInit                         |             | StIdle                  |\n| StIdle                  | MsgRequestMessageIdsBlocking    | ack,req     | StMessageIdsBlocking    |\n| StMessageIdsBlocking    | MsgReplyMessageIds              | [(id,size)] | StIdle                  |\n| StIdle                  | MsgRequestMessageIdsNonBlocking | ack,req     | StMessageIdsNonBlocking |\n| StMessageIdsNonBlocking | MsgReplyMessageIds              | [(id,size)] | StIdle                  |\n| StIdle                  | MsgRequestMessages              | [id]        | StMessages              |\n| StMessages              | MsgReplyMessages                | [messages]  | StIdle                  |\n| StMessageIdsBlocking    | MsgDone                         |             | StDone                  |\n\n> [!NOTE]\n> The `StInit` state is needed as it allows to start all outbound sides on the same side of the connection, which is needed as the information flows in the opposite direction with this special **message submission mini-protocol**. This is also the case with the **tx-submission mini-protocol** because information flows in the other direction than for headers with **chain-sync mini-protocol** or blocks with **block-fetch mini-protocol**.\n\n##### CDDL encoding specification\n\n```cddl\nmessageSubmissionMessage\n  = msgInit\n  / msgRequestMessageIds\n  / msgReplyMessageIds\n  / msgRequestMessages\n  / msgReplyMessages\n  / msgDone\n\nmsgInit              = [0]\nmsgRequestMessageIds = [1, isBlocking, messageCount, messageCount]\nmsgReplyMessageIds   = [2, [ *messageIdAndSize ] ]\nmsgRequestMessages   = [3, messageIdList ]\nmsgReplyMessages     = [4, ]\nmsgDone              = [5, ]\n\nisBlocking = false / true\nmessageCount = word16\nmessageId = bstr\nmessageBody = bstr\nmessageIdAndSize = [ messageId, messageSizeInBytes ]\nmessageIdList = [ * messageId ]\nmessageList = [ * message ]\nmessageSizeInBytes = word32\nkesSignature = bstr\nkesPeriod = word32\noperationalCertificate = [ bstr .size 32, word64, word64, bstr .size 64 ]\ncoldVerificationKey = bstr .size 32\nexpiresAt = word32\n\nmessagePayload = [\n  messageId\n  , messageBody\n  , kesPeriod\n  , expiresAt\n]\nmessage = [\n  messagePayload\n  , kesSignature\n  , operationalCertificate\n  , coldVerificationKey\n]\n```\n\n#### Inbound side and outbound side implementation\n\nThis mini-protocol is designed with two goals in mind:\n\n- diffuse messages with high efficiency\n- protect from asymmetric resource attacks from the message consumer against the message provider\n\nThe mini-protocol is based on two pull-based operations:\n\n- the message consumer asks for message ids,\n- and uses these ids to request a batch of messages (which it has not received yet)\n\nThe outbound side is responsible for initiating the mini-protocol with a peer node, but the inbound side (i.e. the other node) is the one who asks for information.\n\nThe outbound side maintains a limited size FIFO queue of outstanding messages for each of the inbound sides it is connected to, so does the inbound side with a mirror FIFO queue of message ids:\n\n- the inbound side asks for the next message ids and acknowledges for the previous message ids received (and removed from its queue).\n- the outbound side removes the acknowledged ids from the FIFO queue it maintains for the inbound side.\n- the inbound side can download the content of the messages by giving an unordered list of ids to the outbound side.\n- the outbound side reply omits any message that may have become invalid in the meantime.\n\nThe protocol supports blocking and non-blocking requests:\n\n- the outbound side must reply immediately to a non-blocking request.\n- the inbound side must wait until the outbound side has at least one message available.\n- if the current queue of the inbound side is empty, it must use a blocking request and a non-blocking request otherwise.\n\n#### Protocol invariants\n\n##### Outbound side\n\n- blocking request must be done if and only if the buffer of unacknowledged ids is empty (this also means that one cannot do a non-blocking request if the unacknowledged ids buffer is empty).\n- one cannot request `0` ids either through a blocking or a non-blocking request.\n\n##### Inbound side\n\n- it is a protocol error to send a message which id wasn't requested.\n\n#### Message invalidation\n\n##### Message invalidation mechanism\n\nIn order to bound the resource requirements needed to store the messages in a network node, their lifetime should be limited. Thus, they carry an expiration date (formatted as a Unix timestamp) which must be checked before processing the message:\n\n- the message will be invalidated when the local clock of the processing node exceeds the expiration date\n- an expiration date which expires too far in the future will be considered a protocol violation (the maximum allowed time to live is a protocol parameter for each topic which may be negotiated).\n\n##### Cost of valid message storage\n\n> [!NOTE]\n> Computations are based on the assumption of a **30 minutes** TTL for messages and are assuming that the messages are stored once in the memory of the network node (i.e. the aforementioned FIFO queues store reference to the messages).\n\nFor a total of **3,100** Cardano SPOs on the `mainnet`, on an average **50%** of them will be eligible to send signatures (i.e. will win at least one lottery in the Mithril protocol). This means that if the full Cardano stake distribution is involved in the Mithril protocol, only **1,550** signers will send signatures at each round:\n\n- the maximum number of valid messages stored by a node at any given time is:\n\n| Send period | Messages in memory |\n| ----------- | ------------------ |\n| 1 min       | 45 k               |\n| 2 min       | 23 k               |\n| 5 min       | 9 k                |\n| 10 min      | 5 k                |\n\n- the maximum extra memory for the valid messages stored by a node at any given time is:\n\n| Send period | Lower bound | Upper bound |\n| ----------- | ----------- | ----------- |\n| 1 min       | 51 MB       | 124 MB      |\n| 2 min       | 26 MB       | 62 MB       |\n| 5 min       | 11 MB       | 25 MB       |\n| 10 min      | 6 MB        | 13 MB       |\n\n#### Protocol authentication\n\n##### Message authentication mechanism\n\nThe payload part of the message (message id, message body, KES period and expiration timestamp fields) is signed with the KES key of the SPO (the message signed is the CBOR encoding of the payload: `bstr .cbor messagePayload`). The message is composed of the aforementioned payload (encoded as an array), the KES signature (raw bytes), the operational certificate (the KES public key, the issue number of the operational certificate, the KES period at the time of creation of the operational certificate and their cold signing key signature, encoded as an array) and the cold verification key (raw bytes) are appended to the message.\n\nBefore being diffused to other peers, an incoming message must be verified by the receiving node. This is done with the following steps:\n\n- Verify that the operational certificate is valid by checking that the KES verification key is signed by cold secret key.\n- Verify the KES signature of the message body with the KES verification key from the operational certificate.\n- Compute the SPO pool id by hashing the cold verification key from the operational certificate. Make sure that this pool id is part of the stake distribution (the network layer will need to have access to this information).\n- Verify that the announced id of the message is verified upon reception.\n\nIf any of these step fails, the message is considered as invalid, which is a protocol violation.\n\n> [!WARNING]\n> We also probably need to make sure that the KES key used to sign is from the latest rotation:\n>\n> - either the last seen opcert number in the block headers of the chain.\n> - or the last seen opcert number from a previous message diffused.\n> - or the last opcert number recorded in the Mithril signer registration.\n>\n> If the opcert number received is strictly lower than the previous one which has been seen, it should be considered as a protocol violation.\n\n##### Cost of authentication\n\n> [!NOTE]\n> Computations are based on the assumption of a **2 ms** KES signature verification time on a virtual CPU, which may vary depending on the infrastructure.\n\nFor a total of **3,100** Cardano SPOs on the `mainnet`, on an average **50%** of them will be eligible to send signatures (i.e. will win at least one lottery in the Mithril protocol). This means that if the full Cardano stake distribution is involved in the Mithril protocol, only **1,550** signers will send signatures at each round:\n\n- the number of messages received by a node which need to be verified is:\n\n| Send period | Messages sent |\n| ----------- | ------------- |\n| 1 min       | 64 M/month    |\n| 2 min       | 32 M/month    |\n| 5 min       | 13 M/month    |\n| 10 min      | 7 M/month     |\n\n- the extra CPU time for the verification of messages based on the aforementioned volume of messages received is:\n\n| Send period | CPU core usage |\n| ----------- | -------------- |\n| 1 min       | 5%             |\n| 2 min       | 2.5%           |\n| 5 min       | 1.0%           |\n| 10 min      | 0.5%           |\n\n#### Network load\n\n##### Mithril extra network usage\n\n> [!NOTE]\n> The below computations of the network throughput and volume apply a multiplicative factor of **2** to the number of messages transmitted to reflect the redundancy of the diffusion mechanism.\n\n> [!WARNING]\n> Some compression can be applied to the Mithril signatures which allows them to always be on the lower bound size, but it is not implemented yet.\n\nThe following tables gather figures about expected network load in the case of **Mithril** using the mini-protocol to diffuse the individual signatures:\n\n| Message part           | Lower bound | Upper bound |\n| ---------------------- | ----------- | ----------- |\n| messageId              | 32 B        | 32 B        |\n| messageBody            | 360 B       | 2,000 B     |\n| kesSignature           | 448 B       | 448 B       |\n| kesPeriod              | 8 B         | 8 B         |\n| operationalCertificate | 304 B       | 304 B       |\n| coldVerificationKey    | 4 B         | 4 B         |\n| expiresAt              | 4 B         | 4 B         |\n\n| Message | Lower bound | Upper bound |\n| ------- | ----------- | ----------- |\n| total   | 1,160 B     | 2,800 B     |\n\nFor a total of **3,100** Cardano SPOs on the `mainnet`, on an average **50%** of them will be eligible to send signatures (i.e. will win at least one lottery in the Mithril protocol). This means that if the full Cardano stake distribution is involved in the Mithril protocol, only **1,550** signers will send signatures at each round:\n\n- the network outbound throughput of a peer is:\n\n| Send period | Lower bound | Upper bound |\n| ----------- | ----------- | ----------- |\n| 1 min       | 57 kB/s     | 138 kB/s    |\n| 2 min       | 29 kB/s     | 69 kB/s     |\n| 5 min       | 12 kB/s     | 28 kB/s     |\n| 10 min      | 6 kB/s      | 14 kB/s     |\n\n- the network outbound volume of a peer is:\n\n| Send period | Lower bound  | Upper bound  |\n| ----------- | ------------ | ------------ |\n| 1 min       | 147 GB/month | 356 GB/month |\n| 2 min       | 74 GB/month  | 178 GB/month |\n| 5 min       | 30 GB/month  | 72 GB/month  |\n| 10 min      | 15 GB/month  | 36 GB/month  |\n\n#### Infrastructure extra operating costs\n\n##### Networking traffic cost\n\n> [!NOTE]\n>\n> - These data apply to cloud providers which bill the traffic on the volume, not the bandwidth.\n> - Some cloud providers offer a free tier for the first **100GB** of traffic which is not taken into consideration here for simplicity.\n\n| Cloud Provider | Inbound Traffic | Outbound Traffic |\n| -------------- | --------------- | ---------------- |\n| AWS            | 0 $/GB          | 0.09 $/GB        |\n| GCP            | 0 $/GB          | 0.11 $/GB        |\n| Azure          | 0 $/GB          | 0.09 $/GB        |\n| Average        | 0 $/GB          | 0.1 $/GB         |\n\n##### Mithril message diffusion extra networking cost\n\nFor a total of `3,000` SPOs sending messages, the extra networking cost incurred for a Cardano full node is:\n\n| Send period | Lower bound | Upper bound |\n| ----------- | ----------- | ----------- |\n| 1 min       | 15 $/month  | 36 $/month  |\n| 2 min       | 8 $/month   | 18 $/month  |\n| 5 min       | 3 $/month   | 8 $/month   |\n| 10 min      | 2 $/month   | 4 $/month   |\n\n#### Possible attacks\n\n##### Sybil attack\n\nIn this attack, a malicious sender would attempt to create multiple identities impersonating SPOs. This attack is completely mitigated by the [Message authentication mechanism](#Message-authentication-mechanism) as only active SPO on the Cardano chain can be authenticated and send messages. This would be considered as a protocol violation and the malicous peer would be disconnected.\n\n##### Equivocation\n\nIn this attack, a malicious SPO would send different messages to different peers. This attack needs to be handled by the receiver of the message as the network layer does not verify the content of the message body by design.\n\nIn the specific case of Mithril, the individual signature is unique so there will be two cases:\n\n- the message embeds a valid signature and it will be accepted by the receiving Mithril aggregator.\n- the message embeds an invalid signature and it will be rejected by the receiving Mithril aggregator.\n\n##### DoS attack\n\nIn this attack, a malicous SPO would try to flood the network by sending many messages at once. In that case, the network layer could detect that the throughput of messages originating from a SPO is above a threshold and consider it as a protocol violation, thus disconnecting the malicous peer. If a peer asks for N messages and receives more than N messages, then it would also be considered as a protocol violation. Also, the way mini-protocols are implemented allows to set a maximum message size.\n\n#### Network node handshaking\n\nA standalone network node will use its own `handshake`. It can introduce its own protocol parameters, but quite likely it will start with `NodeToNodeVersionData`:\n\n```hs\ndata NodeToNodeVersionData = NodeToNodeVersionData\n  { networkMagic  :: !NetworkMagic\n  , diffusionMode :: !DiffusionMode\n  , peerSharing   :: !PeerSharing\n  , query         :: !Bool\n  }\n  deriving (Show, Typeable, Eq)\n```\n\n- `networkMagic`: this is used for debugging purpose and to make sure the network node runs on the right network (it should be different than the existing `networkMagic`s).\n- `diffusionMode`: this would be useful if there are initiator-only nodes, e.g. a network node running next to an edge node (a wallet).\n- `peerSharing`: this will be useful to implement peer sharing in the side network if this is needed.\n- `query`: this is useful for tools like `cardano-cli ping`.\n\n### Local Message Submission mini-protocol\n\n#### Description\n\nThe local message submission mini-protocol is used by local clients to submit message to a local network node. This mini-protocol is **not** used to diffuse messages from a network node to another.\n\nThe protocol follows a simple request-response pattern:\n\n1. The client sends a request with a single message.\n2. The server either accepts the message (and returns a confirmation) or rejects it (and returns the reason)\n\n#### State machine\n\n| Agency            |                |\n| ----------------- | -------------- |\n| Client has Agency | StIdle         |\n| Server has Agency | StBusy, StDone |\n\n```mermaid\nstateDiagram-v2\n\n  classDef White fill:white,stroke:white\n  classDef Black fill:white,stroke:black\n  classDef Blue fill:white,stroke:blue\n  classDef Green fill:white,stroke:green\n\n  start:::White --> StIdle:::Blue;\n  StIdle:::Blue --> StBusy:::Green : MsgSubmitMessage\n  StBusy:::Green --> StIdle:::Blue : MsgAcceptMessage\n  StBusy:::Green --> StIdle:::Blue : MsgRejectMessage\n  StIdle:::Blue --> StDone:::Black : MsgDone\n\n```\n\n##### Protocol messages\n\n- **MsgSubmitMessage(message)**: The client submits a message.\n- **MsgAcceptMessage**: The server accepts the message.\n- **MsgRejectMessage(reason)**: The server rejects the message and replies with a _reason_.\n- **MsgDone**: The client terminates the mini-protocol.\n\n##### Transition table\n\n| From state | Message          | Parameters | To State |\n| ---------- | ---------------- | ---------- | -------- |\n| StIdle     | MsgSubmitMessage | message    | StBusy   |\n| StBusy     | MsgAcceptMessage |            | StIdle   |\n| StBusy     | MsgRejectMessage | reason     | StIdle   |\n| StIdle     | MsgDone          |            | StDone   |\n\n##### CDDL Encoding Specification\n\n```cddl\nlocalMessageSubmissionMessage\n  = msgSubmitMessage\n  / msgAcceptMessage\n  / msgRejectMessage\n  / msgDone\n\nmsgSubmitMessage = [0, message]\nmsgAcceptMessage = [1]\nmsgRejectMessage = [2, reason]\nmsgDone          = [3]\n\nreason = invalid\n       / alreadyReceived\n       / expired\n       / other\n\ninvalid         = [0, tstr]\nalreadyReceived = [1]\nexpired         = [2]\nother           = [3, tstr]\n\nmessageId    = bstr\nmessageBody  = bstr\nkesSignature = bstr\nkesPeriod    = word64\noperationalCertificate = [ bstr .size 32, word64, word64, bstr .size 64 ]\ncoldVerificationKey = bstr .size 32\nexpiresAt = word32\n\nmessagePayload = [\n  messageId\n  , messageBody\n  , kesPeriod\n  , expiresAt\n]\nmessage = [\n  messagePayload\n  , kesSignature\n  , operationalCertificate\n  , coldVerificationKey\n]\n```\n\n### Local Message Notification mini-protocol\n\n#### Description\n\nThe local message notification mini-protocol is used by local clients to be notified about new message received by the network node.\n\nThe protocol follows a simple request-response pattern:\n\n1. The client sends a request with a single message.\n\n2. The server either has messages that it can provide, returning the list of all available messages; or doesn't have any, in which case it returns a suitable response saying exactly that.\n\n#### State machine\n\n| Agency            |                                          |\n| ----------------- | ---------------------------------------- |\n| Client has Agency | StIdle                                   |\n| Server has Agency | StBusyNonBlocking,StBusyBlocking, StDone |\n\n```mermaid\nstateDiagram-v2\n\n  classDef White fill:white,stroke:white\n  classDef Black fill:white,stroke:black\n  classDef Blue fill:white,stroke:blue\n  classDef Green fill:white,stroke:green\n\n  start:::White --> StIdle:::Blue;\n  StIdle:::Blue --> StBusyNonBlocking:::Green : MsgRequestMessagesNonBlocking\n  StBusyNonBlocking:::Green --> StIdle:::Blue : MsgReplyMessagesNonBlocking\n  StIdle:::Blue --> StBusyBlocking:::Green : MsgRequestMessagesBlocking\n  StBusyBlocking:::Green --> StIdle:::Blue : MsgReplyMessagesBlocking\n  StIdle:::Blue --> StDone:::Black : MsgClientDone\n\n```\n\n##### Protocol messages\n\n- **MsgRequestMessagesNonBlocking**: The client asks for available messages and acknowledges old message ids. The server side immediately replies (possible without available message).\n- **MsgReplyMessagesNonBlocking([message], hasMore)**: The server has received new messages and indicates if further message are available. In the non-blocking case, the reply may contain an empty list.\n- **MsgRequestMessagesBlocking**: The client asks for available messages and acknowledges old message ids. The server will only reply once there are available messages.\n- **MsgReplyMessagesBlocking([message])**: The server has received new messages and indicates if further message are available. In the blocking case, the reply is guaranteed to contain at least one message.\n- **MsgClientDone**: The client terminates the mini-protocol.\n\n#### Transition table\n\n| From state        | Message                       | Parameters           | To State          |\n| ----------------- | ----------------------------- | -------------------- | ----------------- |\n| StIdle            | MsgRequestMessagesNonBlocking |                      | StBusyNonBlocking |\n| StBusyNonBlocking | MsgReplyMessagesNonBlocking   | ([message], hasMore) | StIdle            |\n| StIdle            | MsgRequestMessagesBlocking    |                      | StBusyBlocking    |\n| StBusyBlocking    | MsgReplyMessagesBlocking      | [message]            | StIdle            |\n| StIdle            | MsgClientDone                 |                      | StDone            |\n\n##### CDDL Encoding Specification\n\n```cddl\nlocalMessageNotificationMessage\n  =\n  ; corresponds to either MsgRequestMessagesBlocking or\n  ; MsgRequestMessagesNonBlocking in the spec\n    msgRequestMessages\n  / MsgReplyMessagesNonBlocking\n  / msgReplyMessagesBlocking\n  / msgClientDone\n\nmsgRequestMessages          = [0, isBlocking]\nmsgReplyMessagesNonBlocking = [1, [* message], hasMore]\nmsgReplyMessagesBlocking    = [2, [+ message]]\nmsgClientDone               = [3]\n\nmessageId    = bstr\nmessageBody  = bstr\nkesSignature = bstr\nkesPeriod    = word64\noperationalCertificate = [ bstr .size 32, word64, word64, bstr .size 64 ]\ncoldVerificationKey = bstr .size 32\nexpiresAt = word32\n\nmessagePayload = [\n  messageId\n  , messageBody\n  , kesPeriod\n  , expiresAt\n]\nmessage = [\n  messagePayload\n  , kesSignature\n  , operationalCertificate\n  , coldVerificationKey\n]\n\nhasMore = false / true\nisBlocking = false / true\n```\n\n### Network magic\n\nIn order to identify messages belonging to a specific protocol, each DMQ network is identified by a unique network magic number:\n\n| Protocol | Cardano network | DMQ network magic number |\n| -------- | --------------- | ------------------------ |\n| Mithril  | `preview`       | `2147483650`             |\n| Mithril  | `preprod`       | `2147483649`             |\n| Mithril  | `mainnet`       | `2912307721`             |\n\n## Rationale: how does this CIP achieve its goals?\n\n### Why are we proposing this CIP?\n\n#### For Mithril\n\n- Mithril requires strong network foundations to support interactions between its various nodes:\n\n  - Mithril needs to exist in a decentralized context where multiple aggregators can operate seamlessly and independently.\n  - Mithril needs participation of all or nearly all of the Cardano network SPOs to provide maximal security to the multi-signatures embedded in the certificates.\n  - Creating a separate network would entail significant costs and efforts (there are more than 3,000 SPOs which would need to be connected with resilient and secure network, and much more passive nodes).\n  - Cardano SPOs need to be vigilant about what other applications run on their block producers and relay nodes. While a separate p2p network could be created, incoming connections must be treated carefully and all the same DoS considerations as with Cardano would need to apply. By standardizing the message diffusion of Mithril in the same way as the Cardano protocol stack, the additional risk of operating Mithril is greatly reduced.\n  - The Cardano network is very efficient for diffusion (e.g. broadcasting) which is precisely what is needed for Mithril.\n  - Mithril signer node needs to run on the same machine as the Cardano block producing node (to access the KES keys). It makes sense to use the same network layer, which will also facilitate a high level of participation.\n\n#### For Cardano\n\n- Why would it be great for Cardano to support a decentralized message queue with its network?\n\n  - This is a required feature to make the Cardano ecosystem scalable.\n  - The design is versatile enough to support present and future use cases.\n\n### Information Diffusion Architecture\n\nIn this section, we propose an architecture for `Cardano` and `Mithril`. Note,\nin this section, `Mithril` is used as a placeholder for a possible `Mithril`\napplication: we've seen many ideas about how `Mithril` can be used in `Cardano`\nand all of them can follow this design.\n\nAny software included in `cardano-node` needs to undergo a rigorous development\nand review process to avoid catastrophic events. We think that merging\n`Cardano`, a mature software, with new technologies, should be a process, and\nthus we propose first to develop `Decentralized Message Queue (DMQ)` nodes as standalone processes which\ncommunicate with `cardano-node` via its local interface (`node-to-client`\nprotocol). As we will see, this approach has advantages for the `Mithril`\nnetwork and SPOs.\n\n`Ouroboros-Network` (ON) is, to a large extent, an agnostic network stack,\nwhich can be adapted to be used by both `Cardano` and `DMQ` nodes. To construct\nan overlay network, the stack needs to access stake pool information registered\non chain. This can be done via the `node-to-client` protocol over a Unix\nsocket. Since `DMQ` nodes will have their own end-points, we'll either need\nto propose a modification to the SPO registration process, which includes\n`Mithril` instantiated `DMQ` nodes, or we could pass incoming `Mithril` connections from\n`cardano-node` to the `DMQ` node via\n[CMSG_DATA](https://man.openbsd.org/CMSG_DATA.3).\n\n`Ouroboros-Network` outbound governor component, which is responsible for\ncreating the overlay network has a built-in mechanism which churns connections\nbased on a defined metric. By developing a standalone `Mithril network` node, we can\ndesign metrics specific for the purpose. This way, the `Mithril` network will\noptimise for its benefits rather than being stuck in a suboptimal solution from\nits perspective - if `Mithril` and `Cardano` were tied more strongly (e.g. as\npart `cardano-node`), then we wouldn't have that opportunity because `Cardano`\nmust meet its deadlines, or the security of the system as a whole must be at\nstake.\n\nEventually, there will be many `Mithril` applications, and all of them might\nhave different network requirements and thus might require slightly different\nconfigurations. We SHOULD aim to build something that can be used as\na scaffolding for such applications. This may also open future avenues for\ndelivering new functionalities that fit together well with existing\ninfrastructure while still mitigating the risk of catastrophic events at the\ncore of the system.\n\nPlease also note that any protocols and their instances that will be built as\npart of the standalone `DMQ` node could be reused in future for `Peras` and\n`Leios`. It will give us even more confidence that the future core system will\nbe built from components that are used in production.\n\n`Cardano` and `DMQ` nodes, as separate executables, can still be packaged\ntogether, lowering the barrier of participation. When run separately, the SPO\nis also in better control of the resources dedicated to each process - this is\nimportant for the health of both systems.\n\nAnother benefit of such a design is that `DMQ` node can be developed on its own\npace, not affected by significant changes in other parts of the system like\nledger - the Cardano Core team restrains itself to not publishing new `cardano-node`\nversions with significant changes across many of its subsystems - just for the\nsake of clarity of where to look if a bug is found.\n\nIn this design, a `DMQ` node runs alongside a `cardano-node`, which is connected to\nit via a UNIX socket (`node-to-client`) protocol. This means an SPO will run\na `DMQ` node instantiated for `Mithril` per `cardano-node`. Future protocols will run\ntheir custom instantiated new `DMQ` node instance. The `DMQ` node connected to BP can\nalso have access to necessary keys for signing purposes. `DMQ` node might also\nuse the KES agent, as `cardano-node` will in the near future, to securely access\nthe KES key.\n\n## Path to Active\n\n### Acceptance Criteria\n\n1. A Cardano node implementing the previously described mini-protocols is released for production.\n1. A message producer node (e.g. a Mithril signer) publishing messages to the local DMQ node through mini-protocols is released.\n1. A message subscriber node (e.g. a Mithril aggregator) receiving messages from the local DMQ node is released.\n\n### Implementation Plan\n\n> [!WARNING]\n> A hard-fork of the Cardano chain may be required if some information, like peer ports for an overlay network, are to be registered by the SPOs on-chain.\n\n- [x] Write a \"formal\" specification of the protocols along with vectors/conformance checker for protocol's structure and state machine logic.\n- [x] Write an architecture document extending this CIP with more technical details about the implementation.\n  - See [here](<https://github.com/IntersectMBO/ouroboros-network/wiki/Decentralized-Message-Queue-(DMQ)-Implementation-Overview>)\n- [x] Validate protocol behaviour with all relevant parties (Network and Node teams).\n- [x] Make the current Cardano Network Diffusion Layer general and reusable so a new, separate Mithril Diffusion Layer can be instantiated.\n  - See [here](https://github.com/IntersectMBO/ouroboros-network/wiki/Reusable-Diffusion-Investigation) and [here](https://github.com/IntersectMBO/ouroboros-network/pull/5016)\n- [x] Implement DMQ Node that is able to run general diffusion (i.e. without the mini-protocols).\n  - See [here](https://github.com/IntersectMBO/ouroboros-network/pull/5109)\n- [x] Implement the n2n and n2c mini-protocols:\n  - [x] Haskell DMQ Node:\n    - [x] n2c mini-protocols\n    - [x] n2n mini-protocols\n  - [x] Pallas Library (TxPipe):\n    - [x] n2c mini-protocols\n    - [x] ~~n2n mini-protocols~~ (will be done in a separate stream of work)\n- [x] Implement the n2c mini-protocols in Mithril nodes:\n  - [x] Mithril signer\n  - [x] Mithril aggregator\n\n## References\n\n### Cardano network\n\n- **The Shelley Networking Protocol**: https://ouroboros-network.cardano.intersectmbo.org/pdfs/network-spec/network-spec.pdf\n- **Introduction to the design of the Data Diffusion and\n  Networking for Cardano Shelley**: https://ouroboros-network.cardano.intersectmbo.org/pdfs/network-design/network-design.pdf\n\n### Mithril\n\n- **Mithril: Stake-based Threshold Multisignatures**: https://iohk.io/en/research/library/papers/mithril-stake-based-threshold-multisignatures/\n- **Mithril Network Architecture**: https://mithril.network/doc/mithril/mithril-network/architecture\n- **Mithril Protocol in depth**: https://mithril.network/doc/mithril/mithril-protocol/protocol\n- **Mithril Certificate Chain in depth**: https://mithril.network/doc/mithril/mithril-protocol/certificates\n- **Fast Bootstrap a Cardano node**: https://mithril.network/doc/manual/getting-started/bootstrap-cardano-node\n- **Run a Mithril Signer node (SPO)**: https://mithril.network/doc/manual/getting-started/run-signer-node/\n- **Mithril Threat Model**: https://mithril.network/doc/mithril/threat-model\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0)\n"
  },
  {
    "path": "CIP-0138/README.md",
    "content": "---\nCIP: 138\nTitle: Plutus Core Builtin Type - `Array`\nCategory: Plutus\nStatus: Proposed\nAuthors:\n    - Michael Peyton Jones <michael.peyton-jones@iohk.io>\n    - Ana Pantilie <ana.pantilie@iohk.io>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/915\nCreated: 2024-09-18\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nWe propose an array builtin type for Plutus Core. This type will have constant-time lookup,\nwhich is a useful feature that is otherwise not possible to achieve. \n\n## Motivation: why is this CIP necessary?\n\nThe first part of [CPS-0013][1] outlines in great detail the motivation for introducing this\nnew builtin type.\n\nTo summarize, it is currently not possible to write a data structure with constant-time\nlookup in Plutus Core. We propose to solve this problem by introducing an array type into\nPlutus Core's builtin language, as it is the standard example of a data structure\nwith this property, and it is a key component of many classical algorithms and data\nstructures.\n\nAccess to an array type would provide significant performance improvement opportunities to\nusers of Plutus Core, since currently they must rely on suboptimal data structures such as\nlists for looking up elements inside a collection.\n\n## Specification\n\nWe add the following builtin type: `Array` of kind `Type -> Type` representing\na one-dimensional array type with indices of type `Integer`. Elements are indexed\nconsecutively starting from `0`.\n\n***Note***: Here `Type` is the universe of all _builtin_ types, since we do not consider\ntypes formed out of applying builtin types to arbitrary types to be inhabited.\n\nThe `Array` builtin type should be implemented with a fixed-size immutable array structure\nthat has constant-time lookup.\n\nWe add the following builtin functions:\n\n1. `indexArray` of type `forall a . Integer -> Array a -> a`.\n    - It returns the element at the given index in the array, or fails with an error if the\n    index is outside the bounds of the array.\n    - It uses constant time and constant memory.\n2. `lengthOfArray` of type `forall a . Array a -> Integer`\n    - It returns the length of the array.\n    - It uses constant time and constant memory.\n3. `listToArray` of type `forall a . List a -> Array a`\n    - It converts the argument builtin list into a builtin array.\n    - It uses linear time and linear memory.\n\n### Binary serialisation and deserialisation\n\nAs with all Plutus Core builtin types, arrays must have a fixed binary representation.\n\nFor arrays, this representation will be based on the one currently implemented in the [flat][8] encoding\nfor the [Haskell `List` type][9].  Plutus Core arrays must be converted to lists before being serialised,\nand deserialisation is performed by using the flat decoder for lists and converting the result to an array.\n\n## Rationale: how does this CIP achieve its goals?\n\n### Choice of builtin functions and their specification\n\nThe following section presents the reasoning behind the above specification of a Plutus\ncore builtin array type.\n\nIt is important to mention that we based our decisions on the desire to keep the builtin\nlanguage as small as possible, i.e. to not introduce types or functions\nwhich are not essential for definitional purposes or essential for providing a practical\ninterface to users.\n\nIt also discusses some alternatives or additions which should be considered as part of the\n[preliminary investigation](#implementation-plan).\n\n### Providing safe lookups\n\nThe `indexArray` builtin function is necessary, since access to constant-time lookup is the main\nrequirement outlined in this CIP. However, there remains the question of how users should\ndeal with the function's partiality.\nWe considered the following options:\n\n1. Introduce another new builtin type, one which implements `Maybe` semantics. The type\nsignature for `indexArray` would become `forall a . Integer -> Array a -> Maybe a` and it\nwould return `Nothing` for out-of-bounds lookups.\n    - The obvious disadvantage is the necessity of adding another new builtin type (there is\n    no `Maybe` builtin type in Plutus Core), which would further increase the complexity of\n    the builtin language.\n    - Another disadvantage would be that this solution is the most costly: users will incur\n    additional costs in deconstructing the returned `Maybe`.\n\n2. Failed lookups return a default value provided by the caller:\n`indexArray :: forall a . Integer -> a -> Array a -> a`.\n    - This solution is problematic whenever there is no sensible default value and\n    the user wants the function to fail. Since Plutus Core is strict, it is not possible\n    to pass `error` as the default value without it getting evaluated before the call and\n    terminating execution immediately.\n    - As of the time of writing, builtin functions cannot be higher-order. However, that is\n    subject to change in the near future when pattern matching builtins will be supported by\n    Plutus Core. This feature would allow a safe version of `indexArray` with type `forall a .\n    Integer -> (() -> a) -> Array a -> a` to be expressible in the builtins language.\n\n3. Include `lengthOfArray` and require the user to perform appropriate length guards before\ncalling `indexArray`.\n    - This is a familiar option from other languages.\n    - By definition arrays are fixed-size and their length is available in constant time.\n    - It also allows users to omit bounds checks when they know a priori that the\n    index is in bounds.\n\nAfter considering these three options, we concluded that the addition of\nthe `lengthOfArray` builtin function is both necessary and sufficient for introducing a\nwell-defined array type into the builtin language.\n\n### Constructing arrays\n\nThe last required functionality for having a practical interface is the ability to\nconstruct arrays.\n\nDue to our decision of providing immutable arrays, it is difficult (or very expensive) to build up arrays incrementally.\nA naive approach would require repeated copying and potentially the usage of quadratic\nspace and time.\n\nA more appropriate approach would be to construct the array in bulk,\nhowever that would require an intermediate representation of a collection of elements. Fortunately this already exists in the builtin language in the form of builtin lists.\nWe can then naturally introduce a function which transforms lists into arrays: `listToArray`.\n\n\n### Slices\n\nMany array-like data structures support cheap _slices_, e.g. a function with the following\ntype signature: `slice :: Integer -> Integer -> Array a -> Array a`, which produces a _view_\nof the original array between the two indices (similarly, the same can be achieved using an\n`indexArray` and a `lengthOfArray`).\n\nWe do not propose to add `slice` to our builtin set, since it is very easy to build a data\nstructure that supports slices on top of `array`, simply by tracking some additional\nintegers to track the subset of the array that is in view.\n\n### Arrays in `Data`\n\nIn [CPS-0013][1] the idea of representing the arguments to the `Data` constructor\n`Constr` as an `Array` in Plutus Core was presented as being more appropriate than\nthe current list representation.\n\nA significant requirement in implementing this modification is maintaining backwards\ncompatibility. Therefore, we cannot simply modify the internal representation of `Data`.\n\nOne idea would be to add a new builtin such as the following:\n`unConstrDataArray :: Data -> (Integer, Array Data)`. However, this builtin will\ninevitably have linear time complexity since it is based on a list traversal. So\nit does not actually solve the original problem, unless it can be shown experimentally\nthat, in practice, these lists are usually small enough for the transformation to be negligible.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] The feature is implemented according to the implementation plan and merged into\nthe master branch of the [plutus repository][5].\n- [ ] [cardano-ledger][6] is updated to include new protocol parameters to control costing of\nthe new builtins.\n- [ ] The feature is integrated into [cardano-node][7] and released as part of a hard fork.\n\n### Implementation Plan\n\nThe implementation of this CIP should not proceed without an empirical assessment of the effectiveness of the new primitives, as per the following plan:\n\n1. Implement the new primitives according to the specification, including the experimental\nversions discussed in the CIP.\n2. Assign a preliminary cost to the new builtin functions. Consider similar operations and their\ncurrent costs.\n3. Create variants of the [existing benchmarks][4] and potentially add some more.\n4. From the total set of newly implemented builtins, find a minimal but practical set of\nprimitives which are indeed significantly faster in both real-time performance and modelled costs.\n5. If such a set does not exist, find out why. This means that the preliminary investigation\nwas not successful. If it does, revise the specification to include\nthe final set of primitives.\n\nIf the preliminary performance investigation was not successful, this CIP should be revised\naccording to the findings of the experiment. Otherwise, the implementation can proceed:\n\n6. Determine the most appropriate costing functions for modelling the builtin's performance\nand assign costs accordingly.\n6. Add the new builtin type and functions to the appropriate sections in the [Plutus Core\nSpecification][2].\n7. Formalize the new builtin type and functions in the [plutus-metatheory][3].\n8. The final version of the feature is ready to be merged into [plutus][5] and accepted by\nthe Plutus Core team.\n\n## Copyright\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[1]: https://cips.cardano.org/cps/CPS-0013 \"CPS-0013\"\n[2]: https://plutus.cardano.intersectmbo.org/resources/plutus-core-spec.pdf \"Formal Specification of the Plutus Core Language\"\n[3]: https://github.com/IntersectMBO/plutus/tree/master/plutus-metatheory \"plutus-metatheory\"\n[4]: https://github.com/IntersectMBO/plutus/tree/master/plutus-benchmark/list \"List benchmarks\"\n[5]: https://github.com/IntersectMBO/plutus \"plutus\"\n[6]: https://github.com/IntersectMBO/cardano-ledger \"cardano-ledger\"\n[7]: https://github.com/IntersectMBO/cardano-node \"cardano-node\"\n[8]: https://hackage.haskell.org/package/flat \"flat\"\n[9]: https://hackage.haskell.org/package/base-4.21.0.0/docs/Data-List.html \"Haskell List\"\n"
  },
  {
    "path": "CIP-0139/Query_Layer_API_Comparison.md",
    "content": "# WIP Query Layer API Comparison (1)\n\n|                                                                           | Blockfrost                                                                                         | Maestro                                                                          | Koios                                                |\n|---------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------|------------------------------------------------------|\n| Accounts                                                                  |                                                                                                    |                                                                                  |                                                      |\n| List of all stake addresses                                               |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/account_list            |\n| Account info                                                              | https://blockfrost.dev/api/specific-account-address                                                | https://docs.gomaestro.org/Cardano/Indexer-API/Accounts/account-info             | https://api.koios.rest/#post-/account_info           |\n| Account reward history                                                    | https://blockfrost.dev/api/account-reward-history                                                  | https://docs.gomaestro.org/Cardano/Indexer-API/Accounts/account-rewards          | https://api.koios.rest/#post-/account_rewards        |\n| Account history                                                           | https://blockfrost.dev/api/account-history                                                         | https://docs.gomaestro.org/Cardano/Indexer-API/Accounts/account-history          | https://api.koios.rest/#post-/account_history        |\n| Account delegation history                                                | https://blockfrost.dev/api/account-delegation-history                                              | https://docs.gomaestro.org/Cardano/Indexer-API/Accounts/account-delegations      | https://api.koios.rest/#post-/account_updates        |\n| Account registration history                                              | https://blockfrost.dev/api/account-registration-history                                            | https://docs.gomaestro.org/Cardano/Indexer-API/Accounts/account-updates          | https://api.koios.rest/#post-/account_updates        |\n| Account withdrawal history                                                | https://blockfrost.dev/api/account-withdrawal-history                                              | https://docs.gomaestro.org/Cardano/Indexer-API/Accounts/account-updates          | https://api.koios.rest/#post-/account_updates        |\n| Account MIR history                                                       | https://blockfrost.dev/api/account-mir-history                                                     |                                                                                  | https://api.koios.rest/#post-/account_rewards        |\n| Account associated addresses                                              | https://blockfrost.dev/api/account-associated-addresses                                            | https://docs.gomaestro.org/Cardano/Indexer-API/Accounts/account-addresses        | https://api.koios.rest/#post-/account_addresses      |\n| Assets associated with the account addresses                              | https://blockfrost.dev/api/assets-associated-with-the-account-addresses                            | https://docs.gomaestro.org/Cardano/Indexer-API/Accounts/account-assets           | https://api.koios.rest/#post-/account_assets         |\n| Summed details of account addresses                                       | https://blockfrost.dev/api/detailed-information-about-account-associated-addresses                 |                                                                                  |                                                      |\n| Account utxos                                                             |                                                                                                    |                                                                                  | https://api.koios.rest/#post-/account_utxos          |\n| Addresses                                                                 |                                                                                                    |                                                                                  |                                                      |\n| Address details/balance                                                   | https://blockfrost.dev/api/specific-address                                                        | https://docs.gomaestro.org/Cardano/Indexer-API/Addresses/balance-by-payment-cred | https://api.koios.rest/#post-/address_info           |\n| Extended information of an address / assets                               | https://blockfrost.dev/api/extended-information-of-a-specific-address                              |                                                                                  | https://api.koios.rest/#post-/address_assets         |\n| Address details / tx count                                                | https://blockfrost.dev/api/address-details                                                         | https://docs.gomaestro.org/Cardano/Indexer-API/Addresses/tx-count-by-address     |                                                      |\n| Address UTXOs                                                             | https://blockfrost.dev/api/address-utx-os                                                          | https://docs.gomaestro.org/Cardano/Indexer-API/Addresses/utxos-by-address        | https://api.koios.rest/#post-/address_utxos          |\n| Address UTXOs of a given asset                                            | https://blockfrost.dev/api/address-utx-os-of-a-given-asset                                         |                                                                                  |                                                      |\n| UTxO references at an address                                             |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Addresses/utxo-refs-at-address    |                                                      |\n| UTxOs by multiple addresses                                               |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Addresses/utxos-by-addresses      |                                                      |\n| UTxOs by payment credential(s)                                            |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Addresses/utxos-by-payment-cred   |                                                      |\n| Address transactions                                                      | https://blockfrost.dev/api/address-transactions                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Addresses/txs-by-address          | https://api.koios.rest/#post-/address_txs            |\n| Payment credential(s) transactions                                        |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Addresses/txs-by-payment-cred     |                                                      |\n| Decode address                                                            |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Addresses/decode-address          |                                                      |\n| Assets                                                                    |                                                                                                    |                                                                                  |                                                      |\n| List of all assets                                                        | https://blockfrost.dev/api/assets                                                                  |                                                                                  | https://api.koios.rest/#get-/asset_list              |\n| List of assets registered via token registry                              |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/asset_token_registry    |\n| Asset info                                                                | https://blockfrost.dev/api/specific-asset                                                          | https://docs.gomaestro.org/Cardano/Indexer-API/Assets/asset-info                 | https://api.koios.rest/#post-/asset_info             |\n| Asset mint/burn history                                                   | https://blockfrost.dev/api/asset-history                                                           | https://docs.gomaestro.org/Cardano/Indexer-API/Assets/asset-mints                | https://api.koios.rest/#get-/asset_history           |\n| Asset transactions                                                        | https://blockfrost.dev/api/asset-transactions                                                      | https://docs.gomaestro.org/Cardano/Indexer-API/Assets/asset-txs                  | https://api.koios.rest/#get-/asset_txs               |\n| Asset addresses                                                           | https://blockfrost.dev/api/asset-addresses                                                         | https://docs.gomaestro.org/Cardano/Indexer-API/Assets/asset-addresses            | https://api.koios.rest/#get-/asset_addresses         |\n| Asset summary                                                             |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/asset_summary           |\n| NFT address                                                               |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/asset_nft_address       |\n| Asset accounts                                                            |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Assets/asset-accounts             |                                                      |\n| Asset UTxOs                                                               |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Assets/asset-utxos                | https://api.koios.rest/#post-/asset_utxos            |\n| Assets of a specific policy                                               | https://blockfrost.dev/api/assets-of-a-specific-policy                                             | https://docs.gomaestro.org/Cardano/Indexer-API/Asset%20Policy/policy-assets      | https://api.koios.rest/#get-/policy_asset_list       |\n| Policy assets information                                                 |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Asset%20Policy/policy-info        | https://api.koios.rest/#get-/policy_asset_info       |\n| Policy accounts                                                           |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Asset%20Policy/policy-accounts    |                                                      |\n| Policy addresses                                                          |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Asset%20Policy/policy-addresses   | https://api.koios.rest/#get-/policy_asset_addresses  |\n| Policy mint/burn history                                                  |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Asset%20Policy/policy-mints       | https://api.koios.rest/#get-/policy_asset_mints      |\n| Policy tx history                                                         |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Asset%20Policy/policy-txs         |                                                      |\n| Policy UTxOs                                                              |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Asset%20Policy/policy-utxos       |                                                      |\n| Blocks                                                                    |                                                                                                    |                                                                                  |                                                      |\n| List of all blocks                                                        |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/blocks                  |\n| Latest block info                                                         | https://blockfrost.dev/api/latest-block                                                            | https://docs.gomaestro.org/Cardano/Indexer-API/Blocks/latest-block               |                                                      |\n| Latest block transactions                                                 | https://blockfrost.dev/api/latest-block-transactions                                               |                                                                                  |                                                      |\n| Block info                                                                | https://blockfrost.dev/api/specific-block                                                          | https://docs.gomaestro.org/Cardano/Indexer-API/Blocks/block-info                 | https://api.koios.rest/#post-/block_info             |\n| Listing of next blocks                                                    | https://blockfrost.dev/api/listing-of-next-blocks                                                  |                                                                                  |                                                      |\n| Listing of previous blocks                                                | https://blockfrost.dev/api/listing-of-previous-blocks                                              |                                                                                  |                                                      |\n| Specific block in a slot                                                  | https://blockfrost.dev/api/specific-block-in-a-slot                                                |                                                                                  |                                                      |\n| Specific block in a slot in an epoch                                      | https://blockfrost.dev/api/specific-block-in-a-slot-in-an-epoch                                    |                                                                                  |                                                      |\n| Block transactions                                                        | https://blockfrost.dev/api/block-transactions                                                      |                                                                                  | https://api.koios.rest/#post-/block_txs              |\n| Addresses affected in a specific block                                    | https://blockfrost.dev/api/addresses-affected-in-a-specific-block                                  |                                                                                  |                                                      |\n| Epochs                                                                    |                                                                                                    |                                                                                  |                                                      |\n| Latest epoch                                                              | https://blockfrost.dev/api/latest-epoch                                                            | https://docs.gomaestro.org/Cardano/Indexer-API/Epochs/current-epoch              |                                                      |\n| Latest epoch protocol parameters                                          | https://blockfrost.dev/api/latest-epoch-protocol-parameters                                        |                                                                                  |                                                      |\n| Specific epoch                                                            | https://blockfrost.dev/api/specific-epoch                                                          | https://docs.gomaestro.org/Cardano/Indexer-API/Epochs/epoch-info                 | https://api.koios.rest/#get-/epoch_info              |\n| Listing of next epochs                                                    | https://blockfrost.dev/api/listing-of-next-epochs                                                  |                                                                                  |                                                      |\n| Listing of previous epochs                                                | https://blockfrost.dev/api/listing-of-previous-epochs                                              |                                                                                  |                                                      |\n| Stake distribution                                                        | https://blockfrost.dev/api/stake-distribution                                                      |                                                                                  |                                                      |\n| Stake distribution by pool                                                | https://blockfrost.dev/api/stake-distribution-by-pool                                              |                                                                                  |                                                      |\n| Block distribution                                                        | https://blockfrost.dev/api/block-distribution                                                      |                                                                                  |                                                      |\n| Block distribution by pool                                                | https://blockfrost.dev/api/block-distribution-by-pool                                              |                                                                                  |                                                      |\n| Block protocols                                                           |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/epoch_block_protocols   |\n| Protocol parameters by epoch                                              | https://blockfrost.dev/api/protocol-parameters                                                     |                                                                                  | https://api.koios.rest/#get-/epoch_params            |\n| Current protocol parameters                                               |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/General/protocol-parameters       | https://api.koios.rest/#get-/cli_protocol_params     |\n| General                                                                   |                                                                                                    |                                                                                  |                                                      |\n| Blockchain genesis                                                        | https://blockfrost.dev/api/blockchain-genesis                                                      |                                                                                  | https://api.koios.rest/#get-/genesis                 |\n| Blockchain system start                                                   |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/General/system-start              |                                                      |\n| Chain tip                                                                 |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/General/chain-tip                 |                                                      |\n| Mempool                                                                   |                                                                                                    |                                                                                  |                                                      |\n| Mempool transactions                                                      | https://blockfrost.dev/api/mempool                                                                 |                                                                                  |                                                      |\n| Specific transaction in the mempool                                       | https://blockfrost.dev/api/specific-transaction-in-the-mempool                                     |                                                                                  |                                                      |\n| Mempool by address                                                        | https://blockfrost.dev/api/mempool-by-address                                                      |                                                                                  |                                                      |\n| Metadata                                                                  |                                                                                                    |                                                                                  |                                                      |\n| Transaction metadata labels                                               | https://blockfrost.dev/api/transaction-metadata-labels                                             |                                                                                  |                                                      |\n| Transaction metadata content in JSON                                      | https://blockfrost.dev/api/transaction-metadata-content-in-json                                    |                                                                                  |                                                      |\n| Transaction metadata content in CBOR                                      | https://blockfrost.dev/api/transaction-metadata-content-in-cbor                                    |                                                                                  |                                                      |\n| Network                                                                   |                                                                                                    |                                                                                  |                                                      |\n| Network information                                                       | https://blockfrost.dev/api/network-information                                                     |                                                                                  | https://api.koios.rest/#get-/tip                     |\n| Query summary of blockchain eras                                          | https://blockfrost.dev/api/query-summary-of-blockchain-eras                                        | https://docs.gomaestro.org/Cardano/Indexer-API/General/era-summaries             |                                                      |\n| Historical tokenomic stats                                                |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/totals                  |\n| Param update proposals                                                    |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/param_updates           |\n| Reserve withdrawals                                                       |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/reserve_withdrawals     |\n| Treasury withdrawals                                                      |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/treasury_withdrawals    |\n| Pools                                                                     |                                                                                                    |                                                                                  |                                                      |\n| List of stake pools                                                       | https://blockfrost.dev/api/list-of-stake-pools                                                     | https://docs.gomaestro.org/Cardano/Indexer-API/Pools/list-pools                  | https://api.koios.rest/#get-/pool_list               |\n| List of stake pools with additional information                           | https://blockfrost.dev/api/list-of-stake-pools-with-additional-information                         |                                                                                  |                                                      |\n| List of retired stake pools                                               | https://blockfrost.dev/api/list-of-retired-stake-pools                                             |                                                                                  |                                                      |\n| List of retiring stake pools                                              | https://blockfrost.dev/api/list-of-retiring-stake-pools                                            |                                                                                  |                                                      |\n| List of stake pool retirements                                            |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/pool_retirements        |\n| Stake pool info                                                           | https://blockfrost.dev/api/specific-stake-pool                                                     | https://docs.gomaestro.org/Cardano/Indexer-API/Pools/pool-info                   | https://api.koios.rest/#post-/pool_info              |\n| Stake pool history                                                        | https://blockfrost.dev/api/stake-pool-history                                                      | https://docs.gomaestro.org/Cardano/Indexer-API/Pools/pool-history                | https://api.koios.rest/#get-/pool_history            |\n| Stake pool metadata                                                       | https://blockfrost.dev/api/stake-pool-metadata                                                     | https://docs.gomaestro.org/Cardano/Indexer-API/Pools/pool-metadata               | https://api.koios.rest/#post-/pool_metadata          |\n| Stake pool relays                                                         | https://blockfrost.dev/api/stake-pool-relays                                                       | https://docs.gomaestro.org/Cardano/Indexer-API/Pools/pool-relays                 | https://api.koios.rest/#get-/pool_relays             |\n| Stake pool delegators                                                     | https://blockfrost.dev/api/stake-pool-delegators                                                   | https://docs.gomaestro.org/Cardano/Indexer-API/Pools/pool-delegators             | https://api.koios.rest/#get-/pool_delegators         |\n| Stake pool delegator history                                              |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Pools/pool-historical-delegators  | https://api.koios.rest/#get-/pool_delegators_history |\n| Stake pool blocks                                                         | https://blockfrost.dev/api/stake-pool-blocks                                                       | https://docs.gomaestro.org/Cardano/Indexer-API/Pools/pool-blocks                 | https://api.koios.rest/#get-/pool_blocks             |\n| Stake pool updates                                                        | https://blockfrost.dev/api/stake-pool-updates                                                      | https://docs.gomaestro.org/Cardano/Indexer-API/Pools/pool-updates                | https://api.koios.rest/#get-/pool_updates            |\n| Stake pool stake snapshot                                                 |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/pool_stake_snapshot     |\n| Stake pool registrations                                                  |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/pool_registrations      |\n| Scripts                                                                   |                                                                                                    |                                                                                  |                                                      |\n| List of scripts                                                           | https://blockfrost.dev/api/scripts                                                                 |                                                                                  | https://api.koios.rest/#get-/native_script_list      |\n| Script info                                                               | https://blockfrost.dev/api/specific-script                                                         | https://docs.gomaestro.org/Cardano/Indexer-API/Scripts/script-by-hash            | https://api.koios.rest/#post-/script_info            |\n| Script JSON                                                               | https://blockfrost.dev/api/script-json                                                             |                                                                                  |                                                      |\n| Script CBOR                                                               | https://blockfrost.dev/api/script-cbor                                                             |                                                                                  |                                                      |\n| Redeemers of a specific script                                            | https://blockfrost.dev/api/redeemers-of-a-specific-script                                          |                                                                                  | https://api.koios.rest/#get-/script_redeemers        |\n| Script UTxOs                                                              |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/script_utxos            |\n| Datums                                                                    |                                                                                                    |                                                                                  |                                                      |\n| Datum value                                                               | https://blockfrost.dev/api/datum-value                                                             | https://docs.gomaestro.org/Cardano/Indexer-API/Datum/datum-by-hash               |                                                      |\n| Datum CBOR value                                                          | https://blockfrost.dev/api/datum-cbor-value                                                        |                                                                                  | https://api.koios.rest/#post-/datum_info             |\n| Transactions                                                              |                                                                                                    |                                                                                  |                                                      |\n| Transaction info                                                          | https://blockfrost.dev/api/specific-transaction                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Transactions/tx-info              | https://api.koios.rest/#post-/tx_info                |\n| Transaction UTXOs                                                         | https://blockfrost.dev/api/transaction-utx-os                                                      |                                                                                  | https://api.koios.rest/#post-/utxo_info              |\n| Transaction output by output ref                                          |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Transactions/txo-by-txo-ref       |                                                      |\n| Transaction outputs by output refs                                        |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Transactions/txos-by-txo-refs     |                                                      |\n| Transaction address by output ref                                         |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Transactions/address-by-txo       |                                                      |\n| Transaction stake addresses certificates                                  | https://blockfrost.dev/api/transaction-stake-addresses-certificates                                |                                                                                  |                                                      |\n| Transaction delegation certificates                                       | https://blockfrost.dev/api/transaction-delegation-certificates                                     |                                                                                  |                                                      |\n| Transaction withdrawal                                                    | https://blockfrost.dev/api/transaction-withdrawal                                                  |                                                                                  |                                                      |\n| Transaction MIRs                                                          | https://blockfrost.dev/api/transaction-mi-rs                                                       |                                                                                  |                                                      |\n| Transaction stake pool registration and update certificates               | https://blockfrost.dev/api/transaction-stake-pool-registration-and-update-certificates             |                                                                                  |                                                      |\n| Transaction stake pool retirement certificates                            | https://blockfrost.dev/api/transaction-stake-pool-retirement-certificates                          |                                                                                  |                                                      |\n| Transaction CBOR                                                          |                                                                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Transactions/tx-cbor-by-tx-hash   |                                                      |\n| Transaction metadata                                                      | https://blockfrost.dev/api/transaction-metadata                                                    |                                                                                  | https://api.koios.rest/#post-/tx_metadata            |\n| Transaction metadata labels                                               |                                                                                                    |                                                                                  | https://api.koios.rest/#get-/tx_metalabels           |\n| Transaction metadata in CBOR                                              | https://blockfrost.dev/api/transaction-metadata-in-cbor                                            |                                                                                  |                                                      |\n| Transaction redeemers                                                     | https://blockfrost.dev/api/transaction-redeemers                                                   |                                                                                  |                                                      |\n| Submit a transaction                                                      | https://blockfrost.dev/api/submit-a-transaction                                                    | https://docs.gomaestro.org/Cardano/Indexer-API/Transactions/iog-tx-submit        | https://api.koios.rest/#post-/submittx               |\n| Transaction confirmations                                                 |                                                                                                    |                                                                                  | https://api.koios.rest/#post-/tx_status              |\n| Utilities                                                                 |                                                                                                    |                                                                                  |                                                      |\n| Derive an address                                                         | https://blockfrost.dev/api/derive-an-address                                                       |                                                                                  |                                                      |\n| Submit a transaction for execution units evaluation                       | https://blockfrost.dev/api/submit-a-transaction-for-execution-units-evaluation                     | https://docs.gomaestro.org/Cardano/Indexer-API/Transactions/evaluate-redeemers   |                                                      |\n| Submit a transaction for execution units evaluation (additional UTXO set) | https://blockfrost.dev/api/submit-a-transaction-for-execution-units-evaluation-additional-utxo-set |                                                                                  |                                                      |\n"
  },
  {
    "path": "CIP-0139/README.md",
    "content": "---\nCIP: 139\nTitle: Universal Query Layer\nCategory: Tools\nStatus: Proposed\nAuthors:\n    - Vladimir Kalnitsky <klntsky@gmail.com>\n    - Giovanni Garufi <giovanni@mlabs.city>\nImplementors: []\nDiscussions:\n    - https://discord.gg/MU8vHAgmGy\n    - https://github.com/cardano-foundation/CIPs/pull/869\nSolution-To: CPS-0012\nCreated: 2024-05-14\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nA transport-agnostic query layer specification for use in dApps and wallets.\n\n## Motivation: why is this CIP necessary?\n\nSee [CPS-12 | Query Layer Standardization](https://github.com/cardano-foundation/CIPs/blob/master/CPS-0012/README.md) for motivation.\n\n## Specification\n\nThe goal of this proposal is to define a standard, JSON-based, transport-agnostic query layer for wallets to implement which covers enough functionalities to be useful to a wide set of dApps.\n\nWe will start by discussing existing query layer designs for dApps, so we can properly define the use case for this CIP. \nNext, we will define the query layer API.\nWe attempt to define the API in a transport-agnostic way: the request and return types for each endpoint are as defined in CIP-0116, with a few notable exception where the corresponding CDDL type lacked some useful information (more on this can be found in the `Query Layer API` section). Finally, we end this section with some notes on rollbacks and pagination.\n\n#### Existing Query Layer designs\n\nThere are two approaches to Cardano dApp development:\n\n1. **Using customized chain followers**. A chain follower is a program that interacts with cardano-node and processes all incoming transactions, as well as rollbacks, to maintain consistent dApp-specific state. Example: [Carp](https://dcspark.github.io/carp/docs/intro/).\n\n2. **Using general-purpose query layers**. General-purpose query layers allow to query blockchain data using a wide set of APIs that are not built with a particular dApp domain in mind. dApp state has to be constructed based on data returned from the queries. Examples: Blockfrost, Maestro.\n\nThe first approach allows for lower runtime resource consumption, but a general-purpose query layer has an advantage of being more easily reusable between dApps.\n\nIn this proposal, we are focusing on general-purpose querying only.\n\n### Query Layer API\n\nThis section contains descriptions for methods & their parameter lists.\n\nThe scope of this section is loosely based on a [comparison table for existing Cardano query layers](./Query_Layer_API_Comparison.md).\nThe goal is to make it so that the API could be implemented via simple adapters that transform requests and responses to the appropriate formats.\n\nThe payload formats used below are either references to [CIP-0116 - Standard JSON encoding for Domain Types](https://cips.cardano.org/cip/CIP-0116), which specifies cardano domain types via a JSON schema, or references to the [Query Layer JSON schema](./query-layer.json) which we defined in this CIP to define some types that are not present in the CDDL spec.\n\n[View the list of endpoints here](./endpoints.md)\n\n### Transports\n\nThe API can be implemented across several transports. The goal is to allow several different clients, possibly written in different languages, to interact with wallets.\nFor this reason we provide an [Openapi schema](./open-api.json), a [JSON-RPC](./json-rpc.json) schema, and an interface for an [injected Javascript](./ts-api.md) object in Typescript.\nWe also generate a [specification](./cip-0144.md) of this API that is compatible with [CIP-0144 | Wallet Connector API]. This defines the API as a wallet extension that can be enabled by the user, enabling a full-data wallet\nWe generate these interfaces from a high level specification of the endpoints [source](https://github.com/mlabs-haskell/query-layer-impl), ensuring that the information is consistent and easily updatable for different choices of transport layer.\n\n### Pagination\n\nIn CIP-30, pagination is not reliable: because there is no guarantee that the set of UTxOs does not change between calls. On the other hand, there are good reasons to want to paginate responses, especially when designing an universal query layer. There are, generally, no bounds on the number of results that will be returned by many of the queries we want the API to cover (e.g. there is no way to control how many UTxOs might ever be at a given script address).\nEven if we remove pagination from this API, we still have the issue that the underlying provider being used to fetch the data, could be using pagination itself. While this is somewhat of an \"implementation detail\", it can still lead to issues for end-users interacting with this API.\nIn this CIP, we have decided to remove pagination from the API. While very useful to have, it introduces potential issues about consistency of the results that affect both dApp developers and end users.\nWe hope to revisit this topic in a future CIP, to come up with a solution that does not force us to pick between consistency and efficiency.\n\n### Handling of rollbacks\n\nTransaction rollbacks are essential to blockchains: local node's view of the chain may be different from other nodes'. During conflict resolution, the node may issue a rollback event, that should be handled by dApps.\n\nCustomized chain followers, at least in principle, allow for \"live\" rollback handling: that is, a user-facing dApp can subscribe to a local view of a part of the UTxO set.\n\nGeneral purpose query layers can also handle rollbacks just fine, but they don't propagate rollback events to dApps, because they do not possess any dApp-specific info to determine if a dApp *needs* to handle a particular rollback. dApps that work with general-purpose query layers follow pull-based architecture, rather than event subscription-based, which means they just request data as needed, instead of reacting to blockchain events.\n\nIn the context of this API, rollbacks should be acknowledged as a source of potential inconsistency between data pieces returned by different queries.\n\n#### Error handling\n\nErrors should be divided in two categories:\n\n- domain errors\n- transport errors (404, 500, etc)\n\nHere we will only specify the domain errors. Users should also handle transport specific errors that can occur when interacting with the API.\n\n##### Error Types\n\n###### APIError\n\n```\nAPIErrorCode {\n\tInvalidRequest: -1,\n\tInternalError: -2,\n\tRefused: -3,\n\tAccountChange: -4,\n}\nAPIError {\n\tcode: APIErrorCode,\n\tinfo: string\n}\n```\n\n- InvalidRequest - Inputs do not conform to this spec or are otherwise invalid.\n- InternalError - An error occurred during execution of this API call.\n- Refused - The request was refused due to lack of access - e.g. wallet disconnects.\n- AccountChange - The account has changed. The dApp should call wallet.enable() to reestablish connection to the new account. The wallet should not ask for confirmation as the user was the one who initiated the account change in the first place.\n\nNote that the error codes and their meaning are copied from [CIP-30](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030#apierror). The reason is that this API will most likely live \"alongside\" the CIP-30 API, so unifying the error types reduces burden on the users.\n\n### Versioning\n\nThe API has an endpoint that must return the current version of the API implemented. While the CIP is in preparation, the version shall be set to 0.0.0. The moment this CIP is merged the version should be set to 1.0.0, and all implementations should return that as the current version. Any changes to the API should come in form of PRs to this CIP. Every change must update the version in accordance to SemVer.\n\n## Rationale: how does this CIP achieve its goals?\n\nThis CIP originates from the work layed out in the wallet working group, and specifically to address [CPS-012](https://github.com/cardano-foundation/CIPs/blob/master/CPS-0012/README.md)\n\nThis CPS initiative originated in the discussion about [Extensive Wallet Standard CIP](https://github.com/cardano-foundation/CIPs/pull/620) on the CIP Discord server ([invite](https://discord.gg/P59aNVN8zu))\nin the [`#general`](https://discord.com/channels/971785110770831360/992011119872970762/1176567729017327737) channel, continuing in a dedicated [`#query-layer-standard`](https://discord.com/channels/971785110770831360/1178763938389823598) channel.\n\nThis CIP attempts to solve the issues raised and discussed in these previous discussions and CPSs. At every step we have tried to get feedback for this CIP from the community, this includes: dApp and wallet developers, query layer providers, end users, etc.\n\nWe have attempted to define a minimal API to cover many use cases, but we expect this to evolve over time: either to fill in some gap we missed, or simply to keep up with the continuing evolution of Cardano itself. We encourage future authors to follow the versioning scheme defined above.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] There are at least two protocol adapter for any of the existing query layers that implements this spec, that can be run.\n- [ ] There are at least two offchain library that implements a provider interface for this CIP, effectively making it usable with the protocol adapter in production.\n\n### Implementation Plan\n\n- [ ] Build at least one protocol adapter for any of the existing query layers that implements this spec\n- [ ] Build at least one offchain library integration\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0139/cip-0144.md",
    "content": "#### CIP-139\n\nThis document defines the API for the `Query Layer API` as defined in CIP-139. Enabling this extension, alongside the `cip-30` extension, would give you a full-data wallet.\n\n##### Utxos\n\n###### Asset\n\n```\n{\n  \"operation\": \"getUtxosByAsset\",\n  \"request\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"asset_name\": {\n        \"$ref\": \"#/cip-116/AssetName\"\n      },\n      \"minting_policy_hash\": {\n        \"$ref\": \"#/cip-116/ScriptHash\"\n      }\n    },\n    \"required\": [\n      \"asset_name\",\n      \"minting_policy_hash\"\n    ]\n  },\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"utxos\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-116/TransactionUnspentOutput\"\n        }\n      }\n    },\n    \"required\": [\n      \"utxos\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet all UTxOs that contain some of the specified asset.\n\n###### Transaction Hash\n\n```\n{\n  \"operation\": \"getUtxosByTransactionHash\",\n  \"request\": {\n    \"$ref\": \"#/cip-139/TransactionHash\"\n  },\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"utxos\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-116/TransactionUnspentOutput\"\n        }\n      }\n    },\n    \"required\": [\n      \"utxos\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet all UTxOs produced by the transaction.\n\n###### Address\n\n```\n{\n  \"operation\": \"getUtxosByAddress\",\n  \"request\": {\n    \"$ref\": \"#/cip-116/Address\"\n  },\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"utxos\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-116/TransactionUnspentOutput\"\n        }\n      }\n    },\n    \"required\": [\n      \"utxos\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet all UTxOs present at the address.\n\n###### Payment Credential\n\n```\n{\n  \"operation\": \"getUtxosByPaymentCredential\",\n  \"request\": {\n    \"$ref\": \"#/cip-116/Credential\"\n  },\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"utxos\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-116/TransactionUnspentOutput\"\n        }\n      }\n    },\n    \"required\": [\n      \"utxos\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet all UTxOs present at the addresses which use the payment credential.\n\n###### Stake Credential\n\n```\n{\n  \"operation\": \"getUtxosByStakeCredential\",\n  \"request\": {\n    \"$ref\": \"#/cip-116/RewardAddress\"\n  },\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"utxos\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-116/TransactionUnspentOutput\"\n        }\n      }\n    },\n    \"required\": [\n      \"utxos\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet all UTxOs present at the addresses which use the stake credential.\n\n##### Block\n\n###### Number\n\n```\n{\n  \"operation\": \"getBlockByNumber\",\n  \"request\": {\n    \"$ref\": \"#/cip-139/UInt64\"\n  },\n  \"response\": {\n    \"$ref\": \"#/cip-116/Block\"\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet the block with the supplied block number.\n\n###### Hash\n\n```\n{\n  \"operation\": \"getBlockByHash\",\n  \"request\": {\n    \"$ref\": \"#/cip-116/BlockHash\"\n  },\n  \"response\": {\n    \"$ref\": \"#/cip-116/Block\"\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet the block with the supplied block hash.\n\n##### Transaction\n\n###### Hash\n\n```\n{\n  \"operation\": \"getTransactionByHash\",\n  \"request\": {\n    \"$ref\": \"#/cip-139/TransactionHash\"\n  },\n  \"response\": {\n    \"$ref\": \"#/cip-116/Transaction\"\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet the transaction with the supplied transaction hash.\n\n###### Block Number\n\n```\n{\n  \"operation\": \"getTransactionByBlockNumber\",\n  \"request\": {\n    \"$ref\": \"#/cip-139/UInt64\"\n  },\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"transactions\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-116/Transaction\"\n        }\n      }\n    },\n    \"required\": [\n      \"transactions\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet all transactions contained in the block with the supplied block number [].\n\n###### Block Hash\n\n```\n{\n  \"operation\": \"getTransactionByBlockHash\",\n  \"request\": {\n    \"$ref\": \"#/cip-116/BlockHash\"\n  },\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"transactions\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-116/Transaction\"\n        }\n      }\n    },\n    \"required\": [\n      \"transactions\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet all transactions contained in the block with the supplied block hash.\n\n##### Datum\n\n###### Hash\n\n```\n{\n  \"operation\": \"getDatumByHash\",\n  \"request\": {\n    \"$ref\": \"#/cip-116/DataHash\"\n  },\n  \"response\": {\n    \"$ref\": \"#/cip-116/PlutusData\"\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet the datum that hashes to the supplied data hash.\n\n##### Plutus Script\n\n###### Hash\n\n```\n{\n  \"operation\": \"getPlutusScriptByHash\",\n  \"request\": {\n    \"$ref\": \"#/cip-116/ScriptHash\"\n  },\n  \"response\": {\n    \"$ref\": \"#/cip-116/PlutusScript\"\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet the plutus script that hashes to the supplied script hash.\n\n##### Native Script\n\n###### Hash\n\n```\n{\n  \"operation\": \"getNativeScriptByHash\",\n  \"request\": {\n    \"$ref\": \"#/cip-116/ScriptHash\"\n  },\n  \"response\": {\n    \"$ref\": \"#/cip-116/NativeScript\"\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet the native script that hashes to the supplied script hash.\n\n##### Metadata\n\n###### Transaction Hash\n\n```\n{\n  \"operation\": \"getMetadataByTransactionHash\",\n  \"request\": {\n    \"$ref\": \"#/cip-139/TransactionHash\"\n  },\n  \"response\": {\n    \"$ref\": \"#/cip-116/TransactionMetadatum\"\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet the metadata present on the transaction with the supplied transaction hash.\n\n##### Protocol Parameters\n\n###### Latest\n\n```\n{\n  \"operation\": \"getProtocolParametersByLatest\",\n  \"request\": {},\n  \"response\": {\n    \"$ref\": \"#/cip-139/ProtocolParams\"\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet the latest protocol parameters.\n\n###### Epoch\n\n```\n{\n  \"operation\": \"getProtocolParametersByEpoch\",\n  \"request\": {\n    \"$ref\": \"#/cip-139/UInt32\"\n  },\n  \"response\": {\n    \"$ref\": \"#/cip-139/ProtocolParams\"\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet the protocol parameters at the supplied epoch number.\n\n##### Votes\n\n###### Cc Id\n\n```\n{\n  \"operation\": \"getVotesByCcId\",\n  \"request\": {\n    \"$ref\": \"#/cip-139/CCHotId\"\n  },\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"votes\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-139/VoteInfo\"\n        }\n      }\n    },\n    \"required\": [\n      \"votes\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nVotes cast by the supplied cc credential.\n\n###### Spo Id\n\n```\n{\n  \"operation\": \"getVotesBySpoId\",\n  \"request\": {\n    \"$ref\": \"#/cip-139/PoolPubKeyHash\"\n  },\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"votes\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-139/VoteInfo\"\n        }\n      }\n    },\n    \"required\": [\n      \"votes\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nVotes cast by the supplied stake pool operator.\n\n###### Drep Id\n\n```\n{\n  \"operation\": \"getVotesByDrepId\",\n  \"request\": {\n    \"$ref\": \"#/cip-139/DRepId\"\n  },\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"votes\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-139/VoteInfo\"\n        }\n      }\n    },\n    \"required\": [\n      \"votes\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nVotes cast by the supplied DRep.\n\n###### Proposal Id\n\n```\n{\n  \"operation\": \"getVotesByProposalId\",\n  \"request\": {\n    \"$ref\": \"#/cip-139/ProposalId\"\n  },\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"votes\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-139/VoteInfo\"\n        }\n      }\n    },\n    \"required\": [\n      \"votes\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nVotes cast on the supplied proposal.\n\n##### Drep\n\n###### All\n\n```\n{\n  \"operation\": \"getAllDreps\",\n  \"request\": {},\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"dreps\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-139/DRepInfo\"\n        }\n      }\n    },\n    \"required\": [\n      \"dreps\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet all the known DReps.\n\n###### Id\n\n```\n{\n  \"operation\": \"getDrepById\",\n  \"request\": {\n    \"$ref\": \"#/cip-139/DRepId\"\n  },\n  \"response\": {\n    \"$ref\": \"#/cip-139/DRepInfo\"\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet a specific DRep by id.\n\n###### Stake Credential\n\n```\n{\n  \"operation\": \"getDrepByStakeCredential\",\n  \"request\": {\n    \"$ref\": \"#/cip-116/RewardAddress\"\n  },\n  \"response\": {\n    \"$ref\": \"#/cip-139/DRepInfo\"\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet the DRep that the stake credential has delegated to.\n\n##### Committee Member\n\n###### All\n\n```\n{\n  \"operation\": \"getAllCommitteeMembers\",\n  \"request\": {},\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"cc_members\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-139/CCMember\"\n        }\n      }\n    },\n    \"required\": [\n      \"cc_members\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet all known committee members.\n\n###### Id\n\n```\n{\n  \"operation\": \"getCommitteeMemberById\",\n  \"request\": {\n    \"$ref\": \"#/cip-139/CCHotId\"\n  },\n  \"response\": {\n    \"$ref\": \"#/cip-139/CCMember\"\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet a specific Committee member by id.\n\n##### Pool\n\n###### All\n\n```\n{\n  \"operation\": \"getAllPools\",\n  \"request\": {},\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"pools\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-139/Pool\"\n        }\n      }\n    },\n    \"required\": [\n      \"pools\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet all known stake pools.\n\n###### Id\n\n```\n{\n  \"operation\": \"getPoolById\",\n  \"request\": {\n    \"$ref\": \"#/cip-139/PoolPubKeyHash\"\n  },\n  \"response\": {\n    \"$ref\": \"#/cip-139/Pool\"\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet a specific stake pool by id.\n\n##### Proposal\n\n###### All\n\n```\n{\n  \"operation\": \"getAllProposals\",\n  \"request\": {},\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"proposals\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-139/Proposal\"\n        }\n      }\n    },\n    \"required\": [\n      \"proposals\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet all known proposals.\n\n###### Id\n\n```\n{\n  \"operation\": \"getProposalById\",\n  \"request\": {\n    \"$ref\": \"#/cip-139/ProposalId\"\n  },\n  \"response\": {\n    \"$ref\": \"#/cip-139/Proposal\"\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet a specific proposal by id.\n\n##### Era\n\n###### Summary\n\n```\n{\n  \"operation\": \"getEraBySummary\",\n  \"request\": {},\n  \"response\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"summary\": {\n        \"type\": \"array\",\n        \"items\": {\n          \"$ref\": \"#/cip-139/EraSummary\"\n        }\n      }\n    },\n    \"required\": [\n      \"summary\"\n    ]\n  },\n  \"errors\": [\n    {\n      \"$ref\": \"#/appendix/APIError\"\n    }\n  ]\n}\n```\n\nGet the start and end of each era along with parameters that can vary between hard forks.\n\n\n### Versioning\n\nWhile the CIP is in preparation, the version shall be set to `0.0.0`. The moment this CIP is merged the versions shall be set to `1.0.0`, and all implementations should consider that the current version. Any changes to the API should come in form of PRs to this CIP.\n\n| API | Version |\n| --- | --- |\n| CIP-144 | 0.0.0 |"
  },
  {
    "path": "CIP-0139/endpoints.md",
    "content": "# Endpoints\n\nThis document contains a list of endpoints for a universal query layer. Each section is named after a resource that can be obtained from the query layer, and each subsection defines different ways to obtain that resource.\n\n\n## Contents\n\n1. [Utxos](#utxos)\n1. [Block](#block)\n1. [Transaction](#transaction)\n1. [Datum](#datum)\n1. [Plutus Script](#plutus-script)\n1. [Native Script](#native-script)\n1. [Metadata](#metadata)\n1. [Protocol Parameters](#protocol-parameters)\n1. [Votes](#votes)\n1. [Drep](#drep)\n1. [Committee](#committee)\n1. [Pool](#pool)\n1. [Proposal](#proposal)\n1. [Era](#era)\n\n## Utxos\n\n### Asset\n\nGet all UTxOs that contain some of the specified asset\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_utxos_asset)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"asset_name\": \"504154415445\",\n  \"minting_policy_hash\": \"fa055f570e99cfd65e86a5e4488220f5a2cfd8f2be90d98f54d3eafa\"\n}\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"utxos\": [\n    {\n      \"input\": {\n        \"transaction_id\": \"eca40340fa6e65d964915ba4bc8bd811a0493d263ffe95875291114cbb2d0686\",\n        \"index\": 4201022945\n      },\n      \"output\": {\n        \"address\": \"stake1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5egfu2p0u\",\n        \"amount\": {\n          \"coin\": \"0\"\n        }\n      }\n    },\n    {\n      \"input\": {\n        \"transaction_id\": \"eca40340fa6e65d964915ba4bc8bd811a0493d263ffe95875291114cbb2d0686\",\n        \"index\": 1609920239\n      },\n      \"output\": {\n        \"address\": \"37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na\",\n        \"amount\": {\n          \"coin\": \"0\"\n        }\n      }\n    }\n  ]\n}\n```\n</details>\n\n### Transaction Hash\n\nGet all UTxOs produced by the transaction\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_utxos_transaction_hash)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"fbc1da46d62a431e69855ad48a6b49b0e2aaafc6fd3dc4a066c6851b7bd31a91\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"utxos\": [\n    {\n      \"input\": {\n        \"transaction_id\": \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n        \"index\": 940381344\n      },\n      \"output\": {\n        \"address\": \"37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na\",\n        \"amount\": {\n          \"coin\": \"0\"\n        }\n      }\n    }\n  ]\n}\n```\n</details>\n\n### Address\n\nGet all UTxOs present at the address\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_utxos_address)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"stake1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5egfu2p0u\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"utxos\": [\n    {\n      \"input\": {\n        \"transaction_id\": \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n        \"index\": 1477617979\n      },\n      \"output\": {\n        \"address\": \"37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na\",\n        \"amount\": {\n          \"coin\": \"175253\"\n        }\n      }\n    },\n    {\n      \"input\": {\n        \"transaction_id\": \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n        \"index\": 4056981757\n      },\n      \"output\": {\n        \"address\": \"addr1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0yu80w\",\n        \"amount\": {\n          \"coin\": \"0\"\n        }\n      }\n    }\n  ]\n}\n```\n</details>\n\n### Payment Credential\n\nGet all UTxOs present at the addresses which use the payment credential\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_utxos_payment_credential)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"tag\": \"pubkey_hash\",\n  \"value\": \"cbc69eb73a694e55425ed0c15f6674a33e8f2f7236b52cba5fd30129\"\n}\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"utxos\": [\n    {\n      \"input\": {\n        \"transaction_id\": \"c6726192662abeab149098095eabe004ecbec47f5e564748ab0d394affca47d9\",\n        \"index\": 2697252292\n      },\n      \"output\": {\n        \"address\": \"addr1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0yu80w\",\n        \"amount\": {\n          \"coin\": \"0\"\n        }\n      }\n    },\n    {\n      \"input\": {\n        \"transaction_id\": \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n        \"index\": 3633155075\n      },\n      \"output\": {\n        \"address\": \"37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na\",\n        \"amount\": {\n          \"coin\": \"7\"\n        }\n      }\n    }\n  ]\n}\n```\n</details>\n\n### Stake Credential\n\nGet all UTxOs present at the addresses which use the stake credential\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_utxos_stake_credential)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"stake1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5egfu2p0u\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"utxos\": [\n    {\n      \"input\": {\n        \"transaction_id\": \"fbc1da46d62a431e69855ad48a6b49b0e2aaafc6fd3dc4a066c6851b7bd31a91\",\n        \"index\": 2129548537\n      },\n      \"output\": {\n        \"address\": \"37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na\",\n        \"amount\": {\n          \"coin\": \"81751092945\"\n        }\n      }\n    }\n  ]\n}\n```\n</details>\n\n## Block\n\n### Number\n\nGet the block with the supplied block number\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_block_number)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"0\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"auxiliary_data_set\": {},\n  \"header\": {\n    \"body_signature\": \"136c77da7cc6f02fc1af792625a5b75d8f2d83a71b27635ba228ff7c4bf13e8e9e0318e1aea7cced706c828404377d0991de77a75325c0651b5a45099dd72032c7647d8a1b76e96b8fd823198d199f3663caf27847384974b3f0a2eaaa2ad85e443bcc028ce4be9465858260e9dd1f437991aef8e43aaceab1c051ede06630ec4210f2150abc8a1ac01408061ac8867a5930f0051ade40a2d79eaa06aab715e9a9ea7af88b69a677c3314d91d15ee434bdd51e8c46aa97b1bf185cc60c48ef63324ffa914fbb1abd55d46c68cba8cd8077da8f88a6cdebc84f937bfa375505dcb95d243844b7fd08e0bc34bc083a2ad090c6b6cfd6beaec2064fc15d57540f80d93f378319dafda2668ea330d59d0ae7efd1b5f015a37eed6bcd21cd794675ebe52e31709f15e69b2ca3903acf1006c746a0b32ae7f5f469884c70a8b01d744c086474d3bbc8b86e19e1d0cff76509a143bb1bd16c6ca6a0d6020c746629485f222d649c99db064f8c9b66c199f12cc46a693437895242a01915b4f958f6ac4587706f62762e6e45f20394ad6cf93f04e0de89b5525099ed6e40d3b46ac25e1a4ddb714b34d0d27978ca16aa43d32f190029b17ef50856ba8288fb3059398204\",\n    \"header_body\": {\n      \"block_number\": 795642744,\n      \"slot\": \"0\",\n      \"issuer_vkey\": \"165767b4ab5815811983109a23250978bde372be3a36cd0bf4e6d936b2d23d08\",\n      \"vrf_vkey\": \"f517f9db8eb29964be142f29fd85d86b320175067198b0e9f867bbba511c42ee\",\n      \"vrf_result\": {\n        \"output\": \"9f1be1c3\",\n        \"proof\": \"f370\"\n      },\n      \"block_body_size\": 3194471960,\n      \"block_body_hash\": \"3ee393fd2a52c0a909af1814ee5764f02ed3b85d9d3247badea629da066ad244\",\n      \"operational_cert\": {\n        \"hot_vkey\": \"8272bd2deeafc2d91b2b16796b50960457c20aa5fadedcaa9e1bce26d9d965fb\",\n        \"kes_period\": 518134050,\n        \"sequence_number\": 1254271129,\n        \"sigma\": \"0e003769525373e7214d716fb4a02d1a0da0fdcbaa8fdd03295d577747e8854cc37dde5784f0d0d0172b67efb9e284e250bdb0b847dd70b72d6e161b0eae9409\"\n      },\n      \"protocol_version\": {\n        \"major\": 3571437749,\n        \"minor\": 1179319841\n      }\n    }\n  },\n  \"invalid_transactions\": [\n    1049628808\n  ],\n  \"transaction_bodies\": [\n    {\n      \"inputs\": [\n        {\n          \"transaction_id\": \"c6726192662abeab149098095eabe004ecbec47f5e564748ab0d394affca47d9\",\n          \"index\": 3734755317\n        }\n      ],\n      \"outputs\": [\n        {\n          \"address\": \"addr1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0yu80w\",\n          \"amount\": {\n            \"coin\": \"0\"\n          }\n        },\n        {\n          \"address\": \"37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na\",\n          \"amount\": {\n            \"coin\": \"0\"\n          }\n        }\n      ],\n      \"fee\": \"54969\"\n    },\n    {\n      \"inputs\": [\n        {\n          \"transaction_id\": \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n          \"index\": 3792213977\n        }\n      ],\n      \"outputs\": [\n        {\n          \"address\": \"stake1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5egfu2p0u\",\n          \"amount\": {\n            \"coin\": \"0\"\n          }\n        },\n        {\n          \"address\": \"addr1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0yu80w\",\n          \"amount\": {\n            \"coin\": \"208074\"\n          }\n        }\n      ],\n      \"fee\": \"0\"\n    }\n  ],\n  \"transaction_witness_sets\": []\n}\n```\n</details>\n\n### Hash\n\nGet the block with the supplied block hash\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_block_hash)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"e9096ec2733dfb25be098b8ab96ff8f598f9dc9b57b7ecf43b6f215073306755\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"auxiliary_data_set\": {},\n  \"header\": {\n    \"body_signature\": \"618b6723c85ac208a076aaed1403cb2e1defe348df9c0a29b2320096dcb99c8e7b1caaeacb48b6c649f7c3b5ff472368a3cc358144977e04630659c92a1f013a83b2290f7ed85e414220eea362cd8c6b257cf91db67e4c6925f1a3dfda5b436a06c5ea8fc7f31d1d350c15b058cd8ece85ca5ce04d093b0072908905f4549fdaaeebb5b70fbb933ef4c58c8dcc1fbfe410b8e0dc590a146f040a392962f99c5c0022f7b3185ac21cd663abe019c7e356340348853e65c96064f014c2a02243431abf30516068a4ac8fde6d13c5e7f24d39f2bf2ad384590cd655f2487448db4b000039aa046b90d61e0bb05c1a92a8982d87774b92d21dde8d4df2349e853561fef6e8d82e5894836bc6912d13df16823ffc36aa2bab392e7dabc37931f879c750cb1fae261821c26f3350dd687efce8411aeedbdd9e94777c27ffe9579778cf444f82597995c7a96cd7913166d1e1786eb976958328969af10c814e0a0eb5fbddef29482057dfa9366599acdc4977f3938e62cfed90cadf5ca0813f84c2580a6a2be36944e415d81582dc15c4858c319fcadeb1705abf753f781242cebdb83ae69e313cfd66a241bd5f0d447c77672ca878a1fbbc2f66e1e1c0edf9c7283582\",\n    \"header_body\": {\n      \"block_number\": 3044719066,\n      \"slot\": \"63441\",\n      \"issuer_vkey\": \"47d9426dba32ee6800bd6042ecb31162c26a5f9d4548d6b898be3696663cb1e9\",\n      \"vrf_vkey\": \"2659846f2ec75dab36fb08b59e4b15a61cc7fbad655f4d8cd6dc5871335321e3\",\n      \"vrf_result\": {\n        \"output\": \"8f7b6d7a61b9\",\n        \"proof\": \"605199ad5a52f09e63\"\n      },\n      \"block_body_size\": 3287206835,\n      \"block_body_hash\": \"fea424dee30c903d27100067c73b54517467886bedfcf6b2752025a74c86b28d\",\n      \"operational_cert\": {\n        \"hot_vkey\": \"4ba98524fc74be4c9801a279602cbdd25c1b8c864da36e46110653d46cfc773b\",\n        \"kes_period\": 2895629300,\n        \"sequence_number\": 3801291659,\n        \"sigma\": \"c0d9a3eccedbc707724c5e2e6052e8f6cb7c35c7f9bb283535d10f45f37ba188737583bec3bf3e8c97c5f016ea89bd2e907a948ec0a2394bf2411fb2494d613f\"\n      },\n      \"protocol_version\": {\n        \"major\": 2583355968,\n        \"minor\": 1095517331\n      }\n    }\n  },\n  \"invalid_transactions\": [\n    3906487169\n  ],\n  \"transaction_bodies\": [\n    {\n      \"inputs\": [\n        {\n          \"transaction_id\": \"eca40340fa6e65d964915ba4bc8bd811a0493d263ffe95875291114cbb2d0686\",\n          \"index\": 1586486251\n        },\n        {\n          \"transaction_id\": \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n          \"index\": 3307196019\n        }\n      ],\n      \"outputs\": [\n        {\n          \"address\": \"addr1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0yu80w\",\n          \"amount\": {\n            \"coin\": \"6\"\n          }\n        }\n      ],\n      \"fee\": \"356709740\"\n    },\n    {\n      \"inputs\": [\n        {\n          \"transaction_id\": \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n          \"index\": 1277654959\n        }\n      ],\n      \"outputs\": [\n        {\n          \"address\": \"stake1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5egfu2p0u\",\n          \"amount\": {\n            \"coin\": \"0\"\n          }\n        },\n        {\n          \"address\": \"37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na\",\n          \"amount\": {\n            \"coin\": \"0\"\n          }\n        }\n      ],\n      \"fee\": \"207293551\"\n    }\n  ],\n  \"transaction_witness_sets\": []\n}\n```\n</details>\n\n## Transaction\n\n### Hash\n\nGet the transaction with the supplied transaction hash\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_transaction_hash)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"eca40340fa6e65d964915ba4bc8bd811a0493d263ffe95875291114cbb2d0686\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"body\": {\n    \"inputs\": [\n      {\n        \"transaction_id\": \"fbc1da46d62a431e69855ad48a6b49b0e2aaafc6fd3dc4a066c6851b7bd31a91\",\n        \"index\": 2711013252\n      },\n      {\n        \"transaction_id\": \"c6726192662abeab149098095eabe004ecbec47f5e564748ab0d394affca47d9\",\n        \"index\": 1026523974\n      }\n    ],\n    \"outputs\": [\n      {\n        \"address\": \"37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na\",\n        \"amount\": {\n          \"coin\": \"82519\"\n        }\n      }\n    ],\n    \"fee\": \"0\"\n  },\n  \"is_valid\": true,\n  \"witness_set\": {}\n}\n```\n</details>\n\n### Block Number\n\nGet all transactions contained in the block with the supplied block number []\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_transaction_block_number)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"0\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"transactions\": [\n    {\n      \"body\": {\n        \"inputs\": [\n          {\n            \"transaction_id\": \"eca40340fa6e65d964915ba4bc8bd811a0493d263ffe95875291114cbb2d0686\",\n            \"index\": 1290535197\n          },\n          {\n            \"transaction_id\": \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n            \"index\": 1270916115\n          }\n        ],\n        \"outputs\": [\n          {\n            \"address\": \"37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na\",\n            \"amount\": {\n              \"coin\": \"6\"\n            }\n          },\n          {\n            \"address\": \"stake1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5egfu2p0u\",\n            \"amount\": {\n              \"coin\": \"0\"\n            }\n          }\n        ],\n        \"fee\": \"8721093\"\n      },\n      \"is_valid\": false,\n      \"witness_set\": {}\n    },\n    {\n      \"body\": {\n        \"inputs\": [\n          {\n            \"transaction_id\": \"c6726192662abeab149098095eabe004ecbec47f5e564748ab0d394affca47d9\",\n            \"index\": 2137591745\n          },\n          {\n            \"transaction_id\": \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n            \"index\": 3073661304\n          }\n        ],\n        \"outputs\": [\n          {\n            \"address\": \"addr1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0yu80w\",\n            \"amount\": {\n              \"coin\": \"0\"\n            }\n          },\n          {\n            \"address\": \"addr1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0yu80w\",\n            \"amount\": {\n              \"coin\": \"76294560\"\n            }\n          }\n        ],\n        \"fee\": \"0\"\n      },\n      \"is_valid\": true,\n      \"witness_set\": {}\n    }\n  ]\n}\n```\n</details>\n\n### Block Hash\n\nGet all transactions contained in the block with the supplied block hash\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_transaction_block_hash)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"3f18df12b07c2f4c2393c43d24189d9d40e005cf66060e1473948d061c6b03ee\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"transactions\": [\n    {\n      \"body\": {\n        \"inputs\": [\n          {\n            \"transaction_id\": \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n            \"index\": 2411299684\n          }\n        ],\n        \"outputs\": [\n          {\n            \"address\": \"37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na\",\n            \"amount\": {\n              \"coin\": \"0\"\n            }\n          },\n          {\n            \"address\": \"stake1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5egfu2p0u\",\n            \"amount\": {\n              \"coin\": \"0\"\n            }\n          }\n        ],\n        \"fee\": \"0\"\n      },\n      \"is_valid\": true,\n      \"witness_set\": {}\n    }\n  ]\n}\n```\n</details>\n\n## Datum\n\n### Hash\n\nGet the datum that hashes to the supplied data hash\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_datum_hash)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"58c9a67f503ff9d29c332ccda2d4eaf77a9288d43b01d967a0b61726c81cfe80\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"tag\": \"list\",\n  \"contents\": [\n    {\n      \"tag\": \"map\",\n      \"contents\": []\n    },\n    {\n      \"tag\": \"list\",\n      \"contents\": [\n        {\n          \"tag\": \"list\",\n          \"contents\": [\n            {\n              \"tag\": \"map\",\n              \"contents\": []\n            },\n            {\n              \"tag\": \"list\",\n              \"contents\": [\n                {\n                  \"tag\": \"constr\",\n                  \"alternative\": \"0\",\n                  \"data\": []\n                }\n              ]\n            }\n          ]\n        },\n        {\n          \"tag\": \"map\",\n          \"contents\": []\n        }\n      ]\n    }\n  ]\n}\n```\n</details>\n\n## Plutus Script\n\n### Hash\n\nGet the plutus script that hashes to the supplied script hash\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_plutus_script_hash)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"7ab2cf4ea16b2d5b8a71fd6c220e11fdb5f3484f043ca7d65fb385b3\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"language\": \"plutus_v3\",\n  \"bytes\": \"10\"\n}\n```\n</details>\n\n## Native Script\n\n### Hash\n\nGet the native script that hashes to the supplied script hash\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_native_script_hash)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"f02a5b9b9c750f691ed46f591b8170c3fd26f9d184ec8dd35bdba3c7\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"tag\": \"pubkey\",\n  \"pubkey\": \"ca42e84ecfc9efd10bc10d42e22b22d2289c161cbdde6376415b5871\"\n}\n```\n</details>\n\n## Metadata\n\n### Transaction Hash\n\nGet the metadata present on the transaction with the supplied transaction hash\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_metadata_transaction_hash)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"tag\": \"map\",\n  \"contents\": [\n    {\n      \"key\": {\n        \"tag\": \"list\",\n        \"contents\": [\n          {\n            \"tag\": \"string\",\n            \"value\": \"1{10-64}\"\n          },\n          {\n            \"tag\": \"int\",\n            \"value\": \"985574311\"\n          }\n        ]\n      },\n      \"value\": {\n        \"tag\": \"list\",\n        \"contents\": [\n          {\n            \"tag\": \"map\",\n            \"contents\": [\n              {\n                \"key\": {\n                  \"tag\": \"bytes\",\n                  \"value\": \"21af83472287ded28aae95a6eb10\"\n                },\n                \"value\": {\n                  \"tag\": \"string\",\n                  \"value\": \"I{10-64}\"\n                }\n              }\n            ]\n          }\n        ]\n      }\n    }\n  ]\n}\n```\n</details>\n\n## Protocol Parameters\n\n### Latest\n\nGet the latest protocol parameters\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_protocol_parameters_latest)\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"ada_per_utxo_byte\": \"8214865595\",\n  \"collateral_percentage\": 3252825201,\n  \"cost_models\": {},\n  \"d\": {\n    \"numerator\": \"0\",\n    \"denominator\": \"3991\"\n  },\n  \"execution_costs\": {\n    \"mem_price\": {\n      \"numerator\": \"0\",\n      \"denominator\": \"0\"\n    },\n    \"step_price\": {\n      \"numerator\": \"0\",\n      \"denominator\": \"33538740\"\n    }\n  },\n  \"expansion_rate\": {\n    \"numerator\": \"0\",\n    \"denominator\": \"0\"\n  },\n  \"key_deposit\": \"805976\",\n  \"max_block_body_size\": 4067656587,\n  \"max_block_ex_units\": {\n    \"mem\": \"0\",\n    \"steps\": \"70847615\"\n  },\n  \"max_block_header_size\": 1371478347,\n  \"max_collateral_inputs\": 5466590,\n  \"max_epoch\": 1884857497,\n  \"max_tx_ex_units\": {\n    \"mem\": \"742373\",\n    \"steps\": \"6022896\"\n  },\n  \"max_tx_size\": 2695796622,\n  \"max_value_size\": 4174634245,\n  \"min_pool_cost\": \"18062\",\n  \"minfee_a\": \"0\",\n  \"minfee_b\": \"5357594652\",\n  \"n_opt\": \"378123732\",\n  \"pool_deposit\": \"46\",\n  \"pool_pledge_influence\": {\n    \"numerator\": \"0\",\n    \"denominator\": \"0\"\n  },\n  \"protocol_version\": {\n    \"major\": 3754287127,\n    \"minor\": 1343856109\n  },\n  \"treasury_growth_rate\": {\n    \"numerator\": \"221491\",\n    \"denominator\": \"0\"\n  },\n  \"pool_voting_thresholds\": [\n    {\n      \"numerator\": \"67527890493\",\n      \"denominator\": \"0\"\n    },\n    {\n      \"numerator\": \"0\",\n      \"denominator\": \"71472732409\"\n    }\n  ],\n  \"drep_voting_thresholds\": [\n    {\n      \"numerator\": \"63\",\n      \"denominator\": \"0\"\n    },\n    {\n      \"numerator\": \"0\",\n      \"denominator\": \"0\"\n    }\n  ],\n  \"committee_min_size\": \"0\",\n  \"committee_max_term_length\": 1479674763,\n  \"gov_action_lifetime\": 74433822,\n  \"gov_action_deposit\": \"24159164462\",\n  \"drep_deposit\": \"4\",\n  \"drep_activity\": 3383589293,\n  \"min_fee_ref_script_cost_per_byte\": {\n    \"numerator\": \"0\",\n    \"denominator\": \"2\"\n  }\n}\n```\n</details>\n\n### Epoch\n\nGet the protocol parameters at the supplied epoch number\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_protocol_parameters_epoch)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n3733274909\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"ada_per_utxo_byte\": \"0\",\n  \"collateral_percentage\": 1617421275,\n  \"cost_models\": {},\n  \"d\": {\n    \"numerator\": \"0\",\n    \"denominator\": \"0\"\n  },\n  \"execution_costs\": {\n    \"mem_price\": {\n      \"numerator\": \"0\",\n      \"denominator\": \"33570\"\n    },\n    \"step_price\": {\n      \"numerator\": \"56901\",\n      \"denominator\": \"7\"\n    }\n  },\n  \"expansion_rate\": {\n    \"numerator\": \"0\",\n    \"denominator\": \"8811326272\"\n  },\n  \"key_deposit\": \"81689650\",\n  \"max_block_body_size\": 3533825275,\n  \"max_block_ex_units\": {\n    \"mem\": \"9789470\",\n    \"steps\": \"0\"\n  },\n  \"max_block_header_size\": 3659142665,\n  \"max_collateral_inputs\": 4240535489,\n  \"max_epoch\": 1042276500,\n  \"max_tx_ex_units\": {\n    \"mem\": \"0\",\n    \"steps\": \"959332\"\n  },\n  \"max_tx_size\": 2519810430,\n  \"max_value_size\": 295500448,\n  \"min_pool_cost\": \"0\",\n  \"minfee_a\": \"0\",\n  \"minfee_b\": \"848900193\",\n  \"n_opt\": \"0\",\n  \"pool_deposit\": \"880\",\n  \"pool_pledge_influence\": {\n    \"numerator\": \"0\",\n    \"denominator\": \"67\"\n  },\n  \"protocol_version\": {\n    \"major\": 2763174108,\n    \"minor\": 968052096\n  },\n  \"treasury_growth_rate\": {\n    \"numerator\": \"4607565\",\n    \"denominator\": \"0\"\n  },\n  \"pool_voting_thresholds\": [\n    {\n      \"numerator\": \"5210139\",\n      \"denominator\": \"7\"\n    },\n    {\n      \"numerator\": \"618128115\",\n      \"denominator\": \"6733225\"\n    }\n  ],\n  \"drep_voting_thresholds\": [\n    {\n      \"numerator\": \"0\",\n      \"denominator\": \"0\"\n    },\n    {\n      \"numerator\": \"0\",\n      \"denominator\": \"7348778\"\n    }\n  ],\n  \"committee_min_size\": \"0\",\n  \"committee_max_term_length\": 3523439575,\n  \"gov_action_lifetime\": 3541801449,\n  \"gov_action_deposit\": \"0\",\n  \"drep_deposit\": \"24\",\n  \"drep_activity\": 1127315307,\n  \"min_fee_ref_script_cost_per_byte\": {\n    \"numerator\": \"871793417\",\n    \"denominator\": \"351068\"\n  }\n}\n```\n</details>\n\n## Votes\n\n### Cc Id\n\nVotes cast by the supplied cc credential\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_votes_cc_id)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"cc_hot1qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqvcdjk7\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"votes\": [\n    {\n      \"proposal_id\": \"gov_action1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpzklpgpf\",\n      \"vote_tx_hash\": \"c6726192662abeab149098095eabe004ecbec47f5e564748ab0d394affca47d9\",\n      \"vote\": \"abstain\"\n    }\n  ]\n}\n```\n</details>\n\n### Spo Id\n\nVotes cast by the supplied stake pool operator\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_votes_spo_id)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"pool12a39rkzfylvn9wfe8j6y8ucq6g2l4mw4azj70y0gd8ejczznyj2\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"votes\": [\n    {\n      \"proposal_id\": \"gov_action1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpzklpgpf\",\n      \"vote_tx_hash\": \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n      \"vote\": \"abstain\"\n    },\n    {\n      \"proposal_id\": \"gov_action1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpzklpgpf\",\n      \"vote_tx_hash\": \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n      \"vote\": \"yes\"\n    }\n  ]\n}\n```\n</details>\n\n### Drep Id\n\nVotes cast by the supplied DRep\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_votes_drep_id)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"drep1ygqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq7vlc9n\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"votes\": [\n    {\n      \"proposal_id\": \"gov_action1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpzklpgpf\",\n      \"vote_tx_hash\": \"c6726192662abeab149098095eabe004ecbec47f5e564748ab0d394affca47d9\",\n      \"vote\": \"no\"\n    },\n    {\n      \"proposal_id\": \"gov_action1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpzklpgpf\",\n      \"vote_tx_hash\": \"fbc1da46d62a431e69855ad48a6b49b0e2aaafc6fd3dc4a066c6851b7bd31a91\",\n      \"vote\": \"abstain\"\n    }\n  ]\n}\n```\n</details>\n\n### Proposal Id\n\nVotes cast on the supplied proposal\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_votes_proposal_id)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"gov_action1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpzklpgpf\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"votes\": [\n    {\n      \"proposal_id\": \"gov_action1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpzklpgpf\",\n      \"vote_tx_hash\": \"fbc1da46d62a431e69855ad48a6b49b0e2aaafc6fd3dc4a066c6851b7bd31a91\",\n      \"vote\": \"abstain\"\n    }\n  ]\n}\n```\n</details>\n\n## Drep\n\n### All\n\nGet all the known DReps\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_drep_all)\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"dreps\": [\n    {\n      \"drep_id\": \"drep1ygqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq7vlc9n\",\n      \"amount\": \"73330\",\n      \"active\": true\n    }\n  ]\n}\n```\n</details>\n\n### Id\n\nGet a specific DRep by id\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_drep_id)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"drep1ygqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq7vlc9n\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"drep_id\": \"drep1ygqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq7vlc9n\",\n  \"amount\": \"7149\",\n  \"active\": true\n}\n```\n</details>\n\n### Stake Credential\n\nGet the DRep that the stake credential has delegated to\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_drep_stake_credential)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"stake1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5egfu2p0u\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"drep_id\": \"drep1ygqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq7vlc9n\",\n  \"amount\": \"3566817384\",\n  \"active\": false\n}\n```\n</details>\n\n## Committee\n\n### All\n\nGet all known committee members\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_committee_all)\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"cc_members\": [\n    {\n      \"cc_cold_key\": \"cc_cold1zvqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq6kflvs\",\n      \"cc_hot_key\": \"cc_hot1qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqvcdjk7\",\n      \"status\": \"not_authorised\"\n    },\n    {\n      \"cc_cold_key\": \"cc_cold1zvqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq6kflvs\",\n      \"cc_hot_key\": \"cc_hot1qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqvcdjk7\",\n      \"status\": \"resigned\"\n    }\n  ]\n}\n```\n</details>\n\n### Id\n\nGet a specific Committee member by id\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_committee_id)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"cc_hot1qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqvcdjk7\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"cc_cold_key\": \"cc_cold1zvqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq6kflvs\",\n  \"cc_hot_key\": \"cc_hot1qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqvcdjk7\",\n  \"status\": \"authorised\"\n}\n```\n</details>\n\n## Pool\n\n### All\n\nGet all known stake pools\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_pool_all)\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"pools\": [\n    {\n      \"pool_id\": \"pool12a39rkzfylvn9wfe8j6y8ucq6g2l4mw4azj70y0gd8ejczznyj2\",\n      \"status\": \"active\",\n      \"active_stake\": \"65155183259\",\n      \"live_stake\": \"81525215\"\n    }\n  ]\n}\n```\n</details>\n\n### Id\n\nGet a specific stake pool by id\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_pool_id)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"pool12a39rkzfylvn9wfe8j6y8ucq6g2l4mw4azj70y0gd8ejczznyj2\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"pool_id\": \"pool12a39rkzfylvn9wfe8j6y8ucq6g2l4mw4azj70y0gd8ejczznyj2\",\n  \"status\": \"active\",\n  \"active_stake\": \"0\",\n  \"live_stake\": \"1\"\n}\n```\n</details>\n\n## Proposal\n\n### All\n\nGet all known proposals\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_proposal_all)\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"proposals\": [\n    {\n      \"proposal_id\": \"gov_action1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpzklpgpf\"\n    }\n  ]\n}\n```\n</details>\n\n### Id\n\nGet a specific proposal by id\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_proposal_id)\n\n#### Request\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n\"gov_action1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpzklpgpf\"\n```\n</details>\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"proposal_id\": \"gov_action1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpzklpgpf\"\n}\n```\n</details>\n\n## Era\n\n### Summary\n\nGet the start and end of each era along with parameters that can vary between hard forks\n\n[Link to OpenApi endpoint](https://mlabs-haskell.github.io/query-layer-impl/index.html#/default/get_era_summary)\n\n#### Response\n\n\n<details>\n<summary>Show Example: </summary>\n\n```\n{\n  \"summary\": [\n    {\n      \"start\": {\n        \"time\": \"3921276999\",\n        \"slot\": \"0\",\n        \"epoch\": 2336213278\n      },\n      \"end\": {\n        \"time\": \"41781628\",\n        \"slot\": \"0\",\n        \"epoch\": 2978580216\n      },\n      \"parameters\": {\n        \"epoch_length\": 720472590,\n        \"slot_length\": 1582308913,\n        \"safe_zone\": 2230198492\n      }\n    },\n    {\n      \"start\": {\n        \"time\": \"0\",\n        \"slot\": \"745258045\",\n        \"epoch\": 4094381277\n      },\n      \"end\": {\n        \"time\": \"810001507\",\n        \"slot\": \"1831\",\n        \"epoch\": 2068430763\n      },\n      \"parameters\": {\n        \"epoch_length\": 116725424,\n        \"slot_length\": 3750916013,\n        \"safe_zone\": 1825569387\n      }\n    }\n  ]\n}\n```\n</details>\n"
  },
  {
    "path": "CIP-0139/json-rpc.json",
    "content": "{\n  \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n  \"$id\": \"cardano-query-layer.json\",\n  \"title\": \"Cardano Query Layer types\",\n  \"definitions\": {\n    \"utxos/asset:request\": {\n      \"title\": \"utxos by asset\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"asset_name\": {\n          \"$ref\": \"cardano-conway.json#/definitions/AssetName\"\n        },\n        \"minting_policy_hash\": {\n          \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n        }\n      }\n    },\n    \"utxos/asset:response\": {\n      \"title\": \"utxos by asset\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"utxos\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"anyOf\": [\n              {\n                \"$ref\": \"cardano-conway.json#/definitions/TransactionUnspentOutput\"\n              },\n              {\n                \"$ref\": \"cardano-babbage.json#/definitions/TransactionUnspentOutput\"\n              }\n            ]\n          }\n        }\n      }\n    },\n    \"utxos/transaction_hash:request\": {\n      \"title\": \"utxos by transaction_hash\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/TransactionHash\"\n    },\n    \"utxos/transaction_hash:response\": {\n      \"title\": \"utxos by transaction_hash\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"utxos\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"anyOf\": [\n              {\n                \"$ref\": \"cardano-conway.json#/definitions/TransactionUnspentOutput\"\n              },\n              {\n                \"$ref\": \"cardano-babbage.json#/definitions/TransactionUnspentOutput\"\n              }\n            ]\n          }\n        }\n      }\n    },\n    \"utxos/address:request\": {\n      \"title\": \"utxos by address\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-babbage.json#/definitions/Address\"\n    },\n    \"utxos/address:response\": {\n      \"title\": \"utxos by address\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"utxos\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"anyOf\": [\n              {\n                \"$ref\": \"cardano-conway.json#/definitions/TransactionUnspentOutput\"\n              },\n              {\n                \"$ref\": \"cardano-babbage.json#/definitions/TransactionUnspentOutput\"\n              }\n            ]\n          }\n        }\n      }\n    },\n    \"utxos/payment_credential:request\": {\n      \"title\": \"utxos by payment_credential\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n    },\n    \"utxos/payment_credential:response\": {\n      \"title\": \"utxos by payment_credential\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"utxos\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"anyOf\": [\n              {\n                \"$ref\": \"cardano-conway.json#/definitions/TransactionUnspentOutput\"\n              },\n              {\n                \"$ref\": \"cardano-babbage.json#/definitions/TransactionUnspentOutput\"\n              }\n            ]\n          }\n        }\n      }\n    },\n    \"utxos/stake_credential:request\": {\n      \"title\": \"utxos by stake_credential\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/RewardAddress\"\n    },\n    \"utxos/stake_credential:response\": {\n      \"title\": \"utxos by stake_credential\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"utxos\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"anyOf\": [\n              {\n                \"$ref\": \"cardano-conway.json#/definitions/TransactionUnspentOutput\"\n              },\n              {\n                \"$ref\": \"cardano-babbage.json#/definitions/TransactionUnspentOutput\"\n              }\n            ]\n          }\n        }\n      }\n    },\n    \"block/number:request\": {\n      \"title\": \"block by number\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n    },\n    \"block/number:response\": {\n      \"title\": \"block by number\",\n      \"type\": \"object\",\n      \"anyOf\": [\n        {\n          \"$ref\": \"cardano-conway.json#/definitions/Block\"\n        },\n        {\n          \"$ref\": \"cardano-babbage.json#/definitions/Block\"\n        }\n      ]\n    },\n    \"block/hash:request\": {\n      \"title\": \"block by hash\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/BlockHash\"\n    },\n    \"block/hash:response\": {\n      \"title\": \"block by hash\",\n      \"type\": \"object\",\n      \"anyOf\": [\n        {\n          \"$ref\": \"cardano-conway.json#/definitions/Block\"\n        },\n        {\n          \"$ref\": \"cardano-babbage.json#/definitions/Block\"\n        }\n      ]\n    },\n    \"transaction/hash:request\": {\n      \"title\": \"transaction by hash\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/TransactionHash\"\n    },\n    \"transaction/hash:response\": {\n      \"title\": \"transaction by hash\",\n      \"type\": \"object\",\n      \"anyOf\": [\n        {\n          \"$ref\": \"cardano-conway.json#/definitions/Transaction\"\n        },\n        {\n          \"$ref\": \"cardano-babbage.json#/definitions/Transaction\"\n        }\n      ]\n    },\n    \"transaction/block_number:request\": {\n      \"title\": \"transaction by block_number\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n    },\n    \"transaction/block_number:response\": {\n      \"title\": \"transaction by block_number\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"transactions\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"anyOf\": [\n              {\n                \"$ref\": \"cardano-conway.json#/definitions/Transaction\"\n              },\n              {\n                \"$ref\": \"cardano-babbage.json#/definitions/Transaction\"\n              }\n            ]\n          }\n        }\n      }\n    },\n    \"transaction/block_hash:request\": {\n      \"title\": \"transaction by block_hash\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/BlockHash\"\n    },\n    \"transaction/block_hash:response\": {\n      \"title\": \"transaction by block_hash\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"transactions\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"anyOf\": [\n              {\n                \"$ref\": \"cardano-conway.json#/definitions/Transaction\"\n              },\n              {\n                \"$ref\": \"cardano-babbage.json#/definitions/Transaction\"\n              }\n            ]\n          }\n        }\n      }\n    },\n    \"datum/hash:request\": {\n      \"title\": \"datum by hash\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/DataHash\"\n    },\n    \"datum/hash:response\": {\n      \"title\": \"datum by hash\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n    },\n    \"plutus_script/hash:request\": {\n      \"title\": \"plutus_script by hash\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n    },\n    \"plutus_script/hash:response\": {\n      \"title\": \"plutus_script by hash\",\n      \"type\": \"object\",\n      \"anyOf\": [\n        {\n          \"$ref\": \"cardano-conway.json#/definitions/PlutusScript\"\n        },\n        {\n          \"$ref\": \"cardano-babbage.json#/definitions/PlutusScript\"\n        }\n      ]\n    },\n    \"native_script/hash:request\": {\n      \"title\": \"native_script by hash\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n    },\n    \"native_script/hash:response\": {\n      \"title\": \"native_script by hash\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/NativeScript\"\n    },\n    \"metadata/transaction_hash:request\": {\n      \"title\": \"metadata by transaction_hash\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/TransactionHash\"\n    },\n    \"metadata/transaction_hash:response\": {\n      \"title\": \"metadata by transaction_hash\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/TransactionMetadatum\"\n    },\n    \"protocol_parameters/latest:request\": {\n      \"title\": \"protocol_parameters (latest)\",\n      \"type\": \"object\",\n      \"properties\": {}\n    },\n    \"protocol_parameters/latest:response\": {\n      \"title\": \"protocol_parameters (latest)\",\n      \"type\": \"object\",\n      \"$ref\": \"query-layer.json#/definitions/ProtocolParams\"\n    },\n    \"protocol_parameters/epoch:request\": {\n      \"title\": \"protocol_parameters by epoch\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n    },\n    \"protocol_parameters/epoch:response\": {\n      \"title\": \"protocol_parameters by epoch\",\n      \"type\": \"object\",\n      \"$ref\": \"query-layer.json#/definitions/ProtocolParams\"\n    },\n    \"votes/cc_id:request\": {\n      \"title\": \"votes by cc_id\",\n      \"type\": \"object\",\n      \"$ref\": \"query-layer.json#/definitions/CCHotId\"\n    },\n    \"votes/cc_id:response\": {\n      \"title\": \"votes by cc_id\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"votes\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"query-layer.json#/definitions/VoteInfo\"\n          }\n        }\n      }\n    },\n    \"votes/spo_id:request\": {\n      \"title\": \"votes by spo_id\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n    },\n    \"votes/spo_id:response\": {\n      \"title\": \"votes by spo_id\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"votes\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"query-layer.json#/definitions/VoteInfo\"\n          }\n        }\n      }\n    },\n    \"votes/drep_id:request\": {\n      \"title\": \"votes by drep_id\",\n      \"type\": \"object\",\n      \"$ref\": \"query-layer.json#/definitions/DRepId\"\n    },\n    \"votes/drep_id:response\": {\n      \"title\": \"votes by drep_id\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"votes\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"query-layer.json#/definitions/VoteInfo\"\n          }\n        }\n      }\n    },\n    \"votes/proposal_id:request\": {\n      \"title\": \"votes by proposal_id\",\n      \"type\": \"object\",\n      \"$ref\": \"query-layer.json#/definitions/ProposalId\"\n    },\n    \"votes/proposal_id:response\": {\n      \"title\": \"votes by proposal_id\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"votes\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"query-layer.json#/definitions/VoteInfo\"\n          }\n        }\n      }\n    },\n    \"drep/all:request\": {\n      \"title\": \"drep (all)\",\n      \"type\": \"object\",\n      \"properties\": {}\n    },\n    \"drep/all:response\": {\n      \"title\": \"drep (all)\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"dreps\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"query-layer.json#/definitions/DRepInfo\"\n          }\n        }\n      }\n    },\n    \"drep/id:request\": {\n      \"title\": \"drep by id\",\n      \"type\": \"object\",\n      \"$ref\": \"query-layer.json#/definitions/DRepId\"\n    },\n    \"drep/id:response\": {\n      \"title\": \"drep by id\",\n      \"type\": \"object\",\n      \"$ref\": \"query-layer.json#/definitions/DRepInfo\"\n    },\n    \"drep/stake_credential:request\": {\n      \"title\": \"drep by stake_credential\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/RewardAddress\"\n    },\n    \"drep/stake_credential:response\": {\n      \"title\": \"drep by stake_credential\",\n      \"type\": \"object\",\n      \"$ref\": \"query-layer.json#/definitions/DRepInfo\"\n    },\n    \"committee/all:request\": {\n      \"title\": \"committee (all)\",\n      \"type\": \"object\",\n      \"properties\": {}\n    },\n    \"committee/all:response\": {\n      \"title\": \"committee (all)\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"cc_members\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"query-layer.json#/definitions/CCMember\"\n          }\n        }\n      }\n    },\n    \"committee/id:request\": {\n      \"title\": \"committee by id\",\n      \"type\": \"object\",\n      \"$ref\": \"query-layer.json#/definitions/CCHotId\"\n    },\n    \"committee/id:response\": {\n      \"title\": \"committee by id\",\n      \"type\": \"object\",\n      \"$ref\": \"query-layer.json#/definitions/CCMember\"\n    },\n    \"pool/all:request\": {\n      \"title\": \"pool (all)\",\n      \"type\": \"object\",\n      \"properties\": {}\n    },\n    \"pool/all:response\": {\n      \"title\": \"pool (all)\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"pools\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"query-layer.json#/definitions/Pool\"\n          }\n        }\n      }\n    },\n    \"pool/id:request\": {\n      \"title\": \"pool by id\",\n      \"type\": \"object\",\n      \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n    },\n    \"pool/id:response\": {\n      \"title\": \"pool by id\",\n      \"type\": \"object\",\n      \"$ref\": \"query-layer.json#/definitions/Pool\"\n    },\n    \"proposal/all:request\": {\n      \"title\": \"proposal (all)\",\n      \"type\": \"object\",\n      \"properties\": {}\n    },\n    \"proposal/all:response\": {\n      \"title\": \"proposal (all)\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"proposals\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"query-layer.json#/definitions/Proposal\"\n          }\n        }\n      }\n    },\n    \"proposal/id:request\": {\n      \"title\": \"proposal by id\",\n      \"type\": \"object\",\n      \"$ref\": \"query-layer.json#/definitions/ProposalId\"\n    },\n    \"proposal/id:response\": {\n      \"title\": \"proposal by id\",\n      \"type\": \"object\",\n      \"$ref\": \"query-layer.json#/definitions/Proposal\"\n    },\n    \"era/summary:request\": {\n      \"title\": \"era summary\",\n      \"type\": \"object\",\n      \"properties\": {}\n    },\n    \"era/summary:response\": {\n      \"title\": \"era summary\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"summary\": {\n          \"type\": \"array\",\n          \"items\": {\n            \"$ref\": \"query-layer.json#/definitions/EraSummary\"\n          }\n        }\n      }\n    }\n  }\n}\n"
  },
  {
    "path": "CIP-0139/open-api.json",
    "content": "{\n  \"openapi\": \"3.1.0\",\n  \"info\": {\n    \"title\": \"Cardano Query Layer Specification\",\n    \"version\": \"1.0.0\"\n  },\n  \"paths\": {\n    \"/utxos/asset\": {\n      \"get\": {\n        \"summary\": \"utxos by asset\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"utxos by asset\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"utxos\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"anyOf\": [\n                          {\n                            \"$ref\": \"cardano-conway.json#/definitions/TransactionUnspentOutput\"\n                          },\n                          {\n                            \"$ref\": \"cardano-babbage.json#/definitions/TransactionUnspentOutput\"\n                          }\n                        ]\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"asset_name\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/AssetName\"\n            }\n          },\n          {\n            \"name\": \"minting_policy_hash\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n            }\n          }\n        ]\n      }\n    },\n    \"/utxos/transaction_hash\": {\n      \"get\": {\n        \"summary\": \"utxos by transaction_hash\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"utxos by transaction_hash\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"utxos\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"anyOf\": [\n                          {\n                            \"$ref\": \"cardano-conway.json#/definitions/TransactionUnspentOutput\"\n                          },\n                          {\n                            \"$ref\": \"cardano-babbage.json#/definitions/TransactionUnspentOutput\"\n                          }\n                        ]\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"transaction_hash\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/TransactionHash\"\n            }\n          }\n        ]\n      }\n    },\n    \"/utxos/address\": {\n      \"get\": {\n        \"summary\": \"utxos by address\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"utxos by address\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"utxos\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"anyOf\": [\n                          {\n                            \"$ref\": \"cardano-conway.json#/definitions/TransactionUnspentOutput\"\n                          },\n                          {\n                            \"$ref\": \"cardano-babbage.json#/definitions/TransactionUnspentOutput\"\n                          }\n                        ]\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"address\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/Address\"\n            }\n          }\n        ]\n      }\n    },\n    \"/utxos/payment_credential\": {\n      \"get\": {\n        \"summary\": \"utxos by payment_credential\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"utxos by payment_credential\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"utxos\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"anyOf\": [\n                          {\n                            \"$ref\": \"cardano-conway.json#/definitions/TransactionUnspentOutput\"\n                          },\n                          {\n                            \"$ref\": \"cardano-babbage.json#/definitions/TransactionUnspentOutput\"\n                          }\n                        ]\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"credential\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n            }\n          }\n        ]\n      }\n    },\n    \"/utxos/stake_credential\": {\n      \"get\": {\n        \"summary\": \"utxos by stake_credential\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"utxos by stake_credential\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"utxos\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"anyOf\": [\n                          {\n                            \"$ref\": \"cardano-conway.json#/definitions/TransactionUnspentOutput\"\n                          },\n                          {\n                            \"$ref\": \"cardano-babbage.json#/definitions/TransactionUnspentOutput\"\n                          }\n                        ]\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"reward_address\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/RewardAddress\"\n            }\n          }\n        ]\n      }\n    },\n    \"/block/number\": {\n      \"get\": {\n        \"summary\": \"block by number\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"block by number\",\n                  \"type\": \"object\",\n                  \"anyOf\": [\n                    {\n                      \"$ref\": \"cardano-conway.json#/definitions/Block\"\n                    },\n                    {\n                      \"$ref\": \"cardano-babbage.json#/definitions/Block\"\n                    }\n                  ]\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"u_int64\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n            }\n          }\n        ]\n      }\n    },\n    \"/block/hash\": {\n      \"get\": {\n        \"summary\": \"block by hash\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"block by hash\",\n                  \"type\": \"object\",\n                  \"anyOf\": [\n                    {\n                      \"$ref\": \"cardano-conway.json#/definitions/Block\"\n                    },\n                    {\n                      \"$ref\": \"cardano-babbage.json#/definitions/Block\"\n                    }\n                  ]\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"block_hash\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/BlockHash\"\n            }\n          }\n        ]\n      }\n    },\n    \"/transaction/hash\": {\n      \"get\": {\n        \"summary\": \"transaction by hash\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"transaction by hash\",\n                  \"type\": \"object\",\n                  \"anyOf\": [\n                    {\n                      \"$ref\": \"cardano-conway.json#/definitions/Transaction\"\n                    },\n                    {\n                      \"$ref\": \"cardano-babbage.json#/definitions/Transaction\"\n                    }\n                  ]\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"transaction_hash\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/TransactionHash\"\n            }\n          }\n        ]\n      }\n    },\n    \"/transaction/block_number\": {\n      \"get\": {\n        \"summary\": \"transaction by block_number\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"transaction by block_number\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"transactions\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"anyOf\": [\n                          {\n                            \"$ref\": \"cardano-conway.json#/definitions/Transaction\"\n                          },\n                          {\n                            \"$ref\": \"cardano-babbage.json#/definitions/Transaction\"\n                          }\n                        ]\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"u_int64\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n            }\n          }\n        ]\n      }\n    },\n    \"/transaction/block_hash\": {\n      \"get\": {\n        \"summary\": \"transaction by block_hash\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"transaction by block_hash\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"transactions\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"anyOf\": [\n                          {\n                            \"$ref\": \"cardano-conway.json#/definitions/Transaction\"\n                          },\n                          {\n                            \"$ref\": \"cardano-babbage.json#/definitions/Transaction\"\n                          }\n                        ]\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"block_hash\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/BlockHash\"\n            }\n          }\n        ]\n      }\n    },\n    \"/datum/hash\": {\n      \"get\": {\n        \"summary\": \"datum by hash\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"datum by hash\",\n                  \"type\": \"object\",\n                  \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"data_hash\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/DataHash\"\n            }\n          }\n        ]\n      }\n    },\n    \"/plutus_script/hash\": {\n      \"get\": {\n        \"summary\": \"plutus_script by hash\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"plutus_script by hash\",\n                  \"type\": \"object\",\n                  \"anyOf\": [\n                    {\n                      \"$ref\": \"cardano-conway.json#/definitions/PlutusScript\"\n                    },\n                    {\n                      \"$ref\": \"cardano-babbage.json#/definitions/PlutusScript\"\n                    }\n                  ]\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"script_hash\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n            }\n          }\n        ]\n      }\n    },\n    \"/native_script/hash\": {\n      \"get\": {\n        \"summary\": \"native_script by hash\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"native_script by hash\",\n                  \"type\": \"object\",\n                  \"$ref\": \"cardano-conway.json#/definitions/NativeScript\"\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"script_hash\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n            }\n          }\n        ]\n      }\n    },\n    \"/metadata/transaction_hash\": {\n      \"get\": {\n        \"summary\": \"metadata by transaction_hash\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"metadata by transaction_hash\",\n                  \"type\": \"object\",\n                  \"$ref\": \"cardano-conway.json#/definitions/TransactionMetadatum\"\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"transaction_hash\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/TransactionHash\"\n            }\n          }\n        ]\n      }\n    },\n    \"/protocol_parameters/latest\": {\n      \"get\": {\n        \"summary\": \"protocol_parameters (latest)\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"protocol_parameters (latest)\",\n                  \"type\": \"object\",\n                  \"$ref\": \"query-layer.json#/definitions/ProtocolParams\"\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": []\n      }\n    },\n    \"/protocol_parameters/epoch\": {\n      \"get\": {\n        \"summary\": \"protocol_parameters by epoch\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"protocol_parameters by epoch\",\n                  \"type\": \"object\",\n                  \"$ref\": \"query-layer.json#/definitions/ProtocolParams\"\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"u_int32\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n            }\n          }\n        ]\n      }\n    },\n    \"/votes/cc_id\": {\n      \"get\": {\n        \"summary\": \"votes by cc_id\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"votes by cc_id\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"votes\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"$ref\": \"query-layer.json#/definitions/VoteInfo\"\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"cc_hot_id\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"query-layer.json#/definitions/CCHotId\"\n            }\n          }\n        ]\n      }\n    },\n    \"/votes/spo_id\": {\n      \"get\": {\n        \"summary\": \"votes by spo_id\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"votes by spo_id\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"votes\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"$ref\": \"query-layer.json#/definitions/VoteInfo\"\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"pool_pub_key_hash\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n            }\n          }\n        ]\n      }\n    },\n    \"/votes/drep_id\": {\n      \"get\": {\n        \"summary\": \"votes by drep_id\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"votes by drep_id\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"votes\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"$ref\": \"query-layer.json#/definitions/VoteInfo\"\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"d_rep_id\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"query-layer.json#/definitions/DRepId\"\n            }\n          }\n        ]\n      }\n    },\n    \"/votes/proposal_id\": {\n      \"get\": {\n        \"summary\": \"votes by proposal_id\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"votes by proposal_id\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"votes\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"$ref\": \"query-layer.json#/definitions/VoteInfo\"\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"proposal_id\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"query-layer.json#/definitions/ProposalId\"\n            }\n          }\n        ]\n      }\n    },\n    \"/drep/all\": {\n      \"get\": {\n        \"summary\": \"drep (all)\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"drep (all)\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"dreps\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"$ref\": \"query-layer.json#/definitions/DRepInfo\"\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": []\n      }\n    },\n    \"/drep/id\": {\n      \"get\": {\n        \"summary\": \"drep by id\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"drep by id\",\n                  \"type\": \"object\",\n                  \"$ref\": \"query-layer.json#/definitions/DRepInfo\"\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"d_rep_id\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"query-layer.json#/definitions/DRepId\"\n            }\n          }\n        ]\n      }\n    },\n    \"/drep/stake_credential\": {\n      \"get\": {\n        \"summary\": \"drep by stake_credential\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"drep by stake_credential\",\n                  \"type\": \"object\",\n                  \"$ref\": \"query-layer.json#/definitions/DRepInfo\"\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"reward_address\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/RewardAddress\"\n            }\n          }\n        ]\n      }\n    },\n    \"/committee/all\": {\n      \"get\": {\n        \"summary\": \"committee (all)\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"committee (all)\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"cc_members\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"$ref\": \"query-layer.json#/definitions/CCMember\"\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": []\n      }\n    },\n    \"/committee/id\": {\n      \"get\": {\n        \"summary\": \"committee by id\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"committee by id\",\n                  \"type\": \"object\",\n                  \"$ref\": \"query-layer.json#/definitions/CCMember\"\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"cc_hot_id\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"query-layer.json#/definitions/CCHotId\"\n            }\n          }\n        ]\n      }\n    },\n    \"/pool/all\": {\n      \"get\": {\n        \"summary\": \"pool (all)\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"pool (all)\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"pools\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"$ref\": \"query-layer.json#/definitions/Pool\"\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": []\n      }\n    },\n    \"/pool/id\": {\n      \"get\": {\n        \"summary\": \"pool by id\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"pool by id\",\n                  \"type\": \"object\",\n                  \"$ref\": \"query-layer.json#/definitions/Pool\"\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"pool_pub_key_hash\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n            }\n          }\n        ]\n      }\n    },\n    \"/proposal/all\": {\n      \"get\": {\n        \"summary\": \"proposal (all)\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"proposal (all)\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"proposals\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"$ref\": \"query-layer.json#/definitions/Proposal\"\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": []\n      }\n    },\n    \"/proposal/id\": {\n      \"get\": {\n        \"summary\": \"proposal by id\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"proposal by id\",\n                  \"type\": \"object\",\n                  \"$ref\": \"query-layer.json#/definitions/Proposal\"\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": [\n          {\n            \"name\": \"proposal_id\",\n            \"in\": \"query\",\n            \"required\": true,\n            \"schema\": {\n              \"$ref\": \"query-layer.json#/definitions/ProposalId\"\n            }\n          }\n        ]\n      }\n    },\n    \"/era/summary\": {\n      \"get\": {\n        \"summary\": \"era summary\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"Successful response\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"title\": \"era summary\",\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"summary\": {\n                      \"type\": \"array\",\n                      \"items\": {\n                        \"$ref\": \"query-layer.json#/definitions/EraSummary\"\n                      }\n                    }\n                  }\n                }\n              }\n            }\n          },\n          \"404\": {\n            \"description\": \"Item not found\"\n          }\n        },\n        \"parameters\": []\n      }\n    }\n  },\n  \"components\": {\n    \"schemas\": {\n      \"cardano-conway.json\": {\n        \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n        \"$id\": \"cardano-conway.json\",\n        \"title\": \"Cardano Conway Era Domain Types\",\n        \"definitions\": {\n          \"BigInt\": {\n            \"title\": \"BigInt\",\n            \"type\": \"string\",\n            \"description\": \"A long integer domain type\",\n            \"pattern\": \"^(0|-?[1-9][0-9]*)$\",\n            \"examples\": [\n              \"0\",\n              \"-123\",\n              \"123\"\n            ]\n          },\n          \"ByteString\": {\n            \"title\": \"ByteString\",\n            \"description\": \"Arbitrary-length byte array\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^([0-9a-f][0-9a-f])*$\"\n          },\n          \"UInt64\": {\n            \"title\": \"UInt64\",\n            \"description\": \"64-bit unsigned integer\",\n            \"type\": \"string\",\n            \"pattern\": \"^(0|[1-9][0-9]*)$\",\n            \"format\": \"uint64\"\n          },\n          \"UInt16\": {\n            \"title\": \"UInt16\",\n            \"description\": \"16-bit unsigned integer\",\n            \"type\": \"string\",\n            \"pattern\": \"^(0|[1-9][0-9]*)$\",\n            \"format\": \"uint16\"\n          },\n          \"PosInt64\": {\n            \"title\": \"PosInt64\",\n            \"description\": \"64-bit unsigned integer, zero-excluded. 1-18446744073709551615\",\n            \"type\": \"string\",\n            \"pattern\": \"^([1-9][0-9]*)$\",\n            \"format\": \"posint64\"\n          },\n          \"Int128\": {\n            \"title\": \"Int128\",\n            \"description\": \"128-bit signed integer\",\n            \"type\": \"string\",\n            \"pattern\": \"^-?(0|[1-9][0-9]*)$\",\n            \"format\": \"int128\"\n          },\n          \"NonZeroInt64\": {\n            \"title\": \"NonZeroInt64\",\n            \"description\": \"64-bit signed integer, zero excluded. Ranges: -9223372036854775808..-1 and 1..9223372036854775807\",\n            \"type\": \"string\",\n            \"pattern\": \"^-?([1-9][0-9]*)$\"\n          },\n          \"UInt32\": {\n            \"title\": \"UInt32\",\n            \"description\": \"32-bit unsigned integer\",\n            \"type\": \"integer\",\n            \"minimum\": 0,\n            \"maximum\": 4294967295\n          },\n          \"RewardAddress\": {\n            \"title\": \"RewardAddress\",\n            \"type\": \"string\",\n            \"format\": \"bech32\",\n            \"pattern\": \"^(stake1|stake_test1)[02-9ac-hj-np-z]*$\",\n            \"examples\": [\n              \"stake1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5egfu2p0u\"\n            ]\n          },\n          \"ByronAddress\": {\n            \"title\": \"ByronAddress\",\n            \"type\": \"string\",\n            \"format\": \"base58\",\n            \"pattern\": \"^[1-9A-HJ-NP-Za-km-z]+$\",\n            \"examples\": [\n              \"37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na\"\n            ]\n          },\n          \"EnterpriseAddress\": {\n            \"title\": \"EnterpriseAddress\",\n            \"type\": \"string\",\n            \"format\": \"bech32\",\n            \"pattern\": \"^(addr1|addr_test1)[02-9ac-hj-np-z]*$\",\n            \"examples\": [\n              \"addr1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0yu80w\"\n            ]\n          },\n          \"BaseAddress\": {\n            \"title\": \"BaseAddress\",\n            \"type\": \"string\",\n            \"format\": \"bech32\",\n            \"pattern\": \"^(addr1|addr_test1)[02-9ac-hj-np-z]*$\",\n            \"examples\": [\n              \"addr1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0yu80w\"\n            ]\n          },\n          \"Address\": {\n            \"title\": \"Address\",\n            \"anyOf\": [\n              {\n                \"$ref\": \"cardano-conway.json#/definitions/RewardAddress\"\n              },\n              {\n                \"$ref\": \"cardano-conway.json#/definitions/BaseAddress\"\n              },\n              {\n                \"$ref\": \"cardano-conway.json#/definitions/EnterpriseAddress\"\n              },\n              {\n                \"$ref\": \"cardano-conway.json#/definitions/ByronAddress\"\n              }\n            ]\n          },\n          \"Ed25519KeyHash\": {\n            \"title\": \"Ed25519KeyHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{56}$\"\n          },\n          \"ScriptHash\": {\n            \"title\": \"ScriptHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{56}$\"\n          },\n          \"AssetName\": {\n            \"title\": \"AssetName\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^([0-9a-f][0-9a-f]){0,32}$\",\n            \"examples\": [\n              \"504154415445\",\n              \"1e349c9bdea19fd6c147626a5260bc44b71635f398b67c59881df209\",\n              \"7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc373\"\n            ]\n          },\n          \"ScriptDataHash\": {\n            \"title\": \"ScriptDataHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\"\n          },\n          \"TransactionMetadata\": {\n            \"title\": \"TransactionMetadata\",\n            \"type\": \"array\",\n            \"items\": {\n              \"type\": \"object\",\n              \"properties\": {\n                \"key\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                },\n                \"value\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/TransactionMetadatum\"\n                }\n              },\n              \"required\": [\n                \"key\",\n                \"value\"\n              ],\n              \"unevaluatedProperties\": false\n            }\n          },\n          \"AuxiliaryDataHash\": {\n            \"title\": \"AuxiliaryDataHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\"\n          },\n          \"AuxiliaryData\": {\n            \"unevaluatedProperties\": false,\n            \"properties\": {\n              \"metadata\": {\n                \"$ref\": \"cardano-conway.json#/definitions/TransactionMetadata\"\n              },\n              \"native_scripts\": {\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/NativeScript\"\n                },\n                \"type\": \"array\"\n              },\n              \"plutus_scripts\": {\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/PlutusScript\"\n                },\n                \"type\": \"array\"\n              }\n            },\n            \"required\": [],\n            \"title\": \"AuxiliaryData\",\n            \"type\": \"object\"\n          },\n          \"Vote\": {\n            \"title\": \"Vote\",\n            \"type\": \"string\",\n            \"enum\": [\n              \"yes\",\n              \"no\",\n              \"abstain\"\n            ]\n          },\n          \"Voter\": {\n            \"type\": \"object\",\n            \"title\": \"Voter\",\n            \"oneOf\": [\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"cc_credential\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"drep_credential\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"spo_keyhash\"\n                    ]\n                  },\n                  \"pubkey_hash\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Ed25519KeyHash\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\"\n                ],\n                \"unevaluatedProperties\": false\n              }\n            ]\n          },\n          \"VotingProcedure\": {\n            \"title\": \"VotingProcedure\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"vote\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Vote\"\n              },\n              \"anchor\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Anchor\"\n              }\n            },\n            \"required\": [\n              \"vote\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"VotingProcedures\": {\n            \"title\": \"VotingProcedures\",\n            \"type\": \"array\",\n            \"items\": {\n              \"type\": \"object\",\n              \"properties\": {\n                \"key\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/Voter\"\n                },\n                \"value\": {\n                  \"type\": \"array\",\n                  \"items\": {\n                    \"type\": \"object\",\n                    \"properties\": {\n                      \"key\": {\n                        \"$ref\": \"cardano-conway.json#/definitions/GovActionId\"\n                      },\n                      \"value\": {\n                        \"$ref\": \"cardano-conway.json#/definitions/VotingProcedure\"\n                      }\n                    },\n                    \"required\": [\n                      \"key\",\n                      \"value\"\n                    ],\n                    \"unevaluatedProperties\": false\n                  }\n                }\n              },\n              \"required\": [\n                \"key\",\n                \"value\"\n              ],\n              \"unevaluatedProperties\": false\n            }\n          },\n          \"ProposalProcedure\": {\n            \"title\": \"ProposalProcedure\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"deposit\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"reward_account\": {\n                \"$ref\": \"cardano-conway.json#/definitions/RewardAddress\"\n              },\n              \"gov_action\": {\n                \"$ref\": \"cardano-conway.json#/definitions/GovAction\"\n              },\n              \"anchor\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Anchor\"\n              }\n            },\n            \"required\": [\n              \"deposit\",\n              \"reward_account\",\n              \"gov_action\",\n              \"anchor\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"ProposalProcedures\": {\n            \"title\": \"ProposalProcedures\",\n            \"type\": \"array\",\n            \"minLength\": 1,\n            \"items\": {\n              \"$ref\": \"cardano-conway.json#/definitions/ProposalProcedure\"\n            }\n          },\n          \"TransactionBody\": {\n            \"title\": \"TransactionBody\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"auxiliary_data_hash\": {\n                \"$ref\": \"cardano-conway.json#/definitions/AuxiliaryDataHash\"\n              },\n              \"inputs\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/TransactionInput\"\n                }\n              },\n              \"outputs\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/TransactionOutput\"\n                }\n              },\n              \"fee\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"certs\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/Certificate\"\n                }\n              },\n              \"collateral\": {\n                \"title\": \"Collateral Inputs\",\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/TransactionInput\"\n                }\n              },\n              \"collateral_return\": {\n                \"allOf\": [\n                  {\n                    \"$ref\": \"cardano-conway.json#/definitions/TransactionOutput\"\n                  },\n                  {\n                    \"title\": \"Collateral Return\",\n                    \"description\": \"Collateral return, introduced in CIP-40\"\n                  }\n                ]\n              },\n              \"mint\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Mint\"\n              },\n              \"network_id\": {\n                \"$ref\": \"cardano-conway.json#/definitions/NetworkId\"\n              },\n              \"reference_inputs\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/TransactionInput\"\n                }\n              },\n              \"required_signers\": {\n                \"title\": \"Required signers\",\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/Ed25519KeyHash\"\n                }\n              },\n              \"script_data_hash\": {\n                \"$ref\": \"cardano-conway.json#/definitions/ScriptDataHash\"\n              },\n              \"total_collateral\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"ttl\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"update\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Update\"\n              },\n              \"validity_start_interval\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"withdrawals\": {\n                \"type\": \"array\",\n                \"minLength\": 1,\n                \"items\": {\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"key\": {\n                      \"$ref\": \"cardano-conway.json#/definitions/RewardAddress\"\n                    },\n                    \"value\": {\n                      \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                    }\n                  },\n                  \"unevaluatedProperties\": false\n                }\n              },\n              \"voting_procedures\": {\n                \"$ref\": \"cardano-conway.json#/definitions/VotingProcedures\"\n              },\n              \"proposal_procedures\": {\n                \"$ref\": \"cardano-conway.json#/definitions/ProposalProcedures\"\n              },\n              \"donation\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"current_treasury_value\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              }\n            },\n            \"required\": [\n              \"inputs\",\n              \"outputs\",\n              \"fee\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"Credential\": {\n            \"title\": \"Credential\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"pubkey_hash\"\n                    ]\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Ed25519KeyHash\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"script_hash\"\n                    ]\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              }\n            ]\n          },\n          \"MultiAsset\": {\n            \"title\": \"MultiAsset\",\n            \"description\": \"A mapping from policy IDs (script hashes) to mappings from asset names to amounts\",\n            \"type\": \"object\",\n            \"patternProperties\": {\n              \"^[0-9a-f]{56}$\": {\n                \"type\": \"object\",\n                \"patternProperties\": {\n                  \"^([0-9a-f][0-9a-f]){0,32}$\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/PosInt64\"\n                  }\n                },\n                \"unevaluatedProperties\": false\n              }\n            },\n            \"unevaluatedProperties\": false\n          },\n          \"Value\": {\n            \"title\": \"Value\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"coin\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"assets\": {\n                \"$ref\": \"cardano-conway.json#/definitions/MultiAsset\"\n              }\n            },\n            \"required\": [\n              \"coin\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"TransactionHash\": {\n            \"title\": \"TransactionHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\",\n            \"maxLength\": 64,\n            \"minLength\": 64,\n            \"examples\": [\n              \"eca40340fa6e65d964915ba4bc8bd811a0493d263ffe95875291114cbb2d0686\",\n              \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n              \"fbc1da46d62a431e69855ad48a6b49b0e2aaafc6fd3dc4a066c6851b7bd31a91\",\n              \"c6726192662abeab149098095eabe004ecbec47f5e564748ab0d394affca47d9\"\n            ]\n          },\n          \"TransactionInput\": {\n            \"title\": \"TransactionInput\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"transaction_id\": {\n                \"$ref\": \"cardano-conway.json#/definitions/TransactionHash\"\n              },\n              \"index\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              }\n            },\n            \"required\": [\n              \"transaction_id\",\n              \"index\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"PlutusScript\": {\n            \"title\": \"PlutusScript\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"language\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Language\"\n              },\n              \"bytes\": {\n                \"type\": \"string\",\n                \"format\": \"hex\",\n                \"pattern\": \"^([0-9a-f][0-9a-f])+$\"\n              }\n            },\n            \"required\": [\n              \"language\",\n              \"bytes\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"NativeScript\": {\n            \"title\": \"NativeScript\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"title\": \"ScriptPubkey\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"pubkey\"\n                    ]\n                  },\n                  \"pubkey\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Ed25519KeyHash\"\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"pubkey\"\n                ]\n              },\n              {\n                \"title\": \"ScriptAll\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"all\"\n                    ]\n                  },\n                  \"scripts\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"$ref\": \"cardano-conway.json#/definitions/NativeScript\"\n                    }\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"scripts\"\n                ]\n              },\n              {\n                \"title\": \"ScriptAny\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"any\"\n                    ]\n                  },\n                  \"scripts\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"$ref\": \"cardano-conway.json#/definitions/NativeScript\"\n                    }\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"scripts\"\n                ]\n              },\n              {\n                \"title\": \"ScriptNOfK\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"n_of_k\"\n                    ]\n                  },\n                  \"scripts\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"$ref\": \"cardano-conway.json#/definitions/NativeScript\"\n                    }\n                  },\n                  \"n\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"scripts\",\n                  \"n\"\n                ]\n              },\n              {\n                \"title\": \"TimelockStart\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"timelock_start\"\n                    ]\n                  },\n                  \"slot\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"slot\"\n                ]\n              },\n              {\n                \"title\": \"TimelockExpiry\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"timelock_expiry\"\n                    ]\n                  },\n                  \"slot\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"slot\"\n                ]\n              }\n            ]\n          },\n          \"ScriptRef\": {\n            \"title\": \"ScriptRef\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"title\": \"PlutusScript\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"plutus_script\"\n                    ]\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/PlutusScript\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"title\": \"NativeScript\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"native_script\"\n                    ]\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/NativeScript\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              }\n            ]\n          },\n          \"DataHash\": {\n            \"title\": \"DataHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^([0-9a-f][0-9a-f]){32}$\"\n          },\n          \"TransactionOutput\": {\n            \"title\": \"TransactionOutput\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"address\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Address\"\n              },\n              \"amount\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Value\"\n              },\n              \"plutus_data\": {\n                \"type\": \"object\",\n                \"discriminator\": {\n                  \"propertyName\": \"tag\"\n                },\n                \"oneOf\": [\n                  {\n                    \"type\": \"object\",\n                    \"properties\": {\n                      \"tag\": {\n                        \"enum\": [\n                          \"datum\"\n                        ]\n                      },\n                      \"value\": {\n                        \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n                      }\n                    }\n                  },\n                  {\n                    \"type\": \"object\",\n                    \"properties\": {\n                      \"tag\": {\n                        \"enum\": [\n                          \"datum_hash\"\n                        ]\n                      },\n                      \"value\": {\n                        \"$ref\": \"cardano-conway.json#/definitions/DataHash\"\n                      }\n                    }\n                  }\n                ],\n                \"unevaluatedProperties\": false\n              },\n              \"script_ref\": {\n                \"$ref\": \"cardano-conway.json#/definitions/ScriptRef\"\n              }\n            },\n            \"required\": [\n              \"address\",\n              \"amount\"\n            ]\n          },\n          \"TransactionUnspentOutput\": {\n            \"title\": \"TransactionUnspentOutput\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"input\": {\n                \"$ref\": \"cardano-conway.json#/definitions/TransactionInput\"\n              },\n              \"output\": {\n                \"$ref\": \"cardano-conway.json#/definitions/TransactionOutput\"\n              }\n            },\n            \"required\": [\n              \"input\",\n              \"output\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"TransactionMetadatum\": {\n            \"title\": \"TransactionMetadatum\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"map\"\n                    ]\n                  },\n                  \"contents\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"type\": \"object\",\n                      \"properties\": {\n                        \"key\": {\n                          \"$ref\": \"cardano-conway.json#/definitions/TransactionMetadatum\"\n                        },\n                        \"value\": {\n                          \"$ref\": \"cardano-conway.json#/definitions/TransactionMetadatum\"\n                        }\n                      },\n                      \"required\": [\n                        \"key\",\n                        \"value\"\n                      ],\n                      \"unevaluatedProperties\": false\n                    }\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"contents\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"list\"\n                    ]\n                  },\n                  \"contents\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"$ref\": \"cardano-conway.json#/definitions/TransactionMetadatum\"\n                    }\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"contents\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"int\"\n                    ]\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Int128\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"bytes\"\n                    ]\n                  },\n                  \"value\": {\n                    \"type\": \"string\",\n                    \"format\": \"hex\",\n                    \"pattern\": \"^([0-9a-f][0-9a-f]){0,64}$\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"title\": \"Metadata String\",\n                \"description\": \"UTF-8 string. Maximum size is 64 bytes, but there is no way to express byte length limit in a json-schema (maxLength limits the number of characters)\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"string\"\n                    ]\n                  },\n                  \"value\": {\n                    \"type\": \"string\",\n                    \"maxLength\": 64,\n                    \"format\": \"string64\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              }\n            ]\n          },\n          \"PlutusV1CostModel\": {\n            \"title\": \"PlutusV1CostModel\",\n            \"type\": \"array\",\n            \"items\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Int128\"\n            },\n            \"maxItems\": 166,\n            \"minItems\": 166\n          },\n          \"PlutusV2CostModel\": {\n            \"title\": \"PlutusV2CostModel\",\n            \"type\": \"array\",\n            \"items\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Int128\"\n            },\n            \"maxItems\": 175,\n            \"minItems\": 175\n          },\n          \"PlutusV3CostModel\": {\n            \"title\": \"PlutusV3CostModel\",\n            \"type\": \"array\",\n            \"items\": {\n              \"$ref\": \"cardano-conway.json#/definitions/Int128\"\n            },\n            \"maxItems\": 251,\n            \"minItems\": 251\n          },\n          \"CostModels\": {\n            \"title\": \"CostModels\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"plutus_v1\": {\n                \"$ref\": \"cardano-conway.json#/definitions/PlutusV1CostModel\"\n              },\n              \"plutus_v2\": {\n                \"$ref\": \"cardano-conway.json#/definitions/PlutusV2CostModel\"\n              },\n              \"plutus_v3\": {\n                \"$ref\": \"cardano-conway.json#/definitions/PlutusV3CostModel\"\n              }\n            },\n            \"required\": [],\n            \"unevaluatedProperties\": false\n          },\n          \"ExUnitPrices\": {\n            \"title\": \"ExUnitPrices\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"mem_price\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n              },\n              \"step_price\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n              }\n            },\n            \"unevaluatedProperties\": false,\n            \"required\": [\n              \"mem_price\",\n              \"step_price\"\n            ]\n          },\n          \"ExUnits\": {\n            \"title\": \"ExUnits\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"mem\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"steps\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              }\n            },\n            \"required\": [\n              \"mem\",\n              \"steps\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"ProtocolVersion\": {\n            \"title\": \"ProtocolVersion\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"major\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"minor\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              }\n            },\n            \"required\": [\n              \"major\",\n              \"minor\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"NonnegativeInterval\": {\n            \"title\": \"NonnegativeInterval\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"numerator\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"denominator\": {\n                \"$ref\": \"cardano-conway.json#/definitions/PosInt64\"\n              }\n            },\n            \"required\": [\n              \"numerator\",\n              \"denominator\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"PoolVotingThresholds\": {\n            \"title\": \"PoolVotingThresholds\",\n            \"type\": \"array\",\n            \"items\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n            },\n            \"minItems\": 5,\n            \"maxItems\": 5\n          },\n          \"DRepVotingThresholds\": {\n            \"title\": \"DRepVotingThresholds\",\n            \"type\": \"array\",\n            \"items\": {\n              \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n            },\n            \"minItems\": 10,\n            \"maxItems\": 10\n          },\n          \"ProtocolParamUpdate\": {\n            \"title\": \"ProtocolParamUpdate\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"ada_per_utxo_byte\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"collateral_percentage\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"cost_models\": {\n                \"$ref\": \"cardano-conway.json#/definitions/CostModels\"\n              },\n              \"d\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n              },\n              \"execution_costs\": {\n                \"$ref\": \"cardano-conway.json#/definitions/ExUnitPrices\"\n              },\n              \"expansion_rate\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n              },\n              \"key_deposit\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"max_block_body_size\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"max_block_ex_units\": {\n                \"$ref\": \"cardano-conway.json#/definitions/ExUnits\"\n              },\n              \"max_block_header_size\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"max_collateral_inputs\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"max_epoch\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"max_tx_ex_units\": {\n                \"$ref\": \"cardano-conway.json#/definitions/ExUnits\"\n              },\n              \"max_tx_size\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"max_value_size\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"min_pool_cost\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"minfee_a\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"minfee_b\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"n_opt\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"pool_deposit\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"pool_pledge_influence\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n              },\n              \"protocol_version\": {\n                \"$ref\": \"cardano-conway.json#/definitions/ProtocolVersion\"\n              },\n              \"treasury_growth_rate\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n              },\n              \"pool_voting_thresholds\": {\n                \"$ref\": \"cardano-conway.json#/definitions/PoolVotingThresholds\"\n              },\n              \"drep_voting_thresholds\": {\n                \"$ref\": \"cardano-conway.json#/definitions/DRepVotingThresholds\"\n              },\n              \"committee_min_size\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt16\"\n              },\n              \"committee_max_term_length\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"gov_action_lifetime\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"gov_action_deposit\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"drep_deposit\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"drep_activity\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"min_fee_ref_script_cost_per_byte\": {\n                \"$ref\": \"cardano-conway.json#/definitions/NonnegativeInterval\"\n              }\n            },\n            \"unevaluatedProperties\": false,\n            \"required\": []\n          },\n          \"Update\": {\n            \"title\": \"Update\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"epoch\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"proposed_protocol_parameter_updates\": {\n                \"type\": \"object\",\n                \"title\": \"ProposedProtocolParameterUpdates\",\n                \"description\": \"A mapping from GenesisHash to ProtocolParamUpdate\",\n                \"patternProperties\": {\n                  \"^[0-9a-f]{56}$\": {\n                    \"title\": \"ProtocolParamUpdate for a given GenesisHash\",\n                    \"$ref\": \"cardano-conway.json#/definitions/ProtocolParamUpdate\"\n                  }\n                },\n                \"unevaluatedProperties\": false\n              }\n            },\n            \"required\": [\n              \"epoch\",\n              \"proposed_protocol_parameter_updates\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"NetworkId\": {\n            \"title\": \"NetworkId\",\n            \"type\": \"string\",\n            \"enum\": [\n              \"testnet\",\n              \"mainnet\"\n            ]\n          },\n          \"PlutusData\": {\n            \"title\": \"PlutusData\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"title\": \"PlutusDataList\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"list\"\n                    ]\n                  },\n                  \"contents\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n                    }\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"contents\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"title\": \"PlutusDataConstr\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"constr\"\n                    ]\n                  },\n                  \"alternative\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                  },\n                  \"data\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n                    }\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"alternative\",\n                  \"data\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"title\": \"PlutusDataMap\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"map\"\n                    ]\n                  },\n                  \"contents\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"type\": \"object\",\n                      \"properties\": {\n                        \"key\": {\n                          \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n                        },\n                        \"value\": {\n                          \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n                        }\n                      },\n                      \"unevaluatedProperties\": false\n                    }\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"contents\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"title\": \"PlutusDataInteger\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"integer\"\n                    ]\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/BigInt\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"title\": \"PlutusDataBytes\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"bytes\"\n                    ]\n                  },\n                  \"value\": {\n                    \"type\": \"string\",\n                    \"format\": \"hex\",\n                    \"pattern\": \"^([0-9a-f][0-9a-f])*$\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              }\n            ]\n          },\n          \"UnitInterval\": {\n            \"title\": \"UnitInterval\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"numerator\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"denominator\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              }\n            },\n            \"required\": [\n              \"numerator\",\n              \"denominator\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"Ipv4\": {\n            \"title\": \"Ipv4\",\n            \"description\": \"IPv4 Address\",\n            \"type\": \"string\",\n            \"pattern\": \"^((25[0-5]|(2[0-4]|1\\\\d|[1-9]|)\\\\d)\\\\.){3}(25[0-5]|(2[0-4]|1\\\\d|[1-9]|)\\\\d)$\"\n          },\n          \"Ipv6\": {\n            \"title\": \"Ipv6\",\n            \"description\": \"IPv6 address\",\n            \"type\": \"string\",\n            \"format\": \"ipv6\"\n          },\n          \"DNSName\": {\n            \"title\": \"DNSName\",\n            \"type\": \"string\",\n            \"maxLength\": 64,\n            \"format\": \"string64\"\n          },\n          \"Relay\": {\n            \"title\": \"Relay\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"type\": \"object\",\n                \"title\": \"SingleHostAddr\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"single_host_addr\"\n                    ]\n                  },\n                  \"port\": {\n                    \"type\": \"integer\",\n                    \"maximum\": 65535\n                  },\n                  \"ipv4\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Ipv4\"\n                  },\n                  \"ipv6\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Ipv6\"\n                  }\n                },\n                \"required\": [\n                  \"tag\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"SingleHostName\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"single_host_name\"\n                    ]\n                  },\n                  \"port\": {\n                    \"type\": \"integer\",\n                    \"minimum\": 1,\n                    \"maximum\": 65535\n                  },\n                  \"dns_name\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/DNSName\"\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"dns_name\"\n                ]\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"MultiHostName\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"multi_host_name\"\n                    ]\n                  },\n                  \"dns_name\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/DNSName\"\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"dns_name\"\n                ]\n              }\n            ]\n          },\n          \"VRFKeyHash\": {\n            \"title\": \"VRFKeyHash\",\n            \"type\": \"string\",\n            \"description\": \"blake2b_256 digest of a VRF verification key, encoded as bech32\",\n            \"pattern\": \"^vrf_vkh[02-9ac-hj-np-z]*\",\n            \"format\": \"bech32\",\n            \"examples\": [\n              \"vrf_vkh3ak4chlh2xj9tw3jjwxdgs7v2uq6ev86l03vw\"\n            ]\n          },\n          \"URL\": {\n            \"title\": \"URL\",\n            \"description\": \"UTF-8 URL string. Maximum size is 128 bytes, but there is no way to express byte length limit in a json-schema (maxLength limits the number of characters)\",\n            \"type\": \"string\",\n            \"maxLength\": 128,\n            \"format\": \"string128\"\n          },\n          \"PoolMetadataHash\": {\n            \"title\": \"PoolMetadataHash\",\n            \"description\": \"Pool Metadata Hash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\"\n          },\n          \"PoolMetadata\": {\n            \"title\": \"PoolMetadata\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"url\": {\n                \"$ref\": \"cardano-conway.json#/definitions/URL\"\n              },\n              \"hash\": {\n                \"$ref\": \"cardano-conway.json#/definitions/PoolMetadataHash\"\n              }\n            },\n            \"unevaluatedProperties\": false,\n            \"required\": [\n              \"url\",\n              \"hash\"\n            ]\n          },\n          \"PoolPubKeyHash\": {\n            \"title\": \"PoolPubKeyHash\",\n            \"type\": \"string\",\n            \"format\": \"bech32\",\n            \"pattern\": \"^(pool1)[02-9ac-hj-np-z]*$\",\n            \"examples\": [\n              \"pool12a39rkzfylvn9wfe8j6y8ucq6g2l4mw4azj70y0gd8ejczznyj2\"\n            ]\n          },\n          \"PoolParams\": {\n            \"title\": \"PoolParams\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"operator\": {\n                \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n              },\n              \"vrf_keyhash\": {\n                \"$ref\": \"cardano-conway.json#/definitions/VRFKeyHash\"\n              },\n              \"pledge\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"cost\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"margin\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n              },\n              \"reward_account\": {\n                \"$ref\": \"cardano-conway.json#/definitions/RewardAddress\"\n              },\n              \"pool_owners\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/Ed25519KeyHash\"\n                }\n              },\n              \"relays\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/Relay\"\n                }\n              },\n              \"pool_metadata\": {\n                \"$ref\": \"cardano-conway.json#/definitions/PoolMetadata\"\n              }\n            },\n            \"required\": [\n              \"cost\",\n              \"margin\",\n              \"operator\",\n              \"pledge\",\n              \"pool_owners\",\n              \"relays\",\n              \"reward_account\",\n              \"vrf_keyhash\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"GenesisHash\": {\n            \"title\": \"GenesisHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{56}$\"\n          },\n          \"GenesisDelegateHash\": {\n            \"title\": \"GenesisDelegateHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{56}$\"\n          },\n          \"Anchor\": {\n            \"title\": \"Anchor\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"url\": {\n                \"$ref\": \"cardano-conway.json#/definitions/URL\"\n              },\n              \"data_hash\": {\n                \"$ref\": \"cardano-conway.json#/definitions/DataHash\"\n              }\n            },\n            \"required\": [\n              \"url\",\n              \"data_hash\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"DRep\": {\n            \"title\": \"DRep\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"key_hash\"\n                    ]\n                  },\n                  \"key_hash\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Ed25519KeyHash\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"key_hash\"\n                ]\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"script_hash\"\n                    ]\n                  },\n                  \"script_hash\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"script_hash\"\n                ]\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"always_abstain\"\n                    ]\n                  }\n                },\n                \"required\": [\n                  \"tag\"\n                ]\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"always_no_confidence\"\n                    ]\n                  }\n                },\n                \"required\": [\n                  \"tag\"\n                ]\n              }\n            ]\n          },\n          \"Certificate\": {\n            \"title\": \"Certificate\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"type\": \"object\",\n                \"title\": \"Stake Registration Certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"stake_registration\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Stake Deregistration Certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"stake_deregistration\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Stake Delegation Certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"stake_delegation\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"pool_keyhash\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\",\n                  \"pool_keyhash\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Pool Registration Certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"pool_registration\"\n                    ]\n                  },\n                  \"pool_params\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/PoolParams\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"pool_params\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Pool Retirement Certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"pool_retirement\"\n                    ]\n                  },\n                  \"pool_keyhash\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n                  },\n                  \"epoch\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"pool_keyhash\",\n                  \"epoch\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Registration certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"registration\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"coin\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\",\n                  \"coin\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Unregistration certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"unregistration\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"coin\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\",\n                  \"coin\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Vote delegation certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"vote_delegation\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"drep\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/DRep\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\",\n                  \"drep\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Stake vote delegation certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"stake_vote_delegation\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"pool_keyhash\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n                  },\n                  \"drep\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/DRep\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\",\n                  \"pool_keyhash\",\n                  \"drep\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"stake_registration_delegation\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"pool_keyhash\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n                  },\n                  \"coin\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\",\n                  \"pool_keyhash\",\n                  \"coin\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"vote_registration_delegation\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"pool_keyhash\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n                  },\n                  \"drep\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/DRep\"\n                  },\n                  \"coin\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\",\n                  \"pool_keyhash\",\n                  \"drep\",\n                  \"coin\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Stake registration delegation certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"stake_vote_registration_delegation\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"pool_keyhash\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n                  },\n                  \"drep\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/DRep\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\",\n                  \"pool_keyhash\",\n                  \"drep\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Vote registration delegation certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"vote_registration_delegation\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"drep\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/DRep\"\n                  },\n                  \"coin\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\",\n                  \"drep\",\n                  \"coin\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Stake vote registration delegation certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"stake_vote_registration_delegation\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"pool_keyhash\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/PoolPubKeyHash\"\n                  },\n                  \"drep\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/DRep\"\n                  },\n                  \"coin\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\",\n                  \"pool_keyhash\",\n                  \"drep\",\n                  \"coin\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Constitutional committee hot certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"auth_committee_hot\"\n                    ]\n                  },\n                  \"committee_cold_credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"committee_hot_credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"committee_cold_credential\",\n                  \"committee_hot_credential\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Resign committee cold certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"resign_committee_cold\"\n                    ]\n                  },\n                  \"committee_cold_credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"anchor\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Anchor\"\n                  }\n                },\n                \"required\": [\n                  \"committee_cold_credential\",\n                  \"tag\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Register DRep certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"register_drep\"\n                    ]\n                  },\n                  \"drep_credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"coin\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                  },\n                  \"anchor\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Anchor\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"drep_credential\",\n                  \"coin\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Unregister DRep certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"unregister_drep\"\n                    ]\n                  },\n                  \"drep_credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"coin\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"drep_credential\",\n                  \"coin\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Update DRep certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"update_drep\"\n                    ]\n                  },\n                  \"drep_credential\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                  },\n                  \"anchor\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Anchor\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"drep_credential\"\n                ],\n                \"unevaluatedProperties\": false\n              }\n            ]\n          },\n          \"Constitution\": {\n            \"title\": \"Constitution\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"anchor\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Anchor\"\n              },\n              \"script_hash\": {\n                \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n              }\n            },\n            \"required\": [\n              \"anchor\"\n            ]\n          },\n          \"GovActionId\": {\n            \"title\": \"GovActionId\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"transaction_id\": {\n                \"$ref\": \"cardano-conway.json#/definitions/TransactionHash\"\n              },\n              \"gov_action_index\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt16\"\n              }\n            },\n            \"required\": [\n              \"transaction_id\",\n              \"gov_action_index\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"GovAction\": {\n            \"title\": \"GovAction\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"type\": \"object\",\n                \"title\": \"Parameter Change Action\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"parameter_change_action\"\n                    ]\n                  },\n                  \"gov_action_id\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/GovActionId\"\n                  },\n                  \"protocol_param_update\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/ProtocolParamUpdate\"\n                  },\n                  \"policy_hash\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"protocol_param_update\"\n                ]\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Hard fork initiation action\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"hard_fork_initiation_action\"\n                    ]\n                  },\n                  \"gov_action_id\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/GovActionId\"\n                  },\n                  \"protocol_version\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/ProtocolVersion\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"protocol_version\"\n                ]\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Trasury withdrawals action\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"treasury_withdrawals_action\"\n                    ]\n                  },\n                  \"rewards\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"type\": \"object\",\n                      \"properties\": {\n                        \"key\": {\n                          \"$ref\": \"cardano-conway.json#/definitions/RewardAddress\"\n                        },\n                        \"value\": {\n                          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                        }\n                      },\n                      \"unevaluatedProperties\": false\n                    }\n                  },\n                  \"policy_hash\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n                  }\n                },\n                \"required\": [\n                  \"tag\"\n                ]\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"No confidence governance action\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"no_confidence\"\n                    ]\n                  },\n                  \"gov_action_id\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/GovActionId\"\n                  }\n                },\n                \"required\": [\n                  \"tag\"\n                ]\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Update committee\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"update_committee\"\n                    ]\n                  },\n                  \"gov_action_id\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/GovActionId\"\n                  },\n                  \"members_to_remove\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                    }\n                  },\n                  \"committee\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"type\": \"object\",\n                      \"properties\": {\n                        \"key\": {\n                          \"$ref\": \"cardano-conway.json#/definitions/Credential\"\n                        },\n                        \"value\": {\n                          \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n                        }\n                      },\n                      \"unevaluatedProperties\": false\n                    }\n                  },\n                  \"signature_threshold\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/UnitInterval\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"signature_threshold\",\n                  \"committee\"\n                ]\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"New constitution\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"new_constitution\"\n                    ]\n                  },\n                  \"gov_action_id\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/GovActionId\"\n                  },\n                  \"constitution\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/Constitution\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"constitution\"\n                ]\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Info action\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"info_action\"\n                    ]\n                  }\n                },\n                \"required\": [\n                  \"tag\"\n                ]\n              }\n            ]\n          },\n          \"Language\": {\n            \"title\": \"Language\",\n            \"type\": \"string\",\n            \"enum\": [\n              \"plutus_v1\",\n              \"plutus_v2\",\n              \"plutus_v3\"\n            ]\n          },\n          \"Mint\": {\n            \"title\": \"Mint\",\n            \"description\": \"Minting or burning of assets. A mapping from policy IDs (script hashes) to mappings from asset names to amounts (that can be negative). Allows for duplicate script hash keys.\",\n            \"type\": \"array\",\n            \"items\": {\n              \"type\": \"object\",\n              \"properties\": {\n                \"script_hash\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/ScriptHash\"\n                },\n                \"assets\": {\n                  \"type\": \"array\",\n                  \"items\": {\n                    \"title\": \"Assets\",\n                    \"type\": \"object\",\n                    \"properties\": {\n                      \"asset_name\": {\n                        \"$ref\": \"cardano-conway.json#/definitions/AssetName\"\n                      },\n                      \"amount\": {\n                        \"$ref\": \"cardano-conway.json#/definitions/NonZeroInt64\"\n                      }\n                    },\n                    \"required\": [\n                      \"asset_name\",\n                      \"amount\"\n                    ],\n                    \"unevaluatedProperties\": false\n                  }\n                }\n              },\n              \"required\": [\n                \"script_hash\",\n                \"assets\"\n              ],\n              \"unevaluatedProperties\": false\n            }\n          },\n          \"Ed25519Signature\": {\n            \"title\": \"Ed25519Signature\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^([0-9a-f][0-9a-f]){64}$\"\n          },\n          \"Ed25519PublicKey\": {\n            \"title\": \"Ed25519PublicKey\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^([0-9a-f][0-9a-f]){32}$\"\n          },\n          \"BootstrapWitness\": {\n            \"title\": \"BootstrapWitness\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"attributes\": {\n                \"type\": \"string\",\n                \"format\": \"hex\",\n                \"pattern\": \"^([0-9a-f][0-9a-f])*$\"\n              },\n              \"chain_code\": {\n                \"type\": \"string\",\n                \"format\": \"hex\",\n                \"pattern\": \"^([0-9a-f][0-9a-f]){32}$\"\n              },\n              \"signature\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Ed25519Signature\"\n              },\n              \"vkey\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Ed25519PublicKey\"\n              }\n            },\n            \"required\": [\n              \"attributes\",\n              \"chain_code\",\n              \"signature\",\n              \"vkey\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"RedeemerTag\": {\n            \"title\": \"RedeemerTag\",\n            \"type\": \"string\",\n            \"enum\": [\n              \"spend\",\n              \"mint\",\n              \"cert\",\n              \"reward\",\n              \"vote\",\n              \"propose\"\n            ]\n          },\n          \"Redeemer\": {\n            \"title\": \"Redeemer\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"data\": {\n                \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n              },\n              \"tag\": {\n                \"$ref\": \"cardano-conway.json#/definitions/RedeemerTag\"\n              },\n              \"index\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"ex_units\": {\n                \"$ref\": \"cardano-conway.json#/definitions/ExUnits\"\n              }\n            },\n            \"required\": [\n              \"data\",\n              \"tag\",\n              \"index\",\n              \"ex_units\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"Vkeywitness\": {\n            \"title\": \"Vkeywitness\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"vkey\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Ed25519PublicKey\"\n              },\n              \"signature\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Ed25519Signature\"\n              }\n            },\n            \"required\": [\n              \"vkey\",\n              \"signature\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"TransactionWitnessSet\": {\n            \"title\": \"TransactionWitnessSet\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"bootstraps\": {\n                \"title\": \"BootstrapWitnesses\",\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/BootstrapWitness\"\n                }\n              },\n              \"native_scripts\": {\n                \"title\": \"NativeScripts\",\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/NativeScript\"\n                }\n              },\n              \"plutus_data\": {\n                \"type\": \"array\",\n                \"title\": \"PlutusList\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/PlutusData\"\n                }\n              },\n              \"plutus_scripts\": {\n                \"type\": \"array\",\n                \"title\": \"PlutusScripts\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/PlutusScript\"\n                }\n              },\n              \"redeemers\": {\n                \"type\": \"array\",\n                \"title\": \"Redeemers\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/Redeemer\"\n                }\n              },\n              \"vkeywitnesses\": {\n                \"type\": \"array\",\n                \"title\": \"VkeyWitnesses\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/Vkeywitness\"\n                }\n              }\n            },\n            \"required\": []\n          },\n          \"Transaction\": {\n            \"type\": \"object\",\n            \"title\": \"Transaction\",\n            \"properties\": {\n              \"auxiliary_data\": {\n                \"$ref\": \"cardano-conway.json#/definitions/AuxiliaryData\"\n              },\n              \"body\": {\n                \"$ref\": \"cardano-conway.json#/definitions/TransactionBody\"\n              },\n              \"is_valid\": {\n                \"type\": \"boolean\"\n              },\n              \"witness_set\": {\n                \"$ref\": \"cardano-conway.json#/definitions/TransactionWitnessSet\"\n              }\n            },\n            \"required\": [\n              \"body\",\n              \"is_valid\",\n              \"witness_set\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"VRFCert\": {\n            \"title\": \"VRFCert\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"output\": {\n                \"$ref\": \"cardano-conway.json#/definitions/ByteString\"\n              },\n              \"proof\": {\n                \"$ref\": \"cardano-conway.json#/definitions/ByteString\",\n                \"type\": \"string\",\n                \"pattern\": \"^[0-9a-f]{160}$\"\n              }\n            },\n            \"required\": [\n              \"output\",\n              \"proof\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"KESVKey\": {\n            \"title\": \"KESVKey\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\",\n            \"maxLength\": 64,\n            \"minLength\": 64\n          },\n          \"BlockHash\": {\n            \"title\": \"BlockHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\",\n            \"maxLength\": 64,\n            \"minLength\": 64\n          },\n          \"VRFVKey\": {\n            \"title\": \"VRFVKey\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\",\n            \"maxLength\": 64,\n            \"minLength\": 64\n          },\n          \"KESSignature\": {\n            \"title\": \"KESSignature\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{896}$\",\n            \"maxLength\": 896,\n            \"minLength\": 896\n          },\n          \"OperationalCert\": {\n            \"title\": \"OperationalCert\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"hot_vkey\": {\n                \"$ref\": \"cardano-conway.json#/definitions/KESVKey\"\n              },\n              \"kes_period\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"sequence_number\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"sigma\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Ed25519Signature\"\n              }\n            },\n            \"required\": [\n              \"hot_vkey\",\n              \"kes_period\",\n              \"sequence_number\",\n              \"sigma\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"HeaderBody\": {\n            \"title\": \"HeaderBody\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"block_number\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"slot\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt64\"\n              },\n              \"prev_hash\": {\n                \"$ref\": \"cardano-conway.json#/definitions/BlockHash\"\n              },\n              \"issuer_vkey\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Ed25519PublicKey\"\n              },\n              \"vrf_vkey\": {\n                \"$ref\": \"cardano-conway.json#/definitions/VRFVKey\"\n              },\n              \"vrf_result\": {\n                \"$ref\": \"cardano-conway.json#/definitions/VRFCert\"\n              },\n              \"block_body_size\": {\n                \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n              },\n              \"block_body_hash\": {\n                \"$ref\": \"cardano-conway.json#/definitions/BlockHash\"\n              },\n              \"operational_cert\": {\n                \"$ref\": \"cardano-conway.json#/definitions/OperationalCert\"\n              },\n              \"protocol_version\": {\n                \"$ref\": \"cardano-conway.json#/definitions/ProtocolVersion\"\n              }\n            },\n            \"unevaluatedProperties\": false,\n            \"required\": [\n              \"block_number\",\n              \"slot\",\n              \"issuer_vkey\",\n              \"vrf_vkey\",\n              \"vrf_result\",\n              \"block_body_size\",\n              \"block_body_hash\",\n              \"operational_cert\",\n              \"protocol_version\"\n            ]\n          },\n          \"Header\": {\n            \"title\": \"Header\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"body_signature\": {\n                \"$ref\": \"cardano-conway.json#/definitions/KESSignature\"\n              },\n              \"header_body\": {\n                \"$ref\": \"cardano-conway.json#/definitions/HeaderBody\"\n              }\n            },\n            \"required\": [\n              \"body_signature\",\n              \"header_body\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"Block\": {\n            \"title\": \"Block\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"auxiliary_data_set\": {\n                \"type\": \"object\",\n                \"title\": \"AuxiliaryDataSet\",\n                \"description\": \"A mapping from transaction indices to AuxiliaryData values\",\n                \"patternProperties\": {\n                  \"^(0|[1-9][0-9]*)$\": {\n                    \"$ref\": \"cardano-conway.json#/definitions/AuxiliaryData\"\n                  }\n                },\n                \"unevaluatedProperties\": false\n              },\n              \"header\": {\n                \"$ref\": \"cardano-conway.json#/definitions/Header\"\n              },\n              \"invalid_transactions\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"allOf\": [\n                    {\n                      \"title\": \"TransactionIndex\"\n                    },\n                    {\n                      \"$ref\": \"cardano-conway.json#/definitions/UInt32\"\n                    }\n                  ]\n                }\n              },\n              \"transaction_bodies\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/TransactionBody\"\n                }\n              },\n              \"transaction_witness_sets\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-conway.json#/definitions/TransactionWitnessSet\"\n                }\n              }\n            },\n            \"unevaluatedProperties\": false,\n            \"required\": [\n              \"auxiliary_data_set\",\n              \"header\",\n              \"invalid_transactions\",\n              \"transaction_bodies\",\n              \"transaction_witness_sets\"\n            ]\n          }\n        }\n      },\n      \"cardano-babbage.json\": {\n        \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n        \"$id\": \"cardano-babbage.json\",\n        \"title\": \"Cardano Babbage Era Domain Types\",\n        \"definitions\": {\n          \"BigInt\": {\n            \"title\": \"BigInt\",\n            \"type\": \"string\",\n            \"description\": \"A long integer domain type\",\n            \"pattern\": \"^(0|-?[1-9][0-9]*)$\",\n            \"examples\": [\n              \"0\",\n              \"-123\",\n              \"123\"\n            ]\n          },\n          \"ByteString\": {\n            \"title\": \"ByteString\",\n            \"description\": \"Arbitrary-length byte array\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^([0-9a-f][0-9a-f])*$\"\n          },\n          \"UInt64\": {\n            \"title\": \"UInt64\",\n            \"description\": \"64-bit unsigned integer\",\n            \"type\": \"string\",\n            \"pattern\": \"^(0|[1-9][0-9]*)$\",\n            \"format\": \"uint64\"\n          },\n          \"PosInt64\": {\n            \"title\": \"PosInt64\",\n            \"description\": \"64-bit unsigned integer, zero-excluded. 1-18446744073709551615\",\n            \"type\": \"string\",\n            \"pattern\": \"^([1-9][0-9]*)$\",\n            \"format\": \"posint64\"\n          },\n          \"Int128\": {\n            \"title\": \"Int128\",\n            \"description\": \"128-bit signed integer\",\n            \"type\": \"string\",\n            \"pattern\": \"^-?(0|[1-9][0-9]*)$\",\n            \"format\": \"int128\"\n          },\n          \"NonZeroInt64\": {\n            \"title\": \"NonZeroInt64\",\n            \"description\": \"64-bit signed integer, zero excluded. Ranges: -9223372036854775808..-1 and 1..9223372036854775807\",\n            \"type\": \"string\",\n            \"pattern\": \"^-?([1-9][0-9]*)$\"\n          },\n          \"UInt32\": {\n            \"title\": \"UInt32\",\n            \"description\": \"32-bit unsigned integer\",\n            \"type\": \"integer\",\n            \"minimum\": 0,\n            \"maximum\": 4294967295\n          },\n          \"RewardAddress\": {\n            \"title\": \"RewardAddress\",\n            \"type\": \"string\",\n            \"format\": \"bech32\",\n            \"pattern\": \"^(stake1|stake_test1)[02-9ac-hj-np-z]*$\",\n            \"examples\": [\n              \"stake1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5egfu2p0u\"\n            ]\n          },\n          \"ByronAddress\": {\n            \"title\": \"ByronAddress\",\n            \"type\": \"string\",\n            \"format\": \"base58\",\n            \"pattern\": \"^[1-9A-HJ-NP-Za-km-z]+$\",\n            \"examples\": [\n              \"37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na\"\n            ]\n          },\n          \"PointerAddress\": {\n            \"title\": \"PointerAddress\",\n            \"type\": \"string\",\n            \"format\": \"bech32\",\n            \"pattern\": \"^(addr1|addr_test1)[02-9ac-hj-np-z]*$\",\n            \"examples\": [\n              \"addr1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0yu80w\"\n            ]\n          },\n          \"EnterpriseAddress\": {\n            \"title\": \"EnterpriseAddress\",\n            \"type\": \"string\",\n            \"format\": \"bech32\",\n            \"pattern\": \"^(addr1|addr_test1)[02-9ac-hj-np-z]*$\",\n            \"examples\": [\n              \"addr1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0yu80w\"\n            ]\n          },\n          \"BaseAddress\": {\n            \"title\": \"BaseAddress\",\n            \"type\": \"string\",\n            \"format\": \"bech32\",\n            \"pattern\": \"^(addr1|addr_test1)[02-9ac-hj-np-z]*$\",\n            \"examples\": [\n              \"addr1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0yu80w\"\n            ]\n          },\n          \"Address\": {\n            \"title\": \"Address\",\n            \"anyOf\": [\n              {\n                \"$ref\": \"cardano-babbage.json#/definitions/RewardAddress\"\n              },\n              {\n                \"$ref\": \"cardano-babbage.json#/definitions/BaseAddress\"\n              },\n              {\n                \"$ref\": \"cardano-babbage.json#/definitions/PointerAddress\"\n              },\n              {\n                \"$ref\": \"cardano-babbage.json#/definitions/EnterpriseAddress\"\n              },\n              {\n                \"$ref\": \"cardano-babbage.json#/definitions/ByronAddress\"\n              }\n            ]\n          },\n          \"Ed25519KeyHash\": {\n            \"title\": \"Ed25519KeyHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{56}$\"\n          },\n          \"ScriptHash\": {\n            \"title\": \"ScriptHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{56}$\"\n          },\n          \"AssetName\": {\n            \"title\": \"AssetName\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^([0-9a-f][0-9a-f]){0,32}$\",\n            \"examples\": [\n              \"504154415445\",\n              \"1e349c9bdea19fd6c147626a5260bc44b71635f398b67c59881df209\",\n              \"7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc373\"\n            ]\n          },\n          \"Credential\": {\n            \"title\": \"Credential\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"pubkey_hash\"\n                    ]\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/Ed25519KeyHash\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"script_hash\"\n                    ]\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/ScriptHash\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              }\n            ]\n          },\n          \"MultiAsset\": {\n            \"title\": \"MultiAsset\",\n            \"description\": \"A mapping from policy IDs (script hashes) to mappings from asset names to amounts\",\n            \"type\": \"object\",\n            \"patternProperties\": {\n              \"^[0-9a-f]{56}$\": {\n                \"type\": \"object\",\n                \"patternProperties\": {\n                  \"^([0-9a-f][0-9a-f]){0,32}$\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/PosInt64\"\n                  }\n                },\n                \"unevaluatedProperties\": false\n              }\n            },\n            \"unevaluatedProperties\": false\n          },\n          \"Value\": {\n            \"title\": \"Value\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"coin\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"assets\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/MultiAsset\"\n              }\n            },\n            \"required\": [\n              \"coin\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"TransactionHash\": {\n            \"title\": \"TransactionHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\",\n            \"maxLength\": 64,\n            \"minLength\": 64,\n            \"examples\": [\n              \"eca40340fa6e65d964915ba4bc8bd811a0493d263ffe95875291114cbb2d0686\",\n              \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n              \"fbc1da46d62a431e69855ad48a6b49b0e2aaafc6fd3dc4a066c6851b7bd31a91\",\n              \"c6726192662abeab149098095eabe004ecbec47f5e564748ab0d394affca47d9\"\n            ]\n          },\n          \"TransactionInput\": {\n            \"title\": \"TransactionInput\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"transaction_id\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/TransactionHash\"\n              },\n              \"index\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              }\n            },\n            \"required\": [\n              \"transaction_id\",\n              \"index\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"PlutusScript\": {\n            \"title\": \"PlutusScript\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"language\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/Language\"\n              },\n              \"bytes\": {\n                \"type\": \"string\",\n                \"format\": \"hex\",\n                \"pattern\": \"^([0-9a-f][0-9a-f])+$\"\n              }\n            },\n            \"required\": [\n              \"language\",\n              \"bytes\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"NativeScript\": {\n            \"title\": \"NativeScript\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"title\": \"ScriptPubkey\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"pubkey\"\n                    ]\n                  },\n                  \"pubkey\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/Ed25519KeyHash\"\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"pubkey\"\n                ]\n              },\n              {\n                \"title\": \"ScriptAll\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"all\"\n                    ]\n                  },\n                  \"scripts\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"$ref\": \"cardano-babbage.json#/definitions/NativeScript\"\n                    }\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"scripts\"\n                ]\n              },\n              {\n                \"title\": \"ScriptAny\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"any\"\n                    ]\n                  },\n                  \"scripts\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"$ref\": \"cardano-babbage.json#/definitions/NativeScript\"\n                    }\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"scripts\"\n                ]\n              },\n              {\n                \"title\": \"ScriptNOfK\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"n_of_k\"\n                    ]\n                  },\n                  \"scripts\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"$ref\": \"cardano-babbage.json#/definitions/NativeScript\"\n                    }\n                  },\n                  \"n\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"scripts\",\n                  \"n\"\n                ]\n              },\n              {\n                \"title\": \"TimelockStart\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"timelock_start\"\n                    ]\n                  },\n                  \"slot\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"slot\"\n                ]\n              },\n              {\n                \"title\": \"TimelockExpiry\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"timelock_expiry\"\n                    ]\n                  },\n                  \"slot\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"slot\"\n                ]\n              }\n            ]\n          },\n          \"ScriptRef\": {\n            \"title\": \"ScriptRef\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"title\": \"PlutusScript\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"plutus_script\"\n                    ]\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/PlutusScript\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"title\": \"NativeScript\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"native_script\"\n                    ]\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/NativeScript\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              }\n            ]\n          },\n          \"DataHash\": {\n            \"title\": \"DataHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^([0-9a-f][0-9a-f]){32}$\"\n          },\n          \"TransactionOutput\": {\n            \"title\": \"TransactionOutput\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"address\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/Address\"\n              },\n              \"amount\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/Value\"\n              },\n              \"plutus_data\": {\n                \"type\": \"object\",\n                \"discriminator\": {\n                  \"propertyName\": \"tag\"\n                },\n                \"oneOf\": [\n                  {\n                    \"type\": \"object\",\n                    \"properties\": {\n                      \"tag\": {\n                        \"enum\": [\n                          \"datum\"\n                        ]\n                      },\n                      \"value\": {\n                        \"$ref\": \"cardano-babbage.json#/definitions/PlutusData\"\n                      }\n                    }\n                  },\n                  {\n                    \"type\": \"object\",\n                    \"properties\": {\n                      \"tag\": {\n                        \"enum\": [\n                          \"datum_hash\"\n                        ]\n                      },\n                      \"value\": {\n                        \"$ref\": \"cardano-babbage.json#/definitions/DataHash\"\n                      }\n                    }\n                  }\n                ],\n                \"unevaluatedProperties\": false\n              },\n              \"script_ref\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/ScriptRef\"\n              }\n            },\n            \"required\": [\n              \"address\",\n              \"amount\"\n            ]\n          },\n          \"TransactionUnspentOutput\": {\n            \"title\": \"TransactionUnspentOutput\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"input\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/TransactionInput\"\n              },\n              \"output\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/TransactionOutput\"\n              }\n            },\n            \"required\": [\n              \"input\",\n              \"output\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"TransactionMetadatum\": {\n            \"title\": \"TransactionMetadatum\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"map\"\n                    ]\n                  },\n                  \"contents\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"type\": \"object\",\n                      \"properties\": {\n                        \"key\": {\n                          \"$ref\": \"cardano-babbage.json#/definitions/TransactionMetadatum\"\n                        },\n                        \"value\": {\n                          \"$ref\": \"cardano-babbage.json#/definitions/TransactionMetadatum\"\n                        }\n                      },\n                      \"required\": [\n                        \"key\",\n                        \"value\"\n                      ],\n                      \"unevaluatedProperties\": false\n                    }\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"contents\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"list\"\n                    ]\n                  },\n                  \"contents\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"$ref\": \"cardano-babbage.json#/definitions/TransactionMetadatum\"\n                    }\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"contents\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"int\"\n                    ]\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/Int128\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"bytes\"\n                    ]\n                  },\n                  \"value\": {\n                    \"type\": \"string\",\n                    \"format\": \"hex\",\n                    \"pattern\": \"^([0-9a-f][0-9a-f]){0,64}$\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"title\": \"Metadata String\",\n                \"description\": \"UTF-8 string. Maximum size is 64 bytes, but there is no way to express byte length limit in a json-schema (maxLength limits the number of characters)\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"string\"\n                    ]\n                  },\n                  \"value\": {\n                    \"type\": \"string\",\n                    \"maxLength\": 64,\n                    \"format\": \"string64\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              }\n            ]\n          },\n          \"PlutusV1CostModel\": {\n            \"title\": \"PlutusV1CostModel\",\n            \"type\": \"array\",\n            \"items\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/Int128\"\n            },\n            \"maxItems\": 166,\n            \"minItems\": 166\n          },\n          \"PlutusV2CostModel\": {\n            \"title\": \"PlutusV2CostModel\",\n            \"type\": \"array\",\n            \"items\": {\n              \"$ref\": \"cardano-babbage.json#/definitions/Int128\"\n            },\n            \"maxItems\": 175,\n            \"minItems\": 175\n          },\n          \"CostModels\": {\n            \"title\": \"CostModels\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"plutus_v1\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/PlutusV1CostModel\"\n              },\n              \"plutus_v2\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/PlutusV2CostModel\"\n              }\n            },\n            \"required\": [],\n            \"unevaluatedProperties\": false\n          },\n          \"ExUnitPrices\": {\n            \"title\": \"ExUnitPrices\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"mem_price\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UnitInterval\"\n              },\n              \"step_price\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UnitInterval\"\n              }\n            },\n            \"unevaluatedProperties\": false,\n            \"required\": [\n              \"mem_price\",\n              \"step_price\"\n            ]\n          },\n          \"ExUnits\": {\n            \"title\": \"ExUnits\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"mem\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"steps\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              }\n            },\n            \"required\": [\n              \"mem\",\n              \"steps\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"ProtocolVersion\": {\n            \"title\": \"ProtocolVersion\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"major\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              },\n              \"minor\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              }\n            },\n            \"required\": [\n              \"major\",\n              \"minor\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"ProtocolParamUpdate\": {\n            \"title\": \"ProtocolParamUpdate\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"ada_per_utxo_byte\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"collateral_percentage\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              },\n              \"cost_models\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/CostModels\"\n              },\n              \"d\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UnitInterval\"\n              },\n              \"execution_costs\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/ExUnitPrices\"\n              },\n              \"expansion_rate\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UnitInterval\"\n              },\n              \"key_deposit\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"max_block_body_size\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              },\n              \"max_block_ex_units\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/ExUnits\"\n              },\n              \"max_block_header_size\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              },\n              \"max_collateral_inputs\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              },\n              \"max_epoch\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              },\n              \"max_tx_ex_units\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/ExUnits\"\n              },\n              \"max_tx_size\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              },\n              \"max_value_size\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              },\n              \"min_pool_cost\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"minfee_a\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"minfee_b\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"n_opt\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"pool_deposit\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"pool_pledge_influence\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UnitInterval\"\n              },\n              \"protocol_version\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/ProtocolVersion\"\n              },\n              \"treasury_growth_rate\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UnitInterval\"\n              }\n            },\n            \"unevaluatedProperties\": false,\n            \"required\": []\n          },\n          \"Update\": {\n            \"title\": \"Update\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"epoch\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              },\n              \"proposed_protocol_parameter_updates\": {\n                \"type\": \"object\",\n                \"title\": \"ProposedProtocolParameterUpdates\",\n                \"description\": \"A mapping from GenesisHash to ProtocolParamUpdate\",\n                \"patternProperties\": {\n                  \"^[0-9a-f]{56}$\": {\n                    \"title\": \"ProtocolParamUpdate for a given GenesisHash\",\n                    \"$ref\": \"cardano-babbage.json#/definitions/ProtocolParamUpdate\"\n                  }\n                },\n                \"unevaluatedProperties\": false\n              }\n            },\n            \"required\": [\n              \"epoch\",\n              \"proposed_protocol_parameter_updates\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"ScriptDataHash\": {\n            \"title\": \"ScriptDataHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\"\n          },\n          \"TransactionMetadata\": {\n            \"title\": \"TransactionMetadata\",\n            \"type\": \"array\",\n            \"items\": {\n              \"type\": \"object\",\n              \"properties\": {\n                \"key\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n                },\n                \"value\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/TransactionMetadatum\"\n                }\n              },\n              \"required\": [\n                \"key\",\n                \"value\"\n              ],\n              \"unevaluatedProperties\": false\n            }\n          },\n          \"AuxiliaryDataHash\": {\n            \"title\": \"AuxiliaryDataHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\"\n          },\n          \"AuxiliaryData\": {\n            \"title\": \"AuxiliaryData\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"metadata\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/TransactionMetadata\"\n              },\n              \"native_scripts\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/NativeScript\"\n                }\n              },\n              \"plutus_scripts\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/PlutusScript\"\n                }\n              }\n            },\n            \"required\": [],\n            \"unevaluatedProperties\": false\n          },\n          \"TransactionBody\": {\n            \"title\": \"TransactionBody\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"auxiliary_data_hash\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/AuxiliaryDataHash\"\n              },\n              \"inputs\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/TransactionInput\"\n                }\n              },\n              \"outputs\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/TransactionOutput\"\n                }\n              },\n              \"fee\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"certs\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/Certificate\"\n                }\n              },\n              \"collateral\": {\n                \"title\": \"Collateral Inputs\",\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/TransactionInput\"\n                }\n              },\n              \"collateral_return\": {\n                \"allOf\": [\n                  {\n                    \"$ref\": \"cardano-babbage.json#/definitions/TransactionOutput\"\n                  },\n                  {\n                    \"title\": \"Collateral Return\",\n                    \"description\": \"Collateral return, introduced in CIP-40\"\n                  }\n                ]\n              },\n              \"mint\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/Mint\"\n              },\n              \"network_id\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/NetworkId\"\n              },\n              \"reference_inputs\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/TransactionInput\"\n                }\n              },\n              \"required_signers\": {\n                \"title\": \"Required signers\",\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/Ed25519KeyHash\"\n                }\n              },\n              \"script_data_hash\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/ScriptDataHash\"\n              },\n              \"total_collateral\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"ttl\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"update\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/Update\"\n              },\n              \"validity_start_interval\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"withdrawals\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"type\": \"object\",\n                  \"properties\": {\n                    \"key\": {\n                      \"$ref\": \"cardano-babbage.json#/definitions/RewardAddress\"\n                    },\n                    \"value\": {\n                      \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n                    }\n                  },\n                  \"unevaluatedProperties\": false\n                }\n              }\n            },\n            \"required\": [\n              \"inputs\",\n              \"outputs\",\n              \"fee\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"NetworkId\": {\n            \"title\": \"NetworkId\",\n            \"type\": \"string\",\n            \"enum\": [\n              \"testnet\",\n              \"mainnet\"\n            ]\n          },\n          \"PlutusData\": {\n            \"title\": \"PlutusData\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"title\": \"PlutusDataList\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"list\"\n                    ]\n                  },\n                  \"contents\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"$ref\": \"cardano-babbage.json#/definitions/PlutusData\"\n                    }\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"contents\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"title\": \"PlutusDataConstr\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"constr\"\n                    ]\n                  },\n                  \"alternative\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n                  },\n                  \"data\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"$ref\": \"cardano-babbage.json#/definitions/PlutusData\"\n                    }\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"alternative\",\n                  \"data\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"title\": \"PlutusDataMap\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"map\"\n                    ]\n                  },\n                  \"contents\": {\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"type\": \"object\",\n                      \"properties\": {\n                        \"key\": {\n                          \"$ref\": \"cardano-babbage.json#/definitions/PlutusData\"\n                        },\n                        \"value\": {\n                          \"$ref\": \"cardano-babbage.json#/definitions/PlutusData\"\n                        }\n                      },\n                      \"unevaluatedProperties\": false\n                    }\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"contents\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"title\": \"PlutusDataInteger\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"integer\"\n                    ]\n                  },\n                  \"value\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/BigInt\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"title\": \"PlutusDataBytes\",\n                \"type\": \"object\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"bytes\"\n                    ]\n                  },\n                  \"value\": {\n                    \"type\": \"string\",\n                    \"format\": \"hex\",\n                    \"pattern\": \"^([0-9a-f][0-9a-f])*$\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"value\"\n                ],\n                \"unevaluatedProperties\": false\n              }\n            ]\n          },\n          \"UnitInterval\": {\n            \"title\": \"UnitInterval\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"numerator\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"denominator\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              }\n            },\n            \"required\": [\n              \"numerator\",\n              \"denominator\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"Ipv4\": {\n            \"title\": \"Ipv4\",\n            \"description\": \"IPv4 Address\",\n            \"type\": \"string\",\n            \"pattern\": \"^((25[0-5]|(2[0-4]|1\\\\d|[1-9]|)\\\\d)\\\\.){3}(25[0-5]|(2[0-4]|1\\\\d|[1-9]|)\\\\d)$\"\n          },\n          \"Ipv6\": {\n            \"title\": \"Ipv6\",\n            \"description\": \"IPv6 address\",\n            \"type\": \"string\",\n            \"format\": \"ipv6\"\n          },\n          \"DNSName\": {\n            \"title\": \"DNSName\",\n            \"type\": \"string\",\n            \"maxLength\": 64,\n            \"format\": \"string64\"\n          },\n          \"Relay\": {\n            \"title\": \"Relay\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"type\": \"object\",\n                \"title\": \"SingleHostAddr\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"single_host_addr\"\n                    ]\n                  },\n                  \"port\": {\n                    \"type\": \"integer\",\n                    \"maximum\": 65535\n                  },\n                  \"ipv4\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/Ipv4\"\n                  },\n                  \"ipv6\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/Ipv6\"\n                  }\n                },\n                \"required\": [\n                  \"tag\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"SingleHostName\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"single_host_name\"\n                    ]\n                  },\n                  \"port\": {\n                    \"type\": \"integer\",\n                    \"minimum\": 1,\n                    \"maximum\": 65535\n                  },\n                  \"dns_name\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/DNSName\"\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"dns_name\"\n                ]\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"MultiHostName\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"multi_host_name\"\n                    ]\n                  },\n                  \"dns_name\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/DNSName\"\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"tag\",\n                  \"dns_name\"\n                ]\n              }\n            ]\n          },\n          \"VRFKeyHash\": {\n            \"title\": \"VRFKeyHash\",\n            \"type\": \"string\",\n            \"description\": \"blake2b_256 digest of a VRF verification key, encoded as bech32\",\n            \"pattern\": \"^vrf_vkh[02-9ac-hj-np-z]*\",\n            \"format\": \"bech32\",\n            \"examples\": [\n              \"vrf_vkh3ak4chlh2xj9tw3jjwxdgs7v2uq6ev86l03vw\"\n            ]\n          },\n          \"URL\": {\n            \"title\": \"URL\",\n            \"description\": \"UTF-8 URL string. Maximum size is 64 bytes, but there is no way to express byte length limit in a json-schema (maxLength limits the number of characters)\",\n            \"type\": \"string\",\n            \"maxLength\": 64,\n            \"format\": \"string64\"\n          },\n          \"PoolMetadataHash\": {\n            \"title\": \"PoolMetadataHash\",\n            \"description\": \"Pool Metadata Hash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\"\n          },\n          \"PoolMetadata\": {\n            \"title\": \"PoolMetadata\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"url\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/URL\"\n              },\n              \"hash\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/PoolMetadataHash\"\n              }\n            },\n            \"unevaluatedProperties\": false,\n            \"required\": [\n              \"url\",\n              \"hash\"\n            ]\n          },\n          \"PoolPubKeyHash\": {\n            \"title\": \"PoolPubKeyHash\",\n            \"type\": \"string\",\n            \"format\": \"bech32\",\n            \"pattern\": \"^(pool1)[02-9ac-hj-np-z]*$\",\n            \"examples\": [\n              \"pool12a39rkzfylvn9wfe8j6y8ucq6g2l4mw4azj70y0gd8ejczznyj2\"\n            ]\n          },\n          \"PoolParams\": {\n            \"title\": \"PoolParams\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"operator\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/PoolPubKeyHash\"\n              },\n              \"vrf_keyhash\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/VRFKeyHash\"\n              },\n              \"pledge\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"cost\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"margin\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UnitInterval\"\n              },\n              \"reward_account\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/RewardAddress\"\n              },\n              \"pool_owners\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/Ed25519KeyHash\"\n                }\n              },\n              \"relays\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/Relay\"\n                }\n              },\n              \"pool_metadata\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/PoolMetadata\"\n              }\n            },\n            \"required\": [\n              \"cost\",\n              \"margin\",\n              \"operator\",\n              \"pledge\",\n              \"pool_owners\",\n              \"relays\",\n              \"reward_account\",\n              \"vrf_keyhash\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"GenesisHash\": {\n            \"title\": \"GenesisHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{56}$\"\n          },\n          \"GenesisDelegateHash\": {\n            \"title\": \"GenesisDelegateHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{56}$\"\n          },\n          \"MIRPot\": {\n            \"title\": \"MIRPot\",\n            \"enum\": [\n              \"reserves\",\n              \"treasury\"\n            ]\n          },\n          \"MoveInstantaneousRewards\": {\n            \"title\": \"MoveInstantaneousRewards\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"type\": \"object\",\n                \"title\": \"Move Instantaneous Rewards to stake credentials\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"to_stake_creds\"\n                    ]\n                  },\n                  \"pot\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/MIRPot\"\n                  },\n                  \"rewards\": {\n                    \"title\": \"MIRToStakeCredentials\",\n                    \"description\": \"Distribution of rewards\",\n                    \"type\": \"array\",\n                    \"items\": {\n                      \"type\": \"object\",\n                      \"properties\": {\n                        \"key\": {\n                          \"$ref\": \"cardano-babbage.json#/definitions/Credential\"\n                        },\n                        \"value\": {\n                          \"$ref\": \"cardano-babbage.json#/definitions/Int128\"\n                        }\n                      },\n                      \"required\": [\n                        \"key\",\n                        \"value\"\n                      ],\n                      \"unevaluatedProperties\": false\n                    }\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"pot\",\n                  \"rewards\"\n                ]\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Move Instantaneous Rewards to other Pot (reserves or treasury)\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"to_other_pot\"\n                    ]\n                  },\n                  \"pot\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/MIRPot\"\n                  },\n                  \"amount\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n                  }\n                },\n                \"unevaluatedProperties\": false,\n                \"required\": [\n                  \"pot\",\n                  \"amount\"\n                ]\n              }\n            ]\n          },\n          \"Certificate\": {\n            \"title\": \"Certificate\",\n            \"type\": \"object\",\n            \"discriminator\": {\n              \"propertyName\": \"tag\"\n            },\n            \"oneOf\": [\n              {\n                \"type\": \"object\",\n                \"title\": \"Stake Registration Certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"stake_registration\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/Credential\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Stake Deregistration Certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"stake_deregistration\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/Credential\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Stake Delegation Certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"stake_delegation\"\n                    ]\n                  },\n                  \"credential\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/Credential\"\n                  },\n                  \"pool_keyhash\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/PoolPubKeyHash\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"credential\",\n                  \"pool_keyhash\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Pool Registration Certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"pool_registration\"\n                    ]\n                  },\n                  \"pool_params\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/PoolParams\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"pool_params\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Pool Retirement Certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"pool_retirement\"\n                    ]\n                  },\n                  \"pool_keyhash\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/PoolPubKeyHash\"\n                  },\n                  \"epoch\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"pool_keyhash\",\n                  \"epoch\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Genesis Key Delegation Certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"type\": \"string\",\n                    \"enum\": [\n                      \"genesis_key_delegation\"\n                    ]\n                  },\n                  \"genesis_hash\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/GenesisHash\"\n                  },\n                  \"genesis_delegate_hash\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/GenesisDelegateHash\"\n                  },\n                  \"vrf_keyhash\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/VRFKeyHash\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"genesis_hash\",\n                  \"genesis_delegate_hash\",\n                  \"vrf_keyhash\"\n                ],\n                \"unevaluatedProperties\": false\n              },\n              {\n                \"type\": \"object\",\n                \"title\": \"Move Instantaneous Rewards Certificate\",\n                \"properties\": {\n                  \"tag\": {\n                    \"enum\": [\n                      \"move_instantaneous_rewards\"\n                    ]\n                  },\n                  \"move_instantaneous_rewards\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/MoveInstantaneousRewards\"\n                  }\n                },\n                \"required\": [\n                  \"tag\",\n                  \"move_instantaneous_rewards\"\n                ],\n                \"unevaluatedProperties\": false\n              }\n            ]\n          },\n          \"Language\": {\n            \"title\": \"Language\",\n            \"type\": \"string\",\n            \"enum\": [\n              \"plutus_v1\",\n              \"plutus_v2\"\n            ]\n          },\n          \"Mint\": {\n            \"title\": \"Mint\",\n            \"description\": \"Minting or burning of assets. A mapping from policy IDs (script hashes) to mappings from asset names to amounts (that can be negative). Allows for duplicate script hash keys.\",\n            \"type\": \"array\",\n            \"items\": {\n              \"type\": \"object\",\n              \"properties\": {\n                \"script_hash\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/ScriptHash\"\n                },\n                \"assets\": {\n                  \"type\": \"array\",\n                  \"items\": {\n                    \"title\": \"Assets\",\n                    \"type\": \"object\",\n                    \"properties\": {\n                      \"asset_name\": {\n                        \"$ref\": \"cardano-babbage.json#/definitions/AssetName\"\n                      },\n                      \"amount\": {\n                        \"$ref\": \"cardano-babbage.json#/definitions/NonZeroInt64\"\n                      }\n                    },\n                    \"required\": [\n                      \"asset_name\",\n                      \"amount\"\n                    ],\n                    \"unevaluatedProperties\": false\n                  }\n                }\n              },\n              \"required\": [\n                \"script_hash\",\n                \"assets\"\n              ],\n              \"unevaluatedProperties\": false\n            }\n          },\n          \"Ed25519Signature\": {\n            \"title\": \"Ed25519Signature\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^([0-9a-f][0-9a-f]){64}$\"\n          },\n          \"Ed25519PublicKey\": {\n            \"title\": \"Ed25519PublicKey\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^([0-9a-f][0-9a-f]){32}$\"\n          },\n          \"BootstrapWitness\": {\n            \"title\": \"BootstrapWitness\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"attributes\": {\n                \"type\": \"string\",\n                \"format\": \"hex\",\n                \"pattern\": \"^([0-9a-f][0-9a-f])*$\"\n              },\n              \"chain_code\": {\n                \"type\": \"string\",\n                \"format\": \"hex\",\n                \"pattern\": \"^([0-9a-f][0-9a-f]){32}$\"\n              },\n              \"signature\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/Ed25519Signature\"\n              },\n              \"vkey\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/Ed25519PublicKey\"\n              }\n            },\n            \"required\": [\n              \"attributes\",\n              \"chain_code\",\n              \"signature\",\n              \"vkey\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"RedeemerTag\": {\n            \"title\": \"RedeemerTag\",\n            \"type\": \"string\",\n            \"enum\": [\n              \"spend\",\n              \"mint\",\n              \"cert\",\n              \"reward\"\n            ]\n          },\n          \"Redeemer\": {\n            \"title\": \"Redeemer\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"data\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/PlutusData\"\n              },\n              \"tag\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/RedeemerTag\"\n              },\n              \"index\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"ex_units\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/ExUnits\"\n              }\n            },\n            \"required\": [\n              \"data\",\n              \"tag\",\n              \"index\",\n              \"ex_units\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"Vkeywitness\": {\n            \"title\": \"Vkeywitness\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"vkey\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/Ed25519PublicKey\"\n              },\n              \"signature\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/Ed25519Signature\"\n              }\n            },\n            \"required\": [\n              \"vkey\",\n              \"signature\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"TransactionWitnessSet\": {\n            \"title\": \"TransactionWitnessSet\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"bootstraps\": {\n                \"title\": \"BootstrapWitnesses\",\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/BootstrapWitness\"\n                }\n              },\n              \"native_scripts\": {\n                \"title\": \"NativeScripts\",\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/NativeScript\"\n                }\n              },\n              \"plutus_data\": {\n                \"type\": \"array\",\n                \"title\": \"PlutusList\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/PlutusData\"\n                }\n              },\n              \"plutus_scripts\": {\n                \"type\": \"array\",\n                \"title\": \"PlutusScripts\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/PlutusScript\"\n                }\n              },\n              \"redeemers\": {\n                \"type\": \"array\",\n                \"title\": \"Redeemers\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/Redeemer\"\n                }\n              },\n              \"vkeywitnesses\": {\n                \"type\": \"array\",\n                \"title\": \"VkeyWitnesses\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/Vkeywitness\"\n                }\n              }\n            },\n            \"required\": []\n          },\n          \"Transaction\": {\n            \"type\": \"object\",\n            \"title\": \"Transaction\",\n            \"properties\": {\n              \"auxiliary_data\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/AuxiliaryData\"\n              },\n              \"body\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/TransactionBody\"\n              },\n              \"is_valid\": {\n                \"type\": \"boolean\"\n              },\n              \"witness_set\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/TransactionWitnessSet\"\n              }\n            },\n            \"required\": [\n              \"body\",\n              \"is_valid\",\n              \"witness_set\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"VRFCert\": {\n            \"title\": \"VRFCert\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"output\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/ByteString\"\n              },\n              \"proof\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/ByteString\",\n                \"type\": \"string\",\n                \"pattern\": \"^[0-9a-f]{160}$\"\n              }\n            },\n            \"required\": [\n              \"output\",\n              \"proof\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"KESVKey\": {\n            \"title\": \"KESVKey\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\",\n            \"maxLength\": 64,\n            \"minLength\": 64\n          },\n          \"BlockHash\": {\n            \"title\": \"BlockHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\",\n            \"maxLength\": 64,\n            \"minLength\": 64\n          },\n          \"VRFVKey\": {\n            \"title\": \"VRFVKey\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\",\n            \"maxLength\": 64,\n            \"minLength\": 64\n          },\n          \"KESSignature\": {\n            \"title\": \"KESSignature\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{896}$\",\n            \"maxLength\": 896,\n            \"minLength\": 896\n          },\n          \"OperationalCert\": {\n            \"title\": \"OperationalCert\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"hot_vkey\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/KESVKey\"\n              },\n              \"kes_period\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              },\n              \"sequence_number\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              },\n              \"sigma\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/Ed25519Signature\"\n              }\n            },\n            \"required\": [\n              \"hot_vkey\",\n              \"kes_period\",\n              \"sequence_number\",\n              \"sigma\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"HeaderBody\": {\n            \"title\": \"HeaderBody\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"block_number\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              },\n              \"slot\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt64\"\n              },\n              \"prev_hash\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/BlockHash\"\n              },\n              \"issuer_vkey\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/Ed25519PublicKey\"\n              },\n              \"vrf_vkey\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/VRFVKey\"\n              },\n              \"vrf_result\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/VRFCert\"\n              },\n              \"block_body_size\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n              },\n              \"block_body_hash\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/BlockHash\"\n              },\n              \"operational_cert\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/OperationalCert\"\n              },\n              \"protocol_version\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/ProtocolVersion\"\n              }\n            },\n            \"unevaluatedProperties\": false,\n            \"required\": [\n              \"block_number\",\n              \"slot\",\n              \"issuer_vkey\",\n              \"vrf_vkey\",\n              \"vrf_result\",\n              \"block_body_size\",\n              \"block_body_hash\",\n              \"operational_cert\",\n              \"protocol_version\"\n            ]\n          },\n          \"Header\": {\n            \"title\": \"Header\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"body_signature\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/KESSignature\"\n              },\n              \"header_body\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/HeaderBody\"\n              }\n            },\n            \"required\": [\n              \"body_signature\",\n              \"header_body\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"Block\": {\n            \"title\": \"Block\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"auxiliary_data_set\": {\n                \"type\": \"object\",\n                \"title\": \"AuxiliaryDataSet\",\n                \"description\": \"A mapping from transaction indices to AuxiliaryData values\",\n                \"patternProperties\": {\n                  \"^(0|[1-9][0-9]*)$\": {\n                    \"$ref\": \"cardano-babbage.json#/definitions/AuxiliaryData\"\n                  }\n                },\n                \"unevaluatedProperties\": false\n              },\n              \"header\": {\n                \"$ref\": \"cardano-babbage.json#/definitions/Header\"\n              },\n              \"invalid_transactions\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"allOf\": [\n                    {\n                      \"title\": \"TransactionIndex\"\n                    },\n                    {\n                      \"$ref\": \"cardano-babbage.json#/definitions/UInt32\"\n                    }\n                  ]\n                }\n              },\n              \"transaction_bodies\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/TransactionBody\"\n                }\n              },\n              \"transaction_witness_sets\": {\n                \"type\": \"array\",\n                \"items\": {\n                  \"$ref\": \"cardano-babbage.json#/definitions/TransactionWitnessSet\"\n                }\n              }\n            },\n            \"unevaluatedProperties\": false,\n            \"required\": [\n              \"auxiliary_data_set\",\n              \"header\",\n              \"invalid_transactions\",\n              \"transaction_bodies\",\n              \"transaction_witness_sets\"\n            ]\n          }\n        }\n      },\n      \"query-layer.json\": {\n        \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n        \"$id\": \"query-layer.json\",\n        \"title\": \"Cardano Query Layer Types\",\n        \"definitions\": {\n          \"UInt16\": {\n            \"title\": \"UInt16\",\n            \"description\": \"16-bit unsigned integer\",\n            \"type\": \"string\",\n            \"pattern\": \"^(0|[1-9][0-9]*)$\",\n            \"format\": \"uint16\"\n          },\n          \"UInt32\": {\n            \"title\": \"UInt32\",\n            \"description\": \"32-bit unsigned integer\",\n            \"type\": \"integer\",\n            \"minimum\": 0,\n            \"maximum\": 4294967295\n          },\n          \"UInt64\": {\n            \"title\": \"UInt64\",\n            \"description\": \"64-bit unsigned integer\",\n            \"type\": \"string\",\n            \"pattern\": \"^(0|[1-9][0-9]*)$\",\n            \"format\": \"uint64\"\n          },\n          \"PosInt64\": {\n            \"title\": \"PosInt64\",\n            \"description\": \"64-bit unsigned integer, zero-excluded. 1-18446744073709551615\",\n            \"type\": \"string\",\n            \"pattern\": \"^([1-9][0-9]*)$\",\n            \"format\": \"posint64\"\n          },\n          \"Int128\": {\n            \"title\": \"Int128\",\n            \"description\": \"128-bit signed integer\",\n            \"type\": \"string\",\n            \"pattern\": \"^-?(0|[1-9][0-9]*)$\",\n            \"format\": \"int128\"\n          },\n          \"DRepId\": {\n            \"title\": \"DRepId\",\n            \"type\": \"string\",\n            \"format\": \"bech32\",\n            \"pattern\": \"^(drep1)[02-9ac-hj-np-z]*$\",\n            \"examples\": [\n              \"drep1ygqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq7vlc9n\"\n            ]\n          },\n          \"CCColdId\": {\n            \"title\": \"CCColdId\",\n            \"type\": \"string\",\n            \"format\": \"bech32\",\n            \"pattern\": \"^(cc_cold1)[02-9ac-hj-np-z]*$\",\n            \"examples\": [\n              \"cc_cold1zvqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq6kflvs\"\n            ]\n          },\n          \"CCHotId\": {\n            \"title\": \"CCHotId\",\n            \"type\": \"string\",\n            \"format\": \"bech32\",\n            \"pattern\": \"^(cc_hot1)[02-9ac-hj-np-z]*$\",\n            \"examples\": [\n              \"cc_hot1qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqvcdjk7\"\n            ]\n          },\n          \"ProposalId\": {\n            \"title\": \"ProposalId\",\n            \"type\": \"string\",\n            \"format\": \"bech32\",\n            \"pattern\": \"^(gov_action1)[02-9ac-hj-np-z]*$\",\n            \"examples\": [\n              \"gov_action1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpzklpgpf\"\n            ]\n          },\n          \"PoolPubKeyHash\": {\n            \"title\": \"PoolPubKeyHash\",\n            \"type\": \"string\",\n            \"format\": \"bech32\",\n            \"pattern\": \"^(pool1)[02-9ac-hj-np-z]*$\",\n            \"examples\": [\n              \"pool12a39rkzfylvn9wfe8j6y8ucq6g2l4mw4azj70y0gd8ejczznyj2\"\n            ]\n          },\n          \"TransactionHash\": {\n            \"title\": \"TransactionHash\",\n            \"type\": \"string\",\n            \"format\": \"hex\",\n            \"pattern\": \"^[0-9a-f]{64}$\",\n            \"maxLength\": 64,\n            \"minLength\": 64,\n            \"examples\": [\n              \"eca40340fa6e65d964915ba4bc8bd811a0493d263ffe95875291114cbb2d0686\",\n              \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n              \"fbc1da46d62a431e69855ad48a6b49b0e2aaafc6fd3dc4a066c6851b7bd31a91\",\n              \"c6726192662abeab149098095eabe004ecbec47f5e564748ab0d394affca47d9\"\n            ]\n          },\n          \"Vote\": {\n            \"title\": \"Vote\",\n            \"type\": \"string\",\n            \"enum\": [\n              \"yes\",\n              \"no\",\n              \"abstain\"\n            ]\n          },\n          \"PlutusV1CostModel\": {\n            \"title\": \"PlutusV1CostModel\",\n            \"type\": \"array\",\n            \"items\": {\n              \"$ref\": \"query-layer.json#/definitions/Int128\"\n            },\n            \"maxItems\": 166,\n            \"minItems\": 166\n          },\n          \"PlutusV2CostModel\": {\n            \"title\": \"PlutusV2CostModel\",\n            \"type\": \"array\",\n            \"items\": {\n              \"$ref\": \"query-layer.json#/definitions/Int128\"\n            },\n            \"maxItems\": 175,\n            \"minItems\": 175\n          },\n          \"PlutusV3CostModel\": {\n            \"title\": \"PlutusV3CostModel\",\n            \"type\": \"array\",\n            \"items\": {\n              \"$ref\": \"query-layer.json#/definitions/Int128\"\n            },\n            \"maxItems\": 251,\n            \"minItems\": 251\n          },\n          \"CostModels\": {\n            \"title\": \"CostModels\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"plutus_v1\": {\n                \"$ref\": \"query-layer.json#/definitions/PlutusV1CostModel\"\n              },\n              \"plutus_v2\": {\n                \"$ref\": \"query-layer.json#/definitions/PlutusV2CostModel\"\n              },\n              \"plutus_v3\": {\n                \"$ref\": \"query-layer.json#/definitions/PlutusV3CostModel\"\n              }\n            },\n            \"required\": [],\n            \"unevaluatedProperties\": false\n          },\n          \"UnitInterval\": {\n            \"title\": \"UnitInterval\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"numerator\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"denominator\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              }\n            },\n            \"required\": [\n              \"numerator\",\n              \"denominator\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"NonnegativeInterval\": {\n            \"title\": \"NonnegativeInterval\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"numerator\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"denominator\": {\n                \"$ref\": \"query-layer.json#/definitions/PosInt64\"\n              }\n            },\n            \"required\": [\n              \"numerator\",\n              \"denominator\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"ExUnitPrices\": {\n            \"title\": \"ExUnitPrices\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"mem_price\": {\n                \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n              },\n              \"step_price\": {\n                \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n              }\n            },\n            \"unevaluatedProperties\": false,\n            \"required\": [\n              \"mem_price\",\n              \"step_price\"\n            ]\n          },\n          \"ExUnits\": {\n            \"title\": \"ExUnits\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"mem\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"steps\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              }\n            },\n            \"required\": [\n              \"mem\",\n              \"steps\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"ProtocolVersion\": {\n            \"title\": \"ProtocolVersion\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"major\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"minor\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              }\n            },\n            \"required\": [\n              \"major\",\n              \"minor\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"PoolVotingThresholds\": {\n            \"title\": \"PoolVotingThresholds\",\n            \"type\": \"array\",\n            \"items\": {\n              \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n            },\n            \"minItems\": 5,\n            \"maxItems\": 5\n          },\n          \"DRepVotingThresholds\": {\n            \"title\": \"DRepVotingThresholds\",\n            \"type\": \"array\",\n            \"items\": {\n              \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n            },\n            \"minItems\": 10,\n            \"maxItems\": 10\n          },\n          \"ProtocolParamUpdate\": {\n            \"title\": \"ProtocolParamUpdate\",\n            \"type\": \"object\",\n            \"properties\": {\n              \"ada_per_utxo_byte\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"collateral_percentage\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"cost_models\": {\n                \"$ref\": \"query-layer.json#/definitions/CostModels\"\n              },\n              \"d\": {\n                \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n              },\n              \"execution_costs\": {\n                \"$ref\": \"query-layer.json#/definitions/ExUnitPrices\"\n              },\n              \"expansion_rate\": {\n                \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n              },\n              \"key_deposit\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"max_block_body_size\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"max_block_ex_units\": {\n                \"$ref\": \"query-layer.json#/definitions/ExUnits\"\n              },\n              \"max_block_header_size\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"max_collateral_inputs\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"max_epoch\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"max_tx_ex_units\": {\n                \"$ref\": \"query-layer.json#/definitions/ExUnits\"\n              },\n              \"max_tx_size\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"max_value_size\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"min_pool_cost\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"minfee_a\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"minfee_b\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"n_opt\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"pool_deposit\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"pool_pledge_influence\": {\n                \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n              },\n              \"protocol_version\": {\n                \"$ref\": \"query-layer.json#/definitions/ProtocolVersion\"\n              },\n              \"treasury_growth_rate\": {\n                \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n              },\n              \"pool_voting_thresholds\": {\n                \"$ref\": \"query-layer.json#/definitions/PoolVotingThresholds\"\n              },\n              \"drep_voting_thresholds\": {\n                \"$ref\": \"query-layer.json#/definitions/DRepVotingThresholds\"\n              },\n              \"committee_min_size\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt16\"\n              },\n              \"committee_max_term_length\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"gov_action_lifetime\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"gov_action_deposit\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"drep_deposit\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"drep_activity\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"min_fee_ref_script_cost_per_byte\": {\n                \"$ref\": \"query-layer.json#/definitions/NonnegativeInterval\"\n              }\n            },\n            \"unevaluatedProperties\": false,\n            \"required\": []\n          },\n          \"ProtocolParams\": {\n            \"title\": \"ProtocolParams\",\n            \"type\": \"object\",\n            \"description\": \"Protocol parameters\",\n            \"allOf\": [\n              {\n                \"$ref\": \"query-layer.json#/definitions/ProtocolParamUpdate\"\n              }\n            ],\n            \"required\": [\n              \"ada_per_utxo_byte\",\n              \"collateral_percentage\",\n              \"cost_models\",\n              \"d\",\n              \"execution_costs\",\n              \"expansion_rate\",\n              \"key_deposit\",\n              \"max_block_body_size\",\n              \"max_block_ex_units\",\n              \"max_block_header_size\",\n              \"max_collateral_inputs\",\n              \"max_epoch\",\n              \"max_tx_ex_units\",\n              \"max_tx_size\",\n              \"max_value_size\",\n              \"min_pool_cost\",\n              \"minfee_a\",\n              \"minfee_b\",\n              \"n_opt\",\n              \"pool_deposit\",\n              \"pool_pledge_influence\",\n              \"protocol_version\",\n              \"treasury_growth_rate\",\n              \"pool_voting_thresholds\",\n              \"drep_voting_thresholds\",\n              \"committee_min_size\",\n              \"committee_max_term_length\",\n              \"gov_action_lifetime\",\n              \"gov_action_deposit\",\n              \"drep_deposit\",\n              \"drep_activity\",\n              \"min_fee_ref_script_cost_per_byte\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"DRepInfo\": {\n            \"type\": \"object\",\n            \"title\": \"DRepInfo\",\n            \"properties\": {\n              \"drep_id\": {\n                \"$ref\": \"query-layer.json#/definitions/DRepId\"\n              },\n              \"amount\": {\n                \"$ref\": \"query-layer.json#/definitions/PosInt64\"\n              },\n              \"active\": {\n                \"type\": \"boolean\"\n              }\n            },\n            \"required\": [\n              \"drep_id\",\n              \"amount\",\n              \"active\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"CCMember\": {\n            \"type\": \"object\",\n            \"title\": \"CCMember\",\n            \"properties\": {\n              \"cc_cold_key\": {\n                \"$ref\": \"query-layer.json#/definitions/CCColdId\"\n              },\n              \"cc_hot_key\": {\n                \"$ref\": \"query-layer.json#/definitions/CCHotId\"\n              },\n              \"status\": {\n                \"type\": \"string\",\n                \"enum\": [\n                  \"authorised\",\n                  \"not_authorised\",\n                  \"resigned\"\n                ]\n              }\n            },\n            \"required\": [\n              \"cc_cold_key\",\n              \"cc_hot_key\",\n              \"status\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"Pool\": {\n            \"type\": \"object\",\n            \"title\": \"Pool\",\n            \"properties\": {\n              \"pool_id\": {\n                \"$ref\": \"query-layer.json#/definitions/PoolPubKeyHash\"\n              },\n              \"status\": {\n                \"type\": \"string\",\n                \"enum\": [\n                  \"active\",\n                  \"retiring\",\n                  \"retired\"\n                ]\n              },\n              \"active_stake\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"live_stake\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              }\n            },\n            \"required\": [\n              \"pool_id\",\n              \"status\",\n              \"active_stake\",\n              \"live_stake\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"Proposal\": {\n            \"type\": \"object\",\n            \"title\": \"Proposal\",\n            \"properties\": {\n              \"proposal_id\": {\n                \"$ref\": \"query-layer.json#/definitions/ProposalId\"\n              },\n              \"ratified_epoch\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"enacted_epoch\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"expired_epoch\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"expiration\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              }\n            },\n            \"required\": [\n              \"proposal_id\"\n            ],\n            \"unevaluatedProperties\": false\n          },\n          \"VoteInfo\": {\n            \"type\": \"object\",\n            \"title\": \"VoteInfo\",\n            \"properties\": {\n              \"proposal_id\": {\n                \"$ref\": \"query-layer.json#/definitions/ProposalId\"\n              },\n              \"vote_tx_hash\": {\n                \"$ref\": \"query-layer.json#/definitions/TransactionHash\"\n              },\n              \"vote\": {\n                \"$ref\": \"query-layer.json#/definitions/Vote\"\n              }\n            },\n            \"required\": [\n              \"proposal_id\",\n              \"vote_tx_hash\",\n              \"vote\"\n            ]\n          },\n          \"EraInfo\": {\n            \"type\": \"object\",\n            \"title\": \"EraInfo\",\n            \"properties\": {\n              \"time\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"slot\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt64\"\n              },\n              \"epoch\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              }\n            },\n            \"required\": [\n              \"time\",\n              \"slot\",\n              \"epoch\"\n            ]\n          },\n          \"EraParameters\": {\n            \"type\": \"object\",\n            \"title\": \"EraParameters\",\n            \"properties\": {\n              \"epoch_length\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"slot_length\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              },\n              \"safe_zone\": {\n                \"$ref\": \"query-layer.json#/definitions/UInt32\"\n              }\n            },\n            \"required\": [\n              \"epoch_length\",\n              \"slot_length\",\n              \"safe_zone\"\n            ]\n          },\n          \"EraSummary\": {\n            \"type\": \"object\",\n            \"title\": \"EraSummary\",\n            \"properties\": {\n              \"start\": {\n                \"$ref\": \"query-layer.json#/definitions/EraInfo\"\n              },\n              \"end\": {\n                \"$ref\": \"query-layer.json#/definitions/EraInfo\"\n              },\n              \"parameters\": {\n                \"$ref\": \"query-layer.json#/definitions/EraParameters\"\n              }\n            },\n            \"required\": [\n              \"start\",\n              \"end\",\n              \"parameters\"\n            ]\n          }\n        }\n      }\n    }\n  }\n}\n"
  },
  {
    "path": "CIP-0139/query-layer.json",
    "content": "{\n  \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n  \"$id\": \"query-layer.json\",\n  \"title\": \"Cardano Query Layer Types\",\n  \"definitions\": {\n    \"UInt16\": {\n      \"title\": \"UInt16\",\n      \"description\": \"16-bit unsigned integer\",\n      \"type\": \"string\",\n      \"pattern\": \"^(0|[1-9][0-9]*)$\",\n      \"format\": \"uint16\"\n    },\n    \"UInt32\": {\n      \"title\": \"UInt32\",\n      \"description\": \"32-bit unsigned integer\",\n      \"type\": \"integer\",\n      \"minimum\": 0,\n      \"maximum\": 4294967295\n    },\n    \"UInt64\": {\n      \"title\": \"UInt64\",\n      \"description\": \"64-bit unsigned integer\",\n      \"type\": \"string\",\n      \"pattern\": \"^(0|[1-9][0-9]*)$\",\n      \"format\": \"uint64\"\n    },\n    \"PosInt64\": {\n      \"title\": \"PosInt64\",\n      \"description\": \"64-bit unsigned integer, zero-excluded. 1-18446744073709551615\",\n      \"type\": \"string\",\n      \"pattern\": \"^([1-9][0-9]*)$\",\n      \"format\": \"posint64\"\n    },\n    \"Int128\": {\n      \"title\": \"Int128\",\n      \"description\": \"128-bit signed integer\",\n      \"type\": \"string\",\n      \"pattern\": \"^-?(0|[1-9][0-9]*)$\",\n      \"format\": \"int128\"\n    },\n    \"DRepId\": {\n      \"title\": \"DRepId\",\n      \"type\": \"string\",\n      \"format\": \"bech32\",\n      \"pattern\": \"^(drep1)[02-9ac-hj-np-z]*$\",\n      \"examples\": [\n        \"drep1ygqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq7vlc9n\"\n      ]\n    },\n    \"CCColdId\": {\n      \"title\": \"CCColdId\",\n      \"type\": \"string\",\n      \"format\": \"bech32\",\n      \"pattern\": \"^(cc_cold1)[02-9ac-hj-np-z]*$\",\n      \"examples\": [\n        \"cc_cold1zvqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq6kflvs\"\n      ]\n    },\n    \"CCHotId\": {\n      \"title\": \"CCHotId\",\n      \"type\": \"string\",\n      \"format\": \"bech32\",\n      \"pattern\": \"^(cc_hot1)[02-9ac-hj-np-z]*$\",\n      \"examples\": [\n        \"cc_hot1qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqvcdjk7\"\n      ]\n    },\n    \"ProposalId\": {\n      \"title\": \"ProposalId\",\n      \"type\": \"string\",\n      \"format\": \"bech32\",\n      \"pattern\": \"^(gov_action1)[02-9ac-hj-np-z]*$\",\n      \"examples\": [\n        \"gov_action1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpzklpgpf\"\n      ]\n    },\n    \"PoolPubKeyHash\": {\n      \"title\": \"PoolPubKeyHash\",\n      \"type\": \"string\",\n      \"format\": \"bech32\",\n      \"pattern\": \"^(pool1)[02-9ac-hj-np-z]*$\",\n      \"examples\": [\n        \"pool12a39rkzfylvn9wfe8j6y8ucq6g2l4mw4azj70y0gd8ejczznyj2\"\n      ]\n    },\n    \"TransactionHash\": {\n      \"title\": \"TransactionHash\",\n      \"type\": \"string\",\n      \"format\": \"hex\",\n      \"pattern\": \"^[0-9a-f]{64}$\",\n      \"maxLength\": 64,\n      \"minLength\": 64,\n      \"examples\": [\n        \"eca40340fa6e65d964915ba4bc8bd811a0493d263ffe95875291114cbb2d0686\",\n        \"7420a723bf4ee4417ec1aa2262ff60921270681e7a9d537132cbcc82917e8006\",\n        \"fbc1da46d62a431e69855ad48a6b49b0e2aaafc6fd3dc4a066c6851b7bd31a91\",\n        \"c6726192662abeab149098095eabe004ecbec47f5e564748ab0d394affca47d9\"\n      ]\n    },\n    \"Vote\": {\n      \"title\": \"Vote\",\n      \"type\": \"string\",\n      \"enum\": [\n        \"yes\",\n        \"no\",\n        \"abstain\"\n      ]\n    },\n    \"PlutusV1CostModel\": {\n      \"title\": \"PlutusV1CostModel\",\n      \"type\": \"array\",\n      \"items\": {\n        \"$ref\": \"query-layer.json#/definitions/Int128\"\n      },\n      \"maxItems\": 166,\n      \"minItems\": 166\n    },\n    \"PlutusV2CostModel\": {\n      \"title\": \"PlutusV2CostModel\",\n      \"type\": \"array\",\n      \"items\": {\n        \"$ref\": \"query-layer.json#/definitions/Int128\"\n      },\n      \"maxItems\": 175,\n      \"minItems\": 175\n    },\n    \"PlutusV3CostModel\": {\n      \"title\": \"PlutusV3CostModel\",\n      \"type\": \"array\",\n      \"items\": {\n        \"$ref\": \"query-layer.json#/definitions/Int128\"\n      },\n      \"maxItems\": 251,\n      \"minItems\": 251\n    },\n    \"CostModels\": {\n      \"title\": \"CostModels\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"plutus_v1\": {\n          \"$ref\": \"query-layer.json#/definitions/PlutusV1CostModel\"\n        },\n        \"plutus_v2\": {\n          \"$ref\": \"query-layer.json#/definitions/PlutusV2CostModel\"\n        },\n        \"plutus_v3\": {\n          \"$ref\": \"query-layer.json#/definitions/PlutusV3CostModel\"\n        }\n      },\n      \"required\": [],\n      \"unevaluatedProperties\": false\n    },\n    \"UnitInterval\": {\n      \"title\": \"UnitInterval\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"numerator\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"denominator\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        }\n      },\n      \"required\": [\"numerator\", \"denominator\"],\n      \"unevaluatedProperties\": false\n    },\n    \"NonnegativeInterval\": {\n      \"title\": \"NonnegativeInterval\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"numerator\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"denominator\": {\n          \"$ref\": \"query-layer.json#/definitions/PosInt64\"\n        }\n      },\n      \"required\": [\"numerator\", \"denominator\"],\n      \"unevaluatedProperties\": false\n    },\n    \"ExUnitPrices\": {\n      \"title\": \"ExUnitPrices\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"mem_price\": {\n          \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n        },\n        \"step_price\": {\n          \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n        }\n      },\n      \"unevaluatedProperties\": false,\n      \"required\": [\n        \"mem_price\",\n        \"step_price\"\n      ]\n    },\n    \"ExUnits\": {\n      \"title\": \"ExUnits\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"mem\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"steps\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        }\n      },\n      \"required\": [\n        \"mem\",\n        \"steps\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"ProtocolVersion\": {\n      \"title\": \"ProtocolVersion\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"major\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"minor\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        }\n      },\n      \"required\": [\n        \"major\",\n        \"minor\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"PoolVotingThresholds\": {\n      \"title\": \"PoolVotingThresholds\",\n      \"type\": \"array\",\n      \"items\": {\n        \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n      },\n      \"minItems\": 5,\n      \"maxItems\": 5\n    },\n    \"DRepVotingThresholds\": {\n      \"title\": \"DRepVotingThresholds\",\n      \"type\": \"array\",\n      \"items\": {\n        \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n      },\n      \"minItems\": 10,\n      \"maxItems\": 10\n    },\n    \"ProtocolParamUpdate\": {\n      \"title\": \"ProtocolParamUpdate\",\n      \"type\": \"object\",\n      \"properties\": {\n        \"ada_per_utxo_byte\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"collateral_percentage\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"cost_models\": {\n          \"$ref\": \"query-layer.json#/definitions/CostModels\"\n        },\n        \"d\": {\n          \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n        },\n        \"execution_costs\": {\n          \"$ref\": \"query-layer.json#/definitions/ExUnitPrices\"\n        },\n        \"expansion_rate\": {\n          \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n        },\n        \"key_deposit\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"max_block_body_size\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"max_block_ex_units\": {\n          \"$ref\": \"query-layer.json#/definitions/ExUnits\"\n        },\n        \"max_block_header_size\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"max_collateral_inputs\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"max_epoch\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"max_tx_ex_units\": {\n          \"$ref\": \"query-layer.json#/definitions/ExUnits\"\n        },\n        \"max_tx_size\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"max_value_size\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"min_pool_cost\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"minfee_a\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"minfee_b\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"n_opt\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"pool_deposit\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"pool_pledge_influence\": {\n          \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n        },\n        \"protocol_version\": {\n          \"$ref\": \"query-layer.json#/definitions/ProtocolVersion\"\n        },\n        \"treasury_growth_rate\": {\n          \"$ref\": \"query-layer.json#/definitions/UnitInterval\"\n        },\n        \"pool_voting_thresholds\": {\n          \"$ref\": \"query-layer.json#/definitions/PoolVotingThresholds\"\n        },\n        \"drep_voting_thresholds\": {\n          \"$ref\": \"query-layer.json#/definitions/DRepVotingThresholds\"\n        },\n        \"committee_min_size\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt16\"\n        },\n        \"committee_max_term_length\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"gov_action_lifetime\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"gov_action_deposit\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"drep_deposit\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"drep_activity\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"min_fee_ref_script_cost_per_byte\": {\n          \"$ref\": \"query-layer.json#/definitions/NonnegativeInterval\"\n        }\n      },\n      \"unevaluatedProperties\": false,\n      \"required\": []\n    },\n    \"ProtocolParams\": {\n      \"title\": \"ProtocolParams\",\n      \"type\": \"object\",\n      \"description\": \"Protocol parameters\",\n      \"allOf\": [{\n        \"$ref\": \"query-layer.json#/definitions/ProtocolParamUpdate\"\n      }],\n      \"required\": [\n        \"ada_per_utxo_byte\",\n        \"collateral_percentage\",\n        \"cost_models\",\n        \"d\",\n        \"execution_costs\",\n        \"expansion_rate\",\n        \"key_deposit\",\n        \"max_block_body_size\",\n        \"max_block_ex_units\",\n        \"max_block_header_size\",\n        \"max_collateral_inputs\",\n        \"max_epoch\",\n        \"max_tx_ex_units\",\n        \"max_tx_size\",\n        \"max_value_size\",\n        \"min_pool_cost\",\n        \"minfee_a\",\n        \"minfee_b\",\n        \"n_opt\",\n        \"pool_deposit\",\n        \"pool_pledge_influence\",\n        \"protocol_version\",\n        \"treasury_growth_rate\",\n        \"pool_voting_thresholds\",\n        \"drep_voting_thresholds\",\n        \"committee_min_size\",\n        \"committee_max_term_length\",\n        \"gov_action_lifetime\",\n        \"gov_action_deposit\",\n        \"drep_deposit\",\n        \"drep_activity\",\n        \"min_fee_ref_script_cost_per_byte\"\n      ],\n      \"unevaluatedProperties\": false\n    },\n    \"DRepInfo\": {\n      \"type\": \"object\",\n      \"title\": \"DRepInfo\",\n      \"properties\": {\n        \"drep_id\": {\n          \"$ref\": \"query-layer.json#/definitions/DRepId\"\n        },\n        \"amount\": {\n          \"$ref\": \"query-layer.json#/definitions/PosInt64\"\n        },\n        \"active\": {\n          \"type\": \"boolean\"\n        }\n      },\n      \"required\": [\"drep_id\", \"amount\", \"active\"],\n      \"unevaluatedProperties\": false\n    },\n    \"CCMember\": {\n      \"type\": \"object\",\n      \"title\": \"CCMember\",\n      \"properties\": {\n        \"cc_cold_key\": {\n          \"$ref\": \"query-layer.json#/definitions/CCColdId\"\n        },\n        \"cc_hot_key\": {\n          \"$ref\": \"query-layer.json#/definitions/CCHotId\"\n        },\n        \"status\": {\n          \"type\": \"string\",\n          \"enum\": [\"authorised\", \"not_authorised\", \"resigned\"]\n        }\n      },\n      \"required\": [\"cc_cold_key\", \"cc_hot_key\", \"status\"],\n      \"unevaluatedProperties\": false\n    },\n    \"Pool\": {\n      \"type\": \"object\",\n      \"title\": \"Pool\",\n      \"properties\": {\n        \"pool_id\": {\n          \"$ref\": \"query-layer.json#/definitions/PoolPubKeyHash\"\n        },\n        \"status\": {\n          \"type\": \"string\",\n          \"enum\": [\"active\", \"retiring\", \"retired\"]\n        },\n        \"active_stake\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"live_stake\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        }\n      },\n      \"required\": [\"pool_id\", \"status\", \"active_stake\", \"live_stake\"],\n      \"unevaluatedProperties\": false\n    },\n    \"Proposal\": {\n      \"type\": \"object\",\n      \"title\": \"Proposal\",\n      \"properties\": {\n        \"proposal_id\": {\n          \"$ref\": \"query-layer.json#/definitions/ProposalId\"\n        },\n        \"ratified_epoch\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"enacted_epoch\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"expired_epoch\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"expiration\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        }\n      },\n      \"required\": [\"proposal_id\"],\n      \"unevaluatedProperties\": false\n    },\n    \"VoteInfo\": {\n      \"type\": \"object\",\n      \"title\": \"VoteInfo\",\n      \"properties\": {\n        \"proposal_id\": {\n          \"$ref\": \"query-layer.json#/definitions/ProposalId\"\n        },\n        \"vote_tx_hash\": {\n          \"$ref\": \"query-layer.json#/definitions/TransactionHash\"\n        },\n        \"vote\": {\n          \"$ref\": \"query-layer.json#/definitions/Vote\"\n        }\n      },\n      \"required\": [\"proposal_id\", \"vote_tx_hash\", \"vote\"]\n    },\n    \"EraInfo\": {\n      \"type\": \"object\",\n      \"title\": \"EraInfo\",\n      \"properties\": {\n        \"time\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"slot\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt64\"\n        },\n        \"epoch\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        }\n      },\n      \"required\": [\"time\", \"slot\", \"epoch\"]\n    },\n    \"EraParameters\": {\n      \"type\": \"object\",\n      \"title\": \"EraParameters\",\n      \"properties\": {\n        \"epoch_length\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"slot_length\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        },\n        \"safe_zone\": {\n          \"$ref\": \"query-layer.json#/definitions/UInt32\"\n        }\n      },\n      \"required\": [\"epoch_length\", \"slot_length\", \"safe_zone\"]\n    },\n    \"EraSummary\": {\n      \"type\": \"object\",\n      \"title\": \"EraSummary\",\n      \"properties\": {\n        \"start\": {\n          \"$ref\": \"query-layer.json#/definitions/EraInfo\"\n        },\n        \"end\": {\n          \"$ref\": \"query-layer.json#/definitions/EraInfo\"\n        },\n        \"parameters\": {\n          \"$ref\": \"query-layer.json#/definitions/EraParameters\"\n        }\n      },\n      \"required\": [\"start\", \"end\", \"parameters\"]\n    }\n  }\n}\n"
  },
  {
    "path": "CIP-0139/ts-api.md",
    "content": "## TS API\n\nIn this document we list the API endpoints as methods of an Typescript object called `api`. Implementations are free to add further namespaces, as long as they implement an object with the following methods:\n\n### Utxos\n\n#### `api.query.utxos.asset(asset_name: AssetName, minting_policy_hash: ScriptHash) : Promise<TransactionUnspentOutput[]>`\n\nGet all UTxOs that contain some of the specified asset\n\n#### `api.query.utxos.transaction_hash(transaction_hash: TransactionHash) : Promise<TransactionUnspentOutput[]>`\n\nGet all UTxOs produced by the transaction\n\n#### `api.query.utxos.address(address: Address) : Promise<TransactionUnspentOutput[]>`\n\nGet all UTxOs present at the address\n\n#### `api.query.utxos.payment_credential(credential: Credential) : Promise<TransactionUnspentOutput[]>`\n\nGet all UTxOs present at the addresses which use the payment credential\n\n#### `api.query.utxos.stake_credential(reward_address: RewardAddress) : Promise<TransactionUnspentOutput[]>`\n\nGet all UTxOs present at the addresses which use the stake credential\n\n### Block\n\n#### `api.query.block.number(u_int64: UInt64) : Promise<Block>`\n\nGet the block with the supplied block number\n\n#### `api.query.block.hash(block_hash: BlockHash) : Promise<Block>`\n\nGet the block with the supplied block hash\n\n### Transaction\n\n#### `api.query.transaction.hash(transaction_hash: TransactionHash) : Promise<Transaction>`\n\nGet the transaction with the supplied transaction hash\n\n#### `api.query.transaction.block_number(u_int64: UInt64) : Promise<Transaction[]>`\n\nGet all transactions contained in the block with the supplied block number []\n\n#### `api.query.transaction.block_hash(block_hash: BlockHash) : Promise<Transaction[]>`\n\nGet all transactions contained in the block with the supplied block hash\n\n### Datum\n\n#### `api.query.datum.hash(data_hash: DataHash) : Promise<PlutusData>`\n\nGet the datum that hashes to the supplied data hash\n\n### Plutus Script\n\n#### `api.query.plutus_script.hash(script_hash: ScriptHash) : Promise<PlutusScript>`\n\nGet the plutus script that hashes to the supplied script hash\n\n### Native Script\n\n#### `api.query.native_script.hash(script_hash: ScriptHash) : Promise<NativeScript>`\n\nGet the native script that hashes to the supplied script hash\n\n### Metadata\n\n#### `api.query.metadata.transaction_hash(transaction_hash: TransactionHash) : Promise<TransactionMetadatum>`\n\nGet the metadata present on the transaction with the supplied transaction hash\n\n### Protocol Parameters\n\n#### `api.query.protocol_parameters.latest() : Promise<ProtocolParams>`\n\nGet the latest protocol parameters\n\n#### `api.query.protocol_parameters.epoch(u_int32: UInt32) : Promise<ProtocolParams>`\n\nGet the protocol parameters at the supplied epoch number\n\n### Votes\n\n#### `api.query.votes.cc_id(cc_hot_id: CCHotId) : Promise<VoteInfo[]>`\n\nVotes cast by the supplied cc credential\n\n#### `api.query.votes.spo_id(pool_pubkeyhash: PoolPubKeyHash) : Promise<VoteInfo[]>`\n\nVotes cast by the supplied stake pool operator\n\n#### `api.query.votes.drep_id(drep_id: DRepId) : Promise<VoteInfo[]>`\n\nVotes cast by the supplied DRep\n\n#### `api.query.votes.proposal_id(proposal_id: ProposalId) : Promise<VoteInfo[]>`\n\nVotes cast on the supplied proposal\n\n### DRep\n\n#### `api.query.drep.all() : Promise<DRepInfo[]>`\n\nGet all the known DReps\n\n#### `api.query.drep.id(drep_id: DRepId) : Promise<DRepInfo>`\n\nGet a specific DRep by id\n\n#### `api.query.drep.stake_credential(reward_address: RewardAddress) : Promise<DRepInfo>`\n\nGet the DRep that the stake credential has delegated to\n\n### Committee\n\n#### `api.query.committee.all() : Promise<CCMember[]>`\n\nGet all known committee members\n\n#### `api.query.committee.id(cc_hot_id: CCHotId) : Promise<CCMember>`\n\nGet a specific Committee member by id\n\n### Pool\n\n#### `api.query.pool.all() : Promise<Pool[]>`\n\nGet all known stake pools\n\n#### `api.query.pool.id(pool_pubkeyhash: PoolPubKeyHash) : Promise<Pool>`\n\nGet a specific stake pool by id\n\n### Proposal\n\n#### `api.query.proposal.all() : Promise<Proposal[]>`\n\nGet all known proposals\n\n#### `api.query.proposal.id(proposal_id: ProposalId) : Promise<Proposal>`\n\nGet a specific proposal by id\n\n### Era\n\n#### `api.query.era.summary() : Promise<EraSummary[]>`\n\nGet the start and end of each era along with parameters that can vary between hard forks\n"
  },
  {
    "path": "CIP-0140/.gitignore",
    "content": "*.agdai\n"
  },
  {
    "path": "CIP-0140/README.md",
    "content": "---\nCIP: 140\nTitle: Ouroboros Peras - Faster Settlement\nCategory: Consensus\nStatus: Proposed\nAuthors:\n  - Arnaud Bailly <arnaud.bailly@iohk.io>\n  - Brian W. Bush <brian.bush@iohk.io>\n  - Sandro Coretti-Drayton <sandro.coretti@iohk.io>\n  - Yves Hauser <yves.hauser@iohk.io>\n  - Hans Lahe <hans.lahe@iohk.io>\nImplementors:\n  - Intersect\nSolution-To:\n  - CPS-0017\n  - CPS-0021\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/872\nCreated: 2024-08-15\nLicense: Apache-2.0\n---\n\n\n## Abstract\n\nWe propose Ouroboros Peras, an enhancement to the Ouroboros Praos protocol that introduces a voting layer for fast settlement. It is adaptively secure, supports dynamic participation, and integrates self healing. Voting provides a “boost” to blocks that receive a quorum of votes, and this dramatically reduces the roll-back probability of the boosted block and its predecessors. Fast settlement occurs in the presence of adversaries with up to one-quarter of the stake, but Praos-like safety is maintained when adversaries control more than that amount of stake. In fact, the protocol enters a “cool-down period” of Praos-like behavior when adversaries prevent voting quorums; that cool-down period is exited only when the chain has healed, achieves chain quality, and reaches a common prefix. For realistic settings of the Peras protocol parameters, blocks can be identified (with overwhelming probability) *ex post facto* as being settled versus rolled-back after as little as two minutes. This enables use cases like partner-chains and bridges where high certainty for the status of a transaction is required in a brief time. The protocol requires the implementation of a vote-diffusion layer, certificates that aggregate votes, and one minor addition to the contents of a block.\n\n<details>\n  <summary><h2>Table of contents</h2></summary>\n\n- [Motivation: why is this CIP necessary](#motivation-why-is-this-cip-necessary)\n- [Specification](#specification)\n    - [Non-normative overview of the Peras protocol](#non-normative-overview-of-the-peras-protocol)\n    - [Normative Peras specification in Agda](#normative-peras-specification-in-agda)\n        - [Protocol parameters](#protocol-parameters)\n        - [Network representation](#network-representation)\n        - [Slots and rounds](#slots-and-rounds)\n        - [Hashing](#hashing)\n        - [Parties](#parties)\n        - [Signatures](#signatures)\n        - [Slot leadership and committee membership](#slot-leadership-and-committee-membership)\n        - [Votes](#votes)\n        - [Certificates](#certificates)\n        - [Block bodies](#block-bodies)\n        - [Blocks](#blocks)\n        - [Chains](#chains)\n        - [Messages and their envelopes](#messages-and-their-envelopes)\n        - [Block trees](#block-trees)\n        - [Parameterization of the semantics](#parameterization-of-the-semantics)\n        - [Block-tree update](#block-tree-update)\n        - [Block selection](#block-selection)\n        - [Rules for voting in a round](#rules-for-voting-in-a-round)\n        - [State](#state)\n        - [Progress](#progress)\n        - [Advancing the clock](#advancing-the-clock)\n        - [Updating the global state](#updating-the-global-state)\n        - [Fetching](#fetching)\n        - [Voting](#voting)\n        - [Block creation](#block-creation)\n        - [Small-step semantics](#small-step-semantics)\n    - [Constraints on Peras parameters](#constraints-on-peras-parameters)\n    - [Specification of votes and certificates](#specification-of-votes-and-certificates)\n    - [CDDL schema for the ledger](#cddl-schema-for-the-ledger)\n- [Rationale: how does this CIP achieve its goals?](#rationale-how-does-this-cip-achieve-its-goals)\n    - [How Peras settles faster](#how-peras-settles-faster)\n    - [Evidence for fast settlement](#evidence-for-fast-settlement)\n    - [Why Peras is practical to implement](#why-peras-is-practical-to-implement)\n    - [Use cases](#use-cases)\n    - [Feasible values for Peras protocol parameters](#feasible-values-for-peras-protocol-parameters)\n    - [Attack and mitigation](#feasible-values-for-peras-protocol-parameters)\n    - [Resource requirements](#resource-requirements)\n        - [Network](#network)\n        - [Cost](#cost)\n        - [Persistent storage](#persistent-storage)\n        - [CPU](#cpu)\n        - [Memory](memory)\n- [Path to active](#path-to-active)\n    - [Acceptance criteria](#acceptance-criteria)\n    - [Implementation plan](#implementation-plan)\n- [Versioning](#versioning)\n- [References](#references)\n- [Appendix](#appendix)\n    - [Typechecking this specification](#typechecking-this-specification)\n- [Copyright](#copyright)\n\n</details>\n\n## Motivation: why is this CIP necessary?\n\nUnder Ouroboros Praos, settlement occurs probabilistically on the Cardano blockchain, where the probability that a block will be rolled back from the preferred chain decreases exponentially as the chain grows beyond the block and where that rate of decrease is slower when adversarial activity is stronger[^1]. Some use cases require high assurance that a block (and the transactions within it) will not be rolled back, necessitating a potentially lengthy wait before a transaction is considered \"settled\" or \"finalize\". Some major centralized exchanges, for example, require fifteen confirmations (i.e., blocks) before a transaction is considered settled[^2]: this amounts to waiting ten minutes before a consumer has their transacted funds or tokens available for subsequent use. This situation is not unique to Cardano: centralized exchanges generally require at least five minutes wait for most of the common blockchains[^2]. Partner chains and bridges may have stringent requirements for fast and highly certain settlement.\n\nThere are several definitions of \"settlement\" or \"finality\", and precision is important when discussing these. Two noteworthy scenarios can be defined precisely.\n\n- *Ex ante* settlement probability: \"What is the probability that a transaction that I just submitted will ever be rolled back?\"\n- *Ex post facto* settlement probability: \"Given that I submitted my transaction $x$ seconds ago and it has not yet been rolled back, what is the probability that it will ever be rolled back?\"\n\nIf one is unwilling or unable to re-submit a rolled-back transaction, then the *ex ante* probability might be of most interest. This matches use cases where there is no opportunities for the parties involved in a transaction to resubmit it: for example, one party might have purchased physical goods and left the vendor's premises, leaving no chance to resubmit a rolled-back transaction. Other use cases are better suited for *ex post facto* settlement: for example, a partner chain, bridge, or decentralized exchange can monitor the ledger for a fixed time and see that the transaction either is not or is rolled back, knowing that there is only a vanishingly small chance of that status ever changing once they have watched the chain for the fixed amount of time, giving them an opportunity to re-submit the transaction if it was rolled back. Both opportunity and back-end infrastructure distinguish these use cases. Protocols like Peras optimize *ex post facto* certainty after predefined waiting times.\n\nOuroboros Praos optimizes the worst-case scenario of highly adversarial conditions, but the Cardano blockchain typically operates in the absence of such a challenge. Optimistic protocols like Peras can take advantage of the \"average case\" of lower or no adversarial activity by settling transactions faster than Praos, but without sacrificing any of the security guarantees of Praos if the protocol (such as Peras) falls back to Praos-like behavior for a \"safety and repair period\" after adversarial conditions occur. Furthermore, protocol modification like Peras should not require radical or costly changes to the current `cardano-node` implementations. It is also desirable that settlement-related protocol changes do not interfere with other pending protocol changes like Genesis (security enhancement)[^3] and Leios (maximal throughput)[^4]. Fast settlement is a critical part of Cardano scaling, as described in [*Scaling blockchain protocols: a research-based approach*](https://www.youtube.com/watch?v=Czmg9WmSCcI).\n\nThis CIP responds to the Cardano Problem Statement [\"Faster Settlement\"](https://github.com/cardano-foundation/CIPs/pull/922).\n\n[^1]: https://eprint.iacr.org/2022/1571.pdf\n\n[^2]: https://support.kraken.com/hc/en-us/articles/203325283-Cryptocurrency-deposit-processing-times\n\n[^3]: https://iohk.io/en/blog/posts/2024/05/08/ouroboros-genesis-design-update/\n\n[^4]: https://iohk.io/en/research/library/papers/high-throughput-blockchain-consensus-under-realistic-network-assumptions/\n\n\n## Specification\n\n\n### Non-normative overview of the Peras protocol\n\nThe following informal, non-normative, pseudo-imperative summary of the Peras protocol is provided as an index into the [formal, normative specification in Agda](#normative-peras-specification-in-agda). Peras relies on a few key concepts:\n\n- The progression of the blockchain's [*slots*](#slots-and-rounds) is partitioned in [*rounds*](#slots-and-rounds) of equal length.\n- In each round a [*committee of voters*](#slot-leadership-and-committee-membership) is selected via a sortition algorithm.\n- Members of the committee may [*vote*](#votes) for a block in the history of their preferred chain.\n- A [*quorum*](#quorum) of votes during the same round for the same block is memorialized as a [*certificate*](#certificates).\n- A quorum of votes for a block gives that block's weight a [*boost*](#boost).\n- The [*weight*](#weight) of a [*chain*](#chains) is its length plus the total of the boosts its blocks have received.\n- The lack of a quorum in a round typically triggers a *cool-down period* where no voting occurs.\n- Relevant vote certificates are typically *recorded* in a [*block*](#blocks) near the start and finish of a cool-down period.\n- Certificates [*expire*](#expiration) after a specified number of slots if they have not been included in a block.\n\nThe protocol keeps track of the following [variables](#block-trees), initialized to the values below:\n\n- $C_\\text{pref} \\gets C_\\text{genesis}$: preferred chain\n- $\\mathcal{C} \\gets \\{C_\\text{genesis}\\}$: set of chains\n- $\\mathcal{V} \\gets \\emptyset$: set of votes\n- $\\mathsf{Certs} \\gets \\{\\mathsf{cert}_\\text{genesis}\\}$: set of certificates\n- $\\mathsf{cert}^\\prime \\gets \\mathsf{cert}_\\text{genesis}$: the latest certificate seen\n- $\\mathsf{cert}^* \\gets \\mathsf{cert}_\\text{genesis}$: the latest certificate on chain\n\nA [*fetching*](#fetching) operation occurs at the beginning of each slot:\n\n- Fetch new chains $\\mathcal{C}\\_\\text{new}$ and votes $\\mathcal{V}\\_\\text{new}$.\n- Add any new chains in $\\mathcal{C}\\_\\text{new}$ to $\\mathcal{C}$, add any new certificates contained in chains in $\\mathcal{C}\\_\\text{new}$ to $\\mathsf{Certs}$.\n- Add $\\mathcal{V}\\_\\text{new}$ to $\\mathcal{V}$ and turn any new quorum in $\\mathcal{V}$ into a certificate $\\mathsf{cert}$ and add $\\mathsf{cert}$ to $\\mathsf{Certs}$.\n    -  Ignore all but the first equivocating vote: i.e., do not add them to $\\mathcal{V}$.\n\n       This requires diffusing certificates in cases where different honest nodes received different equivocating votes.\n- Set $C_\\text{pref}$ to the heaviest (w.r.t. $\\mathsf{Wt}\\_\\mathsf{P}(\\cdot)$ ) valid chain in $\\mathcal{C}$.\n    - Each party $\\mathsf{P}$ assigns a certain weight to every chain $C$, based on $C$'s length and all certificates that vote for blocks in $C$ that $\\mathsf{P}$ has seen so far (and thus stored in a local list $\\mathsf{Certs}$).\n    - Let $\\mathsf{certCount}\\_\\mathsf{P}(C)$ denote the number of such certificates: i.e., $\\mathsf{certCount}\\_\\mathsf{P}(C) := \\left| \\left\\\\{ \\mathsf{cert} \\in \\mathsf{Certs} : \\mathsf{cert} \\text{ votes for a block on } C \\right\\\\} \\right|$.\n    - Then the weight of the chain $C$ in $\\mathsf{P}$'s view is $\\mathsf{Wt}\\_\\mathsf{P}(C) := \\mathsf{len}(C) + B \\cdot \\mathsf{certCount}\\_\\mathsf{P}(C)$ for a protocol parameter $B$.\n- Set $\\mathsf{cert}^\\prime$ to the certificate with the highest round number in $\\mathsf{Certs}$.\n- Set $\\mathsf{cert}^*$ to the certificate with the highest round number present in $C_\\text{pref}$.\n\n[*Block creation*](#block-creation) occurs whenever party $\\mathsf{P}$ is slot leader in a slot $s$, belonging to some round $r$:\n\n- Create a new block $\\mathsf{block} = (s, \\mathsf{P}, h, \\mathsf{cert}, ...)$, where\n    - $h$ is the hash of the last block in $C_\\text{pref}$,\n    - $\\mathsf{cert}$ is set to $\\mathsf{cert}^\\prime$ if\n        - there is no round $(r-2)$ certificate in $\\mathsf{Certs}$, and\n        - $r - \\mathsf{round}(\\mathsf{cert}^\\prime) \\leq A$, and\n        - $\\mathsf{round}(\\mathsf{cert}^\\prime) > \\mathsf{round}(\\mathsf{cert}^*)$,\n        - and to $\\bot$ otherwise,\n- Extend $C_\\text{pref}$ by $\\mathsf{block}$, add the new $C_\\text{pref}$ to $\\mathcal{C}$ and diffuse it.\n\nDuring [*voting*](#voting), each party $\\mathsf{P}$ does the following at the beginning of each voting round $r$:\n\n- Let $\\mathsf{block}$ be the youngest block at least $L$ slots old on $C_\\text{pref}$.\n- If party $\\mathsf{P}$ is (voting) committee member in a round $r$,\n    - either\n        - : $\\mathsf{round}(\\mathsf{cert}^\\prime) = r-1$ and $\\mathsf{cert}^\\prime$ was received before the end of round $r-1$, and\n        - : $\\mathsf{block}$ extends (i.e., has the ancestor or is identical to) the block certified by $\\mathsf{cert}^\\prime$,\n    - or\n        - : $r \\geq \\mathsf{round}(\\mathsf{cert}^\\prime) + R$, and\n        - : $r = \\mathsf{round}(\\mathsf{cert}^*) + c \\cdot K$ for some $c > 0$,\n    - then create a vote $v = (r, \\mathsf{P}, h,...)$,\n    - Add $v$ to $\\mathcal{V}$ and diffuse it.\n\nThe diagram below illustrates the key concepts and entities in Peras. In addition to the rhythm of block production, voting is attempted regularly at the start of each round. Certificates record quorums of votes, but most certificates are not recorded in the blocks. The left side of the diagram shows the tail end of a cool-down period, where voting is not allowed. The chain leaves the cool-down period once voting resumes. The recording of a certificate reference in two blocks memorializes the exit of the cool-down period. Nodes track the tip of their preferred chain, the most recent certificate seen, and the most recent certificate on their preferred chain. Each successful vote boosts the weight of that chain.\n\n![Blockchain diagram illustrating key concepts and entities in Peras.](images/simvis-blocktree.png)\n\n| Icon                                                      | Meaning                                                                                                                                                                                                                                                                               |\n| --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| ![Block](images/block.png)                              | A block created by a node, linked to its predecessor. Contains the block hash (truncated to 8 characters), the creator's id, the creation time, and three icons representing truth value of the three conditions presiding to inclusion of a certificate within a block logic.        |\n| ![Block-certificate](images/block-with-certificate.png) | A block containing a certificate on-chain. Its content is identical to a normal block but color differs to ease spotting when a certificate is included on-chain.                                                                                                                     |\n| ![Certificate](images/certificate.png)                  | A certificate created by a node, linked to the block it certifies. A certificate is only identified by its round number, as by construction there cannot be more than one certificate each round.                                                                                     |\n| ![Vote](images/vote.png)                                | A vote cast by a node, linked to the block it votes for. Contains the round number in which the vote is cast, the voter's id, and the truth values of the four different rules for casting a vote.                                                                                    |\n| ![Cooldown](images/cooldown.png)                        | Record a node's decision to enter cooldown period, linked to the block that triggered it. Contains the round number in which the cooldown is started, the node's id, and the truth values of the conditions that lead to the node not casting a vote and entering cooldown.           |\n| ![Node](images/node.png)                                | A node in the network, identified simply by a number. This is a marker representing the state of a node: What's the tip of its best chain, the latest \"live\" certificate it knows, and the latest on-chain certificate it knows. |\n\nAn [online simulator for Peras](https://peras-simulation.cardano-scaling.org/) is available.\n\n\n### Normative Peras specification in Agda\n\nThe following formal, relational specification for Peras type utilizes [Agda 2.6.4.3](https://github.com/agda/agda/tree/v2.6.4.3). See [the Appendix](#typechecking-this-specification) for instruction on type-checking this specification with the Agda compiler and see [github:input-output-hk/peras-design](https://github.com/input-output-hk/peras-design/) for proofs and other modules related to this specification.\n\n```agda\nmodule README where\n```\n\nMost of the imports come from the [Agda Standard Library 2.0](https://github.com/agda/agda-stdlib/tree/v2.0).\n\n```agda\nopen import Data.Bool using (Bool; if_then_else_; not; _∧_)\nopen import Data.Empty using (⊥)\nopen import Data.Fin using (Fin; pred)\n                     renaming (zero to fzero; suc to fsuc)\nopen import Data.List using (List; any; concat; dropWhile; filter; head; map; mapMaybe; sum; []; _∷_; _++_)\n                      renaming (length to ∣_∣)\nopen import Data.List.Membership.Propositional using (_∈_)\nopen import Data.List.Relation.Unary.All using (All)\nopen import Data.List.Relation.Unary.Any using (Any; any?; _─_)\n                                         renaming (_∷=_ to _∷ˡ=_)\nopen import Data.Maybe using (Maybe; just; nothing)\nopen import Data.Nat using (NonZero; Ordering; suc; ℕ; _≤_; _≥_; _>_; _≤?_; _<ᵇ_; _≤ᵇ_; _+_; _∸_; _*_; _/_; _%_)\nopen import Data.Nat.Properties using (_≟_)\nopen import Data.Product using (proj₁; proj₂; _×_; _,_)\nopen import Data.Sum using (_⊎_)\nopen import Data.Unit using (⊤)\nopen import Function.Base using (_∘_)\nopen import Relation.Binary using (DecidableEquality)\nopen import Relation.Binary.PropositionalEquality using (_≡_; _≢_; cong)\nopen import Relation.Nullary using (Dec; no; yes; ¬_; ⌊_⌋)\nopen import Relation.Nullary.Decidable using (_×-dec_; ¬?)\n```\n\nSeveral additional imports come from the [IOG Agda Prelude v0.1.0.0](https://github.com/input-output-hk/iog-agda-prelude/releases/tag/v0.1.0.0).\n\n```agda\nopen import Prelude.AssocList using (AssocList; set; _⁉_)\nopen import Prelude.DecEq using (DecEq; _==_)\nopen import Prelude.Default using (Default)\nopen import Prelude.InferenceRules\n```\n\n#### Protocol parameters\n\nThe seven *protocol parameters* are natural numbers.\n\n```agda\nrecord Params : Set where\n  field\n```\n\nThe $U$ parameter is the duration of each voting round, measured in slots.\n\n```agda\n        U : ℕ\n```\n\nThe $L$ parameter is the minimum age of a candidate block for being voted upon, measured in slots.\n\n```agda\n        L : ℕ\n```\n\n<span id=\"#expiration\"/>The $A$ parameter is the maximum age for a certificate to be included in a block, measured in rounds.\n\n```agda\n        A : ℕ\n```\n\nThe $R$ parameter is the number of rounds for which to ignore certificates after entering a cool-down period.\n\n```agda\n        R : ℕ\n```\n\nThe $K$ parameter is the minimum number of rounds to wait before voting again after a cool-down period starts.\n\n```agda\n        K : ℕ\n```\n\n<span id=\"#boost\"/>The $B$ parameter is the extra chain weight that a certificate (a quorum of votes) imparts to a block.\n\n```agda\n        B : ℕ\n```\n\n<span id=\"#quorum\"/>The $\\tau$ parameter is the number of votes (the quorum) required to create a certificate.\n\n```agda\n        τ : ℕ\n```\n\nNote that neither the round length nor the cool-down duration may be zero.\n\n```agda\n        ⦃ U-nonZero ⦄ : NonZero U\n        ⦃ K-nonZero ⦄ : NonZero K\n```\n\n#### Network representation\n\nAt the protocol level, the only *network parameter* of interest is the diffusion time $\\Delta$,  which is the upper limit on the number of slots needed to honestly diffuse a message to all nodes.\n\n```agda\nrecord Network : Set₁ where\n  field\n    Δ : ℕ\n```\n\n#### Slots and rounds\n\nAs in Praos, time is measured in *slots*.\n\n```agda\nrecord SlotNumber : Set where\n  constructor MkSlotNumber\n  field getSlotNumber : ℕ\n\n  next : SlotNumber\n  next = record {getSlotNumber = suc getSlotNumber}\n\nopen SlotNumber using (getSlotNumber)\n```\n\nEach Peras voting *round* consists of $U$ consecutive slots.\n\n```agda\nrecord RoundNumber : Set where\n  constructor MkRoundNumber\n  field getRoundNumber : ℕ\n\nopen RoundNumber using (getRoundNumber)\n\nmodule _ ⦃ _ : Params ⦄ where\n  open Params ⦃...⦄\n\n  StartOfRound : SlotNumber → RoundNumber → Set\n  StartOfRound (MkSlotNumber sl) (MkRoundNumber r) = sl ≡ r * U\n\n  rnd : ℕ → ⦃ _ : NonZero U ⦄ → ℕ\n  rnd s = s / U\n\n  v-round : SlotNumber → RoundNumber\n  v-round (MkSlotNumber s) = MkRoundNumber (rnd s)\n```\n\n#### Hashing\n\nThe protocol requires a type for the result of hashing data, an empty value for that type, and an equality test for that type.\n\n```agda\npostulate\n  ByteString : Set\n  emptyBS : ByteString\n  _≟-BS_ : DecidableEquality ByteString\n```\n\nHashes are represented by a byte string, and most of the protocol's primary data types can be hashed.\n\n```agda\nrecord Hash (a : Set) : Set where\n  constructor MkHash\n  field hashBytes : ByteString\n\nrecord Hashable (a : Set) : Set where\n  field hash : a → Hash a\n\nopen Hashable ⦃...⦄\n```\n\n#### Parties\n\nA *party* operates a node and controls its cryptographic keys. Parties are, of course, distinguishable for one another.\n\n```agda\npostulate\n  Party : Set\n  _≟-party_ : DecidableEquality Party\n\ninstance\n  iDecEqParty : DecEq Party\n  iDecEqParty .DecEq._≟_ = _≟-party_\n```\n\n```agda\nParties = List Party\n```\n\n#### Signatures\n\nThe protocol uses standard KES *signatures* (Ed25519) for signing blocks or votes.\n\n```agda\npostulate\n  Signature : Set\n```\n\n#### Slot leadership and committee membership\n\nA *leadership proof* attests a party's slot leadership exactly as it does in Praos. The function `IsSlotLeader` verifies a party's leadership for a particular slot and the function `IsBlockSignature` verifies the validity of a block's signature.\n\n```agda\nrecord Block : Set  -- Blocks will be defined later in this specification.\n\npostulate\n  LeadershipProof : Set\n  IsSlotLeader : Party → SlotNumber → LeadershipProof → Set\n  IsBlockSignature : Block → Signature → Set\n```\n\nThe voting scheme used by Peras is specified in the proposed CIP [*Votes & Certificates on Cardano*](https://github.com/cardano-foundation/CIPs/pull/870). It involves a *proof of membership* in a round's voting committee. The function `IsCommitteeMember` verifies a party's membership in a round's voting committee and the weight of their vote. The function `IsVoteSignature` verifies that validity of a vote's signature.\n\n```agda\nrecord Vote : Set  -- Votes will be defined later in this specification.\n\nrecord VotingWeight : Set where\n  field votes : ℕ\n\npostulate\n  MembershipProof : Set\n  IsCommitteeMember : Party → RoundNumber → VotingWeight → MembershipProof → Set\n  IsVoteSignature : Vote → Signature → Set\n```\n\n#### Votes\n\n*Votes* have a creator, a weight, a proof of the creator's membership in the round's voting committee, and a reference to the block being voted for.\n\n```agda\nrecord Vote where\n  constructor MkVote\n  field votingRound : RoundNumber\n        creatorId   : Party\n        weight      : VotingWeight\n        proofM      : MembershipProof\n        blockHash   : Hash Block\n        signature   : Signature\n\n  votingWeight : ℕ\n  votingWeight = VotingWeight.votes weight\n\n  votingRound' : ℕ\n  votingRound' = getRoundNumber votingRound\n```\n\nVotes are valid if the party and weight are correct for the round and if the vote is properly signed.\n\n```agda\nValidVote : Vote → Set\nValidVote v =\n  IsCommitteeMember\n    (Vote.creatorId v)\n    (Vote.votingRound v)\n    (Vote.weight v)\n    (Vote.proofM v)\n  × IsVoteSignature v (Vote.signature v)\n```\n\n*Equivocated votes* are ones that duplicate votes by the same party in the same round. The protocol will reject such equivocated votes.\n\n```agda\ndata _∻_ : Vote → Vote → Set where\n  Equivocation : ∀ {v₁ v₂}\n    → Vote.creatorId v₁ ≡ Vote.creatorId v₂\n    → Vote.votingRound v₁ ≡ Vote.votingRound v₂\n    → v₁ ≢ v₂\n    → v₁ ∻ v₂\n```\n\n#### Certificates\n\nA *certificate* attests that a quorum of votes for the same block were cast during a round.\n\n```agda\nrecord Certificate : Set where\n  constructor MkCertificate\n  field round : RoundNumber\n        blockRef : Hash Block\n\n  roundNumber : ℕ\n  roundNumber = getRoundNumber round\n\npostulate\n  _≟-certificate_ : DecidableEquality Certificate\n```\n\nThe protocol places special emphasis on the most recent certificate among a set of certificates.\n\n```agda\nlatestCert : Certificate → List Certificate → Certificate\nlatestCert c = maximumBy c Certificate.roundNumber\n  where maximumBy : {a : Set} → a → (a → ℕ) → List a → a\n        maximumBy candidate _ [] = candidate\n        maximumBy candidate f (x ∷ xs) =\n          if f candidate ≤ᵇ f x\n            then maximumBy x f xs\n            else maximumBy candidate f xs\n```\n\n#### Block bodies\n\n*Block bodies* are identical to those in Praos. They consist of a payload of transactions and are identified by their unique hash. The detailed contents are irrelevant for Peras, so we represent them in a slightly simplified manner.\n\n```agda\npostulate\n  Tx : Set\n  hashTxs : List Tx → Hash (List Tx)\n\nPayload = List Tx\n\ninstance\n  iHashablePayload : Hashable Payload\n  iHashablePayload .hash = hashTxs\n\nrecord BlockBody : Set where\n  constructor MkBlockBody\n  field blockHash : Hash Payload\n        payload : Payload\n```\n\n#### Blocks\n\n*Blocks* are identical to those in Praos, except for the rare inclusion of a certificate, which may happen near the beginning or ending of a cool-down period. The other detailed contents are irrelevant for Peras, so we represent them in a slightly simplified manner.\n\n```agda\nrecord Block where\n  constructor MkBlock\n  field slotNumber : SlotNumber\n        creatorId : Party\n        parentBlock : Hash Block\n        certificate : Maybe Certificate  -- NB: New in Peras and not present in Praos.\n        leadershipProof : LeadershipProof\n        signature : Signature\n        bodyHash : Hash Payload\n\n  slotNumber' : ℕ\n  slotNumber' = getSlotNumber slotNumber\n\npostulate\n  hashBlock : Block → Hash Block\n\ninstance\n  iHashableBlock : Hashable Block\n  iHashableBlock .hash = hashBlock\n\n_≟-BlockHash_ : DecidableEquality (Hash Block)\n(MkHash b₁) ≟-BlockHash (MkHash b₂) with b₁ ≟-BS b₂\n... | yes p = yes (cong MkHash p)\n... | no ¬p =  no (¬p ∘ cong Hash.hashBytes)\n\ngenesisHash : Hash Block\ngenesisHash = MkHash emptyBS\n\ncert₀ : Certificate\ncert₀ = MkCertificate (MkRoundNumber 0) genesisHash\n```\n#### Chains\n\nThe linking of blocks into a *chain* is identical to Praos.\n\n```agda\nChain = List Block\n```\n\nThe genesis chain is the empty list.\n```agda\ngenesis : Chain\ngenesis = []\n```\n\nThe protocol scrutinizes any certificates recorded on the chain.\n```agda\ncertsFromChain : Chain → List Certificate\ncertsFromChain = mapMaybe Block.certificate\n```\n\nIt also needs to test whether a certificate (quorum of votes) refers to a block found on a particular chain.\n\n```agda\n_PointsInto_ : Certificate → Chain → Set\n_PointsInto_ c = Any ((Certificate.blockRef c ≡_) ∘ hash)\n\n_PointsInto?_ : ∀ (c : Certificate) → (ch : Chain) → Dec (c PointsInto ch)\n_PointsInto?_ c = any? ((Certificate.blockRef c ≟-BlockHash_) ∘ hash)\n```\n\nPeras differs from Praos in that the <span id=\"#weight\"/>weight of a chain is its length plus the boost parameter $B$ times the number of vote quorums (certificates) its blocks have received.\n\n```agda\nmodule _ ⦃ _ : Params ⦄ where\n  open Params ⦃...⦄\n\n  ∥_∥_ : Chain → List Certificate → ℕ\n  ∥ ch ∥ cts = ∣ ch ∣ + ∣ filter (_PointsInto? ch) cts ∣ * B\n```\n\nThe protocol can identify a chain by the hash of its most recent block (its tip).\n\n```agda\ntipHash : Chain → Hash Block\ntipHash [] = genesisHash\ntipHash (b ∷ _) = hash b\n```\n\nA chain is valid if its blocks are signed and their creators were slot leaders. The chain's genesis is always valid.\n\n```agda\ndata ValidChain : Chain → Set where\n  Genesis : ValidChain genesis\n  Cons : ∀ {c : Chain} {b : Block}\n    → IsBlockSignature b (Block.signature b)\n    → IsSlotLeader (Block.creatorId b) (Block.slotNumber b) (Block.leadershipProof b)\n    → Block.parentBlock b ≡ tipHash c\n    → ValidChain c\n    → ValidChain (b ∷ c)\n```\n\nA block is said to extend a certificate on a chain if the certified block is an ancestor of or identical to the block and on the chain.\n\n```agda\nChainExtends : Hash Block → Certificate → Chain → Set\nChainExtends h c =\n  Any (λ block → (hash block ≡ Certificate.blockRef c))\n    ∘ dropWhile (λ block' → ¬? (hash block' ≟-BlockHash h))\n\nExtends : Hash Block → Certificate → List Chain → Set\nExtends h c\n  with c ≟-certificate cert₀\nExtends h c | yes _ = λ _ → ⊤\nExtends h c | no _ = Any (ChainExtends h c)\n```\n\n#### Messages and their envelopes\n\nIn addition to the chain *messages* already diffused among nodes in Praos, the Peras protocol also diffuses votes between nodes. (Note that Peras implementations might choose also to diffuse certificates in lieu of sets of votes that meet the quorum condition.)\n\n```agda\ndata Message : Set where\n  ChainMsg : {c : Chain} → ValidChain c → Message\n  VoteMsg : {v : Vote} → ValidVote v → Message\n```\n\nDiffusion of votes or blocks over the network may involve delays of a slot or more.\n\n```agda\nmodule _ ⦃ _ : Params ⦄ ⦃ _ : Network ⦄ where\n  open Params ⦃...⦄\n  open Network ⦃...⦄\n\n  Delay = Fin (suc (suc Δ))\n  pattern 𝟘 = fzero\n  pattern 𝟙 = fsuc fzero\n```\n\nMessages are put into an *envelope* and assigned to a party. Such messages can be delayed.\n\n```agda\n  record Envelope : Set where\n    constructor ⦅_,_,_⦆\n    field\n      partyId : Party\n      message : Message\n      delay : Delay\n```\n\n#### Block trees\n\n*Block trees* are defined by functions and properties: any implementation of the block tree has to possess the required functions.\n\n```agda\nmodule _ ⦃ _ : Params ⦄ where\n  open Params ⦃...⦄\n\n  record IsTreeType {T : Set}\n                    (tree₀ : T)\n                    (addChain : T → {c : Chain} → ValidChain c → T)\n                    (allChains : T → List Chain)\n                    (preferredChain : T → Chain)\n                    (addVote : T → {v : Vote} → ValidVote v → T)\n                    (votes : T → List Vote)\n                    (certs : T → List Certificate)\n                    (cert₀ : Certificate)\n         : Set₁ where\n\n    field\n```\n\nIt must also conform to properties that must hold with respect to chains, certificates and votes. First, the genesis tree must prefer the genesis chain, have an empty set of certificates, and have an empty set of votes.\n\n```agda\n      instantiated :\n        preferredChain tree₀ ≡ genesis\n\n      instantiated-certs :\n        certs tree₀ ≡ cert₀ ∷ []\n\n      instantiated-votes :\n        votes tree₀ ≡ []\n```\n\nThe certificates in a chain newly incorporated into the block tree must equate to the certificates on the chain itself and the block tree's record of certificates.\n\n```agda\n      extendable-chain : ∀ (t : T) {c : Chain} (vc : ValidChain c)\n        → certs (addChain t vc) ≡ certsFromChain c ++ certs t\n```\n\nA valid block tree must have a valid preferred chain.\n\n```agda\n      valid : ∀ (t : T)\n        → ValidChain (preferredChain t)\n```\n\nThe preferred chain must be at least as weighty as any other chain present in the block tree.\n\n```agda\n      optimal : ∀ (c : Chain) (t : T)\n        → let b = preferredChain t\n              cts = certs t\n          in ValidChain c\n        → c ∈ allChains t\n        → ∥ c ∥ cts ≤ ∥ b ∥ cts\n```\n\nThe preferred chain must be present in the list of all chains seen.\n\n```agda\n      self-contained : ∀ (t : T)\n        → preferredChain t ∈ allChains t\n```\n\nDuplicate or equivocated votes must not be present in the block tree.\n\n```agda\n      unique-votes : ∀ (t : T) {v : Vote} (vv : ValidVote v)\n        → let vs = votes t\n          in v ∈ vs\n        → vs ≡ votes (addVote t vv)\n\n      no-equivocations : ∀ (t : T) {v : Vote} (vv : ValidVote v)\n        → let vs = votes t\n          in Any (v ∻_) vs\n        → vs ≡ votes (addVote t vv)\n```\n\nEvery certificate must represent a quorum of recorded votes.\n\n```agda\n      quorum-cert : ∀ (t : T) (b : Block) (r : ℕ)\n        →  (sum ∘ map Vote.votingWeight) (filter (λ {v →\n                     (getRoundNumber (Vote.votingRound v) ≟ r)\n               ×-dec (Vote.blockHash v ≟-BlockHash hash b)}\n             ) (votes t)) ≥ τ\n        → Any (λ {c →\n            (getRoundNumber (Certificate.round c) ≡ r)\n          × (Certificate.blockRef c ≡ hash b) }) (certs t)\n```\n\nThe concrete block tree type (`TreeType`) manages chains, certificates, and votes.\n\n```agda\n  record TreeType (T : Set) : Set₁ where\n\n    field\n      tree₀ : T\n      addChain : T → {c : Chain} → ValidChain c → T\n      allChains : T → List Chain\n      preferredChain : T → Chain\n      addVote : T → {v : Vote} → ValidVote v → T\n      votes : T → List Vote\n      certs : T → List Certificate\n```\n\nIt conforms to the `IsTreeType` requirements.\n\n```agda\n      is-TreeType : IsTreeType\n                      tree₀ addChain allChains preferredChain\n                      addVote votes certs cert₀\n```\n\nSeveral convenience functions are provided for extracting information about certificates and votes.\n\n```agda\n    latestCertOnChain : T → Certificate\n    latestCertOnChain = latestCert cert₀ ∘ mapMaybe Block.certificate ∘ preferredChain\n\n    latestCertSeen : T → Certificate\n    latestCertSeen = latestCert cert₀ ∘ certs\n\n    hasVote : RoundNumber → T → Set\n    hasVote (MkRoundNumber r) = Any ((r ≡_) ∘ Vote.votingRound') ∘ votes\n```\n\n#### Parameterization of the semantics\n\nIn order to define the semantics the following parameters are required.\n\n- The type of the block-tree\n- A function that mimics the node's memory pool by selecting the transactions available to a particular party in a particular slot\n- A list of the parties participating in the protocol\n\n```agda\nmodule Semantics\n           ⦃ _ : Params ⦄\n           ⦃ _ : Network ⦄\n           {T : Set} {blockTree : TreeType T}\n           {txSelection : SlotNumber → Party → List Tx}\n           {parties : Parties}\n           where\n    open Params ⦃...⦄\n    open TreeType blockTree\n```\n\nThe protocol starts from the genesis block tree.\n\n```agda\n    instance\n      Default-T : Default T\n      Default-T .Default.def = tree₀\n```\n\n#### Block-tree update\n\nUpdating the block tree involves recording the votes and chains received via messages.\n\n```agda\n    data _[_]→_ : T → Message → T → Set where\n\n      VoteReceived : ∀ {v vv t} →\n        ──────────────────────────────────\n        t [ VoteMsg {v} vv ]→ addVote t vv\n\n      ChainReceived : ∀ {c vc t} →\n        ────────────────────────────────────\n        t [ ChainMsg {c} vc ]→ addChain t vc\n```\n\n#### Block selection\n\nThe block selected for voting is the most recent one on the preferred chain that is at least $L$ slots old.\n\n```agda\n    BlockSelection : SlotNumber → T → Hash Block\n    BlockSelection (MkSlotNumber s) = tipHash ∘ filter (λ {b → (Block.slotNumber' b) + L ≤? s}) ∘ preferredChain\n```\n\n#### Rules for voting in a round\n\nVoting is allowed in a round if voting has proceeded regularly in preceding rounds or if a sufficient number of slots have lapsed since the protocol entered a cool-down period. Specifically, either of two pairs of conditions must be met.\n\n- `VR-1A`: The vote has seen the certificate for the previous round.\n\n```agda\n    VotingRule-1A : RoundNumber → T → Set\n    VotingRule-1A (MkRoundNumber r) t = r ≡ Certificate.roundNumber (latestCertSeen t) + 1\n```\n\n- `VR-1B`: The block being voted upon extends the most recently certified block\n\n```agda\n    VotingRule-1B : SlotNumber → T → Set\n    VotingRule-1B s t =\n      Extends (BlockSelection s t) (latestCertSeen t) (allChains t)\n```\n\n- `VR-1`: Both `VR-1A` and `VR-1B` hold, which is the situation typically occurring when the voting has regularly occurred in preceding rounds.\n\n```agda\n    VotingRule-1 : SlotNumber → T → Set\n    VotingRule-1 s t =\n        VotingRule-1A (v-round s) t\n      × VotingRule-1B s t\n```\n\n- `VR-2A`: The last certificate a party has seen is from a round at least $R$ rounds previously. This enforces the chain-healing period that must occur before leaving a cool-down period.\n\n```agda\n    VotingRule-2A : RoundNumber → T → Set\n    VotingRule-2A (MkRoundNumber r) t =\n      r ≥ Certificate.roundNumber (latestCertSeen t) + R\n```\n\n- `VR-2B`: The last certificate included in a party's current chain is from a round exactly $c \\cdot K$ rounds ago for some $c \\in ℕ$ with $c ≥ 0$. This enforces chain quality and common prefix before leaving a cool-down period.\n\n```agda\n    VotingRule-2B : RoundNumber → T → Set\n    VotingRule-2B (MkRoundNumber r) t =\n        r > Certificate.roundNumber (latestCertOnChain t)\n      × r mod K ≡ (Certificate.roundNumber (latestCertOnChain t)) mod K\n      where\n        _mod_ : ℕ → (n : ℕ) → ⦃ NonZero n ⦄ → ℕ\n        _mod_ a b ⦃ prf ⦄ = _%_ a b ⦃ prf ⦄\n```\n\n- `VR-2`: Both `VR-2A` and `VR-2B` hold, which is the situation typically occurring when the chain is about to exit a cool-down period.\n\n```agda\n    VotingRule-2 : RoundNumber → T → Set\n    VotingRule-2 r t =\n        VotingRule-2A r t\n      × VotingRule-2B r t\n```\n\nIf either `VR-1A` and `VR-1B` hold, or `VR-2A` and `VR-2B` hold, then voting is allowed.\n\n```agda\n    VotingRule : SlotNumber → T → Set\n    VotingRule s t =\n        VotingRule-1 s t\n      ⊎ VotingRule-2 (v-round s) t\n```\n\n#### State\n\nThe small-step semantics rely on a global state, which consists of several pieces of information.\n\n- Current slot of the system\n- Map with local state per party\n- All the messages that have been sent but not yet been delivered\n- All the messages that have been sent\n\n```agda\n    record State : Set where\n      constructor ⟦_,_,_,_,_⟧\n      field\n        clock : SlotNumber\n        blockTrees : AssocList Party T\n        messages : List Envelope\n        history : List Message\n```\n\n#### Progress\n\nRather than keeping track of progress, we introduce a predicate stating that all messages that are not delayed have been delivered. This is a precondition that must hold before transitioning to the next slot.\n\n```agda\n    Fetched : State → Set\n    Fetched = All (λ { z → Envelope.delay z ≢ 𝟘 }) ∘ messages\n      where open State\n```\n\n#### Advancing the clock\n\nTicking the global clock increments the slot number and decrements the delay of all the messages in the message buffer.\n\n```agda\n    tick : State → State\n    tick M =\n      record M\n        { clock = SlotNumber.next clock\n        ; messages =\n            map (λ where e → record e { delay = pred (Envelope.delay e) })\n              messages\n        }\n      where open State M\n```\n\n#### Updating the global state\n\nNew messages are buffered, recorded in the global history, and will update a party's portion of the global state.`\n```agda\n    _,_⇑_ : Message → (Party → Delay) → State → State\n    m , fᵈ ⇑ M =\n      record M\n        { messages =\n            map (λ { p → ⦅ p , m , fᵈ p ⦆}) parties\n            ++ messages\n        ; history = m ∷ history\n        }\n      where open State M\n```\nThis occurs when a message diffuses to new parties.\n```agda\n    delay_by_update_ : Message → (Party → Delay) → State → State\n    delay m@(ChainMsg x) by fᵈ update M = m , fᵈ ⇑ M\n    delay m@(VoteMsg x) by fᵈ update M = m , fᵈ ⇑ M\n```\n\n#### Fetching\n\nA party receives messages from the global state by fetching messages assigned to the party, updating the local block tree, and putting the local state back into the global state.\n\n```agda\n    data _⊢_[_]⇀_ : Party → State → Message → State → Set\n      where\n```\n\nAn honest party consumes a message from the global message buffer and updates their local state.\n\n```agda\n      honest : ∀ {p} {t t′} {m} {N}\n        → let open State N\n          in\n          (m∈ms : ⦅ p , m , 𝟘 ⦆ ∈ messages) →\n        ∙ blockTrees ⁉ p ≡ just t\n        ∙ t [ m ]→ t′\n          ─────────────────────────────────────\n          p ⊢\n          N [ m ]⇀ record N\n            { blockTrees = set p t′ blockTrees\n            ; messages = messages ─ m∈ms\n            }\n```\n\n#### Voting\n\nVotes are created with the required information about committee membership and the block being voted for.\n\n```agda\n    createVote : SlotNumber → Party → VotingWeight → MembershipProof → Signature → Hash Block → Vote\n    createVote s p w prf sig hb =\n      record\n        { votingRound = v-round s\n        ; creatorId = p\n        ; weight = w\n        ; proofM = prf\n        ; blockHash = hb\n        ; signature = sig\n        }\n```\n\nA party can consider voting for a block, if\n\n- the current slot is the first slot in a voting round\n- the party is a member of the voting committee\n- the chain is not in a cool-down phase\n\nVoting updates the party's local state and for all other parties a message is ready to be consumed immediately.\n\n```agda\n    infix 2 _⊢_⇉_\n    data _⊢_⇉_ : Party → State → State → Set where\n\n      honest : ∀ {p} {t} {M} {w} {π} {σ} {b}\n        → let\n            open State\n            s = clock M\n            r = v-round s\n            v = createVote s p w π σ b\n          in\n          (fᵈ : Party → Delay)\n          (mem : IsCommitteeMember p r w π)\n          (sig : IsVoteSignature v σ) →\n        ∙ BlockSelection s t ≡ b\n        ∙ blockTrees M ⁉ p ≡ just t\n        ∙ StartOfRound s r\n        ∙ VotingRule s t\n          ────────────────────────────────────────────\n          p ⊢\n            M ⇉ delay VoteMsg (mem , sig) by fᵈ\n                 update M\n```\n\n#### Block creation\n\nCertificates are conditionally added to a block, typically near the beginning or ending of a cool-down period. Such recording occurs if . . .\n\n1. There is no certificate seen (recorded) from two rounds ago,\n2. The last seen certificate is not expired, and\n3. The last seen certificate is from a later round than the last certificate on chain.\n\n```agda\n    needCert : RoundNumber → T → Maybe Certificate\n    needCert (MkRoundNumber r) t =\n      let\n        cert⋆ = latestCertOnChain t\n        cert′ = latestCertSeen t\n      in\n        if not (any (λ {c → ⌊ Certificate.roundNumber c + 2 ≟ r ⌋}) (certs t))  -- (1)\n           ∧ (r ≤ᵇ A + Certificate.roundNumber cert′)                           -- (2)\n           ∧ (Certificate.roundNumber cert⋆ <ᵇ Certificate.roundNumber cert′)   -- (3)\n        then just cert′\n        else nothing\n```\n\nBlocks are created with the required information.\n\n```agda\n    createBlock : SlotNumber → Party → LeadershipProof → Signature → T → Block\n    createBlock s p π σ t =\n      record\n        { slotNumber = s\n        ; creatorId = p\n        ; parentBlock = tipHash (preferredChain t)\n        ; certificate = needCert (v-round s) t\n        ; leadershipProof = π\n        ; bodyHash = hash (txSelection s p)\n        ; signature = σ\n        }\n```\n\nA party can create a new block by adding it to the local block tree and diffuse the block creation messages to the other parties. Block creation is possible, if as in Praos, . . .\n\n- the block signature is correct, and\n- the party is the slot leader.\n\nBlock creation updates the party's local state, but for all other parties a message is added to the message buffer\n\n```agda\n    infix 2 _⊢_↷_\n    data _⊢_↷_ : Party → State → State → Set where\n\n      honest : ∀ {p} {t} {M} {π} {σ} →\n        let open State M\n            b = createBlock clock p π σ t\n            pref = preferredChain t\n          in\n          (fᵈ : Party → Delay)\n          (vc : ValidChain (b ∷ pref)) →\n        ∙ blockTrees ⁉ p ≡ just t\n          ──────────────────────────────\n          p ⊢\n            M ↷ delay ChainMsg vc by fᵈ\n                update M\n```\n\n#### Small-step semantics\n\nThe small-step semantics describe the evolution of the global state.\n\n```agda\n    variable\n      M N O : State\n      p : Party\n```\n\nThe relation allows\n\n- Fetching messages at the beginning of each slot\n- Block creation\n- Voting\n- Transitioning to next slot in the same voting round\n- Transitioning to next slot in a new voting round\n\nNote that when transitioning to the next slot we need to distinguish whether the next slot is in the same or a new voting round. This is necessary in order to detect adversarial behavior with respect to voting (adversarially not voting in a voting round).\n\n```agda\n    data _↝_ : State → State → Set where\n\n      Fetch : ∀ {m} →\n        ∙ p ⊢ M [ m ]⇀ N\n          ──────────────\n          M ↝ N\n\n      CreateVote :\n        ∙ Fetched M\n        ∙ p ⊢ M ⇉ N\n          ─────────\n          M ↝ N\n\n      CreateBlock :\n        ∙ Fetched M\n        ∙ p ⊢ M ↷ N\n          ─────────\n          M ↝ N\n\n      NextSlot :\n        ∙ Fetched M\n          ─────────────────────\n          M ↝ tick M\n```\n\nThis completes for formal specification of Peras. The repository [github:input-output-hk/peras-design](https://github.com/input-output-hk/peras-design/tree/main) leverages this specification by providing the following Agda code.\n\n- Proofs of properties of the Peras protocol.\n- An executable specification (since the above specification is *relational* and not *executable*)\n- Proofs of the soundness of the executable specification with respect to this relational one\n- Scaffolding for generating dynamic, property-based conformance tests using the Haskell [`quickcheck-dynamic`](https://hackage.haskell.org/package/quickcheck-dynamic) package.\n\n\n### Constraints on Peras parameters\n\nThe structure of the Peras protocol imposes the following constraints on its [parameters](#protocol-parameters). These arise from both theoretical and practical considerations.\n\n| Parameter               | Symbol          | Units   | Description                                                                               | Constraints                                                      | Rationale                                                                                 |\n|-------------------------|-----------------|---------|-------------------------------------------------------------------------------------------|------------------------------------------------------------------|-------------------------------------------------------------------------------------------|\n| Round length            | $U$             | slots   | The duration of each voting round.                                                        | $U \\geq \\Delta$                                                  | All of a round's votes must be received before the end of the round.                      |\n| Block selection offset  | $L$             | slots   | The minimum age of a candidate block for being voted upon.                                | $\\Delta < L                                                      | Blocks must propagate before they are voted upon.                                         |\n| Certificate expiration  | $A$             | rounds  | The maximum age for a certificate to be included in a block.                              | $A = \\left\\lceil\\frac{T_\\text{heal}+T_\\text{CQ}}{U}\\right\\rceil$ | After a quorum failure, the chain must heal and achieve quality.                          |\n| Chain ignorance period  | $R$             | rounds  | The number of rounds for which to ignore certificates after entering a cool-down period.  | $R = A$                                                          | Ensure chain-ignorance period lasts long enough to include a certificate on the chain.    |\n| Cool-down period        | $K$             | rounds  | The minimum number of rounds to wait before voting again after a cool-down period starts. | $K = \\left\\lceil \\frac{A + T_\\text{CP}}{U} \\right\\rceil$         | After a quorum failure, the chain must heal, achieve quality, and attain a common prefix. |\n| Certification boost     | $B$             | blocks  | The extra chain weight that a certificate gives to a block.                               | $B > 0$                                                          | Peras requires that some blocks be boosted.                                               |\n| Quorum size             | $\\tau$          | parties | The number of votes required to create a certificate.                                     | $\\tau > 3 n / 4$                                                 | Guard against a minority (< 50%) of adversarial voters.                                   |\n| Committee size          | $n$             | parties | The number of members on the voting committee.                                            | $n > 0$                                                          | Peras requires a voting committee.                                                        |\n| Network diffusion time  | $\\Delta$        | slots   | Upper limit on the time needed to diffuse a message to all nodes.                         | $\\Delta > 0$                                                     | Messages have a finite delay.                                                             |\n| Active slot coefficient | $f$             | 1/slots | The probability that a party will be the slot leader for a particular slot.               | $0 < f \\leq 1$                                                   | Blocks must be produced.                                                                  |\n| Healing time            | $T_\\text{heal}$ | slots   | Healing period to mitigate a strong (25-50%) adversary.                                   | $T_\\text{heal} = \\mathcal{O}\\left( B / f \\right)$                | Sufficient blocks must be produced to overcome an adversarially boosted block.            |\n| Chain-quality time      | $T_\\text{CQ}$   | slots   | Ensure the presence of at least one honest block on the chain.                            | $T_\\text{CQ} = \\mathcal{O} (k/f)$                                | A least one honest block must be produced.                                                |\n| Common-prefix time      | $T_\\text{CP}$   | slots   | Achieve settlement.                                                                       | $T_\\text{CP} = \\mathcal{O} (k/f)$                                | The Ouroboros Praos security parameter defines the time for having a common prefix.       |\n| Security parameter      | $k$             | blocks  | The Ouroboros Praos security parameter.                                                   | n/a                                                              | Value for the Cardano mainnet.                                                            |\n\n\n### Specification of votes and certificates\n\nThe stake-proportional voting in Peras mimics the _sortition_ algorithm used in Praos: specifically it is based on the use of a *verifiable random function* (VRF) by each stake-pool operator guaranteeing the following properties:\n\n- The probability for each voter to cast their vote in a given round is correlated to their share of total stake.\n- It should be computationally impossible to predict a given SPO's schedule without access to their secret key VRF key.\n- Verification of a voter's right to vote in a round should be efficiently computable.\n- A vote should be unique and non-malleable, which is a requirement for the use of efficient certificates aggregation.\n\nAdditionally one would like the following property to be provided by the voting scheme:\n\n- Voting should require minimal additional configuration (e.g., key management) for SPOs.\n- Voting and certificate construction should be fast in order to ensure it does not interfere with other operations happening in the node.\n\nThe precise scheme and format for votes and certificates is immaterial to the protocol itself and is deferred to another proposed CIP [*Votes & Certificates on Cardano*](https://github.com/cardano-foundation/CIPs/pull/870) or to [the scheme documented in the Peras repository](https://github.com/input-output-hk/peras-design/blob/main/analytics/certificates-jan2025.md). Presumably, voting and certificates will be handled uniformly across Mithril, Peras, Leios, and partner chains.\n\n### CDDL schema for the ledger\n\nPeras requires a single addition, `peras_cert`, the [block](#blocks) data on the ledger.\n\n```diff\n block =\n   [ header\n   , transaction_bodies         : [* transaction_body]\n   , transaction_witness_sets   : [* transaction_witness_set]\n   , auxiliary_data_set         : {* transaction_index => auxiliary_data }\n   , invalid_transactions       : [* transaction_index ]\n+  , ? peras_cert               : votes_certificate\n   ]\n```\n\n[Votes](https://github.com/input-output-hk/peras-design/blob/main/analytics/certificates-jan2025.md) are serialized in the following CDDL.\n\n```cddl\nvotes_certificate =\n  [ voter_id         : hash32\n  , voting_round     : round_no\n  , block_hash       : hash32\n  , voting_proof     : vrf_cert\n  , voting_weight    : voting_weight\n  , kes_period       : kes_period\n  , kes_vkey         : kes_vkey\n  , kes_signature    : kes_signature\n  ]\n```\n\nThis definition relies on the following primitive types (drawn from Ledger definitions in [crypto.cddl](https://github.com/input-output-hk/cardano-ledger/blob/e2aaf98b5ff2f0983059dc6ea9b1378c2112101a/eras/conway/impl/cddl-files/crypto.cddl#L1)).\n\n```cddl\nround_no = uint .size 8\nvoting_weight = uint .size 8\nvrf_cert = [bytes, bytes .size 80]\nhash32 = bytes .size 32\nkes_vkey = bytes .size 32\nkes_signature = bytes .size 448\nkes_period = uint .size 8\n```\n\nAs already mentioned, the vote serialization mimics the block header's structure, which allows Cardano nodes to reuse their existing VRF and KES keys. Also note the following.\n\n- The total size of each vote is 710 bytes, according to the above definition.\n- Unless explicitly mentioned, the `hash` function exclusively uses 32-bytes Blake2b-256 hashes.\n- The `voter_id` is it's pool identifier (i.e., the hash of the node's cold key).\n\nThe CDDL for the [certificates](#certificates) that aggregate votes is specified in the proposed CIP [*Votes & Certificates on Cardano*](https://github.com/cardano-foundation/CIPs/pull/870).\n\n\n## Rationale: how does this CIP achieve its goals?\n\nThe Ouroboros Peras protocol achieves the goal of fast *ex post facto* settlement by periodically voting upon blocks of the preferred chain and giving such blocks a boost in weight if a quorum of voters vote for them in the same round. With overwhelming probability, the boost effectively \"cements\" the block forever unto the preferred chain, thus guarding it and prior blocks from rollbacks. The protocol operates under conditions of up to 25% adversarial stake, but reverts to the familiar Praos protocol under stronger adversarial conditions; after adversarial conditions abate, it remains safely in \"Praos mode\" for long enough to achieve chain healing, chain quality, and a common prefix. Thus, it does not weaken the worst-case security guarantees provided by Praos, though it does significantly speed settlement under \"normal\" non-adversarial conditions and under weakly adversarial conditions.\n\n### How Peras settles faster\n\nThe diagram below illustrates why Peras provides fast settlement. If an adversary begins building a private fork, they would reveal it publicly if it ever becomes longer than the public, honestly preferred chain: once it is revealed to be longer, honest parties would build upon it, causing the rollback of the honest blocks that were built subsequent to the divergence of the honest and private chains. Peras's boosted blocks protect against rollbacks because it can be made extremely difficult for an adversary to cause a rollback of a boosted block. Thus adversaries only have an opportunity to roll back blocks after the last boosted block and before voting occurs to boost another block. Mathematically, the window of adversarial opportunity lasts for $U + L$ slots: blocks are voted upon for boosting every $U$ slots, but there is an $L$ slot delay between a block being produced and it being voted upon. Successful voting to boost a block effectively protects that block and its ancestors. Hence a transaction is at risk of rollback for typically no more that $U+L$ slots  and that risk abates once its block or a descendant block is boosted.\n\n![Adversarial scenario against settlement](images/block-progression-adversarial.svg)\n\n### Evidence for fast settlement\n\nThe following plot quantifies the settlement-time benefits of Peras[^5] using an approximate adversarial model and probabilistic computations. Using the [example Peras protocol parameters](#feasible-values=for-peras-protocol-parameters), one has *ex post facto* settlement within two minutes of a transaction's being included in a block. This means that if the transaction's block is still on the preferred chain after two minutes, then it will remain there with essentially no chance of being rolled back unless the adversarial stake is stronger than approximately 25%. The solid curves in the plot represent Peras and the dashed ones represent Praos. (The Praos probabilities are consistent with the model of Gaži, Ren, and Russell[^1].) The protocol parameters are those listed in the section [Feasible values for Peras protocol parameters](#feasible-values-for-peras-protocol-parameters), but the [Markov-chain simulation of an adversary building and then strategically revealing it a private chain](https://github.com/input-output-hk/peras-design/tree/main/peras-markov) used to make the plot simplifies the protocol in a few inessential aspects (network diffusion and the $L$ parameter) and does not model the memory pool (which mitigates short honest forks). The red curve shows the *ex ante* probability that a block included in the preferred chain remains on the preferred chain in the future, never being rolled back. The green curve shows the *ex post facto* probability that a block which has remained on the preferred chain for 120 slots (two minutes) remains on the preferred chain in the future.\n\n![Comparison of settlement times for Peras and Praos](images/rollback-posterior.svg)\n\n[^5]: https://peras.cardano-scaling.org/docs/reports/tech-report-2#settlement-probabilities\n\nEven for adversarial stake less of 50%, there is only a vanishingly small probability of rolling back a block if it has \"survived\" long enough to have a descendant that received a Peras boost.\n\n![Probability of rolling back a transaction covered by a boosted block](images/rollback-boosted.svg)\n\n Strong adversarial activity prior to the two minutes might cause the block to be rolled back before then, as show in the plot below, but adversarial activity after that time will not roll it back. If the transaction was rolled back in the first two minutes, then it would have to be resubmitted. So, the Peras protocol provides certainty about the fate of a transaction within a brief, fixed amount of time.\n\n![Probability of a block being rolled back in Peras and Praos](images/rollback-prior.svg)\n\nThe figure below shows the race between honest parties and a modestly powerful adversary building a private chain. If the adversary's private chain ever becomes longer than the honest public one, then the adversary can reveal their chain publicly, shortly after which time the honest parties will adopt it as their preferred chain, with the consequence of rolling back all of the blocks on the honest chain from the time when the adversary started building privately. The Peras round length is 150 slots in this simulation, and one can see jump to the right every 150 slots the probability distribution of the honest chain's weight advantage over the private adversarial chain's weight. Each jump is a boost of 10 blocks' worth of chain weight. Even after one boost of the honest chain, the adversary has essentially no chance of ever overtaking the honest chain. The \"shoulder\" on the left side of the probability distribution is associated with the chain entering a cool-down period because the adversary thwarted voting, so no boost occurs.\n\n![Animation of Markov-chain simulation of honest vs adversarial behavior](images/markov.gif)\n\n### Why Peras is practical to implement\n\nPeras is compatible with many stake-based voting schemes, which means it has synergies with protocol enhancements like Ouroboros Genesis and Leios. Because Peras only modifies Praos's chain-weight computation and adds voting, its effects are mostly orthogonal to other existing and proposed aspects of Ouroboros.\n\nPeras is straightforward to implement, as it requires the following additions to the node, which have minimal or modest impact on node resources[^6].\n- Chain selection that includes the boosting from certificates\n- Building and verifying votes and certificate\n- Mini-protocols for diffusing votes and certificates\n- Permanent storage of certificates\n- Temporary storage of unexpired votes\n\n[^6]: https://peras.cardano-scaling.org/docs/reports/tech-report-2#resources-impact-of-peras\n\nThe impact of Peras upon nodes falls into four categories: [network](#network), [CPU](#cpu), [memory](#memory), and [storage](#persistent-storage). [Evidence](#votes--certificates) is provided that the CPU time required to construct and verify votes and certificates is much smaller than the duration of a voting round. Similarly, the [memory](#memory) needed to cache votes and certificates and the [disk space](#persistent-storage) needed to persist certificates are trivial compared to that needed for the UTXO set and the disk needed for the blocks.\n\nOn the networking side, [the ΔQ studies](#vote-diffusion) demonstrate that diffusion of Peras votes and certificates consumes minimal bandwidth and would not interfere with other node operations such as memory-pool and block diffusion. However, [diffusion of votes and certificates](#network-traffic) across a network will still have a noticeable impact on the _volume_ of data transfer, on the order of 20%, which might translate to increased operating costs for nodes deployed in cloud providers.\n\nThe remainder of this section outlines the use cases for Peras, discusses its mitigation of attacks, and summarizes it resource requirements.\n\n### Use cases\n\nPeras primarily benefits use cases where a party needs certainty, after a fixed amount of time, about the settlement status of a transaction. The generic use case follows.\n\n1. The party submits a transaction to the memory pool.\n2. A block producer includes the transaction in a newly forged block.\n3. The party waits a fixed amount of time, $U + L$, which is predetermined by the protocol.\n4. The party examines the preferred chain to see whether it contains the block and whether the block or one of its descendants has received a Peras boost.\n    1. It the block is on the preferred chain and guarded by a boost, then the transaction is essentially final/settled.\n    2. If the block is not on the preferred chain, then it has been rolled back and needs to be resubmitted.\n    3. If the block is on the preferred chain but there is no boost, then the chain has entered a cool-down period and the party want to wait for more confirmation, as one does currently in Praos.\n\nNote that the third (\"cool down\") case would only occur if voting was prevented by a substantial disruption such as widespread loss of network connectivity or an attack. Reasonable values for $U$ and $L$ are 90 and 30 seconds, respectively, which means that settled versus rolled-back would be certain in two minutes.\n\nSpecific use cases involving time-constrained, high-value transactions conform to this generic pattern. When the value at risk is low, a one-in-a-million chance of a rollback might not be as concerning as it would be for a large transaction. Examples follow:\n\n- Centralized exchanges, where fast settlement improves the user convenience and experience\n- Partner chains and bridges, where certainty about synchronization between two chains is essential\n- Dapps where fixed-horizon certainty is needed to orchestrate transactions\n- Ordinary transactions where a brief wait is acceptable but a roll-back is not\n\nFor example, the partner-chain use case might leverage Peras as follows.\n\n1. Funds or tokens need to be transferred from the partner chain to the Cardano chain.\n2. A smart-contract transaction escrows the funds/tokens on the partner chain.\n3. Simultaneously, a mirror of that smart-contract transaction is submitted on Cardano.\n4. After a short amount of time, the Cardano transaction has been incorporated into a newly-formed block.\n5. Wait $U + L$ slots on Cardano.\n6. With high probability the transaction will be protected by a boosted block, so there would only be an infinitesimally small chance of it ever being rolled back.\n    - If it was rolled back, go back to step 3 above.\n    - In the unlikely event that a cool-down period has been entered, wait for more confirmations.\n7. Complete the escrow contract on the partner chain.\n\n<span id=\"#confirmations\"/>Taking Kraken as an example of a centralized exchange, we see in the following table[^7] the significant delay required for transactions to be treated as final. A technology like Peras would put Cardano in the cluster of faster-settling blockchains.\n\n| Blockchain | Confirmations Required | Approximate time (minutes) |\n| ---------- | ---------------------: | -------------------------: |\n| Algorand   |                     10 |                          1 |\n| Aptos      |                     50 |                          5 |\n| Avalance   |                     20 |                          1 |\n| Bitcoin    |                      3 |                         30 |\n| Cardano    |                     15 |                         10 |\n| Dogecoin   |                     40 |                         40 |\n| Ethereum   |                     70 |                         14 |\n| Polkadot   |                    n/a |                          5 |\n| Ripple     |                    n/a |                          0 |\n| Solana     |                    n/a |                          0 |\n| Tezos      |                      6 |                          3 |\n\n[^7]: Data extracted from https://support.kraken.com/hc/en-us/articles/203325283-Cryptocurrency-deposit-processing-times on 7 August 2024.\n\n\n### Feasible values for Peras protocol parameters\n\nBased on the analyses in the [Peras Technical Report #2](https://peras.cardano-scaling.org/docs/reports/tech-report-2#defining-protocol-parameters-values), a reasonable set of default [protocol parameters](#protocol-parameters) for further study, simulation, and discussion is show in the table below. The optimal values for a real-life blockchain would depend somewhat upon external requirements such as balancing settlement time against resisting adversarial behavior at high values of adversarial stake. This set of parameters is focused on the use case of knowing soon whether a block is settled or rolled back; other sets of parameters would be optimal for use cases that reduce the probability of roll-back at the expense of waiting longer for settlement.\n\n| Parameter              | Symbol           | Units   | Value | Rationale                                                            |\n| ---------------------- | ---------------- | ------- | ----: | -------------------------------------------------------------------- |\n| Round length           | $U$              | slots   |    90 | Settlement/non-settlement in under two minutes.                      |\n| Block-selection offset | $L$              | slots   |  > 30 | Several multiples of $\\Delta$ to ensure block diffusion.             |\n| Certification boost    | $B$              | blocks  |    15 | Negligible probability to roll back boosted block.                   |\n| Security parameter     | $k_\\text{peras}$ | blocks  |  3150 | Determined by the Praos security parameter and the boost.            |\n| Certificate expiration | $A$              | rounds  |   300 | Determined by the Praos security parameter and boost.                |\n| Chain-ignorance period | $R$              | rounds  |   300 | Determined by the Praos security parameter, round length, and boost. |\n| Cool-down period       | $K$              | rounds  |   780 | Determined by the Praos security parameter, round length and boost.  |\n| Committee size         | $n$              | parties |   900 | 1 ppm probability of no honest quorum at 10% adversarial stake.      |\n| Quorum size            | $\\tau$           | parties |   675 | Three-quarters of committee size.                                    |\n\nIn pre-alpha Peras, there is a fundamental trade-off between low latency until a block can receive a boost (favoring a small $L$), and resilience against weak adversaries (<25% stake) trying to disable Peras by forcing into into a cooldown (favoring a high $L$). A *block-selection offset* of $L = 30 \\text{\\,slots}$ allows plenty of time for blocks to diffuse to voters before a vote occurs, but it provides only little resilience against weak attackers. Future iterations of Peras (involving pre-agreement) allow to resolve this trade-off (at the cost of additional complexity and network bandwidth overhead).\n\nCombining this with a *round length* of $U = 90 \\text{\\, slots}$ ensures that there is certainty in $U + L = 120 \\text{\\,slots}$ as to whether a block has been cemented onto the preferred chain by the presence of a certificate for a subsequent block. That certainty of not rolling back certified blocks is provided by a *certification boost* of $B = 15 \\text{\\,blocks}$ because of the infinitesimal probability of forging that many blocks on a non-preferred fork within the time $U$. Thus, anyone seeing a transaction appearing in a block need wait no more than two minutes to be certain whether the transaction is on the preferred chain (effectively permanently, less than a one in a trillion probability even at 45% adversarial stake) versus having been discarded because of a roll back. Unless the transaction has a stringent time-to-live (TTL) constraint, it can be resubmitted in the first $U - L = 60 \\text{\\,slots}$ of the current round, or in a subsequent round.\n\nThe Praos security parameter $k_\\text{praos} = 2160 \\text{\\,blocks} \\approx 43200 \\text{\\,slots} = 12 \\text{\\,hours}$ implies a ~17% probability of a longer private adversarial chain at 49% adversarial stake. At that same probability, having to overcome a $B = 15 \\text{\\,blocks}$ adversarial boost would require $k_\\text{peras} \\approx 70200 \\text{\\,slots} = 3510 \\text{\\,blocks} = 19.5 \\text{\\,hours}$. This determines the *certificate-expiration time* as $A = \\left\\lceil (k_\\text{peras} - k_\\text{praos}) / U \\right\\rceil = 300 \\text{\\,rounds}$, the *chain-ignorance period* as $R = A = 300 \\text{\\,rounds}$, and the *cool-down period* as $K = \\left\\lceil k_\\text{peras} / U \\right\\rceil = 780 \\text{\\,rounds}$.\n\nThe *committee size* of $n = 900 \\text{\\,parties}$ corresponds to a one in a million chance of not reaching a quorum if 10% of the parties do not vote for the majority block (either because they are adversarial, offline, didn't receive the block, or chose to vote for a block on a non-preferred fork). This \"no quorum\" probability is equivalent to one missed quorum in every 1.2 years. The *quorum size* of $\\tau = \\left\\lceil 3 n / 4 \\right\\rceil = 675 \\text{\\,parties}$ is computed from this.\n\nAt dashboard for computing the probabilistic implications of Peras protocol parameters is a available at https://peras.cardano-scaling.org/dashboard/.\n\n\n### Attack and mitigation\n\nThree major attack vectors for Peras are (1) adversarial stake, (2) equivocation of votes or blocks, and (3) manipulation of diffusion[^8].\n\n[^8]: https://peras.cardano-scaling.org/docs/reports/tech-report-2#analyses-of-adversarial-scenarios\n\nAn adversary with a significant amount of stake has an appreciable likelihood of becoming a member of the Peras voting committees. Unless they possess nearly at least 50% of the total stake, they would not have sufficient adversarial strength to dominate the committee and vote for the block of their choice. (Note that Praos itself would be weakened by an adversary with 50% of the total stake anyway.) If they possessed approximately at least 25% of the stake, they could choose not to vote, with the result that no quorum would be reached and the protocol would enter a cool-down period. Therefore, an adversary with that much stake can negate the benefits of Peras by repeatedly forcing into Praos-like cool downs. The plot below indicates that for modest amounts of adversarial stake and a committee size over 500, it would be extremely difficult for an adversary to force the protocol into a cool-down period.\n\n![Plot of the probability of not having an honest quorum as a function of the adversarial fraction of stake, for various mean sizes of the voting committee.](images/no-honest-quorum.plot.svg)\n\nA malicious party with less than 25% adversarial stake can (as in Praos) create private forks and then reveal them publicly whenever they see fit. In the context of Peras, they might try to build a fork that is longer than the public, preferred fork and then reveal it just $L$ slots before the end of the current round. Since it is then the longest chain, all parties (honest and adversarial) will likely extended it with newly forged blocks. When voting occurs at the start of the next round, that formerly adversarial chain will receive the boost and the honest fork will be abandoned essentially forever. Any transactions on that honest fork will be rolled back. Essentially, a strong enough adversary has some probability of rolling back a public, honest chain's blocks between $L + U$ and $L$ in the past.\n\n![An adversary builds their chain privately and then reveals it in order to receive a boost](images/adversarial-chain-receives-boost-variant.diagram.svg)\n\nThe plot below illustrates how shorter rounds and stronger adversaries make such attacks more likely. It is important to note that this attack cannot roll back transactions further than the last previously recorded boost (near $U + L$ in the past). This is why Peras provides an effective *ex post facto* finality: once a boost appears, all of the transactions prior to that are safe. Until a boost appears, blocks are at risk in Peras just as they are in Praos.\n\n![Plot of the probability of the dishonest boost as a function of the adversarial fraction of stake and the round length.](images/adversarial-chain-receives-boost-variant.plot.svg)\n\nDecentralized, stake-based block production and voting systems may be subject to equivocations, where a slot leader or a voting-committee member creates more than one block or casts duplicate votes for different blocks. Protocols' no-equivocation rules ensure that only the first block or vote is acted upon by the node. In the case of Peras, an adversary does not gain power from equivocating votes unless they have near 50% or more of the stake. A scenario where an adversary sends one version of a vote to some honest nodes and a different version to the other honest nodes can be handled by diffusing certificates in this case, such that no permanent disagreements on whether a round was successful arise. Equivocated votes burden the nodes slightly by creating extra network traffic.\n\nNatural events or adversaries might interfere with the diffusion of votes over the network. Peras voting is not affected so long as the network diffuses at least the 75% threshold for reaching a quorum. One quarter of the votes could be lost, dishonest, or withheld. Furthermore, the Peras $L$ parameter ensures that there is plenty of time for honest blocks to diffuse and for them to be in a common prefix of the active forks before voting begins. The Peras $R$ parameter, the number of slots for which certificates (votes) are ignored once a cool-down period starts, guards against an adversary holding onto votes and then releasing them to try to revert an already-begun cool-down period.\n\nIn no way does Peras weaken any of the security guarantees provided by Praos or Genesis. Under strongly adversarial conditions, where an adversary can trigger a Peras voting cool-down period, the protocol in essence reverts to the Praos (or Genesis) protocol, but for a duration somewhat longer than the Praos security parameter. Otherwise, settlement occurs at the blocks that Peras voting has boosted. The Peras protocol parameters can be tuned to adjust the settlement time or the non-settlement probabilities. Some stakeholder use cases might prefer shorter settlement times but with a higher probability of retries, or vice versa.\n\n\n### Resource requirements\n\nThe impact of Peras upon nodes falls into four categories: [network](#network), [CPU](#cpu), [memory](#memory), and [storage](#persistent-storage). The [Peras Technical Report #2](https://peras.cardano-scaling.org/docs/reports/tech-report-2#resources-impact-of-peras) provides supporting data, simulations, and discussion. The discussion in the following sub-sections summarizes evidence that the CPU time required to construct and verify votes and certificates is much smaller than the duration of a voting round. Similarly, the memory needed to cache votes and certificates and the disk space needed to persist certificates is trivial compared to the memory needed for the UTXO set and the disk needed for the blocks. On the networking side, ΔQ studies demonstrate that diffusion of Peras votes and certificates consumes minimal bandwidth and would not interfere with other node operations such as memory-pool and block diffusion. However, diffusion of votes and certificates across a network will still have a noticeable impact on the volume of data transfer, in the order of 20%, which might translate to increased operating costs for nodes deployed in cloud providers.\n\n#### Network\n\nFor a fully synced nodes, the impact of Peras on network traffic is modest:\n\n* For votes, assuming $U \\approx 100$, a committee size of 2000 SPOs, a single vote size of 700 bytes, means we will be adding an average of 14 kB/s to the expected traffic to each node,\n* For certificates, assuming an average of 50 kB size consistent with the size of current Mithril certificates, means an negligible increase of 0.5 kB/s on average. Note that a node will download either votes or certificate for a given round, but never both so these numbers are not cumulative. An exception to this is the needless adversarial inclusion of certificates into their blocks when Peras is *not* in a cooldown period.\n\nA fully non-synced node will have to catch-up with the _tip_ of the chain and therefore download all relevant blocks _and_ certificates. At 50% load (current monthly load is 34% as of this writing[^9]), the chain produces a 45 kB block every 20 s on average. Below are rough estimates of the amount of data a node would have to download (and store) for synchronizing, depending on how long it has been offline:\n\n| Time offline | Blocks (GB) | Certificates (GB) |\n| ------------ | ----------- | ----------------- |\n| 1 month      | 5.56        | 1.23              |\n| 3 months     | 16.68       | 3.69              |\n| 6 months     | 33.36       | 7.38              |\n\nThe Peras [Technical Report #1](https://peras.cardano-scaling.org/docs/reports/tech-report-1#network-performance-analysis) and [Technical Report #2](https://peras.cardano-scaling.org/docs/reports/tech-report-2#vote-diffusion) document network performance analysis for vote diffusion in Peras, using a ΔQ model[^10] to evaluate the expected delay to reach _quorum_. The plot below shows the diffusion of a single vote (red) and the receipt and verification of a quorum of votes (green for parallel verification of votes and blue for sequential verification of votes). The graph demonstrates that vote diffusion should be non-problematic, with a quorum expected to be reached in under 1 second most of the time to compare with a round length of about 2 minutes.\n\n![Vote diffusion](images/vote-diffusion.svg)\n\n#### Cost\n\nNetwork usage and the infrastructure for the Cardano node translates to monthly costs. This can be estimated for Peras from published network pricing for a few major Cloud and well-known VPS providers, based on the share of stakes each provider is reported to support[^11], and some typical traffic pattern as exemplified by the following plot (data courtesy of Markus Gufler).\n\n![Typical node inbound & outbound traffic](images/node-average-traffic.svg)\n\nThe next table compares the cost (in US\\$/month) for different outgoing data transfer volumes expressed as bytes/seconds, on similar VMs tailored to cardano-node's hardware requirements[^12] (32 GB RAM, 4+ Cores, 500 GB+ SSD disk). The base cost of the VM is added to the network cost to yield total costs depending on transfer rate[^13]. For an AWS hosted SPO, which represent about 20% of the SPOs, a 14 kB/s increase in traffic would lead to a cost increase of **\\$3.8/mo** (34 GB times \\$0.11/GB). This represents an average across the whole network: depending on the source of the vote and its diffusion pattern, some nodes might need to send a vote to more than one downstream peer which will increase their traffic, while other nodes might end up not needing to send a single vote to their own peers. Any single node in the network is expected to download each vote _at most_ once.\n\n| Provider     |     VM | 50 kB/s | 125 kB/s | 250 kB/s |\n| ------------ | -----: | ------: | -------: | -------: |\n| DigitalOcean |   $188 |    $188 |     $188 |     $188 |\n| Google Cloud |   $200 |    $214 |     $234 |     $268 |\n| AWS          | ? $150 |    $161 |     $178 |     $206 |\n| Azure        |   $175 |    $186 |     $202 |     $230 |\n| OVH          |    $70 |     $70 |      $70 |      $70 |\n| Hetzner      |    $32 |     $32 |      $32 |      $32 |\n\nAt present, this CIP does not include a design for a Peras-specific rewards system to e.g. directly incentivize voting participation. Any such design (where rewards are distributed on-chain) would require including certificates on-chain, therefore itself increasing the resource impact of Peras.\n\n[^9]: https://cexplorer.io/usage\n\n[^10]: https://iohk.io/en/research/library/papers/mind-your-outcomes-the-dqsd-paradigm-for-quality-centric-systems-development-and-its-application-to-a-blockchain-case-study/\n\n[^11]: https://pooltool.io/networkhealth\n\n[^12]: https://developers.cardano.org/docs/operate-a-stake-pool/hardware-requirements/\n\n[^13]: The AWS cost is quite hard to estimate up-front. The $150 base price is a rough average of various instances options in the target range. Google, AWS and Azure prices are based on 100% uptime and at least 1-year reservation for discounts. Cloud providers only charge _outgoing_ network traffic. The actual cost per GB depends on the destination, this table assumes all outbound traffic will be targeted outside of the provider which obviously won't be true, so it should be treated as an upper bound.\n\n#### Persistent storage\n\nUnder similar assumptions, we can estimate the storage requirements entailed by Peras: ignoring the impact of cool-down periods, which last for a period at least as long as $k$ blocks, the requirement to store certificates for every round increases node's storage by about **20%**. Votes are expected to be kept in memory so their impact on storage will be null.\n\nAdditionally, again ignoring cooldown periods, adversaries can include certificates in blocks they forge. Implementations could implement optimizations to avoid storing certificates twice in that case.\n\n#### CPU\n\nThe [Peras Technical Report #2](https://peras.cardano-scaling.org/docs/reports/tech-report-2#votes--certificates) provides some models and benchmarks for votes generation, votes verification, certificates proving and certificates verification, and votes diffusion. The CPU requirements will of course be dependent on the details of the Certificates' scheme used but should be negligible compared to the duration of a voting round. Moreover, as already noted, votes and certificates construction are kept out of the critical path of block forging and diffusion hence they should not impact the node's performance.\n\n#### Memory\n\nA node is expected to need to keep the following data in memory:\n\n* *Votes for the latest voting round:* For a committee size of 1000 and individual vote size of 700 bytes, that amounts to 700 kB.\n* *Cached certificates for voting rounds up to settlement depth, for fast delivery to downstream nodes:* With a boost of 10/certificate, settlement depth would be in the order of 216 blocks, or 4320 seconds, which represent about 10 rounds of 400 slots. Each certificate weighing 50 kB, that is another 500 kB of data a node would need to cache in memory.\n\nThus, Peras should not have any significant impact on the memory requirements of a node.\n\n\n## Path to active\n\n- [ ] Clear evidence of stakeholder use cases that require the fast *ex post facto* settlement that Peras provides.\n\n\n### Acceptance criteria\n\n- [ ] The revised `cardano-node` implementations pass the node-level conformance test suites.\n- [ ] Audit.\n- [ ] Successful operation in testnet environments.\n- [ ] Community agreement on the settings for the Peras protocol parameters.\n- [ ] The upcoming CIP that establishes a *Consensus* category for CIPs may define additional acceptance criteria.\n\n\n### Implementation plan\n\n- [ ] Detailed node-level (as opposed to this protocol-level) specification.\n- [ ] Develop node-level conformance test suite.\n- Consider developing a \"quick and dirty\" implementation for large scale experiments.\n- Coordinate with related activities on other protocol enhancements.\n    - Compatibility between Peras, Leios, and Genesis.\n    - Common design and implementation for certificates, voting, and related key registration: Mithril, Peras, Leios, and partner chains.\n- Triage by intersect Core Infrastructure and Consensus functions.\n\nThe following diagram summarizes a possible architecture for Peras highlighting its interactions with other components of the node.\n\n![Peras High-level Architecture](images/peras-architecture.png)\n\nPeras has no impact in the existing block diffusion process, and imposes no changes to the block header structure. The block body structure needs to accommodate for a certificate, but only on the rare occasions when the chain enters or leaves a cool-down period.\n\nThe consensus *preferred chain* selection algorithm must be modified to be aware of the existence of a _quorum_ when computing the _weight_ of a possible chain, which is manifested by a _certificate_ from the Peras component. Consensus will need to maintain or query a list of valid certificates (e.g., similar to _volatile_ blocks) as they are received or produced. The chain selection and headers diffusion is not dependent on individual votes.\n\nThe Peras component can be treated as another *chain follower* to which new blocks and rollbacks are reported. The Peras component will also need to be able to retrieve current *stake distribution*. Furthermore, it needs to access to VRF and KES keys for voting: see [_Votes & Certificates on Cardano_](https://github.com/cardano-foundation/CIPs/pull/870) for details. Dedicated long term storage will be needed for certificates.\n\nThe networking layer will need to accommodate two new mini-protocols for vote and certificate diffusion. In general, there are opportunities for shared voting, certificate, and diffusion components that handle Peras, Leios, and Mithril uniformly.\n\nPrior to full-scale Peras implementation, it would be possible to develop a standalone Peras prototype built upon the existing node, where the node is modified to receive chain-weight information from Peras, which acts as a chain follower and communicates with the node via an ad-hoc mechanism. Such a prototype would run on a testnet where the measurements and experiments could be conducted.\n\n\n## Versioning\n\nThis document describes the *pre-alpha* version of the Peras protocol. We anticipate a subsequent, separate CIP for an *alpha* or *beta* version of the protocol. That version will add strong guarantees for block selection prior to the voting process and will constitute a layer built upon this pre-alpha version.\n\nThis machine-readable specification is pinned to [Agda 2.6.4.3](https://github.com/agda/agda/tree/v2.6.4.3), the [Agda Standard Library 2.0](https://github.com/agda/agda-stdlib/tree/v2.0), and the [IOG Agda Prelude v0.1.0.0](https://github.com/input-output-hk/iog-agda-prelude/releases/tag/v0.1.0.0) via the file [flake.lock](./flake.lock). Thus it is fully and deterministically reproducible. Future revisions of the Agda code in this specification must be type checked against either those pinned versions or an upgraded future piinning of Agda and those libraries.\n\n\n## References\n\n- [Peras web site](https://peras.cardano-scaling.org/)\n- [Discord channel for Peras](https://discord.gg/9EgySPJk)\n- [Peras Technical Report #1](https://peras.cardano-scaling.org/docs/reports/tech-report-1)\n- [Peras Technical Report #2](https://peras.cardano-scaling.org/docs/reports/tech-report-2)\n- [Software repository for Peras design](https://github.com/input-output-hk/peras-design/)\n- [Online simulator for the Peras protocol](https://peras-simulation.cardano-scaling.org/)\n- [Scaling blockchain protocols: a research-based approach](https://www.youtube.com/watch?v=Czmg9WmSCcI)\n- [Consensus Redux: Distributed Ledgers in the Face of Adversarial Supremacy](https://eprint.iacr.org/2020/1021.pdf)\n- [Practical Settlement Bounds for Longest-Chain Consensus](https://eprint.iacr.org/2022/1571.pdf)\n\n\n## Appendix\n\n\n### Typechecking this specification\n\nWith [Nix](https://nix.dev/install-nix.html) installed and [Nix flakes](https://nixos.wiki/wiki/Flakes) enabled, one just needs to execute the following command to run the Agda typechecker on this file:\n\n```bash\nnix build --no-link\n```\n\nAdditionally, one can also open a Nix development shell and view, edit, or compile this specification in Emacs.\n\n```bash\nnix develop\n\nemacs README.lagda.md\n```\n\nThe first time one runs `agda-mode` in Emacs[^14], one might have to execute `agda-mode setup`, which adds lines like the following to the local configuration file `$HOME/.emacs`:\n\n```lisp\n(load-file (let ((coding-system-for-read 'utf-8))\n                (shell-command-to-string \"agda-mode locate\")))\n\n;; auto-load agda-mode for .agda and .lagda.md\n(setq auto-mode-alist\n   (append\n     '((\"\\\\.agda\\\\'\" . agda2-mode)\n       (\"\\\\.lagda.md\\\\'\" . agda2-mode))\n     auto-mode-alist))\n```\n\nFinally, the Nix flake [flake.nix](./flake.nix) contains the derivation for building this specification, and its lock file [flake.lock](./flake.lock) records the commit hashes of all dependencies, thus enabling a fully reproducible set of dependencies.\n\n[^14]: https://agda.readthedocs.io/en/v2.6.4.3/tools/emacs-mode.html\n\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0).\n"
  },
  {
    "path": "CIP-0140/flake.nix",
    "content": "{\n  description = \"Peras Specification\";\n\n  inputs = {\n    nixpkgs.url = \"github:nixos/nixpkgs/cb9a96f23c491c081b38eab96d22fa958043c9fa\";\n    flake-utils.url = \"github:numtide/flake-utils\";\n  };\n\n  outputs = { self, nixpkgs, flake-utils, ... }:\n    flake-utils.lib.eachDefaultSystem\n      (system:\n        let\n          pkgs = import nixpkgs { inherit system; };\n          lib = pkgs.stdEnv.lib;\n          localEmacs = (pkgs.emacs.pkgs.withPackages (epkgs: (with epkgs.melpaStablePackages; [\n            epkgs.agda2-mode\n          ])));\n          agda-stdlib = pkgs.agdaPackages.standard-library.overrideAttrs (oldAtts: rec {\n            version = \"2.0\";\n            src = pkgs.fetchFromGitHub {\n              repo = \"agda-stdlib\";\n              owner = \"agda\";\n              rev = \"v${version}\";\n              sha256 = \"sha256-TjGvY3eqpF+DDwatT7A78flyPcTkcLHQ1xcg+MKgCoE=\";\n            };\n            preConfigure = ''\n              runhaskell GenerateEverything.hs\n              rm EverythingSafe.agda\n            '';\n          });\n          iog-prelude = pkgs.agdaPackages.mkDerivation rec {\n            pname = \"iog-prelude\";\n            version = \"0.1.0.0\";\n            meta = { };\n            src = pkgs.fetchFromGitHub {\n              repo = \"iog-agda-prelude\";\n              owner = \"input-output-hk\";\n              rev = \"v${version}\";\n              sha256 = \"sha256-OV2WvQkjyGcfsgj81tkk/tIWHBUKsPia1d2Lh3F8qf4=\";\n            };\n            preConfigure = ''\n              mv src/Everything.agda Everything.agda\n            '';\n            buildInputs = [ agda-stdlib ];\n          };\n          localAgda = pkgs.agda.withPackages (ps: [\n            agda-stdlib\n            iog-prelude\n          ]);\n          peras-agda = pkgs.agdaPackages.mkDerivation {\n            pname = \"peras-agda\";\n            version = \"0.1\";\n            meta = { };\n            src = ./.;\n            preConfigure = ''\n              echo \"open import README\" > Everything.agda\n            '';\n            buildInputs = [ localAgda ];\n          };\n        in\n        {\n          packages.default = peras-agda;\n          defaultPackage = peras-agda;\n          devShell = pkgs.mkShell {\n            buildInputs = [\n              pkgs.nixpkgs-fmt\n              localAgda\n              localEmacs\n              pkgs.mononoki\n            ];\n          };\n        }\n      );\n\n  nixConfig = {\n    bash-prompt = \"\\\\n\\\\[\\\\033[1;32m\\\\][peras-agda:\\\\w]\\\\$\\\\[\\\\033[0m\\\\] \";\n  };\n}\n"
  },
  {
    "path": "CIP-0140/peras.agda-lib",
    "content": "name: peras\ndepend: standard-library iog-prelude\ninclude: .\nflags: --erasure\n"
  },
  {
    "path": "CIP-0141/README.md",
    "content": "---\nCIP: 141\nTitle: Web-Wallet Bridge - Plutus wallets\nStatus: Proposed\nCategory: Wallets\nAuthors: \n  - Leo\nImplementors: BroClan\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/798\nCreated: 2023-10-12\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis document describes a CIP-30 extension allowing webpages (i.e., DApps) to interface with Cardano Plutus wallets. This interface is a work in progress, and new versions are expected to be included as the ecosystem evolves. \n\n## Motivation: why is this CIP necessary?\n  \nPlutus wallets is a class of wallets where the holding address does not correspond to a public key, but to a script. This enables more complex validation logic to be implemented in the wallet, allowing for more complex spending conditions to be enforced.\n  \nExamples of Plutus wallets include :\n  - Updatable Multi-signature wallets\n  - Subscription wallets (wallet that allow for periodic payments to be made)\n  - Maltifactor authetication wallets\n  - Semi-custodial wallets\n  - Tokenized wallets\n  - EstatePlanning wallets\n  - wallets controlled by non-cardano addresses\n  \nIn order to facilitate future DApp development, we will need a way for DApps to communicate with Plutus wallets. Given the unique complexities of Plutus script-based addresses, special provisions need to be made to make the connector compatible with them.\n  \n### Rationale for the required data\n  \n  - Script descriptor: Any transaction consuming a UTXO from a Plutus-based address must attach the corresponding script.\n  - `ScriptRequirement` list: \n      - DApps need to know the scriptContext under which the transaction will be validated.\n      - DApps need to know the collateral donor to attach the collateral to the transaction.\n      - DApps need to know the `Datum` of the UTXOs that it will be consuming.\n      - DApps need to know the `Redeemers` that will be used in the transaction.\n  - Change datum\n      - DApps need to know the `Datum` that will be used as the change output for the transaction. This is mandatory for wallets based on Plutus v2 and before, as the change output must contain a datum to be valid and spendable.\n\n## Specification\n\n### Versioning\n\nTo facilitate future updates, the API will be versioned. Newer version of the API have to be compatible with the previous versions. \n\nThe current version of the API is 2.0, the major version number is derived from the version of Plutus that the API implements, and the minor version number is used for incremental updates within the same version of Plutus.\n\n### Data Types\n\n#### KeyHash\n\nA hex-encoded string of the corresponding bytes. This represents the hash of the public key used to sign transactions.\n\n```ts\ntype KeyHash = String\n```\n\n#### ScriptRequirements\n\nScript requirements encapsulate all the possible requirements for a transaction to be valid. It includes the following fields:\n\n- collateral: The input that can be used as collateral for the transaction.\n- inputs: The list of inputs that must be used as inputs for the transaction.\n- reference_inputs: The list of inputs that must be used as reference inputs for the transaction.\n- outputs: The list of outputs that must be included in the transaction.\n- mint: The amount of tokens that must be minted/burned in the transaction.\n- certificates: The list of certificates that must be included in the transaction.\n- withdrawals: The list of withdrawals that must be included in the transaction.\n- validity_range: The validity range that the transaction must be valid in.\n- signatories: The list of signatories that must sign the transaction.\n- redeemers: The list of redeemers required for the transaction, if the type is secret, the secretId will be provided to retrieve the secret from the wallet, if the type is signature, the redeemer will be a pair of [DataSpec, Signature].\n- datums: The list of datums that should be used in the transaction for the change outputs, the wallet will use the first datum in the list that is valid for the current transaction, if more than one datum is valid, the wallet will use separate datums for each change output.\n\n\n```ts\ntype ScriptRequirement = {\n  collateral?: cbor<transaction_unspent_output>,\n  inputs?: List<cbor<transaction_unspent_output>>,\n  reference_inputs?: List<cbor<transaction_unspent_output>>,\n  outputs?: List<transaction_output>,\n  mint?: Value,\n  certificates?: List<Certificate>,\n  withdrawals?: Dict<StakeCredential, Int>,\n  validity_range?: ValidityRange,\n  signatories?: List<KeyHash>,\n  redeemers?: Dict<ScriptPurpose, Redeemer>,\n  datums?: List<Hash<Blake2b_256, Data>, Data>\n}\n```\n\n```ts\ntype Redeemer = \n  | { type: RedeemerType.Data, redeemer: string }\n  | { type: RedeemerType.Secret, redeemer: SecretId }\n  | { type: RedeemerType.Signature, redeemer: [DataSpec, Primitive] };\n\nenum RedeemerType {\n  Data = 1,\n  Secret = 2,\n  Signature = 3,\n}\n\ntype DataSpec = string;\ntype Primitive = string;\n```\n\n#### ValidityRange\n\n```ts\ntype ValidityRange = {\n  valid_before?: PosixTime,\n  valid_after?: PosixTime,\n}\n```\n\n#### Value\n```ts\ntype Value = {\n    amount: Coin,\n    asset: String\n}\n```\n\n### Aditional Error Types\n\n#### CompletedTxError\n\n```ts\nCompletedTxErrorCode = {\n\tNotFound: 1,\n\tNotReady: 2\n}\n```\n\n* NotFound - The transaction with the given id was not found.\n* NotReady - The transaction with the given id is not ready yet. \n\n### V2 Additional API Endpoints\n\n#### `api.cip141.getScriptRequirements`: Promise<ScriptRequirement[]>\n\nErrors: `APIError`\n\nReturns a list of `ScriptRequirement` that will be used to validate any transaction sent to the wallet. Every field in the `ScriptRequirement` object is optional, and the wallet should only include the fields that are relevant to the current transaction.\n\nFor wallets with multiple spend conditions, separate entries in the list should be used to represent each spend condition. Wallet providers should implement UX to allow users to order the list of `ScriptRequirement` from most to least preferred. DApps should use the first entry in the list that is valid for the current transaction or select one based on the logic of their use-case.\n\n#### `api.cip141getScript()`: Promise[<number<plutusVersion>>,<CBOR<plutusScript>>]\n\nErrors: `APIError`\n\nReturns the CBOR-encoded Plutus script that controls this wallet.\n\n#### `api.cip141.submitUnsignedTx(tx: CBOR<unsignedTransaction>)`: Promise<hash32>\n\nErrors: `APIError`, `TxError`\n\nSubmits a transaction to the wallet for signing. The wallet should check that the transaction is valid, gather the required signatures, compose the finalized transaction, and submit the transaction to the network. If the transaction is valid and the wallet is able to sign it, the wallet should return the transaction hash. If the transaction is invalid or the wallet is unable to sign it, the wallet should throw a `TxError` with the appropriate error code. The wallet should not submit the transaction to the network if it is invalid or the wallet is unable to sign it.\n\nIf the transaction contains hidden metadata, the wallet should not submit the transaction when it is ready, but return it to the DApp when the DApp calls the `getCompletedTx` function.\n\nIt is expected that this will be the endpoint used by all wallets that require multiple signatures to sign a transaction.\n\n#### `api.cip141.getCompletedTx(txId: hash32)`: Promise[<CBOR<transaction>,CBOR<transaction_witness_set>>]\n\nErrors: `APIError`, `CompletedTxError`\n\nIf the transaction is not ready, the wallet should throw a `CompletedTxError` with the appropriate error code. If the transaction is ready, the wallet should return the CBOR-encoded transaction and the signatures.\n\n#### `api.cip141.getSecret(secretId: String)`: Promise<String>\n\nErrors: `APIError`\n\nReturns the secret associated with the given secretId. The secret should be returned as a hex-encoded string. \n\nWallets should request authorization from the user before returning the secret to the DApp.\n\n#### `api.cip141.signRedeemer(data: Data, primitive : encriptionPrimitive  )`: Promise<CBOR<redeemer>>\n\nErrors: `APIError`\nReturns the CBOR-encoded redeemer.\n\n### Altered API endpoints\n\n#### `api.signTx(tx: CBOR<transaction>, partialSign: bool = false)`: Promise<CBOR<transaction_witness_set>>\n\nThis endpoint will now optionally return an error if the smart Wallet is a multiparty schema and signatures need to be gathered from multiple parties asynchronously.\n\n#### `api.signData(addr: Address, payload: Bytes)`: Promise<DataSignature>\n\nPlutus contracts cannot sign data, only validate transactions. This endpoint will be disabled when connecting to a wallet using this extension.\n\n## Rationale: how does this CIP achieve its goals?\n\nBy altering the API endpoints and adding new ones, we can provide the necessary information for DApps to interact with Plutus wallets. This will allow any developer to integrate smart-wallets into their DApps, while providing a consistent interface for all wallets.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] The interface is implemented and supported by three different wallet providers.\n- [ ] The interface is used by three different DApps to interact with wallet providers. \n\n### Implementation Plan\n\n- [x] Provide some reference implementation of wallet providers\n    - [x] [leo42/BroClanWallet](https://github.com/leo42/BroClanWallet)\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0142/README.md",
    "content": "---\nCIP: 142\nTitle: Web-Wallet Bridge - Network Determination\nStatus: Proposed\nCategory: Wallets\nAuthors:\n  - Steven Johnson <steven.johnson@iohk.io>\n  - Nathan Bogale <nathan.bogale@iohk.io>\nImplementors:\n  - Lace <https://www.lace.io/>\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/209\n  - https://github.com/cardano-foundation/CIPs/pull/323\n  - https://github.com/cardano-foundation/CIPs/pull/960\n  - https://github.com/cardano-foundation/CIPs/pull/972\nCreated: 2024-01-17\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP extends CIP-0030 to provide functionality for dApps to determine the specific network magic number of the connected Cardano network. While CIP-0030's `getNetworkId()` allows distinguishing between mainnet and testnet, this extension enables dApps to identify specific test networks through their magic numbers.\n\n## Motivation: why is this CIP necessary?\n\nCurrently, CIP-0030 only provides a way to distinguish between mainnet (1) and testnet (0) through the `getNetworkId()` function. However, there are multiple test networks in the Cardano ecosystem (preview, preprod, etc.), each with its own magic number. dApps often need to know the specific test network they're connected to for proper configuration and interaction. This extension addresses this limitation by providing access to the network magic number.\n\n## Specification\n\n### Extension Identifier\n\nThis extension uses the following identifier:\n```ts\n{ \"cip\": 142 }\n```\n\n### API Extension\n\nWhen this extension is enabled, the following function is added to the API under the `cip-142` namespace:\n\n#### `api.cip142.getNetworkMagic(): Promise<number>`\n\nErrors: `APIError`\n\nReturns the magic number of the currently connected network. For example:\n- Mainnet: 764824073\n- Preview Testnet: 2\n- Preprod Testnet: 1\n- Custom Testnet: (other values)\n\nThis function will return the same value unless the connected account changes networks.\n\nExample usage:\n```typescript\nconst api = await window.cardano.lace.enable({\n  extensions: [{ cip: 142 }]\n});\n\nconst magic = await api.cip142.getNetworkMagic();\nconsole.log(`Connected to network with magic number: ${magic}`);\n```\n\n### Error Handling\n\nThe function uses the existing `APIError` type from CIP-0030 with the following error codes:\n- `InvalidRequest` (-1): If the request is malformed\n- `InternalError` (-2): If an error occurs while retrieving the magic number\n- `Refused` (-3): If access to the magic number is refused\n- `AccountChange` (-4): If the account has changed\n\n## Rationale: how does this CIP achieve its goals?\n\n### Why a New Extension?\n\nWhile CIP-0030's `getNetworkId()` provides basic network identification, the growing Cardano ecosystem requires more specific network identification, especially for development and testing purposes. This extension:\n\n1. Maintains backward compatibility by not modifying existing CIP-0030 functionality\n2. Uses explicit namespacing to avoid conflicts\n3. Provides a simple, focused solution to a specific need\n\n### Design Decisions\n\n1. **Explicit Namespacing**: The extension uses the `cip-142` namespace to clearly separate its functionality from the base CIP-0030 API.\n2. **Promise-based API**: Follows CIP-0030's pattern of returning Promises for consistency.\n3. **Reuse of Error Types**: Leverages existing error types from CIP-0030 to maintain consistency.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] Implementation by at least three wallet providers\n  - [x] Eternl\n  - [ ] Lace\n  - [x] Gero\n- [ ] Implementation by at least three web app providers\n- [ ] Implementation by at one serialisation library or SDK\n- [ ] No reported conflicts with other CIP-0030 extensions\n\n### Implementation Plan\n\n1. **Reach out to the Lace wallet team/architects**\n   - Validate technical feasibility of proposed changes\n   - Identify priorities for this implementation\n   - Identify potential integration challenges\n2. **Involve ops and products team to drive the plan further**\n   - First implementation on the Catalyst playground\n   - Create a plan, validate and collect feedback and suggestions\n3. **Implement the CIP-0142 extension in the Lace wallet**\n   - Implement and use the CIP-0142 extension in the Catalyst pla\n   - Validate against all specified acceptance criteria\n4. **Reach out to other Cardano wallet providers**\n   - Introduce the CIP-0142 extension to other wallet providers (Nami)\n   - Collect feedback and suggestions\n   - Validate against acceptance criteria\n\n**Note:** This implementation plan is subject to iterative refinement based on ongoing technical assessments and stakeholder feedback.\n  \n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). \n"
  },
  {
    "path": "CIP-0143/README.md",
    "content": "---\nCIP: 143\nTitle: Interoperable Programmable Tokens\nCategory: Tokens\nStatus: Inactive (incorporated into candidate CIP-0113)\nAuthors:\n    - Philip DiSarro <philipdisarro@gmail.com>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/444\n    - https://github.com/cardano-foundation/CIPs/pull/944\nSolution-To: CPS-0003\nCreated: 2024-12-3\nLicense: Apache-2.0\n---\n\n## Abstract\n\nThis CIP proposes a robust framework for the issuance of interoperable programmable tokens on Cardano. Unlike all its predecessors, this framework allows these tokens to be used in existing dApps, and does not require dApps to be developed specifically for these tokens. \n\n## Motivation: why is this CIP necessary?\n\nThis CIP proposes a solution to [CPS-0003 (Smart Tokens)](../CPS-0003).\n\nWith this framework we achieve programmability over the transfer of tokens (meta-tokens) and their lifecycle without sacrificing composability with existing dApps. \n\nAnswers to the open questions of CPS-0003:\n\n1) How to support wallets to start supporting validators?\n\nFor every user address you can easily derive the equivalent smart token address. So to obtain a users total wallet balance including their programmable tokens, the wallet can query their programmable token address and their normal address and combine the two results.  \n\n2) How would wallets know how to interact with these tokens? - smart contract registry?\n\nFor any given programmable token transfer, wallets can easily determine which stake script needs to be invoked (that contains the transfer logic) directly from the chain (no offchain registry required) by querying the original minting tx. \n\n3) Is there a possibility to have a transition period, so users won't have their funds blocked until the wallets start supporting smart tokens?\n\nThis framework will not cause any funds to be blocked. Transfers of non-programmable tokens will remain unaffected.\n\n4) Can this be achieved without a hard fork?\n\nYes, this framework has been possible since the Chang hard fork. \n\n5) How to make validator scripts generic enough without impacting costs significantly?\n\nThe impact that the required script executions have on the cost of transactions is negligible.  \n\n\n## Specification\n\n### Programmable Logic Minting Policy\n\nThe `mkProgrammableLogicMinting` smart contract is responsible for the minting and issuance of new programmable tokens. Additionally, the contract ensures that an entry is added to the onchain directory linked list that permenantly associates the issued programmable token with its transfer script logic and issuer script logic. \n\n```haskell\nmkProgrammableLogicMinting :: \n    Credential -- Minting logic credential\n    -> ScriptContext \n    -> ()  \nmkProgrammableLogicMinting mintingLogicCred = ... \n```\n\nThe contract accepts a single parameter, *mintingLogicCred* that defines the specialized the minting logic for the programmable token. `mintingLogicCred` must be a `ScriptCredential` of a [withdraw-zero rewarding script](https://github.com/Anastasia-Labs/design-patterns/blob/main/stake-validator/STAKE-VALIDATOR-TRICK.md).\n\n#### Supported Actions\n\nThe minting policy supports two actions:\n\n##### Token Registration (`PRegisterPToken`)\n\n- Enforces that an immutable entry for the programmable token is inserted into the programmable token directory.\n- The directory entry associates the programmable token with a transfer logic script and a issuer logic script.\n  - The transfer logic script is a withdraw-zero script that must be invoked in every user transaction that spends the programmable token.\n  - The issuer logic script is a withdraw-zero script that must be invoked in every permissioned transaction that spends the programmable token.\n    - A permissioned action is an action that can only be performed by the token issuer, that bypasses the normal transfer logic of the system. An example is seizure / clawbacks which allow the issuer of a programmable token to reclaim the token from any UTxO at their discretion. \n- Enforces that only a single new type of programmable token is issued in the transaction.\n- Enforces that all minted programmable tokens must be sent to the `programmableLogicBase` contract. \n- Enforces that the `mintingLogicCred` script is executed in the transaction see [the withdraw-zero trick](https://github.com/Anastasia-Labs/design-patterns/blob/main/stake-validator/STAKE-VALIDATOR-TRICK.md) \n\n##### Token Minting/Burning (`PMintPToken`)\n\n- Responsible for validating the minting / burning of programmable tokens.\n- If this action is used to mint programmable tokens, then it enforces that all minted programmable tokens must be sent to the `programmableLogicBase` contract.\n- Enforces that the `mintingLogicCred` script is executed in the transaction see [the withdraw-zero trick](https://github.com/Anastasia-Labs/design-patterns/blob/main/stake-validator/STAKE-VALIDATOR-TRICK.md)\n\n### Programmable Logic Base Script\n\nThe `mkProgrammableLogicBase` is a spending script that manages the ownership and transfer of programmable tokens. The `mkProgrammableLogicBase` script forwards its logic to the `mkProgrammableLogicGlobal` via [the withdraw-zero trick](https://github.com/Anastasia-Labs/design-patterns/blob/main/stake-validator/STAKE-VALIDATOR-TRICK.md). The `mkProgrammableLogicGlobal` script is responsible for ensuring that programmable tokens must always remain within the `mkProgrammableLogicBase` script and that the associated `transferLogicScript` is invoked (or  in the case of a permissioned action, that the associated `issuerLogicScript` is invoked) for each unique programmable token spent.\n\n#### Ownership Mechanism\n\nThe system enforces that programmable tokens must all reside at the `mkProgrammableLogicBase` script. As such the payment credential of any UTxO that contains programmable tokens will always be the `mkProgrammableLogicBase` script credential. This system leverages staking credentials to identify and manage ownership. This approach ensures that programmable tokens remain secure and can only be transferred by their rightful owners. The owner of a UTxO at the `mkProgrammableLogicBase` script is determined by its staking credential. If the UTxO's staking credential is a public key credential, then any transaction that spends that UTxO must be signed by the public key; the system refers to all such required signatures in a transaction as the transaction's required public key witnesses. If the UTxO's staking credential is a script credential then the associated script must be invoked in the transaction via [the withdraw-zero trick](https://github.com/Anastasia-Labs/design-patterns/blob/main/stake-validator/STAKE-VALIDATOR-TRICK.md); we refer to all such required scripts as the transaction's required script witnesses.\n\n#### Supported Actions\n\nThe `mkProgrammableLogicGlobal` (and thus the `mkProgrammableLogicBase`) supports two actions:\n\n```haskell\ndata ProgrammableLogicGlobalRedeemer\n  = PTransferAct\n      { proofs :: [PTokenProof]\n      }\n  | PSeizeAct\n      { seizeInputIdx :: Integer\n      , seizeOutputIdx :: Integer\n      , directoryNodeIdx :: Integer\n      }\n```\n\nWhere `PTokenProof` is defined as,\n```haskell\ndata PTokenProof\n  = PTokenExists { nodeIdx :: Integer }\n  | PTokenDoesNotExist { nodeIdx :: Integer }\n```\n\n##### Transfer Action (`PTransferAct`)\n- Traverse the transaction inputs and compute the sum of all value spent from the `mkProgrammableLogicBase` script, which we refer to as the `totalValueSpent`.\n  - Enforce that the required witness for each input is present in the transaction\n      - If the staking credential of the input is a payment credential then the public key hash must be present in the transaction signatories.\n      - If the staking credential of the input is a script credential then the associated script must be invoked in the transaction. \n- Simultaneously traverse the currency symbols in `totalValueSpent` and the `PTransferAct` proof list and compute the `totalProgrammableValueSpent` (value consisting of only programmable tokens).\n  - If a proof for a given currency symbol, `currentSymbol`, is `PTokenExists { nodeIdx ... }` then the reference input indexed by `nodeIdx` must satisfy the following:\n    - The reference input must be a valid programmable token directory node (i.e. it must contain a token with the `directoryNode` currency symbol).\n    - It must be the correct directory node for `currentSymbol` (i.e. the currency symbol must be equal to the node's key).\n    - The directory node's transfer logic script must be executed in the transaction.\n    - Together, these conditions enforce that the `currentSymbol` is indeed a programmable token and that the `transferLogicScript` associated with the programmable token is executed. \n  - If a proof for a given currency symbol, `currentSymbol`, is `PTokenDoesNotExist { nodeIdx ... }` then the reference input indexed by `nodeIdx` must satisfy the following:\n    - The reference input must be a valid programmable token directory node (i.e. it must contain a token with the `directoryNode` currency symbol).\n    - The directory node's `key` must be lexographically less than the `currentSymbol` and the directory node's `next` must be lexographically greater than the `currentSymbol`. \n    - Together, these conditions enforce that the `currentSymbol` is not a programmable token. \n- Traverse the transaction outputs and compute `totalProgrammableValueProduced`, the sum of all value produced to the `mkProgrammableLogicBase` script.\n- Enforce that the `totalProgrammableValueProduced` is greater than or equal to the `totalProgrammableValueSpent`.\n  - This insures that programmable tokens always remain at the `mkProgrammableLogicBase` script.\n\n##### Seize Action (`PSeizeAct`)\n- Enforce that the transaction input indexed by `seizeInputIdx`, which we refer to as the `programmableTokenInput`, is a UTxO from the `mkProgrammableLogicBase` script.\n- Enforce that there is only a single input from the `mkProgrammableLogicBase` script in the transaction.\n- Enforce that the reference input indexed by `directoryNodeIdx`, which we refer to as the `indexedDirectoryNode`, is a valid directory node (i.e. it must contain a token with the `directoryNode` currency symbol).\n- Enforce that the `issuerLogicScript` in the directory node is invoked in the transaction.\n- Enforce the the transaction output indexed by `seizeOutputIdx`, which we refer to as the `programmableTokenOutput`, satisfies the following criteria:\n  - The address of the `programmableTokenOutput` equal to the address of the `programmableTokenInput`.\n  - The value in the `programmableTokenOutput` is equal to the value in the `programmableTokenInput` after filtering the currency symbol of the programmable token associated with the `indexedDirectoryNode` (the node's `key`).\n  - The datum in the `programmableTokenOutput` is equal to the datum in the `programmableTokenInput`\n  - Together these conditions enforce that the permissioned actions of a programmable token are limited in scope such that they can only be used to transfer the associated programmable token from UTxOs, and cannot be used to modify those UTxOs in any other manner. \n\nThe system guarantees that each programmable token must have a transfer logic script (located in the associated directory node in the directory linked list). The transfer logic script for a programmable token is the smart contract that must be executed in every transaction that spends the programmable token. For example to have a stable coin that supports freezing / arrestability this script might require a non-membership merkle proof in a blacklist. This must be a staking script (or an observer script once CIP-112 is implemented), see \n[the withdraw-zero trick](https://github.com/Anastasia-Labs/design-patterns/blob/main/stake-validator/STAKE-VALIDATOR-TRICK.md) for an explanation.\n\nThis framework doesn't require custom indexers to find user / script UTxOs, instead they can be easily queried by all existing indexers / wallets. For example, to obtain all the smart tokens in a user's wallet you can construct a franken-address where the payment credential is the `mkProgrammableLogicBase` credential and the staking credential is the user's public key credential and then query this address (in the same way you would query any normal address). \n\n## Rationale: how does this CIP achieve its goals?\n\nThe existing proposed frameworks for programmable tokens are:\n1. Ethereum Account Abstraction (emulate Ethereum accounts via Plutus contract data)\n2. Smart Tokens - CIP 113\n3. Arrestable assets - CIP 125\n\nThe issue with all of the above is that they are not interoperable with existing dApps. Thus entirely new dApps protocols would need to be developed specifically for transacting with the proposed smart tokens. Furthermore, in some of the above CIPs, each smart-token enabled dApp must be thoroughly audited to ensure that it is a closed system (ie. there is no way for tokens to be smuggled to non-compliant addresses) and thus there needs to be a permissioned whitelist of which addresses are compliant.\n\nAdditionally, these proposed solutions attempt to maintain interoperability:\n1. CIP 68 Smart Tokens\n2. Transfer Scripts (ledger changes required)\n\nThe CIP 68 approach allows the tokens to be used anywhere but if the contract does not obey the logic then the token can be invalidated (ie revoked). So if you put it into a liquidity pool and the batcher does not obey the token logic then your tokens can be revoked and it wouldn't be your fault.\nThe transfer scripts proposal is to introduce a new Plutus script type that would need to be invoked in any transaction that spends a smart token (identified by the policy id). The issue with this approach is that it introduces a huge potential for vulnerabilities and exploits to the existing ledger and these vulnerabilities are responsible for the vast majority of exploits and centralization risks in ecosystems with fully programmable tokens (ie Ethereum). Regardless, this means that these tokens could not be used on existing dApps, since they would require a new Plutus version with new features, and the ledger does not allow contracts that use new features to co-exist in transactions with contract from previous versions where those features did not exist. \n\nFurthermore, all of the aforementioned proposals would require custom indexers and infrastructure to locate a user's (or smart contract's) programmable tokens. You could not simply query an address, instead you would need to query UTxOs from the contracts and check their datum / value (depending on the CIP) to determine the owner.\n\nThe above factors motivated the design of this framework. Some of the core unique properties of this framework include: \n1. Each user gets their own programmable token address that can be easily derived their credentials.\n2. Interoperability with existing dApps\n3. Introduces no new risk / vulnerabilities into existing protocols\n4. Doesn't require changes to the ledger\n5. Smart tokens cannot be revoked by dApps that fail to follow the standard (unlike the CIP 68 case in which they can)\n6. Very low effort (relative to the existing proposals) to implement and get it to production / mainnet adoption\n7. Completely permissionless and natively interoperable with other smart tokens. IE anyone can mint their own smart tokens with their own custom logic and the correctness of their behavior will be enforced\n\n## Path to Active\n\n### Acceptance Criteria\n- [x] Issuance of at-least one smart token via the proposed framework on the following networks:\n  - [x] 1. Preview testnet\n  - [x] 2. [Mainnet](https://cexplorer.io/asset/asset1dk6zekxuyuc6up56q7nkd7084k609k3gfl27n8/mint#data) \n- [x] End-to-end tests of programmable token logic including arrestability, transfer fees, and blacklisting. \n- [x] Finally, a widely adopted wallet that can read and display programmable token balances to users and allow the user to conduct transfers of such tokens. \n\n### Implementation Plan\n- [x] Implement the contracts detailed in the specification. Done [here](https://github.com/input-output-hk/wsc-poc/tree/main/src/lib/SmartTokens).\n- [x] Implement the offchain code required to query programmable token balances and construct transactions to transfer such tokens. Done [here](https://github.com/input-output-hk/wsc-poc/tree/main/src/lib/Wst/Offchain).\n\n## Copyright\nThis CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0).\n"
  },
  {
    "path": "CIP-0146/README.md",
    "content": "---\r\nCIP: 146\r\nTitle: Multi-signature wallet registration and discovery\r\nCategory: Wallets\r\nStatus: Proposed\r\nAuthors:\r\n  - Ola Ahlman <ola.ahlman@tastenkunst.io>\r\n  - Marcel Baumberg <marcel.baumberg@tastenkunst.io>\r\nImplementors:\r\n  - Eternl <https://eternl.io/>\r\nDiscussions:\r\n  - https://github.com/cardano-foundation/CIPs/pull/971\r\nCreated: 2025-01-22\r\nLicense: CC-BY-4.0\r\n---\r\n\r\n## Abstract\r\n\r\nThis document describes how to format and register a multi-signature wallet registration on the blockchain. The \r\nindividual parties that are part of the multi-signature wallet can through this registration transaction easily be \r\ndiscovered and added to the Cardano wallet software that implement the standard.\r\n\r\nThis standard both extend on and add restrictions to\r\n[CIP-1854 | Multi-signature HD Wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1854/README.md)\r\nto provide the structure of transaction auxiliary data.\r\n\r\n## Motivation: why is this CIP necessary?\r\n\r\nTerm     | Definition\r\n---      | ---\r\nMultisig | Shorthand for Multi-party signature scheme.\r\nCSL      | [Cardano serialization lib](https://github.com/Emurgo/cardano-serialization-lib) by Emurgo.\r\n\r\nMultisig wallets have the ability to communicate scripts and metadata ahead of time through a registration \r\ntransaction utilizing the transaction auxiliary data. This is a convenient way for the multisig participants to \r\ndiscover the multisig wallet before it's first usage.\r\n\r\nA common structure of the auxiliary data is needed for interoperability between wallets and web applications. The \r\nmetadatum label `1854` is used to define the native script types added in the auxiliary data and optionally provide \r\ninformation about the wallet and its participants. \r\n\r\n## Specification\r\n\r\nThe following rules apply for a multisig registration to be valid:\r\n\r\n- Auxiliary data with a non-empty native scripts array.\r\n- Auxiliary data with label `1854` metadata that at a minimum includes a mapping for script types.\r\n- `ScriptType` mapping array in metadata must match the length of, and directly corresponds to the elements in the \r\n  `native_script` array of transaction auxiliary data.\r\n- Native scripts array must at least include a payment script. Other script types are optional.\r\n- Public key hashes (credentials) included in the native scripts must be derived in accordance with CIP-1854, ie using \r\n  `purpose=1854'`. \r\n- Key derivation limited to path `1854'/1815'/0'/x/y`, ie account `0` for best cross-project interoperability and performance.\r\n- Key index (`y`) must be incremented by `1` for each publicly registered multisig wallet.\r\n- Key for role (`x`) must use the same index (`y`) for all native scripts in the registration transaction.\r\n- Additional optional metadata can be added to the `1854` metadatum label to describe the multisig.\r\n- Optional icon fields is a URL to a non-animated image file, maximum 40kb in size.\r\n\r\n### Data Types\r\n\r\n#### MultiSigRegistration\r\nLabel `1854` metadata.\r\n```ts\r\ninterface MultiSigRegistration {\r\n  types: ScriptType[];\r\n  name?: string;\r\n  description?: string;\r\n  icon?: string;\r\n  participants?: MultiSigParticipants;\r\n}\r\n```\r\n\r\n#### ScriptType\r\nA number representing a specific type (role). This corresponds to the key derivation path role (`x`).\r\n```ts\r\ntype ScriptType = number;\r\n```\r\n\r\n#### MultiSigParticipants\r\nA mapping between key credential and participant details.\r\n```ts\r\ninterface MultiSigParticipants {\r\n  [key: string]: MultiSigParticipant;\r\n}\r\n```\r\n\r\n#### MultiSigParticipant\r\nMultisig participant details.\r\n```ts\r\ninterface MultiSigParticipant {\r\n  name: string;\r\n  description?: string;\r\n  icon?: string;\r\n}\r\n```\r\n\r\n#### OffChainMultiSigRegistration\r\nThe hex-encoded bytes for a transaction auxiliary data `metadata` and `native_script` array.\r\n```ts\r\ninterface OffChainMultiSigRegistration {\r\n  metadata: string;\r\n  native_scripts: string;\r\n}\r\n```\r\n\r\n### Registration\r\n\r\nAfter the multisig wallet has been defined according to the Cardano native script standard, and adhering to the\r\n[rules](#specification), either a registration transaction can be put on the blockchain or a JSON download provided for \r\noff-chain sharing. \r\n\r\n> [!NOTE]\r\n> The registration **must** use previously unused keys in the scripts **if** registered in a transaction. \r\n\r\nThe transaction auxiliary data metadata ([MultiSigRegistration](#multisigregistration)) should be formatted using \r\nNoConversions JSON schema.\r\n\r\nIf using the CSL library, this can be accomplished with helper functions `encode_json_str_to_metadatum` and \r\n`decode_metadatum_to_json_str` specifying `MetadataJsonSchema.NoConversions` as the JSON schema.\r\n\r\nInput Output Global (IOG) documentation also describe the\r\n[no schema](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/reference/tx-metadata.md#no-schema)\r\nJSON mapping in more detail.\r\n\r\n#### Transaction\r\n\r\nA registration transaction is the most user-friendly alternative as it allows for automatic multisig wallet discovery \r\nby its participants. \r\n\r\n#### Off-chain download\r\n\r\nThe off-chain JSON file should have the format of `OffChainMultiSigRegistration`.\r\n\r\n### Discovery\r\n\r\nDiscovering registered multisig wallets on the blockchain that has public keys included for a participant wallet \r\ncan be done in the following way.\r\n\r\n- Derive Ed25519 verification keys from path `1854'/1815'/0'/x/y`.\r\n- Create key credentials, `blake2b-224` hash digests of derived keys in previous step.\r\n- Search for multisig registration transactions on the blockchain that contain metadata with metadatum label `1854` \r\n  and key credentials matching participant wallet. Only the first (oldest) encountered match should be returned.\r\n- Use `types` field in metadata to map native scripts and figure out its purpose\r\n- Repeat until no more matches are found, either sequentially or in bulk.\r\n\r\n> [!NOTE]\r\n> There might be updated metadata for the registration. In addition to locating the initial registration, a\r\n> scan for updated metadata conforming to specification and at least one input UTxO matching the multisig payment script \r\n> should be performed. If available, the last valid metadata update is to be used.\r\n\r\n### Metadata update\r\n\r\nMetadata included in the original registration transaction might need to be updated after the initial registration. To \r\nsupport this, a metadata update transaction can be created that spends at least one input UTxO from the multisig wallet \r\nto verify ownership. If this transaction includes label `1854` metadata according to specification mentioned in\r\n[registration](#registration), this will replace and update previously registered metadata.\r\n\r\n### Encrypted metadata (optional)\r\n\r\nTo increase anonymity, encrypting the metadata following the specification of [CIP-83 | Encrypted Transaction message/comment metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0083/README.md)\r\nis supported. For this to be valid, the `enc` key should be added to the root metadata object and each value \r\n(**except** `types`) within the metadata should be base64 encrypted and split into 64 character chunks according to CIP-83 specification.\r\n\r\n> [!NOTE]\r\n> `types` mapping array within metadata should always be unencrypted!\r\n\r\n> [!IMPORTANT]\r\n> The fields for `name | desciprion | icon` for the wallet and each participant is in encrypted mode a string array. \r\n> As encrypting the content might push the length outside the 64 character limitation, data needs to be split in 64 \r\n> character chunks and later merged when decrypting.\r\n\r\nExample structure:\r\n```json\r\n{ \r\n  \"1854\": { \r\n    \"enc\": \"<encryption-method>\",\r\n    \"types\": [0,2],\r\n    \"name\": [\"base64-string\"],\r\n    \"description\": [\"base64-string\"],\r\n    \"icon\": [\"base64-string\"],\r\n    \"participants\": {\r\n      \"<pub-key-hash>\": {\r\n        \"name\": [\"base64-string\"],\r\n        \"description\": [\"base64-string\"],\r\n        \"icon\": [\"base64-string\"]\r\n      },\r\n      ...\r\n    }\r\n  }\r\n}\r\n```\r\n\r\n## Rationale: how does this CIP achieve its goals?\r\n\r\nThe structure to handle registration of native scripts ahead of time has been available from the Allegra era and \r\nbeyond by including script pre-image in transaction auxiliary data. The principal aim for this specification is to \r\nreduce friction and increase interoperability between wallet providers and web applications by adding some common \r\nrules and restrictions for format of metadata and keys used in scripts.\r\n\r\n### Q & A\r\nA couple of questions was raised during discussions with team members and other projects when formalizing this \r\nstandard. The answers lay the ground in large for the specification and restrictions defined.  \r\n\r\n#### Why limit it to purpose 1854 and not allow both HD (1852) and Multi-Signature (1854) keys?\r\nMostly due to compatibility across projects and hardware devices as this is how the well established CIP-1854 \r\nspecification describe that it should be done. Also for discovery, it reduces complexity and increases\r\nperformance by only having to scan for a restricted amount of keys.\r\n \r\n#### Why not encourage and scan any account index, and not just index 0?\r\nAccount indexes is a very useful feature for normal wallets to separate funds, multi-delegation and much more. \r\nHowever, for multisig wallets, they add little value. The idea behind a multisig is that each participant is its own \r\nidentity, either person or wallet. Having multiple keys in the multisig from the same root key adds false security.\r\n\r\n#### But what if I want to utilise the benefits of account separation for fund splitting between the same set of participants?\r\nThis can easily be solved without additional accounts by adding an `after` timelock with the current slot height of \r\nthe blockchain. This creates a unique multisig wallet (address) even if the rest of the script is identical. This way,\r\nan infinite number of multisig wallets can be created similar to account separation.\r\n\r\n#### What roles should be supported on discovery?\r\nThis specification doesn't restrict discovery to any specific role, depending on the use case of the implementer and \r\nadditional roles defined in the future through new CIPs. CIP-1854 define role 0 (payment) and role 2 (stake) for \r\nscript wallets. CIP-105 was created to extend key definition with additional governance roles 3-5.\r\n\r\n#### What about key role and index restrictions?\r\nThe main reason for the incrementing key index is to mitigate a possible attack vector where a malicious actor could \r\nreplay a publicly registered multisig wallet, modifying the script in a nefarious way. When the wallets connected to the\r\nusers multisig key are discovered, both the valid and the invalid multisig registrations would be discovered and the \r\nuser might interact with the malicious wallet. By only allowing a key to be registered once, this threat can be \r\neliminated. \r\n\r\nKeeping key index in sync for all roles for the same registration makes key handling more manageable.\r\n\r\n#### Is types mapping in metadata really necessary?\r\nIt's true that on the wallet side when deriving purpose `1854` keys and scanning for registered wallets, it's known \r\nfrom what path the keys where derived and thus one could figure out the type of native script based on key credential. \r\nHowever, enforcing the transaction to include metadata with metadatum label `1854` and the types mapping make it clear \r\nthat this is a multisig registration and easier to scan for. \r\n\r\n## Path to Active\r\n\r\n### Acceptance Criteria\r\n\r\n- [ ] The specification is implemented by three wallet providers or dApps (web applications).\r\n  - [x] [Eternl Wallet](https://eternl.io)\r\n  - [ ] [MeshJS/multisig](https://github.com/MeshJS/multisig)\r\n\r\n### Implementation Plan\r\n\r\n- [x] Author to engage with wallet providers and web applications for feedback.\r\n  - [x] Discussion channel opened on [Cardano Improvement Proposals Discord server](https://discordapp.com/channels/971785110770831360/1336823914671767663)\r\n  - [x] [GitHub PR](https://github.com/cardano-foundation/CIPs/pull/971) for proposal.\r\n- [x] Author to implement said standard in Eternl wallet.\r\n- [ ] Collaborate with web applications and wallet providers to drive adoption of standard.\r\n\r\n## Copyright\r\n\r\nThis CIP is licensed under\r\n[CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\r\n"
  },
  {
    "path": "CIP-0149/README.md",
    "content": "---\nCIP: 149\nTitle: Optional DRep Compensation\nCategory: Metadata\nStatus: Proposed\nAuthors:\n    - Philip DiSarro <info@anastasialabs.com>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/991\nCreated: 2025-02-19\nLicense: CC-BY-4.0\n---\n\n## Abstract\nWe propose an opt-in standard for DRep compensation that does not require any changes to the ledger. When delegating to a DRep a user can opt-in to donate a percentage of their staking rewards to their DRep. \n\n## Motivation: why is this CIP necessary?\nIntroducing DRep compensation into the ledger will be a an absolutely massive undertaking, that will involve a large amount of engineering hours and a non-trivial price-tag. Also, the community has not yet reached consensus on whether DRep compensation is even desirable, or should be mandatory, or what the compensation scheme would even look like.\n\nThe best way to approach feature development is to release an MVP, evaluate its reception in the market, and use that data to determine the best way to proceed. This also allows us to introduce the feature without imposing it on anyone, it is opt-in, if you do not wish to compensate your DRep you can simply not opt-in. If, at any time, you wish to adjust the percentage of rewards that you are donating to your DRep you can just issue a new delegation certificate and adjust the amount or opt-out entirely.\n\n## Specification\n\nWhen tool or wallet builds a DRep vote delegation transaction (any transaction containing a `vote_deleg_cert`, `stake_vote_deleg_cert`, `vote_reg_deleg_cert` or `stake_vote_reg_deleg_cert ` certificate), the user should receive a prompt asking if they want to donate a percentage of their staking rewards to that DRep (i.e. if they want to opt-in to compensate their DRep).\n\nIf they choose to opt-in, they enter the percentage of their staking rewards that they would like their DRep to receive. The DRep delegation transaction will include that percentage in the transaction metadata, with metadatum label `3692`, in   the following format:\n\n```json\n{\n    \"3692\": {\n        \"donationBasisPoints\": PERCENTAGE_INTEGER_HERE \n    }\n}\n```\nWhere the integer stored in the metadata is the thousandths place in the decimal so 1 would convey that the user is electing to donate 0.1% of their staking rewards to their DRep. This value should be obtained directly from the percentage the user described in the prompt (ie. the user put 0.5% in the prompt then the integer in the metadata would be 5).\n\nWhen a user claims their staking rewards, their wallet will look up their delegation transaction and determine if they have opted-in to compensate their DRep (by checking the tx metadata). If metadata in the format described above is found, then the wallet will add an additional output to the reward withdrawal transaction that sends the intended percentage of their rewards to their DRep. If there is not enough ada in their reward balance to produce a output which satisfies minimum `lovelacePerUTxOWord`, the wallet will convey this to the user and let them decide how to proceed (or the user can establish how to handle this via wallet settings). \n\n## Rationale: how does this CIP achieve its goals?\nThere is little community consensus regarding the topic of DRep delegation, it is a very controversial topic that people on both sides feel very passionate about. \n\nGreat features are the result of endless iteration, the first release is never perfect. We cannot have a meaningful discussion on the impact (both positive and negative) and desirability of DRep compensation without any concrete data from which we can draw conclusions. This implementation was designed to embody the philosophy of rapid feedback based iteration. It is extremely simple to implement and bring to production. This proposal was designed to be favorable to everyone regardless on whether or not they support DRep delegation as it is entirely optional and thus can be entirely ignored by those who do not want to engage with it; furthermore, unlike other solutions, it doesn't involve any changes to the ledger that would have an ecosystem wide impact. \n\n## Path to Active\n\n### Acceptance Criteria\n- [ ] One major wallet supports this standard.\n- [ ] Gov-tools supports this standard.\n\n### Implementation Plan\n\n- [ ] Gov-tools to implement the changes required to support this standard in their UI and backend.\n- [ ] Lace to implement required DRep delegation metadata queries and construct payouts accordingly.\n\n## Copyright\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). \n"
  },
  {
    "path": "CIP-0150/README.md",
    "content": "---\nCIP: 150\nTitle: Block Data Compression\nStatus: Proposed\nCategory: Network\nAuthors:\n  - Alex Sierkov <alex.sierkov@gmail.com>\nImplementors: []\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/993\nCreated: 2025-02-24\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis proposal presents a lightweight extension to the Cardano Network protocol that:\n- Establishes a technical foundation for significantly increasing the ```max_block_size``` and ```active_slot_coefficient``` protocol parameters, improving the throughput and latency of the Cardano blockchain.\n- Accelerates blockchain synchronization by optimizing the download process for new and lagging nodes.\n- Lowers network traffic costs for Cardano stake pool operators through improved data transmission efficiency.\n\n## Motivation: why is this CIP necessary?\n\n### The Status Quo\n\nThe current block-generation time and maximum throughput of the Cardano blockchain are several orders of magnitude behind those of its more recent competitors. While ongoing research explores major architectural changes, such as sharding, this proposal offers an interim scalability improvement by enabling stake pool operators to better leverage modern hardware. By optimizing network performance with minimal protocol changes, this approach helps Cardano remain competitive until more comprehensive scaling solutions are ready for deployment.\n\n### Capabilites That Drive Demand\n\nNewer blockchains, such as Solana and Aptos, have shown that shorter block generation times and higher maximum throughput attract new use cases and drive greater demand for blockchain transactions. Thus, the claim that Cardano does not need to increase its throughput because blocks are not currently saturated overlooks the fact that alternative blockchains handle vastly more transactions—by orders of magnitude—than Cardano. This difference demonstrates strong demand for higher throughput and faster block generation.\n\n### Broad Availability of Affordable High-Performance Hardware\n\nOver the last decade, there has been a significant improvement in both CPU performance and network connectivity for rentable cloud servers. For example, servers with 24 CPU cores and 1 Gbps Internet connections are now available for lease for under $500 per month. By efficiently leveraging this hardware, it is possible to scale Cardano with minimal changes to the protocol.\nFollowing sections present one approach to achieving this.\n\nThis document does not propose a specific minimum hardware configuration for block-producing nodes.\nInstead, it demonstrates the scalability achievable with certain configurations and argues that Cardano's protocols and software should be capable of leveraging them.\n\nAnalyzing more powerful hardware configurations is also important because implementing this CIP may take a year or two. During that time, hardware performance is likely to improve while costs decline. Therefore, it is valuable to discuss hardware configurations that may become standard in the near future.\n\n### WORM Access Pattern\n\nA fundamental property of blockchain data is that historical blocks are immutable. Another key property is that each historical block is transferred to all other nodes, where it is read and validated.\n\nTherefore, block data follows a **Write Once, Read Many (WORM)** access pattern. This pattern is common in online services that distribute digital data. To optimize for this, specialized compression techniques have been developed. These techniques prioritize compression ratio and decompression speed, as blockchain data is written once but read frequently. Since blocks are typically compressed before distribution, compression speed is of secondary importance.\n\nOne example of such a technique is the [ZStandard](https://github.com/facebook/zstd) algorithm, which strikes an excellent balance between compression ratio and decompression speed. The following section explores its effectiveness on Cardano Mainnet data.\n\n### ZStandard Performance on Mainnet Data\n\nTo understand the behavior of ZStandard compression on the Cardano mainnet data, a quick simulation using two parameters has been conducted on epoch 525. The table below summarizes the simulation parameters, and the three charts display the results. The raw simulation results are provided in the [stats.json](stats.json) file.\n\n| Simulated&nbsp;Parameter | Value&nbsp;Range | Description |\n|---------------------    |-------------      |-------------|\n| ```max_block_size```    | **64&nbsp;KB**&nbsp;to&nbsp;**64&nbsp;MB** | Block sizes  were simulated by dynamically regroupping real transactions from the Cardano mainnet to evaluate their impact on compression. |\n| ```compression_level``` | **1**&nbsp;to&nbsp;**21**                  | A parameter that influences both the compression ratio and speed of the ```ZStandard``` algorithm, with higher levels generally providing greater compression at reduced speed. |\n\n![Compression ratio](compression-ratio.png)\n![Decompression speed](decode-speed.png)\n![Compression speed](encode-speed.png)\n\nThe above charts show the following tendencies:\n- The compression ratio increases with the block size.\n- Block sizes below 4 MB are too small to achieve high compression ratios.\n- The decompression speed remains above **800 MB per second** for all parameter values.\n- Compression speed is primarily dependent on the compression level, with minor improvements from larger block sizes.\n- **Compression level 9** offers a good balance of compression ratio and speed and will be used in further analysis of ZStandard performance.\n\n### Retransmission Rounds and Block Propagation Time\n\nFor a newly generated block to have a high chance of being included in the blockchain, it must reach at least 90% of the active stake before the next block is produced. The table below illustrates the distribution of active stake in epoch 525. It shows that reaching the top 515 pools covers 90% of the active stake, while reaching the top 975 pools covers 99% of it.\n\n| Number of Largest Pools (Epoch 525) | Percentage of Active Stake |\n| --- | --- |\n| 177 | 50.1% |\n| 337 | 75.1% |\n| 515 | 90.0% |\n| 654 | 95.0% |\n| 975 | 99.0% |\n| 1373 | 99.9% |\n| 2834 | 100.0% |\n\nEach block-producing node has open connections to a small subset of block-producing stake pools. Therefore, block propagation requires multiple rounds of retransmission for a new block to reach most nodes.\n\nThe required number of retransmission rounds can be estimated from a typical stake pool’s network configuration. To highlight the benefits of leveraging modern hardware, we assume all pools operate on a symmetric 1 Gbps Internet connection. Such a connection allows a block-producing node to maintain 10 open connections with 100 Mbps of bandwidth reserved for each.\n\nThe number of retransmission rounds can be calculated as the logarithm (base number of connections) of the total number of stake pools. The table below illustrates that three retransmission rounds in this configuration are sufficient to deliver a new block to 1,000 nodes, while four rounds are needed for 10,000 nodes.\n\n| Retransmission Round Number | Stake Pools Receiving New Block |\n| --- | ---- |\n| 1   | 10    | \n| 2   | 100   |\n| 3   | 1000  |\n| 4   | 10000 |\n\nGoing forward, the required number of retransmission rounds is referred to as the **retransmission coefficient**. This coefficient is important because optimizations in data compression affect not just one retransmission round but all rounds. The implications of this will be explored further in the following sections.\n\n### Impact of Data Compression on Network Propagation Time\n\nThe figure below illustrates the network propagation time of a block across three retransmission rounds. The evaluated compression settings are either no compression (level 0) or ZStandard level 9 and the assumed network bandwidth available for each connection is 100 Mbps. This analysis does not account for cross-continent round-trip delays or data processing overhead, which are discussed in the next section.\n\nA key result is that 16 MB blocks—nearly 200 times larger than the current Cardano block size of 90 KB—can still be retransmitted in under one second with three rounds of retransmissions.\n\n![3-round network propagation time](propagation-3-round.png)\n\nEven with four retransmission rounds, the network propagation time for 16 MB blocks remains just above one second, as illustrated in the next figure. Therefore, accounting for additional delays and inefficiencies, it becomes possible to consider 2- or 3-second block-generation times.\n\n![4-round network propagation time](propagation-4-round.png)\n\nThese results highlight how Cardano can leverage affordable high-performance servers and WORM-optimized compression algorithms to significantly improve its network efficiency\n\n### Block Validation Time\n\nBefore retransmitting a block, a node must first validate it. This validation consumes CPU resources proportional to the number of transactions in the block, and thus, its size. This could make validation time a bottleneck, leading some to argue that optimizing network efficiency is a lower priority.\n\nHowever, effective use of parallelization, together with the availability of affordable 24-core servers, can help manage the increased CPU demands without increasing block processing time.\n\nRecent research ([Parallelized Ouroboros Praos](https://github.com/sierkov/daedalus-turbo/blob/main/doc/2024-sierkov-parallelized-ouroboros-praos.pdf), [Parallelization-Aware Plutus Benchmarking Dataset](https://github.com/sierkov/daedalus-turbo/tree/main/experiment/plutus-benchmark)) has shown that most resource-intensive steps of block validation can be parallelized with an efficiency coefficient above 0.9 for up to 24 worker threads:\n- Validation of consensus rules.\n- Verification of cryptographic and script transaction witnesses.\n- Checking transaction inputs against the UTXO set.\n\n### Cross-Continent Transmission Delays\n\nA potential concern is that Cardano nodes are geographically distributed, leading to network packet round-trip times of up to 200 milliseconds in extreme cases. However, these cross-continent transmission delays can be mitigated through smarter algorithms for constructing node connectivity graphs. By optimizing these graphs, the impact of cross-continent delays can be minimized, ensuring that the delay penalty is incurred only once per full block retransmission cycle.\n\n### Moving in Small Steps\n\nCardano's average block-generation period is 20 seconds, with a maximum block size of 90 KB. There is a substantial difference between these parameters and the discussed 16 MB block size with a 2- to 3-second block-generation period.\n\nReducing the block-generation time to 10 or 5 seconds and increasing the maximum block size to 1 MB would still provide a sufficient safety margin for block processing and cross-continent delays, while delivering a major immediate improvement to Cardano's scalability.\n\nFurthermore, these incremental changes would provide Cardano with the necessary time and empirical data to refine its block processing and network propagation algorithms, ultimately enabling even lower propagation times, such as 3 or 2 seconds.\n\n### Compresed Storage of Blockchhain Data\n\nA final remark regarding compression is that the compression ratio increases with input size, even beyond the proposed block size of 16 MB. This fact can be leveraged to organize the compressed local storage of blocks:\n- Grouping blocks into larger chunks to achieve better compression ratios.\n- Utilizing the maximum compression level to further enhance the compression ratio.\n\n### Secure Integration of ZStandard Compression\n\nThe ZStandard C library is a highly optimized and widely adopted compression algorithm. It is used by major organizations such as Google and Mozilla and is supported as a content encoding in browsers like Chrome and Firefox. Additionally, ZStandard participates in Google's [OSS-Fuzz](https://introspector.oss-fuzz.com/projects-overview) initiative, which highlights its code quality and robustness.\n\nHowever, since ZStandard is implemented in C—a language without built-in memory safety—careful security measures must be in place to mitigate potential risks.\n\nThe primary security concern is a vulnerability in the decompression algorithm. The decompression code directly processes untrusted data received over the Internet. A malicious actor could craft a compressed block to exploit such vulnerabilities, potentially affecting all nodes, as every node must validate new blocks.\n\nIn contrast, the compression process presents a lower risk, as it operates only on known data controlled by the block producer.\n\nMost Cardano nodes run on Linux, which provides several security mechanisms to mitigate these risks. By ensuring that the decompression process is secure on Linux, we can achieve significant risk reduction. The following strategies can be applied:\n- **Isolation via IPC**: Running ZStandard in a separate process with minimal privileges and communicating through an IPC mechanism (e.g., a Unix socket). Even if an attacker exploits a vulnerability, they would only gain access to already published blocks or blocks pending validation, minimizing the impact.\n- **Virtualization**: Running ZStandard within a lightweight virtualized environment for added isolation.\n- **Dedicated Relay Node**: Executing ZStandard on a separate relay node, which does not store sensitive data such as private keys.\n\nAmong these, isolation via IPC is particularly attractive due to its minimal impact on performance and decompression latency. To demonstrate this approach, this proposal includes an example implementation that leverages Linux’s ```seccomp``` library to restrict available syscalls to only ```read```, ```write```, and ```exit```, significantly limiting the attack surface. Further details are provided in the section **Example Approach to Secure Integration of ZStandard Library on Linux**.\n\nFor enhanced security, these strategies can be combined to provide multiple layers of defense. Moreover, modern Linux distributions also include **Data Execution Prevention (DEP)** and **Address Space Layout Randomization (ASLR)** by default, which harden the system against memory-based exploits by preventing code execution in non-executable memory regions and randomizing memory addresses.\n\nAnother option for securely executing ZStandard compression code is **WebAssembly (WASM)**.\nC code with minimal modifications can be compiled directly into WASM bytecode, enabling secure execution within a WebAssembly runtime. This approach has already been explored in projects such as [zstandard-wasm](https://github.com/fabiospampinato/zstandard-wasm).  Moreover, early benchmarks indicate that decompression performance is reduced by only a factor of two compared to native execution. Given this level of efficiency, WebAssembly presents a viable solution for reducing block propagation time while enhancing security.\n\nFinally, ```ZStandard``` data format is well documented in [RFC8478](https://datatracker.ietf.org/doc/html/rfc8478), which allows for the development of decompression implementations in memory-safe languages. For example, a Rust-based implementation, [zstd-rs](https://github.com/KillingSpark/zstd-rs), already exists. However, its current decompression performance is reported to be approximately **3.5 times slower** than the C version.\n\n## Specification\n\nThe technical foundation for the above improvements can be achieved with minimal changes to [the existing network protocol](https://ouroboros-network.cardano.intersectmbo.org/pdfs/network-spec/network-spec.pdf):\n- Clients will use a new version number to signal support for compressed transfers during the handshake.\n- The FetchBlock mini-protocol is extended to include a new Server Message, ```MsgCompressedBlocks``` in the StStreaming state.\n- Stake pool operators can optionally indicate protocol version support in onchain data.\n\nThe following sections provide a detailed breakdown of these changes.\n\n### New Protocol Version Number\n\nThe Ouroboros Network Specification includes an effective mechanism for feature extension via the Handshake mini-protocol. The next unallocated version number (e.g., 15) should be used by clients and servers to signal support for the extended FetchBlock mini-protocol.\n\n### MsgCompressedBlocks Message for StStreaming State\n\n```\nMsgCompressedBlocks = [6, encoding, encoded_data]\n\n; value 0 - no compression\n; value 1 - ZStandard compression\n; values 2+ - reserved for future use\nencoding = uint\n\nencoded_data = bytes\n```\n\n```MsgCompressedBlocks``` is a new server message used to transfer a sequence of blocks, extending the functionality of ```MsgBlock``` by allowing:\n- The transmission of multiple blocks at once.\n- The option to compress a sequence of blocks.\n\nThe server can choose to send either compressed or uncompressed blocks based on its configuration. This capability enables the server to send blocks as they are stored on disk, which improves performance and reduces CPU processing times during batch synchronization.\n\n### Example Approach to Secure Integration of ZStandard Library on Linux\n\nSince Cardano block-producers are run dominantly on Linux, the use of the **Isolation via IPC** tactic can be further strengthened using Linux's ```seccomp``` feature to minimize the potential attack surface. An example implementation of this approach is provided in the [secure-zstd](https://github.com/sierkov/secure-zstd) repository.\n\n#### How It Works:\n1. The managing (caller) process creates a Unix socket.\n2. A new worker process is started, which communicates exclusively with the parent process through this socket.\n3. The worker process pre-initializes the ZStandard library by running a compressor and decompressor on a statically defined dataset. This eliminates the need for further dynamic memory allocations.\n4. The worker process closes all open file descriptors except for the Unix socket.\n5. The worker process applies a ```seccomp``` profile to restrict system calls to only ```read```, ```write```, and ```exit```.\n6. The worker process is then ready to handle compression and decompression requests from the caller process.\n\nAn attacker can still send malicious data to the Cardano Node. However, in such cases, the worker process will immediately crash, and the caller process will receive a corresponding notification.\n\nGiven the high quality of the ZStandard library, such a crash is likely indicative of an attack attempt, warranting an appropriate response:\n- **Block the malicious peer** to prevent further communication and mitigate potential Denial-of-Service attacks.\n- **Restart the worker process** to continue handling requests from a safe state.\n\nThe provided implementation is compact—approximately **200 lines of code** for [the worker process](https://github.com/sierkov/secure-zstd/blob/main/lib/seczstd/worker.c) and **100 lines of code** for [the caller](https://github.com/sierkov/secure-zstd/blob/main/lib/seczstd/caller.c). This allows for **easy security audits** compared to auditing the full ZStandard decompression library, which consists of about **15,000** lines of code.\n\nFurthermore, the **Isolation via IPC** approach, extended with ```seccomp```, can be similarly applied to other untrusted data-processing tasks, such as newer but less-tested cryptographic libraries (e.g., potential Plutus builtins) and other use cases.\n\n### Indicating Protocol Version Support in Stake Pool Operator On-Chain Data\n\nSome clients may prefer receiving block data in a compressed form to save bandwidth. Providing a quick way to identify stake pool operators that support compressed transfers would be valuable.\n\nCardano stake pool operators can already publish a URL linking to a publicly available JSON file containing additional information about their pool. These URLs are recorded on-chain and can also be retrieved through a stake pool metadata aggregation service (SMASH).\n\nThis proposal extends the metadata JSON by adding an optional key, ```protocolVersions```, which contains a list of currently supported protocol versions as a JSON array.\n\n```\nprotocolVersions = [12, 13, 15]\n```\n\nThis allows clients to quickly determine whether a stake pool operator supports the latest protocol version, including features such as compressed block transfers.\nThis is particularly important during node bootstrapping, when a new node does not yet have an up-to-date list of block-producing nodes but needs to synchronize as quickly as possible.\n\n### Possible Support Levels\n\nThe specification is intentionally designed to facilitate partial and incremental implementation. The following levels of support are possible:\n- **Minimal level** – A minimal implementation only needs to recognize protocol version 15 during the handshake and be able to parse MsgCompressedBlocks messages.\n  This implementation is straightforward and can be completed within days in most programming languages.\n- **Intermediate level** – In addition to parsing compressed blocks, an intermediate implementation can compress block data on-the-fly for each transmitted block.\n  Although on-the-fly compression is not CPU-efficient, ZStandard’s level 9 compression speed exceeds 100 MB/sec, allowing a single CPU core to fully saturate a 1 Gbps connection.\n  Implementing this is also straightforward and should take about a week in most programming languages.\n- **Advanced level** – To use CPU resources more efficiently, an advanced implementation may either cache previously compressed blocks in memory or store all block data in a compressed format.\nThis may require additional work, as certain software components may need to be modified to support compressed block data.\n- **Full level** – A full implementation must leverage data compression for block storage, including storing compressed block data on disk\nand enabling direct transmission of compressed block sequences from disk when a client requests a block range.\n\nTo be ready for testnet testing, all implementations should provide at least minimal support, and at least one implementation should support the intermediate level.\n\n## Rationale: how does this CIP achieve its goals?\n\n- Analyzes how support for data compression can serve as a technical foundation for drastically improving Cardano's scalability.\n- Evaluates the performance of the ZStandard compression algorithm on Cardano mainnet data.\n- Demonstrates how data compression, combined with more efficient use of affordable, high-performance server hardware, can scale Cardano’s transaction throughput by multiple orders of magnitude.\n- Proposes specific changes to the networking protocol to enable data compression.\n\n## Path to Active\n\n### Acceptance criteria\n- The proposed changes have been discussed and approved by subject matter experts.\n- An implementation has been prepared and addresses all major concerns identified during discussions.\n- The implementation has been tested on a testnet.\n- A security model for using the ZStandard compression library on the mainnet has been presented and approved by subject matter experts.\n- Any new concerns arising during testnet evaluation are addressed in an updated implementation, which is subsequently confirmed through a follow-up testnet evaluation.\n\n### Implementation plan\n- Develop the implementation. The individuals responsible for development will be designated after approval from subject matter experts has been received.\n- Deploy and test on the testnet.\n- Deploy on the mainnet following successful testnet evaluation.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0150/stats.json",
    "content": "[\n    {\n        \"maxBlockSize\": 65536,\n        \"zstdLevel\": 1,\n        \"compressionRatio\": 1.63256,\n        \"encodeThroughput\": 398.113,\n        \"encodeTimeMean\": 0.00015838,\n        \"decodeThroughput\": 1209.36,\n        \"decodeTimeMean\": 5.21377e-05\n    },\n    {\n        \"maxBlockSize\": 65536,\n        \"zstdLevel\": 5,\n        \"compressionRatio\": 1.71149,\n        \"encodeThroughput\": 136.188,\n        \"encodeTimeMean\": 0.000462986,\n        \"decodeThroughput\": 1409.33,\n        \"decodeTimeMean\": 4.47399e-05\n    },\n    {\n        \"maxBlockSize\": 65536,\n        \"zstdLevel\": 9,\n        \"compressionRatio\": 1.71797,\n        \"encodeThroughput\": 100.5,\n        \"encodeTimeMean\": 0.000627393,\n        \"decodeThroughput\": 1451.87,\n        \"decodeTimeMean\": 4.3429e-05\n    },\n    {\n        \"maxBlockSize\": 65536,\n        \"zstdLevel\": 13,\n        \"compressionRatio\": 1.72087,\n        \"encodeThroughput\": 45.2326,\n        \"encodeTimeMean\": 0.00139398,\n        \"decodeThroughput\": 1370.17,\n        \"decodeTimeMean\": 4.60185e-05\n    },\n    {\n        \"maxBlockSize\": 65536,\n        \"zstdLevel\": 17,\n        \"compressionRatio\": 1.75162,\n        \"encodeThroughput\": 16.5579,\n        \"encodeTimeMean\": 0.00380805,\n        \"decodeThroughput\": 1087.69,\n        \"decodeTimeMean\": 5.797e-05\n    },\n    {\n        \"maxBlockSize\": 65536,\n        \"zstdLevel\": 21,\n        \"compressionRatio\": 1.7543,\n        \"encodeThroughput\": 7.52276,\n        \"encodeTimeMean\": 0.00838166,\n        \"decodeThroughput\": 934.353,\n        \"decodeTimeMean\": 6.74833e-05\n    },\n    {\n        \"maxBlockSize\": 262144,\n        \"zstdLevel\": 1,\n        \"compressionRatio\": 2.06212,\n        \"encodeThroughput\": 500.562,\n        \"encodeTimeMean\": 0.000518702,\n        \"decodeThroughput\": 1567.63,\n        \"decodeTimeMean\": 0.000165627\n    },\n    {\n        \"maxBlockSize\": 262144,\n        \"zstdLevel\": 5,\n        \"compressionRatio\": 2.15692,\n        \"encodeThroughput\": 153.107,\n        \"encodeTimeMean\": 0.00169582,\n        \"decodeThroughput\": 1905.46,\n        \"decodeTimeMean\": 0.000136262\n    },\n    {\n        \"maxBlockSize\": 262144,\n        \"zstdLevel\": 9,\n        \"compressionRatio\": 2.19791,\n        \"encodeThroughput\": 112.152,\n        \"encodeTimeMean\": 0.00231508,\n        \"decodeThroughput\": 1892.36,\n        \"decodeTimeMean\": 0.000137205\n    },\n    {\n        \"maxBlockSize\": 262144,\n        \"zstdLevel\": 13,\n        \"compressionRatio\": 2.21787,\n        \"encodeThroughput\": 35.0223,\n        \"encodeTimeMean\": 0.00741363,\n        \"decodeThroughput\": 1715.47,\n        \"decodeTimeMean\": 0.000151353\n    },\n    {\n        \"maxBlockSize\": 262144,\n        \"zstdLevel\": 17,\n        \"compressionRatio\": 2.24438,\n        \"encodeThroughput\": 12.2225,\n        \"encodeTimeMean\": 0.021243,\n        \"decodeThroughput\": 1427.37,\n        \"decodeTimeMean\": 0.000181903\n    },\n    {\n        \"maxBlockSize\": 262144,\n        \"zstdLevel\": 21,\n        \"compressionRatio\": 2.24532,\n        \"encodeThroughput\": 6.64986,\n        \"encodeTimeMean\": 0.0390448,\n        \"decodeThroughput\": 1376.23,\n        \"decodeTimeMean\": 0.000188662\n    },\n    {\n        \"maxBlockSize\": 1048576,\n        \"zstdLevel\": 1,\n        \"compressionRatio\": 2.53074,\n        \"encodeThroughput\": 609.36,\n        \"encodeTimeMean\": 0.00171645,\n        \"decodeThroughput\": 1744.34,\n        \"decodeTimeMean\": 0.000599615\n    },\n    {\n        \"maxBlockSize\": 1048576,\n        \"zstdLevel\": 5,\n        \"compressionRatio\": 2.86093,\n        \"encodeThroughput\": 185.966,\n        \"encodeTimeMean\": 0.00562432,\n        \"decodeThroughput\": 1814.69,\n        \"decodeTimeMean\": 0.00057637\n    },\n    {\n        \"maxBlockSize\": 1048576,\n        \"zstdLevel\": 9,\n        \"compressionRatio\": 2.88514,\n        \"encodeThroughput\": 130.082,\n        \"encodeTimeMean\": 0.00804059,\n        \"decodeThroughput\": 1849.96,\n        \"decodeTimeMean\": 0.000565382\n    },\n    {\n        \"maxBlockSize\": 1048576,\n        \"zstdLevel\": 13,\n        \"compressionRatio\": 2.88951,\n        \"encodeThroughput\": 41.6058,\n        \"encodeTimeMean\": 0.0251391,\n        \"decodeThroughput\": 1828.97,\n        \"decodeTimeMean\": 0.000571871\n    },\n    {\n        \"maxBlockSize\": 1048576,\n        \"zstdLevel\": 17,\n        \"compressionRatio\": 2.9483,\n        \"encodeThroughput\": 20.4048,\n        \"encodeTimeMean\": 0.0512593,\n        \"decodeThroughput\": 1711.73,\n        \"decodeTimeMean\": 0.000611039\n    },\n    {\n        \"maxBlockSize\": 1048576,\n        \"zstdLevel\": 21,\n        \"compressionRatio\": 2.96801,\n        \"encodeThroughput\": 7.00983,\n        \"encodeTimeMean\": 0.149209,\n        \"decodeThroughput\": 1545.39,\n        \"decodeTimeMean\": 0.000676809\n    },\n    {\n        \"maxBlockSize\": 4194304,\n        \"zstdLevel\": 1,\n        \"compressionRatio\": 2.69259,\n        \"encodeThroughput\": 745.699,\n        \"encodeTimeMean\": 0.00562112,\n        \"decodeThroughput\": 2002.4,\n        \"decodeTimeMean\": 0.00209332\n    },\n    {\n        \"maxBlockSize\": 4194304,\n        \"zstdLevel\": 5,\n        \"compressionRatio\": 3.53123,\n        \"encodeThroughput\": 227.479,\n        \"encodeTimeMean\": 0.0184266,\n        \"decodeThroughput\": 2081.91,\n        \"decodeTimeMean\": 0.00201337\n    },\n    {\n        \"maxBlockSize\": 4194304,\n        \"zstdLevel\": 9,\n        \"compressionRatio\": 3.60462,\n        \"encodeThroughput\": 150.785,\n        \"encodeTimeMean\": 0.0277989,\n        \"decodeThroughput\": 2151.63,\n        \"decodeTimeMean\": 0.00194814\n    },\n    {\n        \"maxBlockSize\": 4194304,\n        \"zstdLevel\": 13,\n        \"compressionRatio\": 3.61693,\n        \"encodeThroughput\": 31.7403,\n        \"encodeTimeMean\": 0.132061,\n        \"decodeThroughput\": 2188,\n        \"decodeTimeMean\": 0.00191575\n    },\n    {\n        \"maxBlockSize\": 4194304,\n        \"zstdLevel\": 17,\n        \"compressionRatio\": 3.66747,\n        \"encodeThroughput\": 15.8395,\n        \"encodeTimeMean\": 0.264634,\n        \"decodeThroughput\": 2044.09,\n        \"decodeTimeMean\": 0.00205062\n    },\n    {\n        \"maxBlockSize\": 4194304,\n        \"zstdLevel\": 21,\n        \"compressionRatio\": 3.68262,\n        \"encodeThroughput\": 6.51622,\n        \"encodeTimeMean\": 0.643266,\n        \"decodeThroughput\": 1926.62,\n        \"decodeTimeMean\": 0.00217566\n    },\n    {\n        \"maxBlockSize\": 16777216,\n        \"zstdLevel\": 1,\n        \"compressionRatio\": 2.7386,\n        \"encodeThroughput\": 762.638,\n        \"encodeTimeMean\": 0.0219948,\n        \"decodeThroughput\": 2077.56,\n        \"decodeTimeMean\": 0.00807395\n    },\n    {\n        \"maxBlockSize\": 16777216,\n        \"zstdLevel\": 5,\n        \"compressionRatio\": 3.84668,\n        \"encodeThroughput\": 243.176,\n        \"encodeTimeMean\": 0.0689793,\n        \"decodeThroughput\": 2192.05,\n        \"decodeTimeMean\": 0.00765222\n    },\n    {\n        \"maxBlockSize\": 16777216,\n        \"zstdLevel\": 9,\n        \"compressionRatio\": 4.08797,\n        \"encodeThroughput\": 156.885,\n        \"encodeTimeMean\": 0.106919,\n        \"decodeThroughput\": 2246.4,\n        \"decodeTimeMean\": 0.00746709\n    },\n    {\n        \"maxBlockSize\": 16777216,\n        \"zstdLevel\": 13,\n        \"compressionRatio\": 4.11466,\n        \"encodeThroughput\": 29.0096,\n        \"encodeTimeMean\": 0.578225,\n        \"decodeThroughput\": 2280.43,\n        \"decodeTimeMean\": 0.00735565\n    },\n    {\n        \"maxBlockSize\": 16777216,\n        \"zstdLevel\": 17,\n        \"compressionRatio\": 4.24382,\n        \"encodeThroughput\": 13.0623,\n        \"encodeTimeMean\": 1.28416,\n        \"decodeThroughput\": 2188.63,\n        \"decodeTimeMean\": 0.0076642\n    },\n    {\n        \"maxBlockSize\": 16777216,\n        \"zstdLevel\": 21,\n        \"compressionRatio\": 4.279,\n        \"encodeThroughput\": 5.66808,\n        \"encodeTimeMean\": 2.95939,\n        \"decodeThroughput\": 2108.3,\n        \"decodeTimeMean\": 0.00795622\n    },\n    {\n        \"maxBlockSize\": 67108864,\n        \"zstdLevel\": 1,\n        \"compressionRatio\": 2.74633,\n        \"encodeThroughput\": 748.516,\n        \"encodeTimeMean\": 0.0896523,\n        \"decodeThroughput\": 2016.43,\n        \"decodeTimeMean\": 0.0332796\n    },\n    {\n        \"maxBlockSize\": 67108864,\n        \"zstdLevel\": 5,\n        \"compressionRatio\": 3.93538,\n        \"encodeThroughput\": 257.649,\n        \"encodeTimeMean\": 0.260456,\n        \"decodeThroughput\": 2138.61,\n        \"decodeTimeMean\": 0.0313783\n    },\n    {\n        \"maxBlockSize\": 67108864,\n        \"zstdLevel\": 9,\n        \"compressionRatio\": 4.25619,\n        \"encodeThroughput\": 163.85,\n        \"encodeTimeMean\": 0.409559,\n        \"decodeThroughput\": 2210.75,\n        \"decodeTimeMean\": 0.0303544\n    },\n    {\n        \"maxBlockSize\": 67108864,\n        \"zstdLevel\": 13,\n        \"compressionRatio\": 4.29296,\n        \"encodeThroughput\": 30.6292,\n        \"encodeTimeMean\": 2.19092,\n        \"decodeThroughput\": 2354.02,\n        \"decodeTimeMean\": 0.028507\n    },\n    {\n        \"maxBlockSize\": 67108864,\n        \"zstdLevel\": 17,\n        \"compressionRatio\": 4.49838,\n        \"encodeThroughput\": 12.4501,\n        \"encodeTimeMean\": 5.39001,\n        \"decodeThroughput\": 2273.69,\n        \"decodeTimeMean\": 0.0295142\n    },\n    {\n        \"maxBlockSize\": 67108864,\n        \"zstdLevel\": 21,\n        \"compressionRatio\": 4.74204,\n        \"encodeThroughput\": 4.88263,\n        \"encodeTimeMean\": 13.7438,\n        \"decodeThroughput\": 2033.34,\n        \"decodeTimeMean\": 0.0330029\n    }\n]\n  "
  },
  {
    "path": "CIP-0151/CIP88_Master_v2.cddl",
    "content": "; CIP-0088 Cardano Registration Certificates\n; Version: 2\n\n; Definitions\nstring = text .size (0..64)\n\n; A token-asset is a reference to a specific token\n\npolicy-id = bytes .size (28) ; Policy ID bytes\nasset-id = bytes .size (0..32) ; Asset ID bytes\npool-id = bytes .size (28) ; Pool ID bytes\n\ntoken-asset = [\n    policy-id,\n    asset-id,\n]\n\n; A uri should consist of a scheme and one or more path strings describing the path to the resource\n; The first entry should contain the URI \"Scheme\" (e.g. \"https://\", \"ftp://\", \"ar://\", \"ipfs://\")\n; One or more subsequent entries should describe the path of the URI\n\nuri.scheme = text .size (5..64)\nuri.path = text .size (1..64)\nuri = [\n    uri.scheme,\n    + uri.path,\n]\n\n; CIP Details\n;\n; CIP-Specific details should each be documented in their own versioned file for historic compatibility and future-proofing\n; against changes to the specification. Wherever possible, future specs should honor previous fields and be only additive\n; where possible. Previously used numeric indexes should never be repurposed.\n\ncip-details = {\n    ? 25 : cip25-details,  ; ./cip/CIP-25_v1.cddl\n    ? 26 : cip26-details,  ; ./cip/CIP-26_v1.cddl\n    ? 27 : cip27-details,  ; ./cip/CIP-27_v1.cddl\n    ? 48 : cip48-details,  ; ./cip/CIP-48_v1.cddl\n    ? 60 : cip60-details,  ; ./cip/CIP-60_v1.cddl\n    ? 68 : cip68-details,  ; ./cip/CIP-68_v1.cddl\n    ? 86 : cip86-details,  ; ./cip/CIP-86_v1.cddl\n}\n\n; Registration Scopes\n;\n; Each registration should begin with a scope declaring the type of object being registered\n\ntoken-scope = [\n    0,                       ; scope identifier\n    bytes .size (28),        ; Token Policy ID\n    [+ bytes .size (1..64)], ; Token Policy Hex\n]\n\npool-scope = [\n    1,                       ; scope identifier\n    pool-id,                 ; Stake Pool ID\n]\n\n; Validation Methods\n; 0 = Ed25519 Key Signature\n; 1 = \"Beacon\" or Reference Token Mint (CIP-27 \"Nameless\" Token)\n; 2 = \"CIP-0008\" COSE Signature\n\nvalidation.method = uint;\nvalidation.context = string;\n\nvalidation-details = [\n    validation.method,\n    * validation.context,\n]\n\ncalidus-key = bytes .size (32) ; An Ed25519 public key that can be used to provide future updates/authentication\n\nregistration-scope = token-scope / pool-scope\n\nscope-details = {\n      1 : registration-scope,   ; Registration scope\n      2 : [* uint],             ; Feature Set\n      3 : validation-details,   ; Signature Method\n      4 : uint,                 ; Nonce\n    ? 5 : uri,                  ; Oracle URI\n    ? 6 : cip-details,          ; CIP-specific details\n    ? 7 : calidus-key,           ; An Ed25519 public key that is authorized for future updates/authentication\n}\n\n; Witness is changed to a map in v2 to support more dynamic types and identification in the future w/o guessing at\n; array length. It is recommended to only use v2 witnesses with v2+ registrations\nv1_witness = [\n    bytes .size (32),  ; Public Key\n    bytes .size (64),  ; Signature\n]\n\n; In v2 witnesses are changed to a map with an optional type identifier.\n; A default of 0 for \"Witness Type Identifier\" should be considered a COSE Signature from CIP-0008\n\nCOSE_Headers = {\n     1 : uint,              ; COSE Key Type\n     3 : int,               ; COSE Key Algorithm\n    -1 : uint,              ; EC Identifier\n    -2 : bytes .size (32),  ; Public Key\n}\n\nCOSE_Sign1_Payload = [\n    bytes .size (41),\n    uint,\n    bytes .size (32),\n    bytes .size (64),\n]\n\nCOSE_Witness = {\n  ? 0 : uint,                ; Witness Type Identifier (optional or 0)\n    1 : COSE_Headers,        ; COSE Header Object\n    2 : COSE_Sign1_Payload,  ; COSE Signature Payload\n}\n\nv2_witness = {\n    0 : uint,   ; Witness Type Identifier (Must be set)\n    1 : bytes,  ; Witness Public Key\n    2 : bytes,  ; Witness Signature\n}\n\nwitness = v1_witness / COSE_Witness / v2_witness;\n\nwitnesses = [+ witness]\n\ncip88-registration = {\n    ? 0 : uint, ; version\n      1 : scope-details,\n    ? 2 : witnesses\n}\n\nmetadata = { 867 : uint => cip88-registration }"
  },
  {
    "path": "CIP-0151/CIP88_Master_v2.example.json",
    "content": "{\n  \"867\": {\n    \"0\": 2,\n    \"1\": {\n      \"1\": [\n        1,\n        \"0x4a930ad12820627500fbd68b071a22ef558acbdfbff53699f21152ce\"\n      ],\n      \"2\": [],\n      \"3\": [\n        2\n      ],\n      \"4\": 147897723,\n      \"7\": \"0x57758911253f6b31df2a87c10eb08a2c9b8450768cb8dd0d378d93f7c2e220f0\"\n    },\n    \"2\": [\n      {\n        \"1\": {\n          \"1\": 1,\n          \"3\": -8,\n          \"-1\": 6,\n          \"-2\": \"0x64e7344b00dcde14e6a498d79d96bfd72d73e2138802c41e6dd9b46662013f30\"\n        },\n        \"2\": [\n          \"0xa201276761646472657373581c4a930ad12820627500fbd68b071a22ef558acbdfbff53699f21152ce\",\n          0,\n          \"0x9fbfa7da5a94f7de7fd9eb6976a3c72fa39e8d909b10fff8e83b7a6b238df9e0\",\n          \"0x6b0ee625102b1e254698987f079e51f43585c45f837d408ce23b35619ed97c5a371c52834ba4a588e76d02bdccd9d368077a85bbfd7935588730300686ecec06\"\n        ]\n      }\n    ]\n  }\n}"
  },
  {
    "path": "CIP-0151/README.md",
    "content": "---\nCIP: 151\nTitle: On-Chain Registration - Stake Pools\nCategory: Metadata\nStatus: Active\nAuthors:\n    - Adam Dean <adam@crypto2099.io>\n    - Martin Lang <martin@martinlang.at>\nImplementors:\n    -   Cardano Signer: https://github.com/gitmachtl/cardano-signer/releases/tag/v1.23.0\n    -   pg_cardano: https://github.com/cardano-community/pg_cardano/releases/tag/v1.0.5-p1\n    -   Cardano Koios: https://github.com/cardano-community/koios-artifacts/tree/v1.3.2\n    -   CNTools: https://github.com/cardano-community/guild-operators/tree/alpha\n    -   SPO Scripts: https://github.com/gitmachtl/scripts\n    -   Reference Implementation: https://github.com/crypto2099/calidus-demo\n    -   VeriGlyph Sentinel: https://sentinel.veriglyph.io\n    -   Ekklesia: https://ekklesia.vote\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/999\n    - https://forum.cardano.org/t/new-calidus-pool-key-for-spos-and-services-interacting-with-pools\nCreated: 2025-02-17\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\n[CIP-0088] defined a standard to submit on-chain registration certificates with\na specific initial focus on Cardano's _Native Scripts_ specifically related to\nNFT and FT minting policies. This extension to the standard aims to provide\nsupport for stake pools to register verifiable information on-chain.\n\n## Motivation: why is this CIP necessary?\n\nBy extending the existing [CIP-0088] specification, we can provide an extensible\nframework for stake pool operators (SPOs) to provide verifiable, on-chain\ninformation related to their pool operation. This method is preferred over a\nchange to the in-ledger stake pool registration certificates because additional\nextensions and functionality may be added dynamically without changing the core\nCardano network ledger.\n\n## Specification\n\n[CIP-0088] provides a clear framework for extension and versioning of the\nstandard so this CIP introduces a _[Version 2]_ of the CIP-0088 Master CDDL\nalong with a number of other changes.\n\n### Registration Metadata Format\n\n`Version: 2`\n\n| Index | Name                                                 | Type  | Required | Notes                                                        |\n|-------|------------------------------------------------------|-------|----------|--------------------------------------------------------------|\n| 0     | Version                                              | UInt  | Yes      | Should be set to 2                                           |\n| 1     | [Registration Payload](#registration-payload-object) | Map   | Yes      | Object describing and providing details for the token policy | \n| 2     | [Registration Witness](#registration-witness-array)  | Array | Yes      | Array of witness signatures used to validate the payload     |\n\n### Registration Payload Object\n\nThe Token Registration Payload Object (TRPO) consists of 4 required fields and\noptional additional fields to provide context and information. The top-level\nmetadata label of **867** has been chosen for the purposes of this standard.\n\n#### Fields\n\n| Index | Name              | Type   | Required | Notes/Examples                                                                                                                                                                                                                                    |\n|-------|-------------------|--------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 1     | Scope             | Array  | Yes      | An array defining the scope of this registration (for greater compatibility with CPS-0001). The first entry should be an unsigned integer value identifying the type of scope while the second entry addresses the specific scope of registration |\n| 2     | Feature Set       | Array  | Yes      | An array of unsigned integers specifying none or more CIP standards utilized by the tokens of this project. Should reference the assigned CIP number.                                                                                             |\n| 3     | Validation Method | Array  | Yes      | How should this payload be validated.                                                                                                                                                                                                             |\n| 4     | Nonce             | UInt   | Yes      | A simple cache-busting nonce. Recommend to use the blockchain slot height at the time of submission. Only the highest observed nonce value should be honored by explorers.                                                                        |\n| 6     | CIP Details       | Object | No       | If one or more of the CIPs addressed in the Feature Set have additionally defined metadata, it may be added here                                                                                                                                  | \n| 7     | Calidus Key       | String | No       | An Ed25519 public key that is authorized by the owner to authenticate and sign messages on behalf of the _Scope_                                                                                                                                  |\n\n> The following fields (1-4) are required in all token registration submissions.\n\n##### 1. Scope\n\nThe scope entry indicates what type of entity is being registered with this\nmetadata.\n\n**Scopes**\n\n| ID | Scope         | Format                             |\n|----|---------------|------------------------------------|\n| 0  | Native Script | `[0, h'policyID', [h'policyHex']]` |\n| 1  | Stake Pool    | `[1, h'poolID']`                   |\n\n0. **Native Scripts**: Native scripts should be specified as an array with the\n   first entry indicating the type (Native Script), the second entry indicating\n   the script hash (Policy ID) and the third entry consisting of an array with\n   one or more 64-byte strings constituting the hex-encoded CBOR representation\n   of the Native Script itself. In this way, CIP-88 registration may be\n   submitted on-chain prior to any tokens being minted and can be used by\n   validators to confirm the legitimacy of the certificate without any secondary\n   information source.\n1. **Stake Pool**: Stake pools are specified as an array with the first entry\n   indicating the type (Stake Pool), the second entry is the Pool ID. The Pool\n   ID is the blake2b-224 hash of the pool **cold** public key.\n\n**Example:**\n\nNative Script:\n<br />\n`[0, h'3668b628d7bd0cbdc4b7a60fe9bd327b56a1902e89fd01251a34c8be', h'8200581c4bdb4c5017cdcb50c001af21d2488ed2e741df55b252dd3ab2482050']` <br />\nStake Pool:\n<br />\n`[1, h'71e3c37983775238704fad6d337ca632c713829292bf10a8e9fc50ad']`\n\n#### 2. Feature Set\n\nThe _Feature Set_ is a simple array of unsigned integer values representing the\nCIP standards that should be applied to the subject scope. For now this should\nbe an empty array when registering a stake pool.\n\n**Example:**\n\n`[25, 27]`\n\n#### 3. Validation Method\n\nIn order to minimize issues relating to capitalization and misspellings, we\nshould use a well-defined map of integer values for validation methods that will\nbe utilized by third party observers and processors to authenticate the payload.\nThe validation method entry should always be provided as an array with the first\nelement being an unsigned integer representing the method and additional entries\nproviding additional context to the validation as required.\n\n***Proposed Validation Methods***\n\n| ID | Type                   | Format                              | Notes                                                                                                                                                                                                                                                                                                                                                                                                                                      |\n|----|------------------------|-------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 0  | Ed25519 Key Signature  | `[0]`                               | The most basic and simplistic approach to signing and validation. In this case the Registration Witness object could contain one or more pubkey + signed witness objects. The payload to be signed should be the hex-encoded CBOR representation of the Registration Payload object.                                                                                                                                                       |\n| 1  | Beacon/Reference Token | `[1, [h'<policyId>',h'<assetId>']]` | Similar to the approach utilized by [CIP-27](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0027). We could attach this metadata during a mint transaction for a specially formatted token under the policy ID in question. CIP-27 uses a \"nameless\" token that has an empty \"Asset ID\" for example. This may be a validation method that lends itself better to supporting token projects that are minted via Smart Contract. |\n| 2  | CIP-0008 Signature     | `[2]`                               | Follow the specifications in [CIP-0008] to verify signatures                                                                                                                                                                                                                                                                                                                                                                               |\n\n**Examples:**\n\n`[0]`<br />\n`[1, [h'<policyId>',h'<assetId>']]`<br />\n`[2]`\n\n#### 4. Nonce\n\nThe nonce value is utilized to prevent a replay attack vector. The nonce value\nshould be an unsigned integer value that is always at least one greater than the\npreviously registered value. It is recommended that you use the current absolute\nslot height of the chain when constructing a new registration to ensure that\nthis value always increases.\n\n**Example:**\n\n`12345`\n\n> Note: The following map keys and values are optional\n\n#### 5. Data Oracle URI\n\nTo be utilized and expanded upon in a separate CIP, this should be a valid URI\npointing to a source of additional, potentially dynamic information relating to\nthe project and/or the tokens minted under it.\n\n> This is not currently used for stake pool operator registrations.\n\n#### 6. CIP-Specific Information\n\nThis entry, if present, should be a CIP ID indexed object containing additional\ninformation pertaining to that CIP. When and where possible the CIP-Specific\nregistration should follow the CBOR-like declaration syntax to ensure that the\ncontent is well-formed and easily parseable.\n\n> There are currently no Stake Pool-specific CIPs to be used here but could be\n> added in the future.\n\n#### 7. Calidus Key\n\nCalidus is a Latin word meaning: _fiery_, _spirited_, or _rash_. It is\nsynonymous with being a \"quick\" or \"hot\" key and was chosen by the authors\nbecause other labels were causing confusion (update key, daily key, etc.)\n\nThe Calidus Key is an Ed25519 Public Key that is authorized to be used for\nsigning authentication or update transactions in the future on behalf of the\nstake pool or native script being registered with this certificate.\n\nThe Calidus Key should be provided as the byte-array (hex-encoded) public key\nthat will be used for signing in the future. The active `Calidus Key` for the\nregistered entity should be the highest nonce value valid registration. If the\nkey is thought to be compromised previous keys may be invalidated by submitting\na new on-chain registration with a higher nonce value.\n\n**Example:**\n`h'57758911253f6b31df2a87c10eb08a2c9b8450768cb8dd0d378d93f7c2e220f0'`\n\n> **IMPORTANT NOTE:** This standard does not provide a mechanism to revoke the\n> authorization of a Calidus key except for replacing it with a new key. Those\n> wishing to revoke their key without replacement should submit an update\n> registration with a blank key (all zeroes) in place of the Calidus key.\n>\n> Tooling providers should recognize this as explicitly revoking all previous\n> registrations without adding a new key.\n>\n> Example: `h'0000000000000000000000000000000000000000000000000000000000000000'`\n\n##### Bech32 Encoding\n\nWe define a prefix when Bech32 encoding the Calidus key to leave room for future\nexpansion and use similar to [CIP-129] and other Bech32 encodings used within\nthe Cardano ecosystem.\n\n###### Binary format\n\nIn the header-byte, bits [7;4] indicate the type of key being used. The\nremaining four bits [3;0] are used to define the credential type. There are\ncurrently 1 types of credentials defined in the Cardano Conway era, this\nspecification will allow us to define a maximum of 16 different types of keys in\nthe future.\n\n```\n  1 byte     variable length   \n <------> <-------------------> \n┌────────┬─────────────────────┐\n│ header │        key      │\n└────────┴─────────────────────┘\n    🔎                          \n    ╎          7 6 5 4 3 2 1 0  \n    ╎         ┌─┬─┬─┬─┬─┬─┬─┬─┐ \n    ╰╌╌╌╌╌╌╌╌ |t│t│t│t│c│c│c│c│ \n              └─┴─┴─┴─┴─┴─┴─┴─┘ \n```\n\n###### Key Type Prefix\n\n| Key Type (`t t t t . . . .`) | Key        |\n|------------------------------|------------|\n| `1010....`                   | Stake Pool |\n\n###### Credential Type Prefix\n\n| Credential Type (`. . . . c c c c`) | Semantic    |\n|-------------------------------------|-------------|\n| `....0001`                          | Key Hash    |\n| `....0010`                          | Script Hash |\n\n**Stake Pool Calidus Key Example**\n\n| Label                          | Value                                                              |\n|--------------------------------|--------------------------------------------------------------------|\n| Stake Pool Key Hash Prefix     | `a1`                                                               |\n| Calidus Public Key             | `57758911253f6b31df2a87c10eb08a2c9b8450768cb8dd0d378d93f7c2e220f0` |\n| Blake2b-224 Hash of Public Key | `171983a1178a55b02afacfd6ad6b516da375469fd7dbcf54a2f95823`         |\n| Prefixed PubKey Hash           | `a1171983a1178a55b02afacfd6ad6b516da375469fd7dbcf54a2f95823`       |\n| Bech32-encoded Calidus Key ID  | `calidus15yt3nqapz799tvp2lt8adttt29k6xa2xnltahn655tu4sgcph42p7`    |\n\n![Calidus Key Flow Chart](CalidusKeyv2.jpg)\n\n### Registration Witness Array\n\n**IMPORTANT**: This v2 CIP introduces two major changes to the signing method(s)\navailable and utilized.\n\n1. Change #1: Signature Payload\n    1. Version 1 of the standard used the hex-encoded CBOR of the Token\n       Registration Payload Object as the signing payload.\n    2. Version 2 of this standard uses the `blake2b-256` hash of the hex-encoded\n       CBOR of the Token Registration Payload Object as the signing payload.\n       This change was made to better support signing using hardware wallets (\n       Ledger, Trezor, Keystone)\n    3. Objects in the signing payload **MUST BE** in numerical order by index in\n       order to ensure that hashes can be correctly parsed by downstream\n       tooling.\n2. Change #2: Witness Structure Changes to Maps\n    1. Version 1 of the standard assumed basic Ed25519 CLI keys and signatures\n       so the structure of witnesses in the Registration Witness Array were\n       passed as simple arrays with the first element being a public key and the\n       second element being the signature.\n    2. Version 2 of this standard introduces the ability to use [CIP-0008]\n       signing (validation method `2`) which provides the ability for SPOs to\n       sign with hardware wallets and [CIP-0030] web wallets as well. Please\n       refer to [CIP-0008] for signature validation and payload structure\n       details.\n\n#### (Stake Pools)\n\nThe Witness Array **must** include a signature from the Pool Cold Key. The\nformat of witnesses will depend on the validation method used although all v2+\nregistrations should use the updated `blake2b-256` hash of the hex-encoded CBOR\nof the Token Registration Payload Object as the signature payload.\n\n##### Version 1 Witness\n\nA CIP-88 v1 Witness is a simple array consisting of the hex-encoded byte array\nof the public key as the first entry and the hex-encoded byte array of the\nwitness signature as the second entry.\n\n**Example**\n\n```cbor\n[\n  [\n    h'02b76ae694ce6549d4a20dce308bc7af7fa5a00c7d82b70001e044e596a35deb',\n    h'23d0614301b0d554def300388c2e36b702a66e85432940f703a5ba93bfb1659a0717962b40d87523c507ebe24efbb12a2024bb8b14441785a93af00276a32e08'\n  ]\n]\n```\n\n##### Version 2 Witness\n\nCIP-88 v2 (this CIP) introduces the version 2 witness structure which is a map\nthat allows us to provide additional scoped information for different witnesses\nto suite a variety of purposes.\n\n**v2 Witness Schema**\n\n```cbor\n; In v2 witnesses are changed to a map with an optional type identifier.\n; A default of 0 for \"Witness Type Identifier\" should be considered a COSE Signature from CIP-0008\n\nCOSE_Key = {\n     1 : uint,              ; COSE Key Type\n     3 : int,               ; COSE Key Algorithm\n    -1 : uint,              ; EC Identifier\n    -2 : bytes .size (32),  ; Public Key\n}\n\nCOSE_Sign1_Payload = [\n    bytes .size (41),\n    uint,\n    bytes .size (32),\n    bytes .size (64),\n]\n\nCOSE_Witness = {\n  ? 0 : uint,                ; Witness Type Identifier (optional or 0)\n    1 : COSE_Key,            ; COSE Key Header Object\n    2 : COSE_Sign1_Payload,  ; COSE Signature Payload\n}\n\nv2_witness = {\n    0 : uint,   ; Witness Type Identifier (Must be set)\n    1 : bytes,  ; Witness Public Key\n    2 : bytes,  ; Witness Signature\n}\n```\n\nAs documented in the CDDL above we define a COSE Witness ([CIP-0008]/CIP-0030\nCompatible) as well as a generic v2 Witness structure while leaving the format\nopen to future expansion.\n\n**Fields**\n\n**0: Witness Type Identifier**\n\nThe Witness Type identifier is optional for a COSE Witness and is assumed to be\na value of `0`.\n\n**1: Witness Header or Public Key Identifier**\n\nThe `1` key is used to help identify the public key in the case of a simple\nsignature witness or provides the COSE Signature Headers in the case of a COSE\nWitness (CIP-0008/CIP-0030).\n\n**2: Witness Signature Payload**\n\nThe `2` key is used to contain the actual signature payload for the witness. In\nthe case of the COSE signing this will be an array of elements used in the\nvalidation process. In the case of a simple Ed25519 key signature, this will be\na simple hex-encoded CBOR witness signature.\n\n> **Note:** COSE Signing as described in CIP-0008 uses a boolean value as the\n> second entry of the COSE Payload to indicate whether the payload was hashed\n> by the signing function before signing. Because Cardano on-chain metadata\n> does not support boolean values, this must be converted to/from a binary (0 or\n> 1\\) value when encoding or decoding the payload.\n>\n> By default, the COSE Sign1 Payload contains an entry which is an object (map)\n> containing a `hashed` key and a boolean `true/false` value. This entire object\n> should be replaced with a simple `1` or `0` value representing the\n`true/false`\n> value of the `hashed` key.\n>\n> Example:\n> `{\"hashed\": true}` becomes `1` and `{\"hashed\": false}` becomes `0`. In most\n> cases it will also be required to convert from the `1` or `0` value stored in\n> entry 2 of the COSE Sign1 Payload array back to object notation before\n> validating.\n\n## Rationale: how does this CIP achieve its goals?\n\nThis CIP was born out of a desire to allow SPOs to routinely identify themselves\nto third-party services such as: voting platforms, social media, governance\nwithout risking or compromising the keys used in the actual operation and setup\nof the stake pool.\n\nThus, the concept of an authorized \"hot key\" (the Calidus Key) was born as a\nsolution to this authentication issue. Given that [CIP-0088] had already been\nwritten and was extensible to support this registration with minimal additional\nsupport effort, extending it was chosen in favor of other solutions.\n\n## Path to Active\n\n### Acceptance Criteria\n\nThis CIP should be considered for `Active` status once a substantial amount of\necosystem tooling supports it and SPOs as well as third-party applications have\nshown an interest in using it as a method of authentication and validation.\n\n* Ecosystem Tooling\n    * [x] Cardano Signer\n    * [x] pg_cardano\n    * [x] cardano-hw-cli support\n    * [x] Cardano Koios\n    * [ ] Blockfrost\n    * [x] CN Tools\n    * [x] SPO Scripts\n    * [x] VeriGlyph\n* Wallets\n    * [x] Eternl\n    * [x] Typhon\n* Applications\n    * [ ] CExplorer\n    * [ ] CardanoScan\n    * [ ] AdaStat\n    * [ ] PoolTool.io\n    * [x] DripDropz\n    * [x] Ekklesia\n\n### Implementation Plan\n\nThe authors of this CIP will continue to work on their own tooling and reference\nimplementations as well as reaching out to community and ecosystem partners to\ndrive adoption and usage of this standard.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0].\n\n[CIP-0088]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0088\n\n[Version 2]: CIP88_Master_v2.cddl\n\n[CIP-0008]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008\n\n[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n\n[CIP-129]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0129"
  },
  {
    "path": "CIP-0152/README.md",
    "content": "---\r\nCIP: 152\r\nTitle: Modules in UPLC\r\nStatus: Proposed\r\nCategory: Plutus\r\nAuthors:\r\n  - John Hughes <john.hughes@quviq.com>\r\nImplementors: []\r\nDiscussions:\r\n  - https://github.com/cardano-foundation/CIPs/pull/946\r\nCreated: 2024-11-12\r\nLicense: CC-BY-4.0\r\n---\r\n## Abstract\r\n\r\nCardano scripts are limited in complexity by the fact that each script\r\nmust be supplied in one transaction, whether the script is supplied in\r\nthe same transaction in which it is used, or pre-loaded onto the chain\r\nfor use as a reference script. This limits script code size, which in\r\nturn limits the use of libraries in scripts, and ultimately limits the\r\nsophistication of Cardano apps, compared to competing blockchains. The\r\nscript size limit is an aspect of Cardano that script developers\r\ncommonly complain about.\r\n\r\nThis CIP addresses this problem directly, by allowing reference inputs\r\nto supply 'modules', which can be used from other scripts (including\r\nother modules), thus allowing the code of a script to be spread across\r\nmany reference inputs. The 'main specification' requires *no* changes to\r\nUPLC, PTLC, PIR or Plinth; only a 'dependency resolution' step before\r\nscripts are run. Many variations are described for better performance,\r\nincluding some requiring changes to the CEK machine itself.\r\n\r\nHigher performance variations will be more expensive to implement; the\r\nfinal choice of variations should take implementation cost into\r\naccount, and (in some cases) may require extensive benchmarking.\r\n\r\n## Motivation: why is this CIP necessary?\r\n\r\nCardano scripts are currently subject to a fairly tight size limit,\r\nderiving from the overall limit on transaction size; even when a\r\nscript is supplied in a reference UTxO, that UTxO must itself be\r\ncreated by a single transaction, which is subject to the overall\r\ntransaction size limit. Competing blockchains suffer from no such\r\nlimit: on the Ethereum chain, for example, contracts can call one\r\nanother, and so the code executed in one transaction may come from\r\nmany different contracts, created independently on the\r\nblockchain--each subject to a contract size limit, but together\r\npotentially many times that size. This enables more sophisticated\r\ncontracts to be implemented; conversely, on Cardano, it is rather\r\nimpractical to implement higher-level abstractions as libraries,\r\nbecause doing so will likely exceed the script size limit. This is not\r\njust a theoretical problem: complaints about the script size limit are\r\ncommonly made by Cardano contract developers.\r\n\r\nThus the primary goal of this CIP is to lift the limit on the total\r\namount of code run during a script execution, by allowing part of the\r\ncode to be provided in external modules. By storing these modules on\r\nthe blockchain and providing them as reference UTxOs, it will be\r\npossible to keep transactions small even though they may invoke a large\r\nvolume of code.\r\n\r\nOnce scripts can be split into separate modules, then the question\r\nimmediately arises of whether or not the script and the modules it\r\nimports need to be in the same language. Today there are many\r\nlanguages that compile to UPLC, and run on the Cardano\r\nblockchain. Ideally it should be possible to define a useful library\r\nin any of these languages, and then use it from all of them. A\r\nsecondary goal is thus to define a module system which permits this,\r\nby supporting cross-language calls.\r\n\r\nNote that many languages targetting UPLC already support modules. In\r\nparticular, Plinth already enjoys a module system, namely the Haskell\r\nmodule system. This already enables code to be distributed across\r\nseveral modules, or put into libraries and shared. Indeed this is\r\nalready heavily used: the DJED code base distributes Plinth code\r\nacross 24 files, of which only 4 contain top-level contracts, and the\r\nothers provide supporting code of one sort or another. Thus the\r\nsoftware engineering benefits of a module system are already\r\navailable. The *disadvantage* of this approach is that all the code is\r\ncombined into one script, which can easily exceed the size limit as a\r\nresult. Indeed, the DJED code base also contains an implementation of\r\ninsertion sort in Plinth, with a comment that a quadratic algorithm is\r\nused because its code is smaller than, for example, QuickSort. There\r\nis no clearer way to indicate why the overall limit on code size must be\r\nlifted.\r\n\r\n### The Situation on Ethereum\r\n\r\nEthereum contracts are not directly comparable to Cardano scripts;\r\nthey correspond to both the *on-chain* and the *off-chain* parts of\r\nCardano contracts, so one should expect Ethereum contracts to require\r\nmore code for the same task, since in Cardano only the verifiers need\r\nto run on the chain itself. Nevertheless, it is interesting to ask\r\nwhether, and how, the need for modules has been met in the Ethereum\r\ncontext.\r\n\r\nSolidity does provide a notion of 'library', which collects a number\r\nof reusable functions together. Libraries can be 'internal' or\r\n'external'--the former are just compiled into the code of client\r\ncontracts (and so count towards its size limit), while the latter are\r\nstored separately on the blockchain.\r\n\r\nThere is a problem of trust in using code supplied by someone else:\r\nthe documentation for the `ethpm` package manager for Ethereum warns\r\nsternly\r\n\r\n**you should NEVER import a package from a registry with an unknown or\r\n  untrusted owner**\r\n\r\nIt seems there *is* only one trusted registry, and it is the one\r\nsupplied as an example by the developers of `ethpm`. In other words,\r\nwhile there is a package manager for Ethereum, it does not appear to\r\nbe in use.\r\n\r\nThis is not to say that code is never shared. On the contrary, there\r\nis an open source repo on `github` called `OpenZeppelin` which appears\r\nto be heavily used. It provides 264 Solidity files, in which 43\r\nlibraries are declared (almost all internal). It seems, thus, that\r\nlibraries are not the main way of reusing code in Solidity; rather it\r\nis by calling, or inheriting from, another contract, that code reuse\r\nprimarily occurs.\r\n\r\nA small study of 20 'verified' contracts running on the Ethereum chain\r\n(verified in the sense that their source code was provided) showed that\r\n\r\n* 55% of contracts consisted of more than one module\r\n* 40% of contracts contained more than one 'application' module\r\n* 55% of contracts imported `OpenZeppelin` modules\r\n* 10-15% of contracts imported modules from other sources\r\n* 5% of contracts were simply copies of `OpenZeppelin` contracts\r\n\r\nSome of the 'other' modules were provided to support specific\r\nprotocols; for example Layr Labs provide modules to support their\r\nEigenlayer protocol for re-staking.\r\n\r\nA sample of 20 is too small to draw very strong statistical conclusions,\r\nbut we can say that the 95% confidence interval for contracts to\r\nconsist of multiple modules is 34-74%.\r\nThus code sharing is clearly going on, and a significant number of\r\ntransactions exploit multiple modules. We may conclude that there is a\r\nsignificant demand for modules in the context of smart contracts, even\r\nif the total contract code still remains relatively small.\r\n\r\n\r\n## Specification\r\n\r\n### Adding modules to UPLC\r\n\r\nThis CIP provides the simplest possible way to split scripts across\r\nmultiple UTxOs; essentially, it allows any closed subterm to be\r\nreplaced by its hash, whereupon the term can be supplied either as a\r\nwitness in the invoking transaction, or via a [reference script](https://cips.cardano.org/cip/CIP-0033) in that\r\ntransaction. To avoid any change to the syntax of UPLC, hashes are\r\nallowed only at the top-level (so to replace a deeply nested subterm\r\nby its hash, we need to first lambda-abstract it). This also places\r\nall references to external terms in one place, where they can easily\r\nbe found and resolved. Thus we need only change the definition of a\r\n`Script`; instead of simply some code, it becomes the application of\r\ncode to zero or more arguments, given by hashes.\r\n\r\nCurrently, the definition of “script” used by the ledger is (approximately):\r\n```\r\nnewtype Script = Script ShortByteString\r\n```\r\nWe change this to:\r\n```\r\nnewtype CompleteScript = CompleteScript ShortByteString\r\n\r\nnewtype Arg = ScriptArg ScriptHash\r\n\r\ndata Script =\r\n  ScriptWithArgs { head :: CompleteScript, args :: [Arg] }\r\n\r\n-- hash of a Script, not a CompleteScript\r\ntype ScriptHash = ByteString\r\n```\r\n\r\nScripts in transactions, and on the chain, are represented in this\r\nway, with dependencies that must be supplied in a transaction using\r\nthe script. During phase 2 verification we need to resolve the\r\narguments of each script before running it:\r\n```\r\nresolveScriptDependencies\r\n  :: Map ScriptHash Script\r\n  -> Script\r\n  -> Maybe CompleteScript\r\nresolveScriptDependencies preimages = go\r\n  where\r\n    go (ScriptWithArgs head args) = do\r\n      argScripts <- traverse lookupArg args\r\n      pure $ applyScript head argScripts\r\n      where\r\n        lookupArg :: Arg -> Maybe CompleteScript\r\n        lookupArg (ScriptArg hash) = do\r\n          script <- lookup hash preimages\r\n          go script\r\n```\r\nThe `preimages` map is the usual witness map constructed by the ledger,\r\nso in order for a script hash argument to be resolved, the transaction\r\nmust provide the pre-image in the usual way. Note that arguments are\r\nmapped to a `Script`, not a `CompleteScript`, so the result of looking\r\nup a hash may contain further dependencies, which need to be resolved\r\nrecursively. A transaction must provide witnesses for *all* the\r\nrecursive dependencies of the scripts it invokes.\r\n\r\nThe only scripts that can be run are complete scripts, so the type of\r\n`runScript` changes to take a `CompleteScript` instead of a `Script`.\r\n\r\n#### Variation: Lazy Loading\r\n\r\nWith the design above, if any script hash is missing from the `preimages`,\r\nthen the entire resolution fails. As an alternative, we might replace\r\nmissing subterms by a dummy value, such as `builtin unit`, thus:\r\n```\r\nresolveScriptDependencies\r\n  :: Map ScriptHash Script\r\n  -> Script\r\n  -> CompleteScript\r\nresolveScriptDependencies preimages = go\r\n  where\r\n    go (ScriptWithArgs head args) =\r\n      applyScript head (map lookupArg args)\r\n      where\r\n        lookupArg :: Arg -> CompleteScript\r\n        lookupArg (ScriptArg hash) = do\r\n          case lookup hash preimages of\r\n\t    Nothing     -> builtin unit\r\n\t    Just script -> go script\r\n```\r\nThis would allow transactions to provide witnesses only for script\r\narguments which are actually *used* in the calls that the transaction\r\nmakes. This may sometimes lead to a significant reduction in the\r\namount of code that must be loaded; for example, imagine a spending\r\nverifier which offers a choice of two encryption methods, provided as\r\nseparate script arguments. In any call of the verifier, only one\r\nencryption method will be required, allowing the other (and all its\r\ndependencies) to be omitted from the spending transaction.\r\n\r\n#### Variation: Value Scripts\r\n\r\nThe goal of this variation is to eliminate the cost of evaluating\r\nscripts, by converting them directly to values (in linear time). Since\r\nUPLC runs on the CEK machine, this means converting them directly into\r\nthe `CekValue` type, *without* any CEK machine execution. To make this\r\npossible, the syntax of scripts is restricted so that those parts that\r\nwould be evaluated during an application to the script arguments are\r\nalready (UPLC) values. That is, script code is syntactically\r\nrestricted to explicit λ-expressions with one λ per `ScriptArg`,\r\nfollowed by a syntactic value. (Values are constants, variables,\r\nbuilt-ins, λ-abstractions, delayed terms, and SoP constructors whose\r\nfields are also values).\r\n\r\nThis means that every script must take the form\r\n`λA1.λA2....λAn.<value>`, where `n` is the number of `ScriptArg`s\r\nsupplied. Now, since variables in `CompiledCode` are de Bruijn indices\r\nthen the `n` λs can be omitted from the representation--we know how\r\nmany there must be from the number of `ScriptArg`s, and the names\r\nthemselves can be reconstructed.\r\n\r\nThere must be a dynamic check that the code of each script really is\r\nof this form, but this check can be built into deserialization, and\r\nthus need cost very little.\r\n\r\n`Script`s in this restricted form can be mapped directly into CEK\r\nvalues, without any CEK-machine evaluation steps. In pseudocode:\r\n```\r\nscriptCekValue\r\n  :: Map ScriptHash CekValue\r\n  -> Script\r\n  -> CekValue\r\nscriptCekValue scriptValues (ScriptWithArgs head args) =\r\n  cekValue (Env.fromList [case lookup h scriptValues of\r\n\t   \t\t    Just v -> v\r\n\t\t\t    Nothing -> vbuiltin unit\r\n\t   \t\t | ScriptArg h <- args])\r\n\t   (deserialize (getPlc head))\r\n\r\n```\r\nThat is, a script is turned into a value by creating a CEK machine\r\nenvironment from the values of the `ScriptArg`s, and converting the\r\nbody of the script (a syntactic value) in a CekValue in that\r\nenvironment.\r\n\r\nThis pseudocode follows the 'lazy loading' variation; an easy\r\nvariation treats not finding a script hash as an error.\r\n\r\nSyntactic values are turned into `CekValue`s by the following\r\nfunction, which is derived by simplifying `computeCek` in\r\nUntypedPlutusCore.Evaluation.Machine.Cek.Internal, and restricting it\r\nto syntactic values.\r\n```\r\ncekValue\r\n  :: Env\r\n  -> NTerm\r\n  -> CEKValue\r\ncekValue env t = case t of\r\n  Var _ varname      -> lookupVarName varName env\r\n  Constant _ val     -> VCon val\r\n  LamAbs _ name body -> VLamAbs name body env\r\n  Delay _ body       -> VDelay body env\r\n  Builtin _ bn       ->\r\n    let meaning = lookupBuiltin bn ?cekRuntime in\r\n    VBuiltin bn (Builtin () bn) meaning\r\n  Constr _ i es      ->\r\n    VConstr i (foldr ConsStack EmptyStack (map (cekValue env) es)\r\n  _                  -> error\r\n```\r\nConverting a syntactic value to a CekValue does require traversing it,\r\nbut the traversal stops at λs and delays, so will normally traverse\r\nonly the top levels of a term.\r\n\r\nFinally, if `preimages` is the `Map ScriptHash Script` constructed from\r\na transaction, then we may define\r\n```\r\nscriptValues = Map.map (scriptCekValue scriptValues) preimages\r\n```\r\nto compute the CekValue of each script.\r\n\r\nScripts are then applied to their arguments by building an initial CEK\r\nmachine configuration applying the script value to its argument value.\r\n\r\n\r\n\r\nNote that this recursive definition of `scriptValues` could potentially allow an\r\nattacker to cause a black-hole exception in the transaction validator,\r\nby submitting a transaction containing scripts with a dependency\r\ncycle. However, since scripts are referred to by hashes, then\r\nconstructing such a transaction would require an attack on the hash\r\nfunction itself... for example a script hash `h` and values for `head`\r\nand `args` such that\r\n```\r\nh = hash (Script head (h:args))\r\n```\r\nWe assume that finding such an `h` is impossible in practice; should\r\nthis not be the case, or if we should wish to defend against an\r\nattacker with the resources to find such an attack on the hash\r\nfunction, then we must build a script dependency graph for each\r\ntransaction and check that it is acyclic before evaluating the scripts\r\nin this way.\r\n\r\n##### Cost\r\n\r\nConverting `Script`s to `CekValue`s does require a traversal of all\r\n`Script`s, and the top level of each `Script` value. This is linear\r\ntime in the total size of the scripts, though, and should be\r\nconsiderably faster than doing the same evaluation using CEK machine\r\ntransitions. The conversion can be done *once* for a whole\r\ntransaction, sharing the cost between several scripts if they share\r\nmodules (such as frequently used libraries). So costs should be\r\ncharged *for the whole transaction*, not per script. The most accurate\r\ncost would be proportional to the total size of values at the\r\ntop-level of scripts. A simpler approach would be to charge a cost\r\nproportional to the aggregated size of all scripts, including\r\nreference scripts--although this risks penalizing complex scripts with\r\na simple API.\r\n\r\n##### Implementation concerns\r\nThe CEK implementation does not, today, expose an API for starting\r\nevaluation from a given configuration, or constructing `CekValue`s\r\ndirectly, so this variation does involve significant changes to the\r\nCEK machine itself.\r\n\r\n##### Subvariation: Module-level recursion\r\n\r\nMany modules define recursive functions at the top-level. In this\r\nvariation, the innermost body of a script is further restricted to the\r\nform `λSelf.<value>`, and `resolveScriptDependencies` applies an\r\nimplicit `fix` to the script body, after supplying the script\r\narguments.  Like the other λs binding script arguments, the `λSelf.`\r\nneed not appear in the actual representation; we know it has to be\r\nthere so we can just store the body of the `λ`. When a script is\r\nevaluated, the value of the script is just added to the environment in\r\nthe same way as the script arguments. The script can then refer to\r\nits own value using `Self`.\r\n\r\n#### Variation: Explicit lambdas\r\n\r\nThis variation is a less-restrictive version of 'value scripts'. As in\r\nthe former case, we restrict scripts syntactically to explicit\r\nλ-expressions binding the script arguments, but we do not restrict the\r\nscript body proper to be a syntactic value. As in the former case, the\r\nλs need not be present in the `Script` representation, because their\r\nnumber is known from the number of script arguments, and the bound\r\nvariables are deBruijn indices.\r\n\r\nIn this variation, script bodies cannot be converted to `CekValue`s\r\nusing `cekValue`; we actually have to run the CEK machine to evaluate\r\nthem. This requires extending the API of the CEK machine, to support\r\nevaluating a UPLC term *in a given environment*, and returning a\r\n`CekValue`, rather than a discharged `NTerm`, because discharging a\r\n`CekValue` loses sharing. Losing sharing is unacceptable because it\r\nintroduces a potentially exponential space cost for acyclic\r\nstructures, and leads to non-termination in the case of cyclic\r\nstructures (created by 'Module-level recursion').\r\n\r\nThe implementation of the CEK machine currently always discharges\r\nvalues before returning them; the core loop of the machine will need\r\nto be modified to change this.\r\n\r\nSince script bodies must be evaluated by running the CEK machine, then\r\nit is possible to exceed the execution unit budget at any point during\r\nthe script evaluation. The budget must be checked during these\r\nevaluations, and the budget for evaluating each script will depend on\r\nthe actual costs of evaluating all the previous ones.\r\n\r\nTo avoid circular dependencies, the scripts must be topologically\r\nsorted before evaluation, so that no earlier script depends on a later\r\none. Topological sorting is linear time in the total number of scripts\r\nand script arguments.\r\n\r\nIt is still possible to write a recursive definition of the\r\n`scriptValues`, so that each script can depend on the *same* map, but\r\ncare is needed to avoid circular dependencies for the reasons\r\nexplained above.\r\n\r\n#### A Note on Tuples\r\n\r\nThe following variations make heavy use of tuples which in practice\r\ncould grow quite large--tuples of modules, and modules as tuples of\r\nexports. These variations only make sense if projection of a component\r\nfrom a tuple is *efficient*, and in particular, constant time,\r\nindependent of the tuple size. At present, tuples are represented\r\nusing the SoP extension (CIP-85) as `constr 0 x1...xn`, but the only\r\nway to select the `i`th component is using\r\n```\r\n  case t of (constr 0 x1...xi...xn) -> xi\r\n```\r\nwhich takes time linear in the size of the tuple to execute, because\r\nall `n` components need to be extracted from the tuple and passed to\r\nthe case branch (represented by a function).\r\n\r\nWe assume below that there is an expression `proj i t` in UPLC, where\r\n`i` is a constant, which efficiently extracts the `i`th component from\r\ntuple `t`. There are several ways this could be implemented:\r\n\r\n* `proj i t` could be added as a new construct to UPLC, together with\r\n  extensions to the CEK machine to evaluate it.\r\n* `proj` could be added as a new built-in to UPLC--probably a smaller\r\n  change to the implementation, but less efficient (because `i` would\r\n  be an argument needing evaluation, rather than a constant integer in\r\n  the AST), and problematic to add to TPLC (because typing it requires\r\n  dependent types).\r\n* represent 'tuples' in this context as functions from indices to\r\n  components, so `(x,y,z)` would be represented as\r\n  ```\r\n  λi. case i of 0 -> x\r\n      \t     \t1 -> y\r\n\t\t2 -> z\r\n  ```\r\n  This requires support in UPLC for pattern-matching on integers in\r\n  constant time, which is not implemented right now, but is on the\r\n  horizon. It would also need dependent types to be typed, and so\r\n  cannot be added to Plinth, PIR or PTLC.\r\n\r\nIn the sections below we just use tuples and the notation `proj i t`,\r\non the assumption that an implementation is chosen and deployed.\r\n\r\n#### Variation: Tuples of modules\r\n\r\nIn the main specification in this CIP, script code is a curried\r\nfunction of the script arguments; that is, imported modules are\r\nsupplied to scripts as individual arguments. In this variation, the\r\nscript code is instead an *uncurried* function of the script\r\narguments, which are tupled together to be passed to the script code.\r\n\r\nThis variation only makes sense if the 'value scripts' variation is\r\nalso adopted, and places an additional syntactic restriction on script\r\ncode: it must be of the form `λMods.e`, and all occurrences of `Mods`\r\nin `e` must be of the form `proj i Mods` for some `i`. That is, it is\r\nimpossible to refer to the whole tuple of modules; scripts can refer\r\nto only one module at a time.\r\n\r\nTo avoid additional overheads for scripts without arguments, we\r\nredefine the `Script` type as follows:\r\n```\r\ndata Script =\r\n    CompleteScript CompleteScript\r\n  | ScriptWithArgs { head :: CompleteScript, args :: [Arg] }\r\n```\r\nHere the `CompleteScript` alternative is used for scripts without\r\nscript arguments; such scripts are not applied to a tuple of modules\r\nbefore use, and so need not be of the form `λMods.e`. (This is only\r\nneeded because a 'function of zero arguments' has no overhead, while a\r\nfunction of a zero-tuple does).\r\n\r\n##### Subvariation: Global module environment\r\n\r\nIn the 'tuples of modules' variation, each script is paremeterised on\r\na tuple of modules, and fetches the modules when needed by projecting\r\nout a component of the tuple. In the 'global module environment'\r\nsubvariation, *all* the modules are placed in *one* tuple, from which\r\nscripts fetch the modules they need.\r\n\r\nThe global module environment is constructed for the transaction as a\r\nwhole, containing all the scripts provided by the transaction. It\r\nfollows that the *same* module may end up in *different* components in\r\ndifferent transactions. Scripts refer to other modules via references\r\nof the form `proj i Mods`, where `Mods` is the variable bound to the\r\ntuple of modules. Before scripts are run, these references must be\r\nreplaced by `proj j Mods`, where `j` is the index of the corresponding\r\nmodule in the global module environment. Thus it is necessary to\r\ntraverse the code of all the scripts, relocating module references to\r\nrefer to the global module environment instead. One this is done, then all\r\nthe script values can refer to the *same* tuple of modules.\r\n\r\n###### Subsubvariation: Module environment built into the CEK machine\r\n\r\nIn this subsubvariation, the (single) tuple of modules is passed (as a\r\nnew implicit parameter) directly to the CEK machine, instead of being\r\npassed as a parameter in UPLC. Consequently it cannot be accessed as a\r\nUPLC variable; new UPLC constructs are needed instead. Since\r\nreferences to the global tuple of modules always refer to a\r\n*particular* module, then it suffices to add a construct of the form\r\n```\r\ndata Term name uni fun ann = ..  | ModuleRef Int\r\n```\r\nsuch that `ModuleRef i` evaluates to the `i`th component of the global\r\nmodule tuple.\r\n\r\nOnce again, the scripts provided in a transaction must refer to script\r\narguments using an index into *the script's own* script arguments;\r\nbefore execution these indices must be replaced by the corresponding\r\nindices in the global module environment, necessitating a traversal of\r\nthe script code to prepare it for execution.\r\n\r\n##### Subvariation: Unboxed modules\r\n\r\nIn this subvariation, we distinguish between validation scripts and\r\nscripts representing modules; the latter are subject to an additional\r\nsyntactic restriction that the script body must be a tuple. We change\r\nthe `Script` type accordingly\r\n```\r\ndata Script = ValidatorScript         CompiledCode [ScriptArg]\r\n            | ModuleScript            CompiledCode [ScriptArg]\r\n```\r\nso that the deserializer can easily check the new syntactic\r\nrestriction. `Script`s used as `ScriptArg`s may only be of the\r\n`ModuleScript` form (this requires a dynamic check). The idea is that\r\na module provides a number of exports, which are the components of the\r\ntuple. (Again, special cases for an empty list of script arguments\r\ncan be included in this type if desired).\r\n\r\nIn addition, expressions `M` referring to modules (of the form `proj j\r\nMods`) may only appear in contexts of the form `proj i M`, projecting\r\nout one of the module exports. We call these terms 'export\r\nreferences'.\r\n\r\nWith this restriction, a tuple of modules is now a tuple of tuples,\r\nand the effect of the subvariation is to flatten that into a tuple of\r\nexports instead. Every module export is assigned an index in the\r\nresulting tuple, and the scripts must be preprocessed before execution\r\nto replace the indexes in every export reference by the corresponding\r\nindex in the tuple--so `proj i (proj j Mods)` becomes `proj k Mods`\r\nfor `k` the index of the `i`th export of the `j`th module.\r\n\r\nIn the case of modules which are omitted from the transaction (see\r\n'lazy loading'), the export references `proj i (proj j Mods)` should\r\nbe replaced by `builtin unit`. This is either the correct value, or\r\nwill cause a run-time type error (and thus verification failure) if\r\nthe value is used.\r\n\r\nIn the case of a global module environment, then since the placement\r\nof modules in a global tuple depends on *all* the modules used in a\r\ntransaction, and since some of the scripts used by a transaction are\r\ntaken from pre-existing reference UTxOs, then this preprocessing\r\ncannot be done in advance; it must be done during script verification\r\nof the transaction.  This subvariation can be combined with 'module\r\nenvironment built into the CEK machine', in which case the export\r\nreferences are replaced by suitable `ModuleRef k` expressions as\r\nbefore.  It does not change the `CompiledCode` stored in scripts; it\r\nonly affects the way that code is prepared for execution.\r\n\r\nIf the module environment is *local* for each script, then the\r\npreprocessing can be done at *compile-time*--and scripts on the chain\r\ncan be stored as functions of one big tuple, containing all the\r\nexports from modules imported into the script. There is a subtlety in\r\nthe case of lazy loading: `resolveScriptDependencies` becomes\r\nresponsible for creating a tuple with one entry per export, *even for\r\nmodules which are not provided in the transaction*. For this to be\r\npossible, `resolveScriptDependencies` needs to know *how many* exports\r\nthe imported module has, even without access to its body. To make this\r\npossible we can extend the `ScriptArg` type:\r\n```\r\ndata ScriptArg = ScriptArg ScriptHash Int\r\n```\r\nIn the case of a module which *is* supplied, there should be a dynamic\r\ncheck that the number of components agrees with the `ScriptArg`; in\r\nthe case of a module which is not supplied in the transaction,\r\n`resolveScriptDependencies` should just add this number of `builtin\r\nunit`s to the tuple passed to the script. Note that an attacker could\r\nforce the transaction verifier to allocate a very large amount of\r\nmemory by supplying a very large integer here, in a transaction that\r\ndoes not include the module itself--and so might be cheap. To prevent\r\nthis, transaction fees must take the *values* of these integers into\r\naccount; it may also be sensible to place an absolute upper limit on\r\nthe number of exports from a module.\r\n\r\n##### Script traversal costs\r\n\r\nThe last two subvariations above both require a traversal of all the\r\nscript code in a transaction (including the code fetched from\r\nreference scripts) to adjust module or export references. If they are\r\nadopted, transaction fees should be increased by an amount linear in\r\nthe total script size to pay for this traversal.\r\n\r\n### Modules in TPLC\r\n\r\nNo change is needed in TPLC.\r\n\r\n### Modules in PIR\r\n\r\nNo change is needed in PIR.\r\n\r\n### Modules in Plinth\r\n\r\nThe Plinth modules introduced in this CIP bear no relation to Haskell\r\nmodules; their purpose is simply to support the module mechanism added\r\nto UPLC. They are first-class values in Haskell.\r\n\r\nJust as we introduced a distinction in UPLC between `CompleteScript`\r\nand `Script`, so we introduce a distinction in Plinth between\r\n`CompiledCode a` (returned by the Plinth compiler when compiling a\r\nterm of type `a`), and `Module a` representing a top-level `Script`\r\nwith a value of type `a`.\r\n```\r\nnewtype Module a = Module {unModule :: Mod}\r\n\r\nnewtype ModArg = ModArg ScriptHash\r\n\r\ndata Mod = forall b. Mod{ modCode :: Maybe (CompiledCode b),\r\n     \t   \t     \t  modArgs :: Maybe ([ModArg]),\r\n\t\t\t  modHash :: ScriptHash }\r\n```\r\n\r\nHere the `modArgs` correspond to the `ScriptArg`s in the UPLC case,\r\nand the `modHash` is the hash of the underlying `Script`.  The type\r\nparameter of `Module a` is a phantom parameter, just like the type\r\nparameter of `CompiledCode a`, which tells us the type of value which\r\nthe application of the `modCode` to the `modArgs` represents.\r\n\r\nWe can convert any `ScriptHash` into a module:\r\n```\r\nfromScriptHash :: ScriptHash -> Module a\r\nfromScriptHash hash = Module Nothing Nothing hash\r\n```\r\nand we can convert any `CompiledCode` into a module:\r\n```\r\nmakeModule :: CompiledCode a -> Module a\r\nmakeModule code = Module (Just (Mod code)) (Just []) ...compute the script hash...\r\n```\r\n\r\nWe also need a way to supply an imported module to a `Module`:\r\n```\r\napplyModule :: Module (a->b) -> Module a -> Module b\r\napplyModule (Module (Mod (Just code) (Just args) _)) m =\r\n  Module (Mod (Just code) (Just (args++[modHash m])) ...compute the script hash...)\r\n```\r\nAs in UPLC, the intention is that scripts that import modules be\r\nwritten as lambda-expressions, and the imported module is then\r\nsupplied using `applyModule`. No change is needed in the Plinth\r\ncompiler to support this mechanism.\r\n\r\nNote that only a `Module` containing code and an argument list can\r\nhave the argument list extended by `applyModule`; this is because the\r\n`ScriptHash` of the result depends on the code and the entire list of\r\narguments, so it cannot be computed for a module that lacks either of\r\nthese.\r\n\r\nIt is `Module` values that would then be serialised to produce scripts\r\nfor inclusion in transactions.\r\n\r\nIn the 'unboxed modules' variation we need to distinguish two kinds of\r\nscripts, scripts which define modules, and scripts which define\r\nvalidators. In Plinth, this distinction can be made in the types, by\r\nturning the `Module` type into a GADT with an extra parameter, of type\r\n```\r\ndata ScriptType = ModuleScript | ValidatorScript\r\n```\r\n`applyModule` would be given a more restrictive type:\r\n```\r\napplyModule :: Module s (a->b) -> Module ModuleScript a -> Module s b\r\n```\r\nthus ensuring that only scripts representing modules are passed as\r\nscript arguments.\r\n\r\n### Plutus Ledger Language Versions\r\n\r\nPlutus ledger language version is what \"Plutus V1\", \"Plutus V2\", \"Plutus V3\" refer to.\r\nThese are not distinct programming languages; the primary difference lies in the arguments the script receives from the ledger, and the value it returns[^1].\r\nPlutus V1, V2 and V3 can therefore be understood as type signatures, in the sense that they each represent a subset of UPLC programs with specific types. Any UPLC program that matches the expected argument and return types can be considered and used as a Plutus V1, V2 or V3 script.\r\nA new ledger era is the primary reason for introducing a new ledger language version, though technically there can be cases where a new ledger language version is necessary without a new ledger era.\r\n\r\nCurrently each script on-chain is tagged with a specific ledger language version - V1, V2, V3 or native script - and this version tag is a component of the script hash.\r\nA logical approach, therefore, is to continue doing so for module scripts, and require that a validator script and all modules it references must use the same ledger language version; failure to do so leads to a phase-1 error.\r\n\r\nA different approach is to distinguish between validator scripts and module scripts by applying version tags only to validator scripts.\r\nModule scripts are untagged and can be linked to any validator script.\r\nThis makes module scripts more reusable, which is advantageous because in most cases, a UPLC program has the same semantics regardless of the ledger language version.\r\n\r\nThis is, however, not always the case because a few builtin functions have multiple semantic variants, and the variant used may differ depending on the ledger language version.\r\nNonetheless, if a module script depends on a particular ledger language version to work correctly, this requirement can be communicated through alternative means, e.g., as a piece of metadata in a module script registry.\r\n\r\nAnother drawback of untagged modules is that untagged modules will be a new concept that doesn't currently exist, and as a result, modules will not be usable in Plutus V1 through V3, and can only be used from Plutus V4 onwards.\r\n\r\n### Plutus Core Versions\r\n\r\nPlutus Core version is the usual sense of version pertaining to programming languages - in this instance the Plutus Core language.\r\nSo far there have been two Plutus Core versions: 1.0.0 and 1.1.0. 1.1.0 adds sums-of-products to the language by introducing two new AST node types: Case and Constr.\r\nSee [CIP-85](https://cips.cardano.org/cip/CIP-0085) for more details.\r\nEach UPLC program is tagged with a Plutus Core version (where as for ledger language versions, only _scripts_ that exist on-chain, i.e., stored in UTXOs, are tagged with ledger language versions).\r\n\r\nUPLC programs with different Plutus Core versions are incompatible and cannot be combined, and therefore, a validator script and all modules it references must share the same Plutus Core version; otherwise it is a phase-1 error.\r\n\r\n### Implementation and Integration Considerations\r\n\r\nHere we use the term \"script\" to refer to either a validator script (which needs to be run to validate a transaction) and a module script (which serves as a dependency for other scripts).\r\nBoth validators and modules can reference other modules.\r\n\r\nThe feature proposed in this CIP can only be released in a new ledger era.\r\nAs such, it is anticipated that it will be released alongside the next ledger era - the Dijkstra era.\r\n\r\nWhether this feature can be used in existing Plutus ledger language versions (V1 through V3) depends on which of the options described in subsection _Plutus Ledger Language Versions_ (i.e., tagged or untagged modules) is chosen.\r\nIf tagged modules are adopted, the feature will be available across all Plutus language versions (V1 through V4) starting at the hard fork that introduces the Dijkstra era.\r\nIf untagged modules are adopted, it will only be usable in Plutus V4, as explained in the subsection.\r\n\r\nThe bulk of the implementation effort lies on the Plutus side, including updates to `plutus-ledger-api`, updates to the CEK machine, costing and benchmarking, among others.\r\nThe specifics will depend on which of the various alternatives outlined in this CIP is selected.\r\nThe Plutus team aims to complete the implementation of the selected approach according to its specification, in time for the Dijkstra era.\r\n\r\nOn the ledger and cardano-api side, the effort required to support this feature is not as substantial as it may appear to be.\r\nThis is because the ledger already supports reference inputs and reference scripts since the Babbage era, and this existing mechanism can largely be reused to accommodate module scripts.\r\nThe processes of storing a module script in a UTXO and using it in a transaction are similar to storing and using a reference script.\r\n\r\nThe main difference between reference scripts and module scripts is that a module script is, like an object file, not directly runnable but must be linked with a validator to form a runnable script.\r\nTo support this, the ledger and cardano-api will need to implement some changes.\r\nThe specifics will slightly vary depending on which of the alternative approaches is chosen, but it will generally involve the following.\r\n\r\nCurrently, deserialising a script returns a `ScriptForEvaluation`, which contains a deserialised script, along with the original serialised script. The ledger has a `PlutusRunnable` newtype that wraps `ScriptForEvaluation`.\r\nWith the introduction of modules, deserialising a script no longer produces a runnable script unless it is a self-contained validator that doesn't use modules.\r\nOtherwise, the module hashes it references must be resolved and the modules linked before the validator can be executed.\r\n\r\nTo do so, the `plutus-ledger-api` package can implement one of two options, depending on which is more suitable for the ledger:\r\n- Script deserialisation will be modified to return a new data type, `ScriptForLinking`.\r\n  It is similar to `ScriptForEvaluation` except that the deserialized script is not necessarily a self-contained script and may be accompanied by a list of module hashes it needs.\r\n\r\n  Then, a function `linkValidator :: Map ScriptHash ScriptForLinking -> ScriptHash -> LinkedScript` is provided that performs linking for a particular validator identified by `ScriptHash`, where `LinkedScript ~ UPLC.Program DeBruijn DefaultUni DefaultFun ()` is a fully linked script.\r\n- Alternatively, the following function can be provided: `linkScripts :: Map ScriptHash SerialisedScript -> Map ScriptHash LinkedScript`, which performs deserialisation and linking for all (validator and module) scripts in one go.\r\n\r\nIn either case, the ledger should ensure that each script (including validator script and module script) is deserialised and processed no more than once.\r\n\r\nMoreover, for the transaction builder to decide which modules a validator refers to are used at runtime, `plutus-ledger-api` will also expose the following function:\r\n\r\n```haskell\r\ngetUsedModules ::\r\n  MajorProtocolVersion ->\r\n  EvaluationContext ->\r\n  -- | All scripts provided in a transaction\r\n  Map ScriptHash SerialisedScript ->\r\n  -- | Hash of the validator\r\n  ScriptHash ->\r\n  -- | Script arguments\r\n  [Data] ->\r\n  -- | Hashes of used module scripts\r\n  Set ScriptHash\r\n```\r\n\r\nThe value type of the `Map` could instead be `ScriptForLinking` (i.e., deserialised script) rather than `SerialisedScript`.\r\n\r\nThis function is to be called by the code building transactions (e.g., `Cardano.Api.Fees.makeTransactionBodyAutoBalance`) to determine which modules are necessary to include in a transaction.\r\n\r\n## Rationale: how does this CIP achieve its goals?\r\n\r\nThis CIP provides a minimal mechanism to split scripts across several\r\ntransactions. 'Imported' modules are provided in the calling\r\ntransaction and passed as arguments to the top-level script, and their\r\nidentity is checked using their hash. In the main specification, the\r\nrepresentation of modules is left entirely up to compiler-writers to\r\nchoose--a module may be any value at all (although some of the\r\nvariations do restrict the form). For example, one compiler might\r\nchoose to represent modules as a tuple of functions, while another\r\nmight map function names to tags, as Solidity does, and represent a\r\nmodule as a function from tags to functions. Each language will need\r\nto define its own conventions for module representations, and\r\nimplement them on top of this low-level mechanism. For example, a\r\ntyped language might represent a module as a tuple of exported values,\r\nand store the names and types of the values in an (off-chain)\r\ninterface file. Clients could use the interface file to refer to\r\nexported values by name, and to perform type-checking across module\r\nboundaries.\r\n\r\n### Recursive modules\r\n\r\nThis design does not support mutually recursive modules. Module\r\nrecursion is sometimes used in languages such as Haskell, but it is a\r\nrarely-used feature that will not be much missed.\r\n\r\n### Cross-language calls\r\n\r\nThere is no a priori reason why script arguments need be written in\r\nthe same high-level language as the script itself; thus this CIP\r\nsupports cross-language calls. However, since different languages may\r\nadopt different conventions for how modules are represented, then some\r\n'glue code' is likely to be needed for modules in different languages\r\nto work together. In the longer term, it might be worthwhile defining\r\nan IDL (Interface Definition Language) for UPLC, to generate this glue\r\ncode, and enable scripts to call code in other languages more\r\nseamlessly. This is beyond the scope of this CIP; however this basic\r\nmechanism will not constrain the design of such an IDL in the future.\r\n\r\nIn Plinth, because the `Module` type is a phantom type, it is easy to\r\ntake code from elsewhere and turn it into a `Module t` for arbitrary\r\nchoice of `t`; this can be used to import modules compiled from other\r\nlanguages into Plinth (provided a sensible Plinth type can be given to\r\nthem).\r\n\r\n\r\n### Static vs Dynamic Linking\r\n\r\nWith the introduction of modules, scripts are no longer\r\nself-contained--they may depend on imported modules. This applies both\r\nto scripts for direct use, such as spending verifiers, and to scripts\r\nrepresenting modules stored on the chain.  A module may depend on\r\nimported modules, and so on transitively. An important question is\r\nwhen the identity of those modules is decided. In particular, if a\r\nmodule is replaced by a new version, perhaps fixing a bug, can\r\n*existing* code on the chain use the new version instead of the old?\r\n\r\nThe design in this CIP supports both alternatives. Suppose a module\r\n`A` imports modules `B` and `C`. Then module `A` will be represented\r\nas the lambda-expression `λB.λC.A`. This can be compiled into a\r\n`CompleteScript` and placed on the chain, with an empty list of\r\n`ScriptArg`s, as a reference script in a UTxO, allowing it to be used\r\nwith any implementations of `B` and `C`--the calling script must pass\r\nimplementations of `B` and `C` to the lambda expression, and can\r\nchoose them freely. We call this 'dynamic linking', because the\r\nimplementation of dependencies may vary from use to use. On the other\r\nhand, if we want to *fix* the versions of `B` and `C` then we can\r\ncreate a `Script` that applies the same `CompleteScript` to two\r\n`ScriptArg`s, containing the hashes of the intended versions of `B`\r\nand `C`, which will then be supplied by\r\n`resolveScriptDependencies`. We call this 'static linking', because\r\nthe version choice for the dependency is fixed by the script. It is up\r\nto script developers (or compiler writers) to decide between static\r\nand dynamic linking in this sense.\r\n\r\nOn the other hand, when a script is used directly as a validator then\r\nthere is no opportunity to supply additional arguments; all modules\r\nused must be supplied as `ScriptArg`s, which means they are\r\nfixed. This makes sense: it would be perverse if a transaction trying\r\nto spend a UTxO protected by a spending validator were allowed to\r\nreplace some of the validation code--that would open a real can of\r\nworms, permitting many attacks whenever a script was split over\r\nseveral modules. With the design in the CIP, it is the script in the\r\nUTxO being spent that determines the module versions to be used, not\r\nthe spending transaction. That transaction does need to *supply* all\r\nthe modules actually used--including all of their dependencies--but it\r\ncannot choose to supply alternative implementations of them.\r\n\r\n### In-service upgrade\r\n\r\nLong-lived contracts may need upgrades and bug fixes during their\r\nlifetimes. This is especially true of contracts made up of many\r\nmodules--every time a dependency is upgraded or receives a bug fix,\r\nthe question of whether or not to upgrade the client contract\r\narises. However, the problem of upgrading contracts *securely* is a\r\ntricky one, and exists whether or not modules are used. Therefore this\r\nCIP does not address this problem specifically: developers should use\r\nthe same mechanisms to handle upgrades of scripts with dependencies,\r\nas they use to upgrade scripts without dependencies. The only thing we\r\nnote here is that the need for upgrades is more likely to arise when a\r\nscript depends on many others, so it is more important to be prepared\r\nfor it. Note that, because a script contains the hashes of its\r\ndependencies, no 'silent' upgrade can occur: the hash of a script\r\ndepends on *all* of its code, including the code of its dependencies,\r\nso any change in a dependency will lead to a change in the script\r\nhash.\r\n\r\n### Lazy loading\r\n\r\nThe 'lazy loading' variation in the specification section above\r\npermits fewer modules to be supplied in a transaction.  Dependency\r\ntrees have a tendency to grow very large; when one function in a\r\nmodule uses another module, it becomes a dependency of the entire\r\nmodule and not just of that function. It is easy to imagine situations\r\nin which a script depends on many modules, but a particular call\r\nrequires only a few of them. For example, if a script offers a choice\r\nof protocols for redemption, only one of which is used in a particular\r\ncall, then many modules may not actually be needed. The variation\r\nallows a transaction to omit the unused modules in such cases. This\r\nreduces the size of the transaction, which need provide fewer\r\nwitnesses, but more importantly it reduces the amount of code which\r\nmust be loaded from reference UTxOs.\r\n\r\nIf a script execution *does* try to use a module which was not\r\nprovided, it will encounter a run-time type error and fail (unless the\r\nmodule value was `builtin unit`, in which case the script will behave\r\nas though the module had been provided).\r\n\r\nTo take advantage of this variation, it is necessary, when a\r\ntransaction is constructed, to *observe* which script arguments are\r\nactually used by the script invocations needed to validate the\r\ntransaction. The transaction balancer runs the scripts anyway, and so\r\ncan in principle observe the uses of script arguments, and include\r\nwitnesses in the transaction for just those arguments that are used.\r\n\r\n#### Balancer modifications\r\n\r\nTo take advantage of 'lazy loading', it's necessary to identify\r\nreference scripts that are *dynamically* unused, when the scripts in a\r\ntransaction run. The best place to do that is in a transaction\r\nbalancer, which needs to run the scripts anyway, both to check that\r\nscript validation succeeds, and to determine the number of execution\r\nunits needed to run the scripts. We adopt the view that\r\n\r\n**A transaction balancer may drop reference inputs from a\r\n   transaction, if the resulting transaction still validates**\r\n\r\nWe call reference scripts which are not actually invoked during script\r\nverification 'redundant'; these are the reference scripts that can be\r\nremoved by the balancer.\r\n\r\n##### First approach: search\r\n\r\nThe simplest way for a balancer to identify redundant reference inputs\r\nis to try rerunning the scripts with an input removed. If script\r\nvalidation still succeeds, then that input may safely be removed. The\r\nadvantages of this approach are its simplicity, and lack of a need for\r\nchanges anywhere else in the code. The disadvantage is that\r\ntransaction balancing may become much more expensive--quadratic in the\r\nnumber of scripts, in the worst case.\r\n\r\nThe reason for this is that removing one script may make others\r\nredundant too; for example if script A depends on script B, then\r\nscript B may become redundant only after script A has been\r\nremoved--simply evaluating script A may use the value of B, and\r\nscripts are evaluated when they are passed to other scripts, whether\r\nthey are redundant or not. So if the balancer tries to remove B first,\r\nthen script verification will fail--and so the balancer must try again\r\nto remove B after A has been shown to be redundant. Unless we exploit\r\ninformation on script dependencies, after one successful script\r\nremoval then all the others must be revisited. Hence a quadratic\r\ncomplexity.\r\n\r\nIn the case of 'value scripts' this argument does not apply:\r\nevaluating a script will never fail just because a different script is not\r\npresent. In this case it would be sufficient to traverse all the\r\nscripts once, resulting in a linear number of transaction\r\nverifications.\r\n\r\n##### Second approach: garbage collection\r\n\r\nFirst the balancer analyses all the scripts and reference scripts in a\r\ntransaction, and builds a script dependency dag (where a script\r\ndepends on its `ScriptArg`s). Call the scripts which are invoked\r\ndirectly in the transaction (as validators of one sort or another) the\r\n*root* scripts.\r\n\r\nTopologically sort the scripts according to the dependency relation;\r\nscripts may depend on scripts later in the order, but not\r\nearlier. Now, traverse the topologically sorted scripts in order. This\r\nguarantees that removing a *later* script in the order does not cause\r\nan *earlier* one to become redundant.\r\n\r\nFor each script, construct a modified dependency graph by removing the\r\nscript concerned, and then 'garbage collecting'... removing all the\r\nscripts that are no longer reachable from a root. Construct a transaction\r\nincluding only the reference scripts remaining in the graph, and run\r\nscript validation. If validation fails, restore the dependency graph\r\nbefore the modification. If validation succeeds, the script considered\r\nand all the 'garbage' scripts are redundant; continue using the now\r\nsmaller dependency graph.\r\n\r\nWhen all scripts have been considered in this way, then the remaining\r\ndependency graph contains all the scripts which are dynamically needed\r\nin this transaction. These are the ones that should be included in the\r\ntransaction, either directly or as reference scripts.\r\n\r\nThe advantage of this approach is that only the code in the balancer\r\nneeds to be changed. The disadvantage is that transaction balancing\r\nbecomes more expensive: script verification may need to be rerun up to\r\nonce per script or reference script. In comparison to the first\r\napproach above, this one is more complex to implement, but replaces a\r\nquadratic algorithm by a linear one.\r\n\r\n##### Third approach: modified CEK machine\r\n\r\nThe most direct way to determine that a script is not redundant is to\r\nobserve it being executed during script verification. Unfortunately,\r\nthe CEK machine, in its present form, does not make that\r\npossible. Thus an alternative is to *modify the CEK machine* so that a\r\nbalancer can observe scripts being executed, and declare all the other\r\nscripts redundant. In comparison to the first two approaches, this is\r\nlikely to be much more efficient, because it only requires running\r\nscript verification once.\r\n\r\nThe modifications needed to the CEK machine are as follows:\r\n\r\n`CekValue`s are extended with *tagged values*, whose use can be\r\nobserved in the result of a run of the machine.\r\n```\r\ndata CekValue uni fun ann =\r\n  ...\r\n  | VTag ScriptHash (CekValue uni fun ann)\r\n```\r\nIn the 'value script' variation, no expression resulting in a `VTag`\r\nvalue is needed, because `VTag`s will be inserted only by\r\n`resolveScriptDependencies`. In other variations, a `Tag` constructor\r\nmust also be added to the `NTerm` type, to be added by\r\n`resolveScriptDependencies`. In either case the version of\r\n`runScriptDependencies` *used in the balancer* tags each value or\r\nsubterm derived from a `ScriptHash` `h` as `VTag h ...` (or `Tag h\r\n...` in variations other than 'value scripts').\r\n\r\nThe CEK machine is parameterized over an emitter function, used for\r\nlogging. We can make use of this to emit `ScriptHash`es as they are\r\nused. This allows the balancer to observe which `ScriptHash`es *were*\r\nused.\r\n\r\nSimply evaluating a tagged value, or building it into a\r\ndata-structure, does not *use* it in the sense we mean here: replacing\r\nsuch a value with `builtin unit` will not cause a validation\r\nfailure. Only when such a value is actually *used* should we strip the\r\ntag, emit the `ScriptHash` in the `CekM` monad, and continue with the\r\nuntagged value. This should be done in `returnCek`, on encountering a\r\n`FrameCases` context for a tagged value, and in `applyEvaluate` when\r\nthe function to be applied turns out to be tagged, or when the\r\nargument to a `builtin` turns out to be tagged.\r\n\r\nAdding and removing tags must be assigned a zero cost *in the\r\nbalancer*, since the intention is that they should not appear in\r\ntransactions when they are verified on the chain. Thus a zero cost is\r\nrequired for the balancer to return accurate costs for script\r\nverification on the chain. On the other hand, if these operations *do*\r\nreach the chain, then they should have a *high* cost, to deter attacks\r\nin which a large number of tagging operations are used to keep a\r\ntransaction verifier busy. This can be achieved by adding a `BTag`\r\nstep kind to the CEK machine, a `cekTagCost` to the\r\n`CekMachineCostsBase` type, and modifying the balancer to set this\r\ncost to zero during script verification.\r\n\r\nThe advantage of this approach is that it only requires running each\r\nscript once in the balancer, thus reducing the cost of balancing a\r\ntransaction, perhaps considerably. The disadvantage is that it\r\nrequires extensive modifications to the CEK machine itself, a very\r\ncritical part of the Plutus infrastructure.\r\n\r\n##### Fourth approach: lazy scripts\r\n\r\nAnother way to observe script uses *without* modifying the CEK machine\r\nis to wrap them in `Delay` and force them at the point of use. The\r\nbalancer can then insert trace output of the script hash just inside\r\nthe `Delay`, and so observe which scripts are actually forced during\r\nscript execution.\r\n\r\nThe difficulties with this approach arise from the fact that delayed\r\nclosures must be *explicitly* forced in UPLC; this does not 'just\r\nhappen' when a delayed value is used. This means that corresponding\r\n`Force` operations must also be added to scripts, and the question is:\r\nwho does this, and if it is to be done automatically, then how?\r\n\r\nOne possibility is that it is the developer's responsibility to force\r\nscript arguments at the point of use--that is, that the `Force`\r\noperations needed would be written by the human programmer. It follows\r\nthat they would *always* be part of the script, even when running on\r\nthe chain, and so even on the chain script arguments would need to be\r\ndelayed (even if no trace output would be needed). This would increase\r\ncode size a little, and impose a force-delay overhead on every\r\ncross-module reference, which is probably not acceptable.\r\n\r\nThe alternative is to have the balancer insert corresponding `Force`\r\noperations, as well as the `Delay`s. A simple way to do so would be\r\nto add a `Force` around every use of a variable corresponding to a\r\nscript argument--under the 'value scripts' syntactic restriction these\r\nvariables are easy to identify. These modifications would not be made\r\nduring normal script verification, which might therefore cost less--or\r\nmore--than the modified balancer run. The balancer would thus need to\r\nperform script verification twice: once with `Delay` and\r\n`Force`inserted to determine redundant scripts, and then a second time\r\n(with redundant scripts removed) to determine the actual cost on the\r\nchain.\r\n\r\nThe bigger problem with this approach, though, is that it will\r\n*overestimate* the set of used scripts, leading to more scripts being\r\nused in a transaction, and thus potentially exponentially more\r\nexpensive transactions. The reason for the overestimation is that\r\n*all* occurrences of variables bound to script arguments are wrapped\r\nin `Force`, even those that would not lead to untagging the\r\ncorresponding tagged value in the third approach above. For example,\r\nsuppose a variable bound to a script argument is passed as a parameter\r\nto another function. With the simple `Force`-placement strategy\r\ndescribed above, the script argument would be forced *at that call*,\r\nmaking the corresponding script appear to be used, even though the\r\nfunction it is passed to might not actually use it in all cases. Hence\r\nthe set of scripts used would be overestimated.\r\n\r\nOne might use a more sophisticated strategy to insert `Force`\r\noperations. For example, in the case described above one might pass\r\nthe script argument *unforced* to the function, and modify the\r\nfunction to force it when it is used. This would require the balancer\r\nto perform a flow analysis, to identify the functions that might be\r\npassed a delayed script argument. Moreover, such functions might be\r\ncalled *sometimes* with a delayed script argument, and sometimes\r\nnot. The code could be replicated to create two versions of such\r\nfunctions. But with *n* script arguments, this might require up to\r\n*2^n* versions of each function, leading to an exponential increase in\r\ncode size. An attacker could exploit this to craft a transaction that\r\nwould cause the balancer to run out of memory. This is really not\r\nattractive.\r\n\r\nFinally, one might finesse these problems by modifying the CEK machine\r\nto force delayed closures automatically where the value is required,\r\nthus enabling explicit `Force` operations to be omitted. This would\r\neffectively turn UPLC into a call-by-name programming language. That would\r\n\r\nenable this problem to be solved more easily, but  at the cost of\r\nreversing a rather fundamental design decision in UPLC--and probably\r\nmaking the CEK machine a little bit slower, for all programs.\r\n\r\nThus it appears that there is no good way of using UPLC's existing\r\nlazy evaluation to observe use of script arguments.\r\n\r\n### Value Scripts\r\n\r\nThis section discusses the 'value scripts' variation.\r\n\r\nThe main specification in this CIP represents a `Script` that imports\r\nmodules as compiled code applied to a list of `ScriptHash`es. To\r\nprepare such a script for running, `resolveScriptDependencies`\r\nreplaces each hash by the term it refers to, and builds nested\r\napplications of the compiled code to the arguments. These applications\r\nmust be evaluated by the CEK machine *before* the script proper begins\r\nto run. Moreover, each imported module is itself translated into such\r\na nested application, which must be evaluated before the module is\r\npassed to the client script. In a large module hierarchy this might\r\ncause a considerable overhead before the script proper began to\r\nrun. Worst of all, if a module is used *several times* in a module\r\ndependency tree, then it must be evaluated *each time* it is\r\nused. Resolving module dependencies traverses the entire dependency\r\n*tree*, which may be exponentially larger than the dependency *dag*.\r\n\r\nThe value script variation addresses this problem head on. Scripts are\r\nconverted directly into CEK-machine values that can be invoked at low\r\ncost. Each script is converted into a value only once, no matter how\r\nmany times it is referred to, saving time and memory when modules\r\nappear several times in a module hierarchy.\r\n\r\nOn the other hand it does restrict the syntactic form of\r\nscripts. Scripts are restricted to be syntactic lambda expressions,\r\nbinding their script arguments at the top-level. This is not so\r\nonerous. But inside those λs, there must also be a syntactic\r\nvalue. For example, consider a module represented by a tuple, whose\r\ncomponents represent the exports of the module. Then all of those exports\r\nneed to be syntactic values--an exported value could not be computed\r\nat run-time, for example using an API exported by another\r\nmodule. While many module exports are functions, and so naturally\r\nwritten as λ-expressions (which are values), this restriction will be\r\nonerous at times.\r\n\r\nThis method does require opening up the API of the CEK machine, so\r\nthat CEK values can be constructed in other modules, and introducing a\r\nway to run the machine starting from a given configuration. So it\r\nrequires more invasive changes to the code than the main\r\nspecification.\r\n\r\n#### `ScriptHash` allowed in terms?\r\n\r\nAn alternative design would allow UPLC terms to contain `ScriptHash`es\r\ndirectly, rather than as λ-abstracted variables, to be looked up in a\r\nglobal environment at run-time. This would address this same problem:\r\nthe cost of performing many applications before script evaluation\r\nproper begins. It would also require changes to the CEK machine, and\r\nis not really likely to perform better than the 'value scripts'\r\nvariation (in practice, the main difference is the use of a global\r\nenvironment to look up script hashes, as opposed to many per-module\r\nones). However, this approach is less flexible because it does not\r\nsupport dynamic linking (see Static vs Dynamic Linking above). Once a\r\n`ScriptHash` is embedded in a term, then a different version of the\r\nscript cannot readily be used instead. Moreover, script hashes are\r\nquite large (32 bytes), and including more than a few in a script\r\nwould quickly run into size limits.\r\n\r\n#### Module-level recursion\r\n\r\nThis section discusses the `module-level recursion` subvariation of\r\nthe `value scripts` variation.\r\n\r\nUPLC provides a fixpoint combinator, and this is how recursion is\r\ncompiled. For the sake of argument, consider the well-known fixpoint\r\ncombinator `Y` (in reality, `Y` is not suitable for use in a strict\r\nprogramming language, so the UPLC version is slightly different). We\r\ncan imagine that a recursive function `f` is compiled as `Y h`, for\r\nsome suitable `h`.\r\n\r\nThe difficulty that arises is that `Y h` *is not a value*, and thus\r\ncannot appear at the top-level of a module, under the 'value script'\r\nrestriction. It can be *normalised* into a value, of course, using\r\n```\r\nY h ---> h (Y h)\r\n```\r\nand then reducing the application of `h`; this would need to be done\r\nby a compiler generating UPLC with the `value script`\r\nrestriction. But reducing `h (Y h)` may well duplicate `Y h`. When\r\nthis happens at CEK runtime it is not a problem, because all the\r\noccurrences of `Y h` are represented by the same pointer. But when the\r\nreductions are applied by a compiler, and the resulting term is\r\nserialized to UPLC code for inclusion in a script, then each\r\noccurrence of `Y h` will be serialized separately, losing sharing and\r\ncausing code duplication in the resulting script. The result could be\r\n*larger* code, the opposite of what we are trying to achieve. Thus\r\nthis method of compiling recursion fits badly with the 'value scripts'\r\nvariation.\r\n\r\nHence module-level recursion, which allows recursive occurrences of\r\nscript values to be referred to via the `Self` variable instead of\r\nusing a fixpoint combinator implemented in UPLC. To take advantage of\r\nthis feature, the compiler will need to float occurrences of `fix`\r\nupwards, to the top-level of a module. This can be done using suitable\r\nanalogues of the rules\r\n```\r\n(..,fix (λx.e),...) ---> fix (λx.(..,e[proj i x/x],..))\r\n```\r\nwhere `i` is the index in the tuple at which `fix (λx.e)` appears,\r\n`proj i x` selects the `i`th component from `x`, and `x` does not\r\noccur free elsewhere in the tuple; a corresponding rule for\r\nconstructor applications; and\r\n```\r\nfix (λx. fix (λy.e)) ---> fix (λx. e[x/y])\r\n```\r\nBoth these rules require adjusting deBruijn numbers in the UPLC\r\nimplementation.\r\n\r\nThe intention here is to implement module-level recursion using a\r\ncyclic data-structure--the value restriction guarantees that the\r\nmodule value `Self` is not needed to compute the top-level value of\r\nthe module, and thus there is no risk of falling into an infinite loop\r\nat this point. (Of course, a recursive function can loop *when it is\r\ncalled*, but constructing the function itself cannot loop because it\r\nmust be a syntactic λ-expression). This is a *more efficient* way to\r\nimplement recursion than the fixpoint combinators currently used in\r\nUPLC, and so will probably become the preferred way to implement\r\nrecursion.\r\n\r\nNote that if we adopt value scripts, but *not* module-level recursion,\r\nthen modules will be unable to export recursive functions without\r\n'hiding' them in a value, such as a `Delay`.\r\n\r\n#### Variation: Explicit lambdas\r\n\r\nThis variation lifts some of the restrictions of the 'value scripts'\r\napproach, at the cost of running the CEK machine to evaluate each\r\nmodule, and taking care to compute and check costs correctly for the\r\nnew CEK machine runs. This requires topological sorting of the scripts\r\nin a transaction before evaluation, to guarantee that we do not\r\nencounter a situation where script A depends on script B, but the\r\nbudget for computing script B depends on the cost of script A--such a\r\nsituation would lead to a blackhole error during script verification.\r\n\r\nBecause script bodies may now be arbitrary terms, 'module-level\r\nrecursion' is no longer essential--it is possible to use fixpoint\r\ncombinators in script bodies as at present. It would still improve\r\nefficiency, of course.\r\n\r\nNote that if modules *do* meet the syntactic restrictions of 'value\r\nscripts', then this variation will be less efficient than 'value\r\nscripts'--sometimes considerably so. This is because even evaluating,\r\nsay, a large tuple whose components are λ-expressions, leads the CEK\r\nmachine to descend into, evaluate, and return out of, each component,\r\nthus performing several CEK transitions per element. The `cekValue`\r\nfunction must also visit each component, of course, doing the same\r\nwork, but because this is done directly in Haskell then it will be\r\nconsiderably more efficient.\r\n\r\nThis variation is compatible with the various tuple-based variations,\r\nbut when the script body is constrained to return a tuple then this\r\nmust be checked dynamically when CEK-evaluation is complete; the check\r\ncannot be built into deserialization any more because it is no longer\r\nsyntactic.\r\n\r\n#### Variation: Tuples of modules\r\n\r\nThis variation changes the way modules are referenced in scripts: in\r\nthe main specification, each imported module is bound to a name in the\r\nenvironment, and referenced using the associated variable; in this\r\nvariation *all* imported modules are bound to a single name, and\r\nmodules are referenced by projecting the corresponding component from\r\nthe tuple bound to this name.\r\n\r\nThus: in the main specification, a module reference costs one name\r\nlookup; in this variation, a module reference costs a name lookup plus\r\nprojection of a component from a tuple. However, because projecting a\r\ncomponent from a tuple is constant time, while the cost of a\r\nname lookup is logarithmic in the number of names in the environment,\r\nthen this variation may reduce the cost of module references--since\r\nscripts which import many modules will run with significantly fewer\r\nnames in the environment.\r\n\r\nNote that the uncurried script form can be generated from the curried\r\none, by\r\n* introducing a `λMods.` outermost,\r\n* removing the `λ`s binding names to script arguments,\r\n* substituting `proj i Mods` for the `i`th script argument name in the\r\nscript body\r\n\r\nThus there is no need for any change to earlier parts of the compiler,\r\nor to the languages Plutus, PIR, or TPLC. Tuples of modules can be\r\nintroduced as a last step in the generation of UPLC.\r\n\r\n##### Subvariation: Global module environment\r\n\r\nThe advantage of using a global module environment instead of one\r\ntuple of modules per script is that only one, big, tuple of modules\r\nper transaction need be constructed, instead of one per script. The\r\ncost is an additional traversal of the script code, needed to adjust\r\nmodule indices to refer to the correct index in the global tuple of\r\nmodules. By itself, this is unlikely to improve performance.\r\n\r\nHowever, using a global module environment is a prerequisite to\r\nbuilding the module environment into the CEK machine. Doing the latter\r\ntransforms a module reference from a projection from the\r\ntuple-of-modules variable, to a custom construction `ModuleRef i` that\r\ndirectly accesses the module in the `i`th component of the global\r\nmodule environment. This reduces the cost from a variable lookup plus\r\na projection, to just a projection; this can be expected to speed up every\r\nreference to an external module.\r\n\r\n##### Subvariation: Unboxed modules\r\n\r\nThis subvariation makes every reference to a module export cheaper, by\r\nreplacing two projections from a tuple by one. It does require\r\npreprocessing script code before it is run, updating export references\r\nto refer to the correct element of the large tuple combining several\r\nmodules. This requires a traversal of all the script code in a\r\ntransaction, which must be performed every time script verification is\r\nrun, including on the chain. Because of this, it makes most sense to\r\nuse this subvariation in combination with 'global module environment',\r\nwhich also requires such a traversal. In both cases, the purpose is to\r\nadjust references to refer to the correct index in the new, merged\r\ndata structure; a single traversal suffices to achieve both ends.\r\n\r\nThe syntactic restriction, requiring a module body to be a tuple of\r\nexports, is not onerous. While some compilers might wish to represent\r\na module as built-in data, or as a function from a tag (as Solidity\r\ndoes), this can be achieved by placing the intended module value as\r\nthe first component of a one-tuple. The implementation described here\r\noptimises away the selection of an element from such a tuple, so the\r\nrestriction introduces no extra overhead in this case.\r\n\r\n### Transaction fees\r\n\r\nImported modules are provided using reference scripts, an existing\r\nmechanism (see CIP-33), or in the transaction itself. Provided the\r\ncost of loading reference scripts is correctly accounted for, this CIP\r\nintroduces no new problems.\r\n\r\nNote that there is now (since August 2024) a hard limit on the total\r\nsize of reference scripts used in a transaction, and the transaction\r\nfee is exponential in the total script size (see\r\n[here](https://github.com/IntersectMBO/cardano-ledger/blob/master/docs/adr/2024-08-14_009-refscripts-fee-change.md)).The\r\nexponential fees provide a strong motivation to prefer the 'lazy\r\nloading' variation in this CIP: even a small reduction in the number\r\nof reference scripts that need to be provided may lead to a large\r\nreduction in transaction fees.\r\n\r\nThe motivation for these fees is to deter DDoS attacks based on\r\nsupplying very large Plutus scripts that are costly to deserialize,\r\nbut run fast and so incur low execution unit fees. While these fees\r\nare likely to be reasonable for moderate use of the module system, in\r\nthe longer term they could become prohibitive for more complex\r\napplications. It may be necessary to revisit this design decision in\r\nthe future. To be successful, the DDoS defence just needs fees to\r\nbecome *sufficiently* expensive per byte as the total size of\r\nreference scripts grows; they do not need to grow without bound. So\r\nthere is scope for rethinking here.\r\n\r\nSome of the variations in this CIP require a traversal of all the\r\nscript code in a transaction to adjust module references before\r\nexecution. This should be reflected by a component in the transaction\r\nfee linear in the total size of scripts.\r\n\r\n### Verification\r\n\r\nSince scripts invoked by a transaction specify all their dependencies\r\nas hashes, then the running code is completely known, and testing or\r\nformal verification is no harder than usual. Standalone verification\r\nof modules using 'dynamic linking' poses a problem, however, in that\r\nthe code of the dependencies is unknown. This makes testing\r\ndifficult--one would have to test with mock implementations of the\r\ndependencies--and formal verification would require formulating\r\nassumptions about the dependencies that the module can rely on, and\r\nlater checking that the actual implementations used fulfill those\r\nassumptions.\r\n\r\n### Impact on optimisation and script performance\r\n\r\nSplitting a script into separately compiled parts risks losing\r\noptimisation opportunities that whole-program compilation gives. Note\r\nthat script arguments are known in advance, and so potentially some\r\ncross-module optimisation may be possible, but imported modules are\r\nshared subterms between many scripts, and they cannot be modified when\r\nthe client script is compiled. Moreover, unrestrained inlining across\r\nmodule boundaries could result in larger script sizes, and defeat the\r\npurpose of breaking the code into modules in the first place.\r\n\r\nOn the other hand, since the size limit on scripts will be less of a\r\nproblem, then compilers may be able to optimize *more*\r\naggressively. For example, today the Plinth inliner is very careful\r\nnot to increase script size, but once modules are available it may be\r\nable to inline more often, which can enable further optimizations.\r\n\r\nMoreover, today we see examples of deliberate choice of worse\r\nalgorithms, because their code is smaller, and easier to fit within\r\nthe script size limit. Removing the need to make such choices can\r\npotentially improve performance considerably.\r\n\r\n### Example: Defining and using a Set module\r\n\r\nAs an example of how the module system might be used in a high-level\r\nlanguage, consider the following code, which defines and uses a module\r\nimplementing set insertion and membership testing, using an ordered\r\nbinary tree.\r\n```\r\ndata Tree a = Leaf | Branch (Tree a) a (Tree a)\r\n\r\nempTree = Leaf\r\n\r\ninsTree a Leaf = Branch Leaf a Leaf\r\ninsTree a (Branch l b r)\r\n  | a < b = Branch (insTree a l) b r\r\n  | a > b = Branch l b (insTree a r)\r\n  | a== b = Branch l b r\r\n\r\nmemTree a Leaf = False\r\nmemTree a (Branch l b r)\r\n  | a < b = memTree a l\r\n  | a > b = memTree a r\r\n  | a== b = True\r\n\r\ndata Set = Set {emptySet :: forall a. Tree a,\r\n     \t        insertSet :: forall a. Ord a => a -> Tree a -> Tree a,\r\n\t\tmemberSet :: forall a. Ord a => a -> Tree a -> Bool}\r\n\r\nsetMod = Set empTree insTree memTree\r\n\r\nsetModule :: Module Set\r\nsetModule = makeModule ($$(PlutusTx.compile [| setMod |]))\r\n\r\nclient set redeemer _ = memberSet set redeemer s\r\n  where s = insertSet set 1 (insertSet set 2 (emptySet set))\r\n\r\nclientModule = makeModule ($$(PlutusTx.compile [| client |]))\r\n `applyModule` setModule\r\n```\r\nHere the module signature is represented by a Haskell record type;\r\nHaskell records are compiled into tuples in UPLC, and the record\r\nfields are all values (once fixpoints are floated upwards to the\r\nmodule level), so the `setModule` in this example fits the 'unboxed\r\nmodules' syntactic restrictions. The client script takes the record as\r\nan argument, and uses the module exports via record field selectors,\r\nwhich compile to projections from the tuple. Thus the client also\r\nmeets the syntactic restrictions for 'unboxed modules'. To make use\r\nof these modules, the off-chain code must construct a UTxO\r\ncontaining `setModule` as a reference script, and include it as a\r\nreference UTxO in transactions that use the client.\r\n\r\n### Related work\r\n\r\n#### Merkelized Validators\r\n\r\nPhilip DiSarro describes [\"Merkelized\r\nvalidators\"](https://github.com/Anastasia-Labs/design-patterns/blob/main/merkelized-validators/merkelized-validators.md),\r\nwhich offer a way of offloading individual function calls to stake\r\nvalidators: the client script just checks that the appropriate stake\r\nvalidator is invoked with a particular function-argument and result\r\npair, checks that the argument equals the argument it wants to call\r\nthe function with, and then uses the result as the result of the\r\nfunction. The stake validator inspects the argument-result pair,\r\ncomputes the function for the given argument, and checks that the\r\nresult equals the result in the pair. This design pattern enables the\r\nlogic of a script to be split between the client script and the stake\r\nvalidator, thus circumventing the limits on script size. But the main\r\npoint is that the function call, whose result may be needed by several\r\nvalidators, can be computed just *once* per transaction. More details\r\ncan be found\r\n[here](https://github.com/Anastasia-Labs/design-patterns/blob/main/stake-validator/STAKE-VALIDATOR-TRICK.md).\r\n\r\nFactoring out a shared part of the validation in this way is a\r\ngenerally useful technique which is largely independent of the\r\nexistence of modules--this CIP does not remove the need for sharing\r\nwork between validators, and indeed this trick will work equally well\r\nonce modules are added. But as a way of *implementing* modules, it is\r\nrather intricate and unsatisfactory.\r\n\r\n#### The WebAssembly Component Model\r\n\r\nThe [Web Assembly Component\r\nModel](https://component-model.bytecodealliance.org/) defines a\r\nhigh-level IDL to enable components written in different programming\r\nlanguages (such as C/C++, C#, Go, Python and Rust), to work together\r\nin one WebAssembly system. WASM already has a module system, and a\r\nWASM component may consist of a number of modules (written in the same\r\nlanguage). The focus here is on interaction between *different*\r\nprogramming languages in a well-typed way. Defining such an IDL for\r\nCardano might be useful in the future, but it is too early to do so\r\nnow.\r\n\r\n### Preferred Options\r\n\r\nAllowing script code to be spread across many transactions lifts a\r\ncommonly complained-about restriction faced by Cardano script\r\ndevelopers. It permits more complex applications, and a much heavier\r\nuse of libraries to raise the level of abstraction for script\r\ndevelopers. Modules are already available on the Ethereum blockchain,\r\nand quite heavily used. Adopting this CIP, in one of its variations,\r\nwill make Cardano considerably more competitive against other smart\r\ncontract platforms.\r\n\r\nThe *main alternative* in this CIP is the simplest design, is easiest\r\nto implement, but suffers from several inefficiencies.\r\n\r\nThe *lazy loading* variation allows redundant scripts to be omitted\r\nfrom transactions, potentially making transactions exponentially\r\ncheaper. To take full advantage of it requires a balancer that can\r\ndrop redundant scripts from transactions. Three alternative methods\r\nare described: *search*, the simplest, which must run script\r\nverification a quadratic number of times in the number of scripts in\r\nthe worst case; *garbage collection*, a self-contained change to the\r\nbalancer which analyses script dependencies and thus needs to run script\r\nverification only a linear number of times; a *modified CEK machine*\r\nwhich adds tagged values to the machine, which the balancer can use to\r\nidentify redundant scripts in *one* run of script verification,\r\npossibly requiring one more run to make accurate exunit cost estimates.\r\n\r\nThe *value scripts* variation restricts scripts to be explicit\r\nλ-expressions binding the script arguments, with an innermost script\r\nbody which is a syntactic value. Such scripts can be converted to CEK\r\nvalues in a single traversal; each script can be converted to a value\r\n*once per transaction*, rather than at every use. *Module-level\r\nrecursion* enables recursive definitions to recurse via the module\r\nitself, rather than locally, and makes the syntactic-value restriction\r\neasier to satisfy. This variation is expected to reduce the start-up\r\ncosts of running each script considerably; on the down-side the\r\nsyntactic restriction would be a little annoying, and it requires CEK\r\noperations which are not currently part of the API, so it requires\r\nmodifications to a critical component of the Plutus implementation.\r\n\r\nThe *explicit λs* variation is a half-way house between the main\r\nvariation and the 'value scripts' variation. It places less onerous\r\nsyntactic restrictions on script bodies, and as such can be used with\r\nthe existing implementation of recursion (although efficiency would\r\nstill benefit from module-level recursion). Cost accounting during\r\nscript evaluation is a little intricate. It requires modifications to\r\nthe loop at the core of the CEK machine.\r\n\r\nThe *tuples of modules* variation replaces parameters referring to\r\nindividual modules with a single parameter bound to a tuple of\r\nmodules, effectively uncurrying scripts wrt their module\r\nparameters. At the cost of a traversal of all the script code in a\r\ntransaction to 'relocate' module references, it is possible to replace\r\nmany tuples-of-modules, one per script, by a global tuple of modules\r\nfor the entire transaction; a further improvement would then be to\r\nunbox modules, replacing the global tuple of modules with a global\r\ntuple of module exports. These variations reduce the cost of referring\r\nto a module export, at the cost of an additional traversal of the\r\nscript code before execution. Extensive benchmarking would be needed\r\nto decide whether or not they improve performance overall.\r\n\r\nPerformance can probably be improved further by building the module\r\nenvironment in to the CEK machine.\r\n\r\nThe simplest alternative to implement would be the main alternative\r\nwithout variations. A more efficient implementation would combine\r\nvalue scripts with lazy loading, using tagged values in the CEK\r\nmachine to analyse dynamic script dependencies in the balancer, and so\r\ndrop redundant scripts from each transaction. Further improvements to\r\nperformance may be achievable using a global module environment, and\r\nunboxed modules; because there are performance costs as well as\r\nbenefits to these approaches, extensive benchmarking would be required\r\nto make an informed choice.\r\n\r\nThese latter variations all require modifications to the CEK machine\r\nand to the balancer, as well as resolving dependencies in scripts;\r\nthat is, they are considerably more expensive to implement.\r\n\r\nThere are many variations proposed in this CIP; I do have an opinion\r\nas to which choices might be best. These are opinions, so might be\r\nproven wrong later by benchmarks.\r\n\r\nFirstly, I believe lazy loading will be very valuable, especially for\r\nsmall, cheap transactions.\r\n\r\nI don't think lazy loading will make *any* transaction worse, it's\r\nsimply a win. In general, though, many choices have effects that will\r\ndiffer for different transactions, speeding some up while slowing\r\nothers down.  Many variations do some work before running scripts, in\r\norder to speed them up when they are actually run. These variations\r\nwill tend to make small, cheap transactions *more* expensive, because\r\nthere will be too little execution time to recoup the initial\r\ninvestment, while they make long-running transactions cheaper. It's\r\nnecessary to make a choice here, and decide what kind of transactions\r\nto prioritize. Personally, I favour keeping small, cheap transactions\r\ncheap, even at the cost of making longer running transactions a bit\r\nslower. So I favour choosing a variation that does work in advance\r\nonly if the break-even point is reached very quickly. This is a\r\npersonal opinion, and could be questioned: the important thing is\r\nthink about this issue and make the choices deliberately.\r\n\r\nWith this in mind, I am against variations that require a traversal of\r\nall the script code *during phase 2 verification*. This would be, in\r\nparticular, the 'global module environment' and the 'module\r\nenvironment built into the CEK machine' variations. Note that\r\nsyntactic restrictions which can be implemented during deserialization\r\ndo not require an extra traversal of the code in this sense. Also, the\r\n'unboxed modules' variation--*in its local form*--requires a traversal\r\nof the script code *which treats each script independently*, and so\r\ncan be done at compile-time. This is not either a run-time cost that\r\nconcerns me.\r\n\r\nI like the 'value scripts' variation. I believe it may reduce costs\r\nsignificantly for small, cheap transactions. It does require 'module\r\nlevel recursion' as well, if recursion is to be compiled simply and\r\nefficiently. It does constrain compilers a little bit; any compiler\r\nthat takes advantage of modules must generate code meeting the\r\nrestriction. But since modules are a new feature, no existing code\r\nwill be broken by this. It's also straightforward to meet the\r\nrestriction trivially, for example by wrapping the entire module body\r\nin `Delay`. So I do not expect any major problems here.\r\n\r\nThe 'tuples of modules' variation, given efficient projections, should\r\nsimply be a performance improvement, so I am in favour of it. It does\r\nrequire `resolveScriptDependencies` to *construct* the tuple before\r\nscript execution, but this replaces adding the modules one-by-one to\r\nthe environment, and should be cheaper. Moreover, accessing modules\r\nshould in most cases be slightly cheaper. Checking the restriction\r\nthat the variable bound to the tuple only appears as an argument to a\r\nprojection might be costly, requiring an additional traversal of the\r\ncode, but on the other hand that restriction exists to make adjustment\r\nof the index possible, and this is only required by the 'global module\r\nenvironment' variation. So, provided this is not adopted, one might\r\nrelax that restriction and *allow* scripts to refer to the tuple of\r\nmodules as a whole. That is an odd thing to do, but not actively\r\nharmful.\r\n\r\nThe 'unboxed modules' variation is quite attractive, in its local\r\nvariant (where each script is passed a tuple of the exports from\r\nmodules that *that script* imports). In this variant a traversal of\r\nthe code to adjust references to module exports *is* needed, but can\r\nbe done at compile-time, so does not impose a cost during phase 2\r\nverification. However, (in combination with 'lazy loading') this does\r\nrequire `ScriptArg`s to be larger, making all scripts slightly larger\r\non the chain. Also, there is a start-up cost for the unboxing itself:\r\n`resolveScriptDependencies` must copy *all* the exports from each\r\nimported module into the same tuple (whether or not they will be\r\nused). Modules may have quite a lot of exports--`Data.Map` for example\r\nhas 97--and many may not be used in any particular script. The benefit\r\nof unboxing modules is slightly faster access to module exports when\r\nthe script runs, but for small, cheap runs we may never recover the\r\ncost of building the unboxed tuple in the first place. On balance, I\r\nwould probably prefer *not* to do this, but this is not a strong\r\npreference.\r\n\r\nFinally, all the variations using tuples rely on efficient, constant\r\ntime projections of tuple components. These are not presently\r\navailable in UPLC--but they would benefit *all* UPLC users, not least\r\nby providing an efficient implementation for Haskell record field\r\nselectors in Haskell. Adding efficient projections for SoP data deserves\r\na CIP of its own; it is a prerequisite for many variations here, but\r\nlogically is not a part of implementing modules. A separate CIP should\r\nbe written for this in the near future--it should be straightforward\r\nand uncontroversial compared to adding modules.\r\n\r\n\r\n## Path to Active\r\n\r\n### Acceptance criteria\r\n\r\n- [ ] determine which approach outlined in this CIP will be selected\r\n- [ ] `plutus` changes\r\n- [ ] `cardano-ledger` changes\r\n- [ ] `cardano-api` changes\r\n- [ ] benchmarking and testing\r\n- [ ] integrate the feature into `cardano-node`\r\n- [ ] end-to-end testing\r\n- [ ] release at the hard fork introducing the Dijkstra era\r\n\r\n### Implementation Plan\r\n\r\nThis CIP will be implemented by the Plutus Core team with assistance from the Ledger team and the Cardano API team.\r\nShould we decide to implement tagged modules - the safer and more recommended option - then modules will be usable in existing Plutus ledger language versions (V1, V2 and V3).\r\nIf we instead opt for untagged modules, modules will only be usable from Plutus V4 onwards.\r\n\r\nEnabling modules on-chain requires a new ledger era.\r\nTherefore modules will be enabled in the Dijkstra era at the earliest.\r\n\r\nDevelopers of compilers for other languages targeting Untyped Plutus Core will need to update their languages and compilers accordingly if they wish to support modules.\r\n\r\nAlternative Cardano node implementors must update their Plutus evaluator (unless a variant is chosen that doesn't require modifying the Plutus evaluator, which is unlikely), ledger, and transaction balancer to support this feature and align with the Haskell node.\r\n\r\n## Acknowledgements\r\n\r\nThis CIP draws heavily on a design by Michael Peyton Jones, and has\r\nbenefitted greatly from discussion with Ziyang Liu, Roman Kireev, and\r\nPhil Wadler.\r\n\r\n## Copyright\r\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\r\n\r\n---\r\n\r\n[^1]: At present, a newer ledger language version may have access to more builtin functions and more Plutus Core versions than an older ledger language version, but this difference is going away.\r\n"
  },
  {
    "path": "CIP-0153/README.md",
    "content": "---\nCIP: 153\nTitle: Plutus Core Builtin Type - MaryEraValue\nCategory: Plutus\nStatus: Proposed\nAuthors:\n    - Philip DiSarro <philipdisarro@gmail.com>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/921\nCreated: 2024-10-03\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nWe propose to extend the `Data` type in Plutus Core with a new constructor `Value BuiltinValue`, introducing native, first-class support for multi-asset values that adhere to the invariants of multi-asset values in the Cardano ledger.\n\nThis addition enables on-chain scripts to operate on multi-asset values directly and efficiently, without resorting to nested map encodings. It eliminates the need for costly emulation of value operations, reduces validator script size, enables faster execution, and significantly lowers the ex-unit budgets required to process multi-asset logic. By elevating multi-asset values to a primitive type, this change aligns Plutus Core more closely with its primary domain—expressing constraints over the transfer of value—and unlocks substantial improvements in performance, safety, and consistency across the smart contract ecosystem.\n\n## Motivation: why is this CIP necessary?\n\nUPLC is not a general-purpose programming language. It is a language specifically designed to write validation logic to set constraints for the creation and transfer of Value and Data across the Cardano blockchain. **Given that half of the entire purpose of this language is to express constraints over the creation and transfer of** `Value`, why is Value treated as a standard library concept rather than a first-class language primitive?\n\nThe value proposition of domain-specific languages like UPLC is that they are purpose-built for a specific problem space, and as such, are able to outperform general-purpose languages within that domain. This foundational consideration seems to have been largely absent from the historical design of Plutus. It is difficult to reconcile the absence of first-class support for `Value` in a language explicitly designed to manage the transfer of value.\n\nCurrently, Plutus Core has no concept of multi-asset values. Instead, `Value` is a standard library construct, implemented as a nested `Map`:\n\n```haskell\nnewtype Value = Value (Map CurrencySymbol (Map TokenName Integer))\n```\nWhile this representation superficially resembles the structure of ledger-level values, it lacks the necessary semantic guarantees. The critical invariants upheld by the ledger—such as omitting zero-valued assets, eliminating empty maps, and maintaining canonical order—must be manually replicated in every implementation targeting Plutus Core. This makes secure and correct usage of `Value` significantly harder than it should be.\n\nSmart contract languages like Plinth, Aiken, Plutarch, and Helios must each implement their own standard library for value manipulation, resulting in duplicated logic, inconsistent behavior, and non-trivial security risks. Even operations as fundamental as value equality and union require verbose logic to normalize entries—adding cost and complexity to every validator.\n\nIt should not be the responsibility of language authors or smart contract developers to implement secure and efficient operations over a type that is fundamental to the domain itself.\n\n## Specification\n\n### MaryEraValue\n\nA _map_ is a collection of _values_ indexed by _keys_. We consider a map to be _well-defined_ when each key uniquely identifies each value, and when additional structural and semantic constraints are satisfied. The canonical representation of Mary-era multi-asset Values in Plutus Core is a nested map where the keys of the outer map are `AsData CurrencySymbol`s and the keys of the inner map are `AsData TokenName`s and the _values_ of the inner map are `AsData Integer` (representing the quantity of the asset).\n\nHere are the important invariants of the PlutusCore representation of the Mary-era Value types from the Cardano ledger:\n1. All _keys_ in the outer map are unique (each `CurrencySymbol` appears only once)\n2. All _keys_ in the inner map are unique (each `TokenName` appears only once)\n3. The _keys_ in the outer map are ordered lexographically (`CurrencySymbol`s appear in ascending order)\n4. The _keys_ in the inner map are ordered lexographically (`TokenName`s appear in ascending order)\n5. There are no empty inner maps (The _value_ associated with any given `CurrencySymbol` _key_ cannot be an empty map)\n6. There are no zero-quantity _values_ in the inner maps (The _value_ associated with any given `TokenName` _key_ in an inner-map cannot be zero).\n\n### Mary-era Value as a builtin type\n\nWe propose introducing a new builtin type, `BuiltinValue`, along with a set of builtins for efficient manipulation of multi-asset values. These builtins will enforce all invariants defined for multi-asset values in the Cardano ledger. Additionally propose extending the Data type with a new constructor to support BuiltinValue:\n\n```haskell\ndata Data =\n      Constr Integer [Data]\n    | Map [(Data, Data)]\n    | List [Data]\n    | I Integer\n    | B BS.ByteString\n    | Value BuiltinValue\n    -- ^ New constructor for `BuiltinValue`\n```\nThis enables direct representation of BuiltinValue within `Data`, eliminating the expensive computation that would otherwise be required to convert back and forth between the `Data` representation of `Value` as nested Map structures and the `BuiltinValue` type.\n\n### On the Necessity of a `Data` Constructor for `BuiltinValue`\n\nIntroducing a `BuiltinValue` type to Plutus Core without also adding a corresponding constructor to the `Data` type (i.e. `Value BuiltinValue`) would result in a fragmented and inefficient design. In such a scenario, smart contracts would require dedicated conversion builtins to translate between `BuiltinData`—the standard interface type in validators—and `BuiltinValue`. Although these conversions are linear in the size of the structure and less expensive than conversions like `Data → ScriptContext`, they are still nontrivial and, in practice, can become prohibitively expensive.\n\nConsider, for instance, a `Value` containing hundreds of assets where a script only needs to access ADA. Converting the entire structure to a `BuiltinValue` simply to look up a single entry would be significantly more expensive than directly inspecting the original `Data` representation. Even more critically, this approach creates ambiguity for developers: they must decide when to convert, weigh the performance trade-offs, and handle two separate representations of the same underlying concept.\n\nThis defeats the entire purpose of introducing `BuiltinValue`, which is to simplify, secure, and optimize multi-asset handling in Plutus. If this proposal were to result in developers continuing to use nested `Map` structures within `Data` for performance reasons, it would not only fail to unify the representation of `Value` in Plutus Core—it would add yet another layer of complexity.\n\nIt is therefore a strong requirement of this proposal that `BuiltinValue` be made a first-class constructor within the `Data` type (i.e. `Value BuiltinValue`). Only with this addition can we ensure that all value-related logic is handled canonically, efficiently, and securely via the new builtins—eliminating the need for conversions or manual manipulation of `BuiltinData`.\n\n### BuiltinValue Operations\nWe propose the introduction of the following builtin functions to support efficient and invariant-preserving manipulation of multi-asset values through a new `BuiltinValue` type.\n\nThese functions operate on the following types:\n```haskell\ntype BuiltinValue -- A new primitive type\ntype BuiltinCurrencySymbol = BuiltinByteString\ntype BuiltinTokenName = BuiltinByteString\ntype BuiltinQuantity = BuiltinInteger\n```\n\nWe propose the following set of builtin functions to accompany the new builtin type:\n1. `insertCoin :: BuiltinCurrencySymbol -> BuiltinTokenName -> BuiltinInteger -> BuiltinValue -> BuiltinValue`\n    - it returns a Mary-era Value with the `Coin` inserted, silently discarding any previous value.\n      If the `BuiltinInteger` argument (the quantity) is zero, the `Coin` is removed.\n    - Both `BuiltinCurrencySymbol` and `BuiltinTokenName` must be no longer than 32 bytes (unless the amount is zero).\n    - The amount (`BuiltinInteger`) must satisfy -2<sup>127</sup> ≤ amount ≤ 2<sup>127</sup>-1.\n2. `lookupCoin :: BuiltinCurrencySymbol -> BuiltinTokenName -> BuiltinValue -> BuiltinQuantity`\n   - it returns the quantity of a given `Coin` in a Mary-era Value.\n3. `unionValue :: BuiltinValue -> BuiltinValue -> BuiltinValue`\n    - it merges two provided values\n    - when there are collisions it adds the quantities, if the resulting sum is zero it removes the entry to maintain the Mary-era Value invariants (no zero-quantity entries, no empty inner maps) such that the result is a normalized value.\n    - This operation is commutative and associative, thus makes `BuiltinValue` a commutative semigroup.\n4. `valueContains :: BuiltinValue -> BuiltinValue -> Bool`\n    - it compares the two Mary-era Values and determines if the first value is a superset of the second.\n    - All amounts in both values must be positive.\n    - `valueContains a b == True` if and only if: for each `(currency, token, quantity)` in `b`, `lookupCoin currency token a >= quantity`.\n5. `valueData :: BuiltinValue -> BuiltinData`\n    - encodes a `BuiltinValue` as `BuiltinData`.\n6. `unValueData :: BuiltinData -> BuiltinValue`\n    - decodes a `BuiltinData` into a `BuiltinValue`, or fails if it is not one.\n    - This builtin MUST reject non-canonical `Data`-encoded values.\n    - The outer `Map` must be strictly ascending by `CurrencySymbol` key and contain no duplicate keys; otherwise, the builtin fails.\n    - Each inner `Map` must be strictly ascending by `TokenName` key and contain no duplicate keys; otherwise, the builtin fails.\n    - It fails on empty inner maps.\n    - It fails on zero-amount entries in inner maps.\n    - All currency symbols and token names must be no longer than 32 bytes.\n    - All amounts must lie between -2<sup>127</sup> and 2<sup>127</sup>-1 (inclusive), and be non-zero.\n7. `scaleValue :: BuiltinInteger -> BuiltinValue -> BuiltinValue`\n    - it multiplies all token quantities in the provided value by the provided integer scale factor.\n    - Any entries whose resulting quantity is zero are removed, and any currency symbols whose inner maps become empty are removed, preserving the Mary-era Value invariants.\n    - It fails if any resulting quantity lies outside -2<sup>127</sup> ≤ amount ≤ 2<sup>127</sup>-1.\n\nA note on `valueData` and `unValueData`: in Plutus V1, V2 and V3, the encoding of `BuiltinValue` in `BuiltinData` is identical to that of the [existing `Value` type](https://plutus.cardano.intersectmbo.org/haddock/latest/plutus-ledger-api/PlutusLedgerApi-V1-Value.html#t:Value) in plutus-ledger-api.\nThis ensures backwards compatibility.\nBeginning in the Dijkstra era, a new `Value` constructor will be added to `BuiltinData`, making `valueData` and `unValueData` constant time operations for Plutus V4 onwards.\n\n## Rationale: how does this CIP achieve its goals?\n\n### Efficiency\n\nBuiltins are strictly more efficient than user-defined operations evaluated by the CEK machine. Today, operations on `Value` must be implemented at the Plutus level using nested `Map` structures and generic functional constructs. These are significantly slower and more memory-intensive than equivalent builtins due to their interpretive overhead and lack of optimization opportunities.\n\nBy introducing a dedicated `BuiltinValue` type and associated builtins, we enable:\n\n- Elimination of the need to deconstruct and traverse deeply nested data-encoded maps to perform operations on `Value`s, which significantly improves execution efficiency.\n- Drastically reduced script sizes, since `Value` operations no longer need to be defined in the bytecode of every validator; they are now provided natively by the language as builtins.\n\nThis directly addresses a major pain point for developers working with large or complex multi-asset values.\n\n### Security & Abstraction\n\nIntroducing a single, standardized `BuiltinValue` type — including a constructor on `Data` and associated conversion builtins — eliminates the need for dual representations of multi-asset values. Without this, developers would be forced to evaluate trade-offs in every instance where value manipulation is required: either operate directly on `BuiltinData`, or incur the overhead of converting to and from SOP-style encodings in order to gain performance benefits from subsequent operations on the structured representation. This added friction increases both complexity and fragmentation across the ecosystem.\n\nInstead, developers will have:\n\n- A consistent and canonical representation of multi-asset values.\n- Simple, expressive, and performant builtins for common operations.\n- Fewer footguns and edge cases to reason about in critical onchain logic.\n\nBy elevating `Value` to a first-class builtin type, this CIP ensures that the semantics of `Value` and its operations are uniform across all languages targeting Plutus Core. Currently, each language (e.g., Aiken, Plutarch, Helios, Plu-Ts, etc.) must independently define a `Value` type and implement its operations in their standard libraries. This fragmentation introduces the risk of divergent behaviors and subtle inconsistencies across Cardano’s smart contract ecosystem.\n\nWith `BuiltinValue`, all implementations inherit a single, authoritative definition of `Value` and its operations, removing this burden from language authors and guaranteeing consistency across the entire platform.\n\nThis CIP ultimately shifts the responsibility for correctness and optimization away from the application layer and into the language itself — the appropriate place for enforcing invariants and performance guarantees for such a core domain primitive.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] The feature is implemented according to the implementation plan and merged into\nthe master branch of the [plutus][6] repository.\n- [ ] [cardano-ledger][1] is updated to include new protocol parameters to control costing of\nthe new builtins.\n- [ ] The feature is integrated into [cardano-node][2] and released as part of a hard fork.\n\n### Implementation Plan\n\nThe implementation of this CIP should not proceed without an empirical assessment of the effectiveness of the new primitives, as per the following plan:\n\n1. Implement the new primitives according to the specification.\n2. Assign a preliminary cost to the new builtin functions. Consider similar operations and their current costs.\n3. Create variants of the [existing benchmarks][3] and potentially add some more.\n4. Check that the builtin operations over `BuiltinData = Value` are indeed significantly faster.\n\nIf the preliminary performance investigation was not successful, this CIP should be revised\naccording to the findings of the experiment. Otherwise, the implementation can proceed:\n\n5. Determine the most appropriate costing functions for modelling the builtin's performance\nand assign costs accordingly.\n6. Add the new builtin type and functions to the appropriate sections in the [Plutus Core\nSpecification][4].\n7. Formalize the new builtin type and functions in the [plutus-metatheory][5].\n8. The final version of the feature is ready to be merged into [plutus][6] and accepted by\nthe Plutus Core team.\n\n## Copyright\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[1]: https://github.com/IntersectMBO/cardano-ledger \"cardano-ledger\"\n[2]: https://github.com/IntersectMBO/cardano-node \"cardano-node\"\n[3]: https://github.com/IntersectMBO/plutus/tree/master/plutus-benchmark/script-contexts \"script-context-benchmarks\"\n[4]: https://plutus.cardano.intersectmbo.org/resources/plutus-core-spec.pdf \"Formal Specification of the Plutus Core Language\"\n[5]: https://github.com/IntersectMBO/plutus/tree/master/plutus-metatheory \"plutus-metatheory\"\n[6]: https://github.com/IntersectMBO/plutus/ \"plutus\"\n"
  },
  {
    "path": "CIP-0155/README.md",
    "content": "---\nCIP: 155\nTitle: SRV registry\nStatus: Proposed\nCategory: Network\nAuthors:\n  - Marcin Szamotulski <marcin.szamotulski@iohk.io>\nImplementors: N/A\nDiscussions: \n  - Submission: https://github.com/cardano-foundation/CIPs/pull/1033\nCreated: 2025-04-22\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP defines the procedure for assigning Service Record (SRV) prefixes for Cardano applications (like `cardano-node`, `mithril`, etc.).\n\nThis creates a means of sharing authoritative information between SPOs who deploy services and _decentralised protocol_ developers who write them.\n\n## Motivation: why is this CIP necessary?\n\nThe **Cardano Ledger** allows the use of SRV records in the **SPO** registration certificate (see [register-stake-pool]).\n\nHaving access to the ledger (either directly or through tools like `cardano-cli`) will allow decentralised protocols developers to construct networks based on registered relays. \n\nIn this CIP, we propose to make them usable by decentralised applications running on `Cardano`.\n\n\nAll involved parties (SPOs, decentralised protocol developers, etc) need to agree on SRV prefixes used by various decentralised protocols and thus a public registry governed by a public CIP process is required to foster decentralised protocols that co-exist with the **Cardano** network, like **Mithril** (see [CIP#137]).\n\nWe consider decentralised protocols as applications, which construct their own network and relay on ledger peers published on the block-chain. This include node implementations, overlay networks like Mithril, or Layer 2 protocols like Hydra.\n\n### Problem\n\nBootstraping networks requires sharing information about available services.\n\nHistorically, this was done by sharing IP or DNS names and PORT numbers (note that `A` or `AAAA` records do not contain PORT numbers), but this approach has its limitations.\nSRV records were designed to make deployment independent of hard-coded service end-points (see [RFC#2782] or [cloudflare documentation][srv]).  They include PORT numbers together with a DNS name (point to an `A` or `AAAA` record) together with `TTL`, priority, weight, and some other data.\nThus they can be instrumental in `Cardano`, since relays are registered on the blockchain through the registration certificate.\n\nBy using SRV records in the registration certificate (which is supported by the `cardano-ledger`, but not by `cardano-node`), we wish to solve this problem not just for `Cardano` node implementation, but also for any decentralised protocol that requires constructing its own network.\n\nSRV provides a mechanism for exposing decentralised protocols co-deployed with a node, like **mithril** or **hydra**.\n\nMaking such services discoverable is one of the key features addressed by this CIP.\n\nIn this CIP, we propose prefixes for both **Cardano** and **Mithril**; in the future, other services can be registered through a CIP process, thus starting a registry of prefixes used by the **Cardano** ecosystem.\n\nSPOs who deploy services need to configure their system according to the registry, e.g. SPO's cardano relays node MUST be available at `_cardano._tcp.<SPO_DOMAIN_NAME>`, as other nodes on the system will be looking at this address.\n\nDecentralised protocol developers SHOULD submit proposals to the SRV Prefix Registry, so SPOs, who deploy them, can have an authoritative information how to do it.\n\n## Specification\n\n### SRV Prefix Registry\n\nThe registry is available in `JSON` format [registry.json].\n\n### SRV Prefix Semantics\n\nWhen a **cardano** node implementation reads an SRV record from a ledger, it must add the _cardano_ prefix from the table above before making a DNS lookup, e.g. it should do a DNS query for `_cardano._tcp.<srv-record-from-ledger>`.\n\nThis design allows decentralised protocols to use SRV records registered in the ledger for different purposes, e.g. a **mithril** node can use them to learn about end-points of its network.\n\nEach prefix SHOULD start with `_cardano._tcp` or `_cardano._udp`, to avoid clashes with services not related to `Cardano`.\n\n#### SRV Registry Rules\n\n* Each decentralised protocol can have at most one entry in the registry.\n* A CIP process assigns new entries to [registry.json], after a careful consideration and consultation with all the involved parties (see #acceptance-criteria below).\n* Entries cannot be removed, but can be revoked by assigning a `Revoked` status.\n  This can only happen if a decentralised protocol is no longer supported.\n\n### Example\n\nWhen registering a cardano pool on `example.com` domain using an `SRV` record, one should use:\n```shell\ncardano-cli latest stake-pool ... --multi-host-pool-relay example.com\n```\n(see [register-stake-pool]); and configure SRV record at `_cardano._tcp.example.com` to point to **Cardano** relays, `_mithril._tcp.example.com` to point to **Mithril** relays (see [srv], currently under development).\n\nA **Cardano** node implementation, when retrieving information from a registration certificate from the ledger, will receive `example.com`, and it must prepend the `_cardano._tcp` prefix to make an SRV query.  Such a query might return:\n\n```\n_cardano._tcp.example.com 86400 IN SRV 10 5 3001 cardano.example.com\n```\nFrom this, we learn that a Cardano node is available on port `3001` on IPs resolved by a regular DNS query to `cardano.example.com`.\nRefer to the [Cloudflare documentation][srv] for a deeper understanding of other fields.\n\n\n## Rationale: how does this CIP achieve its goals?\n\nThis CIP constructs a process to maintain SRV registry, and thus provides authritative information for SPOs and decentralised protocol developers.\n\n\n## Path to Active\n\n### Acceptance Criteria\n\nThe CIP should be accepted by:\n\n* [ ] [**Technical Steering Committee**][tsc]\n\nAnd when there's no major objection from one of the currently involved parties:\n\n* [x] [**Cardano-Node Team**][cardano-node] accepts the proposal\n* [ ] [**Amaru Team**][amaru] accepts the proposal\n* [ ] [**Gouroboros Team**][gouroboros] accepts the proposal\n* [ ] [**Hydra Team**][hydra] accepts the proposal\n* [x] [**Mithril Team**][mithril] accepts the proposal\n\n### Implementation Plan\n\nEach **Cardano** node implementation or other tools which rely on SRV records stored in the ledger should comply with this proposal,\ne.g. whenever obtaining _multi-pool relay information_ one needs to prepend a registered prefix before making an SRV query.\n\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n\n[CIP#137]: ../CIP-0137\n[register-stake-pool]: https://developers.cardano.org/docs/operate-a-stake-pool/register-stake-pool\n[RFC#2782]: https://datatracker.ietf.org/doc/html/rfc2782 \n[srv]: https://www.cloudflare.com/en-gb/learning/dns/dns-records/dns-srv-record/\n\n[amaru]: https://github.com/pragma-org/amaru\n[cardano-node]: https://github.com/IntersectMBO/cardano-node\n[mithril]: https://github.com/input-output-hk/mithril\n[gouroboros]: https://github.com/blinklabs-io/gouroboros\n[tsc]: https://docs.intersectmbo.org/intersect-overview/intersect-committees/technical-steering-committee-tsc\n[hydra]: https://github.com/cardano-scaling/hydra\n[register-stake-pool]: https://developers.cardano.org/docs/operate-a-stake-pool/register-stake-pool/#generate-the-stake-pool-registration-certificate\n\n[registry.json]: ./registry.json\n"
  },
  {
    "path": "CIP-0155/registry.json",
    "content": "[\n  { \"service\": \"cardano\",\n    \"prefix\": \"_cardano._tcp\",\n    \"status\": \"Active\"\n  },\n  { \"name\": \"mithril.dmq\",\n    \"prefix\": \"_dmq._mithril._cardano._tcp\",\n    \"status\": \"Active\"\n  },\n  { \"name\": \"mithril.aggregator\",\n    \"prefix\": \"_aggregator._mithril._cardano._tcp\",\n    \"status\": \"Active\"\n  }\n]\n"
  },
  {
    "path": "CIP-0155/registry.schema.json",
    "content": "{\n    \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n    \"$id\": \"https://github.com/cardano-foundation/CIPs/blob/master/CIP-0155\",    \n    \"title\": \"SRV Registry\",\n    \"description\": \"JSON schema for the SRV registry\",    \n    \"type\": \"array\",\n    \"items\": {\n      \"type\": \"object\",\n      \"properties\": {\n        \"service\": {\n          \"type\": \"string\",\n          \"description\": \"A unique identifier for the service name.\"\n        },\n        \"prefix\": {\n          \"type\": \"string\",\n          \"description\": \"A unique SRV prefix.\",\n          \"maxLength\": 255\n        },\n        \"status\": {\n          \"type\": \"string\",\n          \"description\": \"Status of the entry. Can be one of: \\\"Active\\\", \\\"Revoked\\\"\"\n        }\n      },\n      \"required\": [\n        \"service\",\n        \"prefix\",\n        \"status\"\n      ],\n      \"additionalProperties\": false\n    }\n  }\n\n"
  },
  {
    "path": "CIP-0156/README.md",
    "content": "---\nCIP: 156\nTitle: Plutus Core Builtin Function - multiIndexArray\nCategory: Plutus\nStatus: Proposed\nAuthors:\n    - Yura Lazaryev <yuriy.lazaryev@iohk.io>\n    - Philip DiSarro <info@anastasialabs.com>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/1050\nCreated: 2025-07-07\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nWe propose adding a new builtin function, `multiIndexArray`, to Plutus Core. This function takes a list of integer indices and an array, returning a list of the array elements at those positions in the specified order.\n\n## Motivation: why is this CIP necessary?\n\nPlutus Core arrays (CIP-0138) support O(1) individual lookup via `indexArray`. However, extracting multiple elements requires repeated calls to `indexArray`, which:\n\n1. Increases script size and execution cost.\n2. Complicates on-chain logic for batching lookups or reordering.\n3. Prevents efficient bulk access and traversal in a user-defined order.\n\nA single `multiIndexArray` call reduces code and cost overhead by batching lookups and delivering elements in the desired sequence.\n\n## Specification\n\nAdd the following builtin function:\n\n```haskell\nmultiIndexArray :: forall a. List Integer -> Array a -> List a\n```\n\n- **Inputs**:\n  1. A `List Integer` of zero-based indices, in the order elements should be retrieved.\n  2. An `Array a` to index.\n- **Output**: A `List a` containing the elements at the specified indices, in the same order. In case of repeated indices, the same element is returned multiple times.\n- **Error handling**: If any index is out of bounds (< 0 or ≥ lengthOfArray), the entire call fails with the same error semantics as `indexArray`.\n- **Cost**: Time and memory usage are linear in the length of the index list.\n\n## Rationale: how does this CIP achieve its goals?\n\nBy batching multiple lookups into one builtin, `multiIndexArray`:\n\n- Eliminates repetitive script code for loops or folds over `indexArray`.\n- Reduces execution budget and size overhead of repeated builtins.\n- Guarantees elements are returned in caller-specified order, enabling efficient streaming or traversal.\n\n### Alternatives considered\n\n- **List of Maybe a**: Returning `Nothing` for out-of-bounds indices would require a `Maybe` builtin type, increasing complexity.\n- **Default value argument**: Allowing a default on lookup failure complicates strict evaluation and error detection.\n- **Slice and manual mapping**: Users could write a `slice` or fold, but this remains code-heavy and costly.\n- **Returning Array plus helper**: Have `multiIndexArray :: List Integer -> Array a -> Array a` return an `Array a` of selected elements and provide a new helper `arrayToList :: Array a -> List a`. This avoids constructing a list directly but requires adding `arrayToList` as a builtin and introduces extra conversion and costing complexity.\n\nFailing on first error mirrors `indexArray` and keeps the API simple.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] Merge implementation into the Plutus Core repo.\n- [ ] Update `cardano-ledger` costing parameters for `multiIndexArray`.\n- [ ] Integrate into `cardano-node` and schedule for a protocol upgrade.\n\n### Implementation Plan\n\n1. Add `multiIndexArray` to Plutus Core spec and runtime.\n2. Define preliminary cost model (linear in index list length for both CPU usage and memory usage).\n3. Write conformance tests covering valid and out-of-bounds cases.\n4. Extend an E2E test suite to include `multiIndexArray` scenarios.\n5. Benchmark against manual `indexArray` loops to refine costing.\n6. Update formal documentation (`plutus-metatheory`, spec PDF).\n7. Complete integration and include in the next hard fork.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0158/README.md",
    "content": "---\nCIP: 158\nTitle: Cardano URIs - Browse Application\nCategory: Wallets\nStatus: Proposed\nAuthors:\n    - Adam Dean <adam@crypto2099.io>\n    - Alex Dochioiu (VESPR Wallet) <alex@vespr.xyz> \nImplementors:\n    - VESPR Wallet (https://vespr.xyz)\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/1058\nCreated: 2025-07-17\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP proposes a new URI scheme authority, `browse`, under `web+cardano` to\nenable Cardano wallets to launch external or embedded applications and dApps\nwith the full path and context, using a standardized, interoperable URI format.\n\n## Motivation: why is this CIP necessary?\n\nToday, exploring dApps on Cardano — especially on mobile devices — is\ncumbersome. Most Cardano wallets with embedded browsers require users to\nmanually launch the wallet, open its browser, and type or paste full URLs to\nreach specific applications. This creates significant friction, particularly in\nreal-world scenarios like:\n\n* Trade shows or events promoting dApps\n* Point-of-sale terminals or vending machines using Cardano\n* Marketing campaigns linking directly to dApp actions\n\nThe goal of this CIP is to introduce a **deep-linking compatible method** that\nlets dApps and external actors provide QR codes or clickable links that:\n\n* Open the user’s preferred wallet automatically (via `web+cardano` handler)\n* Direct the wallet to launch its embedded browser or app view\n* Navigate directly to the intended dApp page or state without manual user input\n\nThis reduces friction, improves dApp discoverability, and creates a smoother\nexperience for both developers and end-users, particularly in mobile and\ncross-device contexts.\n\n### Security Benefits & Considerations\n\nThe existing process for transferring sessions and information between devices\nor from physical to digital is fraught with opportunity for accidents, errors,\nand malicious interception.\n\nExisting standards for `web+cardano://` URIs describe some rudimentary\ninteractions that may be automated by following the specification such as\nsending payment or claiming airdrops. However, no current standards exist to\neasily point a mobile user to a complex application that requires smart contract\ninteraction (for example).\n\nBy defining this standard to instantly transport the user from a browser or\nQR-based \"deeplink\" to a precise session or page within an application, we\nenable developers to build richer, safer, and more interactive experiences such\nas:\n\n* Showing a full \"checkout\" process and later \"receipt\" to the user on their\n  mobile device rather than simply a payment request out of context\n* Navigating users directly to complex application paths that would otherwise be\n  prone to user data-entry errors and typos\n\n## Specification\n\n#### ABNF Grammar\n\n``` \ncardanourn = \"web+cardano:\" authority\nauthority = \"//browse\" version\nversion = \"/v1\" pathquery\npathquery = ( \"?\" encodedpath)\nencodedpath = \"uri=\" text\n```\n\n### URI Format\n\n```\nweb+cardano://browse/<version>?uri=<percent_encoded_uri>\n```\n\n* **authority (REQUIRED):** `browse`\n* **version (REQUIRED):** `v1`\n* **percent_encoded_uri (REQUIRED):** percent-encoded URI (only `http` and `https` scheme is supported. If no scheme is defined, `https` scheme is assumed)\n\n### Versioning\n\nThis document describes `Version 1` of this specification. Once this CIP is\nmerged and canonized as `Accepted` this `Version 1` should no longer be modified\nto avoid potentially introducing breaking changes with legacy integrations.\n\nInstead, those seeking to amend, extend, or modify the `browse` authority should\nintroduce a new CIP that iterates this standard and increments the Version\nNumber by a single whole integer value (i.e., the next CIP will be `Version 2`).\n\nExtensions to this standard should follow whatever accepted criteria exist at\nthe time of their authoring in terms of acceptance and adoption.\n\n### Example URIs\n\nWeb app (SundaeSwap ADA <=> USDM Trading Page):\n\n```\nweb+cardano://browse/v1?uri=https%3A%2F%2Fapp.sundae.fi%2Fexchange%3Fgiven%3Dada.lovelace%26taken%3Dc48cbb3d5e57ed56e276bc45f99ab39abe94e6cd7ac39fb402da47ad.0014df105553444d%26routeIdent%3D64f35d26b237ad58e099041bc14c687ea7fdc58969d7d5b66e2540ef\n```\n\nLocal development app (HTTP localhost with port):\n\n```\nweb+cardano://browse/v1?uri=http%3A%2F%2Flocalhost%3A3000%2FdevPage\n```\n\n### Wallet Behavior\n\n* Parse and validate version, scheme, and domain.\n* Forward the entire app-specific path and query string to the app.\n* Suggested allowlist/blocklist and security policies:\n    * Each wallet may optionally implement its own allowed list of trusted \n      domains where navigation would not require explicit permissions\n    * Each wallet may optionally implement a blacklist of known untrusted \n      domains where the user would be shown a clear warning that the website is \n      known to be malicious. With very explicit user permission user should \n      still be allowed to navigate.\n    * For domains outside an allowlist/blacklist, wallet may want to show a \n      warning and request explicit permission before navigating. This is to \n      prevent unwanted IP / device info / other data exfiltration which can be \n      obtained simply by loading a webpage\n\n### Security Considerations\n\n* Wallets SHOULD prompt users before launching non-allowlisted or unsafe\n  schemes.\n* Wallets cannot automatically determine whether query parameters contain\n  sensitive or user-specific data; app developers are responsible for ensuring\n  that no long-lived secrets or sensitive information are embedded in shared\n  links.\n* Wallets SHOULD provide a clear UI to inform users of the destination and allow\n  cancellation before proceeding.\n* dApp developers SHOULD design links and query parameters with privacy and\n  security in mind, using short-lived or ephemeral tokens where needed and avoid\n  embedding sensitive user data.\n\n## Rationale: how does this CIP achieve its goals?\n\nA dedicated `browse` authority isolates app navigation and launch intents from\npayment or metadata intents, improving clarity and interoperability.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] At least two major Cardano wallets implement support for the browse\n  authority in web+cardano URIs, including launching its embedded browser with\n  the specified path.\n- [ ] Demonstrable user success in navigating from a mobile device (e.g., native\n  camera or link) into a wallet and then directly into the dApp or application\n  flow.\n- [ ] Positive feedback or validation from the community or wallet/dApp\n  developers confirming interoperability.\n\n### Implementation Plan\n\n- [X] Publish and socialize the CIP draft for feedback from wallet and dApp\n  developers.\n- [X] Develop a reference implementation or demo prototype showing browse URI\n  handling in at least one wallet.\n    - Reference Implementation: https://github.com/crypto2099/cardano-uri-parser\n    - NPM Package: https://www.npmjs.com/package/cardano-uri-parser\n- [ ] Write integration guides or example code for wallet and dApp developers.\n- [ ] Monitor ecosystem adoption and collect feedback for potential refinements\n  or amendments to the standard.\n\n## Copyright\n\nThis CIP is licensed\nunder [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)."
  },
  {
    "path": "CIP-0159/README.md",
    "content": "---\nCIP: 159\nTitle: Account Address Enhancement\nCategory: Ledger\nStatus: Proposed\nAuthors:\n    - fallen-icarus <modern.daidalos@gmail.com>\n    - George Flerovsky <george.flerovsky@gmail.com>\nImplementors: N/A\nDiscussions: \n    - https://github.com/cardano-foundation/CIPs/pull/1061\n    - https://github.com/IntersectMBO/cardano-ledger/issues/5474\nCreated: 2025-07-16\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nCurrently, Cardano's account addresses (a.k.a. reward addresses) can only be used for receiving ADA\nfrom the Cardano protocol (e.g., staking rewards). Users are not allowed to deposit assets into\nthese addresses. By removing this restriction, and enabling very specific plutus script support,\nCardano can unlock new use cases **without sacrificing local determinism**. And by still requiring\nUTxO inputs in transactions, these accounts avoid many of the pitfalls from Ethereum-style accounts.\n\n## Motivation: why is this CIP necessary?\n\nConsider the following use cases:\n\n### Wallet Revenue\n\nImagine a Cardano wallet that wants to charge a fee in a transaction it generates for a user. Right\nnow, the `minUTxOValue` network parameter (now called `utxoCostPerByte`) disallows UTxOs with less\nthan ~1 ADA. So if the wallet just had the user send the money to them directly, **the smallest fee\nthey could charge is ~1 ADA**. When the average transaction fee is only about [0.39\nADA](https://cardanoscan.io/analytics/dailyTxCountAndFees), it is hard to justify paying an extra 1\nADA on top.\n\n*What if the wallet wanted to charge only 0.1 ADA? How could it get this 0.1 ADA from the user?*\n\nThe current method is to have the user deposit 1 ADA into a UTxO for the wallet provider. Then,\nwhenever the user needs to pay 0.1 ADA, this *deposit UTxO* would be spent to accumulate the 0.1 ADA.\nThis UTxO is effectively a \"fee bucket\" for that user.\n\nWhile this method works, it has a few downsides:\n\n1. It creates a bad UX since features are now gated behind different deposits that need proper\n   management (with smart contracts for trustlessness).\n2. What if the user wants to close out their deposit UTxO? If the deposit UTxO has less than 2 ADA\n   (e.g., 1.5 ADA), the amount above 1 ADA (e.g., 0.5 ADA) needs to be sent to the wallet provider\nwhich isn't possible due to the `minUTxOValue`! This complicates the reclamation process for user\ndeposits.\n3. The wallet provider needs to manage one deposit UTxO per user which doesn't scale: withdrawing\n   the accumulated fees requires spending one UTxO per user! (Having fewer UTxOs than users will\ncause UTxO contention.)\n\n**All of these problems go away if the wallet provider can just have the user deposit 0.1 ADA into\nthe designated account address!** By being able to charge much smaller fees, Cardano wallets will\nhave a significantly easier time finding product-market fit.\n\n> [!IMPORTANT]\n> In order for direct deposits to actually be useful, *partial withdrawals are a fundamental\n> requirement*. To see why, imagine a wallet charges a 0.1 ADA fee per transaction and these\n> transactions are submitted every 30 seconds. Currently, the ledger rules require the wallet to\n> withdraw the full balance in the account address. Let's say when the wallet submits the withdrawal\n> transaction, the balance is 100 ADA. While this transaction is sitting in the mempool, another\n> user directly deposits another 0.1 ADA into the wallet's account address. Now the wallets\n> transaction in the mempool is *not* withdrawing the full amount and will fail phase 1 validation!\n> Without partial withdrawals, whether the wallet will actually be able to access the assets in the\n> account will depend on luck!\n\n### Cheaper Batchers/Aggregators\n\nMost batcher/aggregator networks charge at least 1 ADA. For some, the reason is the `minUTxOValue`\nrequirement. If it was actually possible to charge smaller fee amounts, Cardano's DeFi would be much\ncheaper!\n\n### Multi-Asset Cardano Treasury\n\nCardano's Treasury account is currently only allowed to hold ADA. However, it would be more fiscally\nresponsible for the Treasury to hold a basket of assets. The basket would diversify the risk of\nprice fluctuations and ensure that important protocol developments can continue despite price shocks\nin any particular asset class.\n\n> [!NOTE]\n> This CIP only lays *some* of the groundwork for a Cardano Multi-Asset Treasury.\n\n### Decentralized Fixed-Supply Token Minting\n\nImagine you only wanted to have 1 million units of a token minted. How can you keep a global count\nwhile supporting decentralized minting? Currently, you can't. But what if users needed to deposit 1\n\"count\" token into an account address for every unit of the target token minted? The account\naddress' balance of the \"count\" token would be the global count! Since addition is commutative, the\ntransactions that mint the tokens can be processed in any order and fully parallel.\n\n> [!IMPORTANT]\n> In order to prevent actually needing global state, this CIP proposes account balance *intervals*.\n> For example, the transaction to mint another token is only valid if the current account's balance\n> is *less than 1 million*. Checking intervals can be done cheaply in Phase 1 validation just like\n> with time (a.k.a. slot intervals). Plutus scripts will be able to see the interval constraints as\n> part of their contexts.\n\nBy using account balance intervals, incrementing the account's balance doesn't invalidate other\ntransactions until the interval's upper bound is met.\n\n### L2 reserves\n\nMost L2s (e.g. Midgard) need to manage huge reserves of the L1 ADA from the users in the L2.\nInitially, users typically create \"deposit\" event UTxOs; but eventually, the L2 will process these\ndeposits and move the ADA into a \"reserve UTxO\". Since the reserve itself is a UTxO, there may be\ncontention issues around how it is managed.\n\n*With this CIP, L2s can process the deposit event UTxOs by depositing the ADA into an account\naddress.*\n\n## Specification\n\n### Definitions\n\nFor clarity:\n  - *Protocol Deposit* will refer to the deposits required by the protocol for registration (either\n  delegation registration or whitelist registration).\n  - *Direct Deposit* will refer to assets being sent to an account address.\n\n### Enable Direct Deposits\n\nThe ledger rules currently disallow directly depositing assets into account addresses. This\nrestriction will be lifted to support direct deposits. The transaction balancing rules will need to\nbe updated to consider these direct deposits.\n\n**Direct depositing into an account address does not require a witness from the receiving account.**\nIn other words, the receiving staking script does *not* need to be executed. This behavior mirrors\nhow UTxOs can be created at script addresses without having to execute the spending script.\n[CIP-0160](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0160) could enable requiring a\nwitness for direct deposits as an opt-in feature.\n\n> [!IMPORTANT]\n> In order to support direct deposits, the account address must be registered.\n\nBy default, only direct deposits of ADA are supported. Pre-existing registered account addresses\nwill be automatically upgraded to support direct deposits of ADA through a hardfork-combinator\nevent. \n\nUsers will be able to submit a new certificate event (`stake_credential_adjust_whitelist`), which will\ninitialize the balances of certain native assets (listed in the certificate) at an account address,\nstarting all of the balances at zero. After these balances are initialized, users will be able to\ndirect-deposit those native assets into that account.\n\nThe set of initialized balances at an account also acts as a **whitelist** on the native assets\nallowed at the account. Direct deposits of other native assets into the account will be rejected by\nthe ledger rules, except for ADA, which can always be deposited into any Cardano account.\n\n> [!IMPORTANT]\n> For clarity, this CIP will introduce a new ledger type called `AccountValue`, which is similar to\n> `Value` but prevents adding or removing assets in the `AccountValue`. You can only increase or\n> decrease the asset quantities. If a transaction tries directly depositing a native asset that is\n> not found in the `AccountValue`, it will fail phase 1 validation.\n>\n> **This type is only to help explain the invariants!** It is up to the ledger team to decide how to\n> actually implement this functionality.\n\nThe only way to alter which native assets are found in the `AccountValue` is through another\ndedicated certificate event. The new certificate is outlined below:\n\n```cddl\nadd_to_whitelist = multiasset\nremove_from_whitelist = multiasset\n\n; stake_credential - account that will have the whitelist adjusted\n; delta_coin - change in deposit from what the current deposit is in the system\n;              it can be negative (in case whitelist shrinks in size) or\n;              positive (in case when the size is increased)\n; add_to_whitelist - multiassets to be added to the whitelist\n; remove_from_whitelist - multiassets to be removed from the whitelist\nstake_credential_adjust_whitelist = \n  (19, stake_credential, delta_coin, add_to_whitelist, remove_from_whitelist)\n\ncertificate = \n  [  stake_registration\n  // stake_deregistration\n  // stake_delegation\n  ...\n  // stake_credential_adjust_whitelist\n  ]\n```\n\nThe `stake_credential_adjust_whitelist` certificate is an *idempotent* insert/remove operation on\nthe `AccountValue` whitelist. Note a few important points:\n\n1. Removing an asset from the whitelist requires withdrawing all of that asset from the account in\n   the same transaction.\n2. When an asset is added to the whitelist, it is not possible to direct deposit that asset in the\n   same transaction ([CIP-0118](https://github.com/cardano-foundation/CIPs/pull/862) can be used to\n   get around this restriction: one sub-tx updates the whitelist while a subsequent sub-tx makes the\n   direct deposit.)\n3. You cannot add and remove the same asset in one transaction (i.e., the `add_to_whitelist` and\n   `remove_from_whitelist` fields cannot intersect).\n\nThe benefits of this idempotent diffing approach are four-fold:\n\n1. **Proof of Inclusion/Exclusion:** The `stake_credential_adjust_whitelist` can be used to assert\n   that an asset is or is not present in the whitelist.\n2. **Large Whitelists:** A large whitelist can be built up over several transactions which enables\n   whitelists that are larger than the transaction's size limit.\n3. **Efficiency:** Updating only part of a whitelist is significantly cheaper than having to\n   re-certify the entire whitelist every time.\n4. **Improved Decentralized Governance:** It enables breaking up the approval process of a\n   whitelist into digestible pieces. If a community could only vote on the *full* whitelist, it\n   could be rejected just because one asset in the whitelist is contentious. This approach enables\n   voting on each asset independently.\n\nCrucially, since the `AccountValue` will take up space in memory, it must be accompanied with an\nextra protocol deposit that is proportional to the size of the `AccountValue`. This extra protocol\ndeposit must be paid in the transaction using the `stake_credential_adjust_whitelist`. A new\nparameter `accountWhitelistCostPerByte` will be needed.\n\n> [!NOTE]\n> With UTxOs, the minUTxO protocol deposit is paid by the creator of the UTxO. With account\n> addresses, the `AccountValue` protocol deposit will be paid upfront by the address owner. This is\n> what enables the micropayments discussed in the [Motivation section](#motivation-why-is-this-cip-necessary).\n\nFor this to work, the transaction representation needs a new direct deposit field:\n\n```cddl\ndirect_deposits = {+ reward_account => value}\n\ntransaction_body = \n  {   0  : set<transaction_input>         \n  ,   1  : [* transaction_output]      \n  ,   2  : coin                            \n  , ? 3  : slot_no                         \n  , ? 4  : certificates                    \n  , ? 5  : withdrawals                     \n  ...\n  , ? 23 : direct_deposits ; new field\n  }\n```\n\n> [!TIP]\n> *Why not just make withdrawals support negative numbers?*\n>\n> 1. It would cut in half the maximum supported number.\n> 2. Withdrawals require witnesses while direct deposits do not. This means we need to be able to\n>    distinguish between direct deposits and withdrawals for the `ScriptPurpose`.\n>\n> Adding a separate field is the better approach.\n\nPlutus scripts will be able to see the direct deposits occuring in the transaction as part of their\n`ScriptContext`. See the [New Plutus Script Context section](#new-plutus-script-context).\n\n> [!IMPORTANT]\n> The direct deposits are only the diff! If the account currently has 100 ADA and the transaction is\n> direct depositing another 0.1 ADA, the transaction only needs to specify 0.1 ADA.\n\n### Partial Withdrawals and Native Asset Withdrawals\n\nThe ledger rules *must* be changed to allow withdrawing any amount between 0 and the current\nbalance. \n\n> [!IMPORTANT]\n> For all withdrawals, partial or full, the pre-existing `Withdraw` purpose will be used. We do not\n> need a dedicated purpose for partial withdrawals.\n\nTo enable support for withdrawing native assets from account addresses, the representation of\nwithdrawals inside transactions needs to be updated:\n\n```cddl\n; Old representation.\nwithdrawals = {+ reward_account => coin}\n\n; New representation.\nwithdrawals = {+ reward_account => value} ; replaced `coin` with `value`\n```\n\n> [!IMPORTANT]\n> Partial withdrawals will only be possible in transactions *without* plutus v1-v3 scripts. However,\n> [CIP-0118](https://github.com/cardano-foundation/CIPs/pull/862) can help here by isolating the\n> partial withdrawal in a sub-tx.\n\n> [!IMPORTANT]\n> When CIP-0118 is implemented, sub-txs can deposit/withdraw from the same account. If this is\n> naively supported, it can *look* like native assets are minted out of thin air. For example, if\n> the first sub-tx withdraws 1 million ADA and the second sub-tx deposits 1 million ADA, the overall\n> transaction is properly balanced and no ADA is actually minted (the value cancels out), but plutus\n> scripts inside the sub-txs can possibly be tricked. To prevent these *Phantom Asset* attacks,\n> transactions can only withdraw funds that exist in the account *before* the overall transaction\n> is run. This means later sub-txs cannot withdraw assets that were deposited by prior sub-txs in\n> the same overall transaction. This restriction will be enforced as part of Phase 1 Validation.\n\n### Account Balance Intervals\n\nTransactions can specify account balance intervals similarly to how time intervals are set. In order\nfor the transaction to be phase 1 valid, the actual balance for the associated asset in the account\n*must* fall within the specified interval. The transaction representation is shown below:\n\n```cddl\n; We don't want to allow arbitrary precision intervals because it would make\n; costing difficult so we constrain them to be 8-byte integers. \nbalance_bound = uint .size 8\n\nrequired_balance_interval<b> =\n  [ inclusive_lower_bound: b, exclusive_upper_bound: b / nil ] /\n  [ inclusive_lower_bound: b / nil, exclusive_upper_bound: b ]\n\n; Note that when multi-asset interval is supplied, interval for ADA is optional\naccount_balance_interval =\n  required_balance_interval<coin> /\n  [ inclusive_lower_bound: coin / nil\n  , exclusive_upper_bound: coin / nil\n  , {+ policy_id => {+ asset_name => required_balance_interval<balance_bound> } }\n  ] \n\naccount_balance_intervals = \n  { + reward_account => account_balance_interval }\n\ntransaction_body = \n  {   0  : set<transaction_input>         \n  ,   1  : [* transaction_output]      \n  ...\n  , ? 24 : account_balance_intervals ; new field\n  }\n```\n\nAs the representation shows, the transaction submitter can specify intervals for different assets\ninside a given account address. In addition to this, there are a few important behaviors that need to\nbe mentioned:\n\n1. Using the account balance interval does *not* require a witness from the associated credential.\n2. To declare that a certain asset in the `AccountValue` has a specific balance of `n`, the asset's\n   balance interval must be set to `[n, n+1)`.\n3. If the account balance interval is used for an asset not supported in the current whitelist, the\n   transaction will fail *Phase 1 Validation*.\n\nPlutus scripts will be able to see the set account balance intervals as part of their\n`ScriptContext`. See the [New Plutus Script Context section](#new-plutus-script-context).\n\n### New Ledger State\n\nCurrently, account address state is [stored in the ledger](https://github.com/IntersectMBO/cardano-ledger/blob/3fa847bd67a6d1c3c2d5960578c993487e9883b0/eras/conway/impl/src/Cardano/Ledger/Conway/State/Account.hs#L45) as:\n\n```haskell\ndata AccountState era\n  = AccountState\n  { balance :: !(CompactForm Coin)\n  -- ^ Current balance of the account\n  , deposit :: !(CompactForm Coin)\n  -- ^ Deposit amount that was left when staking credential was registered\n  , stakePoolDelegation :: !(StrictMaybe (KeyHash 'StakePool))\n  -- ^ Potential delegation to a stake pool\n  , dRepDelegation :: !(StrictMaybe DRep)\n  -- ^ Potential delegation to a DRep\n  }\n```\n\nThis CIP proposes changing this ledger state to:\n\n```haskell\ndata AccountState era\n  = AccountState\n  { balance :: !(CompactForm (AccountValue era))\n  -- ^ Current multi-asset balance of the account.\n  , deposit :: !(CompactForm Coin)\n  -- ^ Total deposit amount from the staking credential registration *and* the account whitelist.\n  , stakePoolDelegation :: !(StrictMaybe (KeyHash 'StakePool))\n  , dRepDelegation :: !(StrictMaybe DRep)\n  }\n```\n\nThere are a few important points to notice:\n\n1. The `deposit` field holds *both* the stake credential registration deposit *and* the whitelist\n   registration deposit.\n2. The `balance` map *is the whitelist*. Therefore, direct deposits/withdrawals can only\n   increase/decrease the `Integer`; only the `stake_credential_adjust_whitelist` can add/remove\n`PolicyID`s or `AssetName`s from the map. If an asset in the whitelist has no balance, the\n`Integer` should be set to `0`.\n\n> [!IMPORTANT]\n> The required protocol deposit for the whitelist registration will be proportional to the in-memory\n> representation of the multi-assets in the whitelist. The calculation can be similar to the\n> `minUTxOValue` calculation, but it should get separate protocol parameters so that the\n> whitelist costing can be changed independently to the `minUTxOValue` costing.\n\n### New Plutus Script Context\n\nThis CIP does not introduce any new `ScriptPurpose`s, but the `TxInfo` field needs to contain the\nnew sub-fields:\n\n```haskell\ndata BalanceInterval\n  = InclusiveLowerBoundOnly Integer\n  | ExclusiveUpperBoundOnly Integer\n  | InclusiveLowerExclusiveUpperBounds Integer Integer\n\ndata TxInfo = TxInfo\n  { txInfoInputs                :: [TxInInfo]\n  , txInfoReferenceInputs       :: [TxInInfo]\n  , txInfoOutputs               :: [TxOut]\n  , txInfoFee                   :: Value\n  , txInfoMint                  :: Value\n  , txInfoTxCerts               :: [TxCert]\n  , txInfoWdrl                  :: Map Credential Value -- ^ Upgraded field.\n  , txInfoValidRange            :: POSIXTimeRange\n  ... \n  , txInfoDirectDeposits        :: Map Credential Value -- ^ New field.\n  , txInfoBalanceIntervals      :: Map Credential (Map PolicyID (Map AssetName BalanceInterval)) -- ^ New field. \n  }\n```\n\nThe `TxInfo` uses `Value` instead of `AccountValue` because the invariants are checked at the ledger\nlevel. By using `Value` in smart contracts, this CIP can take advantage of the new `BuiltinValue`\ntype introduced in [CIP-153](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0153).\n\n> [!IMPORTANT]\n> In order for contemporary DeFi to be able to charge lower fees with this CIP, **direct deposits\n> must be supported in transactions using smart contracts from prior plutus versions.** To enable\n> this backporting without introducing security vulnerabilities in older smart contracts, older\n> plutus scripts will be supported in the top-level of a nested transaction\n> ([CIP-0118](https://github.com/cardano-foundation/CIPs/pull/862)). Then these new transaction\n> fields can be isolated inside a sub-transaction.\n\n### Phased Delivery\n\nIn order to expedite delivery of this CIP, development will be broken over two phases/eras. \n\n#### Phase 1: ADA Support\n\nThis phase only adds support for ADA because it will be very quick to implement. ADA support is\nenough to enable wallets, DEX aggregators, and DePIN infrastructure to offer lower fees since they\nare all forced to charge *~1 ADA* due to the `minUTxOValue` requirement.\n\n**Ledger Rule Changes**\n1. Deposit ADA into account addresses.\n2. Partial withdrawals from account addresses in sub-transactions, or in a top-level transaction\n   but only when plutus v1-v3 scripts are not used in it.\n3. Account balance intervals validated as part of *Phase 1 Validation*.\n\n**CDDL Changes**\n```cddl\n; The withdrawals field is left unchanged.\n\n; Same definition as current withdrawals.\ndirect_deposits = {+ reward_account => coin}\n\naccount_balance_intervals = \n  { + reward_account => \n        [ inclusive_lower_bound: coin, exclusive_upper_bound: coin / nil ]  /\n        [ inclusive_lower_bound: coin / nil, exclusive_upper_bound: coin ] \n  }\n\ntransaction_body = \n  {   0  : set<transaction_input>         \n  ,   1  : [* transaction_output]      \n  ...\n  , ? 23 : direct_deposits ; new field\n  , ? 24 : account_balance_intervals ; new field\n  }\n```\n\n**Plutus Script Context**\n\nThe plutus script context will be pre-emptively upgraded to support the fields needed in the second\ndelivery phase. This way the features can be turned on with a hardfork and plutus scripts written\nfor the first delivery phase can immediately take advantage of the new features without having to be\nrecompiled.\n\n```haskell\ndata BalanceInterval\n  = InclusiveLowerBoundOnly Integer\n  | ExclusiveUpperBoundOnly Integer\n  | InclusiveLowerExclusiveUpperBounds Integer Integer\n\ndata TxInfo = TxInfo\n  { txInfoInputs                :: [TxInInfo]\n  , txInfoReferenceInputs       :: [TxInInfo]\n  , txInfoOutputs               :: [TxOut]\n  , txInfoFee                   :: Value\n  , txInfoMint                  :: Value\n  , txInfoTxCerts               :: [TxCert]\n  , txInfoWdrl                  :: Map Credential Value -- ^ Upgraded field.\n  , txInfoValidRange            :: POSIXTimeRange\n  ... \n  , txInfoDirectDeposits        :: Map Credential Value -- ^ New field.\n  , txInfoBalanceIntervals      :: Map Credential (Map PolicyID (Map AssetName BalanceInterval)) -- ^ New field. \n  }\n```\n\n> [!IMPORTANT]\n> In order for the community to get the benefits from this CIP, plutus v1-v3 scripts must be\n> allowed in transactions that contain the new `direct_deposits` field. To accomplish this,\n> plutus v1-v3 scripts will be allowed to run inside the top-level of a nested transaction\n> ([CIP-0118](https://github.com/cardano-foundation/CIPs/pull/862)). Then the `direct_deposits`\n> field can be safely isolated inside a sub transaction.\n\n#### Phase 2: Multi-Asset Support\n\nThis phase will add support for native asset deposits and whitelist certificates which will pave the\nway for a Cardano Multi-Asset Treasury, simplify L2 reserve management, and enable more\ndecentralized voting mechanisms.\n\n**Ledger Rule Changes**\n1. Deposit native assets into account addresses.\n2. Withdraw native assets from account addresses.\n3. Whitelist certificates (and extra protocol deposits) for account addresses.\n\n**New Protocol Parameter**\n- `accountWhitelistCostPerByte` which is similar to the current `utxoCostPerByte`.\n\n**CDDL Changes**\n```cddl\nadd_to_whitelist = multiasset\nremove_from_whitelist = multiasset\n\n; stake_credential - account that will have the whitelist adjusted\n; delta_coin - change in deposit from what the current deposit is in the system\n;              it can be negative (in case whitelist shrinks in size) or\n;              positive (in case when the size is increased)\n; add_to_whitelist - multiassets to be added to the whitelist\n; remove_from_whitelist - multiassets to be removed from the whitelist\nstake_credential_adjust_whitelist = \n  (19, stake_credential, delta_coin, add_to_whitelist, remove_from_whitelist)\n\n; New representation: replaced `coin` with `value`.\nwithdrawals = {+ reward_account => value}\n\n; New representation: replaced `coin` with `value`.\ndirect_deposits = {+ reward_account => value}\n\n; New representation: replaced `coin` with `balance_bound` and enables individual\n; intervals for each asset.\nbalance_bound = uint .size 8\n\nrequired_balance_interval<b> =\n  [ inclusive_lower_bound: b, exclusive_upper_bound: b / nil ] /\n  [ inclusive_lower_bound: b / nil, exclusive_upper_bound: b ]\n\n; Note that when multi-asset interval is supplied, interval for ADA is optional\naccount_balance_interval =\n  required_balance_interval<coin> /\n  [ inclusive_lower_bound: coin / nil\n  , exclusive_upper_bound: coin / nil\n  , {+ policy_id => {+ asset_name => required_balance_interval<balance_bound> } }\n  ] \n\naccount_balance_intervals = \n  { + reward_account => account_balance_interval }\n```\n\n**New `AccountState`**\n```haskell\ndata AccountState era\n  = AccountState\n  { balance :: !(CompactForm (AccountValue era))\n  -- ^ Current multi-asset balance of the account.\n  , deposit :: !(CompactForm Coin)\n  -- ^ Total deposit amount from the staking credential registration *and* the account whitelist.\n  , stakePoolDelegation :: !(StrictMaybe (KeyHash 'StakePool))\n  , dRepDelegation :: !(StrictMaybe DRep)\n  }\n```\n\n## Rationale: how does this CIP achieve its goals?\n\nThis CIP is able to upgrade Cardano's account addresses to full accounts *without* sacrificing local\ndeterminism and *without* introducing the issues seen with Ethereum-style accounts. The reasons for\nthis are based on what this CIP *does not* enable, more than on what it does enable. The most\nimportant things are:\n\n- This CIP *does not* enable submitting transactions without UTxO inputs.\n- This CIP *does not* enable attaching datums to account addresses.\n- This CIP *does not* enable phase-2 scripts to view the **exact** account balance, except when the\nbalance interval is set to the exact value (making this feature *opt-in*).\n- This CIP *does not* enable directly depositing arbitrary native assets into account addresses.\nOnly whitelisted native assets are allowed (i.e. native assets with balances initialized at the\naccount).\n\n### Still Require UTxO Inputs\n\nOn Ethereum, every address has an integer nonce that must be incremented after each account event.\nThis integer is required to prevent replay attacks (e.g., it ensures transactions are processed in\nthe right order), but it has the downside of causing contention - if two Ethereum transactions try\nto withdraw using the same nonce integer, only one will succeed. The problem is that the nonce is\nintrinsic to the account.\n\nSince each Cardano transaction must include a UTxO, the UTxO's output reference acts as a nonce.\nChanging the order of the Cardano transactions does not matter as long as the UTxOs actually exist.\nThis means withdrawing from Cardano account addresses *does not* experience contention. Both Alice\nand Bob can each submit a transaction withdrawing from an account address, and these transactions\ncan be processed in any order.\n\n### No Datum Support\n\nConsider the decentralized minting example: what if each user needed to update the datum after each\naccount deposit? The datum itself would be a source of contention in the same way the integer nonce\nis for Ethereum.\n\nIf an account *needs* data for its validation, it can use a datum attached to an existing UTxO.\nUTxOs are the perfect medium for controlling access to data and they enable breaking the data into\nchunks. If an account only needs a piece of the available data, it can reference a UTxO with *just*\nthat data. Storing the data with the account would require processing *all* of the stored data, even\nthe parts that aren't necessary for a given execution. In short, using the datums attached to UTxOs\nis much more efficient.\n\n### No Exact Balance View\n\nEnforcing plutus scripts to view the account's exact balance would require sacrificing Cardano's\nlocal determinism. If Alice submits a transaction at time `t0` where the account's balance is 100\nADA and then the transaction gets processed at time `t1` when the account balance is 1000 ADA, the\nsmart contracts in the transaction use different numbers in there executions. This can result in\ncompletely different execution budget usages which results in completely different fees. Same\ntransaction; different fees.\n\nBy using the account balance intervals instead, Alice's transaction would get the same inputs at\n`t0` and `t1`. As long as the intervals are still satisfied, it does not matter that the account\nbalance has actually changed. Both executions result in the same execution budget usages and\ntherefore, the same fees. Cardano's local determinism is preserved.\n\n### Whitelisted Native Assets Only\n\nThe reason Cardano has a `minUTxOValue` requirement is to prevent native asset dusting attacks - a\nmalicious person can create worthless tokens and create UTxOs with *only* these assets or create\nUTxOs with no assets at all. When block producers try to validate transactions, they need to load\nthe UTxOs into memory. If the size of these UTxOs are not somehow tied to real world resource\nconstraints, the malicious actors can cause block producer memory usages to explode with these\nworthless/valueless UTxOs taking up space. This is effectively a DDoS attack. By requiring every\nUTxO to contain a minimum of ADA, a malicious actor is only able to cause this attack if they\nactually have the required amount of ADA to back the memory usage required to process the native\nasset values.\n\nIf account addresses could accept arbitrary native assets like UTxOs, they would be susceptible to\nthe same dusting attacks. A first thought might be to have a `minUTxOValue`-like protocol deposit\nfor account addresses - the person depositing the native asset into the account would need to cover\nthis protocol deposit. But this would actually prevent the account addresses from being used for\nsome of the use cases discussed in the [Motivation section](#motivation-why-is-this-cip-necessary).\nConsider if a wallet was charging 0.1 ADA per transaction and decides to accept a stablecoin as\npayment instead. The protocol deposit could be more than 1 ADA which is 10x the amount the wallet\nwanted to charge! Users will not pay the fees in stablecoins if using ADA instead is 10x cheaper!\n\nSo the goal is to prevent dusting attacks while still allowing micropayments using non-ADA assets.\nThat is why the whitelist is used. The account address owner covers the protocol deposit for the\nnative assets they are interested in and now users can direct deposit those native assets into the\naccount without having to also cover a protocol deposit. The account address owner would not be able\nto cover the protocol deposit if they did not know which native assets would be deposited ahead of\ntime, so this approach only works with a whitelist.\n\n## Path to Active\n\n### Acceptance Criteria\n- [ ] These rules included within an official Plutus and Ledger version, and released via a major hard fork.\n- [ ] These changes have acknowledgement from infrastructure parties (e.g., wallets, indexers,\noff-chain library maintainers, smart contract language maintainers, L2 builders, etc.).\n      \n### Implementation Plan\n- [ ] Passes all requirements of both Plutus and Ledger teams as agreed to improve utility of\naccount addresses.\n- [ ] Each phase is implemented either together or in separate Cardano eras:\n    - [ ] Delivery Phase 1: ADA Support\n    - [ ] Delivery Phase 2: Multi-Asset Support\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0160/README.md",
    "content": "---\nCIP: 160\nTitle: Receiving Script Purpose and Addresses\nCategory: Ledger\nStatus: Proposed\nAuthors:\n    - Philip DiSarro <philipdisarro@gmail.com>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/1063\nCreated: 2025-07-24\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP proposes the introduction of a new Address type, `ProtectedAddress`, and a corresponding `Receiving` script purpose. This enhancement allows a smart contract to validate not only UTxO spends from its address, but also UTxO creations to its address. The lack of such a mechanism today forces developers to implement complex workarounds involving authentication tokens, threaded NFTs, and registry UTxOs to guard against unauthorized or malformed deposits. This CIP aims to provide a native mechanism to guard script addresses against incoming UTxOs, thereby improving protocol safety, reducing engineering overhead, and eliminating a wide class of vulnerabilities in the Cardano smart contract ecosystem.\n\n## Motivation: why is this CIP necessary?\n\nIn Cardano’s current eUTxO model, smart contracts can enforce logic only when their locked UTxOs are being spent. They have no ability to reject or validate UTxOs being sent to them. This leads to a fundamental weakness: anyone can send arbitrary tokens and datum to a script address, potentially polluting its state or spoofing valid contract UTxOs. To mitigate this, developers today must:\n\n- Mint authentication tokens\n- Use threading tokens to track contract state\n- Build registry systems with always-fails scripts\n- Validate datums defensively with token-datum context coupling\n\nThese workarounds add significant complexity, on-chain cost, and surface area for bugs. A native mechanism to guard UTxO creations at a script address would eliminate the need for most of these patterns.\n\n## Specification\nWe propose:\n\n1. **A new address type**:\n\n    ```haskell\n    data Address = \n      Address\n        { addressCredential         :: Credential\n        -- ^ the payment credential\n        , addressStakingCredential  :: Maybe StakingCredential\n        -- ^ the staking credential\n        }\n      ProtectedAddress -- new \n        { address :: Credential \n        , addressStakingCredential  :: Maybe StakingCredential \n        }\n    ```\n\n2. **A new `ScriptPurpose`:**\n\n    ```haskell\n    data ScriptPurpose =\n        Spending TxOutRef\n    | Minting CurrencySymbol\n    | Certifying DCert\n    | Rewarding StakingCredential\n    | Voting Vote\n    | Proposing Proposal\n    | Receiving ScriptHash         -- NEW: only output(s) to script\n    ```\n\nNormal addresses and protected addresses are differentiated by the introduction of an `isProtected` bit in the address header bytes, if the bit is set then the address is a protected address, otherwise it is unprotected.  \n\n### Receiving validation rule\n\nAny output to a protected address requires the witness for the payment credential of that address to be provided in the transaction. For outputs to protected addresses with public key payment credentials this means the transaction must be signed \nby the owner of that public key. For outputs to protected addresses with plutus script payment credentials this means the associated plutus script must be executed in phase-2 validation. \n\nDuring phase-2 script validation, for each transaction output to a `ProtectedAddress`, with a script payment credential the associated script must be executed using the script purpose:\n\n- `Receiving` is used when the transaction includes an output to a `ProtectedAddress` where the payment credential is a script.\n\nIf any `Receiving` script **fails** during evaluation, the **entire transaction is invalid** and is rejected during phase-2 validation. \n\n### CDDL Extension\n\n```cddl\n; Extend ScriptPurpose with Receiving\nredeemer_tag =\n    0 ; spend    \n  / 1 ; mint     \n  / 2 ; cert     \n  / 3 ; reward   \n  / 4 ; voting   \n  / 5 ; proposing\n  / 6 ; receiving   ; NEW: script validates output creation to a ProtectedAddress\n```\n\n## Rationale: how does this CIP achieve its goals?\n\nThe proposed `ProtectedAddress` and `Receiving` script purpose solve the long-standing problem of uncontrolled UTxO injection at script addresses. By giving smart contracts the ability to validate outputs being sent to them during phase-2 validation, developers can:\n\n- Ensure only valid state transitions or authenticated deposits are accepted\n- Enforce access control and structural correctness of datums before a UTxO is created\n- Remove the need for workaround patterns such as:\n  - Authentication tokens\n  - Threading/state tokens\n  - The issues from cyclic depenencies that are inherent in both of the above. \n\nThis CIP is also forward-compatible and additive. Existing contracts using unprotected `Address` remain unaffected. Contracts that require guarded output validation may opt-in by using `GuardScriptCredential`.\n\n### Alternatives considered\n\n- **Status quo**: Relying on auth tokens, thread tokens, and registry patterns introduces complexity, performance bottlenecks, and cyclic dependencies that are fragile and hard to audit. It has also led to serious exploits in real-world protocols due to misused or mishandled tokens.\n\n- **Off-chain filtering**: While indexers and DApp backends can attempt to filter out junk UTxOs, they provide no on-chain security and cannot be relied on in adversarial environments or in composable settings.\n\n- **Multivalidator pattern**: While technically feasible, this couples minting and spending logic into a single script, constrained by the 16KB script size limit. Furthermore, this introduces a huge layer of complexity and an associated attack surface. Managing the lifecycle of minted state tokens to prevent smuggling is extremely difficult, and becomes more impractical as the complexity of the dApp increases (ie. The attack surface for state token smuggling in a protocol that has 12 different validator scripts is nearly impossible to secure). In practice, this constraints the realm of what types of dApps are feasible on Cardano, you cannot build a cutting-edge financial instrument like AAVE, Balancer, or MakerDAO on Cardano because managing the lifecycle of dozens of state tokens across dozens of scripts while preventing smuggling is infeasible. \n\n### Backward Compatibility\n\nThis proposal can be **fully backward-compatible** with previous Plutus versions. There are no obvious issues with this. However, for extra-safety and to avoid any \nunintended consequences, it is also possible to strictly disallow Receiving scripts to be present in transactions that also execute scripts from Plutus versions before they\nare introduced.\n\nWallets, nodes, and off-chain tooling must be updated to:\n- Recognize and encode/decode `ProtectedAddress` addresses\n- Include `Receiving` redeemers in transactions with outputs to `ProtectedAddress`s\n- Extend phase-2 validation to evaluate `Receiving` scripts\n\nNode software, CLI, Plutus libraries, and serialization tooling (e.g., `cardano-api`, `cardano-ledger`, `plutus-ledger-api`) would require coordinated upgrades.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- Agreement from Cardano Ledger and Plutus teams\n- Implementation of:\n  - `ProtectedAddress` in address serialization\n  - `Receiving` in ledger script validation rules\n  - `Receiving` in Plutus\n  - Phase-2 validation for transactions with outputs to protected addresses\n- Inclusion in a future era upgrade (e.g., Voltaire or beyond)\n\n### Implementation Plan\n\n1. Extend ledger types to introduce the `ProtectedAddress` type. \n2. Modify transaction validation logic to detect outputs to protected addresses and invoke appropriate scripts.\n3. Introduce CDDL changes for redeemer tags and the new address variant.\n4. Update transaction witnesses, CLI tooling, and Plutus interpreter to support `Receiving`.\n5. Provide test cases for:\n   - Correct execution of `Receiving` scripts\n   - Rejection of transactions that include outputs to protected addresses and do not have the required witnesses or where the associated `Receiving` script execution fails. \n6. Provide examples and documentation for contract authors.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0161/README.md",
    "content": "---\nCIP: 161\nTitle: Ouroboros Phalanx - Breaking Grinding Incentives\nCategory: Consensus\nStatus: Proposed\nAuthors:\n  - Nicolas Henin <nicolas.henin@iohk.io>\n  - Raphael Toledo <raphael.toledo@iohk.io>\nSolution-To:\n  - CPS-0017\n  - CPS-0021\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/1065\nCreated: 2025-07-25\nLicense: Apache-2.0\n---\n\n## Abstract\n\nWe propose an extension to Ouroboros Praos, called **Ouroboros Phalanx**. The name derives from the [**Phalanx**](https://en.wikipedia.org/wiki/Phalanx), an **Ancient Greek military formation** where soldiers stood in tightly packed units, shielding one another to form a nearly impenetrable defense. Just as the phalanx multiplied the strength of individual soldiers through coordination, this protocol enhances Cardano’s consensus by reinforcing its resistance to adversarial attacks.\n\nAt its core, **Phalanx Protocol** strengthens the **VRF-based randomness generation sub-protocol** that underpins leader election. It introduces an additional cryptographic primitive that is **lightweight for honest participants** yet **computationally expensive for adversaries** seeking to bias slot leader distributions. This design does not eliminate grinding attacks outright but makes them **economically infeasible at scale**.\n\nBy addressing both [CPS-0021: Randomness Manipulation](https://github.com/cardano-foundation/CIPs/tree/master/CPS-0021) and [CPS-0017: Settlement Speed](https://github.com/cardano-foundation/CIPs/tree/master/CPS-0017), Phalanx achieves two goals simultaneously:  \n- It raises the cost of grinding attacks by a factor of roughly <strong>10<sup>10</sup></strong>.  \n- It reduces settlement time by approximately **20–30%** compared to unmodified Praos, without compromising security.  \n\nOuroboros Phalanx therefore represents a **complementary advancement**: reinforcing Cardano’s consensus security while improving performance, and ensuring the network remains robust against future adversarial strategies.\n\n<details>\n<summary><h2>Table of Contents</h2></summary>\n\n- [Abstract](#abstract)\n- [Motivation: why is this CIP necessary?](#motivation-why-is-this-cip-necessary)\n- [Specification](#specification)\n  - [1. High-Level Overview ](#1-high-level-overview)\n    - [1.1 Changes Relative to Praos](#11-changes-relative-to-praos)\n    - [1.2 Inputs & Outputs ](#12-inputs--outputs)\n      - [1.2.1 The η Stream](#121-the-η-stream)\n      - [1.2.2 The pre-ηₑ Synchronizations](#122-the-pre-ηₑ-synchronizations)\n      - [1.2.3 The Φ Stream ](#123-the-φ-stream)\n        - [1.2.3.1 The Setup](#1231-the-setup)\n        - [1.2.3.2 The Lifecycle](#1232-the-lifecycle)\n      - [1.2.4 The η Generations](#124-the-η-generations)\n  - [2. The Φ Cryptographic Primitive](#2-the-φ-cryptographic-primitive)\n    - [2.1. Expected Properties](#21-expected-properties)\n    - [2.2. Verifiable Delayed Functions (VDF)](#22-verifiable-delayed-functions-vdf)\n    - [2.3 Wesolowski's VDF](#23-wesolowskis-vdf)\n      - [2.3.1 VDF Primitives](#231-vdf-primitives)\n      - [2.3.2 VDF Aggregation Primitives](#232-vdf-aggregation-primitives)\n  - [3. Φ Stream Specification](#3-φ-stream-specification)\n    - [3.1 Distribution of Φ Iterations](#31-distribution-of-φ-iterations)\n    - [3.2 The State Machine](#32-the-state-machine)\n      - [3.2.1 Diagram Overview](#321-diagram-overview)\n      - [3.2.2 Parametrization Phase](#322-parametrization-phase)\n      - [3.2.3 Initialization Grace Phase](#323-initialization-grace-phase)\n        - [3.2.3.1 Initialize Command](#3231-initialize-command)\n        - [3.2.3.2 Tick Commands & Grace Period](#3232-tick-commands--grace-period)\n      - [3.2.4 Computation Phase](#324-computation-phase)\n        - [3.2.4.1 VDF integration](#3241-vdf-integration)\n        - [3.2.4.2 The States](#3242-the-states)\n        - [3.2.4.3 ProvideAttestedOutput & Tick Commands](#3243-provideattestedoutput--tick-commands)\n      - [3.2.5 Catch-up Phase](#325-catch-up-phase)\n        - [3.2.5.1 The States](#3251-the-states)\n        - [3.2.5.2 ProvideMissingAttestedOutput & Tick Commands](#3252-providemissingattestedoutput--tick-commands)\n      - [3.2.6 Closure Phase](#326-closure-phase)\n        - [3.2.6.1. The States](#3261-the-states)\n            - [3.2.6.2. The Successful Scenario: The `Close` Command](#3262-the-successful-scenario-the-close-command)\n            - [3.2.6.3. `tick` Command](#3263-tick-command)\n            - [3.2.6.4. The Failure Scenario: Ungraceful Closure](#3264-the-failure-scenario-ungraceful-closure)\n  - [4. Recommended Parameter Values](#4-recommended-parameter-values)\n    - [4.1. VDF Security Parameters λ and ρ](#41-vdf-security-parameters-λ-and-ρ)\n    - [4.2. Time Budget Tᵩ and Derived T](#42-time-budget-tᵩ-and-derived-t)\n      - [4.2.1. Specialized ASIC vs CPU-Based Chips](#421-specialized-asic-vs-cpu-based-chips)\n      - [4.2.2. Deriving from Tᵩ to T](#421-deriving-from-tᵩ-to-t)\n  - [5. Efficiency Analysis](#5-efficiency-analysis)\n    - [5.1. Block Publication](#51-block-publication)\n    - [5.2. Block Verification](#52-block-verification)\n      - [5.2.1. When Not Syncing](#521-when-not-syncing)\n      - [5.2.2. When Syncing](#522-when-syncing)\n  - [6. CDDL Schema for the Ledger](#6-cddl-schema-for-the-ledger)\n\n- [Rationale: How does this CIP achieve its goals?](#rationale-how-does-this-cip-achieve-its-goals)\n  - [1. How Phalanx Addresses CPS-21 - Ouroboros Randomness Manipulation ?](#1-how-phalanx-addresses-cps-21---ouroboros-randomness-manipulation)\n    - [1.1 Problem Overview](#11-problem-overview)\n    - [1.2 Phalanx Cost Amplification per Grinding Attempt](#12-phalanx-cost-amplification-per-grinding-attempt)\n    - [1.3 Phalanx Cost Amplification per Grinding Attack](#13-phalanx-cost-amplification-per-grinding-attack)\n      - [1.3.1 Formula](#131-formula)\n      - [1.3.2 Estimated Formula Using Mainnet Cardano Parameters](#132-estimated-formula-using-mainnet-cardano-parameters)\n      - [1.3.3 Impact of Tᵩ on Canonical Scenarios](#133-impact-of-tᵩ-on-canonical-scenarios)\n      - [1.3.4 Impact of Tᵩ on Feasibility Categories](#134-impact-of-tᵩ-on-feasibility-categories)\n    - [1.4. Conclusion: How Much Risk is Mitigated?](#14-conclusion-how-much-risk-is-mitigated)\n  - [2. How Phalanx Improves CPS-17 - Settlement Speed ?](#2-how-phalanx-improves-cps-17---settlement-speed)\n    - [2.1 Settlement times without grinding attacks](#21-settlement-times-without-grinding-attacks)\n    - [2.2 How Grinding Power affects Settlement times](#22-how-grinding-power-affects-settlement-times)\n    - [2.3 How Phalanx improves compared to Praos?](#23-how-phalanx-improves-compared-to-praos-) \n    - [2.4 Advocating for Peras: Phalanx as a Complementary Layer](#24-advocating-for-peras-phalanx-as-a-complementary-layer) \n  - [3. Why VDFs Were Chosen over other Cryptographic Primitives ?](#3-why-vdfs-were-chosen-over-other-cryptographic-primitives-)\n    - [3.1 Requirements](#31-requirements)\n    - [3.2 Primitive selection](#32-primitive-selection)\n      - [3.2.1 RSA solutions](#321-rsa-solutions)\n        - [3.2.1.1 Designs](#3211-designs)\n        - [3.2.1.2 Properties](#3212-properties)\n      - [3.2.2 ECC solutions](#322-ecc-solutions)\n        - [3.2.2.1 Designs](#3221-designs)\n        - [3.2.2.2 Properties](#3222-properties)\n      - [3.2.3 Class group solutions](#323-class-group-solutions)\n        - [3.2.3.1 Design](#3231-design)\n        - [3.2.3.2 Properties](#3232-properties)\n      - [3.2.4 OWF solutions](#324-owf-solutions)\n        - [3.2.4.1 Proofs of knowledge](#3241-proofs-of-knowledge)\n        - [3.2.4.2 OWFs](#3242-owfs)\n        - [3.2.4.3 Design](#3243-design)\n        - [3.2.4.4 Properties](#3244-properties)\n    - [3.3 Primitive recommendation](#33-primitive-recommendation)\n- [Path to Active](#path-to-active)\n  - [Acceptance Criteria](#acceptance-criteria)\n  - [Implementation Plan](#implementation-plan)\n- [References](#references)\n- [Copyright](#copyright)\n\n</details>\n\n## Motivation: why is this CIP necessary?\n\nThis proposal strengthens Cardano’s consensus protocol (Ouroboros Praos) against a class of attacks known as *grinding attacks*. These attacks allow adversaries to bias the randomness used in block leader elections in their favor, statistically slowing down settlement times and thys weakening the effectivness of Praos.\n\nThe improvement introduces an additional computation step that is lightweight for honest participants but significantly more expensive for attackers, making grinding attacks economically infeasible.\n\n### Recommended Configuration\n\nAs an initial configuration, we recommend **12 hours of cumulative and distributed execution** of this cryptographic primitive per epoch on standard CPU architectures.  \n- The epoch is divided into **1-hour intervals**.  \n- The **first leader of each interval** must produce the corresponding proof.  \n- For any individual node, this requirement represents roughly **527 seconds (≈10 minutes)** of computation.  \n\nThe algorithm is designed so that with **128-bit confidence**, all required proofs will be produced on time by the end of each epoch.\n\n### Security Improvements\n\nThe proposal increases substantially the computational cost of a grinding attack by a factor of approximately <strong>10<sup>10</sup></strong> compared to the current situation.  \n\nTo maintain this level of security over time:  \n- Governance may choose to **increase the 12-hour budget** as the cost of computation decreases.  \n- Execution could migrate to **ASIC-based architectures**, preserving the same budget while maintaining security guarantees, and later increasing the budget further.  \n\nBeyond parameter updates, adoption of this proposal would necessarily require a **hard fork**, since it modifies the consensus protocol in two fundamental ways:  \n1. The randomness for slot distribution is extended from **1 epoch to 2 epochs**. At the start of epoch *e*, the snapshot of the stake distribution will be taken at the end of *epoch e−2*, rather than at the end of *epoch e−1* as in Praos today.  \n2. The **general method of generating slot leader distributions** is changed, making leader election more resilient to adversarial bias.\n\n### Consensus Performance\n\nThis proposal is not only about security, but also about **consensus performance**.  \n\nIn Praos, because grinding allows adversaries to choose among multiple possible slot leader distributions, the probability of “bad events” (such as rollbacks or settlement failures) is statistically amplified compared to the honest model.  \n\n- If a bad event occurs with probability $`\\varepsilon`$ under unbiased randomness,  \n- An adversary able to try $`R`$ independent randomness candidates can increase the likelihood of that event up to $`R \\cdot \\varepsilon`$ (by the union bound).  \n\nThis translates into slower settlement and weaker guarantees for the network as a whole. By substantially reducing $`R`$ compared to Praos, we limit the impact of grinding attacks and therefore improve settlement. In fact, the recommended configuration reduces settlement time by approximately **20–30%** while maintaining equivalent security.\n\n### Relationship to Peras\n\n[Ouroboros Peras](https://peras.cardano-scaling.org/) is a recent extension of Praos designed to **accelerate settlement**.  \n- Instead of waiting for the traditional 2160-block window (around 5 days) to guarantee finality, Peras introduces **stake-weighted voting and certified blocks**.  \n- Randomly chosen committees of stake pool operators can “vote” on blocks, and when enough votes are collected, the block receives a certificate.  \n- Certified blocks are treated as more important in the chain, which enables **settlement in just 1–2 minutes**.\n\nPeras is fully compatible with Praos:  \n- When enough committee members participate, it achieves **rapid settlement**.  \n- When they do not (e.g., if too many operators are offline), Peras **gracefully falls back to Praos**. Peras would only fall back to Praos if there were massive network disruption or an attack by a 25% adversary.  \n\nIn these fallback situations, the network still relies on Praos’ guarantees—precisely where Phalanx becomes relevant as a **complementary defense layer**. Phalanx ensures that even when Peras cannot certify blocks, the protocol still benefits from:  \n- **Stronger protection against grinding attacks**, and  \n- **Faster settlement** compared to unmodified Praos.  \n\nTogether, they form a **complementary pair**:  \n- **Peras** provides speed when conditions are favorable.  \n- **Phalanx** ensures resilience and strong security guarantees in all cases.\n\n### Technical Depth\n\nThe remainder of this document provides the full technical specification for node implementors and researchers. Because Cardano’s security is grounded in **cryptography, probability, and statistical guarantees**, understanding the full details of this proposal requires technical knowledge in these areas. The complete specification is therefore dense: it describes mathematical models, cryptographic primitives, and rigorous proofs to ensure the system can be trusted at scale. Readers interested only in the high-level motivation and community impact may stop here.\n\nPlease refer to the CPD \"[Ouroboros Randomness Generation Sub-Protocol – The Coin-Flipping Problem](https://github.com/cardano-foundation/CIPs/tree/master/CPS-0021/CPD/README.md)\" for a detailed understanding of **randomness generation, leader election in Praos, and the coin-flipping dilemma in consensus protocols**. Moving forward, we will **dive into the core details**, assuming you have the **relevant background** to understand the proposal.\n\n\n## Specification\n\nThe core principle of the proposed protocol change is to **substantially escalate the computational cost of each grinding attempt for an adversary**. To achieve this, every honest participant is required to perform a designated computation for each block they produce over an epoch (**432,000 slots - 5 days**) - note that this computation can be preprocessed locally at the beginning of the epoch. Consequently, an adversary attempting a grinding attack must **recompute these operations for every single attempt**, while being **constrained by the grinding window**, which dramatically increases the resource expenditure. By enforcing this computational burden, we **drastically reduce the feasible number of grinding attempts** an adversary with a fixed resource budget can execute, making randomness manipulation **more expensive and significantly less practical**.\n \n### 1. High-Level Overview \n\n#### 1.1. Changes Relative to Praos\n\nIn **Phalanx** , the randomness generation and leader election flows are modified as follows:\n\n![alt text](./image/Praos-vs-Phalanx-Highl-Level.png)\n\n1. The **stake distribution stabilization phase** is shifted **back by one epoch :** The **active** **stake distribution** $`\\mathbf{SD}_e`$ used for leader election is now derived from the **end of $epoch_\\text{e-3}$** instead of **$epoch_\\text{e-2}$**  as in the original Praos protocol.  \n2. The **honest contribution inclusion phase**, which originally resulted in a **ηₑ candidate**, is also **shifted back by one epoch**, aligning with the adjusted **stake distribution stabilization**. This value is now referred to as the **pre-ηₑ candidate**, signifying its role as an **intermediate randomness nonce** in the sub-protocol.  \n3. The **pre-ηₑ candidate**, once stabilized (after $`3 \\cdot \\frac{k}{f}`$), undergoes a **sequence of incremental operations** using a **new deterministic cryptographic primitive Φ (Phi)**. This sequence spans a full epoch size, specifically during the interval:$`\\left[\\frac{9k}{f} \\cdot \\text{epoch}_{e-2},  \\frac{9k}{f} \\cdot \\text{epoch}_{e-1}\\right)`$.\n4. The final **ηₑ (eta nonce)**, resulting from the Φ computation, completely determined by the prior stabilized pre-seed pre-ηₑ, does not need stabilization and is availablea a whole $`\\frac{k}{f}`$ slots before the start of $`\\text{epoch}_e`$ .\n\n#### 1.2. Inputs & Outputs \n\nThe Randomness Generation sub-protocol pipelines two parallel streams η stream and Φ Stream, which synchronize at $`9 \\cdot \\frac{k}{f}`$ at each epoch :  \n\n![alt text](./image/Phalanx-Streams.png)\n\n##### 1.2.1. The η stream \n\n   - Already present in Praos and retained in Phalanx \n   - Updated with every block produced in the blockchain tree, a η stream captures intermediate values $`\\eta^\\text{evolving}_t`$ in the block headers, defined as follows:\n\n```math\n   \\eta^{\\text{evolving}}_{t+1} =\n   \\begin{cases}\n   \\eta^{\\text{evolving}}_{t}\\ \\star\\ \\mathsf{VRF}^\\text{Output}_\\text{t+1} & \\text{when BlockProduced}(t) \\\\\n   \\eta^{\\text{evolving}}_{t}  & \\text{otherwise.}\n   \\end{cases}\n   \n```\n```math \n\\text{BlockProduced}(t) = \n\\begin{cases} \n\\text{true} & \\text{if a block is produced at time } t, \\\\\n\\text{false} & \\text{otherwise.}\n\\end{cases}\n```\n\n| **where** ||\n|---------------|-----------------|\n| $`\\text{ProtocolParameter}_\\text{extraEntropy} `$ | The evolving nonce is initialized using the extraEntropy field defined in the protocol parameters.|\n| $`\\mathsf{VRF}^\\text{Output}_\\text{i} `$ | The **VRF output** generated by the $` \\text{slot}_\\text{i} `$ Leader and included in the block header |\n| $a\\ \\star\\ b$    | The concatenation of $a$ and $b$ , followed by a BLAKE2b-256 hash computation.\n\n\n##### 1.2.2. The pre-ηₑ Synchronizations  \n\n- To generate $`\\eta_\\text{e}`$ for epoch $`e`$, the stream Φ Stream is reset with the value of η stream at $`t=9.\\frac{k}{f}`$ at $epoch_{e-2}$\n- This specific value of η stream is referred to as **$`\\text{pre-}\\eta_e`$** and defined as :\n```math\n\\text{pre-}\\eta_e= \\eta^{evolving}_{9.\\frac{k}{f}(epoch_{e-2})}\n```\n\n##### 1.2.3. The Φ Stream\n\n###### 1.2.3.1. The Setup\n\nThe stream is bootstrapped by calling the parametrize function of the cryptographic primitive $`\\Phi`$ with:\n```math\nΦ.\\text{Stream.State} \\leftarrow \\Phi.\\text{parametrize}(\\lambda, T_\\Phi)\n```\nwhere : \n  -  $`\\lambda`$ is a security parameter for the cryptographic primitive $`\\Phi`$.\n  - $`T_\\Phi`$, a time-bound parameter representing the required computation  $`\\Phi`$ duration, independent of available computing power.\n  - Any change to these 2 parameters would require a decision through Cardano governance.\n  - $\\Phi.\\text{Stream.State}$ will contain derived configuration specific to the algorithm and the cryptographic primitive used.\n\n###### 1.2.3.2. The Lifecycle\n\nIt is reset at every pre-ηₑ synchronization point every $`10.\\frac{k}{f}`$ slots :\n```math\nΦ.\\text{Stream.State} \\leftarrow \\Phi.\\text{initialize}(Φ.\\text{Configuration}, \\text{pre-}\\eta)\n```\nAt each slot $t$, update the stream state by :   \n```math\nΦ.\\text{Stream.State} \\leftarrow \\Phi.\\text{tick}(Φ.\\text{Stream.State, t})\n```\nA node must be able to determine, based on the current state, whether it should begin computing $\\Phi$ iterations in order to provide a proof at its next scheduled leader slot (see [Section \"3.2.4.1. VDF integration\"](#3241-vdf-integration) for details):\n```math\n\\{0,1\\} \\leftarrow \\Phi.\\text{shouldCompute}(Φ.\\text{Stream.State, nextElectedSlot})\n```\nA node must be able to compute a specific chunk of the $`\\Phi`$ iterations independently of any global state. \nThe result is an *attested output*—a pair $`\\phi_x =(\\pi_x,\\ o_x)`$ where : \n\n - $`o_x`$ is the computed output for iteration $`x`$, \n - $`\\pi_x`$ is a cryptographic proof attesting that $`o_x`$ was correctly derived from the input according to the rules of $`\\Phi`$. \n - Since this operation may be long-lived, intermediate attested outputs should be persistable to disk, allowing the node to stop, resume, or cancel computation from the latest completed sub-computation.\n\nA subset of block-producing slots must include in their block bodies a unique attested output $`\\phi_x`$ with $`x \\in \\{1,\\ \\dots,\\ i \\}`$ denoting the iteration index within the $`\\Phi`$ computation :\n  - Each attested output updates the stream state as follows:\n```math\n \\Phi.\\text{StreamState} \\leftarrow \\Phi.\\text{provideAttestedOutput}(\\Phi.\\text{StreamState},\\ t,\\ \\phi_x)\n```\n  - Each attested output must be verifiable both:\n      - **logically**, to ensure it corresponds to the correct slot and index, and\n      - **cryptographically**, to confirm that the computation was effectively executed\n\n```math\n\\{0,1\\} \\leftarrow \\Phi.\\text{verify}(\\Phi.\\text{StreamState},\\ t,\\ \\phi_x)\n```\n\nAt the synchronization point $`\\text{pre-}\\eta_{e+1}`$, the stream is closed providing $`\\phi^{final}_e = (\\phi_e,\\ \\phi^{aggregated}_e)`$ with the last attested output $`\\phi_e\\text{,}`$ along with an **aggregated proof** $`\\phi^{final}_e`$. This aggregated proof fastens node synchronisation by allowing nodes to efficiently verify the final result without checking each individual $`\\phi_x`$ produced during the computation phase :\n\n```math\n\\phi^{final}_e \\leftarrow \\Phi.\\text{close}( \\Phi.\\text{StreamState})\n```\n\n##### 1.2.4. The η Generations\n   - This is the final nonce $`\\eta_\\text{e}`$ used to determine participant eligibility during epoch $`e`$.  \n   - It originates from the operation $`\\star`$ with $`\\phi^{\\text{stream}}_{t}`$ at $`\\text{pre-}\\eta_\\text{e+1}`$ synchronization and η stream  $`\\text{when } t = \\text{end of epoch}_\\text{e-3}`$ and the combination of the outputs $`\\{o_i\\}_{[1,i]}`$ using an aggregation function $`f_\\text{agg}`$.\n\n```math\n\\eta_\\text{e} = \\eta^\\text{evolving}_{epoch_\\text{e-3}}\\ \\star\\ f_\\text{agg}(o_1, \\dots, o_e) , \\quad \\text{when } t = \\text{pre-}\\eta_\\text{e+1}\\text{ synchronization } \n```\n\n### 2. The Φ Cryptographic Primitive\n\n#### 2.1. Expected Properties\n\nThe Φ cryptographic primitive is a critical component of the Phalanx protocol, designed to increase the computational cost of grinding attacks while remaining efficient for honest participants. To achieve this, Φ must adhere to a set of well-defined properties that ensure its security, efficiency, and practical usability within the Cardano ecosystem. These properties are outlined in the table below :\n\n| **Property**              | **Description**                                                                                                   |\n|---------------------------|-------------------------------------------------------------------------------------------------------------------|\n| **Functionality**         | Must be a well-defined mathematical function, ensuring a unique output for each given input (unlike proof-of-work, which allows multiple valid outputs). |\n| **Determinism**           | Must be fully deterministic, with the output entirely determined by the input, eliminating non-deterministic variations. |\n| **Efficient Verification**| Must allow for fast and lightweight verification, enabling rapid validation of outputs with minimal computational overhead. |\n| **Compact Representation**| Input and output sizes should be small enough to fit within a block, optimizing on-chain storage efficiency. Further reductions are desirable where feasible. |\n| **Lower Bound on Computation** | Computational cost of evaluation should be well-characterized and predictable, with a lower bound that is difficult to surpass, ensuring adversaries cannot gain an unfair efficiency advantage. |\n| **Ease of Implementation & Maintenance** | Should be simple to implement and maintain, ensuring long-term usability and minimizing technical debt. |\n| **Adaptive Security**     | Function and its parameters should be easily reconfigurable to accommodate evolving threats, such as advances in computational power or new cryptographic attacks. |\n\n#### 2.2. Verifiable Delayed Functions (VDF)\n\nVerifiable Delayed Functions (VDFs) are cryptographic primitives designed to take a certain amount of time to compute, regardless of how much computing resources are available. This delay is enforced by requiring a specific number of sequential steps that cannot be easily sped up through parallel processing. Once the computation is done, the result, $`y = g^{2^T}`$, comes with a proof, $`\\pi`$, that can be checked quickly and efficiently by anyone. Importantly, for a given input, the output is always the same (deterministic function), ensuring consistency. They usually rely on repeatedly squaring numbers in a mathematical setting that prevents shortcuts and enables quick verification.\n\nAs one can see, VDFs present _functionality_, _determinism_, _efficient verification_ and _lower bound on computation_. The _compact representation_ depends on the chosen group as well as the instantiation, which we will tackle later on. The _implementation and maintenance_ is straightforward as the output of a VDF is a simple exponentiation of a group element, only the square operation is needed to be implemented to compute it. As for the proof, this depends on the precise VDF instantiation. Finally, the system is \"adaptively secure\" as we can set up a group with high security to be reused for a whole epoch or more, and set the number of squaring, also called difficulty, depending on how much computation we want the nodes to perform.\n\nVerifiable Delayed Functions were introduced by Boneh et al. [[6]](https://eprint.iacr.org/2018/601.pdf) where the authors suggest several sequential functions combined with the use of proof systems in the incrementally verifiable computation framework (IVC) for viable proof generation and fast verification.\nVDF variants revolve around two primary SNARK-free designs: one from Pietrzak [[36]](https://drops.dagstuhl.de/storage/00lipics/lipics-vol124-itcs2019/LIPIcs.ITCS.2019.60/LIPIcs.ITCS.2019.60.pdf) and the second from Wesolowski [[35]](https://eprint.iacr.org/2018/623.pdf). They differ in the proof design. \n\nIn Wesolowski’s paper, the proof is defined as $g^{{2^T} /\\ p}$ where $g$ is the challenge, $T$ the difficulty and $p$ is a prime number found by hashing the VDF input and output together.  \nThe proof is thus a single group element that can be computed in at most $2\\cdot T$ group operations and constant space, or $(1+1/s) \\cdot T$ time where the number $s$ is both the number of processors and space while the verification takes $\\text{log}_2 T$ scalar multiplications in $\\mathbb{Z}/p$ and two small exponentiations in the group $\\mathbb{G}$. The proving time can further be optimized to $O(T /\\ \\text{log}(T))$ group multiplications by reusing the evaluation intermediary results.  \nWesolowski also presents aggregation and watermarking methods. The aggregation method does not consist in aggregating multiple proofs but computing a proof of several VDF challenges. This is done by batching all inputs and outputs together and creating a proof for this batched input. The watermarking is done by computing the VDF twice, once normally and another time on a combination of the challenger’s id and VDF input.\n\nIn Pietrzak’s paper, the proof is a tuple of group elements $\\pi = \\{x^{2^{T / 2^i}}\\}$, of size logarithmic in $T$, that can be computed in $(1+2 /\\sqrt{T})\\cdot T$ time and can be optimized to $O(\\sqrt{T} \\cdot \\text{log}_2 T)$ multiplications. The verification takes $2 \\cdot \\text{log}_2T$ small exponentiations. Subsequent work on Pietrzak’s paper shows how VDFs challenges can be structured in a Merkle tree to get a proof of the whole tree.\n\nWe will choose Wesolowski design over Pietrzark because of its space efficiency and possibility to aggregate proofs.\n\nSpecialized hardware such as ASICs can be used to evaluate VDF output much faster, up to a factor 5 in Chia's VDF project while Ethereum considers a factor 10. This, while unfortunate, is not prohibitive in our context as we only consider the use of VDFs for their computational cost. An attacker would still require a substantial budget to perform an anti-grinding attack in addition to purchasing at scale the specialized hardware that is not inexpensive nor readily available (Chia' ASICs can be purchased on a case per case basis for $1,000). We can also note that any solution would still be affected by hardware, like in the case of proof of works and hash farms.\n\n#### 2.3. Wesolowski's VDF \n\n##### 2.3.1. VDF Primitives\n\nTo define Wesolowski VDF construction, we first introduce a series of hash functions: $`\\text{Hash}^{(n)}_\\mathbb{N}`$, which samples random integers of $`n`$ bits, $`\\text{Hash}^{(n)}_\\text{prime}`$, which samples a random integer from the set of the first $`2^{2n}`$ prime numbers, and $`\\text{Hash}_\\mathbb{G}`$, which samples a random group element of the class group $`\\mathbb{G}`$.\n\nWe define the interface of a Verifiable Delay Function as $`\\texttt{VDF} = (\\texttt{Setup},\\ \\texttt{Evalute},\\ \\texttt{Prove},\\ \\texttt{Verify})`$, and define its underlying functions based on class groups as follows:\n\n- $`(\\mathbb{G},\\ \\Delta,\\ \\cdot) \\leftarrow \\texttt{VDF.Setup}(\\lambda,\\ \\Delta_{\\text{challenge}})`$\n  Takes as input a **security parameter** $`\\lambda \\in \\mathbb{N}`$ and a **challenge discriminant** $`\\Delta_{\\text{challenge}} \\in \\{0,1\\}^*`$. This challenge discriminant acts as a source of public entropy used to deterministically derive the group discriminant $\\Delta$, which defines a group of unknown order $\\mathbb{G}$ along with its group operation $`\\cdot`$. The use of a challenge ensures that the resulting group is unbiasable and unpredictable, preventing adversarial precomputation. We shall drop the group settings $`(\\mathbb{G},\\ \\Delta,\\ \\cdot)`$ from further functions for readability. Internally, we expect the setup procedure to invoke the following sub-operations:\n```math\n    \\Delta \\leftarrow \\texttt{VDF.CreateDiscriminant}(\\lambda,\\ \\Delta_{\\text{challenge}})\n```\n```math\n  (\\mathbb{G},\\ \\cdot) \\leftarrow \\texttt{VDF.DeriveClassGroup}(\\lambda,\\ \\Delta)\n```\n\n- $`y \\leftarrow \\texttt{VDF.Evaluate}(\\ x,\\ I)`$\n  Given a challenge $`x \\in \\mathbb{G}`$ and a number of iterations $`I \\in \\mathbb{N}`$, computes the  output $`y = x^{2^I}`$.\n\n- $`\\pi \\leftarrow \\texttt{VDF.Prove}(\\ x,\\ y,\\ I)`$ \n  Given a challenge and output $`(x,y) \\in \\mathbb{G}^2`$, computes the VDF  **proof** as $`\\pi = x^{2^I / p}`$ where $`p \\leftarrow \\text{Hash}^{(2 \\lambda)}_\\text{prime}(x \\| y)`$ is sampled from the first $`2^{2 \\lambda}`$ prime numbers.\n\n- $`\\{0,1\\} \\leftarrow \\texttt{VDF.Verify}( \\ x,\\ y,\\ I,\\ \\pi)`$\n  Returns 1 if $`\\pi`$ successfully attests that $`y = x^{2^I}`$ with overwhelming probability, that is if $\\pi^r \\cdot x^p == y$ where $`p \\leftarrow \\text{Hash}^{(2 \\lambda)}_\\text{prime}(x \\| y)`$ and $`r \\leftarrow 2^I \\text{mod}\\ p`$. Returns 0 otherwise.\n\n##### 2.3.2. VDF Aggregation Primitives\n\nIn this section, we present a mechanism for producing a Wesolowski VDF **aggregation proof**. This construction enables efficient synchronization for network participants and may play a central role in deriving the final epoch nonce $`\\eta_e`$. \nThe aggregation mechanism has the following interface $`\\texttt{VDF.Aggregation} = (\\text{Init},\\ \\text{Update},\\ \\text{Prove},\\ \\text{Verify})`$ whose functions will be detailled afterwards. We assume that a class group $`\\mathbb{G}`$ has already been set up, by $`(\\mathbb{G},\\ \\Delta,\\ \\cdot) \\leftarrow \\texttt{VDF.Setup}(\\lambda,\\ \\Delta_{\\text{challenge}})`$.\n\n**N.B.** We are showing here the core algorithms for simplicity and readability. In practice, we may use further techniques, for instance using an arbitrary byte and the epoch's number as personalization tags to ensure domain separation.\n\nAt the beginning of each epoch, we initialize the VDF accumulators' state that will be used to generate the VDF aggregation proof using $`\\texttt{VDF.Aggregation.Init}`$.\n<center>\n\n| `Initialize accumulators` | $`(\\text{Acc}_x, \\text{Acc}_y, \\alpha) \\leftarrow \\texttt{VDF.Aggregation.Init}(\\lambda, \\text{pre-}\\eta_e)`$     |\n| ------------------------- | ------------------------- |\n| **Input Parameters**      | <ul><li>$`\\lambda \\in \\mathbb{N}`$ — Security parameter.</li><li>$\\text{pre-}\\eta_e \\in \\{0,1\\}^{256}$ — 256-bit pre-nonce entropy for epoch $e$.</li></ul> |\n| **Steps**                 | <ol><li>Compute all VDF challenges:<br>$`\\forall i\\ x_i \\leftarrow  \\text{Hash}_\\mathbb{G}(\\text{pre-}\\eta_e \\|\\|\\ i) `$</li><li>Compute the initial aggregation nonce:<br>$`\\alpha \\leftarrow  \\text{Hash}^{(\\lambda)}_\\mathbb{N}(x_1 \\|\\| \\dots \\|\\| x_n) `$</li><li>Initializes the accumulators to the identity:<br>$`(\\text{Acc}_x,\\ \\text{Acc}_y) \\leftarrow (1_\\mathbb{G},\\ 1_\\mathbb{G})`$</li></ol>                                                                                                          |\n| **Returned Output**       | $`(\\text{Acc}_x,\\ \\text{Acc}_y,\\ \\alpha)`$ — Input and output accumulators and initial aggregation nonce.   |\n\n</center>\n\nEvery time a VDF output is published on-chain, if no previous VDF outputs are missing, we shall update the accumulators' state using $`\\texttt{VDF.Aggregation.Update}`$.\n<center>\n\n| `Update accumulators` | $`(\\text{Acc}_x, \\text{Acc}_y, \\alpha) \\leftarrow \\texttt{VDF.Aggregation.Update}(\\lambda, (x_i, y_i),\\ (\\text{Acc}_x,\\ \\text{Acc}_y,\\ \\alpha))`$     |\n| ------------------------- | ------------------------- |\n| **Input Parameters**      | <ul><li>$`\\lambda \\in \\mathbb{N}`$ — Security parameter.</li><li>$`(x_i,\\ y_i)`$ — Pair of VDF input and output for current interval.</li><li>$`(\\text{Acc}_x,\\ \\text{Acc}_y,\\ \\alpha)`$ — Accumulators' state.</li></ul> |\n| **Steps**                 | <ol><li>Compute the aggregation nonce:<br>$`\\alpha \\leftarrow  \\text{Hash}^{(\\lambda)}_\\mathbb{N}(\\alpha\\ \\|\\|\\ y_i) `$</li><li>Update the accumulators:<br>$`(\\text{Acc}_x, \\text{Acc}_y) \\leftarrow (\\text{Acc}_x \\cdot x_i^\\alpha,\\ \\text{Acc}_y \\cdot y_i^\\alpha)`$</li></ol>                                                                                                    |\n| **Returned Output**       | $`(\\text{Acc}_x,\\ \\text{Acc}_y,\\ \\alpha)`$ — Updated accumulator's state.   |\n\n</center>\n\nOnce all VDF outputs have been generated and the accumulators updated, we can generate the VDF aggregation proof $`\\pi`$ using $`\\texttt{VDF.Aggregation.Prove}`$.\n<center>\n\n| `Prove accumulators` | $`\\pi \\leftarrow \\texttt{VDF.Aggregation.Prove}(\\ (\\text{Acc}_x,\\ \\text{Acc}_y,\\ \\_\\alpha),\\ I)`$     |\n| ------------------------- | ------------------------- |\n| **Input Parameters**      | <ul><li>$`(\\text{Acc}_x,\\ \\text{Acc}_y,\\ \\alpha)`$ — Accumulators' state.</li><li>$`I \\in \\mathbb{N}`$ — Per-interval iteration count for the VDF.</li></ul> |\n| **Steps**                 | <ol><li>Compute the accumulator proof as a VDF proof:<br>$`\\pi \\leftarrow \\texttt{VDF.Prove}(\\text{Acc}_x,\\ \\text{Acc}_y,\\ I)`$</li></ol>                                                                                                    |\n| **Returned Output**       | $`\\pi`$ — Aggregated proof.   |\n\n</center>\n\nThe VDF aggregation proof $`\\pi`$ can then be efficiently be verified using $`\\texttt{VDF.Aggregation.Verify}`$.\n<center>\n\n| `Verify accumulators` | $`\\{0,1\\} \\leftarrow \\texttt{VDF.Aggregation.Verify}(\\ (\\text{Acc}_x,\\ \\text{Acc}_y,\\ \\_\\alpha),\\ I,\\ \\pi)`$     |\n| ------------------------- | ------------------------- |\n| **Input Parameters**      | <ul><li>$`(\\text{Acc}_x,\\ \\text{Acc}_y,\\ \\alpha)`$ — Accumulators' state.</li><li>$`I \\in \\mathbb{N}`$ — Per-interval iteration count for the VDF.</li><li>$`\\pi \\in \\mathbb{G}`$ — Aggregated VDF proof.</li></ul> |\n| **Steps**                 | <ol><li>Verfy the accumulators' proof:<br>$`b \\leftarrow \\texttt{VDF.Verify}(\\text{Acc}_x,\\ \\text{Acc}_y,\\ I,\\ \\pi)`$</li></ol>                                                                                                    |\n| **Returned Output**       | $`b`$ — Verification bit.   |\n\n</center>\n\n### 3. Φ Stream Specification\n\nWe previously outlined the purpose of the Phalanx sub-protocol and introduced the cryptographic primitive underpinning its security guarantees. In this section, we provide a precise technical specification of the protocol, focusing on how the $`\\Phi`$ iterations are distributed and how Wesolowski’s Verifiable Delay Function (VDF) is integrated into the process.\n\n#### 3.1. Distribution of Φ Iterations\n\nAs previously mentioned, Φ Stream is divided into epoch-sized *lifecycle segments*. Each segment begins with an **initialize** function, ends with a **close** function, and is immediately followed by the start of a new segment.\n\nWe further partition this segment into **intervals**, each large enough to guarantee (with 128-bit confidence) that at least one block will be produced within it. This corresponds to **3435 slots** per interval. For simplicity, we round this to **3600 slots** (~1 hour), resulting in exactly 120 intervals per segment, which conveniently aligns with the 120 hours in five days.\n\n<details>\n<summary>🔍 How 128-bit Confidence gives 3435 Slots ?</summary>\n<p> \n\n<span style=\"display:block; font-size:1.25em; font-weight:bold\"> 📦 Guaranteeing Honest Block Inclusion with 128-bit Confidence in our context </span>\n\nWe want to make sure that, in any given interval of $N$ slots, there's **at least one honest block** produced — with a failure probability of at most $2^{-128}$ (which is a standard for cryptographic security).\n\nIt is also important to note that we are operating in a context where fork-related concerns can be safely abstracted away. In particular, if an adversary were to attempt a private chain attack and succeed, it would imply that their chain is denser and that the proof of $\\Phi$ computation is valid. In this setting, forks do not undermine security—they actually improve the probability of having at least one valid computation published within the interval.\n\nThis means: $`\\Pr(\\text{at least one honest block in } N \\text{ slots}) \\geq 1 - 2^{-128}`$\n\n<span style=\"display:block; font-size:1.1em; font-weight:bold\"> 🎲 Step 1 — What’s the chance of *not* getting an honest block? </span>\n\nEach slot gives honest participants a chance to be selected as leader.\n\nLet:\n\n- $f = 0.05$ → probability a slot is active  \n- $\\sigma = 0.51$ → at least 51% of stake is honest\n\nThen the chance that **no honest party** is selected in a slot is: $`(1 - f) + f \\cdot(1-\\sigma) = 0.95 + 0.05 \\cdot (1-0.51) \\approx 0.97449`$\n\n\nSo, the chance that **at least one honest party** is selected in a slot is: $`p_h = 1 - 0.97449 = 0.0255`$\n\n\nThis means that **each slot has a 2.584% chance** of having an honest leader.\n\n<span style=\"display:block; font-size:1.1em; font-weight:bold\"> 📐 Step 2 — What about across $N$ slots? </span>\n\nThe chance that **no honest block** is produced in $N$ consecutive slots is: $`(1 - p_h)^N`$\n\nWe want this to be **less than or equal to** $2^{-128}$, so: $(1 - p_h)^N \\leq 2^{-128}$\n\n<span style=\"display:block; font-size:1.1em; font-weight:bold\"> ✏️ Step 3 — Solve for $N$ </span>\n\nTake log base 2 of both sides:\n\n$\\log_2((1 - p_h)^N) \\leq \\log_2(2^{-128})$\n\n$N \\cdot \\log_2(1 - p_h) \\leq -128$\n\n$N \\geq \\frac{-128}{\\log_2(1 - p_h)}$\n\nNow plug in:\n\n\n$`\\log_2(1 - 0.0255) = \\log_2(0.97449) \\approx -0.03726`$\n\n$`N \\geq \\lceil \\frac{128}{0.03726} \\rceil = 3435`$\n\nTo guarantee with 128-bit confidence that an interval contains **at least one honest block**, the interval must be at least **3435 slots** long.\n\nThis ensures security even if up to **49% of stake is adversarial**.\n\n----\n</p> \n</details>\n<br>\n\nThis structure can be illustrated as follows:\n\n![alt text](./image/intervals.png)\n\nAs previously described, we configure the stream using two key parameters, most notably the total computational budget $`T_\\Phi`$. This value defines the total amount of work we require SPOs to collectively perform.\n\nWe split $`T_\\Phi`$ into discrete **iterations**, each with the following properties:\n\n- Iterations are fully independent and can be computed in parallel.\n- Slot leaders are responsible for submitting a proof of computation for the specific iteration assigned to them.\n- These computations are fully decoupled, there is no requirement to wait for previous iterations, enabling input precomputation and reducing latency.\n- All iterations must eventually be completed, and an additional and final iteration is used to aggregating all outputs along with a corresponding proof.\n- The iterations are then used to compute the epoch randomness $\\eta_e$.\n\nEach iteration is mapped to a specific interval, with the following constraints:\n\n  - The first interval is intentionally left without an assigned iteration, giving slot leaders time to compute the first output for interval \\#2 and allowing precomputation of the challenges.\n  - Each interval must be longer than the time required to compute a single iteration (i.e., the iteration duration must be less than one hour).\n  - The first slot leader to produce a block within an interval is responsible for submitting the corresponding attested output.\n\nAt first glance, we could divide $`T_\\Phi`$ evenly across the 120 intervals. However, to ensure resilience, the protocol must remain robust even in extreme scenarios—such as a global outage causing **36 hours** of consecutive downtime (**30% of an epoch**). This scenario is detailed in the [Cardano Disaster Recovery Plan](https://iohk.io/en/research/library/papers/cardano-disaster-recovery-plan).\n\nA global outage implies a sequence of blockless intervals. To tolerate such conditions, the protocol must be able to handle up to **36 intervals without block production**.  To address this, we introduce a catch-up mechanism: \n  - We reserve the final 36 intervals of the segment specifically for recovering any missing attested outputs. \n  - These missing outputs must be submitted in order, according to their original indices, ensuring deterministic reconstruction of the full computation stream.\n\n\nWe define **4 sequential phases** in the stream lifecycle:\n\n- 🟧 **Parametrization Phase** : \n  The stream is configured but not yet active. Parameters such as $`\\lambda`$ (computation hardness) and $`\\#\\text{iterations}_\\phi`$ (number of iterations) are established during this phase.\n\n- 🟩 **Initialization Grace Phase**:\n  The stream is activated, and Stake Pool Operators (SPOs) are given a grace period to begin the first iteration of the computation.\n\n- 🟥 **Computation Phase**:\n  During this phase, the protocol expects attested outputs to be published on-chain. It consists of **82 computation iterations**, each producing an intermediate output that contributes to the final result.\n\n- 🟦 **Catch-up & Closure Phase**:\n  - A bounded recovery window that allows SPOs to submit any **missing attested outputs**, ensuring the completeness of the computation prior to finalization.\n  - A final dedicated interval to compute the **aggregation** of all previous outputs and derive the epoch’s final randomness $`\\eta_e`$. This phase **seals the stream** and concludes a lifecycle.\n\nThe diagram below illustrates how the lifecycle segment is structured:\n\n![alt text](./image/structured-intervals.png)\n\n### 3.2. The State Machine\n\n#### 3.2.1. Diagram Overview\n\nThe figure below presents the **state transition diagram** for the Phalanx computation stream. Each node represents a distinct state in the lifecycle of the stream, and the arrows indicate transitions triggered by `Tick` events. These transitions are guarded by boolean predicates evaluated at each slot (e.g., `isWithinComputationPhase`, `isWithinCurrentInterval`).\n\n![Phalanx State Transition Diagram](./image/state-transition-diagram.png)\n\nIn the following sections, we provide a detailed breakdown of each phase of the state machine, specifying its purpose, entry conditions, timing constraints, and transitions.\n\n#### 3.2.2. 🟧 Parametrization Phase\n\nAt the setup of $`\\phi^{stream}`$, the total number of VDF iterations is derived from the time-bound parameter $`T_\\Phi`$, using a reference hardware profile that reflects the minimal computational capacity expected of SPOs. While this derivation may not be fully automatable in practice, we include it here to clarify how time constraints are mapped to iteration counts during configuration.\n\nImportantly, this **parametrization phase** occurs only once, either during the initial bootstrap of the stream or following a transition from the `Closed` to `Initialized` state.\n\n<center>\n\n| `Parametrized`  |  $`\\Phi.\\text{Stream.State} \\in \\texttt{Parametrized} : \\left\\{ {securityParameter} \\in \\mathbb{N},\\quad I \\in \\mathbb{N} \\right\\}`$ |\n| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |\n| **Fields**       | <ul><li>$`\\text{securityParameter} \\in \\mathbb{N}`$ — The **security parameter**, defining the size (in bits) of the VDF discriminant.</li><li>$`I \\in \\mathbb{N}`$ — The **per-interval VDF iteration count**, computed from $`T_\\Phi`$ and evenly distributed across 82 computation intervals.</li></ul> |\n\n\n|  `parametrize` | $`\\Phi.\\text{Stream.State} \\leftarrow \\Phi.\\text{parametrize}(\\lambda,\\ T_\\Phi)`$|\n| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |\n| **Input Parameters**          | <ul><li>$`\\lambda \\in \\mathbb{N}`$ — **Security parameter**, defines the size (in bits) of the VDF discriminant.</li><li>$`T_\\Phi \\in \\mathbb{N}`$ — **Time budget** in seconds, representing the total computation time under reference hardware.</li></ul> |\n| **Derivation Logic**  | <ul><li>$`\\#\\text{Iterations}_\\Phi \\leftarrow \\texttt{VDF}.\\texttt{IterationsFromDuration}(T_\\Phi)`$</li><li>$`\\#\\text{Iterations}_\\phi \\leftarrow \\left\\lfloor \\frac{\\#\\text{Iterations}_\\Phi}{82} \\right\\rfloor`$</li></ul>                                  |\n| **Returned State** | $`\\texttt{Parametrized} \\left\\{ \\text{securityParameter} \\leftarrowtail \\lambda,\\quad I \\leftarrowtail \\#\\text{Iterations}_\\phi \\right\\}`$|\n\n</center>\n\n#### 3.2.3.  🟩 Initialization Grace Phase\n\nInitialization occurs at every pre-ηₑ synchronization point, followed by an *Initialization Grace* period during which the protocol waits long enough for the first iteration to be computed and its proof to be included within the first computation interval. This process recurs every $`10 \\cdot \\frac{k}{f}`$ slots.\n\n##### 3.2.3.1. Initialize Command\nWe show here how to initialize the class-group based VDF algorithm when generating a group for each different epoch. Were we to use the same group for many, if not all, epochs, we would run these steps in the *Parametrization phase* and change the discriminant seed $`\\Delta_{\\text{challenge}}`$ accordingly, e.g. if we use the same group forever we could use $`\\Delta_{\\text{challenge}} \\leftarrow \\text{Hash}(\\text{bin}(\\text{``IOHKPhalanx2025\"}))`$.\n\n<center>\n\n| `Initialized` | $`\\Phi.\\text{Stream.State} \\in \\texttt{Initialized} : \\left\\{ \\text{parametrized} \\in \\texttt{Parametrized},\\ \\text{group} \\in \\mathbb{G},\\  \\text{discriminant} \\in \\mathbb{Z},\\ \\text{operation} : \\mathbb{G} \\times \\mathbb{G} \\to \\mathbb{G} \\right\\}`$|\n| ----------- | -------------- |\n| **Fields**  | <ul><li>$\\text{parametrized} \\in \\texttt{Parametrized}$ — Reference to the prior configuration (security parameter and iteration count).</li><li>$\\text{group} \\in \\mathbb{G}$ — VDF group used for exponentiation.</li><li>$\\text{discriminant} \\in \\mathbb{Z}$ — Epoch-specific VDF discriminant.</li><li>$\\text{operation} : \\mathbb{G} \\times \\mathbb{G} \\to \\mathbb{G}$ — Group operation used for VDF evaluation (e.g., modular exponentiation).</li><li>$\\text{epochId}_e \\in \\mathbb{N}$ — Numerical identifier for epoch $e$.</li><li>$\\text{pre-}\\eta_e \\in \\{0,1\\}^{256}$ — 256-bit pre-nonce entropy for epoch $e$.</li></ul> |\n\n</center>\n\n<center>\n\n| `initialize`           | $\\Phi.\\text{Stream.State} \\leftarrow \\Phi.\\text{Initialize}(\\text{parametrizedState},\\ \\text{epochId}_e,\\ \\text{pre-}\\eta_e)$ |\n| -------------------- | ----------------------------------------- |\n| **Input Parameters** | <ul><li>$\\text{parametrizedState} = (\\lambda,\\ I) \\in \\texttt{Parametrized}$ — Configuration from the prior Parametrized state.</li><li>$\\text{epochId}_e \\in \\mathbb{N}$ — Numerical identifier for epoch $e$.</li><li>$\\text{pre-}\\eta_e \\in \\{0,1\\}^{256}$ — 256-bit pre-nonce entropy for epoch $e$.</li></ul>              |\n| **Derivation Logic** | <ul><li>$`\\Delta_{\\text{challenge}} \\leftarrow \\text{Hash}(\\text{bin}(\\text{epochId}_e) \\ \\|\\ \\text{pre-}\\eta_e)`$</li><li>$`(\\mathbb{G},\\ \\Delta,\\ \\cdot) \\leftarrow \\texttt{VDF.Setup}(\\lambda,\\ \\Delta_{\\text{challenge}})`$</li></ul> |\n| **Returned State**   | $`\\texttt{Initialized} \\left\\{ \\text{parametrized} \\leftarrowtail (\\lambda,\\ I),\\ \\text{group} \\leftarrowtail \\mathbb{G},\\ \\text{discriminant} \\leftarrowtail \\Delta,\\ \\text{operation} \\leftarrowtail \\cdot , \\ \\text{epochId}_e \\leftarrowtail \\text{epochId}_e ,\\ \\text{pre-}\\eta_e  \\leftarrowtail \\text{pre-}\\eta_e  \\right\\}`$                                        |\n\n</center>\n\n##### 3.2.3.2. Tick Commands & Grace Period\n\n<center>\n\n| `AwaitingComputationPhase` | $`\\Phi.\\text{Stream.State} \\in \\texttt{AwaitingComputationPhase} : \\left\\{ \\text{initialized} \\in \\texttt{Initialized},\\ \\text{currentSlot} \\in\\ \\mathbb{N} \\bmod \\left(10 \\cdot \\frac{k}{f}\\right) \\right\\}`$ |\n|--------------------|-------------|\n| **Fields** | <ul><li>$`\\text{initialized} \\in \\texttt{Initialized}`$ — Reference to the prior initialization.</li><li>$`\\text{currentSlot} \\in\\ \\mathbb{N} \\bmod \\left(10 \\cdot \\frac{k}{f}\\right)`$ — The current slot in the chain timeline.</li></ul> |\n\n</center>\n\n**Initial tick transition to `AwaitingComputationPhase`:**\n\n<center>\n\n| `tick`           | $\\Phi.\\text{Stream.State} \\leftarrow \\Phi.\\text{tick}(\\text{initializedState})$ |\n| -------------------- | ----------------------------------------- |\n| **Input Parameters** | <ul><li>$\\text{initializedState} \\in \\texttt{Initialized}$ — Configuration from the prior Initialized state.</li></ul>              |\n| **Returned State**   | $`\\texttt{AwaitingComputationPhase} \\left\\{ \\text{initialized} \\leftarrowtail initialiinitializedzedState,\\ \\text{currentSlot} \\leftarrowtail 0 \\right\\}`$  \n\n</center>\n\n**Subsequent ticks on `AwaitingComputationPhase`:**\n\n<center>\n\n| `tick`               | $`\\Phi.\\text{Stream.State} \\leftarrow \\Phi.\\text{tick}(\\text{awaitingComputationPhaseState})`$ |\n|--------------------|---------------------------------------------------------------------------------------------------|\n| **Input Parameters** | <ul><li>$`\\text{awaitingComputationPhaseState} \\in \\texttt{AwaitingComputationPhase}`$ — Configuration from the prior Initialized state.</li></ul> |\n| **Returned State**   | $` \\begin{cases} \\text{When } \\texttt{isWithinInitializationGracePhase} :\\ \\texttt{AwaitingComputationPhase}\\ \\{ \\text{initialized} ,\\ \\text{currentSlot++} \\} \\\\\\\\ \\text{When } \\texttt{isWithinComputationPhase} :\\ \\texttt{AwaitingAttestedOutput}\\ \\{ \\text{initialized} ,\\ \\text{currentSlot++} \\} \\end{cases}`$ |\n\n</center>\n\n#### 3.2.4.  🟥  Computation Phase\n\n##### 3.2.4.1. VDF integration\n\nWe are now entering the **Computation Phase**. We have waited long enough for the first slot leader within the initial interval to have the opportunity to produce a block and submit the corresponding attested output. However, because the slot distribution is privately visible, leaders within the interval cannot determine whether they are the first to produce a block.\n\nEach leader is free to adopt their own strategy for deciding whether to initiate the proof of computation. A simple and conservative approach is to wait until $`\\text{currentSlot} \\geq \\text{nextElectedSlot} - \\left(\\frac{T_\\Phi}{82} + C\\right)`$, where $`C`$ is a small constant. At that point, the leader may begin computing. If a block has already been produced by then, the leader can either skip the computation or abort it if already in progress. This delay increases the chances that any earlier eligible leaders have already submitted their outputs, thereby minimizing the risk of redundant proofs.\n\nTo publish the first block of interval $`i \\in [1..82]`$ of epoch $`e`$, the node invokes:\n\n```math\n(y_i, \\pi_i) \\leftarrow \\Phi.\\text{compute}(\\text{initialized} \\in \\texttt{Initialized},\\ i \\in \\texttt{Interval})\n```\n\nThis function internally calls the VDF primitives: $`y_i \\leftarrow \\texttt{VDF.Evaluate}((\\mathbb{G},\\ \\Delta,\\ \\cdot), \\ x_i,\\ I)`$ and $`\\pi \\leftarrow \\texttt{VDF.Prove}((\\mathbb{G},\\ \\Delta, \\cdot),\\ x_i,\\ y_i,\\ I)`$ with inputs constructed as:\n\n- $`x_i \\leftarrow \\text{Hash}(\\text{b``challenge\"} ||\\ \\text{bin}(e) ||\\ \\text{pre-}\\eta_e || \\text{bin}(i))`$\n- The parameters $`(\\mathbb{G}, \\Delta, \\cdot)`$ and $`I`$ are retrieved from the `Initialized` state.\n\nFinally, the node includes the attested outputs in the block header:\n\n- $`y_i`$: the VDF output for interval $`i`$\n- $`\\pi_i`$: the corresponding VDF proof for interval $`i`$\n\nIn rare cases, an interval may produce no block, and consequently, no expected proof for the corresponding iteration. The computation phase simply acknowledges these gaps; they are handled during the subsequent **Catch-up Phase**, which is specifically designed to resolve such missing outputs.\n\n##### 3.2.4.2. The States\n\nDuring the computation phase, the stream alternates between two closely related states: `AwaitingAttestedOutput` and `AttestedOutputProvided`. These two states are **structurally identical**, meaning they share the same underlying fields. What distinguishes them is their **semantic role** in the protocol’s lifecycle:\n\n* `AwaitingAttestedOutput` represents the period **before** an attestation has been submitted for the current interval.\n* `AttestedOutputProvided` signals that the attestation for the current interval has been **successfully received and verified**.\n\nThe field structure for both is as follows:\n\n```math\n\\Phi.\\text{Stream.State} \\in \\texttt{AwaitingAttestedOutput} : \\left\\{\n  \\begin{aligned}\n    &\\text{initialized}     &&\\in\\ \\texttt{Initialized}, \\\\\n    &\\text{currentSlot}     &&\\in\\ \\mathbb{N} \\bmod \\left(10 \\cdot \\frac{k}{f}\\right), \\\\\n    &\\text{attestedOutputs} &&\\in\\ \\left[\\texttt{Maybe}\\ (y, \\pi)\\right]^{82}\n  \\end{aligned}\n\\right\\}\n```\n\n<center>\n\n| **Field**   | **Description** |\n| ---- | -------- |\n| $`\\text{initialized} \\in \\texttt{Initialized}`$ | Reference to the prior initialization state.|\n| $`\\text{currentSlot} \\in\\ \\mathbb{N} \\bmod \\left(10 \\cdot \\frac{k}{f}\\right)`$| The current slot in the timeline.  |\n| $`\\text{attestedOutputs} \\in \\left[\\texttt{Maybe}\\ (y, \\pi)\\right]^{82}`$ | <ul><li>An array of optional attested outputs, one per computation interval.</li><li>Each index corresponds to a specific interval and may contain a proof pair $`(y, \\pi)`$.</li><li>If the output is not yet submitted, the entry is `None`.</li></ul> |\n\n</center>\n\nThe `AttestedOutputProvided` state reuses the exact same structure:\n\n```math\n\\Phi.\\text{Stream.State} \\in \\texttt{AttestedOutputProvided} : \\left\\{\n  \\begin{aligned}\n    &\\text{initialized}     &&\\in\\ \\texttt{Initialized}, \\\\\n    &\\text{currentSlot}     &&\\in\\ \\mathbb{N} \\bmod \\left(10 \\cdot \\frac{k}{f}\\right), \\\\\n    &\\text{attestedOutputs} &&\\in\\ \\left[\\texttt{Maybe}\\ (y, \\pi)\\right]^{82}\n  \\end{aligned}\n\\right\\}\n```\n\nThis version aligns both the field names and their types in two neat columns. Let me know if you'd prefer the braces to be placed differently (e.g. outside the alignment block) for aesthetic reasons.\n\n<center>\n\n| **Field**   | **Description**    |\n| ------------- | --------------- |\n| $`\\text{initialized} \\in \\texttt{Initialized}`$ | Reference to the prior initialization state.     |\n| $`\\text{currentSlot} \\in\\ \\mathbb{N} \\bmod \\left(10 \\cdot \\frac{k}{f}\\right)`$ | The current slot in the timeline.   |\n| $`\\text{attestedOutputs} \\in \\left[\\texttt{Maybe}\\ (y, \\pi)\\right]^{82}`$ | <ul><li>An array of optional attested outputs, one per computation interval.</li><li>Each index corresponds to a specific interval and may contain a proof pair $`(y, \\pi)`$.</li><li>If the output hasn't been submitted yet, the entry is `None`.</li><li>For the current interval, the output **has already been provided** in this state.</li></ul> |\n\n</center>\n\n##### 3.2.4.3. ProvideAttestedOutput & Tick Commands\n\nThe `provideAttestedOutput` command is used to submit a new attested output $`\\phi_i = (y_i, \\pi_i)`$ for a specific interval $`i`$, when the protocol is in the `AwaitingAttestedOutput` state. This function verifies the validity of the provided proof and updates the stream state accordingly :\n\n<center>\n\n| `provideAttestedOutput` | $`\\Phi.\\text{Stream.State} \\leftarrow \\Phi.\\text{provideAttestedOutput}(\\text{awaitingAttestedOutputState},\\ \\phi_i)`$ |\n|-------------------------|--------------------------------------------------------------------------------------------------------------------------|\n| **Input Parameters**    | <ul><li>$`\\text{awaitingAttestedOutputState} \\in \\texttt{AwaitingAttestedOutput}`$ — Current state awaiting an attested output $`\\phi_i`$ for interval $`i`$.</li><li>$`\\phi_i = (y_i, \\pi_i)`$ — Attested output and corresponding proof.</li></ul> |\n| **Property Check**      | <ul><li>Ensure $`\\phi_i`$ is valid by verifying: $`\\texttt{VDF.Verify}((\\mathbb{G},\\ \\Delta,\\ \\cdot),\\ x_i,\\ y_i,\\ I,\\ \\pi_i)`$</li> <li>Where:<br> $`x_i = \\text{Hash}(\\text{b``challenge\"}\\ \\|\\|\\ \\text{bin}(e)\\ \\|\\|\\ \\text{pre-}\\eta_e\\ \\|\\|\\ \\text{bin}(i))`$<br> $`I \\in \\mathbb{N}`$ is the per-interval iteration count.</li></ul> |\n| **Returned State**      | $`\\texttt{AttestedOutputProvided}\\ \\{ \\text{initialized},\\ \\text{currentSlot} + 1,\\ \\text{attestedOutputs}[i] \\leftarrowtail \\phi_i \\}`$ — Updated state reflecting the verified attestation. |\n\n</center>\n\nOnce an attested output has been provided, the next slot may trigger a `tick` event. If no further action is taken, the system must determine whether it remains within the current interval, moves to the next, or enters the catch-up phase. The following command captures this logic when starting from the `AttestedOutputProvided` state :\n\n<center>\n\n| `tick`               | $`\\Phi.\\text{Stream.State} \\leftarrow \\Phi.\\text{tick}(\\text{attestedOutputProvidedState})`$ |\n|----------------------|---------------------------------------------------------------------------------------------------|\n| **Input Parameters** | <ul><li>$`\\text{attestedOutputProvidedState} \\in \\texttt{AttestedOutputProvided}`$ — The current state after an attestation has been successfully provided.</li></ul> |\n| **Returned State**   | $`\\begin{cases} \\text{When } \\texttt{isWithinCurrentInterval} &: \\texttt{AttestedOutputProvided} \\{ \\dots,\\ \\text{currentSlot++} \\} \\\\\\\\ \\text{When } \\texttt{isWithinNextInterval} &: \\texttt{AwaitingAttestedOutput} \\{ \\dots,\\ \\text{currentSlot++} \\} \\\\\\\\ \\text{When } \\texttt{isWithinCatchUpPhase} &: \\texttt{AwaitingMissingAttestedOutput} \\{ \\dots,\\ \\text{currentSlot++} \\} \\end{cases}`$ |\n\n</center>\n\nAlternatively, when still waiting for an attestation and no block was produced, a `tick` may trigger a transition based on the current time. This command applies to the `AwaitingAttestedOutput` state before any attestation has been submitted :\n\n<center>\n\n| `tick`               | $`\\Phi.\\text{Stream.State} \\leftarrow \\Phi.\\text{tick}(\\text{awaitingAttestedOutputState})`$ |\n|--------------------|---------------------------------------------------------------------------------------------------|\n| **Input Parameters** | <ul><li>$`\\text{awaitingAttestedOutputState} \\in \\texttt{AwaitingAttestedOutput}`$ — Current state awaiting an attested output $`\\phi_i`$ for interval $`i`$.</li><li>$`\\phi_i = (y_i, \\pi_i)`$ — Attested output and corresponding proof.</li></ul> |\n| **Returned State**   | $` \\begin{cases} \\text{When } \\texttt{isWithinCurrentInterval} :\\ \\texttt{AwaitingComputationPhase}\\ \\{ \\text{..} ,\\ \\text{currentSlot++} \\} \\\\\\\\ \\text{When } \\texttt{isWithinCatchUpPhase} :\\ \\texttt{AwaitingMissingAttestedOutput}\\ \\{ \\text{..} ,\\ \\text{currentSlot++} \\}  \\\\\\\\ \\text{When } \\texttt{isClosable} :\\ \\texttt{AwaitingGracefulClosure}\\ \\{ \\text{..} ,\\ \\text{currentSlot++} \\}\\end{cases}`$ |\n\n</center>\n\n`isClosable` indicates that all attested outputs have been successfully provided, and only the final interval remains, during which the outputs are aggregated and the seed $`\\eta_e`$ is derived and recorded on-chain.\n\n#### 3.2.5.  🟦 Catch-up Phase\n\nThis Catch-up Phase closely resembles the preceding Computation Phase, but its purpose is to recover from any blockless intervals that may have occurred — albeit such cases are extremely rare.\n\nThe phase spans a total of 37 intervals: 36 are reserved to account for up to 36 consecutive intervals without block production (e.g., a global outage affecting 30% of an epoch), and 1 final interval is allocated for the Closure Phase. As in the Computation Phase, missing attested outputs must be submitted in order, one per interval.\n\nThe faster these missing outputs are provided, the sooner the state machine can transition to the final phase. Although the protocol allocates 37 intervals to handle the worst-case scenario, recovery may complete much earlier in practice.\n\nThis section focuses solely on the Catch-up Phase; the next section will describe the process of stream closure.\n\n##### 3.2.5.1. The States\n\nStructurally, we define two states that are similar in form and semantics to `AwaitingMissingAttestedOutput` and `AttestedMissingOutputProvided`:\n\n```math\n\\Phi.\\text{Stream.State} \\in \\texttt{AwaitingMissingAttestedOutput} : \\left\\{\n  \\begin{aligned}\n    &\\text{initialized}     &&\\in\\ \\texttt{Initialized}, \\\\\n    &\\text{currentSlot}     &&\\in\\ \\mathbb{N} \\bmod \\left(10 \\cdot \\frac{k}{f}\\right), \\\\\n    &\\text{attestedOutputs} &&\\in\\ \\left[\\texttt{Maybe}\\ (y, \\pi)\\right]^{82}\n  \\end{aligned}\n\\right\\}\n```\n\n```math\n\\Phi.\\text{Stream.State} \\in \\texttt{AttestedMissingOutputProvided} : \\left\\{\n  \\begin{aligned}\n    &\\text{initialized}     &&\\in\\ \\texttt{Initialized}, \\\\\n    &\\text{currentSlot}     &&\\in\\ \\mathbb{N} \\bmod \\left(10 \\cdot \\frac{k}{f}\\right), \\\\\n    &\\text{attestedOutputs} &&\\in\\ \\left[\\texttt{Maybe}\\ (y, \\pi)\\right]^{82}\n  \\end{aligned}\n\\right\\}\n```\n\nThis phase focuses on recovering the missing attested outputs—specifically, the `None` entries in the `attestedOutputs` array. The goal during this phase is to have those missing values provided.This phase operates under strict sequential expectations where the missing attested outputs must be provided in order, one per interval, as in the Computation Phase. To make this explicit, we define the sequence of expected indices as follows:\n\n```math\n\\text{ExpectedMissingIndices} := \\left\\{ i \\in \\{1, \\dots, 82\\} \\mid \\text{attestedOutputs}[i] = \\texttt{Nothing} \\right\\}\n```\nThis ordered set defines the exact sequence in which the missing attestations must be submitted during the Catch-up Phase.\n\n\n##### 3.2.5.2. ProvideMissingAttestedOutput & Tick Commands\n\nThe `provideMissingAttestedOutput` command is used to submit a missing attested output $`\\phi_i = (y_i, \\pi_i)`$ for a specific interval $`i`$, when the protocol is in the `AwaitingMissingAttestedOutput` state. This function checks the validity of the proof and updates the stream state accordingly:\n\n<center>\n\n| `provideMissingAttestedOutput` | $`\\Phi.\\text{Stream.State} \\leftarrow \\Phi.\\text{provideMissingAttestedOutput}(\\text{awaitingMissingAttestedOutputState},\\ \\phi_i)`$  |\n| ----- | --- |\n| **Input Parameters**           | <ul><li>$`\\text{awaitingMissingAttestedOutputState} \\in \\texttt{AwaitingMissingAttestedOutput}`$ — State awaiting a missing attestation $`\\phi_i`$ for interval $`i`$.</li><li>$`\\phi_i = (y_i, \\pi_i)`$ — Attested output and its proof.</li></ul>                                            |\n| **Property Check**             | <ul><li>Verify $`\\phi_i`$ with: $`\\texttt{VDF.Verify}((\\mathbb{G},\\ \\Delta,\\ \\cdot),\\ x_i,\\ y_i,\\ I,\\ \\pi_i)`$</li><li>Where:<br> $`x_i = \\text{Hash}(\\text{b``challenge\"}\\ \\|\\|\\ \\text{bin}(e)\\ \\|\\|\\ \\text{pre-}\\eta_e\\ \\|\\|\\ \\text{bin}(i))`$</li><li>$`I \\in \\mathbb{N}`$ is the per-interval iteration count.</li></ul> |\n| **Returned State**             | $`\\texttt{MissingAttestedOutputProvided} \\{ \\text{initialized},\\ \\text{currentSlot} + 1,\\ \\text{attestedOutputs}[i] \\leftarrowtail \\phi_i \\}`$ — Updated state reflecting the accepted missing output.                                                                                                      |\n\n</center>\n\nOnce a missing attested output has been provided, the next slot may trigger a `tick` event. The system must determine whether it remains within the current interval, moves to the next, or enters the closure phase. The following command captures this logic when starting from the `MissingAttestedOutputProvided` state :\n\n<center>\n\n| `tick`               | $`\\Phi.\\text{Stream.State} \\leftarrow \\Phi.\\text{tick}(\\text{missingAttestedOutputProvidedState})`$ |\n|----------------------|---------------------------------------------------------------------------------------------------|\n| **Input Parameters** | <ul><li>$`\\text{missingAttestedOutputProvidedState} \\in \\texttt{MissingAttestedOutputProvided}`$ — The current state after an attestation has been successfully provided.</li></ul> |\n| **Returned State**   | $`\\begin{cases} \\text{When } \\texttt{isWithinCurrentInterval} &: \\texttt{MissingAttestedOutputProvided} \\{ \\dots,\\ \\text{currentSlot++} \\} \\\\\\\\ \\text{When } \\texttt{isWithinNextInterval} &: \\texttt{AwaitingMissingAttestedOutput} \\{ \\dots,\\ \\text{currentSlot++} \\} \\\\\\\\ \\text{When } \\texttt{isClosable} &: \\texttt{AwaitingGracefulClosure} \\{ \\dots,\\ \\text{currentSlot++} \\} \\\\\\\\ \\text{When } \\texttt{isUngracefullyClosable} &: \\texttt{UngracefullyClosed} \\{.., {pre-}\\eta_e = {initialized.}{pre-}\\eta_e \\} \\} \\end{cases}`$ |\n\n</center>\n\nAlternatively, when still waiting for an attestation and no block was produced, a `tick` may trigger a transition based on the current time. This command applies to the `AwaitingMissingAttestedOutput` state before any attestation has been submitted :\n\n<center>\n\n| `tick`               | $`\\Phi.\\text{Stream.State} \\leftarrow \\Phi.\\text{tick}(\\text{awaitingMissingAttestedOutputState})`$ |\n|--------------------|---------------------------------------------------------------------------------------------------|\n| **Input Parameters** | <ul><li>$`\\text{awaitingMissingAttestedOutputState} \\in \\texttt{AwaitingMissingAttestedOutput}`$ — Current state awaiting an attested output $`\\phi_i`$ for interval $`i`$.</li><li>$`\\phi_i = (y_i, \\pi_i)`$ — Attested output and corresponding proof.</li></ul> |\n| **Returned State**   | $` \\begin{cases} \\text{When } \\texttt{isWithinCurrentInterval} :\\ \\texttt{AwaitingMissingAttestedOutput}\\ \\{ \\text{..} ,\\ \\text{currentSlot++} \\} \\\\\\\\ \\text{When } \\texttt{isClosable} :\\ \\texttt{AwaitingGracefulClosure}\\ \\{ \\text{..} ,\\ \\text{currentSlot++} \\} \\\\\\\\ \\text{When } \\texttt{isUngracefullyClosable} :\\ \\texttt{UngracefullyClosed} \\{.., {pre-}\\eta_e = {initialized.}{pre-}\\eta_e \\} \\}\\end{cases}`$ |\n\n</center>\n\n`isUngracefullyClosable` indicates that the end of the lifecycle segment has been reached (i.e., `currentSlot++ == 0`), while some attested outputs are still missing. When this condition holds, the lifecycle is forcefully closed in an ungraceful manner.\n\n\n#### 3.2.6 ⬛ Closure Phase\n\nWe now enter the final phase of the lifecycle, during which all collected outputs are expected to be aggregated and recorded on-chain, and the seed $\\eta_e$ derived and committed.\n\n**Successful Scenarios:**\nIn these cases, all attested outputs have been provided by the end of the catch-up phase.\n\n- **Best-case scenario:** The closure phase begins at interval 84, giving the system 37 intervals to perform output aggregation and seed commitment under normal operating conditions.\n- **Worst-case scenario:** The catch-up mechanism is fully utilized, and the system enters the closure phase at interval 120, the very last interval of the lifecycle segment. Even so, all necessary outputs have been successfully provided.\n\n**Failure Scenario:**\n\nThis occurs when the lifecycle segment reaches its end (i.e., the full $10 \\cdot \\frac{k}{f}$ slots), and despite the entire duration of the catch-up mechanism (up to interval 120), either some required attested outputs remain missing, or all outputs have been delivered but the final aggregation has not occurred.\nThis scenario represents an extremely rare event—statistically far beyond 128-bit confidence—and reflects a severe disruption in which no blocks have been produced for over 36 hours. These edge cases are represented in the diagram by the transition `Tick / isUngracefullyClosable`.\n\n##### 3.2.6.1. The States \n\nIn this phase, we define two states:\n\n- `AwaitingGracefulClosure`: This state signifies that all 82 attested outputs have been successfully collected. At this point, the outputs are no longer optional—each index is populated with a verified pair $`(y, \\pi)`$.\n\n```math\n\\Phi.\\text{Stream.State} \\in \\texttt{AwaitingGracefulClosure} : \\left\\{\n  \\begin{aligned}\n    &\\text{initialized}     &&\\in\\ \\texttt{Initialized}, \\\\\n    &\\text{currentSlot}     &&\\in\\ \\mathbb{N} \\bmod \\left(10 \\cdot \\frac{k}{f}\\right), \\\\\n    &\\text{attestedOutputs} &&\\in\\ \\left[(y, \\pi)\\right]^{82}\n  \\end{aligned}\n\\right\\}\n```\n\n- `Closed`: This is a final state in the stream lifecycle. It signifies that the aggregated output has been computed and verified, and the final epoch randomness \\$`\\eta_e`\\$ has been successfully derived—achieving the core objective of the protocol. This state is reached in response to either a `Close` command :\n\n```math\n\\Phi.\\text{Stream.State} \\in \\texttt{Closed} : \\left\\{\n  \\begin{aligned}\n    &\\text{initialized}      &&\\in\\ \\texttt{Initialized}, \\\\\n    &\\text{attestedOutputs}  &&\\in\\ \\left[(y, \\pi)\\right]^{82}, \\\\\n    &\\text{aggregatedOutput} &&\\in\\ (x, y, \\pi), \\\\\n    &\\eta_e                  &&\\in\\ \\{0,1\\}^{256} \n  \\end{aligned}\n\\right\\}\n```\n\n- `UngracefullyClosed`: This is a terminal state in the stream lifecycle. It indicates that either not all expected attested outputs were provided, or the aggregated output could not be computed. As a result, $`{pre-}\\eta_e`$ is returned as the final value of $`\\eta_e`$. Statistically, this state is highly unlikely to occur, but it is explicitly handled for completeness and structural consistency of the state machine. The transition to this state is triggered by `Tick` in combination with the `isUngracefullyClosable` condition.\n\n```math\n\\Phi.\\text{Stream.State} \\in \\texttt{UngracefullyClosed} : \\left\\{\n  \\begin{aligned}\n    &\\text{initialized}      &&\\in\\ \\texttt{Initialized}, \\\\\n    &\\text{attestedOutputs} &&\\in\\ \\left[\\texttt{Maybe}\\ (y, \\pi)\\right]^{82} \\\\\n    &{pre-}\\eta_e                  &&\\in\\ \\{0,1\\}^{256} \n  \\end{aligned}\n\\right\\}\n```\n\n##### 3.2.6.2. The Successful Scenario: The `Close` Command\n\nAt this stage, the system is in the `AwaitingGracefulClosure` state. All necessary data has been collected, and a block can now be produced within the remaining time before the end of the stream lifecycle (as previously discussed, this could occur at the 84th or 120th interval, depending on how smoothly the lifecycle progressed).\n\nIn this scenario, the first block producer within the remaining intervals must include the following values in the block body:\n\n- $`(y, \\pi)`$: The aggregated output of the $`\\Phi`$ computation, representing the final result and its corresponding proof.\n- $`\\eta_e`$: The final objective of the protocol—a 256-bit epoch randomness beacon, which will be used to seed leader election in the next epoch.\n\nThese values complete the stream and trigger the transition to the `Closed` state.\n\n<center>\n\n| `Close`    | $`\\Phi.\\text{Stream.State} \\leftarrow \\Phi.\\text{Close}((x, y, \\pi),\\ \\text{awaitingGracefulClosureState})`$  |\n| -------------------- | ---- |\n| **Input Parameters** | <ul><li>$`\\text{awaitingGracefulClosureState} \\in \\texttt{AwaitingGracefulClosure}`$ — State indicating readiness for closure.</li><li>$`(y,\\ \\pi)`$ — Aggregated output and its proof for the entire stream.</li></ul>                                                                                                    |\n| **Property Check**   | <ul><li>Verify the aggregated output with:<br> $`\\texttt{VDF.Aggregation.Verify}((\\mathbb{G},\\ \\Delta,\\ \\cdot),\\ \\lambda,\\ x,\\ y,\\ \\text{attestedOutputs},\\ \\pi)`$</li><li>Where:<br> $`\\lambda`$ is the security parameter, <br> $`x`$ is the aggregated input of the $`\\Phi`$ computation<br>$`\\text{attestedOutputs} = \\text{awaitingGracefulClosureState.attestedOutputs}`$</li></ul> |\n| **Epoch Randomness** | $`\\eta_e = \\text{Hash}^{(256)}(y)`$ — Apply the SHA-256 hash function to $`y`$.  |\n| **Returned State**   | $`\\texttt{Closed} \\{ \\text{initialized},\\ \\text{attestedOutputs},\\ (x, y, \\pi),\\ \\eta_e \\}`$ — Final state embedding the verified computation and the derived epoch randomness.  |\n\n</center>\n\n##### 3.2.6.3. `tick` Command\n\nThe `tick` command handles time progression within the `AwaitingGracefulClosure` state:\n\n-  **`isUngracefullyClosable`** is true when the stream reaches the end of its lifecycle segment (i.e., $`\\texttt{currentSlot} + 1 \\equiv 0 \\pmod{T}`$) and some attested outputs are still missing. When this condition holds, the system transitions to the `UngracefullyClosed` state.\n\n-  **Otherwise**, the command simply increments the `currentSlot` field to reflect time advancement.\n\n<center>\n\n| `tick`               | $`\\Phi.\\text{Stream.State} \\leftarrow \\Phi.\\text{tick}(\\text{awaitingGracefulClosureState})`$ |\n|--------------------|---------------------------------------------------------------------------------------------------|\n| **Input Parameters** | <ul><li>$`\\text{awaitingGracefulClosureState} \\in \\texttt{AwaitingMissingAttestedOutput}`$ — State indicating readiness for closure.</li></ul> |\n| **Returned State**   | $`\\begin{cases} \\text{When } \\texttt{isUngracefullyClosable} :\\ \\texttt{UngracefullyClosed} \\{.., {pre-}\\eta_e = {initialized.}{pre-}\\eta_e \\} \\\\\\\\ \\text{Otherwise} :\\ \\texttt{AwaitingGracefulClosure} \\{\\, \\ldots,\\, \\texttt{currentSlot} + 1 \\,\\} \\end{cases}`$ |\n\n</center>\n\n`isUngracefullyClosable` indicates that the end of the lifecycle segment has been reached (i.e., `currentSlot++ == 0`), while some attested outputs are still missing. When this condition holds, the lifecycle is forcefully closed in an ungraceful manner. Otherwise we are just update the current slot field\n\n##### 3.2.6.4. The Failure Scenario: Ungraceful Closure\n\nIf the protocol reaches the end of its lifecycle, or it becomes evident that too many consecutive blockless intervals have occurred—such that a valid $`\\eta_e`$ can no longer be derived—the `Tick` signal triggers the `isUngracefullyClosable` condition. This causes a transition to the terminal state `UngracefullyClosed`, in which the precomputed value $`{pre-}\\eta_e`$ is adopted as the official $`\\eta_e`$.\n\nWhile this state is statistically unexpected, it is explicitly defined to ensure completeness and structural consistency within the state machine.\n\n### 4. Recommended Parameter values\n\nThere are **two categories of parameters** in the Phalanx protocol that Cardano governance will need to oversee. The first category concerns the **VDF parameters**, which are essential to maintaining the protocol’s cryptographic security. The second concerns the **total time budget** $T_\\Phi$ that will be required from SPOs during the **Computation Phase**.\n\nThe goal of this section is to provide **recommended values** for these parameters along with the **rationale** behind their selection, so that governance is well-equipped to **adjust them over time** in response to advances in adversarial computational power.\n\n#### 4.1 VDF Security Parameters λ and ρ\n\nThe VDF component in Phalanx relies on class group security, which is parameterized by two values:\n\n- $`\\lambda`$, the **class group security parameter**, and\n- $`\\rho`$, the **grinding resistance parameter**, newly introduced in the Phalanx design.\n\nSeveral combinations of $`\\lambda`$ and $`\\rho`$ are considered in the literature, depending on the desired level of paranoia or efficiency. Based on the recommendations from the paper [Trustless Unknown-Order Groups]((https://arxiv.org/pdf/2211.16128)), we highlight the following trade-offs: \n\n- A **paranoid** setting, $(\\lambda, \\rho) = (128, 128)$, requires a **group size of \\~3400 bits**.\n- A more **realistic yet cautious** setting, $(\\lambda, \\rho) = (128, 55)$, brings the group size down to **\\~1900 bits**, but requires discriminants of at least **3800 bits**.\n- Based on those benchmarks and our needs, we opt for $(\\lambda, \\rho) = (128, 64)$, which corresponds to:\n\n  - a **discriminant size of 4096 bits**,\n  - and a **group size of 2048 bits**.\n\nThis strikes a balance between long-term security and practical efficiency:\n\n- On one hand, **breaking the class group** is considered harder than **finding a collision in a 256-bit hash** (our minimum security baseline).\n- On the other hand, by following the paper’s recommendation and selecting a slightly lower $`\\rho = 64`$, we can **reduce the size of on-chain group elements** while maintaining sufficient resistance against grinding.\n\nSince Phalanx is designed to operate with a **single class group instance “for the lifetime of the protocol”** (reparametrization would require explicit governance intervention), this configuration $(\\lambda, \\rho) = (128, 64)$ ensures protocol simplicity, consistency, and operational predictability.\n\n#### 4.2 Time Budget Tᵩ and Derived T\n\nIn terms of efficiency, the section [**1. How Phalanx Addresses CPS-21 – Ouroboros Randomness Manipulation**](#1-how-phalanx-addresses-cps-21---ouroboros-randomness-manipulation) in the *Rationale* part of this document illustrates, through three scenarios $`\\text{Phalanx}_{1/10}`$, $`\\text{Phalanx}_{1/100}`$, and $`\\text{Phalanx}_{\\text{max}}`$, how different time budgets (2 hours, 12 hours, and 5 days, respectively) improve the protocol’s security guarantees against grinding attacks.\n\nIn terms of computational load, we recommend setting the time budget at a **midpoint between minimal and maximal protocol capacity**, corresponding to approximately **12 hours** of execution on typical, CPU-based hardware as recommended for SPOs. However, this choice should ultimately be guided by **settlement time performance requirements** across the ecosystem, including the needs of **partner chains and other dependent components**.\n\n##### 4.2.1 Specialized ASIC vs CPU-Based Chips\n\nWe need to account for the possibility that adversaries may equip themselves with specialized ASIC chips optimized for computing Wesolowski’s Verifiable Delay Function (VDF). The Chia team has already developed and deployed such **ASIC Timelords**, which demonstrate between **3× and 5× performance improvements** compared to standard CPU-based implementations. These ASICs reach up to **1,000,000 iterations per second**, while commodity CPU Timelords typically max out around **260,000 IPS** ([Chia Network, Oct 2023](https://www.chia.net/2023/10/26/were-going-to-ludicrous-speed)).\n\nTo mitigate this performance asymmetry, our initial strategy is to require a **12-hour equivalent workload on standard CPU hardware** (as in $`\\text{Phalanx}_{1/10}`$), which is calibrated to provide the **same security guarantees** as a less aggressive configuration like $`\\text{Phalanx}_{1/100}`$. This gives us a conservative baseline for security, assuming an adversary might leverage ASIC acceleration.\n\nCritically, scaling this kind of grinding capability is expensive. For an adversary to mount an effective grinding attack, they would need to build and operate a farm of VDF-optimized ASICs — a non-trivial financial and operational challenge. Chia’s rollout of these units has been tightly controlled and aimed at ensuring global distribution, not centralization ([Chia Global Expansion Update, June 2024](https://www.chia.net/2024/06/10/global-expansion-of-chia-network-security-with-successful-asic-timelord-rollout)).\n\n**Mid-term**, we propose encouraging — or potentially requiring — stake pool operators (SPOs) to adopt VDF ASIC hardware. This would ensure that honest participants remain competitive and are not systematically outperformed by well-resourced adversaries.\n\n**Long-term**, our strategy involves standardizing the use of verifiable delay ASICs across the network, or alternatively, establishing a dynamic calibration process. This would allow iteration requirements to be periodically adjusted based on the evolving performance gap between commodity and specialized hardware, maintaining consistent and predictable security guarantees.\n\nIn summary, while ASIC-equipped adversaries could, in theory, gain a computational advantage during the grinding window, the cost and scale required to pose a real threat remains high. Our mitigation strategy is to raise the honest baseline to neutralize this advantage and prepare for possible hardware evolution over time.\n\n##### 4.2.1 Deriving from Tᵩ to T\n\nWe recommend a **12-hour computation budget** on standard **CPU-based machines**, which we estimate to be **10× slower** than specialized ASICs available to adversaries. This configuration corresponds to **Phalanx<sub>1/10</sub>** in terms of **time budget**, while achieving **Phalanx<sub>1/100</sub>** in terms of **security guarantees** against grinding attacks.\n\nHowever, this **time budget** ($T\\_\\Phi$) is a high-level abstraction. To implement it concretely, we must derive the **number of VDF iterations** ($T$) required for each **first block of an interval**. Assuming 82 intervals per epoch, this translates to:\n\n```math\nT = \\frac{T_\\Phi}{82} = \\frac{12 \\text{ hours} \\times 3600 \\text{ seconds/hour}}{82} \\approx 527 \\text{ seconds}\n```\n\nSo, we ask for approximately **10 minutes of VDF computation** per published interval block on standard CPU-based hardware.\n\nTo translate this into a concrete number of **VDF iterations** ($T$), we rely on performance benchmarks from the implementation available in the repository [rrtoledo/chiavdf](https://github.com/rrtoledo/chiavdf). This library is a **highly optimized and production-hardened** implementation of Wesolowski's VDF, currently in use by the **Chia blockchain**. We have made minor, superficial modifications to this codebase solely to facilitate benchmarking and increase the discriminant size.\n\nThanks to its well-established performance profile, this implementation provides a dependable baseline for estimating how many iterations can be executed within a fixed time frame on standard CPU hardware. Under our test environment—an Ubuntu machine equipped with an **Intel® Core™ i9-14900HX (32 cores, 64 GiB RAM)**—we observed approximately **27 million iterations** in a 10-minute window.\n\n**Note** : We recommend that this benchmark be re-run on a **dedicated, representative SPO machine** to calibrate a more accurate production value for $T$.\n\n### 5. Efficiency analysis\n\n#### 5.1 Block Publication\n\nTo publish a block, a node must:\n\n* Perform $T$ squarings to compute the output,\n* Execute $O(T / \\log(T))$ operations for the proof generation.\n\nWe now show benchmarks for evaluating and proving together VDFs, as well as individually, for different discriminant sizes done on a Ubuntu computer with Intel® Core™ i9-14900HX with 32 cores and 64.0 GiB RAM.  For a 4,096 bit long discriminant, we perform around 45,000 iterations per second, and so evaluate and prove a VDF in 22.6s.\n\n<center>\n\n|   Size Discriminant |   #iterations |      IPS |   Evaluate and Prove  (s) |   σ proving | Eval (s)       |   σ proving | Prove (s)      |   σ proving |\n|-------------------- | ------------- | -------- | ------------------------- | ----------- | -------------- | ----------- | -------------- | ----------- |\n|                 256 |        10,000 | 637252   |                    0.0187 |    0.000676 | 1.57E-02 (84%) |    0.000563 | 8.00E-03 (43%) |    0.000461 |\n|                 256 |       100,000 | 641349   |                    0.172  |    0.00115  | 1.56E-01 (91%) |    0.00188  | 5.68E-02 (33%) |    0.00165  |\n|                 256 |     1,000,000 | 627336   |                    1.72   |    0.0215   | 1.59E+00 (93%) |    0.0197   | 4.88E-01 (29%) |    0.00633  |\n|                 512 |        10,000 | 367449   |                    0.0322 |    0.000635 | 2.72E-02 (85%) |    0.000648 | 1.31E-02 (41%) |    0.000204 |\n|                 512 |       100,000 | 378942   |                    0.289  |    0.0029   | 2.64E-01 (92%) |    0.00283  | 8.76E-02 (31%) |    0.000893 |\n|                 512 |     1,000,000 | 378204   |                    2.83   |    0.0287   | 2.64E+00 (94%) |    0.0279   | 7.29E-01 (26%) |    0.00873  |\n|                1024 |        10,000 | 206186   |                    0.0537 |    0.000902 | 4.85E-02 (91%) |    0.00076  | 2.00E-02 (38%) |    0.000364 |\n|                1024 |       100,000 | 211921   |                    0.503  |    0.00722  | 4.72E-01 (94%) |    0.00721  | 1.45E-01 (29%) |    0.00198  |\n|                1024 |     1,000,000 | 213319   |                    4.92   |    0.0506   | 4.69E+00 (96%) |    0.0475   | 1.20E+00 (25%) |    0.0136   |\n|                2048 |        10,000 | 103135   |                    0.105  |    0.000285 | 9.70E-02 (92%) |    0.000303 | 3.77E-02 (36%) |    0.000122 |\n|                2048 |       100,000 | 105315   |                    1.01   |    0.0165   | 9.50E-01 (94%) |    0.0123   | 2.78E-01 (28%) |    0.00516  |\n|                2048 |     1,000,000 | 107038   |                    9.75   |    0.0746   | 9.34E+00 (96%) |    0.0828   | 2.20E+00 (23%) |    0.0209   |\n|                4096 |        10,000 |  44567.8 |                    0.244  |    0.00463  | 2.24E-01 (92%) |    0.00454  | 8.30E-02 (35%) |    0.00168  |\n|                4096 |       100,000 |  45848.6 |                    2.31   |    0.0253   | 2.18E+00 (95%) |    0.0229   | 6.00E-01 (26%) |    0.0089   |\n|                4096 |     1,000,000 |  46293.2 |                   22.6    |    0.16     | 2.16E+01 (96%) |    0.148    | 4.79E+00 (22%) |    0.0422   |\n\n</center>\n\n#### 5.2 Block Verification\n\n##### 5.2.1 When Not Syncing\n\nTo verify a VDF proof, a node performs:\n\n* 2 hashes,\n* 4 small exponentiations,\n* 3 group multiplications.\n\nOver an epoch with $N$ intervals, this results in:\n* $2 \\cdot N$ hashes,\n* $4 \\cdot N$ small exponentiations,\n* $3 \\cdot N$ group multiplications.\n\n\nWe now show verification benchmarks for discriminants of different sizes done on the same machine as before. For a 4,096 bit long discriminant, the verification takes around 15ms.\n\n<center>\n\n|   Size Discriminant |   #iterations | Verification (ms)   |   σ verification |\n|-------------------- | ------------- | ------------------- | ---------------- |\n|                 256 |        10,000 | 1.74E+00 (10%)      |           0.0786 |\n|                 256 |       100,000 | 1.12E+00 (1%)       |           0.0471 |\n|                 256 |     1,000,000 | 1.75E+00 (1%)       |           0.151  |\n|                 512 |        10,000 | 3.25E+00 (11%)      |           0.0562 |\n|                 512 |       100,000 | 1.89E+00 (1%)       |           0.0268 |\n|                 512 |     1,000,000 | 2.11E+00 (1%)       |           0.134  |\n|                1024 |        10,000 | 3.66E+00 (7%)       |           0.117  |\n|                1024 |       100,000 | 3.21E+00 (1%)       |           0.0467 |\n|                1024 |     1,000,000 | 3.20E+00 (1%)       |           0.135  |\n|                2048 |        10,000 | 7.00E+00 (7%)       |           0.0409 |\n|                2048 |       100,000 | 9.33E+00 (1%)       |           0.147  |\n|                2048 |     1,000,000 | 6.40E+00 (1%)       |           0.218  |\n|                4096 |        10,000 | 1.58E+01 (7%)       |           0.316  |\n|                4096 |       100,000 | 1.47E+01 (1%)       |           0.248  |\n|                4096 |     1,000,000 | 1.37E+01 (1%)       |           0.303  |\n\n</center>\n\n##### 5.2.2 When Syncing\n\nWhen synching, the nodes only need to update the accumulators and verify the final aggregation proof. As such, the node perform in total arounf half as less operations than verifying all proofs individually. More particularly, we have:\n* $2 \\cdot N$ hashes,\n* $2 \\cdot (N + 1)$ small exponentiations.\n* $2 \\cdot N + 1$ group multiplications,\n\nNote: The exponentiations involving the $\\alpha_i$ values are **half as expensive** as those in the full proof verification.\n\nFor a discriminant of 4096 bits, we benchmarks the aggregation functions on the same machine as before. We can see that updating the accumulators in the aggregation indeed takes half time as much as verifying a single VDF proof, and verifying the aggregation is as cheap as a normal VDF proof and that proving the aggregation is more expensive than a VDF output, this is due to the absence of intermediary value found when evaluating the VDF input, but less expensive than evaluating a VDF.\n\n<center>\n\n| Size Discriminant | #iterations | $`\\texttt{VDF.Aggregation.Update}`$ (ms)| $`\\texttt{VDF.Aggregation.Prove}`$  (s)| $`\\texttt{VDF.Aggregation.Verify}`$ (ms)|\n| ----------------- | ----------- | --------------------------------------- | -------------------------------------- | --------------------------------------- |\n|            $4096$ |       1,000 |                                 8.0E+00 |                                2.3E-03 |                                 1.7E+01 |\n|            $4096$ |      10,000 |                                 8.0E+00 |                                3.0E-02 |                                 1.7E+01 |\n|            $4096$ |     100,000 |                                 8.0E+00 |                                3.0E+00 |                                 1.7E+01 |\n|            $4096$ |   1,000,000 |                                 8.0E+00 |                                3.1E+01 |                                 1.7E+01 |\n\n</center>\n\n### 6. CDDL Schema for the Ledger\n\nTo support Phalanx, **one block per interval** (every 3600 slots), across **83 intervals per epoch**, must include **2 group elements**. Each of these elements can be compressed to approximately $3/4 \\cdot \\log_2(|\\Delta|)$ bits. Based on our recommended discriminant size of **4096 bits**:\n\n* **3,104 bits (388 bytes)** per element (the benchmarked library adds 4 bytes to each element),\n* **6,208 bits (776 bytes)** per block (2 elements),\n* **515,264 bits (64,408 bytes ≈ 64.4 KB)** per epoch (83 blocks).\n\nPhalanx requires a single addition to the block body structure in the ledger: the field `phalanx_challenge`.\n\n```diff\n block =\n   [ header\n   , transaction_bodies         : [* transaction_body]\n   , transaction_witness_sets   : [* transaction_witness_set]\n   , auxiliary_data_set         : {* transaction_index => auxiliary_data }\n   , invalid_transactions       : [* transaction_index ]\n+  , ? phalanx_challenge        : vdf_attested_output\n   ]\n```\n\nThe structure `phalanx_challenge` is defined as follows:\n\n```cddl\nvdf_attested_output =\n  [ output : vdf_size\n  , proof  : vdf_size\n  ]\n\nvdf_size = [ bytes, bytes .size 388 ]\n```\n\nWe initially evaluated including the `phalanx_challenge` (i.e., the VDF attested output) in the **block header** (instead as proposed in the **block body**) colocated with the VRF outputs. However, this approach raised concerns due to **header size constraints**.\n\nThe current **maximum block header size** in Cardano is **1100 bytes**, although actual usage today averages around **860 bytes**. Since TCP packet limits suggest keeping headers under **1500 bytes** (1,460 without headers), the available headroom is approximately **600 bytes**. The full `vdf_attested_output` in its default form requires:\n\n- **388 bytes** per group element (assuming the lowest acceptable security parameters)\n- 2 group elements (output + proof)\n- Total: **776 bytes**\n\nThis would **exceed the 1500-bytes limit**, risking fragmentation and violating guidance from the Cardano networking team. We could safely decrease the group element size by decreasing the security parameters if we were to generate new class groups at each epoch. Doing so would however render the protocol more complex and potentially weaken the security of the protocol as we may have more chances to generate a weak class group.\n\n## Rationale: How does this CIP achieve its goals?\n\n### 1. How Phalanx Addresses CPS-21 - Ouroboros Randomness Manipulation?\n\n#### 1.1 Problem Overview\n\n[CPS-0021 / Ouroboros Randomness Manipulation](https://github.com/cardano-foundation/CIPs/tree/master/CPS-0021) examines the *Randomness Generation Sub-Protocol* within *Ouroboros Praos* ⚙️, highlighting its vulnerabilities and their implications for *Cardano’s* **security** 🔒. Key insights include:\n\n- **Randomness Vulnerability**: *Ouroboros Praos* employs **VRFs** for randomness generation, but this approach is susceptible to *grinding attacks*, where adversaries manipulate outcomes to influence **leader election**, threatening Cardano’s **fairness** ⚖️ and **integrity**.\n- **Attack Likelihood**: Attacks become significantly more feasible when an adversary controls **over 20% of the total stake** (approximately **4.36 billion ADA**, as of March 2025), while smaller stakes (e.g., **5%**) make such attempts highly unlikely over extended periods.\n- **Economic Barrier**: Gaining enough stake to execute an attack requires a **substantial investment** 💰—billions of USD for a **20% share**—posing a financial risk, as a successful attack could devalue the asset and undermine network trust.\n- **Computational Feasibility**: The feasibility of attacks varies widely based on the computational resources an adversary can deploy, becoming progressively more accessible as stake accumulates:\n  - Small-scale attacks, costing as little as ~**$56**, are easily achievable with minimal resources, such as a standard computer, making them a low-barrier threat that even individual actors could attempt.\n  - Large-scale attacks, costing up to ~**$3.1 billion**, require extensive computational infrastructure, such as large data centers with millions of CPUs or ASICs, placing them in a range from feasible for well-funded entities (e.g., corporations or nation-states) to nearly impractical for most adversaries due to the immense resource demands.\n  - The intensity of these attacks scales with stake: the more stake an adversary holds, the greater their influence over **leader election**, amplifying their ability to manipulate randomness. In a simplistic view, this can be likened to manipulating a $256$-bits nonce—a value $\\rho$ ranging from $0$ to $256$— where higher stake progressively grants more control, potentially allowing full manipulation of the nonce at the upper limit.\n  - The wide cost disparity reflects how the complexity of the attack—such as the scope of the targeted time window and the depth of evaluation—drastically increases resource needs, acting as a natural deterrent for more ambitious manipulations.\n\nTo illustrate the **Computational Feasibility**, the graph below (sourced from the **CPD**, Section [**3. The Cost of Grinding: Adversarial Effort and Feasibility**](./CPD/README.md#3-the-cost-of-grinding-adversarial-effort-and-feasibility)) maps attack feasibility across four scenarios—**Ant Glance**, **Ant Patrol**, **Owl Stare**, and **Owl Survey**—based on the nonce value $\\rho$ (0 to 256 bits). Each scenario reflects different attack complexities, with feasibility shifting as computational and economic demands grow:\n\n<div align=\"center\">\n<img src=\"./image/grinding_depth_scenarios_cost_with_feasibility_layers_gradient.png\" alt=\"Grinding Depth Scenarios with Feasibility Thresholds\"/>\n</div>\n\nThe table below delineates the **$\\rho$ values** at which each scenario transitions across feasibility categories, illustrating the computational and economic thresholds:\n\n<center>\n\n| **Feasibility Category**                  | **🔵 Ant Glance**   | **🟠 Ant Patrol**   | **🟢 Owl Stare**   | **🔴 Owl Survey**   |\n|--------------------------------------------|---------------------|---------------------|--------------------|--------------------|\n| **🟢 🌱 Trivial for Any Adversary**        | $0 \\to 53.6$        | $0 \\to 32.9$        | $0 \\to 31.6$       | $0 \\to 31.1$       |\n| **🟡 💰 Feasible with Standard Resources** | $53.6 \\to 60$     | $32.9 \\to 39.5$     | $31.6 \\to 38.3$    | $31.1 \\to 37.8$    |\n| **🟠 🏭 Large-Scale Infrastructure Required** | $60 \\to 69.7$  | $39.5 \\to 49.5$     | $38.2 \\to 48.2$    | $37.8 \\to 47.7$    |\n| **🔴 🚫 Borderline Infeasible**            | $69.7 \\to 79.4$     | $49.5 \\to 59.5$     | $48.2 \\to 58.2$    | $47.7 \\to 57.7$    |\n| **🔴 🚫 Infeasible**                      | $79.4 \\to 256$      | $59.5 \\to 256$      | $58.2 \\to 256$     | $57.7 \\to 256$     |\n\n</center>\n\n**Context**: The scenarios represent increasing attack sophistication (e.g., *Ant Glance* is a quick, low-effort attack; *Owl Survey* is a comprehensive, resource-intensive one). As $\\rho$ increases, so does the difficulty, shifting feasibility from trivial (e.g., a lone actor with a laptop) to infeasible (e.g., requiring nation-state-level resources).\n\nThese thresholds reveal critical vulnerabilities in Cardano’s current consensus design. **Phalanx** aims to mitigate these risks.  In the following section, we revisit the core computational model, introduce the proposed enhancements, and quantify how they shift the feasibility landscape in favor of security.\n\n#### 1.2 Phalanx Cost Amplification per Grinding Attempt\n\nIn **Phalanx**, we introduce an additional parameter and **computational cost**, denoted $T_\\Phi$, for each **grinding attempt**. This cost represents the total cumulative effort required to compute $i$ iterations of the $\\Phi$ primitive. This additional cost directly impacts the total estimated **time per grinding attempt**, as originally defined in [CPD Section 3.3.4 - Total Estimated Time per Grinding Attempt](https://github.com/cardano-foundation/CIPs/tree/master/CPS-0021/CPD/README.md#334-total-estimated-time-per-grinding-attempt). The baseline grinding time in **Praos** is:\n\n```math\nT_{\\text{grinding}}^{\\text{Praos}} = \\frac{\\rho}{2} T_{\\text{BLAKE2b}} + w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}}\n```\n\nWith **Phalanx**, the total grinding time per attempt is updated to include $T_\\Phi$:\n\n```math\nT_{\\text{grinding}}^{\\text{Phalanx}} = \\frac{\\rho}{2} T_{\\text{BLAKE2b}} + w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}} + T_\\Phi \n```\nWhere:  \n- $T_{\\mathsf{VRF}}$ is the **VRF evaluation time**,  \n- $T_{\\text{eligibility}}$ is the **eligibility check time**,  \n- $T_{\\text{BLAKE2b}}$ is the time for the **hashing operation**,  \n- $w_T$ is the **target window size** (seconds),  \n- $\\rho$ is the **grinding depth**,  \n- $T_{\\text{eval}}$ is the **nonce selection and evaluation time** (**attack-specific**).\n- $T_\\Phi$ is the additional computational cost of **Phalanx**\n\n\nThe introduction of $T_\\Phi$ substantially increases the **computational burden** for adversaries, as they must **recompute** the $\\Phi^i$ function for each of the $2^\\rho$ possible **nonces** evaluated during a grinding attack. In contrast, for **honest participants**, this computation is **distributed** across the epoch, ensuring it remains **manageable and efficient**. \n\n\n#### 1.3 Phalanx Cost Amplification per Grinding Attack\n\nBuilding on the updated **grinding time formula** introduced in the previous section, which incorporates the additional **computational cost** $T_\\Phi$, we can now revise the formula for a grinding attack from [CPD Section 3.4.1 - Formula](https://github.com/cardano-foundation/CIPs/tree/master/CPS-0021/CPS/CPD/README.md#341-formula), where we defined a total attack time that must fit within the **grinding opportunity window** $w_O$:\n\n```math\n\\frac{2^{\\rho} \\cdot T_{\\text{grinding}}^{\\text{Phalanx}}}{N_{\\text{CPU}}} \\leq w_O\n```\nwhich leads to the lower bound on computational power ($N_\\text{CPU}$) : \n\n```math\nN_{\\text{CPU}} \\geq \\left \\lceil \\frac{2^{\\rho} \\cdot T_{\\text{grinding}}^{\\text{Phalanx}}}{w_O} \\right \\rceil\n```\n\n##### 1.3.1 Formula\n\n<div style=\"font-size:0.8em; font-weight:bold; margin-top:0.5em\">\n\nExpanding $T_{\\text{grinding}}^{\\text{Phalanx}}$\n\n</div>\n\nFrom **Section 1.1**, the per-attempt grinding time under **Phalanx** is:\n\n```math\nT_{\\text{grinding}}^{\\text{Phalanx}} = \\frac{\\rho}{2} T_{\\text{BLAKE2b}} + w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}} + T_{\\Phi}\n```\n\nSubstituting this into the inequality:\n\n```math\nN_{\\text{CPU}} \\geq \\left \\lceil \\frac{2^{\\rho} \\cdot \\left( \\frac{\\rho}{2} T_{\\text{BLAKE2b}} + w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}} + T_{\\Phi} \\right)}{w_O} \\right \\rceil\n```\n\n<div style=\"font-size:0.8em; font-weight:bold; margin-top:0.5em\">\n\nExpanding $w_O$ in Terms of $\\rho$ and $f$\n\n</div>\n \n\nThe grinding opportunity window is:\n\n```math\n\\frac{X_A(w)}{f} \\leq w_O \\leq \\frac{w}{f}\n```\n\nAssuming worst-case upper bound $w_O = \\frac{w}{f}$ and noting $w < 2 \\cdot \\rho - 1$, we substitute:\n\n```math\nN_{\\text{CPU}} \\geq \\left \\lceil f \\cdot \\frac{2^{\\rho} \\cdot \\left( \\frac{\\rho}{2} T_{\\text{BLAKE2b}} + w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}} + T_{\\Phi} \\right)}{w} \\right \\rceil\n```\n\nBounding $w < 2 \\cdot \\rho - 1$:\n\n```math\nN_{\\text{CPU}} \\geq \\left \\lceil f \\cdot \\frac{2^{\\rho} \\cdot \\left( \\frac{\\rho}{2} T_{\\text{BLAKE2b}} + w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}} + T_{\\Phi} \\right)}{2 \\cdot \\rho - 1} \\right \\rceil\n```\n\nRewriting:\n\n```math\nN_{\\text{CPU}} \\geq \\left \\lceil f \\cdot 2^{\\rho} \\cdot \\left( \\frac{\\frac{\\rho}{2} T_{\\text{BLAKE2b}}}{2 \\cdot \\rho - 1} + \\frac{w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} )}{2 \\cdot \\rho - 1} + \\frac{T_{\\text{eval}}}{2 \\cdot \\rho - 1} + \\frac{T_{\\Phi}}{2 \\cdot \\rho - 1} \\right) \\right \\rceil\n```\n\nApproximating $2 \\cdot \\rho - 1 \\approx 2 \\rho$:\n\n```math\nN_{\\text{CPU}} > \\left \\lceil \\frac{f}{2 \\rho} \\cdot 2^{\\rho} \\cdot \\left( \\rho T_{\\text{BLAKE2b}} + 2 w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + 2 T_{\\text{eval}} + 2 T_{\\Phi} \\right) \\right \\rceil\n```\n\nSimplified:\n\n```math\nN_{\\text{CPU}} > \\left \\lceil f \\cdot 2^{\\rho - 2} \\cdot T_{\\text{BLAKE2b}} + \\frac{f \\cdot 2^{\\rho}}{2 \\rho} \\cdot \\left( w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}} + T_{\\Phi} \\right) \\right \\rceil\n```\n\nOr grouped as:\n\n```math\nN_{\\text{CPU}} > \\left \\lceil f \\cdot 2^{\\rho - 2} \\cdot T_{\\text{BLAKE2b}} + \\frac{f}{\\rho} \\cdot 2^{\\rho - 1} \\cdot \\left( w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}} + T_{\\Phi} \\right) \\right \\rceil\n```\n\n##### 1.3.2 Estimated Formula Using Mainnet Cardano Parameters\n\nStarting from the final expression at the end of the last section:\n\n```math\nN_{\\text{CPU}} > \\left \\lceil f \\cdot 2^{\\rho-2} \\cdot T_{\\text{BLAKE2b}} + \\frac{f}{\\rho} \\cdot 2^{\\rho-1} \\cdot \\left( w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}} + T_{\\Phi} \\right) \\right \\rceil\n```\n<div style=\"font-size:0.8em; font-weight:bold; margin-top:0.5em\">\nApplying Cardano Mainnet Parameters\n</div>\n\nUsing Cardano’s mainnet values:\n\n* $T_{\\mathsf{VRF}} = 10^{-6}$ seconds (1 microsecond) – Time to evaluate a Verifiable Random Function.\n* $T_{\\text{BLAKE2b}} = 10^{-8}$ seconds (0.01 microseconds) – Time for a BLAKE2b-256 hash operation.\n* $f = \\frac{1}{20} = 0.05$ – Active slot coefficient.\n* $k = 2160$\n* Slot duration = 1 second.\n\nSince the eligibility check is negligible, set \\$T\\_{\\text{eligibility}} \\approx 0\\$:\n\nSubstitute into the expression:\n\n* First term:\n\n  ```math\n  f \\cdot 2^{\\rho-2} \\cdot T_{\\text{BLAKE2b}} = 0.05 \\cdot 2^{\\rho-2} \\cdot 10^{-8} = 5 \\cdot 10^{-10} \\cdot 2^{\\rho-2}\n  ```\n\n* Second term:\n\n  ```math\n  \\frac{f}{\\rho} \\cdot 2^{\\rho-1} \\cdot \\left( w_T \\cdot 10^{-6} + T_{\\text{eval}} + T_{\\Phi} \\right)\n  = \\frac{0.05 \\cdot 2^{\\rho-1}}{\\rho} \\cdot \\left( 10^{-6} w_T + T_{\\text{eval}} + T_{\\Phi} \\right)\n  ```\n\nThe estimated number of CPUs required is:\n\n```math\nN_{\\text{CPU}} > \\left \\lceil\n5 \\cdot 10^{-10} \\cdot 2^{\\rho - 2} +\n\\frac{5 \\cdot 10^{-8} \\cdot 2^{\\rho - 1}}{\\rho} \\cdot w_T +\n\\frac{5 \\cdot 10^{-2} \\cdot 2^{\\rho - 1}}{\\rho} \\cdot T_{\\text{eval}} +\n\\frac{5 \\cdot 10^{-2} \\cdot 2^{\\rho - 1}}{\\rho} \\cdot T_{\\Phi}\n\\right \\rceil\n```\n\n##### 1.3.3 Impact of Tᵩ on Canonical Scenarios\n\nNow that we have an updated formula, we can evaluate how **Phalanx** directly affects the cost of grinding attempts when compared to the original CPD scenarios. As previously discussed, the goal is to strike a balance between the effort expected from honest **SPOs** during an epoch and the computational burden imposed on an adversary attempting to evaluate multiple $`\\eta_e`$ candidates in preparation for an attack.\n\nTo anchor this analysis, we introduce a baseline configuration denoted as $`\\text{Phalanx}_\\text{1/100}`$: an overhead equal to **1/100 of an epoch**, corresponding to $432{,}000 \\div 100 = 4{,}320$ slots. This represents a **modest but meaningful choice** — substantial enough to raise the adversary’s cost significantly, yet conservative enough to avoid overloading honest participants. In contrast, imposing a full-epoch overhead would likely be excessive in practice, potentially destabilizing the protocol or placing undue demands on block producers. We may refer to that upper bound as $`\\text{Phalanx}_{\\text{max}}`$, and the present section aims to explore and recommend a viable configuration somewhere between this maximum and our conservative baseline.\n\nSince each slot lasts 1 second, the $`\\text{Phalanx}_\\text{1/100}`$ overhead equates to **4,320 seconds**, or exactly **1 hour and 12 minutes**.\n\nWe now revisit the canonical scenarios from [CPD Section 3.5 – Scenarios](https://github.com/input-output-hk/ouroboros-anti-grinding-design/blob/main/CPS/Readme.md#35-scenarios), and extend each one with a **Phalanx-enhanced variant** that incorporates this fixed computational cost: $`T_{\\Phi} = 4320 \\, \\text{seconds}`$. The resulting **$N_{\\text{CPU}}$ formulas** are derived by substituting each scenario’s respective values for $`w_T`$ and $`T_{\\text{eval}}`$ into the base expression from **Section 1.2.2**, now augmented with the constant Phalanx term $`T_{\\Phi}`$.\n\n```math\nN_{\\text{CPU}} > \\left \\lceil\n5 \\cdot 10^{-10} \\cdot 2^{\\rho - 2} +\n\\frac{5 \\cdot 10^{-8} \\cdot 2^{\\rho - 1}}{\\rho} \\cdot w_T +\n\\frac{5 \\cdot 10^{-2} \\cdot 2^{\\rho - 1}}{\\rho} \\cdot T_{\\text{eval}} +\n\\frac{216 \\cdot 2^{\\rho - 1}}{\\rho}\n\\right \\rceil \\quad \\text{(Phalanx}_\\text{1/100}\\text{)}\n```\n\n```math\nN_{\\text{CPU}} > \\left \\lceil\n5 \\cdot 10^{-10} \\cdot 2^{\\rho - 2} +\n\\frac{5 \\cdot 10^{-8} \\cdot 2^{\\rho - 1}}{\\rho} \\cdot w_T +\n\\frac{5 \\cdot 10^{-2} \\cdot 2^{\\rho - 1}}{\\rho} \\cdot T_{\\text{eval}}\n\\right \\rceil \\quad \\text{(Praos)}\n```\n\nThe table below summarizes the expressions for each scenario:\n\n<center>\n\n| **Scenario**            | $\\text{Praos}$  | $\\text{Phalanx}_\\text{1/100}$       |\n|------------------------|---------------|--------------------|\n| **Ant Glance**         | $5 \\cdot 10^{-10} \\cdot 2^{\\rho-2}$           |  $5 \\cdot 10^{-10} \\cdot 2^{\\rho-2} + 216 \\cdot \\frac{2^{\\rho-1}}{\\rho}$|\n| **Ant Patrol**         | $5 \\cdot 10^{-10} \\cdot 2^{\\rho-2} + 2.16 \\cdot 10^{-2} \\cdot \\frac{2^{\\rho-1}}{\\rho}$  |$5 \\cdot 10^{-10} \\cdot 2^{\\rho-2} + 2.16 \\cdot 10^{-2} \\cdot \\frac{2^{\\rho-1}}{\\rho} + 216 \\cdot \\frac{2^{\\rho-1}}{\\rho}$|\n| **Owl Stare**          | $5 \\cdot 10^{-10} \\cdot 2^{\\rho-2} + 5 \\cdot 10^{-2} \\cdot \\frac{2^{\\rho-1}}{\\rho}$  | $5 \\cdot 10^{-10} \\cdot 2^{\\rho-2} + 5 \\cdot 10^{-2} \\cdot \\frac{2^{\\rho-1}}{\\rho} + 216 \\cdot \\frac{2^{\\rho-1}}{\\rho}$ |\n| **Owl Survey**         | $5 \\cdot 10^{-10} \\cdot 2^{\\rho-2} + 7.16 \\cdot 10^{-2} \\cdot \\frac{2^{\\rho-1}}{\\rho}$ | $5 \\cdot 10^{-10} \\cdot 2^{\\rho-2} + 7.16 \\cdot 10^{-2} \\cdot \\frac{2^{\\rho-1}}{\\rho} + 216 \\cdot \\frac{2^{\\rho-1}}{\\rho}$ |\n\n</center>\n\nThe **graph below** presents the **logarithmic cost** (in **USD**) of executing **grinding attacks** as a function of the **grinding depth** ($`\\rho`$), across both **Praos** and **$\\text{Phalanx}_{1/100}$** scenarios.\n\n* **Solid lines** correspond to the original **Praos configurations** (*Ant Glance*, *Ant Patrol*, *Owl Stare*, and *Owl Survey*).\n* **Dashed lines** represent the respective **$\\text{Phalanx}_\\text{1/100}$ variants**, each incorporating a fixed additional computational overhead of $`T_{\\Phi} = 4320 \\, \\text{seconds}`$.\n* The **shaded feasibility regions** reflect increasing **economic difficulty levels**, based on thresholds defined in [**CPD Section 3.6 – Grinding Power Computational Feasibility**](https://github.com/input-output-hk/ouroboros-anti-grinding-design/blob/main/CPS/Readme.md#36-grinding-power-computational-feasibility).\n\n\n<div align=\"center\">\n<img src=\"./image/grinding_depth_scenarios_cost_praos_vs_phalanx.png\" alt=\"Cost of Grinding Attacks: Praos vs Phalanx Scenarios\"/>\n</div>\n\n✏️ **Note**: The Python script used to generate this graph is available here ➡️ [**scenario\\_cost\\_praos\\_vs\\_phalanx.py**](./graph/scenario_cost_praos_vs_phalanx.py)\n\n<div style=\"font-size:0.8em; font-weight:bold; margin-top:0.5em\">\n Interpretation of the Graph\n</div>\n\nThe graph highlights how the **$\\text{Phalanx}_\\text{1/100}$ protocol** dramatically increases the **cost of grinding attacks** compared to **Praos**, using a logarithmic scale to represent costs in **USD** as a function of the grinding depth $`\\rho`$: \n\n1. **Consistent Cost Increase Across All $\\rho$ Values**\n  The differences (deltas) between **$\\text{Phalanx}_\\text{1/100}$** and **Praos** scenarios remain stable across all grinding depths due to the logarithmic scale. This allows us to make generalizable observations regardless of $\\rho$.\n\n2. **Moderate Gap Between Scenarios Within $\\text{Phalanx}_\\text{1/100}$**\n  Variations between different **$\\text{Phalanx}_\\text{1/100}$** scenarios (e.g., Ant Glance vs Owl Survey) are relatively modest. For example:\n    - At $`\\rho = 100`$, the cost difference between **Owl Survey ($\\text{Phalanx}_\\text{1/100}$)** and **Owl Survey (Praos)** is about **3.5** orders of magnitude in $`\\log_{10}(\\text{Cost})`$.\n\n3. **Significant Overhead Introduced by $\\text{Phalanx}_\\text{1/100}$**\n  The **computational burden** imposed by Phalanx is substantial.\n    - At $`\\rho = 150`$, the cost delta between **Owl Survey ($\\text{Phalanx}_\\text{1/100}$)** and **Ant Glance (Praos)** reaches nearly **9.8**, representing a **10⁹.⁸×** increase in expected cost for the attacker.\n    - This effectively pushes grinding attacks into the **\"infeasible\" zone** for a wide range of strategies.\n\n4. **Strategic Uniformity Under $\\text{Phalanx}_\\text{1/100}$**\n  All **$\\text{Phalanx}_\\text{1/100}$** scenario curves tightly cluster together, showing minimal divergence across evaluation complexity ($T_{\\text{eval}}$) and observation scope ($w_T$).\n    - This implies that **Phalanx equalizes grinding costs** across adversarial strategies.\n    - Practically, this means defenders (e.g., protocol designers) can reason about attack feasibility without considering specific adversarial tactics. One cost curve is sufficient.\n\nWe can now **simplify and generalize** the grinding cost formulas for different **Phalanx configurations**, along with their **estimated order-of-magnitude improvements** over Praos:\n\n<center>\n\n| **Configuration**                | **Time Budget** | **Grinding Cost Formula**                               | **Cost Amplification** |\n| ------------------------------- | --------------- | ------------------------------------------------------- | -------------------------- |\n| $`\\text{Phalanx}_{1/100}`$      | 2 hours         | $`\\frac{2.16 \\cdot 10^{2} \\cdot 2^{\\rho - 1}}{\\rho}`$ | $\\boldsymbol{10^{10.2}}$×     |\n| $`\\text{Phalanx}_{1/10}`$       | 12 hours        | $`\\frac{2.16 \\cdot 10^{3} \\cdot 2^{\\rho - 1}}{\\rho}`$ | $\\boldsymbol{10^{11.2}}$×     |\n| $`\\text{Phalanx}_{\\text{max}}`$ | 5 days          | $`\\frac{2.16 \\cdot 10^{4} \\cdot 2^{\\rho - 1}}{\\rho}`$ | $\\boldsymbol{10^{12.2}}$×     |\n\n</center>\n\n\n**N.B.** We can note that even with the use of ASICs, with a speed up of 3x to 10x, Phalanx would still add a significant term and reduce the cost amplification to still acceptable levels.\n\n<div align=\"center\">\n<img src=\"./image/grinding_depth_scenarios_cost_praos_vs_full_phalanx_scenarios.png\" alt=\"Cost of Grinding Attacks: Praos vs Phalanx Scenarios\"/>\n</div>\n\n✏️ **Note**: The Python script used to generate this graph is available here ➡️ [**scenario\\_cost\\_praos\\_vs\\_phalanx-full-scenarios.py**](./graph/scenario_cost_praos_vs_phalanx-full-scenarios.py).\n\nThese results confirm that even the **minimal configuration** ($`\\text{Phalanx}_{1/100}`$) yields a **$10^{10.6}$-fold increase** in the computational cost of a grinding attack — a formidable barrier for adversaries. More aggressive deployments such as $`\\text{Phalanx}_{1/10}`$ and $`\\text{Phalanx}_{\\text{max}}`$ push this cost further, to $10^{11.6}$ and $10^{12.6}$ times that of Praos, respectively — while still remaining practical for honest participants.\n\n\n##### 1.3.4 Impact of Tᵩ on Feasibility Categories\n\nThis **simplification** allows us to **revisit and improve** the **feasibility category table** presented in the **Problem Overview section** :\n\n<div align=\"center\">\n<img src=\"./image/grinding_depth_scenarios_cost_with_feasibility_layers_gradient-phalanx.png\" alt=\"Cost of Grinding Attacks: Praos vs Phalanx Scenarios\"/>\n</div>\n\n✏️ **Note**: The **code** to generate this **graph** is available at ➡️ [**this link**](./graph/scenario-cost-cross-thresholds.py).\n\nThe **tables below** present first the **original Praos feasibility intervals**, followed by the **adjusted categories under Phalanx** :\n\n<center>\n\n| **Feasibility Category**                      | **🔵 Ant Glance**   | **🟠 Ant Patrol**   | **🟢 Owl Stare**    | **🔴 Owl Survey**   | **$`\\text{Phalanx}_{1/100}`$** | **$`\\text{Phalanx}_{1/10}`$** | **$`\\text{Phalanx}_{max}`$** |\n| --------------------------------------------- | ------------------- | ------------------- | ------------------- | ------------------- | ----------------------- | ---------------------- | --------------------- |\n| **🟢 🌱 Trivial for Any Adversary**           | $`0 \\to 53.6`$    | $`0 \\to 32.9`$    | $`0 \\to 31.6`$    | $`0 \\to 31.1`$    | $`0 \\to 19.6`$        | $`0 \\to 16.3`$       | $`0 \\to 13.0`$      |\n| **🟡 💰 Feasible with Standard Resources**    | $`53.6 \\to 60.0`$  | $`32.9 \\to 39.5`$ | $`31.6 \\to 38.3`$ | $`31.1 \\to 37.8`$ | $`19.6 \\to 26.3`$     | $`16.3 \\to 23.0`$    | $`13.0 \\to 19.6`$   |\n| **🟠 🏭 Large-Scale Infrastructure Required** | $`60.0 \\to 69.7`$   | $`39.5 \\to 49.5`$ | $`38.3 \\to 48.2`$ | $`37.8 \\to 47.7`$ | $`26.3 \\to 36.2`$     | $`23.0 \\to 32.9`$    | $`19.6 \\to 29.6`$   |\n| **🔴 🚫 Borderline Infeasible**               | $`69.7 \\to 79.4`$ | $`49.5 \\to 59.5`$ | $`48.2 \\to 58.2`$ | $`47.7 \\to 57.7`$ | $`36.2 \\to 46.2`$     | $`32.9 \\to 42.9`$    | $`29.6 \\to 39.5`$   |\n| **🔴 🚫 Infeasible**                          | $`79.4 \\to 256`$  | $`59.5 \\to 256`$  | $`58.2 \\to 256`$  | $`57.7 \\to 256`$  | $`46.2 \\to 256`$      | $`42.9 \\to 256`$     | $`39.5 \\to 256`$    |\n\n</center>\n\nThe **Phalanx tables** include **delta improvements** for each **Praos scenario**. A **positive** $\\Delta$ implies that **Phalanx forces infeasibility earlier**, i.e., at a lower $`\\rho`$ value, thereby **increasing adversarial cost** :\n\n<center>\n\n| **Scenario**      | $`\\Delta \\text{Phalanx}_{1/100}`$ | $`\\Delta \\text{Phalanx}_{1/10}`$ | $`\\Delta \\text{Phalanx}_{max}`$ |\n| ----------------- | ------------------------- | ------------------------ | ------------------------------ |\n| **🔵 Ant Glance** | $`+34.0`$               | $`+36.5`$              | $`+39.9`$                    |\n| **🟠 Ant Patrol** | $`+13.3`$               | $`+16.6`$              | $`+20.0`$                    |\n| **🟢 Owl Stare**  | $`+12.0`$               | $`+15.3`$              | $`+18.7`$                    |\n| **🔴 Owl Survey** | $`+11.5`$               | $`+14.8`$              | $`+18.2`$                    |\n\n</center>\n\n#### 1.4 Conclusion: How Much Risk is Mitigated?\n\nTo quantify the **security improvement**, we compute the **percentage reduction in the “Trivial for Any Adversary” interval** compared to Praos. This represents the portion of grinding attacks that are now **pushed into more difficult feasibility regions**.\n\n<center>\n\n| **Scenario**      | **Praos Trivial** | $`\\Delta \\text{Phalanx}_{1/100}`$ | **% Reduction** |$`\\Delta \\text{Phalanx}_{1/10}`$ | **% Reduction** | $`\\Delta \\text{Phalanx}_{max}`$ | **% Reduction** |\n| ----------------- | ----------------- | --------------------------- | --------------- | -------------------------- | --------------- | ------------------------- | --------------- |\n| 🔵 **Ant Glance** | 53.6              | 19.6                        | **−63.4%**      | 16.3                       | **−69.6%**      | 13.0                      | **−75.7%**      |\n| 🟠 **Ant Patrol** | 32.9              | 19.6                        | **−40.4%**      | 16.3                       | **−50.5%**      | 13.0                      | **−60.5%**      |\n| 🟢 **Owl Stare**  | 31.6              | 19.6                        | **−38.0%**      | 16.3                       | **−48.4%**      | 13.0                      | **−58.9%**      |\n| 🔴 **Owl Survey** | 31.1              | 19.6                        | **−37.0%**      | 16.3                       | **−47.6%**      | 13.0                      | **−58.2%**      |\n\n</center>\n\nThese results show that **Phalanx makes low-effort grinding substantially harder**, reducing adversarial opportunity for trivial manipulation by up to **76%** in the most favorable configuration, and by **at least 37%** across all attack types and parameterizations.\n\nThis concludes our **high-level assessment of feasibility mitigation** in security terms. In the next section, **“2. How Phalanx Improves CPS-17 – Settlement Speed?”**, we will examine how this risk reduction translates into a much more **tangible and practical benefit**: **faster and more reliable settlement times in Ouroboros**.\n\n### 2. How Phalanx Improves CPS-17 - Settlement Speed?  \n\nLet us recall that, like **Bitcoin**, **Cardano** relies on **probabilistic** and **unbiased randomness** for **leader election**. As a result, both systems inherently provide **statistical consensus guarantees**. For **Stake Pool Operators (SPOs)**, being elected as a **slot leader** grants some **control** over the protocol. This control increases with **stake**—more skin in the game means more chances to be selected. However, due to the **randomized** nature of the leader election, SPOs cannot predict or influence exactly *when* they will be selected.\n\nThis makes **undesirable events**—such as **regional concentrations** of slot leadership deviating from the expected distribution, or **control over multiple consecutive blocks**—**statistically quantifiable** and, in the absence of **grinding attacks**, **extremely unlikely**. These include risks like **rollbacks**, **$k$-common prefix violations**, or **private chain attacks**. This is precisely the **security model** Ouroboros **Praos** was designed around—and so far, it has held up well.\n\nHowever, if **adversaries** manage to control more than **20% of the stake**, they gain **significant** and *exponentially growing* **grinding power**. This power allows them to **bend** the **statistical distribution** of events in their favor. For example, achieving a **grinding depth** of **79.4** means they can select from among **$2^{79.4}$ (~ $10^{24}$)** possible distributions to **optimize** the **timing** and **nature** of their attacks. At that scale, they can deliberately **amplify** the probability of \"**bad events**\" and execute a variety of **targeted attacks** against the protocol.\n\nIn this section, we narrow our focus to a specific class of such bad events: those that **bias or delay the confirmation time of transactions on Cardano**. We’ll show how this issue is **directly tied to adversarial grinding power**, and how reducing that power leads to **faster and more reliable settlement guarantees**, thereby directly addressing  [CPS-0017 / Settlement Speed](https://github.com/cardano-foundation/CIPs/tree/master/CPS-0017).\n\n#### 2.1 Settlement times without grinding attacks\n\nIn longest-chain consensus protocols like Ouroboros Praos, settlement time refers to the duration required for a transaction to be considered irreversibly included in the blockchain with high probability. Without grinding attacks, this is primarily determined by the risk of chain reorganizations (e.g., forks or common prefix violations), where an adversary might create a competing chain that overtakes the honest one. The goal is to compute the minimum number of confirmations (blocks appended after the transaction's block) needed to achieve a target security level, such as a failure probability below $2^{-30}$ or $2^{-60}$.\n\nThe methodology for computing settlement bounds, as detailed in the paper [\"Practical Settlement Bounds for Longest-Chain Consensus\" (Gaži et al., 2022)](https://eprint.iacr.org/2022/1571.pdf), uses a phase-based analytical model that divides time into intervals separated by the maximum network delay $\\Delta$ (e.g., 2-5 seconds for Cardano). It tracks metrics like \"margin\" (for PoW) or \"reach\" and \"margin\" (for PoS) to bound the probability of an adversary overtaking the honest chain. \n\nTo obtain metrics, you can run the software from [https://github.com/renling/LCanalysis/](https://github.com/renling/LCanalysis/), which implements these evaluations in MATLAB. Clone the repo, open `PoSRandomWalk.m` (for PoS like Cardano), set parameters (e.g., honest ratio $\\beta = 0.7$ (30% of stake adversary), network delay $\\Delta = 5s$), and run to output failure probabilities vs. confirmations. Below is a representative graph: \n\n![alt text](./image/settlement-times-30-2s.png)\n\n✏️ **Note**: The Python script used to generate this graph is available here ➡️ [**settlement-time-without-grinding.py**](./graph/settlement-time-without-grinding.py).\n\nA **60-bit confidence level** (failure probability ≤ **$2^{-60}$**) is a common threshold where events are considered negligible in practice. In the graph above, for example, this corresponds to a confirmation interval of **[438, 527]** blocks. Beyond this, the choice of confidence level and thus the number of confirmations required for transaction settlement, becomes **application-specific**, balancing security against efficiency.\n\n#### 2.2 How Grinding Power Affects Settlement Times\n\nWhat does it mean for settlement times when, in a scenario like the **Owl Survey Glance**, the adversary can observe a large portion of the candidate randomness distribution and perform an attack with a grinding power of $2^{57.7}$?\n\nA grinding power of $2^{57.7}$ / a grinding depth of **57.7 bits**, implies that:\n\n- The adversary can simulate approximately $2^{57.7}$ distinct randomness outcomes, derive the associated leader schedules for the next epoch, and select the most favorable one.\n- This drastically increases the likelihood of **bad events** (e.g., settlement failures) compared to a protocol with unbiased randomness.\n- More precisely, if a bad event occurs with probability $\\varepsilon$ under honest randomness, then an adversary capable of evaluating $R$ different randomness candidates can amplify this probability up to $R \\cdot \\varepsilon$ (by the union bound).\n\nIn practical terms, such grinding power **extends the number of confirmations required** to reach a desired security level. The stronger the adversary’s grinding capability, the longer it takes for a transaction to be considered truly settled.\n\n**For example**, assume that on mainnet, a rollback probability of $2^{-60}$ is achieved for a block at index $x$ after $y$ subsequent blocks are appended. If an adversary possesses grinding power of $2^{57.7}$, the effective risk increases to:\n\n```math\n2^{-60} \\cdot 2^{57.7} = 2^{-2.3}\n```\n\nTo preserve the original $2^{-60}$ confidence level *under adversarial grinding*, the protocol must instead target a baseline security of:\n\n```math\n2^{-(60 + 57.7)} = 2^{-117.7}\n```\n\nThis implies that **many more blocks must be appended** before a block is considered settled, thereby **significantly increasing settlement times**.\n\nIn the example above, we used the **Owl Survey Glance** scenario, which is the most computationally expensive in terms of grinding *cost*. However, when establishing a protocol-wide security threshold, it is more prudent to anchor on the **worst-case grinding *power*** — that is, the scenario with the **highest grinding depth**. In our analysis, this is the **Ant Glance** scenario, with a grinding depth of **79.4 bits**. To maintain the original $2^{-60}$ confidence level under such an adversary, the protocol must instead target:\n\n```math\n2^{-(60 + 79.4)} = 2^{-139.4}\n```\n\nThis defines a **stricter baseline** and ensures security even against the most favorable conditions for the adversary. In our previous scenario (30% adversary and 5-second network delay), the effect can be visualized as follows:\n\n![alt text](./image/settlement-times-30-2s-praos.png)\n\n✏️ **Note**: The Python script used to generate this graph is available here ➡️ [**settlement-time-praos.py**](./graph/settlement-time-praos.py).\n\nWhere the confirmation interval was **\\[438, 527]** blocks in the absence of a grinding attack, it increases to **\\[864, 1037]** blocks under grinding power $2^{57.7}$ in the **Owl Survey** scenario, and further to **\\[1024, 1229]** blocks under the same grinding power in the **Ant Glance** scenario.\n\nAssuming a block is produced every 20 seconds, this extends the required confirmation window from approximately **\\[2.43, 2.93] hours** to **\\[4.80, 5.76] hours** in the Owl Survey case, and up to **\\[5.69, 6.83] hours** in the Ant Glance case — more than doubling the settlement time.\n\nAs discussed in [**Section 1: How Phalanx Addresses CPS-21 – Ouroboros Randomness Manipulation**](#1-how-phalanx-addresses-cps-21--ouroboros-randomness-manipulation), this is a key challenge in Praos: the presence of multiple attack scenarios with varying grinding power makes it difficult to define a single, consistent security threshold for settlement — a complexity that **Phalanx simplifies** by unifying the treatment of adversarial power across scenarios.\n \n#### 2.3 How Phalanx improves compared to Praos ? \n\nIn the conclusion of [**Section 1.4: How Much Risk Is Mitigated?**](#14-conclusion-how-much-risk-is-mitigated), we quantified Phalanx's improvement over Praos in terms of **grinding depth reduction** as follows:\n\n<center>\n\n| **Scenario**      | $`\\Delta \\text{Phalanx}_{1/100}`$ | $`\\Delta \\text{Phalanx}_{1/10}`$ | $`\\Delta \\text{Phalanx}_{\\text{max}}`$ |\n| ----------------- | ----------------------------------- | ---------------------------------- | ---------------------------------------- |\n| **🔵 Ant Glance** | $`+34.0`$                         | $`+36.5`$                        | $`+39.9`$                              |\n\n</center>\n\nIn our previous examples, we are given that under **Praos**, the Ant Glance scenario results in a required security level of $`2^{-139.4}`$, which translate into the following threshold for the Phalanx configurations : \n\n<center>\n\n| **Configuration**        | **Computation**       | **Resulting Security Level** |\n| ------------------------ | --------------------- | ---------------------------- |\n| $`\\text{Phalanx}_{1/100}`$      | $2^{-139.4 + 34.0}$ | $2^{-105.4}$    |\n| $`\\text{Phalanx}_{1/10}`$       | $2^{-139.4 + 36.5}$ | $2^{-102.9}$    |\n| $`\\text{Phalanx}_{\\text{max}}`$ | $2^{-139.4 + 39.9}$ | $2^{-99.5}$     |\n\n</center>\n\nThis can be visualized as follows:\n\n![alt text](./image/settlement-times-30-2s-phalanx.png)\n\n✏️ **Note**: The Python script used to generate this graph is available here ➡️ [**settlement-time-phalanx.py**](./graph/settlement-time-phalanx.py).\n\nIn the absence of a grinding attack, the confirmation interval was **\\[438, 527]** blocks. Under the actual version of **Praos**, accounting for a grinding depth of 79.4 bits in the **Ant Glance** scenario, this interval increases to **\\[1024, 1229]** blocks.\n\nHowever, with Phalanx applied, the required confirmation windows are **significantly reduced**:\n\n<center>\n\n| **Configuration**                 | **Confirmation Interval** | **Duration @ 20s/block** |\n| --------------------------------- | ------------------------- | ------------------------ |\n| $`\\text{Phalanx}_{1/100}`$      | \\[773, 928]               | \\~4.29 h → \\~5.16 h      |\n| $`\\text{Phalanx}_{1/10}`$       | \\[754, 906]               | \\~4.19 h → \\~5.03 h      |\n| $`\\text{Phalanx}_{\\text{max}}`$ | \\[729, 876]               | \\~4.05 h → \\~4.87 h      |\n\n</center>\n\nCompared to Praos' ~5.69 h → ~6.83 h (from blocks 1024 to 1229), these configurations reduce settlement time by approximately 20–30% while maintaining equivalent security.\n\n#### 2.4 Advocating for Peras: Phalanx as a Complementary Layer\n\n**[Ouroboros Peras](https://peras.cardano-scaling.org/)** is a recent protocol extension designed to accelerate settlement in Cardano by introducing **stake-weighted voting and certified blocks**. Built as a lightweight augmentation of Praos, it enables rapid finality—often within **1 to 2 minutes**—by allowing randomly selected committees to vote on blocks and issue certificates that elevate their importance in the chain selection rule ([Peras Intro](https://peras.cardano-scaling.org/docs/intro/)). Critically, Peras maintains full compatibility with Praos' security guarantees, reverting gracefully when quorum is not reached ([Peras FAQ](https://peras.cardano-scaling.org/docs/faq/)). Rather than replacing Praos, it overlays an additional mechanism for **fast, probabilistically final settlement**, offering a much-needed middle ground between immediate confirmation and the traditional **2160-block** security window.\n\nWhile Peras dramatically reduces settlement times compared to both Praos and Phalanx, it does so through a **certification mechanism** that depends on the timely participation of randomly selected committees. In practice, this mechanism offers fast settlement when quorum is achieved—but when participation conditions are not met (e.g., insufficient online stake or network asynchrony), **Peras gracefully falls back to standard Praos behavior** ([Peras Technical Report](https://peras.cardano-scaling.org/docs/reports/tech-report-2/)). This fallback mode retains the full settlement guarantees we've detailed in this CIP and in the accompanying [CPS-18: Ouroboros Randomness Manipulation](https://github.com/cardano-foundation/CIPs/pull/0000) and [CIP-Phalanx](https://github.com/input-output-hk/ouroboros-anti-grinding-design). In such scenarios, settlement times revert to those defined under grinding-aware Praos parameters—precisely where Phalanx becomes relevant as a **complementary defense layer**, ensuring that even in fallback conditions, the chain benefits from **stronger security guarantees** and **significantly improved settlement times** compared to unmodified Praos.\n\nFinally, a point of critical importance that we emphasized in the [CPS-21: Ouroboros Randomness Generation Sub-Protocol – The Coin-Flipping Problem](https://github.com/cardano-foundation/CIPs/tree/master/CPS-0021): **today, the protocol remains effectively blind to grinding attacks**. Within the *window of opportunity* defined in the CPD, detecting randomness manipulation is inherently difficult—both in terms of real-time monitoring and retrospective analysis. However, [Ouroboros Peras](https://peras.cardano-scaling.org/docs/intro/) introduces a meaningful defense: by reducing settlement times to **1–2 minutes** ([Peras FAQ](https://peras.cardano-scaling.org/docs/faq/)), it can **close the grinding window entirely**, provided it does **not fall back to Praos mode** during this period. If such a fallback *does* occur within the grinding window, it becomes a suspicion that a grinding attempt may be underway. In this case, examining which SPOs abstained from voting during the certification phase could provide actionable insights to **identify adversarial behavior**. In this light, Peras is not only a mechanism for faster settlement—it also contributes to **resilience against randomness manipulation**. \n\nWe therefore **strongly recommend deploying both mechanisms in tandem**:\n\n* [**Peras**](https://peras.cardano-scaling.org/) for rapid probabilistic finality and real-time detection,\n* [**Phalanx**](./Readme.md) as a fallback that offers **quantifiable grinding resistance** even in worst-case epochs.\n\n**Note:** If Peras committee selection ultimately relies on randomness from the standard beacon in its production version, it too inherits vulnerability to grinding — especially when a **Praos epoch precedes a Peras epoch**. In such cases, **Phalanx mitigates the grinding risk at the source**, reducing the manipulation surface of the beacon and thereby **indirectly strengthening Peras**. This highlights the **complementarity** of the two systems: **each reinforces the other**.\n\n### 3. Why VDFs Were Chosen over other Cryptographic Primitives ? \n\nAs shown previously in the CPS and CPD, Cardano’s randomness generation currently is biasable and this CIP aims at presenting solutions on top of the current Praos’ randomness generation algorithm to disincentivize adversaries from performing grinding attacks by increasing their computational cost. We do not intend to change the protocol in depth, as this would need a much greater initiative that may not bear fruits, but add an additional layer of security on top of the current protocol only.\n\nTo argue about our decision, i.e. increasing the attack cost, we first list different ways to fix the last revealer attack as suggested in [1](https://eprint.iacr.org/2015/1249.pdf) that present a similar issue when combining different sources of randomness.\n- _Simultaneous lottery draws, so that all random nonces are revealed at once._ Unfortunately this solution is not possible in our context as nonces are revealed iteratively in block headers so that they can be easily extractable and verifiable from the blockchain directly.\n- _Using a slow function to generate the randomness on top of the revealed nonces, so that the adversary cannot decide in time whether to reveal their nonces or not._ In practice, time assumptions are delicate in cryptography for theoretical reasons (potential attacks, better algorithms) and practical ones (Moore’s law).\n- _Using a commitment, so that the revealed nonces are combined to some previously committed value._ This solution is not feasible as we would either need to rely on trusted parties, which is contrary to blockchain’s operandi, or to reveal the committed values, which is equivalent to RANDAO.\n- _Limiting the entropy of the last lottery draws, by combining it with sufficiently many low entropy - a single bit- randomness._ This solution is impractical as we would still have a revealer attack, but on the lone bits.\n\nAs such, we should focus from now on using a weakened slow function, that is instead of solely relying on time based guarantees, we will principally count on computational costs: we will append to our existing protocol a computationally costly chain of computation that the adversary will have to process for each grinding attempt.\n\n#### 3.1 Requirements\n\nWhen choosing a cryptographic primitive, we need to balance several criteria. In particular, checking its _security strength and maturity_, _performance_, _deployability_ and _compliance_:\n- _Security strength & Maturity_:  the primitive is resistant to known attacks and comprise a sufficient security margin. Furthermore, it has been extensively reviewed by the cryptographic community, has been developed transparently and has been accepted and standardized.\n- _Performance_: the primitive is efficient in terms of size (input, output and if applicable proof size), and computation (CPU cycles, memory footprint, and power consumption) with respect to the application and intended platform.\n- _Deployability_: the primitive should be easy to set up, upgrade and, in case of attacks and if possible, switch\n- _Compliance_: the primitive should be free of licensing restrictions and meet regulatory standards.\n\nWe furthermore require the following properties for the Phalanx project. The cryptographic primitive must be an **_NP deterministic function_**. More precisely, a primitive whose verification time is fast, that for each input corresponds to a unique output and whose latter is fixed.\n\nWe can either support a primitive which computation can be split in different iterations, each of which is verifiable, or which is finely tunable so that we can solve a challenge in less than a block time and can be used in cascade. Being able to generate and verify a single proof for the whole chain of computation would be another advantage in the context of syncing.\n\n#### 3.2 Primitive selection\n\nTo ensure fast verification, we face a first choice: relying on a cryptographic primitive based on trapdoor assumptions, which present NP problems and by definition have fast verification, or combine a primitive without fast verification with an efficient proof system such as a Succinct Non-interactive ARgument of Knowledge (SNARK).\n\n##### 3.2.1 RSA solutions\n\nAn RSA group is the multiplicative group of integers modulo $N$, where $N$ is the product of two large prime numbers $p$ and $q$, $N = p \\cdot q$. This group is called RSA after the RSA cryptosystem by Rivest, Shamir and Adleman where the public encryption key is the group modulus $N$ and a small exponent $e$, while the corresponding  decryption key is the number $d$ such that $d \\cdot e \\equiv 1\\ (\\text{mod }\\Phi(N))$ where $\\Phi(N) = (p−1)(q−1)$, where $p$ and $q$ remain private. To break the RSA cryptosystem, the adversary has to factorize $N$ into its prime $p$ and $q$ which can be done most efficiently with the General Number Field Sieve algorithm, based on the NFS [[2]](https://dl.acm.org/doi/pdf/10.1145/100216.100295), in sub-exponential time. To reach 128 bit of security, the modulus must be at least 2,048 bit long, and preferably at least 3,072 bit long, according to NIST [[3]](https://csrc.nist.gov/pubs/sp/800/78/5/final).\n\n###### 3.2.1.1 Designs\n\nThree problems defined on RSA groups satisfy the requirements: solving the RSA problem or the integer factorization, or using verifiable delayed functions (VDFs, [[6]](https://eprint.iacr.org/2018/601.pdf)).\nRSA problem. The setup consists in generating an RSA public key $(N,\\ e)$ where $N$’s factorization is unknown and a ciphertext c. The challengers then have to find the plaintext corresponding to that ciphertext, that is finding the eth root the ciphertext modulo N, i.e. finding $m$ such that $c \\equiv m \\cdot e (\\text{mod } N)$. The verification is straightforward, re-encrypting the plaintext and checking it equals the ciphertext.\nThe most efficient method to solve this problem is by first factoring the modulus $N$, which cannot be done in polynomial time without a quantum computer (in which case we would use Shor’s algorithm). The best published algorithm to solve this problem with classical computers is the general number field sieve (GNFS), that is sub-exponential in time.\nInteger factorization. This is a simpler case to the RSA problem: only the group modulus is given and needs to be factorized, by the same algorithm.\nVDF. Similarly to the other problems, we first start by generating an unknown order group of modulus $N$ but also sample a random group element $g$. The challenge then consists in raising this element to a big exponent of the form $2^T$ where $T$ is set depending on the difficulty, the computation or time we want the challenger to need to solve the problem. The challengers eventually compute and output $y = x^{2^T} (\\text{mod }N)$ by squaring the integer $x$ exactly $T$ times as well as generate an additional proof of this result. The verification consists in verifying the proof passes successfully together with the input, output and modulus.\n\n###### 3.2.1.2 Properties\n\n**Security Strength & Maturity.** RSA cryptography, since its introduction in 1977, has reached a high level of maturity and is widely considered one of the most reliable and well-understood public-key cryptographic systems. Its security is based on the computational difficulty of factoring large composite numbers, a problem that has remained challenging even with significant advances in both hardware and algorithmic techniques. Over the years, RSA has undergone extensive cryptanalysis, making it one of the most scrutinized cryptographic algorithms. Its applications have become deeply embedded in a wide range of security protocols, such as SSL/TLS for secure communications, digital signatures, and encryption. RSA is however vulnerable to quantum attacks; when large-scale quantum computers become practical, RSA’s security could be broken by quantum algorithms like Shor's algorithm, making it less future-proof compared to post-quantum cryptographic algorithms.\n\n**Performance.** One of the main drawbacks of the RSA cryptosystem relies on its inefficiency due to large modulus, making the group element large space-wise and operations computationally expensive. \n\n**Deployability.**  As solving the RSA problem or integer factorization consists in breaking the group security, groups latter cannot be continuously reused in this scenario. More particularly, after finding the factorization of the group modulus, decrypting further ciphertexts in the same group becomes trivial. As for solving a VDF puzzle, the group can be reused safely as long as the modulus is of sufficient size, at least 2,048 bit-long. We can in that scenario choose a known secure modulus, whose factorization is unknown, such as an RSA challenge to create a group. Such trusted unknown moduli are however limited in numbers and we would have to generate new ones, in a trustless manner, when updating security parameters or in case of an, potentially post-quantum, attack.\nIn our context, setting up RSA groups would be challenging to say the least, as we would need to generate groups of unknown order, that is the RSA modulus must be public while the underlying prime numbers must remain unknown. There is no known method to generate such groups, even inefficiently, which becomes especially critical if we have to do it repeatedly. Generating such a group might be achievable via multi-party computation (MPC) where the network would compute random numbers passing distributive primality tests. This would however be highly impractical.\n\n**Compliance.** RSA is compliant with a wide range of security standards and regulations. It is one of the most widely accepted public-key cryptosystems and has been incorporated into many cryptographic protocols, including SSL/TLS for secure web communication, digital signatures, and email encryption. RSA complies with industry standards such as FIPS 186-4, X.509, PKCS#1 and NIST guidelines.\nNone of the methods, GNFS or VDFs, are proprietary and there exists open source code implementing these.\n\n##### 3.2.2 ECC solutions\n\nElliptic Curve Cryptography (ECC) is a form of public-key cryptography based on the mathematical structure of elliptic curves over finite fields. More particularly, ECC relies on a safe subgroup of elliptic curves, usually defined on a prime field for security and efficiency. It provides strong security with smaller key sizes compared to traditional methods like RSA, needing 256 to 388 bit long prime only [[3]](https://csrc.nist.gov/pubs/sp/800/78/5/final),  making it ideal for constrained environments. To break ECC, one has to compute the discrete logarithm of the group (ECDLP), which can be done most efficiently with Pollard's Rho algorithm that solves the discrete logarithm in $\\mathcal{O}(n​^{1/2})$ time and $\\mathcal{O}(1)$ space. \n\n###### 3.2.2.1 Designs\n\nThe main problem satisfying our requirements is solving the discrete logarithmic on a secure subgroup of an elliptic curve. In that case, the setup consists in generating a curve and generator $G$, and sampling a random point $P$ from its secure subgroup. The challengers then have to find the scalar a such that $P = a \\cdot G$. Verification is also straightforward, as it consists in raising $G$ to the power $a$ and verifying it equals $P$.\nThe most efficient methods to find this scalar include the Index Calculus and Pollard’s $\\rho$.\n\n###### 3.2.2.2 Properties\n\n**Security Strength & Maturity.** Elliptic Curve Cryptography has reached a high level of maturity over the past few decades and is widely regarded as a modern, efficient alternative to traditional public-key cryptosystems like RSA. Its security is based on the hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP), which has been extensively analyzed, making ECC a trusted and well-understood cryptographic method. ECC is now widely adopted in industry standards, including TLS, SSH, Cardano, Bitcoin, and other blockchain technologies, where its efficiency and robustness are critical. \nECC is also vulnerable to post-quantum attacks and can be broken in polynomial time with Pollard's Rho or the Index Calculus algorithm.\n\n**Performance.** ECC is known for its great performance, particularly in terms of computational efficiency and resource utilization. Compared to traditional public-key systems like RSA, ECC achieves the same level of security with much smaller key sizes, which translates into faster computation, reduced storage requirements, and lower power consumption.\n\n**Deployability.**  To make sure that our elliptic curves are not known too long in advance, or are precomputed in sufficient numbers, to mitigate preprocessing [[12]](https://eprint.iacr.org/2017/1113.pdf)  as much as possible, we would need to generate the curves on the fly. While RSA groups only rely on the generation of sufficiently large prime numbers, ECC has an array of attacks to look out for as described in safecurves website and paper [[7]](https://eprint.iacr.org/2024/1265.pdf). As such, generating a secure elliptic curve is a complex and challenging task. Nevertheless, there have been methods to generate efficiently safe elliptic curves ([[8]](https://core.ac.uk/download/pdf/11679572.pdf), [9](https://link.springer.com/content/pdf/10.1007/s00145-009-9037-2.pdf), [[10]](https://infoscience.epfl.ch/server/api/core/bitstreams/e2890c5e-2c1e-42e0-92d6-29c6d8d33acf/content)) on the fly but these methods still necessitate minutes worth of probabilistic computation that is not easily verifiable. As finding the discrete logarithm of a number on a curve that has already been broken is significantly easier, thanks to the costly precomputation in  Pollard’s Rho algorithm that can be reused (also succinctly mentioned in [10, attacking multiple keys]), we would have to regularly change the elliptic curve which would make ensuring their number is sufficiently large an important yet difficult challenge to solve.\n\n\n**Compliance.** ECC is widely compliant with numerous industry standards and regulations, making it a trusted choice for modern cryptographic applications, including NIST guidelines, FIPS 186-4 and IETF standards for secure communication protocols.\nNone of the methods, Index Calculus or Pollard’s $\\rho$, are proprietary and there exists open source code implementing these.\n\n##### 3.2.3 Class group solutions\n\nThe class group of a number field is the group of fractional ideals modulo principal ideals, whose security is partially determined by a parameter called a discriminant. Class group of binary quadratic forms [[14]](https://github.com/Chia-Network/vdf-competition/blob/master/classgroups.pdf) omits trusted setup as the group order, also called class number, is believed to be difficult to compute when the discriminant is sufficiently large - more particularly the class number grows linearly to the square root of the discriminant. For a class group to be secure, the group size and discriminant must be sufficiently long - respectively at least 1,900 and 3,800 bit-long for 128 bit of security [[4]](https://arxiv.org/pdf/2211.16128)- negative, square free and congruent to 0 or 1 modulo 4. Similarly to ECC, to break a class group security one has to find a class group discrete logarithm (CDLP) which can be done most efficiently with index calculus algorithms that reduce CDLP to integer factorization in sub-exponential time [[5]](https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=b1e2870db7c2f1cdeb916afe072d84e581ce68b5).\n\n###### 3.2.3.1 Design\n\nSimilarly to previous solutions, class groups present two types of problems satisfying the requirements: breaking the discrete logarithm by finding the class order, or using verifiable delayed functions.\nCDLP. In that case, the setup consists in generating a discriminant and generator $G$, and sampling a random point P from its secure subgroup. The challengers then have to find the scalar a such that $P = a \\cdot G$. Verification is also straightforward, as it consists in raising $G$ to the power $a$ and verifying it equals $P$.\nThe most efficient methods to find this scalar include the Index Calculus algorithm.\nVDF. Similarly to the CLPD, we first start by generating a discriminant and sample a random group element $G$. The challenge then consists in raising this element to a big exponent of the form $2^T$ where $T$ is set depending on the difficulty, the computation or time we want the challenger to need to solve the problem. The challengers eventually compute and output $y = x^{2^T} (\\text{mod} N)$ by squaring the integer $x$ exactly $T$ times as well as generate an additional proof of this result. The verification consists in verifying the proof passes successfully together with the input, output and modulus.\n\n###### 3.2.3.2 Properties\n\n**Security Strength & Maturity.** Class group-based cryptography has reached a moderate level of maturity in cryptographic research. While not as widely deployed as more traditional cryptographic methods like RSA or ECC, class group cryptography has gained attention due to its potential resistance to quantum computing attacks. The mathematical foundations, particularly the hardness of the class group discrete logarithm problem, are well-understood, and class group cryptosystems have been rigorously analyzed. However, practical deployment is still in the early stages, with ongoing efforts focused on optimizing efficiency, key management, and standardization. \n\n**Performance.** Class group-based cryptography is generally less efficient than RSA or ECC due to the size of their elements and the computational complexity of the composition of elements.\nMore particularly, to achieve strong security, class groups’ discriminants must be several thousands bit long, and group elements half of this. Operations are thus costly, especially as composition in class groups rely on finding the greatest common denominator between such numbers that is particularly expensive.\n\n**Deployability.**  Setting up class groups, even though their order is hidden, is much easier than previously discussed solutions as it consists in practice to generate a sufficiently long negative square-free random integer d, and such that d ≡ 1 mod 4. as discriminant. Generating a random element in a class group by hashing also is however more of a delicate but still feasible task as mentioned in [[11]](https://eprint.iacr.org/2024/034.pdf). Mysten Labs recently iterated on this work and published a more efficient and secure hash function [[38]](https://eprint.iacr.org/2024/295.pdf) to class groups. Interestingly, there exist algorithms that have been designed to reuse the underlying group such as cascaded and continuous VDFs [[13]](https://par.nsf.gov/servlets/purl/10159432).\n\n**Compliance.** Since class group-based cryptography is still being researched, it is not as broadly standardized or regulated as more established cryptographic techniques like ECC. That said, once formal standards and guidelines are developed and adopted, class group-based cryptography could achieve compliance with relevant legal and regulatory frameworks. None of the VDF proof generation algorithms are proprietary and there exists open source code implementing these. \nOther groups\nWe mostly focused on commonly used groups, such as RSA and ECC, and class groups whose usage have been increasing lately, notably because of the popularity of VDF primitives. There exist however other groups such as lattices which are one of the main candidates for post quantum cryptography, supersingular isogenies, whose security is dubious at the moment since the attack on SIDH in 2022, and hyperelliptic Jacobians groups, which are still novel and need further time to get confidence in their security and for more protocols to be built upon, to cite a few.\n\n##### 3.2.4 OWF solutions\n\nTo widen our spectrum of solutions, we are now exploring solutions based on well-established non-trapdoored cryptographic functions and pair them with efficient proof systems to enable fast verification.\nHash-based approaches are generally more cost-effective than asymmetric cryptography, do not depend on potentially vulnerable trapdoors, and can be implemented using widely deployed primitives. They are well understood both cryptographically and economically, especially given the prevalence of hash farms.\nThe main drawback of hash functions lies in their verification: traditionally, verification requires recomputing the hashes, which can be too time-consuming for our use case, especially when considering synching. To address this, we propose leveraging proof systems, such as Succinct Non-interactive Arguments of Knowledge (SNARKs) and Scalable Transparent ARguments of Knowledge (STARKs) to reduce verification time. This introduces a modest overhead in the form of small proof sizes—on the order of hundreds of bytes—which remains acceptable.\nAlthough SNARKs are relatively new and involve complex protocols, their adoption is growing, with some blockchains like Mina and Midnight fully built around them. While their use may raise concerns, it remains a practical choice. It is worth noting, however, that SNARKs are not quantum-resistant—unlike their hash-based counterpart, STARKs, which do offer quantum resistance.\n\n###### 3.2.4.1 Proofs of knowledge\n\nProofs of knowledge have become an especially active and dynamic area of research in recent years. The foundations were laid in the 1990s with key contributions such as Bellare et al.'s work on Probabilistically Checkable Proofs (PCPs, [[18]](https://dl.acm.org/doi/pdf/10.1145/167088.167174)), Kilian’s results on interactive arguments of knowledge derived from PCPs [[17]], and Micali’s introduction of Computationally Sound Proofs (CS Proofs [[16]](https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Proof%20Systems/Computationally_Sound_Proofs.pdf)), which transformed interactive proofs into non-interactive ones using the Fiat-Shamir heuristic.\nIn 2016, Groth introduced one of the most efficient PCP-based proof systems to date [[15]](https://eprint.iacr.org/2016/260.pdf), offering significant improvements in both verification time and proof size. Its main drawback, however, is its reliance on a lengthy trusted setup that cannot be reused across different applications.\nSubsequent advancements built on this foundation, with SNARKs compiling from interactive oracle proofs (IOPs) and polynomial commitment schemes (PCs) such as Plonk [[19]](https://eprint.iacr.org/2019/953.pdf) and Marlin [[20]](https://eprint.iacr.org/2019/1047.pdf). Researchers introduced novel techniques to optimize proving time—either by reducing asymptotic complexity, such as replacing FFTs with multivariate polynomials, or by enhancing circuit efficiency through the use of lookup tables [[23]](https://eprint.iacr.org/2020/315.pdf), custom gates [[24]](https://docs.zkproof.org/pages/standards/accepted-workshop3/proposal-turbo_plonk.pdf), and cryptographic primitives tailored for specific applications.\nMore recently, proof aggregation has emerged as a promising paradigm. Techniques like folding and recursive proofs—exemplified by concepts such as Proof-Carrying Data (PCD, [[21]](https://eprint.iacr.org/2012/095.pdf)) and Incrementally Verifiable Computation (IVC, [[22]](https://g-city.sass.org.cn/_upload/article/files/b4/b1/dcb2f5064216b5751c14bc8366f8/e092766a-ddaa-4fa1-b052-8662bad2d2b6.pdf#page=12))—enable efficient step-by-step computation and verification.\nDespite ongoing debates about their security—particularly around the soundness of modeling a random oracle (RO) inside a SNARK—these systems are increasingly being integrated into blockchain technologies. Projects like ZCash, Mina, and Midnight blockchains leverage SNARKs for their powerful compression capabilities, and in some cases, for their privacy-preserving features as well.\n\n###### 3.2.4.2 OWFs\n\n**Non-Algebraic standard hashes.** SHA-2, SHA-3, and BLAKE2 are prominent cryptographic hash functions widely used today. SHA-2, standardized by NIST in 2001, remains the industry standard due to its strong security and broad adoption in applications like TLS and cryptocurrencies.\nKeccak [[25]](https://eprint.iacr.org/2015/389.pdf), selected through a NIST competition in 2015 as the new standard SHA-3, offers a fundamentally different sponge-based design, providing an alternative with enhanced flexibility and resilience at the cost of lower throughput.\nBLAKE2 [[26]], developed as a high-performance finalist in the same SHA-3 competition, is favored for its speed and security, often outperforming both SHA-2 and SHA-3 in practical settings. While not standardized by NIST, BLAKE2 is widely trusted and increasingly adopted in modern cryptographic implementations.\nTogether, these functions represent a balance of security, performance, and diversity in cryptographic hashing today.\n\nWhile these hash functions are very efficient on CPU, they are very expensive to verify with classic SNARKs, as the latter are working on prime fields and not bits. Proving hash evaluation is several orders of magnitude higher than evaluating on CPU making this solution very impractical. Simple benchmarks demonstrate such results, with the generation of a proof asserting the evaluation of a few hundreds of hashes taking tens of seconds, while the evaluation itself is of the order of the microsecond. For instance, according to Figure 1, the a hundred evaluations of SHA-256 would take 32μs on CPU and require 300,000 gates. To generate a proof of these evaluations, we would require a circuit of size 219 , i.e. the smallest power of 2 above 300,000, which takes 6s to 18s depending on the commitment scheme, making this solution, combining standard hash functions and SNARKs, highly impractical.\n\n<center>\n\n<img src=\"./image/hash_functions_comparison.png\" width=\"500px\" >\n\nFigure 1, taken from Reinforced Concrete paper [[27]](https://dl.acm.org/doi/pdf/10.1145/3548606.3560686). Performance of various hash functions in the zero knowledge (preimage proof) and native (hashing 512 bits of data) settings on Intel i7-4790 CPU (3.6 GHz base frequency, 4 core, 8 threads).\n</center>\n\n<center>\n\n| $\\text{log}_2(\\text{gates})$ |   #gates   | Proving time - KZG (ms) | Proving time - IPA (ms) |\n| :--------------------------: | :-------------------: | :------------------------------: |:-------------------------------: |\n| $8$                          |  256     \t           |  43\t                            |  77\t                             |\n| $9$                          |  512\t                 |  58\t                            |  105\t                           |\n| $10$                         |  1,024\t               |  75\t                            |  153\t                           |\n| $11$                         |  2,048\t               |  100                             |  210\t                           |\n| $12$                         |  4,096   \t           |  157                             |  330\t                           |\n| $13$                         |  8,192   \t           |  218                             |  500\t                           |\n| $14$                         |  16,384  \t           |  342                             |  856\t                           |\n| $15$                         |  32,768  \t           |  540                             |  1,432\t                         |\n| $16$                         |  65,536  \t           |  917\t                            |  2,590\t                         |\n| $17$                         |  131,072 \t           |  1,646\t                          |  4,779\t                         |\n| $18$                         |  262,144 \t           |  3,028\t                          |  9,199                           |\n| $19$                         |  524,288 \t           |  6,231\t                          |  18,496\t                         |\n| $20$                         |  1,048,576 \t         |  12,743\t                        |  37,287\t                         |\n\nTable 2. Halo2 benchmarks, using KZG [[28]](https://www.cypherpunks.ca/~iang/pubs/PolyCommit-AsiaCrypt.pdf) and IPA [[29]](https://eprint.iacr.org/2017/1066.pdf) commitment schemes on Intel(R) Core(TM) i9-14900HX (2.2 GHz base frequency, 24 cores, 32 threads).\n</center>\n\n\n**Memory-hard functions (MHFs).** are primitives relying on hash functions designed to resist attacks by requiring significant memory and computational effort, making them particularly interesting in our use case, where memory would become another bottleneck to an adversary attempting a grinding attack.\nArgon2, the winner of the Password Hashing Competition in 2015, is the current industry standard due to its strong security, configurability, and resistance to known attacks.\nBalloon Hashing offers a simpler design focused on provable security guarantees and ease of analysis but is less widely adopted. \nThe MHF scrypt, introduced earlier and used notably in cryptocurrencies like Litecoin, was among the first practical memory-hard functions but has seen some theoretical attacks exploiting trade-offs between memory and computation. \nOf the three, only Argon2 is formally standardized in RFC 9106 and recommended for new applications, while scrypt remains popular in legacy systems and Balloon Hashing is still primarily academic.\nUnfortunately, these primitives are much more expensive than hashes on CPU as well as on SNARKs, where the memory requirements become even more prohibitive.\n\n**SNARK-friendly hashes.** A novel branch of research started with the adoption of SNARKs to design SNARK friendly hash functions. We can classify them in two categories: algebraic or not. Algebraic hashes include, but are not limited to, Poseidon [[30]](https://www.usenix.org/system/files/sec21-grassi.pdf), Anemoi [[31]](https://hal.science/hal-04276646v1/file/2022-840%281%29.pdf), Rescue [[32]]((https://eprint.iacr.org/2020/1143.pdf)) which are based on prime fields. Choosing carefully the fields can result in optimizations of 2 to 3 orders of magnitude in SNARKs, but with higher CPU time unfortunately. For instance, a hundred evaluations of Poseidon hash would take 1.9ms, compared to 32μs for SHA-256, on CPU, but the proof generation would take 1s to 3s, compared to 6s to 18s for SHA-256.\nOther, non algebraic, hash functions have also been created such as Reinforced Concrete [[27]](https://dl.acm.org/doi/pdf/10.1145/3548606.3560686) and Monolith [[33]](https://ojs.ub.ruhr-uni-bochum.de/index.php/ToSC/article/download/11810/11315) to minimize the cost of binary operations by making the most of lookup tables, which store binary operations on vectors of bits.\nThe fact that these hash functions are less efficient on CPUs is not problematic as we are only interested in computational cost. Unfortunately, the ratio between CPU and prove generation time still remains too high for our usage. More novel techniques in SNARKs, such as IVC or folding, would be needed to make the “snarkification” of hash practical but these progresses have yet to reach maturity, be it in both theory and practice.\nAnother caveat to using SNARK-friendly hashes would be that adversaries could afford specialised hardware such as CPUs with special instructions such as AVX2, or GPUs, FPGAs or ASICs to accelerate prime field operations and widen the gap between honest users and adversaries.\n\n###### 3.2.4.3 Design\nUsing OWFs and SNARKs in the context of Phalanx is straightforward. To each iteration is associated a input that we have to recursively hash a number of times set by the total duration and number of iterations with the desired primitive. Once the result is computed, a SNARK proof can be generated proving the correctness of the computation. We can remark that IVC based solutions are particularly adapted as a choice for SNARK primitves as we can prove a batch of iterations per step of IVC. Both the hash output and the SNARK are then published.\n\n###### 3.2.4.4 Properties\n\n**Security Strength & Maturity.** While traditional hashes have strong security, more novel ones, especially the more usable with SNARKs, can be deemed too novel for adoption. SNARKs, and SNARKs friendly primitives, are very complex pieces of technology that have been broken before and are still evolving at a rapid pace. SNARKs are not postquantum resistant but STARKs are.\n\n**Performance.** While hash functions are extremely efficient on commodity hardware, the proof generation with current SNARKs is far too slow for this solution to be practical\n\n**Deployability.**  SNARKs are difficult to deploy, they rely on different libraries that are not easy to update. Changing of SNARKs is also tedious as circuits would very likely need to be rewritten, adding further risk and complexity.\n\n**Compliance.** Hash functions are standardized and libraries are easily available. SNARK solutions are not copyrighted, there is however a limited number of available libraries, which can either be open source or proprietary (SP1, RISC0, STARKNET…).\n\n#### 3.3 Primitive recommendation\n\nThe combination of OWFs and SNARKs, however elegant it may be for its modularity, is not practical for the proof generation overhead being prohibitive. \nTrapdoor based solutions seem to be the best candidates for anti-grinding solutions. Out of the ones considered, VDFs seem the most practical primitive thanks to the possibility of reusing the group, and class groups offer the simplest deployment. The main caveat of such a solution is in its relative novelty, regular assessment would need to be done to ensure correct and up to date parametrization.\n\n## Path to Active\n\n### Acceptance Criteria\n\nThe proposal will be considered **Active** once the following criteria are met:\n\n- [ ] The revised `cardano-node` implementation passes all **node-level conformance test suites**.\n- [ ] A formal **security audit** is completed and its findings reviewed.\n- [ ] The solution demonstrates **stable and expected behavior in testnet environments**.\n- [ ] The **hard fork is successfully executed** and the protocol transition is secure.\n- [ ] The **community agrees on the initial Phalanx protocol parameters** and on a clear policy for their future updates.\n- [ ] The upcoming CIP introducing a **Consensus** category may define further acceptance criteria, which will be incorporated accordingly.\n\n### Implementation Plan\n\nTo fulfill the above criteria, the following steps are planned:\n\n- [ ] Triage and scope confirmation by Intersect’s **Core Infrastructure** and **Consensus** teams.\n- [ ] Coordination with ongoing workstreams on consensus protocol enhancements:\n\n  - [ ] Compatibility with **Peras**\n  - [ ] Compatibility with **Leios**\n  - [ ] Compatibility with **Ouroboros Genesis**\n- [ ] Development and publication of a **community communication plan** covering:\n\n  * The initial values of Phalanx parameters\n  * The procedure for evaluating and updating these parameters\n- [ ] Integration of a **Wesolowski-style VDF library** into [`cardano-crypto-class`](https://github.com/IntersectMBO/cardano-base/blob/master/cardano-crypto-class/cardano-crypto-class.cabal)\n- [ ] Implementation of the **node-level logic**, including support for the hard fork mechanism\n- [ ] Construction and execution of a comprehensive **node-level conformance test suite**\n\n## References\n\n1. [Ouroboros Randomness Generation Sub-Protocol – The Coin-Flipping Problem](https://github.com/cardano-foundation/CIPs/tree/master/CPS-0021/CPD/README.md)\n2. [Cardano Disaster Recovery Plan](https://iohk.io/en/research/library/papers/cardano-disaster-recovery-plan)\n3. [Baigneres, Thomas, et al. \"Trap Me If You Can--Million Dollar Curve.\" Cryptology ePrint Archive (2015).](https://eprint.iacr.org/2015/1249.pdf)\n4. [Lenstra, Arjen K., et al. \"The number field sieve.\" Proceedings of the twenty-second annual ACM symposium on Theory of computing. 1990.](https://dl.acm.org/doi/pdf/10.1145/100216.100295)\n5. [National Institute of Standards and Technology (NIST). (April 2010). Special Publication  800-78-5: Cryptographic Algorithms and Key Sizes for Personal Identity Verification.](https://csrc.nist.gov/pubs/sp/800/78/5/final)\n6. [Dobson, Samuel, Steven Galbraith, and Benjamin Smith. \"Trustless unknown-order groups.\" arXiv preprint arXiv:2211.16128 (2022).](https://arxiv.org/pdf/2211.16128)\n7. [Hamdy, Safuat, and Bodo Möller. \"Security of cryptosystems based on class groups of imaginary quadratic orders.\" Advances in Cryptology—ASIACRYPT 2000: 6th International Conference on the Theory and Application of Cryptology and Information Security Kyoto, Japan, December 3–7, 2000 Proceedings 6. Springer Berlin Heidelberg, 2000.](https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=b1e2870db7c2f1cdeb916afe072d84e581ce68b5)\n8. [Boneh, Dan, et al. \"Verifiable delay functions.\" Annual international cryptology conference. Cham: Springer International Publishing, 2018.](https://eprint.iacr.org/2018/601.pdf)\n9. [Bernstein, Daniel J., and Tanja Lange. \"Safe curves for elliptic-curve cryptography.\" Cryptology ePrint Archive (2024).](https://eprint.iacr.org/2024/1265.pdf)\n10. [Baier, Harald. Efficient algorithms for generating elliptic curves over finite fields suitable for use in cryptography. Diss. Technische Universität, 2002.](https://core.ac.uk/download/pdf/11679572.pdf)\n11. [Konstantinou, Elisavet, et al. \"On the efficient generation of prime-order elliptic curves.\" Journal of cryptology 23.3 (2010): 477-503.](https://link.springer.com/content/pdf/10.1007/s00145-009-9037-2.pdf)\n12. [Miele, Andrea, and Arjen K. Lenstra. \"Efficient ephemeral elliptic curve cryptographic keys.\" Information Security: 18th International Conference, ISC 2015, Trondheim, Norway, September 9-11, 2015, Proceedings 18. Springer International Publishing, 2015.](https://infoscience.epfl.ch/server/api/core/bitstreams/e2890c5e-2c1e-42e0-92d6-29c6d8d33acf/content)\n13. [Seres, István András, Péter Burcsi, and Péter Kutas. \"How (not) to hash into class groups of imaginary quadratic fields?.\" Cryptographers’ Track at the RSA Conference. Cham: Springer Nature Switzerland, 2025.](https://eprint.iacr.org/2024/034.pdf)\n14. [Corrigan-Gibbs, Henry, and Dmitry Kogan. \"The discrete-logarithm problem with preprocessing.\" Advances in Cryptology–EUROCRYPT 2018: 37th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Tel Aviv, Israel, April 29-May 3, 2018 Proceedings, Part II 37. Springer International Publishing, 2018.](https://eprint.iacr.org/2017/1113.pdf)\n15. [Ephraim, Naomi, et al. \"Continuous verifiable delay functions.\" Annual International Conference on the Theory and Applications of Cryptographic Techniques. Cham: Springer International Publishing, 2020.](https://par.nsf.gov/servlets/purl/10159432)\n16. [Long, Lipa. \"Binary quadratic forms.\", (2018)](https://github.com/Chia-Network/vdf-competition/blob/master/classgroups.pdf)\n17. [Groth, Jens. \"On the size of pairing-based non-interactive arguments.\" Advances in Cryptology–EUROCRYPT 2016: 35th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Vienna, Austria, May 8-12, 2016, Proceedings, Part II 35. Springer Berlin Heidelberg, 2016.](https://eprint.iacr.org/2016/260.pdf)\n18. [Micali, Silvio. \"CS proofs.\" Proceedings 35th Annual Symposium on Foundations of Computer Science. IEEE, 1994](https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Proof%20Systems/Computationally_Sound_Proofs.pdf)\n19. [Kilian, Joe. \"A note on efficient zero-knowledge proofs and arguments.\" Proceedings of the twenty-fourth annual ACM symposium on Theory of computing. 1992.](https://dl.acm.org/doi/pdf/10.1145/129712.129782)\n20. [Bellare, Mihir, et al. \"Efficient probabilistically checkable proofs and applications to approximations.\" Proceedings of the twenty-fifth annual ACM symposium on Theory of computing. 1993.](https://dl.acm.org/doi/pdf/10.1145/167088.167174)\n21. [Gabizon, Ariel, Zachary J. Williamson, and Oana Ciobotaru. \"Plonk: Permutations over lagrange-bases for oecumenical noninteractive arguments of knowledge.\" Cryptology ePrint Archive (2019).](https://eprint.iacr.org/2019/953.pdf)\n22. [Chiesa, Alessandro, et al. \"Marlin: Preprocessing zkSNARKs with universal and updatable SRS.\" Advances in Cryptology–EUROCRYPT 2020: 39th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Zagreb, Croatia, May 10–14, 2020, Proceedings, Part I 39. Springer International Publishing, 2020.](https://eprint.iacr.org/2019/1047.pdf)\n23. [Bitansky, Nir, et al. \"Recursive composition and bootstrapping for SNARKS and proof-carrying data.\" Proceedings of the forty-fifth annual ACM symposium on Theory of computing. 2013.](https://eprint.iacr.org/2012/095.pdf)\n24. [Valiant, Paul. \"Incrementally verifiable computation or proofs of knowledge imply time/space efficiency.\" Theory of Cryptography: Fifth Theory of Cryptography Conference, TCC 2008, New York, USA, March 19-21, 2008. Proceedings 5. Springer Berlin Heidelberg, 2008.](https://g-city.sass.org.cn/_upload/article/files/b4/b1/dcb2f5064216b5751c14bc8366f8/e092766a-ddaa-4fa1-b052-8662bad2d2b6.pdf#page=12)\n25. [Gabizon, Ariel, and Zachary J. Williamson. \"plookup: A simplified polynomial protocol for lookup tables.\" Cryptology ePrint Archive (2020).](https://eprint.iacr.org/2020/315.pdf)\n26. [Gabizon, Ariel, and Zachary J. Williamson. \"Proposal: The turbo-plonk program syntax for specifying snark programs.\", 2020](https://docs.zkproof.org/pages/standards/accepted-workshop3/proposal-turbo_plonk.pdf)\n27. [Bertoni, Guido, et al. \"Keccak.\" Annual international conference on the theory and applications of cryptographic techniques. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013.](https://eprint.iacr.org/2015/389.pdf)\n28. [Aumasson, Jean-Philippe, et al. \"BLAKE2: simpler, smaller, fast as MD5.\" International Conference on Applied Cryptography and Network Security. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013.](https://eprint.iacr.org/2013/322.pdf)\n29. [Grassi, Lorenzo, et al. \"Reinforced concrete: A fast hash function for verifiable computation.\" Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security. 2022.](https://dl.acm.org/doi/pdf/10.1145/3548606.3560686)\n30. [Kate, Aniket, Gregory M. Zaverucha, and Ian Goldberg. \"Constant-size commitments to polynomials and their applications.\" International conference on the theory and application of cryptology and information security. Berlin, Heidelberg: Springer Berlin Heidelberg, 2010.](https://www.cypherpunks.ca/~iang/pubs/PolyCommit-AsiaCrypt.pdf)\n31. [Bünz, Benedikt, et al. \"Bulletproofs: Short proofs for confidential transactions and more.\" 2018 IEEE symposium on security and privacy (SP). IEEE, 2018.](https://eprint.iacr.org/2017/1066.pdf)\n32. [Grassi, Lorenzo, et al. \"Poseidon: A new hash function for {Zero-Knowledge} proof systems.\" 30th USENIX Security Symposium (USENIX Security 21). 2021.](https://www.usenix.org/system/files/sec21-grassi.pdf)\n33. [Bouvier, Clémence, et al. \"New design techniques for efficient arithmetization-oriented hash functions: Anemoi permutations and Jive compression mode.\" Annual International Cryptology Conference. Cham: Springer Nature Switzerland, 2023.](https://hal.science/hal-04276646v1/file/2022-840%281%29.pdf)\n34. [Szepieniec, Alan, Tomer Ashur, and Siemen Dhooghe. \"Rescue-prime: a standard specification (SoK).\" Cryptology ePrint Archive (2020).](https://eprint.iacr.org/2020/1143.pdf)\n35. [Grassi, Lorenzo, et al. \"Monolith: Circuit-friendly hash functions with new nonlinear layers for fast and constant-time implementations.\" IACR Transactions on Symmetric Cryptology 2024.3 (2024): 44-83.](https://ojs.ub.ruhr-uni-bochum.de/index.php/ToSC/article/download/11810/11315)\n36. [Wesolowski, Benjamin. \"Efficient verifiable delay functions.\" Advances in Cryptology–EUROCRYPT 2019: 38th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Darmstadt, Germany, May 19–23, 2019, Proceedings, Part III 38. Springer International Publishing, 2019.](https://eprint.iacr.org/2018/623.pdf)\n37. [Pietrzak, Krzysztof. \"Simple verifiable delay functions.\" 10th innovations in theoretical computer science conference (itcs 2019). Schloss Dagstuhl–Leibniz-Zentrum für Informatik, 2019.](https://drops.dagstuhl.de/storage/00lipics/lipics-vol124-itcs2019/LIPIcs.ITCS.2019.60/LIPIcs.ITCS.2019.60.pdf)\n38. [Chalkias, Kostas Kryptos, Jonas Lindstrøm, and Arnab Roy. \"An efficient hash function for imaginary class groups.\" Cryptology ePrint Archive (2024).](https://eprint.iacr.org/2024/295.pdf)\n\n\n## Copyright\nThis CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0).\n\nPortions of this document were prepared with the assistance of AI-based tools.The use of AI was limited to drafting, editing, and improving clarity of expression. All **technical ideas, specifications, and cryptographic designs** originate from the human authors, who take full responsibility for their novelty, correctness, and originality.  \n\nThe AI contribution is comparable to that of a copy-editor: it helped improve formatting, emphasis, and readability, but did not generate or propose the underlying concepts.\n"
  },
  {
    "path": "CIP-0161/graph/NhandNa.py",
    "content": "import matplotlib.pyplot as plt\n\n# Adjusted data to ensure matching lengths\ns_a_values = [0.005, 0.01, 0.02, 0.05, 0.1, 0.2, 0.25, 0.3, 0.33, 0.4, 0.45, 0.49, 0.5]\nN_a_values = [269, 434, 730, 1537, 2794, 5204, 6384, 7554, 8252, 9872, 11024, 11942, 12171]\nN_h_values = [19645, 19541, 18713, 17680, 15618, 14590, 13563, 12949, 11517, 10498, 9685, 9482, 9482]\n\n# Plot\nplt.figure(figsize=(14, 6))\n\n# Left plot: Max #Adversarial blocks\nplt.subplot(1, 2, 1)\nplt.plot([x * 100 for x in s_a_values], N_a_values, marker='o', label=\"N_a\")\nplt.title(\"Nₐ s.t. Pr(Xₐ < Nₐ) = 1 - 2⁻¹²⁸\")\nplt.xlabel(\"Adversarial stake sₐ (%)\")\nplt.ylabel(\"Max #Adversarial blocks\")\nplt.grid(True)\nplt.legend()\n\n# Right plot: Min #Honest blocks\nplt.subplot(1, 2, 2)\nplt.plot([x * 100 for x in s_a_values], N_h_values, marker='o', color='orange', label=\"N_h\")\nplt.title(\"Nₕ s.t. Pr(Xₕ > Nₕ) = 2⁻¹²⁸\")\nplt.xlabel(\"Adversarial stake sₐ (%)\")\nplt.ylabel(\"Min #Honest blocks\")\nplt.grid(True)\nplt.legend()\n\nplt.tight_layout()\nplt.show()\n"
  },
  {
    "path": "CIP-0161/graph/extended_error_series_corrected.csv",
    "content": "Number of Blocks,ErrorUB,ErrorLB\n1.000000000000000000e+00,8.676736300353218301e-01,8.121889413522432877e-01\n2.000000000000000000e+00,7.665170928550861795e-01,6.876416416654815844e-01\n3.000000000000000000e+00,6.892413553587528607e-01,5.976483327753178143e-01\n4.000000000000000000e+00,6.233636971643735647e-01,5.254324374189145441e-01\n5.000000000000000000e+00,5.657163917284088184e-01,4.645063982661716273e-01\n6.000000000000000000e+00,5.148322413203135772e-01,4.123629938648500914e-01\n7.000000000000000000e+00,4.695420424714478180e-01,3.673985960267712181e-01\n8.000000000000000000e+00,4.289723410221071287e-01,3.283163309200732849e-01\n9.000000000000000000e+00,3.924626607691574232e-01,2.940989122957397006e-01\n1.000000000000000000e+01,3.594890215620014651e-01,2.639674748869408893e-01\n1.100000000000000000e+01,3.296227802996201661e-01,2.373151334994483552e-01\n1.200000000000000000e+01,3.025063659506418978e-01,2.136553563004263412e-01\n1.300000000000000000e+01,2.778369824982573344e-01,1.925895067761664026e-01\n1.400000000000000000e+01,2.553551459127302303e-01,1.737860346140847612e-01\n1.500000000000000000e+01,2.348363566176548400e-01,1.569659662586282423e-01\n1.600000000000000000e+01,2.160848560472271862e-01,1.418922602581049741e-01\n1.700000000000000000e+01,1.989288240817739251e-01,1.283618303959235818e-01\n1.800000000000000000e+01,1.832166088685094618e-01,1.161994704764356123e-01\n1.900000000000000000e+01,1.688137167962222018e-01,1.052531422355927476e-01\n2.000000000000000000e+01,1.556003746767336549e-01,9.539025430277556228e-02\n2.100000000000000000e+01,1.434695307720732504e-01,8.649467767079334346e-02\n2.200000000000000000e+01,1.323251978238009219e-01,7.846432047056445258e-02\n2.300000000000000000e+01,1.220810663595783691e-01,7.120913531665457041e-02\n2.400000000000000000e+01,1.126593342503926370e-01,6.464946639023633201e-02\n2.500000000000000000e+01,1.039897112177895072e-01,5.871466691555114747e-02\n2.600000000000000000e+01,9.600856630132027780e-02,5.334193434216964735e-02\n2.700000000000000000e+01,8.865819321256680763e-02,4.847532258446164699e-02\n2.800000000000000000e+01,8.188617370925678485e-02,4.406489953310156749e-02\n2.900000000000000000e+01,7.564482309177875119e-02,4.006602469376974868e-02\n3.000000000000000000e+01,6.989070498353891492e-02,3.643872686089284080e-02\n3.100000000000000000e+01,6.458420493919947436e-02,3.314716563020274342e-02\n3.200000000000000000e+01,5.968915429847634901e-02,3.015916359178368727e-02\n3.300000000000000000e+01,5.517249718980014178e-02,2.744579843693805907e-02\n3.400000000000000000e+01,5.100399477754492816e-02,2.498104611090950361e-02\n3.500000000000000000e+01,4.715596180550797600e-02,2.274146766216476184e-02\n3.600000000000000000e+01,4.360303126816341551e-02,2.070593366195472296e-02\n3.700000000000000000e+01,4.032194367801183316e-02,1.885538105912534790e-02\n3.800000000000000000e+01,3.729135792136072797e-02,1.717259814345728497e-02\n3.900000000000000000e+01,3.449168112865765023e-02,1.564203395380971487e-02\n4.000000000000000000e+01,3.190491534661680367e-02,1.424962901422541575e-02\n4.100000000000000000e+01,2.951451910164990325e-02,1.298266473472342065e-02\n4.200000000000000000e+01,2.730528219838205053e-02,1.182962919165776554e-02\n4.300000000000000000e+01,2.526321231197630260e-02,1.078009731938689951e-02\n4.400000000000000000e+01,2.337543211552886233e-02,9.824623811787223590e-03\n4.500000000000000000e+01,2.163008583947576002e-02,8.954647257799135812e-03\n4.600000000000000000e+01,2.001625429329978098e-02,8.162404226884963782e-03\n4.700000000000000000e+01,1.852387749448332691e-02,7.440852183785027531e-03\n4.800000000000000000e+01,1.714368414861848836e-02,6.783600251963899271e-03\n4.900000000000000000e+01,1.586712731031091408e-02,6.184846965458830857e-03\n5.000000000000000000e+01,1.468632562903479828e-02,5.639324252597921992e-03\n5.100000000000000000e+01,1.359400964907008479e-02,5.142246984816187423e-03\n5.200000000000000000e+01,1.258347268950024862e-02,4.689267501685235456e-03\n5.300000000000000000e+01,1.164852588011740242e-02,4.276434591051158501e-03\n5.400000000000000000e+01,1.078345697295671375e-02,3.900156462313562108e-03\n5.500000000000000000e+01,9.982992587887581926e-03,3.557167302609378062e-03\n5.600000000000000000e+01,9.242263584923427963e-03,3.244497051022335928e-03\n5.700000000000000000e+01,8.556773286253361449e-03,2.959444065796819259e-03\n5.800000000000000000e+01,7.922368297970843257e-03,2.699550394634019686e-03\n5.900000000000000000e+01,7.335211705481949236e-03,2.462579389117368431e-03\n6.000000000000000000e+01,6.791758438006847108e-03,2.246495431690643998e-03\n6.100000000000000000e+01,6.288732616743952786e-03,2.049445567855091507e-03\n6.200000000000000000e+01,5.823106718427300058e-03,1.869742857755303175e-03\n6.300000000000000000e+01,5.392082401407284446e-03,1.705851280427196854e-03\n6.400000000000000000e+01,4.993072855222790464e-03,1.556372040977922321e-03\n6.500000000000000000e+01,4.623686547095530452e-03,1.420031146110290734e-03\n6.600000000000000000e+01,4.281712250008304008e-03,1.295668126913478895e-03\n6.700000000000000000e+01,3.965105247171994696e-03,1.182225799908241063e-03\n6.800000000000000000e+01,3.671974616856372997e-03,1.078740968125501114e-03\n6.900000000000000000e+01,3.400571509858655965e-03,9.843359736577388802e-04\n7.000000000000000000e+01,3.149278339407649268e-03,8.982110217798201313e-04\n7.100000000000000000e+01,2.916598810127231638e-03,8.196372045025134608e-04\n7.200000000000000000e+01,2.701148718882467881e-03,7.479501583952578945e-04\n7.300000000000000000e+01,2.501647465970289769e-03,6.825442977817404444e-04\n7.400000000000000000e+01,2.316910220247161804e-03,6.228675700485773910e-04\n7.500000000000000000e+01,2.145840686461239401e-03,5.684166848811588119e-04\n7.600000000000000000e+01,1.987424427318343258e-03,5.187327738111813030e-04\n7.700000000000000000e+01,1.840722696700652179e-03,4.733974405802858173e-04\n7.800000000000000000e+01,1.704866744008957284e-03,4.320291665403725909e-04\n7.900000000000000000e+01,1.579052552845563659e-03,3.942800386652275946e-04\n8.000000000000000000e+01,1.462535980224324936e-03,3.598327707770982136e-04\n8.100000000000000000e+01,1.354628265210592502e-03,3.283979913287650822e-04\n8.200000000000000000e+01,1.254691878382670689e-03,2.997117735559348337e-04\n8.300000000000000000e+01,1.162136685786225795e-03,2.735333860527170411e-04\n8.400000000000000000e+01,1.076416403142931542e-03,2.496432438480028471e-04\n8.500000000000000000e+01,9.970253179921986699e-04,2.278410418938206635e-04\n8.600000000000000000e+01,9.234952592045346607e-04,2.079440545370082373e-04\n8.700000000000000000e+01,8.553927949202646619e-04,1.897855860497340099e-04\n8.800000000000000000e+01,7.923166414519593062e-04,1.732135586576801444e-04\n8.900000000000000000e+01,7.338952670522855921e-04,1.580892257406690067e-04\n9.000000000000000000e+01,6.797846757031186836e-04,1.442859990014865067e-04\n9.100000000000000000e+01,6.296663572346320381e-04,1.316883794155515521e-04\n9.200000000000000000e+01,5.832453911440827572e-04,1.201909826969317760e-04\n9.300000000000000000e+01,5.402486924603260672e-04,1.096976508538574256e-04\n9.400000000000000000e+01,5.004233888988434157e-04,1.001206421674617406e-04\n9.500000000000000000e+01,4.635353193798350240e-04,9.137989261820873854e-05\n9.600000000000000000e+01,4.293676447443481314e-04,8.340234241195210315e-05\n9.700000000000000000e+01,3.977195622058752158e-04,7.612132182768347897e-05\n9.800000000000000000e+01,3.684051157223930742e-04,6.947599112718068814e-05\n9.900000000000000000e+01,3.412520950705765247e-04,6.341082973775745586e-05\n1.000000000000000000e+02,3.161010169542193340e-04,5.787517034753198282e-05\n1.010000000000000000e+02,2.783656615421519322e-04,4.908285669368370733e-05\n1.020000000000000000e+02,2.573721555494425908e-04,4.468043086773172408e-05\n1.030000000000000000e+02,2.379619170166068492e-04,4.067287515445399792e-05\n1.040000000000000000e+02,2.200155406451512609e-04,3.702477216987910683e-05\n1.050000000000000000e+02,2.034226263272198565e-04,3.370388124827063115e-05\n1.060000000000000000e+02,1.880811000010410212e-04,3.068085351033337073e-05\n1.070000000000000000e+02,1.738965857254203039e-04,2.792897248802272495e-05\n1.080000000000000000e+02,1.607818251105035535e-04,2.542391801368935842e-05\n1.090000000000000000e+02,1.486561405333308977e-04,2.314355128689377848e-05\n1.100000000000000000e+02,1.374449388360737367e-04,2.106771921938543329e-05\n1.110000000000000000e+02,1.270792524538624964e-04,1.917807632911610813e-05\n1.120000000000000000e+02,1.174953151493856045e-04,1.745792260924828942e-05\n1.130000000000000000e+02,1.086341697443143250e-04,1.589205593930126273e-05\n1.140000000000000000e+02,1.004413054344506495e-04,1.446663773409608698e-05\n1.150000000000000000e+02,9.286632245748470632e-05,1.316907064315144119e-05\n1.160000000000000000e+02,8.586262205050443472e-05,1.198788721968015172e-05\n1.170000000000000000e+02,7.938711978998575555e-05,1.091264857528168679e-05\n1.180000000000000000e+02,7.339998055082120969e-05,9.933852124676141780e-06\n1.190000000000000000e+02,6.786437345394852403e-05,9.042847605159452947e-06\n1.200000000000000000e+02,6.274624529509438867e-05,8.231760628589381210e-06\n1.210000000000000000e+02,5.801411106084693111e-05,7.493423090281016541e-06\n1.220000000000000000e+02,5.363886024337790519e-05,6.821309819789910275e-06\n1.230000000000000000e+02,4.959357776233121385e-05,6.209480913724476720e-06\n1.240000000000000000e+02,4.585337839224565396e-05,5.652529240945109901e-06\n1.250000000000000000e+02,4.239525367696786955e-05,5.145532656219269717e-06\n1.260000000000000000e+02,3.919793038932129441e-05,4.684010500013269552e-06\n1.270000000000000000e+02,3.624173966532496843e-05,4.263883999981286858e-06\n1.280000000000000000e+02,3.350849600791715107e-05,3.881440224193544513e-06\n1.290000000000000000e+02,3.098138541585739183e-05,3.533299267534893367e-06\n1.300000000000000000e+02,2.864486194961174487e-05,3.216384381278597411e-06\n1.310000000000000000e+02,2.648455209792965916e-05,2.927894781850867439e-06\n1.320000000000000000e+02,2.448716635680832468e-05,2.665280898479465623e-06\n1.330000000000000000e+02,2.264041747690638410e-05,2.426221840973697176e-06\n1.340000000000000000e+02,2.093294487649407907e-05,2.208604888503897214e-06\n1.350000000000000000e+02,1.935424475495199775e-05,2.010506818109298187e-06\n1.360000000000000000e+02,1.789460547690147060e-05,1.830176907922226018e-06\n1.370000000000000000e+02,1.654504782947009879e-05,1.666021464896950666e-06\n1.380000000000000000e+02,1.529726978517621677e-05,1.516589740304674641e-06\n1.390000000000000000e+02,1.414359543063101258e-05,1.380561108520691817e-06\n1.400000000000000000e+02,1.307692774688567603e-05,1.256733395794292108e-06\n1.410000000000000000e+02,1.209070495094321574e-05,1.144012255855159235e-06\n1.420000000000000000e+02,1.117886012986327091e-05,1.041401498461520118e-06\n1.430000000000000000e+02,1.033578391914175012e-05,9.479942854171725012e-07\n1.440000000000000000e+02,9.556289995775807335e-06,8.629651162508121954e-07\n1.450000000000000000e+02,8.835583173738382760e-06,7.855625327298915475e-07\n1.460000000000000000e+02,8.169229905596965126e-06,7.151024777340425933e-07\n1.470000000000000000e+02,7.553131008811888262e-06,6.509622497960926564e-07\n1.480000000000000000e+02,6.983496448935681680e-06,5.925749998830102419e-07\n1.490000000000000000e+02,6.456822024588288959e-06,5.394247217812424903e-07\n1.500000000000000000e+02,5.969867810781543878e-06,4.910416918132189434e-07\n1.510000000000000000e+02,5.519638227983862993e-06,4.469983175828053094e-07\n1.520000000000000000e+02,5.103363614316324944e-06,4.069053590623843819e-07\n1.530000000000000000e+02,4.718483187518783867e-06,3.704084886248282669e-07\n1.540000000000000000e+02,4.362629291873415494e-06,3.371851596191301359e-07\n1.550000000000000000e+02,4.033612833178332707e-06,3.069417558152511936e-07\n1.560000000000000000e+02,3.729409812171819198e-06,2.794109965259691305e-07\n1.570000000000000000e+02,3.448148873565562427e-06,2.543495744730998643e-07\n1.580000000000000000e+02,3.188099794092476424e-06,2.315360055223674233e-07\n1.590000000000000000e+02,2.947662838751631882e-06,2.107686712836371323e-07\n1.600000000000000000e+02,2.725358919773287655e-06,1.918640372776853839e-07\n1.610000000000000000e+02,2.519820497765438816e-06,1.746550309222872992e-07\n1.620000000000000000e+02,2.329783169068632064e-06,1.589895650028257084e-07\n1.630000000000000000e+02,2.154077887567343715e-06,1.447291935783689828e-07\n1.640000000000000000e+02,1.991623773109122690e-06,1.317478884445826465e-07\n1.650000000000000000e+02,1.841421462291206318e-06,1.199309253402790319e-07\n1.660000000000000000e+02,1.702546960710990025e-06,1.091738700542873345e-07\n1.670000000000000000e+02,1.574145958861330386e-06,9.938165547220553085e-08\n1.680000000000000000e+02,1.455428576704084676e-06,9.046774140629903344e-08\n1.690000000000000000e+02,1.345664504592154460e-06,8.235334978341110323e-08\n1.700000000000000000e+02,1.244178510648704480e-06,7.496676843174332518e-08\n1.710000000000000000e+02,1.150346286966370785e-06,6.824271731361543448e-08\n1.720000000000000000e+02,1.063590609073743108e-06,6.212177160319057987e-08\n1.730000000000000000e+02,9.833777850433693248e-07,5.654983651052572371e-08\n1.740000000000000000e+02,9.092143723974497269e-07,5.147766921062733846e-08\n1.750000000000000000e+02,8.406441426146604487e-07,4.686044365248571483e-08\n1.760000000000000000e+02,7.772452745648214321e-07,4.265735440202204290e-08\n1.770000000000000000e+02,7.186277596063158125e-07,3.883125601785006228e-08\n1.780000000000000000e+02,6.644310023833055528e-07,3.534833477278048453e-08\n1.790000000000000000e+02,6.143216025636607207e-07,3.217780981985712666e-08\n1.800000000000000000e+02,5.679913038715634525e-07,2.929166116193395856e-08\n1.810000000000000000e+02,5.251550977979609679e-07,2.666438202068284959e-08\n1.820000000000000000e+02,4.855494703234889103e-07,2.427275341655537063e-08\n1.830000000000000000e+02,4.489307808683264632e-07,2.209563896751477326e-08\n1.840000000000000000e+02,4.150737634967932563e-07,2.011379809304058620e-08\n1.850000000000000000e+02,3.837701411566263280e-07,1.830971597256814844e-08\n1.860000000000000000e+02,3.548273444281777575e-07,1.666744875559394412e-08\n1.870000000000000000e+02,3.280673269017271221e-07,1.517248265546879308e-08\n1.880000000000000000e+02,3.033254698954861223e-07,1.381160568159779057e-08\n1.890000000000000000e+02,2.804495697765056736e-07,1.257279087646123465e-08\n1.900000000000000000e+02,2.592989016548043616e-07,1.144509002554582198e-08\n1.910000000000000000e+02,2.397433536908945878e-07,1.041853690083145727e-08\n1.920000000000000000e+02,2.216626266912393528e-07,9.484059182733264572e-09\n1.930000000000000000e+02,2.049454940678334475e-07,8.633398282095528261e-09\n1.940000000000000000e+02,1.894891176094164732e-07,7.859036353652232629e-09\n1.950000000000000000e+02,1.751984148551755258e-07,7.154129855924554516e-09\n1.960000000000000000e+02,1.619854741792354835e-07,6.512449070380760726e-09\n1.970000000000000000e+02,1.497690139877232306e-07,5.928323045349892307e-09\n1.980000000000000000e+02,1.384738827015775331e-07,5.396589478122675998e-09\n1.990000000000000000e+02,1.280305964491562209e-07,4.912549092315113344e-09\n2.000000000000000000e+02,1.183749116246884473e-07,4.471924107297723266e-09\n2.010000000000000000e+02,1.094474296830875316e-07,4.070820432657715450e-09\n2.020000000000000000e+02,1.011932317399602163e-07,3.705693253581938607e-09\n2.030000000000000000e+02,9.356154072898825187e-08,3.373315703016008423e-09\n2.040000000000000000e+02,8.650540903839294033e-08,3.070750343735317519e-09\n2.050000000000000000e+02,7.998142970492081770e-08,2.795323208296174046e-09\n2.060000000000000000e+02,7.394946938871825903e-08,2.544600167441266716e-09\n2.070000000000000000e+02,6.837242148644100636e-08,2.316365418111634552e-09\n2.080000000000000000e+02,6.321597786383453168e-08,2.108601900949663442e-09\n2.090000000000000000e+02,5.844841780356308297e-08,1.919473474229813436e-09\n2.100000000000000000e+02,5.404041286995998357e-08,1.747308686676473285e-09\n2.110000000000000000e+02,4.996484649029641383e-08,1.590586005758745555e-09\n2.120000000000000000e+02,4.619664714269129270e-08,1.447920370914976626e-09\n2.130000000000000000e+02,4.271263412448961927e-08,1.318050952869095916e-09\n2.140000000000000000e+02,3.949137495233019984e-08,1.199830010859861717e-09\n2.150000000000000000e+02,3.651305351667229472e-08,1.092212749307083357e-09\n2.160000000000000000e+02,3.375934817971471886e-08,9.942480842715522899e-10\n2.170000000000000000e+02,3.121331906680457741e-08,9.050702381058942182e-10\n2.180000000000000000e+02,2.885930385799229745e-08,8.238910880127282860e-10\n2.190000000000000000e+02,2.668282143867477073e-08,7.499932008894290543e-10\n2.200000000000000000e+02,2.467048281661966019e-08,6.827234929038114728e-10\n2.210000000000000000e+02,2.280990875736085888e-08,6.214874577662994116e-10\n2.220000000000000000e+02,2.108965363128705550e-08,5.657439126900469779e-10\n2.230000000000000000e+02,1.949913500395431520e-08,5.150002156056370424e-10\n2.240000000000000000e+02,1.802856853648727623e-08,4.688079113617631988e-10\n2.250000000000000000e+02,1.666890779559739633e-08,4.267587684345295510e-10\n2.260000000000000000e+02,1.541178860294939659e-08,3.884811711191840824e-10\n2.270000000000000000e+02,1.424947758153270722e-08,3.536368353197305825e-10\n2.280000000000000000e+02,1.317482458251117097e-08,3.219178189117093517e-10\n2.290000000000000000e+02,1.218121869989784345e-08,2.930438002567719322e-10\n2.300000000000000000e+02,1.126254760247123952e-08,2.667596008175093138e-10\n2.310000000000000000e+02,1.041315993275733993e-08,2.428329299782635043e-10\n2.320000000000000000e+02,9.627830541767491575e-09,2.210523321414332061e-10\n2.330000000000000000e+02,8.901728345628718890e-09,2.012253179564249117e-10\n2.340000000000000000e+02,8.230386606370657944e-09,1.831766631657031472e-10\n2.350000000000000000e+02,7.609675454047027393e-09,1.667468600337233936e-10\n2.360000000000000000e+02,7.035776481156220974e-09,1.517907076730289407e-10\n2.370000000000000000e+02,6.505159253074929436e-09,1.381760288092931058e-10\n2.380000000000000000e+02,6.014559590004494066e-09,1.257825016445264609e-10\n2.390000000000000000e+02,5.560959486828161671e-09,1.145005964948620555e-10\n2.400000000000000000e+02,5.141568547352446748e-09,1.042306078052926314e-10\n2.410000000000000000e+02,4.753806818722618942e-09,9.488177298664316127e-11\n2.420000000000000000e+02,4.395288920415250225e-09,8.637147028736558546e-11\n2.430000000000000000e+02,4.063809370174622932e-09,7.862448861122621936e-11\n2.440000000000000000e+02,3.757329016623287096e-09,7.157236282778799387e-11\n2.450000000000000000e+02,3.473962495084429824e-09,6.515276870139298642e-11\n2.460000000000000000e+02,3.211966629448694983e-09,5.930897209123766070e-11\n2.470000000000000000e+02,2.969729708737469259e-09,5.398932755476286106e-11\n2.480000000000000000e+02,2.745761572395814082e-09,4.914682192318937868e-11\n2.490000000000000000e+02,2.538684443322857824e-09,4.473865881547940566e-11\n2.500000000000000000e+02,2.347224452247686152e-09,4.072588041880008782e-11\n2.510000000000000000e+02,2.170203801311419778e-09,3.707302319292003322e-11\n2.520000000000000000e+02,2.006533518648580504e-09,3.374780445577120419e-11\n2.530000000000000000e+02,1.855206759396190090e-09,3.072083708032942545e-11\n2.540000000000000000e+02,1.715292611920784544e-09,2.796536978140364930e-11\n2.550000000000000000e+02,1.585930371161226870e-09,2.545705069707879759e-11\n2.560000000000000000e+02,1.466324243858949372e-09,2.317371217542729115e-11\n2.570000000000000000e+02,1.355738453103839569e-09,2.109517486450896286e-11\n2.580000000000000000e+02,1.253492712080669698e-09,1.920306937427496420e-11\n2.590000000000000000e+02,1.158958039172038170e-09,1.748067393428553002e-11\n2.600000000000000000e+02,1.071552888673715085e-09,1.591276661251695914e-11\n2.610000000000000000e+02,9.907395733199086004e-10,1.448549078921904121e-11\n2.620000000000000000e+02,9.160209566109420196e-10,1.318623269692764440e-11\n2.630000000000000000e+02,8.469373945957093238e-10,1.200350994437365236e-11\n2.640000000000000000e+02,7.830639082957389268e-10,1.092687003910134199e-11\n2.650000000000000000e+02,7.240075693766089755e-10,9.946798011974345753e-12\n2.660000000000000000e+02,6.694050829841796573e-10,9.054632327186913564e-12\n2.670000000000000000e+02,6.189205528761082704e-10,8.242488334621845455e-12\n2.680000000000000000e+02,5.722434151004485678e-10,7.503188588054389586e-12\n2.690000000000000000e+02,5.290865275100563133e-10,6.830199413378057654e-12\n2.700000000000000000e+02,4.891844033600834559e-10,6.217573166264628961e-12\n2.710000000000000000e+02,4.522915781222823322e-10,5.659895668951562539e-12\n2.720000000000000000e+02,4.181810994692809050e-10,5.152238361621432942e-12\n2.730000000000000000e+02,3.866431311397467878e-10,4.690114745503920780e-12\n2.740000000000000000e+02,3.574836620958498090e-10,4.269440732759634758e-12\n2.750000000000000000e+02,3.305233130322188974e-10,3.886498552731812865e-12\n2.760000000000000000e+02,3.055962328944229576e-10,3.537903895581929323e-12\n2.770000000000000000e+02,2.825490786187255862e-10,3.220576002936056691e-12\n2.780000000000000000e+02,2.612400718168268088e-10,2.931710441213536974e-12\n2.790000000000000000e+02,2.415381266026109420e-10,2.668754317018090776e-12\n2.800000000000000000e+02,2.233220431956003306e-10,2.429383715553615604e-12\n2.810000000000000000e+02,2.064797623404200538e-10,2.211483162673270904e-12\n2.820000000000000000e+02,1.909076759557261327e-10,2.013126929054463100e-12\n2.830000000000000000e+02,1.765099897719225758e-10,1.832562011272705874e-12\n2.840000000000000000e+02,1.631981340368405417e-10,1.668192639366859089e-12\n2.850000000000000000e+02,1.508902186642304700e-10,1.518566173979062097e-12\n2.860000000000000000e+02,1.395105294733311059e-10,1.382360268433168754e-12\n2.870000000000000000e+02,1.289890624205389078e-10,1.258371182294601375e-12\n2.880000000000000000e+02,1.192610929579354760e-10,1.145503143130931762e-12\n2.890000000000000000e+02,1.102667778695050065e-10,1.042758662456119166e-12\n2.900000000000000000e+02,1.019507871356777599e-10,9.492297202740980749e-13\n2.910000000000000000e+02,9.426196356154517669e-11,8.640897403137704252e-13\n2.920000000000000000e+02,8.715300807489939066e-11,7.865862850353204100e-13\n2.930000000000000000e+02,8.058018875815357934e-11,7.160344058488599620e-13\n2.940000000000000000e+02,7.450307182420372856e-11,6.518105897769469751e-13\n2.950000000000000000e+02,6.888427288128940086e-11,5.933472490636852840e-13\n2.960000000000000000e+02,6.368922695671221836e-11,5.401277050314880655e-13\n2.970000000000000000e+02,5.888597586467960426e-11,4.916816218545713130e-13\n2.980000000000000000e+02,5.444497161022884004e-11,4.475808498944690741e-13\n2.990000000000000000e+02,5.033889461984128329e-11,4.074356418623840791e-13\n3.000000000000000000e+02,4.654248568055842375e-11,3.708912083681716409e-13\n3.010000000000000000e+02,4.303239055374839246e-11,3.376245824150677857e-13\n3.020000000000000000e+02,3.978701630763673066e-11,3.073417651296667306e-13\n3.030000000000000000e+02,3.678639848480974731e-11,2.797751275021010506e-13\n3.040000000000000000e+02,3.401207828754608021e-11,2.546810451739068364e-13\n3.050000000000000000e+02,3.144698902546415306e-11,2.318377453706512016e-13\n3.060000000000000000e+02,2.907535112694859392e-11,2.110433469512621406e-13\n3.070000000000000000e+02,2.688257506850037616e-11,1.921140762526977949e-13\n3.080000000000000000e+02,2.485517162486633514e-11,1.748826429622099205e-13\n3.090000000000000000e+02,2.298066888783444736e-11,1.591967616637269563e-13\n3.100000000000000000e+02,2.124753554322415810e-11,1.449178059922958770e-13\n3.110000000000000000e+02,1.964510993409621605e-11,1.319195835024691444e-13\n3.120000000000000000e+02,1.816353447380391058e-11,1.200872204233483434e-13\n3.130000000000000000e+02,1.679369500541514249e-11,1.093161464441402334e-13\n3.140000000000000000e+02,1.552716473446605233e-11,9.951117055810621720e-14\n3.150000000000000000e+02,1.435615239013837187e-11,9.058563979754443823e-14\n3.160000000000000000e+02,1.327345429596635089e-11,8.246067342498990957e-14\n3.170000000000000000e+02,1.227241005522716294e-11,7.506446581268349015e-14\n3.180000000000000000e+02,1.134686157840695184e-11,6.833165184940058719e-14\n3.190000000000000000e+02,1.049111520069268449e-11,6.220272926632540885e-14\n3.200000000000000000e+02,9.699906656449891247e-12,5.662353277668812290e-14\n3.210000000000000000e+02,8.968368695220184632e-12,5.154475538179355363e-14\n3.220000000000000000e+02,8.292001140023642482e-12,4.692151261291072103e-14\n3.230000000000000000e+02,7.666643203774478818e-12,4.271294585794447297e-14\n3.240000000000000000e+02,7.088447893509771027e-12,3.888186126722826627e-14\n3.250000000000000000e+02,6.553858344974982350e-12,3.539440104721308303e-14\n3.260000000000000000e+02,6.059585941984042814e-12,3.221974423706036589e-14\n3.270000000000000000e+02,5.602590085952025097e-12,2.932983432370653354e-14\n3.280000000000000000e+02,5.180059491149050070e-12,2.669913128815573412e-14\n3.290000000000000000e+02,4.789394890610444315e-12,2.430438589167212839e-14\n3.300000000000000000e+02,4.428193046315229530e-12,2.212443420709200912e-14\n3.310000000000000000e+02,4.094231965269274206e-12,2.014001057939367318e-14\n3.320000000000000000e+02,3.785457230547161562e-12,1.833357736253735107e-14\n3.330000000000000000e+02,3.499969363206153865e-12,1.668916992784723230e-14\n3.340000000000000000e+02,3.236012137326689994e-12,1.519225557417411438e-14\n3.350000000000000000e+02,2.991961776297664548e-12,1.382960509293564292e-14\n3.360000000000000000e+02,2.766316963885514736e-12,1.258917585297064501e-14\n3.370000000000000000e+02,2.557689608638716012e-12,1.146000537195214346e-14\n3.380000000000000000e+02,2.364796304813175835e-12,1.043211443378017946e-14\n3.390000000000000000e+02,2.186450437289155871e-12,9.496418895739695149e-15\n3.400000000000000000e+02,2.021554881911756400e-12,8.644649406005761240e-15\n3.410000000000000000e+02,1.869095256349861128e-12,7.869278321987383052e-15\n3.420000000000000000e+02,1.728133679955195298e-12,7.163453183639622280e-15\n3.430000000000000000e+02,1.597803004234084951e-12,6.520936153804433686e-15\n3.440000000000000000e+02,1.477301478439831202e-12,5.936048890374471573e-15\n3.450000000000000000e+02,1.365887817470125109e-12,5.403622363080264784e-15\n3.460000000000000000e+02,1.262876641728946588e-12,4.918951171397600189e-15\n3.470000000000000000e+02,1.167634260900394234e-12,4.477751959854081519e-15\n3.480000000000000000e+02,1.079574775697717904e-12,4.076125563222481260e-15\n3.490000000000000000e+02,9.981564736067605138e-13,3.710522547054468842e-15\n3.500000000000000000e+02,9.228784964516931914e-13,3.377711839012846954e-15\n3.510000000000000000e+02,8.532777592829400023e-13,3.074752173777897988e-15\n3.520000000000000000e+02,7.889261016333859788e-13,2.798966099166958658e-15\n3.530000000000000000e+02,7.294276536183215621e-13,2.547916313743143879e-15\n3.540000000000000000e+02,6.744164006762431829e-13,2.319384126792618052e-15\n3.550000000000000000e+02,6.235539319696481943e-13,2.111349850307458055e-15\n3.560000000000000000e+02,5.765273585946841961e-13,1.921974949685400147e-15\n3.570000000000000000e+02,5.330473887932177664e-13,1.749585795400153900e-15\n3.580000000000000000e+02,4.928465483266429971e-13,1.592658872045684488e-15\n3.590000000000000000e+02,4.556775350637953998e-13,1.449807314036673508e-15\n3.600000000000000000e+02,4.213116976609075808e-13,1.319768648972782596e-15\n3.610000000000000000e+02,3.895376289749854006e-13,1.201393640346452247e-15\n3.620000000000000000e+02,3.601598655577332377e-13,1.093636130990316322e-15\n3.630000000000000000e+02,3.329976852297734988e-13,9.955437975038318011e-16\n3.640000000000000000e+02,3.078839953382095256e-13,9.062497339502524715e-16\n3.650000000000000000e+02,2.846643048584876654e-13,8.249647904433218070e-16\n3.660000000000000000e+02,2.631957740172573941e-13,7.509705989150201796e-16\n3.670000000000000000e+02,2.433463355898440497e-13,6.836132244283048996e-16\n3.680000000000000000e+02,2.249938824668294346e-13,6.222973859275503952e-16\n3.690000000000000000e+02,2.080255164919366369e-13,5.664811953515379836e-16\n3.700000000000000000e+02,1.923368539503161162e-13,5.156713686151740134e-16\n3.710000000000000000e+02,1.778313834348249981e-13,4.694188661362890043e-16\n3.720000000000000000e+02,1.644198721401191835e-13,4.273149243799097090e-16\n3.730000000000000000e+02,1.520198169322628681e-13,3.889874433482921604e-16\n3.740000000000000000e+02,1.405549368170311779e-13,3.540976980904944306e-16\n3.750000000000000000e+02,1.299547036847328907e-13,3.223373451690579333e-16\n3.760000000000000000e+02,1.201539084448605518e-13,2.934256976278966903e-16\n3.770000000000000000e+02,1.110922598815635728e-13,2.671072443785930827e-16\n3.780000000000000000e+02,1.027140137622447527e-13,2.431493920822219051e-16\n3.790000000000000000e+02,9.496762991767558242e-14,2.213404095703093025e-16\n3.800000000000000000e+02,8.780545518410757469e-14,2.014875566383699967e-16\n3.810000000000000000e+02,8.118343025693810763e-14,1.834153806750088746e-16\n3.820000000000000000e+02,7.506081865259841338e-14,1.669641660727338281e-16\n3.830000000000000000e+02,6.939995611132410899e-14,1.519885227169610314e-16\n3.840000000000000000e+02,6.416601889922209472e-14,1.383561010787239558e-16\n3.850000000000000000e+02,5.932680958430035986e-14,1.259464225555624650e-16\n3.860000000000000000e+02,5.485255896863040438e-14,1.146498147235207282e-16\n3.870000000000000000e+02,5.071574295819381803e-14,1.043664420903950633e-16\n3.880000000000000000e+02,4.689091324385659813e-14,9.500542378437239547e-17\n3.890000000000000000e+02,4.335454075188002996e-14,8.648403038047803374e-17\n3.900000000000000000e+02,4.008487090092414890e-14,7.872695276668838771e-17\n3.910000000000000000e+02,3.706178977513639318e-14,7.166563658817866564e-17\n3.920000000000000000e+02,3.426670039006491180e-14,6.523767638777581469e-17\n3.930000000000000000e+02,3.168240829022817401e-14,5.938626408822211321e-17\n3.940000000000000000e+02,2.929301577457243861e-14,5.405968694214436879e-17\n3.950000000000000000e+02,2.708382409912983833e-14,4.921087051276953526e-17\n3.960000000000000000e+02,2.504124305525896811e-14,4.479696264642345584e-17\n3.970000000000000000e+02,2.315270736722522709e-14,4.077895476009342460e-17\n3.980000000000000000e+02,2.140659939482471955e-14,3.712133709713741242e-17\n3.990000000000000000e+02,1.979217766554574828e-14,3.379178490439913207e-17\n4.000000000000000000e+02,1.829951079662058110e-14,3.076087275728118151e-17\n4.010000000000000000e+02,1.691941640047921700e-14,2.800181450807154600e-17\n4.020000000000000000e+02,1.564340459777049222e-14,2.549022655928535636e-17\n4.030000000000000000e+02,1.446362579046259225e-14,2.320391236990766420e-17\n4.040000000000000000e+02,1.337282237374018578e-14,2.112266629008122988e-17\n4.050000000000000000e+02,1.236428408964567590e-14,1.922809499059974655e-17\n4.060000000000000000e+02,1.143180674781580318e-14,1.750345490905839358e-17\n4.070000000000000000e+02,1.056965405937644031e-14,1.593350427607214782e-17\n4.080000000000000000e+02,9.772522349211190428e-15,1.450436841381648272e-17\n4.090000000000000000e+02,9.035507929524963293e-15,1.320341711644990690e-17\n4.100000000000000000e+02,8.354076933996353586e-15,1.201915302874537319e-17\n4.110000000000000000e+02,7.724037426947298854e-15,1.094111003646320256e-17\n4.120000000000000000e+02,7.141513615956397308e-15,9.959760770471758872e-18\n4.130000000000000000e+02,6.602922009279764520e-15,9.066432407172373860e-18\n4.140000000000000000e+02,6.104949371407503818e-15,8.253230021099326089e-18\n4.150000000000000000e+02,5.644532341146643059e-15,7.512966812314163293e-18\n4.160000000000000000e+02,5.218838586847297349e-15,6.839100591966203033e-18\n4.170000000000000000e+02,4.825249382844932366e-15,6.225675964702582975e-18\n4.180000000000000000e+02,4.461343499935846079e-15,5.667271696954629422e-18\n4.190000000000000000e+02,4.124882310784279658e-15,5.158952805960427139e-18\n4.200000000000000000e+02,3.813796018635554322e-15,4.696226946103343169e-18\n4.210000000000000000e+02,3.526170924618453319e-15,4.275004707123143723e-18\n4.220000000000000000e+02,3.260237655309339112e-15,3.891563473330277053e-18\n4.230000000000000000e+02,3.014360278138567802e-15,3.542514524422502762e-18\n4.240000000000000000e+02,2.787026237680052508e-15,3.224773087153346319e-18\n4.250000000000000000e+02,2.576837050916017807e-15,2.935531073178510642e-18\n4.260000000000000000e+02,2.382499704237044118e-15,2.672232262147648253e-18\n4.270000000000000000e+02,2.202818699254491345e-15,2.432549710717522925e-18\n4.280000000000000000e+02,2.036688698494138888e-15,2.214365187835981068e-18\n4.290000000000000000e+02,1.883087725729600503e-15,2.015750454552272243e-18\n4.300000000000000000e+02,1.741070879126135534e-15,1.834950222911780967e-18\n4.310000000000000000e+02,1.609764518520554211e-15,1.670366643331274987e-18\n4.320000000000000000e+02,1.488360891078907338e-15,1.520545183359958504e-18\n4.330000000000000000e+02,1.376113162271130362e-15,1.384161773027365309e-18\n4.340000000000000000e+02,1.272330821594711862e-15,1.260011103173310945e-18\n4.350000000000000000e+02,1.176375434784855179e-15,1.146995973344690621e-18\n4.360000000000000000e+02,1.087656716380389248e-15,1.044117595119293170e-18\n4.370000000000000000e+02,1.005628898484883901e-15,9.504667651610724053e-19\n4.380000000000000000e+02,9.297873733850346336e-16,8.652158299971301775e-19\n4.390000000000000000e+02,8.596655893727213059e-16,7.876113715041533509e-19\n4.400000000000000000e+02,7.948321806748285388e-16,7.169675484609506790e-19\n4.410000000000000000e+02,7.348883138352421440e-16,6.526600353222535030e-19\n4.420000000000000000e+02,6.794652342247726276e-16,5.941205046465811950e-19\n4.430000000000000000e+02,6.282219975859166315e-16,5.408316044159588989e-19\n4.440000000000000000e+02,5.808433726578047923e-16,4.923223858586301357e-19\n4.450000000000000000e+02,5.370379019788352256e-16,4.481641413675924180e-19\n4.460000000000000000e+02,4.965361089378206708e-16,4.079666157317983479e-19\n4.470000000000000000e+02,4.590888400439744034e-16,3.713745571963187484e-19\n4.480000000000000000e+02,4.244657322179028492e-16,3.380645778708282733e-19\n4.490000000000000000e+02,3.924537956749804067e-16,3.077422957398930402e-19\n4.500000000000000000e+02,3.628561036833754752e-16,2.801397330170644359e-19\n4.510000000000000000e+02,3.354905811366406863e-16,2.550129478503736640e-19\n4.520000000000000000e+02,3.101888844885329317e-16,2.321398784490756536e-19\n4.530000000000000000e+02,2.867953661597804850e-16,2.113183805787384675e-19\n4.540000000000000000e+02,2.651661170462175625e-16,1.923644410807981642e-19\n4.550000000000000000e+02,2.451680812380901216e-16,1.751105516282322150e-19\n4.560000000000000000e+02,2.266782375045670010e-16,1.594042283452191082e-19\n4.570000000000000000e+02,2.095828425082694579e-16,1.451066642076518619e-19\n4.580000000000000000e+02,1.937767310942723611e-16,1.320915023149315262e-19\n4.590000000000000000e+02,1.791626693492340269e-16,1.202437191916051724e-19\n4.600000000000000000e+02,1.656507564508707600e-16,1.094586082498913070e-19\n4.610000000000000000e+02,1.531578716281446131e-16,9.964085442925616968e-20\n4.620000000000000000e+02,1.416071628300720153e-16,9.070369183505629111e-20\n4.630000000000000000e+02,1.309275739576010560e-16,8.256813693172397466e-20\n4.640000000000000000e+02,1.210534077502374201e-16,7.516229051374793918e-20\n4.650000000000000000e+02,1.119239216384686229e-16,6.842070228548935184e-20\n4.660000000000000000e+02,1.034829540757764850e-16,6.228379243422993863e-20\n4.670000000000000000e+02,9.567857905158111059e-17,5.669732508450124359e-20\n4.680000000000000000e+02,8.846278665978478259e-17,5.161192898027381203e-20\n4.690000000000000000e+02,8.179118775787482315e-17,4.698266115896567128e-20\n4.700000000000000000e+02,7.562274089976372549e-17,4.276860976116253355e-20\n4.710000000000000000e+02,6.991949986252882302e-17,3.893253246583209775e-20\n4.720000000000000000e+02,6.464638021393651252e-17,3.544052735563736267e-20\n4.730000000000000000e+02,5.977094348474538318e-17,3.226173330358113428e-20\n4.740000000000000000e+02,5.526319761808487320e-17,2.936805723309391608e-20\n4.750000000000000000e+02,5.109541246834963798e-17,2.673392584119304925e-20\n4.760000000000000000e+02,4.724194921461499310e-17,2.433605959052098097e-20\n4.770000000000000000e+02,4.367910263917931811e-17,2.215326697289000230e-20\n4.780000000000000000e+02,4.038495530099230434e-17,2.016625722609965088e-20\n4.790000000000000000e+02,3.733924270688245255e-17,1.835746984888911742e-20\n4.800000000000000000e+02,3.452322865117067609e-17,1.671091940733164148e-20\n4.810000000000000000e+02,3.191958995679725857e-17,1.521205426112858927e-20\n4.820000000000000000e+02,2.951230990892607729e-17,1.384762796127161391e-20\n4.830000000000000000e+02,2.728657972547133423e-17,1.260558218253183906e-20\n4.840000000000000000e+02,2.522870745841924091e-17,1.147494015617484894e-20\n4.850000000000000000e+02,2.332603376554185159e-17,1.044570966109446761e-20\n4.860000000000000000e+02,2.156685403435624185e-17,9.508794716037600529e-21\n4.870000000000000000e+02,1.994034637926039625e-17,8.655915192483946120e-21\n4.880000000000000000e+02,1.843650506891136148e-17,7.879533637749706721e-21\n4.890000000000000000e+02,1.704607897431138249e-17,7.172788661600998199e-21\n4.900000000000000000e+02,1.576051465895407194e-17,6.529434297673149277e-21\n4.910000000000000000e+02,1.457190376094349867e-17,5.943784803791244227e-21\n4.920000000000000000e+02,1.347293434339478409e-17,5.410664413358102362e-21\n4.930000000000000000e+02,1.245684591384320242e-17,4.925361593728347186e-21\n4.940000000000000000e+02,1.151738783595482914e-17,4.483587407321400176e-21\n4.950000000000000000e+02,1.064878087770091395e-17,4.081437607482108318e-21\n4.960000000000000000e+02,9.845681659454763291e-18,3.715358134106553652e-21\n4.970000000000000000e+02,9.103149783306792585e-18,3.382113704094481000e-21\n4.980000000000000000e+02,8.416617441387696646e-18,3.078759219042100464e-21\n4.990000000000000000e+02,7.781861316242022456e-18,2.802613737486573544e-21\n5.000000000000000000e+02,7.194976600390618060e-18,2.551236781677338397e-21\n5.010000000000000000e+02,6.652352975260620939e-18,2.322406769482471713e-21\n5.020000000000000000e+02,6.150652401712690589e-18,2.114101380818094543e-21\n5.030000000000000000e+02,5.686788585539797799e-18,1.924479685086768240e-21\n5.040000000000000000e+02,5.257907991617408701e-18,1.751865871672837187e-21\n5.050000000000000000e+02,4.861372289909042752e-18,1.594734439711001291e-21\n5.060000000000000000e+02,4.494742125342039087e-18,1.451696716239977104e-21\n5.070000000000000000e+02,4.155762111710725998e-18,1.321488583593802984e-21\n5.080000000000000000e+02,3.842346957294277008e-18,1.202959307569350542e-21\n5.090000000000000000e+02,3.552568636839275290e-18,1.095061367637627848e-21\n5.100000000000000000e+02,3.284644530992978398e-18,9.968411993214926382e-22\n5.110000000000000000e+02,3.036926460224817104e-18,9.074307669244215606e-22\n5.120000000000000000e+02,2.807890545777119078e-18,8.260398921327813119e-22\n5.130000000000000000e+02,2.596127835272268847e-18,7.519492706946844787e-22\n5.140000000000000000e+02,2.400335635308776905e-18,6.845041154590903946e-22\n5.150000000000000000e+02,2.219309497727018050e-18,6.231083695946199208e-22\n5.160000000000000000e+02,2.051935810246688333e-18,5.672194388465630263e-22\n5.170000000000000000e+02,1.897184945896473447e-18,5.163433962774772114e-22\n5.180000000000000000e+02,1.754104929093024947e-18,4.700306171126865319e-22\n5.190000000000000000e+02,1.621815579405469775e-18,4.278718051128258502e-22\n5.200000000000000000e+02,1.499503096979682997e-18,3.894943753560176446e-22\n5.210000000000000000e+02,1.386415056313570838e-18,3.545591614618538494e-22\n5.220000000000000000e+02,1.281855777586961133e-18,3.227574181568771367e-22\n5.230000000000000000e+02,1.185182047071945341e-18,2.938080926911830235e-22\n5.240000000000000000e+02,1.095799160296989963e-18,2.674553409919576062e-22\n5.250000000000000000e+02,1.013157263623910369e-18,2.434662666025006965e-22\n5.260000000000000000e+02,9.367479717320510151e-19,2.216288624243357235e-22\n5.270000000000000000e+02,8.661012402017745203e-19,2.017501370721732044e-22\n5.280000000000000000e+02,8.007824739583490140e-19,1.836544092831638725e-22\n5.290000000000000000e+02,7.403898537882910566e-19,1.671817553069695394e-22\n5.300000000000000000e+02,6.845518644819430603e-19,1.521865955552730303e-22\n5.310000000000000000e+02,6.329250093960640257e-19,1.385364080199896731e-22\n5.320000000000000000e+02,5.851916973773309462e-19,1.261105570898352615e-22\n5.330000000000000000e+02,5.410582890477476776e-19,1.147992274147450823e-22\n5.340000000000000000e+02,5.002532904333314255e-19,1.045024533959854127e-22\n5.350000000000000000e+02,4.625256828239605606e-19,9.512923572495654924e-23\n5.360000000000000000e+02,4.276433785901960184e-19,8.659673716293761145e-23\n5.370000000000000000e+02,3.953917934577504842e-19,7.882955045437875828e-23\n5.380000000000000000e+02,3.655725264567947422e-19,7.175903190379053441e-23\n5.390000000000000000e+02,3.380021394254970229e-19,6.532269472663512011e-23\n5.400000000000000000e+02,3.125110285597854905e-19,5.946365681284690275e-23\n5.410000000000000000e+02,2.889423810674513117e-19,5.413013802252552183e-23\n5.420000000000000000e+02,2.671512105082603699e-19,4.927500257105970294e-23\n5.430000000000000000e+02,2.470034648858509031e-19,4.485534245945516859e-23\n5.440000000000000000e+02,2.283752020046704410e-19,4.083209826835565191e-23\n5.450000000000000000e+02,2.111518270190114762e-19,3.716971396447796750e-23\n5.460000000000000000e+02,1.952273874838436191e-19,3.383582266875153167e-23\n5.470000000000000000e+02,1.805039215707812946e-19,3.080096060909440327e-23\n5.480000000000000000e+02,1.668908554396697179e-19,2.803830672984185987e-23\n5.490000000000000000e+02,1.543044460586030247e-19,2.552344565658024482e-23\n5.500000000000000000e+02,1.426672660447792919e-19,2.323415192155877049e-23\n5.510000000000000000e+02,1.319077273571351971e-19,2.115019354273179486e-23\n5.520000000000000000e+02,1.219596409106419806e-19,1.925315322053750107e-23\n5.530000000000000000e+02,1.127618094031854888e-19,1.752626557220680637e-23\n5.540000000000000000e+02,1.042576508502241009e-19,1.595426896514088847e-23\n5.550000000000000000e+02,9.639485051133075464e-20,1.452327063990768024e-23\n5.560000000000000000e+02,8.912503906740157859e-20,1.322062393086546956e-23\n5.570000000000000000e+02,8.240349506877673964e-20,1.203481649932832131e-23\n5.580000000000000000e+02,7.618886982382821898e-20,1.095536859152037482e-23\n5.590000000000000000e+02,7.044293303563700502e-20,9.972740422155064771e-24\n5.600000000000000000e+02,6.513033762198293468e-20,9.078247865130319037e-24\n5.610000000000000000e+02,6.021840227191351339e-20,8.263985706241249074e-24\n5.620000000000000000e+02,5.567691040124568944e-20,7.522757779645491560e-24\n5.630000000000000000e+02,5.147792427023844027e-20,6.848013370652011949e-24\n5.640000000000000000e+02,4.759561311996099494e-20,6.233789322781879445e-24\n5.650000000000000000e+02,4.400609427009654134e-20,5.674657337465114313e-24\n5.660000000000000000e+02,4.068728620067826305e-20,5.165676000624951665e-24\n5.670000000000000000e+02,3.761877271396126755e-20,4.702347112178706539e-24\n5.680000000000000000e+02,3.478167734079757579e-20,4.280575932509145149e-24\n5.690000000000000000e+02,3.215854721890937441e-20,3.896634994579768954e-24\n5.700000000000000000e+02,2.973324572871552218e-20,3.547131161876926288e-24\n5.710000000000000000e+02,2.749085322624085791e-20,3.228975641049324194e-24\n5.720000000000000000e+02,2.541757526245591730e-20,2.939356684226151971e-24\n5.730000000000000000e+02,2.350065772443663341e-20,2.675714739767231294e-24\n5.740000000000000000e+02,2.172830837632606878e-20,2.435719831835396359e-24\n5.750000000000000000e+02,2.008962431744207358e-20,2.217250968880336939e-24\n5.760000000000000000e+02,1.857452491127620026e-20,2.018377399052598481e-24\n5.770000000000000000e+02,1.717368977278847810e-20,1.837341546890172231e-24\n5.780000000000000000e+02,1.587850143251483669e-20,1.672543480477617894e-24\n5.790000000000000000e+02,1.468099232477496541e-20,1.522526771804055875e-24\n5.800000000000000000e+02,1.357379577387279166e-20,1.385965625358890024e-24\n5.810000000000000000e+02,1.255010067676954755e-20,1.261653161211971461e-24\n5.820000000000000000e+02,1.160360960345523015e-20,1.148490749028490854e-24\n5.830000000000000000e+02,1.072850005726466663e-20,1.045478298755994961e-24\n5.840000000000000000e+02,9.919388656823938164e-21,9.517054221763016904e-25\n5.850000000000000000e+02,9.171298019288510854e-21,8.663433872109078513e-25\n5.860000000000000000e+02,8.479626141147410039e-21,7.886377938750845838e-25\n5.870000000000000000e+02,7.840118088236344185e-21,7.179019071530636801e-25\n5.880000000000000000e+02,7.248839820805325850e-21,6.535105878727938942e-25\n5.890000000000000000e+02,6.702153992620955105e-21,5.948947679432543905e-25\n5.900000000000000000e+02,6.196697575228572968e-21,5.415364211285706336e-25\n5.910000000000000000e+02,5.729361169725607890e-21,4.929639849122223327e-25\n5.920000000000000000e+02,5.297269878778704769e-21,4.487481929915174767e-25\n5.930000000000000000e+02,4.897765621216765016e-21,4.084982815712345097e-25\n5.940000000000000000e+02,4.528390780403913474e-21,3.718585359290926515e-25\n5.950000000000000000e+02,4.186873085803680998e-21,3.385051467327066095e-25\n5.960000000000000000e+02,3.871111634730376734e-21,3.081433483252891112e-25\n5.970000000000000000e+02,3.579163968297902415e-21,2.805048136892826266e-25\n5.980000000000000000e+02,3.309234122062285944e-21,2.553452830654567272e-25\n5.990000000000000000e+02,3.059661577848636164e-21,2.324424052701020428e-25\n6.000000000000000000e+02,2.828911048798541002e-21,2.115937726325640778e-25\n6.010000000000000000e+02,2.615563034798621630e-21,1.926151321866413093e-25\n6.020000000000000000e+02,2.418305090190258857e-21,1.753387573069212482e-25\n6.030000000000000000e+02,2.235923750042729094e-21,1.596119653991954838e-25\n6.040000000000000000e+02,2.067297065322661008e-21,1.452957685447686381e-25\n6.050000000000000000e+02,1.911387701038546028e-21,1.322636451735687952e-25\n6.060000000000000000e+02,1.767236554902778719e-21,1.204004219104937172e-25\n6.070000000000000000e+02,1.633956857254916097e-21,1.096012557131752765e-25\n6.080000000000000000e+02,1.510728715951226299e-21,9.977070730561773409e-26\n6.090000000000000000e+02,1.396794072662342935e-21,9.082189771906637715e-26\n6.100000000000000000e+02,1.291452039551771963e-21,8.267574048588668812e-26\n6.110000000000000000e+02,1.194054587648314314e-21,7.526024270086020242e-26\n6.120000000000000000e+02,1.104002560388406593e-21,6.850986877292404595e-26\n6.130000000000000000e+02,1.020741987805275393e-21,6.236496124439940163e-26\n6.140000000000000000e+02,9.437606786909165745e-22,5.677121355912744169e-26\n6.150000000000000000e+02,8.725850697669677265e-22,5.167919012000456155e-26\n6.160000000000000000e+02,8.067773124817589563e-22,4.704388939436728143e-26\n6.170000000000000000e+02,7.459325795124144058e-22,4.282434620609050281e-26\n6.180000000000000000e+02,6.896765744024574088e-22,3.898326969960720821e-26\n6.190000000000000000e+02,6.376632290151841182e-22,3.548671377629042585e-26\n6.200000000000000000e+02,5.895725746381424038e-22,3.230377709063892298e-26\n6.210000000000000000e+02,5.451087736425971235e-22,2.940632995492786980e-26\n6.220000000000000000e+02,5.039982995893488421e-22,2.676876573881134828e-26\n6.230000000000000000e+02,4.659882545854978005e-22,2.436777456682499615e-26\n6.240000000000000000e+02,4.308448135411648790e-22,2.218213731381287973e-26\n6.250000000000000000e+02,3.983517857557164585e-22,2.019253807767660429e-26\n6.260000000000000000e+02,3.683092849848260107e-22,1.838139347214827145e-26\n6.270000000000000000e+02,3.405324998071458186e-22,1.673269723093740626e-26\n6.280000000000000000e+02,3.148505567262072113e-22,1.523187874991373948e-26\n6.290000000000000000e+02,2.911054690138029211e-22,1.386567431717507902e-26\n6.300000000000000000e+02,2.691511648284567171e-22,1.262200989297239848e-26\n6.310000000000000000e+02,2.488525886302729169e-22,1.148989440354547905e-26\n6.320000000000000000e+02,2.300848703644206618e-22,1.045932260583385413e-26\n6.330000000000000000e+02,2.127325573022881049e-22,9.521186664618146453e-27\n6.340000000000000000e+02,1.966889038148986866e-22,8.667195660638541206e-27\n6.350000000000000000e+02,1.818552147094912170e-22,7.889802318333692497e-27\n6.360000000000000000e+02,1.681402380896795677e-22,7.182136305642968778e-27\n6.370000000000000000e+02,1.554596040042970877e-22,6.537943516400981923e-27\n6.380000000000000000e+02,1.437353054316654089e-22,5.951530798721409616e-27\n6.390000000000000000e+02,1.328952184064674152e-22,5.417715640900521387e-27\n6.400000000000000000e+02,1.228726583372326347e-22,4.931780370180334420e-27\n6.410000000000000000e+02,1.136059697850164964e-22,4.489430459597406154e-27\n6.420000000000000000e+02,1.050381471797549631e-22,4.086756574446589235e-27\n6.430000000000000000e+02,9.711648414105690777e-23,3.720200022940109814e-27\n6.440000000000000000e+02,8.979224924616662607e-23,3.386521305727105659e-27\n6.450000000000000000e+02,8.302038625054804353e-23,3.082771486324504756e-27\n6.460000000000000000e+02,7.675923691692613392e-23,2.806266129441938044e-27\n6.470000000000000000e+02,7.097028474774001957e-23,2.554561576875832009e-27\n6.480000000000000000e+02,6.561791804452757149e-23,2.325433351308031893e-27\n6.490000000000000000e+02,6.066921083665863012e-23,2.116856497148556092e-27\n6.500000000000000000e+02,5.609372033177270017e-23,1.926987684682308783e-27\n6.510000000000000000e+02,5.186329964189866517e-23,1.754148919361853873e-27\n6.520000000000000000e+02,4.795192463320684742e-23,1.596812712275156601e-27\n6.530000000000000000e+02,4.433553383424077754e-23,1.453588580729579809e-27\n6.540000000000000000e+02,4.099188041778614715e-23,1.323210759649413297e-27\n6.550000000000000000e+02,3.790039534582818830e-23,1.204527015184149278e-27\n6.560000000000000000e+02,3.504206083570691505e-23,1.096488461666424437e-27\n6.570000000000000000e+02,3.239929336907403702e-23,9.981402919251143341e-28\n6.580000000000000000e+02,2.995583552396844114e-23,9.086133390316000478e-28\n6.590000000000000000e+02,2.769665596458950275e-23,8.271163949046336662e-28\n6.600000000000000000e+02,2.560785697354511913e-23,7.529292178884031538e-28\n6.610000000000000000e+02,2.367658895774088554e-23,6.853961675072468550e-28\n6.620000000000000000e+02,2.189097140197793686e-23,6.239204101430504758e-28\n6.630000000000000000e+02,2.024001978399582504e-23,5.679586444272890616e-28\n6.640000000000000000e+02,1.871357800136411485e-23,5.170162997324002333e-28\n6.650000000000000000e+02,1.730225589453449093e-23,4.706431653285733329e-28\n6.660000000000000000e+02,1.599737148171949730e-23,4.284294115778262093e-28\n6.670000000000000000e+02,1.479089755024210845e-23,3.900019680021900285e-28\n6.680000000000000000e+02,1.367541227580729773e-23,3.550212262165158039e-28\n6.690000000000000000e+02,1.264405356592041927e-23,3.231780385876709775e-28\n6.700000000000000000e+02,1.169047684658758431e-23,2.941909860952268728e-28\n6.710000000000000000e+02,1.080881603261784383e-23,2.678038912480247449e-28\n6.720000000000000000e+02,9.993647441428348012e-24,2.437835540765637694e-28\n6.730000000000000000e+02,9.239956428361738041e-24,2.219176911927684246e-28\n6.740000000000000000e+02,8.543106538269224011e-24,2.020130597032086764e-28\n6.750000000000000000e+02,7.898810983588011286e-24,1.838937493955943777e-28\n6.760000000000000000e+02,7.303106273457548282e-24,1.673996281054931357e-28\n6.770000000000000000e+02,6.752327831648903552e-24,1.523849265239275899e-28\n6.780000000000000000e+02,6.243087453316530759e-24,1.387169499389167935e-28\n6.790000000000000000e+02,5.772252461895154264e-24,1.262749055257401409e-28\n6.800000000000000000e+02,5.336926437920486942e-24,1.149488348219605082e-28\n6.810000000000000000e+02,4.934431401225119104e-24,1.046386419527580002e-28\n6.820000000000000000e+02,4.562291336899898087e-24,9.525320901839847984e-29\n6.830000000000000000e+02,4.218216963677727722e-24,8.670959082591156264e-29\n6.840000000000000000e+02,3.900091651040660560e-24,7.893228184831719293e-29\n6.850000000000000000e+02,3.605958398416623250e-24,7.185254893303523878e-29\n6.860000000000000000e+02,3.334007796365943579e-24,6.540782386217423321e-29\n6.870000000000000000e+02,3.082566895699583371e-24,5.954115039638144642e-29\n6.880000000000000000e+02,2.850088916054830896e-24,5.420068091540111297e-29\n6.890000000000000000e+02,2.635143730619685658e-24,4.933921820683707603e-29\n6.900000000000000000e+02,2.436409068470863477e-24,4.491379835359523304e-29\n6.910000000000000000e+02,2.252662380404986792e-24,4.088531103372548644e-29\n6.920000000000000000e+02,2.082773318224735573e-24,3.721815387699649019e-29\n6.930000000000000000e+02,1.925696781214499932e-24,3.387991782352277592e-29\n6.940000000000000000e+02,1.780466487030214796e-24,3.084110070376462463e-29\n6.950000000000000000e+02,1.646189027453449921e-24,2.807484650861044566e-29\n6.960000000000000000e+02,1.522038372442641341e-24,2.555670804530773305e-29\n6.970000000000000000e+02,1.407250788672466599e-24,2.326443088167124193e-29\n6.980000000000000000e+02,1.301120141301775108e-24,2.117775666915091107e-29\n6.990000000000000000e+02,1.202993550068039761e-24,1.927824410659045514e-29\n7.000000000000000000e+02,1.112267372986320336e-24,1.754910596242087967e-29\n7.010000000000000000e+02,1.028383492945510211e-24,1.597506071494307944e-29\n7.020000000000000000e+02,9.508258843584797193e-25,1.454219749955357572e-29\n7.030000000000000000e+02,8.791174387451919835e-25,1.323785316935947426e-29\n7.040000000000000000e+02,8.128170297207880141e-25,1.205050038268994740e-29\n7.050000000000000000e+02,7.515167993335889386e-25,1.096964572845741215e-29\n7.060000000000000000e+02,6.948396490592838566e-25,9.985736989039548086e-30\n7.070000000000000000e+02,6.424369200168942526e-25,9.090078721101624389e-30\n7.080000000000000000e+02,5.939862481359099573e-25,8.274755408290804688e-30\n7.090000000000000000e+02,5.491895810802663766e-25,7.532561506655452889e-30\n7.100000000000000000e+02,5.077713447300301053e-25,6.856937764552788663e-30\n7.110000000000000000e+02,4.694767479415486523e-25,6.241913254263920478e-30\n7.120000000000000000e+02,4.340702151574873425e-25,5.682052603010124763e-30\n7.130000000000000000e+02,4.013339372247828841e-25,5.172407957018530245e-30\n7.140000000000000000e+02,3.710665315055253697e-25,4.708475254110659560e-30\n7.150000000000000000e+02,3.430818030383041219e-25,4.286154418367221950e-30\n7.160000000000000000e+02,3.172075991290576891e-25,3.901713125082318274e-30\n7.170000000000000000e+02,2.932847503252364084e-25,3.551753815775693893e-30\n7.180000000000000000e+02,2.711660912585500877e-25,3.233183671752102605e-30\n7.190000000000000000e+02,2.507155553328259536e-25,2.943187280845235977e-30\n7.200000000000000000e+02,2.318073376877828180e-25,2.679201755783622978e-30\n7.210000000000000000e+02,2.143251212896033220e-25,2.438894084284200140e-30\n7.220000000000000000e+02,1.981613613874145195e-25,2.220140510701030700e-30\n7.230000000000000000e+02,1.832166239339395046e-25,2.021007767011117084e-30\n7.240000000000000000e+02,1.693989739004832016e-25,1.839735987263954673e-30\n7.250000000000000000e+02,1.566234097233611439e-25,1.674723154498105604e-30\n7.260000000000000000e+02,1.448113404027062974e-25,1.524510942672408039e-30\n7.270000000000000000e+02,1.338901020369029409e-25,1.387771828487335375e-30\n7.280000000000000000e+02,1.237925108185596967e-25,1.263297359195753912e-30\n7.290000000000000000e+02,1.144564497421889480e-25,1.149987472717678937e-30\n7.300000000000000000e+02,1.058244864811495000e-25,1.046840775674169323e-30\n7.310000000000000000e+02,9.784352008317620867e-26,9.529456934207260372e-31\n7.320000000000000000e+02,9.046445431107550144e-26,8.674724138676056993e-31\n7.330000000000000000e+02,8.364189561908228797e-26,7.896655538890682610e-31\n7.340000000000000000e+02,7.733387390694729881e-26,7.188374835100032522e-31\n7.350000000000000000e+02,7.150158433390660279e-26,6.543622488712276402e-31\n7.360000000000000000e+02,6.610914860427599151e-26,5.956700402669607009e-31\n7.370000000000000000e+02,6.112339425617161910e-26,5.422421563647897577e-31\n7.380000000000000000e+02,5.651365059561083700e-26,4.936064201035921489e-31\n7.390000000000000000e+02,5.225156002065987073e-26,4.493330057568814760e-31\n7.400000000000000000e+02,4.831090357494380465e-26,4.090306402824713083e-31\n7.410000000000000000e+02,4.466743965739352845e-26,3.723431453873974297e-31\n7.420000000000000000e+02,4.129875489602096825e-26,3.389462897479709273e-31\n7.430000000000000000e+02,3.818412626834544164e-26,3.085449235660991000e-31\n7.440000000000000000e+02,3.530439362028842996e-26,2.808703701379828799e-31\n7.450000000000000000e+02,3.264184179931162332e-26,2.556780513828435504e-31\n7.460000000000000000e+02,3.018009167671905100e-26,2.327453263468592805e-31\n7.470000000000000000e+02,2.790399938873490286e-26,2.118695235798443518e-31\n7.480000000000000000e+02,2.579956317651467759e-26,1.928661499954339553e-31\n7.490000000000000000e+02,2.385383725200636131e-26,1.755672603853460954e-31\n7.500000000000000000e+02,2.205485215979065997e-26,1.598199731780079782e-31\n7.510000000000000000e+02,2.039154114499167188e-26,1.454851193243948761e-31\n7.520000000000000000e+02,1.885367207430114028e-26,1.324360123703590878e-31\n7.530000000000000000e+02,1.743178449131537455e-26,1.205573288458042966e-31\n7.540000000000000000e+02,1.611713141896919480e-26,1.097440890759431648e-31\n7.550000000000000000e+02,1.490162555105823422e-26,9.990072940743933023e-32\n7.560000000000000000e+02,1.377778950183393141e-26,9.094025765007047978e-32\n7.570000000000000000e+02,1.273870980762655328e-26,8.278348426998919569e-32\n7.580000000000000000e+02,1.177799439752814181e-26,7.535832254016313165e-32\n7.590000000000000000e+02,1.088973327150856008e-26,6.859915146294336761e-32\n7.600000000000000000e+02,1.006846214407176157e-26,6.244623583450753421e-32\n7.610000000000000000e+02,9.309128829797567593e-27,5.684519832589219466e-32\n7.620000000000000000e+02,8.607062163986219167e-27,5.174653891507052980e-32\n7.630000000000000000e+02,7.957943267214900499e-27,4.710519742296711277e-32\n7.640000000000000000e+02,7.357778977034973260e-27,4.288015528726525503e-32\n7.650000000000000000e+02,6.802877283371752727e-27,3.903407305461121377e-32\n7.660000000000000000e+02,6.289824616512912346e-27,3.553296038751120175e-32\n7.670000000000000000e+02,5.815464847968449300e-27,3.234587566954580383e-32\n7.680000000000000000e+02,5.376879875023699516e-27,2.944465255412432121e-32\n7.690000000000000000e+02,4.971371669546669072e-27,2.680365104010412385e-32\n7.700000000000000000e+02,4.596445680621073726e-27,2.439953087437715407e-32\n7.710000000000000000e+02,4.249795488903133118e-27,2.221104527882928694e-32\n7.720000000000000000e+02,3.929288618300589783e-27,2.021885317870063698e-32\n7.730000000000000000e+02,3.632953417692938516e-27,1.840534827289317675e-32\n7.740000000000000000e+02,3.358966931992657729e-27,1.675450343560273544e-32\n7.750000000000000000e+02,3.105643687935034968e-27,1.525172907415469856e-32\n7.760000000000000000e+02,2.871425325610165078e-27,1.388374419125525792e-32\n7.770000000000000000e+02,2.654871011953614807e-27,1.263845901215612873e-32\n7.780000000000000000e+02,2.454648577223166328e-27,1.150486813942850586e-32\n7.790000000000000000e+02,2.269526319935965075e-27,1.047295329108781641e-32\n7.800000000000000000e+02,2.098365429852634772e-27,9.533594762499862785e-33\n7.810000000000000000e+02,1.940112982397533743e-27,8.678490829602869654e-33\n7.820000000000000000e+02,1.793795461418650420e-27,7.900084381156442745e-33\n7.830000000000000000e+02,1.658512770441743457e-27,7.191496131620481342e-33\n7.840000000000000000e+02,1.533432695577767622e-27,6.546463824420789216e-33\n7.850000000000000000e+02,1.417785786021161554e-27,5.959286888303247640e-33\n7.860000000000000000e+02,1.310860620645815022e-27,5.424776057667376237e-33\n7.870000000000000000e+02,1.211999431580056254e-27,4.938207511640728818e-33\n7.880000000000000000e+02,1.120594057838637920e-27,4.495281126592849213e-33\n7.890000000000000000e+02,1.036082204119687768e-27,4.092082473137624661e-33\n7.900000000000000000e+02,9.579439817519414875e-28,3.725048221767651481e-33\n7.910000000000000000e+02,8.856987105134664822e-28,3.390934651386647628e-33\n7.920000000000000000e+02,8.189019616476471644e-28,3.086788982430492151e-33\n7.930000000000000000e+02,7.571428238860057530e-28,2.809923281228013901e-33\n7.940000000000000000e+02,7.000413756594964637e-28,2.557890704977956177e-33\n7.950000000000000000e+02,6.472463479479832273e-28,2.328463877402816079e-33\n7.960000000000000000e+02,5.984329633906771666e-28,2.119615203971930716e-33\n7.970000000000000000e+02,5.533009383644001096e-28,1.929498952725936403e-33\n7.980000000000000000e+02,5.115726357390943596e-28,1.756434942339581212e-33\n7.990000000000000000e+02,4.729913569470294004e-28,1.598893693263199479e-33\n8.000000000000000000e+02,4.373197628590379814e-28,1.455482910714366314e-33\n8.010000000000000000e+02,4.043384137535137394e-28,1.324935180060662212e-33\n8.020000000000000000e+02,3.738444193966295951e-28,1.206096765849905655e-33\n8.030000000000000000e+02,3.456501909294255508e-28,1.097917415497262405e-33\n8.040000000000000000e+02,3.195822868838699532e-28,9.994410775181379635e-34\n8.050000000000000000e+02,2.954803462289371829e-28,9.097974522776130617e-34\n8.060000000000000000e+02,2.731961018831380141e-28,8.281943005847824371e-34\n8.070000000000000000e+02,2.525924686250185724e-28,7.539104421583075754e-34\n8.080000000000000000e+02,2.335426997906919827e-28,6.862893820858182458e-34\n8.090000000000000000e+02,2.159296075707406840e-28,6.247335089501795808e-34\n8.100000000000000000e+02,1.996448421099938854e-28,5.686988133475150210e-34\n8.110000000000000000e+02,1.845882249754308957e-28,5.176900801212877579e-34\n8.120000000000000000e+02,1.706671328919567601e-28,4.712565118229160047e-34\n8.130000000000000000e+02,1.577959279549815979e-28,4.289877447206915639e-34\n8.140000000000000000e+02,1.458954308146524570e-28,3.905102221477595772e-34\n8.150000000000000000e+02,1.348924335909721896e-28,3.554838931382111445e-34\n8.160000000000000000e+02,1.247192495233881054e-28,3.235992071748699078e-34\n8.170000000000000000e+02,1.153132965844732933e-28,2.945743784894704610e-34\n8.180000000000000000e+02,1.066167124962129127e-28,2.681528957379859143e-34\n8.190000000000000000e+02,9.857599878061978581e-29,2.441012550425745742e-34\n8.200000000000000000e+02,9.114169165497305859e-29,2.222068963655056375e-34\n8.210000000000000000e+02,8.426805774716958938e-29,2.022763249774309772e-34\n8.220000000000000000e+02,7.791281275930591028e-29,1.841334014182595824e-34\n8.230000000000000000e+02,7.203686134881242879e-29,1.676177848378470151e-34\n8.240000000000000000e+02,6.660405662697999031e-29,1.525835159593215533e-34\n8.250000000000000000e+02,6.158097779537819721e-29,1.388977271417303110e-34\n8.260000000000000000e+02,5.693672455228066798e-29,1.264394681420365806e-34\n8.270000000000000000e+02,5.264272700433776333e-29,1.150986371989218221e-34\n8.280000000000000000e+02,4.867256991414386560e-29,1.047750079917082187e-34\n8.290000000000000000e+02,4.500183020252696075e-29,9.537734387497470339e-35\n8.300000000000000000e+02,4.160792670593298042e-29,8.682259156081464918e-35\n8.310000000000000000e+02,3.846998126465262808e-29,7.903514712275201795e-35\n8.320000000000000000e+02,3.556869028736526528e-29,7.194618783453109955e-35\n8.330000000000000000e+02,3.288620600189771820e-29,6.549306393878441583e-35\n8.340000000000000000e+02,3.040602666169606462e-29,5.961874497026431414e-35\n8.350000000000000000e+02,2.811289503259922733e-29,5.427131574042278005e-35\n8.360000000000000000e+02,2.599270453543227688e-29,4.940351752902059485e-35\n8.370000000000000000e+02,2.403241246704915250e-29,4.497233042799327313e-35\n8.380000000000000000e+02,2.221995976598263215e-29,4.093859314646003609e-35\n8.390000000000000000e+02,2.054419682912935427e-29,3.726665691685376028e-35\n8.400000000000000000e+02,1.899481492312007656e-29,3.392407044350459229e-35\n8.410000000000000000e+02,1.756228276843644666e-29,3.088129310937455179e-35\n8.420000000000000000e+02,1.623778790616700691e-29,2.811143390635441484e-35\n8.430000000000000000e+02,1.501318248670570874e-29,2.559001378188561350e-35\n8.440000000000000000e+02,1.388093314690481776e-29,2.329474930160254272e-35\n8.450000000000000000e+02,1.283407466734408576e-29,2.120535571608930342e-35\n8.460000000000000000e+02,1.186616712462816025e-29,1.930336769131661993e-35\n8.470000000000000000e+02,1.097125627513158468e-29,1.757197611844119066e-35\n8.480000000000000000e+02,1.014383692648236147e-29,1.599587956074451391e-35\n8.490000000000000000e+02,9.378819071458758403e-30,1.456114902485643287e-35\n8.500000000000000000e+02,8.671496575967033554e-30,1.325510486115536929e-35\n8.510000000000000000e+02,8.017518228476964169e-30,1.206620470543237802e-35\n8.520000000000000000e+02,7.412860972823704906e-30,1.098394147149039642e-35\n8.530000000000000000e+02,6.853805159711047916e-30,9.998750493169397887e-36\n8.540000000000000000e+02,6.336911664672461488e-30,9.101924995153059850e-36\n8.550000000000000000e+02,5.859000731727001833e-30,8.285539145514954632e-36\n8.560000000000000000e+02,5.417132412583876048e-30,7.542378009972413328e-36\n8.570000000000000000e+02,5.008588481062872492e-30,6.865873788805688541e-36\n8.580000000000000000e+02,4.630855711475978798e-30,6.250047772928058415e-36\n8.590000000000000000e+02,4.281610418103044176e-30,5.689457506133094526e-36\n8.600000000000000000e+02,3.958704160653992273e-30,5.179148686559455718e-36\n8.610000000000000000e+02,3.660150527782627915e-30,4.714611382293479012e-36\n8.620000000000000000e+02,3.384112917347747967e-30,4.291740174159290278e-36\n8.630000000000000000e+02,3.128893238250997222e-30,3.906797873451164519e-36\n8.640000000000000000e+02,2.892921464348054106e-30,3.556382493959390638e-36\n8.650000000000000000e+02,2.674745976172619131e-30,3.237397186399152257e-36\n8.660000000000000000e+02,2.473024631058900199e-30,2.947022869533005224e-36\n8.670000000000000000e+02,2.286516506728380528e-30,2.682693316111304678e-36\n8.680000000000000000e+02,2.114074267550971371e-30,2.442072473447957930e-36\n8.690000000000000000e+02,1.954637106519735833e-30,2.223033818199171963e-36\n8.700000000000000000e+02,1.807224219520790583e-30,2.023641562889310556e-36\n8.710000000000000000e+02,1.670928771754389933e-30,1.842133548094404125e-36\n8.720000000000000000e+02,1.544912319190239323e-30,1.676905669089801227e-36\n8.730000000000000000e+02,1.428399650740224776e-30,1.526497699330453716e-36\n8.740000000000000000e+02,1.320674019418931298e-30,1.389580385476281690e-36\n8.750000000000000000e+02,1.221072733155799623e-30,1.264943699913436125e-36\n8.760000000000000000e+02,1.128983078135034210e-30,1.151486146950928887e-36\n8.770000000000000000e+02,1.043838549585109339e-30,1.048205028184773518e-36\n8.780000000000000000e+02,9.651153668306986622e-31,9.541875809980239400e-37\n8.790000000000000000e+02,8.923292511691324550e-31,8.686029118822025415e-37\n8.800000000000000000e+02,8.250324467496990999e-31,7.906946532893442583e-37\n8.810000000000000000e+02,7.628109661293275618e-31,7.197742791186414593e-37\n8.820000000000000000e+02,7.052820435602809315e-31,6.552150197620942835e-37\n8.830000000000000000e+02,6.520917803431691339e-31,5.964463229326818285e-37\n8.840000000000000000e+02,6.029129677605065505e-31,5.429488113216523590e-37\n8.850000000000000000e+02,5.574430741980590666e-31,4.942496925224019445e-37\n8.860000000000000000e+02,5.154023840714831187e-31,4.499185806556108201e-37\n8.870000000000000000e+02,4.765322771095921522e-31,4.095636927684714212e-37\n8.880000000000000000e+02,4.405936374088601035e-31,3.728283863931978805e-37\n8.890000000000000000e+02,4.073653824723525165e-31,3.393880076648631979e-37\n8.900000000000000000e+02,3.766431031841064397e-31,3.089470221434478561e-37\n8.910000000000000000e+02,3.482378063525791409e-31,2.812364029832055107e-37\n8.920000000000000000e+02,3.219747520877356793e-31,2.560112533669569492e-37\n8.930000000000000000e+02,2.976923788596311747e-31,2.330486421931450719e-37\n8.940000000000000000e+02,2.752413096259103481e-31,2.121456338882895093e-37\n8.950000000000000000e+02,2.544834329141753876e-31,1.931174949329411926e-37\n8.960000000000000000e+02,2.352910532063760773e-31,1.757960612510807811e-37\n8.970000000000000000e+02,2.175461053986853652e-31,1.600282520344676550e-37\n8.980000000000000000e+02,2.011394285044300201e-31,1.456747168676926092e-37\n8.990000000000000000e+02,1.859700941322077993e-31,1.326086041976637655e-37\n9.000000000000000000e+02,1.719447856081609306e-31,1.207144402636736412e-37\n9.010000000000000000e+02,1.589772239229948045e-31,1.098871085804608351e-37\n9.020000000000000000e+02,1.469876369723544675e-31,1.000309209552585452e-37\n9.030000000000000000e+02,1.359022688255152126e-31,9.105877182882339483e-38\n9.040000000000000000e+02,1.256529260035410170e-31,8.289136846678040420e-38\n9.050000000000000000e+02,1.161765579758083117e-31,7.545653019801266059e-38\n9.060000000000000000e+02,1.074148692942175680e-31,6.868855050698459417e-38\n9.070000000000000000e+02,9.931396097908367412e-32,6.252761634240775257e-38\n9.080000000000000000e+02,9.182399895063747150e-32,5.691927951028429750e-38\n9.090000000000000000e+02,8.489890746641799606e-32,5.181397547970424757e-38\n9.100000000000000000e+02,7.849608567871422520e-32,4.716658534875305103e-38\n9.110000000000000000e+02,7.257614556839023892e-32,4.293603709934701399e-38\n9.120000000000000000e+02,6.710266964295809872e-32,3.908494261701392466e-38\n9.130000000000000000e+02,6.204198690834261001e-32,3.557926726773958565e-38\n9.140000000000000000e+02,5.736296573617618961e-32,3.238802911170748755e-38\n9.150000000000000000e+02,5.303682235243271281e-32,2.948302509568390983e-38\n9.160000000000000000e+02,4.903694376927127876e-32,2.683858180424183880e-38\n9.170000000000000000e+02,4.533872407083119257e-32,2.443132856704106088e-38\n9.180000000000000000e+02,4.191941304586618393e-32,2.223999091697112780e-38\n9.190000000000000000e+02,3.875797623604630185e-32,2.024520257380593790e-38\n9.200000000000000000e+02,3.583496553900497159e-32,1.842933429175423034e-38\n9.210000000000000000e+02,3.313239957011412386e-32,1.677633805831431770e-38\n9.220000000000000000e+02,3.063365304701727051e-32,1.527160526752046479e-38\n9.230000000000000000e+02,2.832335451644997599e-32,1.390183761416124558e-38\n9.240000000000000000e+02,2.618729179419979037e-32,1.265492956798291856e-38\n9.250000000000000000e+02,2.421232453649765919e-32,1.151986138922170199e-38\n9.260000000000000000e+02,2.238630340501769200e-32,1.048660173997595477e-38\n9.270000000000000000e+02,2.069799532820892006e-32,9.546019030728663967e-39\n9.280000000000000000e+02,1.913701439919413110e-32,8.689800718535038853e-39\n9.290000000000000000e+02,1.769375798514394401e-32,7.910379843657925574e-39\n9.300000000000000000e+02,1.635934765508817567e-32,7.200868155409146896e-39\n9.310000000000000000e+02,1.512557456277775160e-32,6.554995236184238852e-39\n9.320000000000000000e+02,1.398484894860657941e-32,5.967053085692284113e-39\n9.330000000000000000e+02,1.293015344994755589e-32,5.431845675634227522e-39\n9.340000000000000000e+02,1.195499993268439537e-32,4.944643029010886839e-39\n9.350000000000000000e+02,1.105338957837840392e-32,4.501139418231209030e-39\n9.360000000000000000e+02,1.021977598154368287e-32,4.097415312588765337e-39\n9.370000000000000000e+02,9.449031030014564437e-33,3.729902738812418844e-39\n9.380000000000000000e+02,8.736413358513810084e-33,3.395353748558774285e-39\n9.390000000000000000e+02,8.077539181359001593e-33,3.090811714174270663e-39\n9.400000000000000000e+02,7.468355324877764354e-33,2.813585199047896038e-39\n9.410000000000000000e+02,6.905114293638870231e-33,2.561224171630389232e-39\n9.420000000000000000e+02,6.384351217113014805e-33,2.331498352907031986e-39\n9.430000000000000000e+02,5.902862534947657785e-33,2.122377505967352743e-39\n9.440000000000000000e+02,5.457686289734612648e-33,1.932013493477149723e-39\n9.450000000000000000e+02,5.046083906038599333e-33,1.758723944483442367e-39\n9.460000000000000000e+02,4.665523343596199961e-33,1.600977386204772915e-39\n9.470000000000000000e+02,4.313663521050963525e-33,1.457379709407351128e-39\n9.480000000000000000e+02,3.988339914403457273e-33,1.326661847752433777e-39\n9.490000000000000000e+02,3.687551241583178968e-33,1.207668562229142603e-39\n9.500000000000000000e+02,3.409447151230518935e-33,1.099348231553852754e-39\n9.510000000000000000e+02,3.152316839953447933e-33,1.000743558306896967e-39\n9.520000000000000000e+02,2.914578528037206680e-33,9.109831086708804556e-40\n9.530000000000000000e+02,2.694769728864239262e-33,8.292736110015104642e-40\n9.540000000000000000e+02,2.491538252185408754e-33,7.548929451686845428e-40\n9.550000000000000000e+02,2.303633885897770859e-33,6.871837607098345049e-40\n9.560000000000000000e+02,2.129900705157450427e-33,6.255476673951398543e-40\n9.570000000000000000e+02,1.969269961516585235e-33,5.694399468626737697e-40\n9.580000000000000000e+02,1.820753508340124665e-33,5.183647385869608295e-40\n9.590000000000000000e+02,1.683437722058050316e-33,4.718706576360449506e-40\n9.600000000000000000e+02,1.556477881858702240e-33,4.295468054884350313e-40\n9.610000000000000000e+02,1.439092973248589277e-33,3.910191386547981467e-40\n9.620000000000000000e+02,1.330560883512426761e-33,3.559471630116792656e-40\n9.630000000000000000e+02,1.230213959517090408e-33,3.240209246328410711e-40\n9.640000000000000000e+02,1.137434900532728053e-33,2.949582705242024195e-40\n9.650000000000000000e+02,1.051652960805101525e-33,2.685023550538027927e-40\n9.660000000000000000e+02,9.723404385184094128e-34,2.444193700394029716e-40\n9.670000000000000000e+02,8.990094295501997828e-34,2.224964784330793408e-40\n9.680000000000000000e+02,8.312088260482992356e-34,2.025399333413758195e-40\n9.690000000000000000e+02,7.685215413661154724e-34,1.843733657576398440e-40\n9.700000000000000000e+02,7.105619442850117581e-34,1.678362258740587310e-40\n9.710000000000000000e+02,6.569734867400094168e-34,1.527823641982910864e-40\n9.720000000000000000e+02,6.074265104552259185e-34,1.390787399350543868e-40\n9.730000000000000000e+02,5.616162189964107472e-34,1.266042452178446558e-40\n9.740000000000000000e+02,5.192608027651664957e-34,1.152486347997170745e-40\n9.750000000000000000e+02,4.800997054005032438e-34,1.049115517441324658e-40\n9.760000000000000000e+02,4.438920209232391951e-34,9.550164050523578916e-41\n9.770000000000000000e+02,4.104150117629105159e-34,8.693573955931178385e-41\n9.780000000000000000e+02,3.794627385507292439e-34,7.913814645215695952e-41\n9.790000000000000000e+02,3.508447932494261528e-34,7.203994876710315443e-41\n9.800000000000000000e+02,3.243851278266548579e-34,6.557841510104508388e-41\n9.810000000000000000e+02,2.999209712663701248e-34,5.969644066610914388e-41\n9.820000000000000000e+02,2.773018282559234765e-34,5.434204261739696042e-41\n9.830000000000000000e+02,2.563885533892307176e-34,4.946790064667117179e-41\n9.840000000000000000e+02,2.370524951907461155e-34,4.503093878192809411e-41\n9.850000000000000000e+02,2.191747046945905683e-34,4.099194469693311917e-41\n9.860000000000000000e+02,2.026452037102916178e-34,3.731522316631791997e-41\n9.870000000000000000e+02,1.873623082737024864e-34,3.396828060358615540e-41\n9.880000000000000000e+02,1.732320031212615738e-34,3.092153789409649900e-41\n9.890000000000000000e+02,1.601673633395173984e-34,2.814806898513105893e-41\n9.900000000000000000e+02,1.480880196321207522e-34,2.562336292280520167e-41\n9.910000000000000000e+02,1.369196639147793313e-34,2.332510723277707171e-41\n9.920000000000000000e+02,1.265935921967728856e-34,2.123299073035876659e-41\n9.930000000000000000e+02,1.170462819369582923e-34,1.932852401732907959e-41\n9.940000000000000000e+02,1.082190012743406769e-34,1.759487607905881422e-41\n9.950000000000000000e+02,1.000574477292968590e-34,1.601672553785695053e-41\n9.960000000000000000e+02,9.251141415287310800e-35,1.458012524796127779e-41\n9.970000000000000000e+02,8.553447986919458913e-35,1.327237903551441394e-41\n9.980000000000000000e+02,7.908372511097795828e-35,1.208192949419239551e-41\n9.990000000000000000e+02,7.311946699147700090e-35,1.099825584486695818e-41\n1.000000000000000000e+03,6.760501538862802733e-35,1.001178095661731519e-41\n1.001000000000000000e+03,6.250644723968393326e-35,9.113786707377605693e-42\n1.002000000000000000e+03,5.779239785787638073e-35,8.296336936204469864e-42\n1.003000000000000000e+03,5.343386798734273050e-35,7.552207306246628279e-42\n1.004000000000000000e+03,4.940404540940232861e-35,6.874821458567440406e-42\n1.005000000000000000e+03,4.567814000274970368e-35,6.258192892571609275e-42\n1.006000000000000000e+03,4.223323124291523880e-35,5.696872059393802570e-42\n1.007000000000000000e+03,3.904812720286346753e-35,5.185898200681009183e-42\n1.008000000000000000e+03,3.610323418733888627e-35,4.720755507134884863e-42\n1.009000000000000000e+03,3.338043619900550636e-35,4.297333209359593072e-42\n1.010000000000000000e+03,3.086298349488691546e-35,3.911889248310771831e-42\n1.011000000000000000e+03,2.853538954754662363e-35,3.561017204279045056e-42\n1.012000000000000000e+03,2.638333577715015759e-35,3.241616192137177362e-42\n1.013000000000000000e+03,2.439358346834616703e-35,2.950863456795169159e-42\n1.014000000000000000e+03,2.255389233011711893e-35,2.686189426672462912e-42\n1.015000000000000000e+03,2.085294519760048870e-35,2.445255004717656520e-42\n1.016000000000000000e+03,1.928027841267392914e-35,2.225930896282209984e-42\n1.017000000000000000e+03,1.782621745502833229e-35,2.026278791154475206e-42\n1.018000000000000000e+03,1.648181742775415149e-35,1.844534233448141508e-42\n1.019000000000000000e+03,1.523880803132437187e-35,1.679091027954551990e-42\n1.020000000000000000e+03,1.408954268747771059e-35,1.528487045148018055e-42\n1.021000000000000000e+03,1.302695150002516939e-35,1.391391299393301732e-42\n1.022000000000000000e+03,1.204449776321202306e-35,1.266592186157457772e-42\n1.023000000000000000e+03,1.113613775008997282e-35,1.152986774270200066e-42\n1.024000000000000000e+03,1.029628353352834750e-35,1.049571058601775563e-42\n1.025000000000000000e+03,9.519768611155197109e-36,9.554310870146152215e-43\n1.026000000000000000e+03,8.801816122761713036e-36,8.697348831721796606e-43\n1.027000000000000000e+03,8.138009464655039267e-36,7.917250938214075538e-43\n1.028000000000000000e+03,7.524265120189315940e-36,7.207122955679180846e-43\n1.029000000000000000e+03,6.956807539335710927e-36,6.560689019918156983e-43\n1.030000000000000000e+03,6.432145912761310054e-36,5.972236172571005201e-43\n1.031000000000000000e+03,5.947052697536977159e-36,5.436563871977430254e-43\n1.032000000000000000e+03,5.498543762372166775e-36,4.948938032597342611e-43\n1.033000000000000000e+03,5.083860030237156132e-36,4.505049186809247109e-43\n1.034000000000000000e+03,4.700450505443042596e-36,4.100974399333655548e-43\n1.035000000000000000e+03,4.345956580769412490e-36,3.733142597695323249e-43\n1.036000000000000000e+03,4.018197528101134541e-36,3.398303012326004080e-43\n1.037000000000000000e+03,3.715157083318025444e-36,3.093496447393544902e-43\n1.038000000000000000e+03,3.434971042911981797e-36,2.816029128457928077e-43\n1.039000000000000000e+03,3.175915796030412905e-36,2.563448895829553354e-43\n1.040000000000000000e+03,2.936397721398185870e-36,2.333523533234267206e-43\n1.041000000000000000e+03,2.714943383892501636e-36,2.124221040262207027e-43\n1.042000000000000000e+03,2.510190470462547971e-36,1.933691674254787449e-43\n1.043000000000000000e+03,2.320879409635008348e-36,1.760251602922044574e-43\n1.044000000000000000e+03,2.145845623051570084e-36,1.602368023218454354e-43\n1.045000000000000000e+03,1.984012361371989080e-36,1.458645614962516184e-43\n1.046000000000000000e+03,1.834384080472249585e-36,1.327814209482224887e-43\n1.047000000000000000e+03,1.696040317189895265e-36,1.208717564305853117e-43\n1.048000000000000000e+03,1.568130026942346078e-36,1.100303144693099584e-43\n1.049000000000000000e+03,1.449866348385228169e-36,1.001612821698982602e-43\n1.050000000000000000e+03,1.340521762904296915e-36,9.117744045634221948e-44\n1.051000000000000000e+03,1.239423619164228407e-36,8.299939325924743137e-44\n1.052000000000000000e+03,1.145949995182454497e-36,7.555486584098360949e-44\n1.053000000000000000e+03,1.059525872473021200e-36,6.877806605668083973e-44\n1.054000000000000000e+03,9.796195987251581561e-37,6.260910290613306258e-44\n1.055000000000000000e+03,9.057396172559019734e-37,5.699345723795608937e-44\n1.056000000000000000e+03,8.374314431177779922e-37,5.188149992828817988e-44\n1.057000000000000000e+03,7.742748672593237584e-37,4.722805327584752699e-44\n1.058000000000000000e+03,7.158813715394728108e-37,4.299199173711936601e-44\n1.059000000000000000e+03,6.618917386938761010e-37,3.913587847309743079e-44\n1.060000000000000000e+03,6.119738425503172036e-37,3.562563449551996487e-44\n1.061000000000000000e+03,5.658206048995749158e-37,3.243023748862202422e-44\n1.062000000000000000e+03,5.231481064529283180e-37,2.952144764469198922e-44\n1.063000000000000000e+03,4.836938402656074424e-37,2.687355809047210397e-44\n1.064000000000000000e+03,4.472150968818212458e-37,2.446316769875000200e-44\n1.065000000000000000e+03,4.134874712673501194e-37,2.226897427733435889e-44\n1.066000000000000000e+03,3.823034823447559437e-37,2.027158630768487069e-44\n1.067000000000000000e+03,3.534712966391829254e-37,1.845335156941529315e-44\n1.068000000000000000e+03,3.268135481829441865e-37,1.679820113610669937e-44\n1.069000000000000000e+03,3.021662474193790013e-37,1.529150736372392481e-44\n1.070000000000000000e+03,2.793777723939404585e-37,1.391995461658209339e-44\n1.071000000000000000e+03,2.583079360265922263e-37,1.267142158838928891e-44\n1.072000000000000000e+03,2.388271237277760316e-37,1.153487417835569008e-44\n1.073000000000000000e+03,2.208154960527827717e-37,1.050026797564799748e-44\n1.074000000000000000e+03,2.041622514895489361e-37,9.558459490377897819e-45\n1.075000000000000000e+03,1.887649448448078103e-37,8.701125346618185579e-45\n1.076000000000000000e+03,1.745288570354904597e-37,7.920688723300671725e-45\n1.077000000000000000e+03,1.613664124086041343e-37,7.210252392905265454e-45\n1.078000000000000000e+03,1.491966400050889882e-37,6.563537766161831903e-45\n1.079000000000000000e+03,1.379446754535450240e-37,5.974829404061066144e-45\n1.080000000000000000e+03,1.275413004296550090e-37,5.438924506792123370e-45\n1.081000000000000000e+03,1.179225168481809575e-37,4.951086933206369238e-45\n1.082000000000000000e+03,1.090291531681471067e-37,4.507005344449021237e-45\n1.083000000000000000e+03,1.008065003892990739e-37,4.102755101845242844e-45\n1.084000000000000000e+03,9.320397550062392225e-38,3.734763582308372152e-45\n1.085000000000000000e+03,8.617481031057527507e-38,3.399778604738910769e-45\n1.086000000000000000e+03,7.967576374479889964e-38,3.094839688378993046e-45\n1.087000000000000000e+03,7.366685584149134574e-38,2.817251889112703188e-45\n1.088000000000000000e+03,6.811112180804567333e-38,2.564561982487170728e-45\n1.089000000000000000e+03,6.297438462600359019e-38,2.334536782967586942e-45\n1.090000000000000000e+03,5.822504480546260802e-38,2.125143407820066847e-45\n1.091000000000000000e+03,5.383388599558148529e-38,1.934531311200957977e-45\n1.092000000000000000e+03,4.977389525535184700e-38,1.761015929675914748e-45\n1.093000000000000000e+03,4.602009687901924390e-38,1.603063794634119426e-45\n1.094000000000000000e+03,4.254939875388994717e-38,1.459278980025829132e-45\n1.095000000000000000e+03,3.934045030537296728e-38,1.328390765653394699e-45\n1.096000000000000000e+03,3.637351115538501988e-38,1.209242406987852716e-45\n1.097000000000000000e+03,3.363032968614047661e-38,1.100780912263065569e-45\n1.098000000000000000e+03,3.109403076230267998e-38,1.002047736500578569e-45\n1.099000000000000000e+03,2.874901192079222031e-38,9.121703102224456452e-46\n1.100000000000000000e+03,2.658084738964973458e-38,8.303543279854836481e-46\n1.101000000000000000e+03,2.457619934551091144e-38,7.558767285860054775e-46\n1.102000000000000000e+03,2.272273586377374787e-38,6.880793048962855044e-46\n1.103000000000000000e+03,2.100905505672264293e-38,6.263628868588608935e-46\n1.104000000000000000e+03,1.942461493292646734e-38,5.701820462298343873e-46\n1.105000000000000000e+03,1.795966854643126668e-38,5.190402762737335447e-46\n1.106000000000000000e+03,1.660520403680829429e-38,4.724856038096364830e-46\n1.107000000000000000e+03,1.535288919119973446e-38,4.301065948293041810e-46\n1.108000000000000000e+03,1.419502018733182491e-38,3.915287183865013836e-46\n1.109000000000000000e+03,1.312447420217537208e-38,3.564110366227051206e-46\n1.110000000000000000e+03,1.213466559471968464e-38,3.244431916768754828e-46\n1.111000000000000000e+03,1.121950539331053406e-38,2.953426628505587689e-46\n1.112000000000000000e+03,1.037336383833276528e-38,2.688522697882086962e-46\n1.113000000000000000e+03,9.591035749810219352e-39,2.447378996066160806e-46\n1.114000000000000000e+03,8.867708506879308768e-39,2.227864378866624130e-46\n1.115000000000000000e+03,8.198932442154192336e-39,2.028038852421609469e-46\n1.116000000000000000e+03,7.580593468860451350e-39,1.846136428207504055e-46\n1.117000000000000000e+03,7.008887772349061563e-39,1.680549515846344886e-46\n1.118000000000000000e+03,6.480298410299635722e-39,1.529814715781114102e-46\n1.119000000000000000e+03,5.991573677667464604e-39,1.392599886259127329e-46\n1.120000000000000000e+03,5.539707103281025758e-39,1.267692370326490169e-46\n1.121000000000000000e+03,5.121918955036345778e-39,1.153988278787628974e-46\n1.122000000000000000e+03,4.735639139914676575e-39,1.050482734416285933e-46\n1.123000000000000000e+03,4.378491393628988366e-39,9.562609912000667354e-47\n1.124000000000000000e+03,4.048278662640779764e-39,8.704903501332066380e-47\n1.125000000000000000e+03,3.742969588621122079e-39,7.924128001123369364e-47\n1.126000000000000000e+03,3.460686012213266565e-39,7.213383188978340420e-47\n1.127000000000000000e+03,3.199691419224358624e-39,6.566387749372407347e-47\n1.128000000000000000e+03,2.958380258170345798e-39,5.977423761569817987e-47\n1.129000000000000000e+03,2.735268063460203845e-39,5.441286166628661367e-47\n1.130000000000000000e+03,2.528982323459830352e-39,4.953236766899180834e-47\n1.131000000000000000e+03,2.338254037259312273e-39,4.508962351480788545e-47\n1.132000000000000000e+03,2.161909908203531083e-39,4.104536577563663624e-47\n1.133000000000000000e+03,1.998865126163508089e-39,3.736385270776429989e-47\n1.134000000000000000e+03,1.848116694146955133e-39,3.401254837875425705e-47\n1.135000000000000000e+03,1.708737258196217619e-39,3.096183512619142232e-47\n1.136000000000000000e+03,1.579869402616714752e-39,2.818475180707874237e-47\n1.137000000000000000e+03,1.460720375442203246e-39,2.565675552463144416e-47\n1.138000000000000000e+03,1.350557211689787892e-39,2.335550472668623960e-47\n1.139000000000000000e+03,1.248702224404252854e-39,2.126066175883286538e-47\n1.140000000000000000e+03,1.154528835754555341e-39,1.935371312729657205e-47\n1.141000000000000000e+03,1.067457722536454658e-39,1.761780588311537219e-47\n1.142000000000000000e+03,9.869532523698185934e-40,1.603759868163815629e-47\n1.143000000000000000e+03,9.125201886673418545e-40,1.459912620105430705e-47\n1.144000000000000000e+03,8.437006441045345636e-40,1.328967572173608989e-47\n1.145000000000000000e+03,7.800712638500358924e-40,1.209767477564150542e-47\n1.146000000000000000e+03,7.212406212282063358e-40,1.101258887286633623e-47\n1.147000000000000000e+03,6.668468097930659571e-40,1.002482840148483803e-47\n1.148000000000000000e+03,6.165552170008657624e-40,9.125663877894433339e-48\n1.149000000000000000e+03,5.700564657855207087e-40,8.307148798673950809e-48\n1.150000000000000000e+03,5.270645113743677433e-40,7.562049412149997490e-48\n1.151000000000000000e+03,4.873148816363394431e-40,6.883780789014581877e-48\n1.152000000000000000e+03,4.505630501378289329e-40,6.266348627009864281e-48\n1.153000000000000000e+03,4.165829318978106003e-40,5.704296275368399098e-48\n1.154000000000000000e+03,3.851654925886431071e-40,5.192656510831264355e-48\n1.155000000000000000e+03,3.561174626267297615e-40,4.726907639056197828e-48\n1.156000000000000000e+03,3.292601482426768554e-40,4.302933533454721846e-48\n1.157000000000000000e+03,3.044283322169561332e-40,3.916987258296842885e-48\n1.158000000000000000e+03,2.814692575187993490e-40,3.565657954595743560e-48\n1.159000000000000000e+03,2.602416875960293560e-40,3.245840696122217641e-48\n1.160000000000000000e+03,2.406150375349817053e-40,2.954709049145916525e-48\n1.161000000000000000e+03,2.224685707457885200e-40,2.689690093397004971e-48\n1.162000000000000000e+03,2.056906562312361624e-40,2.448441683491326689e-48\n1.163000000000000000e+03,1.901780818701866208e-40,2.228831749864005861e-48\n1.164000000000000000e+03,1.758354194911236744e-40,2.028919456279728985e-48\n1.165000000000000000e+03,1.625744378299270487e-40,1.846938047397074051e-48\n1.166000000000000000e+03,1.503135597606433782e-40,1.681279234799040396e-48\n1.167000000000000000e+03,1.389773604602760513e-40,1.530478983499316984e-48\n1.168000000000000000e+03,1.284961034204872585e-40,1.393204573309965481e-48\n1.169000000000000000e+03,1.188053114519196199e-40,1.268242820723870376e-48\n1.170000000000000000e+03,1.098453700420707826e-40,1.154489357220772068e-48\n1.171000000000000000e+03,1.015611606267499383e-40,1.050938869242159647e-48\n1.172000000000000000e+03,9.390172151909528269e-41,9.566762135796647142e-49\n1.173000000000000000e+03,8.681993441031205741e-41,8.708683296575476033e-49\n1.174000000000000000e+03,8.027223451359380318e-41,7.927568772330335157e-49\n1.175000000000000000e+03,7.421834256811020741e-41,7.216515344488440799e-49\n1.176000000000000000e+03,6.862101705446532303e-41,6.569238970086990467e-49\n1.177000000000000000e+03,6.344582509731894028e-41,5.980019245586195412e-49\n1.178000000000000000e+03,5.866093064584860716e-41,5.443648851932122512e-49\n1.179000000000000000e+03,5.423689862900726534e-41,4.955387534080934686e-49\n1.180000000000000000e+03,5.014651388080951721e-41,4.510920208273368169e-49\n1.181000000000000000e+03,4.636461372172395160e-41,4.106318826824656938e-49\n1.182000000000000000e+03,4.286793316628395778e-41,3.738007663405119852e-49\n1.183000000000000000e+03,3.963496180467390731e-41,3.402731712013761238e-49\n1.184000000000000000e+03,3.664581147787849158e-41,3.097527920367248756e-49\n1.185000000000000000e+03,3.388209393237937795e-41,2.819699003473982034e-49\n1.186000000000000000e+03,3.132680770176356271e-41,2.566789605967338059e-49\n1.187000000000000000e+03,2.896423351938791925e-41,2.336564602528419240e-49\n1.188000000000000000e+03,2.677983761870530332e-41,2.126989344625771247e-49\n1.189000000000000000e+03,2.476018232639109931e-41,1.936211678999193048e-49\n1.190000000000000000e+03,2.289284339827068962e-41,1.762545578973020407e-49\n1.191000000000000000e+03,2.116633358952059010e-41,1.604456243938725513e-49\n1.192000000000000000e+03,1.957003198898002584e-41,1.460546535320736658e-49\n1.193000000000000000e+03,1.809411868285573873e-41,1.329544629151573040e-49\n1.194000000000000000e+03,1.672951434589494838e-41,1.210292776133701113e-49\n1.195000000000000000e+03,1.546782438841264787e-41,1.101737069853883096e-49\n1.196000000000000000e+03,1.430128731558071510e-41,1.002918132724698152e-49\n1.197000000000000000e+03,1.322272698130748805e-41,9.129626373390601447e-50\n1.198000000000000000e+03,1.222550844298574732e-41,8.310755883061585162e-50\n1.199000000000000000e+03,1.130349714554392308e-41,7.565332963586734405e-50\n1.200000000000000000e+03,1.045102118371395157e-41,6.886769826386334520e-50\n1.201000000000000000e+03,9.662836410366824656e-42,6.269069566389639054e-50\n1.202000000000000000e+03,8.934094176271687532e-42,5.706773163472366095e-50\n1.203000000000000000e+03,8.260311502827311821e-42,5.194911237535275516e-50\n1.204000000000000000e+03,7.637343504276291641e-42,4.728960130850896776e-50\n1.205000000000000000e+03,7.061357889753403644e-42,4.304801929548942513e-50\n1.206000000000000000e+03,6.528811388313783674e-42,3.918688070925625175e-50\n1.207000000000000000e+03,6.036427951913978885e-42,3.567206214949731258e-50\n1.208000000000000000e+03,5.581178602260014764e-42,3.247250087188091058e-50\n1.209000000000000000e+03,5.160262797545429561e-42,2.955992026631871362e-50\n1.210000000000000000e+03,4.771091204454247197e-42,2.690857995811972209e-50\n1.211000000000000000e+03,4.411269769448325635e-42,2.449504832350772243e-50\n1.212000000000000000e+03,4.078584991349915988e-42,2.229799540907893572e-50\n1.213000000000000000e+03,3.770990304622687558e-42,2.029800442508804614e-50\n1.214000000000000000e+03,3.486593489584656121e-42,1.847740014661312268e-50\n1.215000000000000000e+03,3.223645032105235821e-42,1.682009270606279604e-50\n1.216000000000000000e+03,2.980527361179367504e-42,1.531143539652189151e-50\n1.217000000000000000e+03,2.755744898171170466e-42,1.393809522924683849e-50\n1.218000000000000000e+03,2.547914856514354126e-42,1.268793510134789778e-50\n1.219000000000000000e+03,2.355758735271483920e-42,1.154990653229431911e-50\n1.220000000000000000e+03,2.178094454223595720e-42,1.051395202128384820e-50\n1.221000000000000000e+03,2.013829082107989290e-42,9.570916162548369746e-51\n1.222000000000000000e+03,1.861952113270282839e-42,8.712464733060750609e-51\n1.223000000000000000e+03,1.721529251371574234e-42,7.931011037570019468e-51\n1.224000000000000000e+03,1.591696661909674707e-42,7.219648860025850346e-51\n1.225000000000000000e+03,1.471655658198032864e-42,6.572091428842926260e-51\n1.226000000000000000e+03,1.360667788112228508e-42,5.982615856599344362e-51\n1.227000000000000000e+03,1.258050291379449365e-42,5.446012563147780272e-51\n1.228000000000000000e+03,1.163171899465423879e-42,4.957539235156965947e-51\n1.229000000000000000e+03,1.075448952221516062e-42,4.512878915195738464e-51\n1.230000000000000000e+03,9.943418074025931253e-43,4.108101849964106844e-51\n1.231000000000000000e+03,9.193515209683241579e-43,3.739630760500199872e-51\n1.232000000000000000e+03,8.500167777462988439e-43,3.404209227432248563e-51\n1.233000000000000000e+03,7.859110535752247631e-43,3.098872911876638707e-51\n1.234000000000000000e+03,7.266399914709318142e-43,2.820923357641669206e-51\n1.235000000000000000e+03,6.718389756740290894e-43,2.567904143209707465e-51\n1.236000000000000000e+03,6.211708886556355401e-43,2.337579172738094629e-51\n1.237000000000000000e+03,5.743240372830803646e-43,2.127912914221501551e-51\n1.238000000000000000e+03,5.310102353878950723e-43,1.937052410167941035e-51\n1.239000000000000000e+03,4.909630309408862943e-43,1.763310901804533722e-51\n1.240000000000000000e+03,4.539360669283184965e-43,1.605152922090087905e-51\n1.241000000000000000e+03,4.197015658459180569e-43,1.461180725791215455e-51\n1.242000000000000000e+03,3.880489284878391323e-43,1.330121936696038743e-51\n1.243000000000000000e+03,3.587834384107162071e-43,1.210818302795503026e-51\n1.244000000000000000e+03,3.317250641032248697e-43,1.102215460054932700e-51\n1.245000000000000000e+03,3.067073514924036303e-43,1.003353614311256939e-51\n1.246000000000000000e+03,2.835763999738429779e-43,9.133590589459735365e-52\n1.247000000000000000e+03,2.621899156666139653e-43,8.314364533697529730e-52\n1.248000000000000000e+03,2.424163360688972115e-43,7.568617940788981493e-52\n1.249000000000000000e+03,2.241340207294305842e-43,6.889760161641428367e-52\n1.250000000000000000e+03,2.072305029561341737e-43,6.271791687240720853e-52\n1.251000000000000000e+03,1.916017979586147365e-43,5.709251127077040059e-52\n1.252000000000000000e+03,1.771517631684955989e-43,5.197166943274293972e-52\n1.253000000000000000e+03,1.637915068024870637e-43,4.731013513867276565e-52\n1.254000000000000000e+03,1.514388410298371583e-43,4.306671136927821577e-52\n1.255000000000000000e+03,1.400177763802833194e-43,3.920389622071898638e-52\n1.256000000000000000e+03,1.294580542822324411e-43,3.568755147580800793e-52\n1.257000000000000000e+03,1.196947148555144624e-43,3.248660090231987940e-52\n1.258000000000000000e+03,1.106676972999231516e-43,2.957275561205242299e-52\n1.259000000000000000e+03,1.023214704212411902e-43,2.692026405347092362e-52\n1.260000000000000000e+03,9.460469102190492231e-44,2.450568442844858647e-52\n1.261000000000000000e+03,8.746988805481566755e-44,2.230767752180676731e-52\n1.262000000000000000e+03,8.087317059732645876e-44,2.030681811274867182e-52\n1.263000000000000000e+03,7.477395784896371030e-44,1.848542330151357935e-52\n1.264000000000000000e+03,6.913472949190194501e-44,1.682739623405645309e-52\n1.265000000000000000e+03,6.392079487851661300e-44,1.531808384364972627e-52\n1.266000000000000000e+03,5.910007962611599859e-44,1.394414735217291320e-52\n1.267000000000000000e+03,5.464292830606080351e-44,1.269344438663031470e-52\n1.268000000000000000e+03,5.052192201348428434e-44,1.155492166908083442e-52\n1.269000000000000000e+03,4.671170969535095370e-44,1.051851733160961942e-52\n1.270000000000000000e+03,4.318885219925665489e-44,9.575071993038706152e-53\n1.271000000000000000e+03,3.993167808359797827e-44,8.716247811500545882e-53\n1.272000000000000000e+03,3.692015030210835938e-44,7.934454797491153374e-53\n1.273000000000000000e+03,3.413574294264753279e-44,7.222783736181116027e-53\n1.274000000000000000e+03,3.156132726198529852e-44,6.574945126177788058e-53\n1.275000000000000000e+03,2.918106631549641723e-44,5.985213595098623184e-53\n1.276000000000000000e+03,2.698031753357369895e-44,5.448377300721100220e-53\n1.277000000000000000e+03,2.494554264543437434e-44,4.959691870532784835e-53\n1.278000000000000000e+03,2.306422439620381915e-44,4.514838472617038047e-53\n1.279000000000000000e+03,2.132478954494950452e-44,4.109885647318041212e-53\n1.280000000000000000e+03,1.971653766996974556e-44,3.741254562367558621e-53\n1.281000000000000000e+03,1.822957534337797361e-44,3.405687384409341734e-53\n1.282000000000000000e+03,1.685475527004149408e-44,3.100218487400875733e-53\n1.283000000000000000e+03,1.558362001647957372e-44,2.822148243441678492e-53\n1.284000000000000000e+03,1.440834998356095518e-44,2.569019164400298069e-53\n1.285000000000000000e+03,1.332171530294275445e-44,2.338594183488857202e-53\n1.286000000000000000e+03,1.231703136133834706e-44,2.128836884844533730e-53\n1.287000000000000000e+03,1.138811767901089799e-44,1.937893506394345657e-53\n1.288000000000000000e+03,1.052925988952803340e-44,1.764076556950311450e-53\n1.289000000000000000e+03,9.735174586890512657e-45,1.605849902749199357e-53\n1.290000000000000000e+03,9.000976823783862405e-45,1.461815191636386610e-53\n1.291000000000000000e+03,8.322150061016199367e-45,1.330699494915806048e-53\n1.292000000000000000e+03,7.694518383278864337e-45,1.211344057648596762e-53\n1.293000000000000000e+03,7.114220810311478314e-45,1.102694057979940083e-53\n1.294000000000000000e+03,6.577687545442037522e-45,1.003789284990230926e-53\n1.295000000000000000e+03,6.081618015391571671e-45,9.137556526848933069e-54\n1.296000000000000000e+03,5.622960566250150895e-45,8.317974751261874668e-54\n1.297000000000000000e+03,5.198893690722610766e-45,7.571904344376038102e-54\n1.298000000000000000e+03,4.806808671158826767e-45,6.892751795343421628e-54\n1.299000000000000000e+03,4.444293531594770180e-45,6.274514990076124085e-54\n1.300000000000000000e+03,4.109118200082974913e-45,5.711730166649419336e-54\n1.301000000000000000e+03,3.799220790035050512e-45,5.199423628473433318e-54\n1.302000000000000000e+03,3.512694916184958513e-45,4.733067788492317913e-54\n1.303000000000000000e+03,3.247777967144103590e-45,4.308541155943631572e-54\n1.304000000000000000e+03,3.002840262405280743e-45,3.922091912056335685e-54\n1.305000000000000000e+03,2.776375027093180119e-45,3.570304752780864131e-54\n1.306000000000000000e+03,2.566989122788811626e-45,3.250070705519639188e-54\n1.307000000000000000e+03,2.373394477407867574e-45,2.958559653107923980e-54\n1.308000000000000000e+03,2.194400161411823975e-45,2.693195322222563945e-54\n1.309000000000000000e+03,2.028905061607525684e-45,2.451632515174034203e-54\n1.310000000000000000e+03,1.875891107467048335e-45,2.231736383864824526e-54\n1.311000000000000000e+03,1.734417008297977891e-45,2.031563562744019949e-54\n1.312000000000000000e+03,1.603612462737872031e-45,1.849344994018416048e-54\n1.313000000000000000e+03,1.482672804951195220e-45,1.683470293334780193e-54\n1.314000000000000000e+03,1.370854054594082335e-45,1.532473517762965022e-54\n1.315000000000000000e+03,1.267468340096060838e-45,1.395020210301846341e-54\n1.316000000000000000e+03,1.171879667103986874e-45,1.269895606412423711e-54\n1.317000000000000000e+03,1.083500006057484028e-45,1.155993898351241448e-54\n1.318000000000000000e+03,1.001785674827648801e-45,1.052308462425928894e-54\n1.319000000000000000e+03,9.262339941663497032e-46,9.579229628050860846e-55\n1.320000000000000000e+03,8.563801953915297354e-46,8.720032532607820075e-55\n1.321000000000000000e+03,7.917945612856986155e-46,7.937900052742748780e-55\n1.322000000000000000e+03,7.320797826191916055e-46,7.225919973545034618e-55\n1.323000000000000000e+03,6.768685140366636077e-46,6.577800062629386506e-55\n1.324000000000000000e+03,6.258211142712555738e-46,5.987812461573601172e-55\n1.325000000000000000e+03,5.786235567850567365e-46,5.450743065097742570e-55\n1.326000000000000000e+03,5.349854979828576443e-46,4.961845440614078267e-55\n1.327000000000000000e+03,4.946384911153650339e-46,4.516798880906566190e-55\n1.328000000000000000e+03,4.573343348845781509e-46,4.111670219222636065e-55\n1.329000000000000000e+03,4.228435465923700593e-46,3.742879069313219056e-55\n1.330000000000000000e+03,3.909539504396405053e-46,3.407166183223613764e-55\n1.331000000000000000e+03,3.614693722917539860e-46,3.101564647193503626e-55\n1.332000000000000000e+03,3.342084328808113827e-46,2.823373661104852494e-55\n1.333000000000000000e+03,3.090034320210532669e-46,2.570134669749247345e-55\n1.334000000000000000e+03,2.856993169733744913e-46,2.339609634971996672e-55\n1.335000000000000000e+03,2.641527286127044591e-46,2.129761256668999854e-55\n1.336000000000000000e+03,2.442311195306107832e-46,1.938734967836920175e-55\n1.337000000000000000e+03,2.258119386479306316e-46,1.764842544554648053e-55\n1.338000000000000000e+03,2.087818773215172175e-46,1.606547186047412763e-55\n1.339000000000000000e+03,1.930361723073428250e-46,1.462449932975821732e-55\n1.340000000000000000e+03,1.784779612920446117e-46,1.331277303919722012e-55\n1.341000000000000000e+03,1.650176870283519305e-46,1.211870040792066466e-55\n1.342000000000000000e+03,1.525725464088505178e-46,1.103172863719101751e-55\n1.343000000000000000e+03,1.410659810889322907e-46,1.004225144843727348e-55\n1.344000000000000000e+03,1.304272065254634340e-46,9.141524186305613616e-56\n1.345000000000000000e+03,1.205907765339361220e-46,8.321586536435001509e-56\n1.346000000000000000e+03,1.114961806854188670e-46,7.575192174967157382e-56\n1.347000000000000000e+03,1.030874720666331993e-46,6.895744728056123121e-56\n1.348000000000000000e+03,9.531292311323675854e-47,6.277239475409079752e-56\n1.349000000000000000e+03,8.812470739914691073e-47,5.714210282656705742e-56\n1.350000000000000000e+03,8.147860542435452619e-47,5.201681293557986858e-56\n1.351000000000000000e+03,7.533373259134163426e-47,4.735122955113169485e-56\n1.352000000000000000e+03,6.965228769670992551e-47,4.310411986948797542e-56\n1.353000000000000000e+03,6.439932039080777895e-47,3.923794941199753045e-56\n1.354000000000000000e+03,5.954251617486800557e-47,3.571855030841960873e-56\n1.355000000000000000e+03,5.505199761301315055e-47,3.251481933316890078e-56\n1.356000000000000000e+03,5.090014053625741938e-47,2.959844302581918758e-56\n1.357000000000000000e+03,4.706140410785702652e-47,2.694364746658681887e-56\n1.358000000000000000e+03,4.351217370461645394e-47,2.452697049538834704e-56\n1.359000000000000000e+03,4.023061564762413914e-47,2.232705436142886148e-56\n1.360000000000000000e+03,3.719654288875814865e-47,2.032445697082437758e-56\n1.361000000000000000e+03,3.439129082671429490e-47,1.850148006413730093e-56\n1.362000000000000000e+03,3.179760248862060973e-47,1.684201280531386227e-56\n1.363000000000000000e+03,2.939952237090630420e-47,1.533138939971516784e-56\n1.364000000000000000e+03,2.718229828637987148e-47,1.395625948292457208e-56\n1.365000000000000000e+03,2.513229061370470602e-47,1.270447013486857600e-56\n1.366000000000000000e+03,2.323688839100846504e-47,1.156495847653479167e-56\n1.367000000000000000e+03,2.148443173746122826e-47,1.052765390009346456e-56\n1.368000000000000000e+03,1.986414012558785164e-47,9.583389068368253589e-57\n1.369000000000000000e+03,1.836604606306503898e-47,8.723818897095843988e-57\n1.370000000000000000e+03,1.698093377604204682e-47,7.941346803974099986e-57\n1.371000000000000000e+03,1.570028251678051013e-47,7.229057572708663633e-57\n1.372000000000000000e+03,1.451621414686270499e-47,6.580656238735762081e-57\n1.373000000000000000e+03,1.342144467351853033e-47,5.990412456514149555e-57\n1.374000000000000000e+03,1.240923944093580369e-47,5.453109856723637027e-57\n1.375000000000000000e+03,1.147337170090999613e-47,4.963999945806636737e-57\n1.376000000000000000e+03,1.060808430797071395e-47,4.518760140433717764e-57\n1.377000000000000000e+03,9.808054303347253323e-48,4.113455566014211996e-57\n1.378000000000000000e+03,9.068360169906327352e-48,3.744504281643335569e-57\n1.379000000000000000e+03,8.384451556623073819e-48,3.408645624153760747e-57\n1.380000000000000000e+03,7.752121286343354565e-48,3.102911391508265481e-57\n1.381000000000000000e+03,7.167479474636239665e-48,2.824599610862173029e-57\n1.382000000000000000e+03,6.626929600525300868e-48,2.571250659466748153e-57\n1.383000000000000000e+03,6.127146381894294299e-48,2.340625527378851998e-57\n1.384000000000000000e+03,5.665055319462647956e-48,2.130686029869107496e-57\n1.385000000000000000e+03,5.237813783494118616e-48,1.939576794654246496e-57\n1.386000000000000000e+03,4.842793526888851672e-48,1.765608864761902917e-57\n1.387000000000000000e+03,4.477564517085871688e-48,1.607244772116138772e-57\n1.388000000000000000e+03,4.139879987315075259e-48,1.463084949929165234e-57\n1.389000000000000000e+03,3.827662615239414157e-48,1.331855363816699392e-57\n1.390000000000000000e+03,3.538991743961969149e-48,1.212396252325021837e-57\n1.391000000000000000e+03,3.272091566787057168e-48,1.103651877362638232e-57\n1.392000000000000000e+03,3.025320203051039543e-48,1.004661193953888230e-57\n1.393000000000000000e+03,2.797159597821331610e-48,9.145493568577525519e-58\n1.394000000000000000e+03,2.586206183330110004e-48,8.325199889897588423e-58\n1.395000000000000000e+03,2.391162244694383875e-48,7.578481433182070709e-58\n1.396000000000000000e+03,2.210827936808032923e-48,6.898738960343675054e-58\n1.397000000000000000e+03,2.044093903295789042e-48,6.279965143752959703e-58\n1.398000000000000000e+03,1.889934452123652572e-48,5.716691475566219798e-58\n1.399000000000000000e+03,1.747401245884504507e-48,5.203939938953437172e-58\n1.400000000000000000e+03,1.615617467943244904e-48,4.737179014117148902e-58\n1.401000000000000000e+03,1.493772428554091370e-48,4.312283630295894980e-58\n1.402000000000000000e+03,1.381116577768255011e-48,3.925498709823102759e-58\n1.403000000000000000e+03,1.276956894453215258e-48,3.573405982056307891e-58\n1.404000000000000000e+03,1.180652623058466403e-48,3.252893773889746499e-58\n1.405000000000000000e+03,1.091611331901468471e-48,2.961129509869288447e-58\n1.406000000000000000e+03,1.009285268726065110e-48,2.695534678875798158e-58\n1.407000000000000000e+03,9.331679911137016395e-49,2.453762046139882795e-58\n1.408000000000000000e+03,8.627912510189602514e-49,2.233674909197489307e-58\n1.409000000000000000e+03,7.977221142641729779e-49,2.033328214456368650e-58\n1.410000000000000000e+03,7.375602972730167140e-49,1.850951367488715246e-58\n1.411000000000000000e+03,6.819357046598204932e-49,1.684932585133249756e-58\n1.412000000000000000e+03,6.305061525264656190e-49,1.533804651116013093e-58\n1.413000000000000000e+03,5.829552634614375742e-49,1.396231949303261431e-58\n1.414000000000000000e+03,5.389905202917500873e-49,1.270998659990197762e-58\n1.415000000000000000e+03,4.983414666151184107e-49,1.156998014909344752e-58\n1.416000000000000000e+03,4.607580430425400868e-49,1.053222515997371773e-58\n1.417000000000000000e+03,4.260090489165618546e-49,9.587550314775177367e-59\n1.418000000000000000e+03,3.938807200421195843e-49,8.727606905678319889e-59\n1.419000000000000000e+03,3.641754136806669030e-49,7.944795051834894780e-59\n1.420000000000000000e+03,3.367103927181423402e-49,7.232196534263213428e-59\n1.421000000000000000e+03,3.113167015273012136e-49,6.583513655035099440e-59\n1.422000000000000000e+03,2.878381266092019197e-49,5.993013580410005540e-59\n1.423000000000000000e+03,2.661302356199777895e-49,5.455477676044596547e-59\n1.424000000000000000e+03,2.460594888713386015e-49,4.966155386516712175e-59\n1.425000000000000000e+03,2.275024178390659791e-49,4.520722251568305350e-59\n1.426000000000000000e+03,2.103448656259065563e-49,4.115241688029294811e-59\n1.427000000000000000e+03,1.944812847065183629e-49,3.746130199664144336e-59\n1.428000000000000000e+03,1.798140876343761949e-49,3.410125707478550100e-59\n1.429000000000000000e+03,1.662530467164225001e-49,3.104258720598836112e-59\n1.430000000000000000e+03,1.537147389624728662e-49,2.825826092944563495e-59\n1.431000000000000000e+03,1.421220328948544621e-49,2.572367133763228659e-59\n1.432000000000000000e+03,1.314036140613509534e-49,2.341641860900978450e-59\n1.433000000000000000e+03,1.214935463325308388e-49,2.131611204619169322e-59\n1.434000000000000000e+03,1.123308662847219045e-49,1.940418987005003063e-59\n1.435000000000000000e+03,1.038592081734078501e-49,1.766375517716470949e-59\n1.436000000000000000e+03,9.602645719001744946e-50,1.607942661086821684e-59\n1.437000000000000000e+03,8.878442886903523932e-50,1.463720242616030400e-59\n1.438000000000000000e+03,8.208857267328438229e-50,1.332433674715622765e-59\n1.439000000000000000e+03,7.589769793391378783e-50,1.212922692346684704e-59\n1.440000000000000000e+03,7.017372045917267976e-50,1.104131099000871498e-59\n1.441000000000000000e+03,6.488142825319876346e-50,1.005097432402905678e-59\n1.442000000000000000e+03,5.998826490358508468e-50,9.149464674412612051e-60\n1.443000000000000000e+03,5.546412930521889177e-50,8.328814812330492909e-60\n1.444000000000000000e+03,5.128119048834488423e-50,7.581772119640349368e-60\n1.445000000000000000e+03,4.741371641174270100e-50,6.901734492770079900e-60\n1.446000000000000000e+03,4.383791566781444751e-50,6.282691995621710552e-60\n1.447000000000000000e+03,4.053179112579452624e-50,5.719173745845813747e-60\n1.448000000000000000e+03,3.747500461275785316e-50,5.206199565085520813e-60\n1.449000000000000000e+03,3.464875179997841823e-50,4.739235965891810583e-60\n1.450000000000000000e+03,3.203564652498493538e-50,4.314156086337595612e-60\n1.451000000000000000e+03,2.961961383770347187e-50,3.927203218247422219e-60\n1.452000000000000000e+03,2.738579111273571608e-50,3.574957606716044772e-60\n1.453000000000000000e+03,2.532043661945808042e-50,3.254306227504146776e-60\n1.454000000000000000e+03,2.341084498748841991e-50,2.962415275212370248e-60\n1.455000000000000000e+03,2.164526904749487237e-50,2.696705119094512864e-60\n1.456000000000000000e+03,2.001284756653701450e-50,2.454827505177922509e-60\n1.457000000000000000e+03,1.850353843339294937e-50,2.234644803211310551e-60\n1.458000000000000000e+03,1.710805688284643215e-50,2.034211115032103355e-60\n1.459000000000000000e+03,1.581781837891641105e-50,1.851755077394668112e-60\n1.460000000000000000e+03,1.462488580566123559e-50,1.685664207278121250e-60\n1.461000000000000000e+03,1.352192064069461539e-50,1.534470651321978301e-60\n1.462000000000000000e+03,1.250213781104999337e-50,1.396838213448525776e-60\n1.463000000000000000e+03,1.155926395367874734e-50,1.271550546026479565e-60\n1.464000000000000000e+03,1.068749882381875994e-50,1.157500400213542678e-60\n1.465000000000000000e+03,9.881479613827479681e-51,1.053679840476095574e-60\n1.466000000000000000e+03,9.136247962982000267e-51,9.591713368055317457e-61\n1.467000000000000000e+03,8.447219455302035691e-51,8.731396559068768402e-61\n1.468000000000000000e+03,7.810155417754594915e-51,7.948244796974654672e-61\n1.469000000000000000e+03,7.221136845355036155e-51,7.235336858800563690e-61\n1.470000000000000000e+03,6.676540292758427931e-51,6.586372312066188056e-61\n1.471000000000000000e+03,6.173015584035025576e-51,5.995615833751722202e-61\n1.472000000000000000e+03,5.707465203508299381e-51,5.457846523507019792e-61\n1.473000000000000000e+03,5.277025240873455249e-51,4.968311763150237618e-61\n1.474000000000000000e+03,4.879047773379045062e-51,4.522685214679852194e-61\n1.475000000000000000e+03,4.511084576691316462e-51,4.117028585604322240e-61\n1.476000000000000000e+03,4.170872064236504993e-51,3.747756823682224865e-61\n1.477000000000000000e+03,3.856317362373211150e-51,3.411606433477063368e-61\n1.478000000000000000e+03,3.565485435733045399e-51,3.105606634719311170e-61\n1.479000000000000000e+03,3.296587183530187463e-51,2.827053107583327150e-61\n1.480000000000000000e+03,3.047968433611395121e-51,2.573484092848954354e-61\n1.481000000000000000e+03,2.818099766541917916e-51,2.342658635729780515e-61\n1.482000000000000000e+03,2.605567107128392522e-51,2.132536781093453841e-61\n1.483000000000000000e+03,2.409063025501136138e-51,1.941261545047827886e-61\n1.484000000000000000e+03,2.227378694242437988e-51,1.767142503562911835e-61\n1.485000000000000000e+03,2.059396452084565577e-51,1.608640853091054545e-61\n1.486000000000000000e+03,1.904082928431241519e-51,1.464355811156227868e-61\n1.487000000000000000e+03,1.760482686407174904e-51,1.333012236725556852e-61\n1.488000000000000000e+03,1.627712345329914066e-51,1.213449360956199126e-61\n1.489000000000000000e+03,1.504955146447052201e-51,1.104610528724053091e-61\n1.490000000000000000e+03,1.391455928509534813e-51,1.005533860272950684e-61\n1.491000000000000000e+03,1.286516482272084734e-51,9.153437504559656371e-62\n1.492000000000000000e+03,1.189491255343323164e-51,8.332431304415336217e-62\n1.493000000000000000e+03,1.099783380963338938e-51,7.585064234962590697e-62\n1.494000000000000000e+03,1.016841006278812580e-51,6.904731325900269675e-62\n1.495000000000000000e+03,9.401538975288218218e-52,6.285420031528879589e-62\n1.496000000000000000e+03,8.692503012573004922e-52,5.721657093962970190e-62\n1.497000000000000000e+03,8.036940422434753214e-52,5.208460172379868264e-62\n1.498000000000000000e+03,7.430818402977705825e-52,4.741293810824604705e-62\n1.499000000000000000e+03,6.870408294168290652e-52,4.316029355426965602e-62\n1.500000000000000000e+03,6.352262640365598482e-52,3.928908466794111388e-62\n1.501000000000000000e+03,5.873193982726658903e-52,3.576509905113795610e-62\n1.502000000000000000e+03,5.430255251025220712e-52,3.255719294426465816e-62\n1.503000000000000000e+03,5.020721634260882031e-52,2.963701598853312528e-62\n1.504000000000000000e+03,4.642073818533017907e-52,2.697876067535255072e-62\n1.505000000000000000e+03,4.291982489063446063e-52,2.455893426853646414e-62\n1.506000000000000000e+03,3.968294001030916691e-52,2.235615118367229955e-62\n1.507000000000000000e+03,3.669017131068070893e-52,2.035094398976119516e-62\n1.508000000000000000e+03,3.392310827920914262e-52,1.852559136283161486e-62\n1.509000000000000000e+03,3.136472886917173973e-52,1.686396147103977737e-62\n1.510000000000000000e+03,2.899929478571913423e-52,1.535136940714840560e-62\n1.511000000000000000e+03,2.681225466914882705e-52,1.397444740842427981e-62\n1.512000000000000000e+03,2.479015457980439989e-52,1.272102671699639677e-62\n1.513000000000000000e+03,2.292055523393615518e-52,1.158003003660686680e-62\n1.514000000000000000e+03,2.119195548138735300e-52,1.054137363531764950e-62\n1.515000000000000000e+03,1.959372155436129691e-52,9.595878228993794317e-63\n1.516000000000000000e+03,1.811602165203817783e-52,8.735187857981882089e-63\n1.517000000000000000e+03,1.674976545862291259e-52,7.951696040043970522e-63\n1.518000000000000000e+03,1.548654822276108583e-52,7.238478546912129166e-63\n1.519000000000000000e+03,1.431859905431929203e-52,6.589232210367398079e-63\n1.520000000000000000e+03,1.323873312046550199e-52,5.998219217029378070e-63\n1.521000000000000000e+03,1.224030744698035024e-52,5.460216399557492376e-63\n1.522000000000000000e+03,1.131718005290029279e-52,4.970469076113887749e-63\n1.523000000000000000e+03,1.046367216710386286e-52,4.524649030138555658e-63\n1.524000000000000000e+03,9.674533294410798260e-53,4.118816259076287766e-63\n1.525000000000000000e+03,8.944908916290015699e-53,3.749384154003919408e-63\n1.526000000000000000e+03,8.270310627485160711e-53,3.413087802428165996e-63\n1.527000000000000000e+03,7.646588524845785982e-53,3.106955134123540842e-63\n1.528000000000000000e+03,7.069905678510520878e-53,2.828280655009547503e-63\n1.529000000000000000e+03,6.536714528397178363e-53,2.574601536934574572e-63\n1.530000000000000000e+03,6.043735060799478695e-53,2.343675852057014618e-63\n1.531000000000000000e+03,5.587934630838673078e-53,2.133462759466517159e-63\n1.532000000000000000e+03,5.166509306646478838e-53,1.942104468941619849e-63\n1.533000000000000000e+03,4.776866620513500024e-53,1.767909822445671825e-63\n1.534000000000000000e+03,4.416609620894486053e-53,1.609339348260327201e-63\n1.535000000000000000e+03,4.083522127164004251e-53,1.464991655669454113e-63\n1.536000000000000000e+03,3.775555096413717385e-53,1.333591049955461515e-63\n1.537000000000000000e+03,3.490814018425689510e-53,1.213976258252890348e-63\n1.538000000000000000e+03,3.227547261278799656e-53,1.105090166622599292e-63\n1.539000000000000000e+03,2.984135295894706284e-53,1.005970477646329840e-63\n1.540000000000000000e+03,2.759080733236544171e-53,9.157412059766862053e-64\n1.541000000000000000e+03,2.550999112871896043e-53,8.336049366833215378e-64\n1.542000000000000000e+03,2.358610386235219436e-53,7.588357779768793906e-64\n1.543000000000000000e+03,2.180731042196961002e-53,6.907729460298635615e-64\n1.544000000000000000e+03,2.016266826498706978e-53,6.288149251988950640e-64\n1.545000000000000000e+03,1.864206010266922875e-53,5.724141520386029566e-64\n1.546000000000000000e+03,1.723613166194968859e-53,5.210721761262808981e-64\n1.547000000000000000e+03,1.593623414107151575e-53,4.743352549303623876e-64\n1.548000000000000000e+03,1.473437100504986247e-53,4.317903437916796524e-64\n1.549000000000000000e+03,1.362314879366203121e-53,3.930614455784318255e-64\n1.550000000000000000e+03,1.259573163935168456e-53,3.578062877541903572e-64\n1.551000000000000000e+03,1.164579921525763776e-53,3.257132974922827527e-64\n1.552000000000000000e+03,1.076750785467482004e-53,2.964988481034703625e-64\n1.553000000000000000e+03,9.955454602771032945e-54,2.699047524418854736e-64\n1.554000000000000000e+03,9.204643979414875731e-54,2.456959811368078138e-64\n1.555000000000000000e+03,8.510457248651864709e-54,2.236585854847987913e-64\n1.556000000000000000e+03,7.868624005785416734e-54,2.035978066454766356e-64\n1.557000000000000000e+03,7.275195907274016409e-54,1.853363544305623215e-64\n1.558000000000000000e+03,6.726522381842221211e-54,1.687128404748664877e-64\n1.559000000000000000e+03,6.219228173386448506e-54,1.535803519420255758e-64\n1.560000000000000000e+03,5.750192577527716922e-54,1.398051531599353184e-64\n1.561000000000000000e+03,5.316530244081903805e-54,1.272655037113804130e-64\n1.562000000000000000e+03,4.915573427349502545e-54,1.158505825345564017e-64\n1.563000000000000000e+03,4.544855575036261955e-54,1.054595085250545204e-64\n1.564000000000000000e+03,4.202096154847967655e-54,9.600044898374969566e-65\n1.565000000000000000e+03,3.885186625418110686e-54,8.738980803131674562e-65\n1.566000000000000000e+03,3.592177465266525253e-54,7.955148781692812575e-65\n1.567000000000000000e+03,3.321266179994629903e-54,7.241621599190403707e-65\n1.568000000000000000e+03,3.070786213942712699e-54,6.592093350478079302e-65\n1.569000000000000000e+03,2.839196698096587206e-54,6.000823730733948849e-65\n1.570000000000000000e+03,2.625072971176505821e-54,5.462587304642332275e-65\n1.571000000000000000e+03,2.427097815597387989e-54,4.972627325813945990e-65\n1.572000000000000000e+03,2.244053354386363112e-54,4.526613698314260933e-65\n1.573000000000000000e+03,2.074813559210928952e-54,4.120604708781863089e-65\n1.574000000000000000e+03,1.918337323429052601e-54,3.751012190936127928e-65\n1.575000000000000000e+03,1.773662057549154822e-54,3.414569814611230032e-65\n1.576000000000000000e+03,1.639897767701334501e-54,3.108304219065841435e-65\n1.577000000000000000e+03,1.516221580692707208e-54,2.829508735454729116e-65\n1.578000000000000000e+03,1.401872681966466784e-54,2.575719466230535822e-65\n1.579000000000000000e+03,1.296147635325176527e-54,2.344693510074251564e-65\n1.580000000000000000e+03,1.198396055626421956e-54,2.134389139912747322e-65\n1.581000000000000000e+03,1.108016607830823807e-54,1.942947758845125518e-65\n1.582000000000000000e+03,1.024453307789971815e-54,1.768677474509459678e-65\n1.583000000000000000e+03,9.471921020177137678e-55,1.610038146726370222e-65\n1.584000000000000000e+03,8.757577054050265833e-55,1.465627776275623469e-65\n1.585000000000000000e+03,8.097106774248991011e-55,1.334170114514458153e-65\n1.586000000000000000e+03,7.486447188411077250e-55,1.214503384335988405e-65\n1.587000000000000000e+03,6.921841722911858313e-55,1.105570012786840130e-65\n1.588000000000000000e+03,6.399817113678487300e-55,1.006407284605270712e-65\n1.589000000000000000e+03,5.917162039830939908e-55,9.161388340783794076e-66\n1.590000000000000000e+03,5.470907368709414861e-55,8.339669000266461841e-66\n1.591000000000000000e+03,5.058307890762731597e-55,7.591652754680096160e-66\n1.592000000000000000e+03,4.676825431937211500e-55,6.910728896530599218e-66\n1.593000000000000000e+03,4.324113239677971593e-55,6.290879657515914585e-66\n1.594000000000000000e+03,3.998001546492049935e-55,5.726627025582879383e-66\n1.595000000000000000e+03,3.696484222264076732e-55,5.212984332160267889e-66\n1.596000000000000000e+03,3.417706433214464741e-55,4.745412181716589619e-66\n1.597000000000000000e+03,3.159953231582034065e-55,4.319778334160525864e-66\n1.598000000000000000e+03,2.921639005838888374e-55,3.932321185539778389e-66\n1.599000000000000000e+03,2.701297726538092818e-55,3.579616524293245711e-66\n1.600000000000000000e+03,2.497573927790810033e-55,3.258547269259838760e-66\n1.601000000000000000e+03,2.309214368893243044e-55,2.966275921998901546e-66\n1.602000000000000000e+03,2.135060324808761977e-55,2.700219489965932222e-66\n1.603000000000000000e+03,1.974040458078971843e-55,2.458026658922048897e-66\n1.604000000000000000e+03,1.825164228313632269e-55,2.237557012836656180e-66\n1.605000000000000000e+03,1.687515798717449869e-55,2.036862117634695269e-66\n1.606000000000000000e+03,1.560248402168250174e-55,1.854168301613757563e-66\n1.607000000000000000e+03,1.442579132188702423e-55,1.687860980350281109e-66\n1.608000000000000000e+03,1.333784126767482019e-55,1.536470387563761098e-66\n1.609000000000000000e+03,1.233194115402044093e-55,1.398658585833578175e-66\n1.610000000000000000e+03,1.140190301970316077e-55,1.273207642372999764e-66\n1.611000000000000000e+03,1.054200558103803061e-55,1.159008865362870126e-66\n1.612000000000000000e+03,9.746959036451152076e-56,1.055053005718758744e-66\n1.613000000000000000e+03,9.011872525389379172e-56,9.604213376984641641e-67\n1.614000000000000000e+03,8.332224041380371661e-56,8.742775395233465360e-67\n1.615000000000000000e+03,7.703832614161098787e-56,7.958603022572338227e-67\n1.616000000000000000e+03,7.122832589746359354e-56,7.244766016227318813e-67\n1.617000000000000000e+03,6.585649850217679597e-56,6.594955732937070148e-67\n1.618000000000000000e+03,6.088979826945106959e-56,6.003429375355942738e-67\n1.619000000000000000e+03,5.629767171985158674e-56,5.464959239208671978e-67\n1.620000000000000000e+03,5.205186962602084294e-56,4.974786512657440907e-67\n1.621000000000000000e+03,4.812627323287489645e-56,4.528579219577486383e-67\n1.622000000000000000e+03,4.449673358375370505e-56,4.122393935058334793e-67\n1.623000000000000000e+03,4.114092296411230659e-56,3.752640934785457330e-67\n1.624000000000000000e+03,3.803819754888766485e-56,3.416052470305363334e-67\n1.625000000000000000e+03,3.516947040858453120e-56,3.109653889800285038e-67\n1.626000000000000000e+03,3.251709409286857185e-56,2.830737349150155583e-67\n1.627000000000000000e+03,3.006475206935093286e-56,2.576837880947671025e-67\n1.628000000000000000e+03,2.779735834973529540e-56,2.345711609973413451e-67\n1.629000000000000000e+03,2.570096468586281887e-56,2.135315922606852306e-67\n1.630000000000000000e+03,2.376267476475000348e-56,1.943791414917382972e-67\n1.631000000000000000e+03,2.197056487478419614e-56,1.769445459898847858e-67\n1.632000000000000000e+03,2.031361055503548431e-56,1.610737248620787828e-67\n1.633000000000000000e+03,1.878161877645835580e-56,1.466264173094536437e-67\n1.634000000000000000e+03,1.736516523778590239e-56,1.334749430511715844e-67\n1.635000000000000000e+03,1.605553639037616788e-56,1.215030739304905038e-67\n1.636000000000000000e+03,1.484467583537724290e-56,1.106050067307270366e-67\n1.637000000000000000e+03,1.372513476345316902e-56,1.006844281232151864e-67\n1.638000000000000000e+03,1.269002613219799680e-56,9.165366348359303614e-68\n1.639000000000000000e+03,1.173298229935606381e-56,8.343290205396759117e-68\n1.640000000000000000e+03,1.084811585121256687e-56,7.594949160317035839e-68\n1.641000000000000000e+03,1.002998338519508449e-56,6.913729635161043096e-68\n1.642000000000000000e+03,9.273552023879569027e-57,6.293611248624704585e-68\n1.643000000000000000e+03,8.574168454410227118e-57,5.729113610022267298e-68\n1.644000000000000000e+03,7.927530302876345974e-57,5.215247885498945715e-68\n1.645000000000000000e+03,7.329659667544259945e-57,4.747472708451929747e-68\n1.646000000000000000e+03,6.776878648137413356e-57,4.321654044511249346e-68\n1.647000000000000000e+03,6.265786720622626455e-57,3.934028656381919028e-68\n1.648000000000000000e+03,5.793239818322576055e-57,3.581170845660419229e-68\n1.649000000000000000e+03,5.356330990669939440e-57,3.259962177703853286e-68\n1.650000000000000000e+03,4.952372520617942310e-57,2.967563921988707560e-68\n1.651000000000000000e+03,4.578879390704742986e-57,2.701391964397510773e-68\n1.652000000000000000e+03,4.233553996056246615e-57,2.459093969716757992e-68\n1.653000000000000000e+03,3.914272010288690162e-57,2.238528592516132708e-68\n1.654000000000000000e+03,3.619069317363759762e-57,2.037746552682399860e-68\n1.655000000000000000e+03,3.346129929002410759e-57,1.854973408359124215e-68\n1.656000000000000000e+03,3.093774813332929287e-57,1.688593874046790920e-68\n1.657000000000000000e+03,2.860451566047372013e-57,1.537137545271121462e-68\n1.658000000000000000e+03,2.644724860529904705e-57,1.399265903659588640e-68\n1.659000000000000000e+03,2.445267618206993837e-57,1.273760487581442586e-68\n1.660000000000000000e+03,2.260852844803484686e-57,1.159512123807474241e-68\n1.661000000000000000e+03,2.090346082284506581e-57,1.055511125022645009e-68\n1.662000000000000000e+03,1.932698430048358350e-57,9.608383665607860303e-69\n1.663000000000000000e+03,1.786940092441110587e-57,8.746571635001883023e-69\n1.664000000000000000e+03,1.652174412897742647e-57,7.962058763333084696e-69\n1.665000000000000000e+03,1.527572358010587052e-57,7.247911798615881478e-69\n1.666000000000000000e+03,1.412367417593287709e-57,6.597819358284192037e-69\n1.667000000000000000e+03,1.305850889366021343e-57,6.006036151386759859e-69\n1.668000000000000000e+03,1.207367519256296137e-57,5.467332203703217677e-69\n1.669000000000000000e+03,1.116311470494814086e-57,4.976946637051010368e-69\n1.670000000000000000e+03,1.032122596710115536e-57,4.530545594298397893e-69\n1.671000000000000000e+03,9.542829960955874050e-58,4.124183938242665179e-69\n1.672000000000000000e+03,8.823138254504411902e-58,3.754270385859075687e-69\n1.673000000000000000e+03,8.157723544966257095e-58,3.417535769790181942e-69\n1.674000000000000000e+03,7.542492423500700393e-58,3.111004146581408750e-69\n1.675000000000000000e+03,6.973660193923520132e-58,2.831966496327533119e-69\n1.676000000000000000e+03,6.447727590522822060e-58,2.577956781296609763e-69\n1.677000000000000000e+03,5.961459251744548439e-58,2.346730151946237982e-69\n1.678000000000000000e+03,5.511863817331177951e-58,2.136243107723372567e-69\n1.679000000000000000e+03,5.096175526472810399e-58,1.944635437317277405e-69\n1.680000000000000000e+03,4.711837203770891716e-58,1.770213778758670877e-69\n1.681000000000000000e+03,4.356484528351062456e-58,1.611436654075424347e-69\n1.682000000000000000e+03,4.027931489350426030e-58,1.466900846246211902e-69\n1.683000000000000000e+03,3.724156938310451780e-58,1.335328998056336265e-69\n1.684000000000000000e+03,3.443292155746905293e-58,1.215558323258956395e-69\n1.685000000000000000e+03,3.183609355412045225e-58,1.106530330274298327e-69\n1.686000000000000000e+03,2.943511055531929656e-58,1.007281467609272111e-69\n1.687000000000000000e+03,2.721520251631833177e-58,9.169346083243607901e-70\n1.688000000000000000e+03,2.516271330499119647e-58,8.346912982907037298e-70\n1.689000000000000000e+03,2.326501669387000596e-58,7.598246997301286515e-70\n1.690000000000000000e+03,2.151043868781320515e-58,6.916731676755880016e-70\n1.691000000000000000e+03,1.988818570949483387e-58,6.296344025829758905e-70\n1.692000000000000000e+03,1.838827820092007332e-58,5.731601274172488252e-70\n1.693000000000000000e+03,1.700148923252491731e-58,5.217512421705135982e-70\n1.694000000000000000e+03,1.571928774218817284e-58,4.749534129897702904e-70\n1.695000000000000000e+03,1.453378605498806061e-58,4.323530569322712051e-70\n1.696000000000000000e+03,1.343769136086616556e-58,3.935736868632753617e-70\n1.697000000000000000e+03,1.242426085169452946e-58,3.582725841936556384e-70\n1.698000000000000000e+03,1.148726024177708436e-58,3.261377700521617500e-70\n1.699000000000000000e+03,1.062092541660687912e-58,2.968852481246688403e-70\n1.700000000000000000e+03,9.819926973959802839e-59,2.702564947934400445e-70\n1.701000000000000000e+03,9.079337439195891342e-59,2.460161743953209899e-70\n1.702000000000000000e+03,8.394600953080298573e-59,2.239500594069648520e-70\n1.703000000000000000e+03,7.761505245662478434e-59,2.038631371764675833e-70\n1.704000000000000000e+03,7.176155723797656901e-59,1.855778864693559362e-70\n1.705000000000000000e+03,6.634951512913443029e-59,1.689327085976412182e-70\n1.706000000000000000e+03,6.134563305632484303e-59,1.537804992667982189e-70\n1.707000000000000000e+03,5.671912880986027305e-59,1.399873485191759962e-70\n1.708000000000000000e+03,5.244154168228815685e-59,1.274313572843250220e-70\n1.709000000000000000e+03,4.848655738761976708e-59,1.160015600774154985e-70\n1.710000000000000000e+03,4.482984618465104826e-59,1.055969443248602017e-70\n1.711000000000000000e+03,4.144891320852317264e-59,9.612555765031103133e-71\n1.712000000000000000e+03,3.832296008983084530e-59,8.750369523152870853e-71\n1.713000000000000000e+03,3.543275701001516054e-59,7.965516004626545025e-71\n1.714000000000000000e+03,3.276052440593934941e-59,7.251058946948539726e-71\n1.715000000000000000e+03,3.028982359596770947e-59,6.600684227058748115e-71\n1.716000000000000000e+03,2.800545565468830774e-59,6.008644059317333661e-71\n1.717000000000000000e+03,2.589336791420273079e-59,5.469706198573488457e-71\n1.718000000000000000e+03,2.394056751681673577e-59,4.979107699402035932e-71\n1.719000000000000000e+03,2.213504148731715508e-59,4.532512822847837316e-71\n1.720000000000000000e+03,2.046568283316949928e-59,4.125974718672435153e-71\n1.721000000000000000e+03,1.892222221801067386e-59,3.755900544463854747e-71\n1.722000000000000000e+03,1.749516478812330447e-59,3.419019713345033394e-71\n1.723000000000000000e+03,1.617573176327368299e-59,3.112354989663504682e-71\n1.724000000000000000e+03,1.495580643258640488e-59,2.833196177218346283e-71\n1.725000000000000000e+03,1.382788422325598611e-59,2.579076167488368143e-71\n1.726000000000000000e+03,1.278502653492219559e-59,2.347749136184813944e-71\n1.727000000000000000e+03,1.182081805571926877e-59,2.137170695437167141e-71\n1.728000000000000000e+03,1.092932729742457314e-59,1.945479826203928172e-71\n1.729000000000000000e+03,1.010507010692317600e-59,1.770982431233626607e-71\n1.730000000000000000e+03,9.342975929533607175e-60,1.612136363221998847e-71\n1.731000000000000000e+03,8.638356616649496401e-60,1.467537795850554255e-71\n1.732000000000000000e+03,7.986877585815961072e-60,1.335908817257620980e-71\n1.733000000000000000e+03,7.384531155829163365e-60,1.216086136297640526e-71\n1.734000000000000000e+03,6.827611892819437378e-60,1.107010801778497558e-71\n1.735000000000000000e+03,6.312693815662445824e-60,1.007718843819081437e-71\n1.736000000000000000e+03,5.836609320487909203e-60,9.173327546186208978e-72\n1.737000000000000000e+03,5.396429694639090689e-60,8.350537333479570912e-72\n1.738000000000000000e+03,4.989447100212797205e-60,7.601546266253929628e-72\n1.739000000000000000e+03,4.613157916344559691e-60,6.919735021880485835e-72\n1.740000000000000000e+03,4.265247337771122389e-60,6.299077989646453965e-72\n1.741000000000000000e+03,3.943575134921821685e-60,5.734090018502694705e-72\n1.742000000000000000e+03,3.646162487941454018e-60,5.219777941205910646e-72\n1.743000000000000000e+03,3.371179813652858310e-60,4.751596446442674855e-72\n1.744000000000000000e+03,3.116935510571980330e-60,4.325407908948317000e-72\n1.745000000000000000e+03,2.881865552741775505e-60,3.937445822613989622e-72\n1.746000000000000000e+03,2.664523868367055619e-60,3.584281513414508575e-72\n1.747000000000000000e+03,2.463573444064027372e-60,3.262793837979994703e-72\n1.748000000000000000e+03,2.277778100001464515e-60,2.970141600015856985e-72\n1.749000000000000000e+03,2.105994885335065906e-60,2.703738440797816157e-72\n1.750000000000000000e+03,1.947167047156494953e-60,2.461229981832778431e-72\n1.751000000000000000e+03,1.800317529702267702e-60,2.240473017680261194e-72\n1.752000000000000000e+03,1.664542963833746023e-60,2.039516575048161637e-72\n1.753000000000000000e+03,1.539008109812007646e-60,1.856584670768754110e-72\n1.754000000000000000e+03,1.422940719182080101e-60,1.690060616277230630e-72\n1.755000000000000000e+03,1.315626784158921884e-60,1.538472729880218790e-72\n1.756000000000000000e+03,1.216406145289889446e-60,1.400481330544676849e-72\n1.757000000000000000e+03,1.124668430374760118e-60,1.274866898262729322e-72\n1.758000000000000000e+03,1.039849299659877182e-60,1.160519296357863258e-72\n1.759000000000000000e+03,9.614269742085691563e-61,1.056427960482943825e-72\n1.760000000000000000e+03,8.889190260917737022e-61,9.616729676040101890e-73\n1.761000000000000000e+03,8.218794106524686083e-61,8.754169060401679746e-73\n1.762000000000000000e+03,7.598957225882469933e-61,7.968974747104500557e-73\n1.763000000000000000e+03,7.025866589716788609e-61,7.254207461818813816e-73\n1.764000000000000000e+03,6.495996736021197865e-61,6.603550339801028380e-73\n1.765000000000000000e+03,6.006088082594840023e-61,6.011253099639493121e-73\n1.766000000000000000e+03,5.553126875180902015e-61,5.472081224266578828e-73\n1.767000000000000000e+03,5.134326647859226496e-61,4.981269700117508869e-73\n1.768000000000000000e+03,4.747111081638908672e-61,4.534480905596291319e-73\n1.769000000000000000e+03,4.389098155804784939e-61,4.127766276684900146e-73\n1.770000000000000000e+03,4.058085494523266350e-61,3.757531410907230253e-73\n1.771000000000000000e+03,3.752036818561441595e-61,3.420504301249777801e-73\n1.772000000000000000e+03,3.469069418778838716e-61,3.113706419301330693e-73\n1.773000000000000000e+03,3.207442574329797705e-61,2.834426392054501982e-73\n1.774000000000000000e+03,2.965546844330511263e-61,2.580196039733758107e-73\n1.775000000000000000e+03,2.741894167117403919e-61,2.348768562881045158e-73\n1.776000000000000000e+03,2.535108706188539762e-61,2.138098685922927725e-73\n1.777000000000000000e+03,2.343918386517996805e-61,1.946324581736525398e-73\n1.778000000000000000e+03,2.167147069175301800e-61,1.771751417468675616e-73\n1.779000000000000000e+03,2.003707316111753394e-61,1.612836376192469815e-73\n1.780000000000000000e+03,1.852593700605520912e-61,1.468175022027686311e-73\n1.781000000000000000e+03,1.712876622212093581e-61,1.336488888224767230e-73\n1.782000000000000000e+03,1.583696588173515990e-61,1.216614178520360018e-73\n1.783000000000000000e+03,1.464258926106089532e-61,1.107491481910355180e-73\n1.784000000000000000e+03,1.353828895441420677e-61,1.008156409943950262e-73\n1.785000000000000000e+03,1.251727167548367410e-61,9.177310737937976039e-74\n1.786000000000000000e+03,1.157325646730081195e-61,8.354163257797880654e-74\n1.787000000000000000e+03,1.070043606389525474e-61,7.604846967797178512e-74\n1.788000000000000000e+03,9.893441165934664007e-62,6.922739671101261248e-74\n1.789000000000000000e+03,9.147307410589467878e-62,6.301813140589678023e-74\n1.790000000000000000e+03,8.457444832434346783e-62,5.736579843481591736e-74\n1.791000000000000000e+03,7.819609627513218053e-62,5.222044444427933457e-74\n1.792000000000000000e+03,7.229878046877827280e-62,4.753659658475240491e-74\n1.793000000000000000e+03,6.684622258995123386e-62,4.327286063742115775e-74\n1.794000000000000000e+03,6.180488032539963022e-62,3.939155518647920476e-74\n1.795000000000000000e+03,5.714374102286674168e-62,3.585837860387660394e-74\n1.796000000000000000e+03,5.283413091160704479e-62,3.264210590345684781e-74\n1.797000000000000000e+03,4.884953871094790703e-62,2.971431278538991096e-74\n1.798000000000000000e+03,4.516545254174120339e-62,2.704912443208762074e-74\n1.799000000000000000e+03,4.175920913748773773e-62,2.462298683556644731e-74\n1.800000000000000000e+03,3.860985442749338637e-62,2.241445863531360403e-74\n1.801000000000000000e+03,3.569801463442828104e-62,2.040402162699798811e-74\n1.802000000000000000e+03,3.300577709333322895e-62,1.857390826736676452e-74\n1.803000000000000000e+03,3.051658005888473800e-62,1.690794465087582713e-74\n1.804000000000000000e+03,2.821511082308149520e-62,1.539140757033584974e-74\n1.805000000000000000e+03,2.608721151658064234e-62,1.401089439832814556e-74\n1.806000000000000000e+03,2.411979201421662947e-62,1.275420463944087947e-74\n1.807000000000000000e+03,2.230074940893258256e-62,1.161023210653460492e-74\n1.808000000000000000e+03,2.061889355873638852e-62,1.056886676812143504e-74\n1.809000000000000000e+03,1.906387824869290245e-62,9.620905399422016397e-75\n1.810000000000000000e+03,1.762613754446624672e-62,8.757970247464868931e-75\n1.811000000000000000e+03,1.629682694588837612e-62,7.972434991418335864e-75\n1.812000000000000000e+03,1.506776897855436948e-62,7.257357343819664059e-75\n1.813000000000000000e+03,1.393140288872979673e-62,6.606417697050808100e-75\n1.814000000000000000e+03,1.288073813212456796e-62,6.013863272844598210e-75\n1.815000000000000000e+03,1.190931137039996131e-62,5.474457281230396006e-75\n1.816000000000000000e+03,1.101114671087097371e-62,4.983432639605163812e-75\n1.817000000000000000e+03,1.018071894481471021e-62,4.536449842914922896e-75\n1.818000000000000000e+03,9.412919558230805540e-63,4.129558612617934000e-75\n1.819000000000000000e+03,8.703025305973278932e-63,3.759162985496341713e-75\n1.820000000000000000e+03,8.046669155924411555e-63,3.421989533784006235e-75\n1.821000000000000000e+03,7.439813424472448489e-63,3.115058435749399988e-75\n1.822000000000000000e+03,6.878724938033476478e-63,2.835657141067686347e-75\n1.823000000000000000e+03,6.359952067813785380e-63,2.581316398243978574e-75\n1.824000000000000000e+03,5.880303496544898860e-63,2.349788432227187363e-75\n1.825000000000000000e+03,5.436828586565938884e-63,2.139027079355665343e-75\n1.826000000000000000e+03,5.026799228486735237e-63,1.947169704074160557e-75\n1.827000000000000000e+03,4.647693058771972568e-63,1.772520737608641270e-75\n1.828000000000000000e+03,4.297177943002775686e-63,1.613536693118670736e-75\n1.829000000000000000e+03,3.973097629366392522e-63,1.468812524897617050e-75\n1.830000000000000000e+03,3.673458484115443832e-63,1.337069211067171134e-75\n1.831000000000000000e+03,3.396417227399303898e-63,1.217142450026699129e-75\n1.832000000000000000e+03,3.140269594023422812e-63,1.107972370760522915e-75\n1.833000000000000000e+03,2.903439849378787344e-63,1.008594166066400039e-75\n1.834000000000000000e+03,2.684471096050053517e-63,9.181295659249060974e-76\n1.835000000000000000e+03,2.482016311469390577e-63,8.357790756544835701e-76\n1.836000000000000000e+03,2.294830061483768858e-63,7.608149102552650490e-76\n1.837000000000000000e+03,2.121760838860906358e-63,6.925745624984072177e-76\n1.838000000000000000e+03,1.961743979601188805e-63,6.304549479175255577e-76\n1.839000000000000000e+03,1.813795113481169421e-63,5.739070749578736545e-76\n1.840000000000000000e+03,1.677004108536569985e-63,5.224311931798649097e-76\n1.841000000000000000e+03,1.550529472235086110e-63,4.755723766384368373e-76\n1.842000000000000000e+03,1.433593174895466602e-63,4.329165034057818737e-76\n1.843000000000000000e+03,1.325475863508903701e-63,3.940865957056533679e-76\n1.844000000000000000e+03,1.225512436520096225e-63,3.587394883149120105e-76\n1.845000000000000000e+03,1.133087952344514118e-63,3.265627957885875053e-76\n1.846000000000000000e+03,1.047633846453609971e-63,2.972721517059313102e-76\n1.847000000000000000e+03,9.686244337557939749e-64,2.706086955388644209e-76\n1.848000000000000000e+03,8.955736747574160186e-64,2.463367849326355726e-76\n1.849000000000000000e+03,8.280321856104811176e-64,2.242419131806162196e-76\n1.850000000000000000e+03,7.655844736532359774e-64,2.041288134886369342e-76\n1.851000000000000000e+03,7.078463814383923699e-64,1.858197332749148988e-76\n1.852000000000000000e+03,6.544627235248562849e-64,1.691528632545674826e-76\n1.853000000000000000e+03,6.051051014955840116e-64,1.539809074254065685e-76\n1.854000000000000000e+03,5.594698837604385298e-64,1.401697813170856934e-76\n1.855000000000000000e+03,5.172763377160091631e-64,1.275974269991723098e-76\n1.856000000000000000e+03,4.782649027726051685e-64,1.161527343755979713e-76\n1.857000000000000000e+03,4.421955936242253024e-64,1.057345592322590403e-76\n1.858000000000000000e+03,4.088465239391505811e-64,9.625082935963261887e-77\n1.859000000000000000e+03,3.780125413894981632e-64,8.761773085058316828e-77\n1.860000000000000000e+03,3.495039656225868534e-64,7.975896738220620356e-77\n1.861000000000000000e+03,3.231454214108992386e-64,7.260508593545128936e-77\n1.862000000000000000e+03,2.987747598022740199e-64,6.609286299348842817e-77\n1.863000000000000000e+03,2.762420606337365883e-64,6.016474579424903571e-77\n1.864000000000000000e+03,2.554087102728360226e-64,5.476834369912423453e-77\n1.865000000000000000e+03,2.361465489128517160e-64,4.985596518272345529e-77\n1.866000000000000000e+03,2.183370821765618698e-64,4.538419635174541845e-77\n1.867000000000000000e+03,2.018707521784227880e-64,4.131351726809084939e-77\n1.868000000000000000e+03,1.866462635610675300e-64,3.760795268538889625e-77\n1.869000000000000000e+03,1.725699603601717434e-64,3.423475411227820858e-77\n1.870000000000000000e+03,1.595552498642264932e-64,3.116411039262692092e-77\n1.871000000000000000e+03,1.475220699251623288e-64,2.836888424490007623e-77\n1.872000000000000000e+03,1.363963964427627380e-64,2.582437243230026055e-77\n1.873000000000000000e+03,1.261097879931357662e-64,2.350808744415311873e-77\n1.874000000000000000e+03,1.165989647999821468e-64,2.139955875910224583e-77\n1.875000000000000000e+03,1.078054194585363305e-64,1.948015193376216737e-77\n1.876000000000000000e+03,9.967505701759663042e-65,1.773290391798610212e-77\n1.877000000000000000e+03,9.215786220545828141e-65,1.614237314132675180e-77\n1.878000000000000000e+03,8.520759175267516606e-65,1.469450304580574072e-77\n1.879000000000000000e+03,7.878148991894423573e-65,1.337649785894124751e-77\n1.880000000000000000e+03,7.284002547406437542e-65,1.217670950916146826e-77\n1.881000000000000000e+03,6.734664851504053776e-65,1.108453468419566566e-77\n1.882000000000000000e+03,6.226756562329167465e-65,1.009032112268873083e-77\n1.883000000000000000e+03,5.757153197883214316e-65,9.185282310870988573e-78\n1.884000000000000000e+03,5.322965915259707525e-65,8.361419830404551173e-78\n1.885000000000000000e+03,4.921523739447061269e-65,7.611452671143102895e-78\n1.886000000000000000e+03,4.550357132384514922e-65,6.928752884095815510e-78\n1.887000000000000000e+03,4.207182801188388584e-65,6.307287005918522345e-78\n1.888000000000000000e+03,3.889889652098553822e-65,5.741562737263242879e-78\n1.889000000000000000e+03,3.596525803734928176e-65,5.226580403745089227e-78\n1.890000000000000000e+03,3.325286579775473370e-65,4.757788770559197256e-78\n1.891000000000000000e+03,3.074503407191498481e-65,4.331044820249783978e-78\n1.892000000000000000e+03,2.842633551743414185e-65,3.942577138162401164e-78\n1.893000000000000000e+03,2.628250627596091865e-65,3.588952581992527627e-78\n1.894000000000000000e+03,2.430035822669751820e-65,3.267045940867497075e-78\n1.895000000000000000e+03,2.246769785748750840e-65,2.974012315819812557e-78\n1.896000000000000000e+03,2.077325125441026721e-65,2.707261977558657119e-78\n1.897000000000000000e+03,1.920659474842616376e-65,2.464437479343267354e-78\n1.898000000000000000e+03,1.775809079245376714e-65,2.243392822688216020e-78\n1.899000000000000000e+03,1.641882867440001084e-65,2.042174491774959955e-78\n1.900000000000000000e+03,1.518056970143707780e-65,1.859004188958272539e-78\n1.901000000000000000e+03,1.403569651832164954e-65,1.692263118789964487e-78\n1.902000000000000000e+03,1.297716624796839462e-65,1.540477681667524202e-78\n1.903000000000000000e+03,1.199846716602759415e-65,1.402306450673378899e-78\n1.904000000000000000e+03,1.109357864293247140e-65,1.276528316509933218e-78\n1.905000000000000000e+03,1.025693410699799497e-65,1.162031695760364463e-78\n1.906000000000000000e+03,9.483386800735019536e-66,1.057804707100832239e-78\n1.907000000000000000e+03,8.768178119716394106e-66,9.629262286451683858e-79\n1.908000000000000000e+03,8.106908339235366341e-66,8.765577573899202340e-79\n1.909000000000000000e+03,7.495509548669109520e-66,7.979359988163303536e-79\n1.910000000000000000e+03,6.930220627051925747e-66,7.263661211588684327e-79\n1.911000000000000000e+03,6.407564105917938075e-66,6.612156147235378111e-79\n1.912000000000000000e+03,5.924324777075983302e-66,6.019087019872195655e-79\n1.913000000000000000e+03,5.477529913725047913e-66,5.479212490760959424e-79\n1.914000000000000000e+03,5.064430983232161638e-66,4.987761336527142646e-79\n1.915000000000000000e+03,4.682486739078101860e-66,4.540390282746632276e-79\n1.916000000000000000e+03,4.329347587959377514e-66,4.133145619596519792e-79\n1.917000000000000000e+03,4.002841135874600665e-66,3.762428260342281319e-79\n1.918000000000000000e+03,3.700958824283758900e-66,3.424961933861056092e-79\n1.919000000000000000e+03,3.421843574127122133e-66,3.117764230095941554e-79\n1.920000000000000000e+03,3.163778361695438056e-66,2.838120242553352639e-79\n1.921000000000000000e+03,2.925175656074773801e-66,2.583558574903282060e-79\n1.922000000000000000e+03,2.704567653186304076e-66,2.351829499637841024e-79\n1.923000000000000000e+03,2.500597246346935912e-66,2.140885075761767247e-79\n1.924000000000000000e+03,2.312009677802399119e-66,1.948861049801924912e-79\n1.925000000000000000e+03,2.137644819876833334e-66,1.774060380183531062e-79\n1.926000000000000000e+03,1.976430038255632703e-66,1.614938239366430861e-79\n1.927000000000000000e+03,1.827373593497222332e-66,1.470088361196669382e-79\n1.928000000000000000e+03,1.689558540183978008e-66,1.338230612815119609e-79\n1.929000000000000000e+03,1.562137086180366439e-66,1.218199681288374014e-79\n1.930000000000000000e+03,1.444325377299026506e-66,1.108934774978216806e-79\n1.931000000000000000e+03,1.335398675292171719e-66,1.009470248633962158e-79\n1.932000000000000000e+03,1.234686899503831319e-66,9.189270693554555198e-80\n1.933000000000000000e+03,1.141570504757983578e-66,8.365050480060486263e-80\n1.934000000000000000e+03,1.055476670123458066e-66,7.614757674190691931e-80\n1.935000000000000000e+03,9.758757751113070049e-67,6.931761449002846308e-80\n1.936000000000000000e+03,9.022781416265010216e-67,6.310025721335747758e-80\n1.937000000000000000e+03,8.342310216319217647e-67,5.744055807005076271e-80\n1.938000000000000000e+03,7.713158119939752813e-67,5.228849860695071608e-80\n1.939000000000000000e+03,7.131454793758578832e-67,4.759854671388627901e-80\n1.940000000000000000e+03,6.593621793380202332e-67,4.332925422672031383e-80\n1.941000000000000000e+03,6.096350549987285911e-67,3.944289062287789605e-80\n1.942000000000000000e+03,5.636582017130898896e-67,3.590510957211243494e-80\n1.943000000000000000e+03,5.211487852500638698e-67,3.268464539557971077e-80\n1.944000000000000000e+03,4.818453018906940749e-67,2.975303675063923994e-80\n1.945000000000000000e+03,4.455059697447613669e-67,2.708437509940401202e-80\n1.946000000000000000e+03,4.119072413893738847e-67,2.465507573809102459e-80\n1.947000000000000000e+03,3.808424286799227505e-67,2.244366936360896713e-80\n1.948000000000000000e+03,3.521204312737966209e-67,2.043061233532497874e-80\n1.949000000000000000e+03,3.255645610448693045e-67,1.859811395516001030e-80\n1.950000000000000000e+03,3.010114551572911417e-67,1.692997923958776249e-80\n1.951000000000000000e+03,2.783100711119011372e-67,1.541146579400054166e-80\n1.952000000000000000e+03,2.573207575832454605e-67,1.402915352455164086e-80\n1.953000000000000000e+03,2.379143953313653352e-67,1.277082603603206681e-80\n1.954000000000000000e+03,2.199716029033373076e-67,1.162536266761698500e-80\n1.955000000000000000e+03,2.033820022385352952e-67,1.058264021233333747e-80\n1.956000000000000000e+03,1.880435396596784639e-67,9.633443451674376290e-81\n1.957000000000000000e+03,1.738618580727112340e-67,8.769383714704025870e-81\n1.958000000000000000e+03,1.607497165135427246e-67,7.982824741899524783e-81\n1.959000000000000000e+03,1.486264534707595373e-67,7.266815198544885651e-81\n1.960000000000000000e+03,1.374174906830074703e-67,6.615027241251640237e-81\n1.961000000000000000e+03,1.270538743584438552e-67,6.021700594679156940e-81\n1.962000000000000000e+03,1.174718509940519603e-67,5.481591644223873759e-81\n1.963000000000000000e+03,1.086124751854293279e-67,4.989927094777255438e-81\n1.964000000000000000e+03,1.004212470143377193e-67,4.542361786002326195e-81\n1.965000000000000000e+03,9.284777678344898602e-68,4.134940291318079932e-81\n1.966000000000000000e+03,8.584547503576192781e-68,3.764061961214484801e-81\n1.967000000000000000e+03,7.937126595183152286e-68,3.426449101964057322e-81\n1.968000000000000000e+03,7.338532236174528879e-68,3.119118008504348800e-81\n1.969000000000000000e+03,6.785082074166980858e-68,2.839352595489950887e-81\n1.970000000000000000e+03,6.273371468785794140e-68,2.584680393474926577e-81\n1.971000000000000000e+03,5.800252547454773153e-68,2.352850698087012064e-81\n1.972000000000000000e+03,5.362814840736059714e-68,2.141814679085290079e-81\n1.973000000000000000e+03,4.958367378096306253e-68,1.949707273510805703e-81\n1.974000000000000000e+03,4.584422133954289649e-68,1.774830702908616677e-81\n1.975000000000000000e+03,4.238678722180354649e-68,1.615639468952125603e-81\n1.976000000000000000e+03,3.919010244889488383e-68,1.470726694866235206e-81\n1.977000000000000000e+03,3.623450208476268714e-68,1.338811691939542046e-81\n1.978000000000000000e+03,3.350180426404402673e-68,1.218728641242955862e-81\n1.979000000000000000e+03,3.097519834330124295e-68,1.109416290527117995e-81\n1.980000000000000000e+03,2.863914148757139474e-68,1.009908575244181321e-81\n1.981000000000000000e+03,2.647926305603424083e-68,9.193260808051943972e-82\n1.982000000000000000e+03,2.448227619864025214e-68,8.368682706197353262e-82\n1.983000000000000000e+03,2.263589611984815588e-68,7.618064112318713325e-82\n1.984000000000000000e+03,2.092876450666789255e-68,6.934771320272357913e-82\n1.985000000000000000e+03,1.935037965612082946e-68,6.312765625942714576e-82\n1.986000000000000000e+03,1.789103187226884673e-68,5.746549959273755238e-82\n1.987000000000000000e+03,1.654174373541505989e-68,5.231120303075997987e-82\n1.988000000000000000e+03,1.529421487601714636e-68,4.761921469262270011e-82\n1.989000000000000000e+03,1.414077091358762382e-68,4.334806841679225794e-82\n1.990000000000000000e+03,1.307431624647374378e-68,3.946001729755552904e-82\n1.991000000000000000e+03,1.208829040208489087e-68,3.592070009099164084e-82\n1.992000000000000000e+03,1.117662767906117798e-68,3.269883754224460839e-82\n1.993000000000000000e+03,1.033371983310520989e-68,2.976595595034847370e-82\n1.994000000000000000e+03,9.554381576937240792e-69,2.709613552755262655e-82\n1.995000000000000000e+03,8.833818682143376966e-69,2.466578132925391424e-82\n1.996000000000000000e+03,8.167598486682851347e-69,2.245341473007914008e-82\n1.997000000000000000e+03,7.551622626634898131e-69,2.043948360326214701e-82\n1.998000000000000000e+03,6.982101824433152370e-69,1.860618952574567182e-82\n1.999000000000000000e+03,6.455532578496297159e-69,1.693733048190688589e-82\n2.000000000000000000e+03,5.968675610858992640e-69,1.541815767577628960e-82\n2.001000000000000000e+03,5.518535940215206786e-69,1.403524518630886783e-82\n2.002000000000000000e+03,5.102344457795731526e-69,1.277637131375931793e-82\n2.003000000000000000e+03,4.717540892736183206e-69,1.163041056855105754e-82\n2.004000000000000000e+03,4.361758062146191717e-69,1.058723534806717681e-82\n2.005000000000000000e+03,4.032807308992575948e-69,9.637626432419873407e-83\n2.006000000000000000e+03,3.728665038211920833e-69,8.773191508190590789e-83\n2.007000000000000000e+03,3.447460268231103685e-69,7.986291000081800460e-83\n2.008000000000000000e+03,3.187463121313747228e-69,7.269970555007721907e-83\n2.009000000000000000e+03,2.947074181930443803e-69,6.617899581938340651e-83\n2.010000000000000000e+03,2.724814657689756283e-69,6.024315304338002944e-83\n2.011000000000000000e+03,2.519317282301096244e-69,5.483971830749852281e-83\n2.012000000000000000e+03,2.329317904610170817e-69,4.992093793431127026e-83\n2.013000000000000000e+03,2.153647711963425058e-69,4.544334145313432195e-83\n2.014000000000000000e+03,1.991226040063175828e-69,4.136735742312225649e-83\n2.015000000000000000e+03,1.841053725082556504e-69,3.765696371463173345e-83\n2.016000000000000000e+03,1.702206957143209819e-69,3.427936915816902808e-83\n2.017000000000000000e+03,1.573831597346142070e-69,3.120472374742869634e-83\n2.018000000000000000e+03,1.455137923394581267e-69,2.840585483532133234e-83\n2.019000000000000000e+03,1.345395771486303577e-69,2.585802699156524523e-83\n2.020000000000000000e+03,1.243930044590313451e-69,2.353872339955415321e-83\n2.021000000000000000e+03,1.150116559475278048e-69,2.142744686056107649e-83\n2.022000000000000000e+03,1.063378206943223074e-69,1.950553864662228026e-83\n2.023000000000000000e+03,9.831814016465540468e-70,1.775601360118942341e-83\n2.024000000000000000e+03,9.090327996493041186e-70,1.616341003021822806e-83\n2.025000000000000000e+03,8.404762635403657475e-70,1.471365305709488758e-83\n2.026000000000000000e+03,7.770900564284111332e-70,1.339393023376978931e-83\n2.027000000000000000e+03,7.184842475577257137e-70,1.219257830879649707e-83\n2.028000000000000000e+03,6.642983135843699704e-70,1.109898015157079641e-83\n2.029000000000000000e+03,6.141989207572474467e-70,1.010347092182195103e-83\n2.030000000000000000e+03,5.678778743602308916e-70,9.197252655114606559e-84\n2.031000000000000000e+03,5.250502228012581343e-70,8.372316509499204691e-84\n2.032000000000000000e+03,4.854525046855121167e-70,7.621371986149868045e-84\n2.033000000000000000e+03,4.488411280888723029e-70,6.937782498471787259e-84\n2.034000000000000000e+03,4.149908720619355658e-70,6.315506720256146972e-84\n2.035000000000000000e+03,3.836935011459798845e-70,5.749045194539654915e-84\n2.036000000000000000e+03,3.547564843780078265e-70,5.233391731316056416e-84\n2.037000000000000000e+03,3.280018109047033533e-70,4.763989164569364512e-84\n2.038000000000000000e+03,3.032648949190882869e-70,4.336689077625692783e-84\n2.039000000000000000e+03,2.803935631837295277e-70,3.947715140888236812e-84\n2.040000000000000000e+03,2.592471189118229771e-70,3.593629737949904578e-84\n2.041000000000000000e+03,2.396954762475764065e-70,3.271303585134616823e-84\n2.042000000000000000e+03,2.216183600215659749e-70,2.977888075976228653e-84\n2.043000000000000000e+03,2.049045658580452050e-70,2.710790106225033771e-84\n2.044000000000000000e+03,1.894512760828493075e-70,2.467649156894032092e-84\n2.045000000000000000e+03,1.751634272234143014e-70,2.246316432812801505e-84\n2.046000000000000000e+03,1.619531252100607755e-70,2.044835872323182566e-84\n2.047000000000000000e+03,1.497391046810960007e-70,1.861426860286057481e-84\n2.048000000000000000e+03,1.384462290654376758e-70,1.694468491624147230e-84\n2.049000000000000000e+03,1.280050283675794655e-70,1.542485246326451626e-84\n2.050000000000000000e+03,1.183512718113879033e-70,1.404133949315430138e-84\n2.051000000000000000e+03,1.094255727138314486e-70,1.278191899932687827e-84\n2.052000000000000000e+03,1.011730231579835344e-70,1.163546066135653525e-84\n2.053000000000000000e+03,9.354285621784778030e-71,1.059183247907523786e-84\n2.054000000000000000e+03,8.648813365722246310e-71,9.641811229475950026e-85\n2.055000000000000000e+03,7.996545718135323927e-71,8.777000955076015369e-85\n2.056000000000000000e+03,7.393470146512596678e-71,7.989758763363834239e-85\n2.057000000000000000e+03,6.835876731549688999e-71,7.273127281572264374e-85\n2.058000000000000000e+03,6.320335344964189451e-71,6.620773169837179425e-85\n2.059000000000000000e+03,5.843674548494633838e-71,6.026931149341844288e-85\n2.060000000000000000e+03,5.402962084271876470e-71,5.486353050787156873e-85\n2.061000000000000000e+03,4.995486836548539275e-71,4.994261432896808242e-85\n2.062000000000000000e+03,4.618742153822361845e-71,4.546307361051404263e-85\n2.063000000000000000e+03,4.270410428752961082e-71,4.138531972917094170e-85\n2.064000000000000000e+03,3.948348841017252985e-71,3.767331491396584066e-85\n2.065000000000000000e+03,3.650576175394723457e-71,3.429425375700180377e-85\n2.066000000000000000e+03,3.375260633993447832e-71,3.121827329066926269e-85\n2.067000000000000000e+03,3.120708567642574245e-71,2.841818906912088607e-85\n2.068000000000000000e+03,2.885354057128020557e-71,2.586925492159438870e-85\n2.069000000000000000e+03,2.667749280181632174e-71,2.354894425435455455e-85\n2.070000000000000000e+03,2.466555604962295912e-71,2.143675096849368142e-85\n2.071000000000000000e+03,2.280535355240176782e-71,1.951400823415851804e-85\n2.072000000000000000e+03,2.108544196626812655e-71,1.776372351959846930e-85\n2.073000000000000000e+03,1.949524097011973248e-71,1.617042841707824335e-85\n2.074000000000000000e+03,1.802496817904323259e-71,1.472004193846866473e-85\n2.075000000000000000e+03,1.666557896634793142e-71,1.339974607236911711e-85\n2.076000000000000000e+03,1.540871082404990651e-71,1.219787250298118075e-85\n2.077000000000000000e+03,1.424663191951675579e-71,1.110379948958824706e-85\n2.078000000000000000e+03,1.317219353181694298e-71,1.010785799530589236e-85\n2.079000000000000000e+03,1.217878607518136786e-71,9.201246235495370605e-86\n2.080000000000000000e+03,1.126029843903819751e-71,8.375951890651345164e-86\n2.081000000000000000e+03,1.041108039450621673e-71,7.624681296307990958e-86\n2.082000000000000000e+03,9.625907836074461138e-72,6.940794984168227786e-86\n2.083000000000000000e+03,8.899950644650818427e-72,6.318249004792271245e-86\n2.084000000000000000e+03,8.228742974286048737e-72,5.751541513272703333e-86\n2.085000000000000000e+03,7.608155779780362786e-72,5.235664145843023781e-86\n2.086000000000000000e+03,7.034371416179460510e-72,4.766057757699859381e-86\n2.087000000000000000e+03,6.503860153898232470e-72,4.338572130866406922e-86\n2.088000000000000000e+03,6.013358465003859234e-72,3.949429296008975491e-86\n2.089000000000000000e+03,5.559848947084295633e-72,3.595190144057615676e-86\n2.090000000000000000e+03,5.140541761195943101e-72,3.272724032555836261e-86\n2.091000000000000000e+03,4.752857469708312597e-72,2.979181118131478329e-86\n2.092000000000000000e+03,4.394411168465495755e-72,2.711967170571294333e-86\n2.093000000000000000e+03,4.062997815652751882e-72,2.468720645916730039e-86\n2.094000000000000000e+03,3.756578667117302140e-72,2.247291815959428672e-86\n2.095000000000000000e+03,3.473268734694907495e-72,2.045723769690778495e-86\n2.096000000000000000e+03,3.211325190393642362e-72,1.862235118802836665e-86\n2.097000000000000000e+03,2.969136645098357045e-72,1.695204254397801884e-86\n2.098000000000000000e+03,2.745213235843314359e-72,1.543155015772604564e-86\n2.099000000000000000e+03,2.538177460673888121e-72,1.404743644623568209e-86\n2.100000000000000000e+03,2.346755704714395468e-72,1.278746909377954024e-86\n2.101000000000000000e+03,2.169770405315701097e-72,1.164051294698582031e-86\n2.102000000000000000e+03,2.006132808083215265e-72,1.059643160622450156e-86\n2.103000000000000000e+03,1.854836269223682771e-72,9.645997843631826224e-87\n2.104000000000000000e+03,1.714950063009496096e-72,8.780812056078732674e-87\n2.105000000000000000e+03,1.585613656264728005e-72,7.993228032398710906e-87\n2.106000000000000000e+03,1.466031414653079440e-72,7.276285378833019635e-87\n2.107000000000000000e+03,1.355467708201259400e-72,6.623648005489336023e-87\n2.108000000000000000e+03,1.253242385949210929e-72,6.029548130183319325e-87\n2.109000000000000000e+03,1.158726591889056780e-72,5.488735304784864521e-87\n2.110000000000000000e+03,1.071338896452870681e-72,4.996430013583099509e-87\n2.111000000000000000e+03,9.905417197525995392e-73,4.548281433588372014e-87\n2.112000000000000000e+03,9.158380245681933835e-73,4.140328983471437958e-87\n2.113000000000000000e+03,8.467682587407200466e-73,3.768967321322657107e-87\n2.114000000000000000e+03,7.829075281612989583e-73,3.430914481894209960e-87\n2.115000000000000000e+03,7.238629829643873584e-73,3.123182871731696618e-87\n2.116000000000000000e+03,6.692714008469059245e-73,2.843052865862429706e-87\n2.117000000000000000e+03,6.187969526459808568e-73,2.588048772695419964e-87\n2.118000000000000000e+03,5.721291364301564070e-73,2.355916954719889257e-87\n2.119000000000000000e+03,5.289808673954399380e-73,2.144605911640538205e-87\n2.120000000000000000e+03,4.890867118154252824e-73,1.952248149931184015e-87\n2.121000000000000000e+03,4.522012541818705691e-73,1.777143678576530339e-87\n2.122000000000000000e+03,4.180975874904184168e-73,1.617744985142308297e-87\n2.123000000000000000e+03,3.865659173846589223e-73,1.472643359398689822e-87\n2.124000000000000000e+03,3.574122715713391564e-73,1.340556443629022668e-87\n2.125000000000000000e+03,3.304573065676344348e-73,1.220316899598204087e-87\n2.126000000000000000e+03,3.055352044400691435e-73,1.110862092023241835e-87\n2.127000000000000000e+03,2.824926527479457232e-73,1.011224697372100133e-87\n2.128000000000000000e+03,2.611879014165278076e-73,9.205241549946346204e-88\n2.129000000000000000e+03,2.414898907379383935e-73,8.379588850338425672e-88\n2.130000000000000000e+03,2.232774451356324996e-73,7.627992043416323331e-88\n2.131000000000000000e+03,2.064385277328084896e-73,6.943808777929809540e-88\n2.132000000000000000e+03,1.908695511389438077e-73,6.320992480068259235e-88\n2.133000000000000000e+03,1.764747402148422767e-73,5.754038915943682413e-88\n2.134000000000000000e+03,1.631655428959756556e-73,5.237937547085456066e-88\n2.135000000000000000e+03,1.508600854497736413e-73,4.768127249043332344e-88\n2.136000000000000000e+03,1.394826688158249612e-73,4.340456001756002179e-88\n2.137000000000000000e+03,1.289633029305283912e-73,3.951144195440596407e-88\n2.138000000000000000e+03,1.192372761716494094e-73,3.596751227716169358e-88\n2.139000000000000000e+03,1.102447572740400254e-73,3.274145096756002661e-88\n2.140000000000000000e+03,1.019304272676889877e-73,2.980474721744455175e-88\n2.141000000000000000e+03,9.424313917393403425e-74,2.713144746016027343e-88\n2.142000000000000000e+03,8.713560336632362013e-74,2.469792600195558848e-88\n2.143000000000000000e+03,8.056409666066440773e-74,2.248267622631488267e-88\n2.144000000000000000e+03,7.448819334459964773e-74,2.046612052596220029e-88\n2.145000000000000000e+03,6.887051649213569043e-74,1.863043728277123568e-88\n2.146000000000000000e+03,6.367650803330356795e-74,1.695940336650363221e-88\n2.147000000000000000e+03,5.887421616444917311e-74,1.543825076042400371e-88\n2.148000000000000000e+03,5.443409879143244318e-74,1.405353604670284326e-88\n2.149000000000000000e+03,5.032884179653407097e-74,1.279302159816400437e-88\n2.150000000000000000e+03,4.653319101113066992e-74,1.164556742639040776e-88\n2.151000000000000000e+03,4.302379686050218417e-74,1.060103273038111841e-88\n2.152000000000000000e+03,3.977907072504305654e-74,9.650186275675961325e-89\n2.153000000000000000e+03,3.677905213430082631e-74,8.784624811916480200e-89\n2.154000000000000000e+03,3.400528597683052063e-74,7.996698807840702325e-89\n2.155000000000000000e+03,3.144070897051616545e-74,7.279444847385575001e-89\n2.156000000000000000e+03,2.906954469497036402e-74,6.626524089436979964e-89\n2.157000000000000000e+03,2.687720654026277854e-74,6.032166247355971499e-89\n2.158000000000000000e+03,2.485020797497842482e-74,5.491118593191622361e-89\n2.159000000000000000e+03,2.297607958158218658e-74,4.998599535898408119e-89\n2.160000000000000000e+03,2.124329234872896829e-74,4.550256363296112304e-89\n2.161000000000000000e+03,1.964118674864476538e-74,4.142126774313687163e-89\n2.162000000000000000e+03,1.815990716327027291e-74,3.770603861549895959e-89\n2.163000000000000000e+03,1.679034125579758365e-74,3.432404234679826022e-89\n2.164000000000000000e+03,1.552406391461851758e-74,3.124539002992823759e-89\n2.165000000000000000e+03,1.435328542485338498e-74,2.844287360615547663e-89\n2.166000000000000000e+03,1.327080354863232757e-74,2.589172540976012941e-89\n2.167000000000000000e+03,1.226995921933227622e-74,2.356939928001288687e-89\n2.168000000000000000e+03,1.134459557722840857e-74,2.145537130604918028e-89\n2.169000000000000000e+03,1.048902009454848858e-74,1.953095844368023673e-89\n2.170000000000000000e+03,9.697969556947467539e-75,1.777915340114458919e-89\n2.171000000000000000e+03,8.966577685971250869e-75,1.618447433457692017e-89\n2.172000000000000000e+03,8.290345203337778890e-75,1.473282802485499765e-89\n2.173000000000000000e+03,7.665112152882991908e-75,1.341138532662888286e-89\n2.174000000000000000e+03,7.087032309899219129e-75,1.220846778879656740e-89\n2.175000000000000000e+03,6.552549520448246298e-75,1.111344444441132887e-89\n2.176000000000000000e+03,6.058375825090365307e-75,1.011663785789385404e-89\n2.177000000000000000e+03,5.601471232456627860e-75,9.209238599221013796e-90\n2.178000000000000000e+03,5.179025018239449194e-75,8.383227389246342922e-90\n2.179000000000000000e+03,4.788438434554978114e-75,7.631304228099241772e-90\n2.180000000000000000e+03,4.427308723316002364e-75,6.946823880324120265e-90\n2.181000000000000000e+03,4.093414335266938781e-75,6.323737146600787463e-90\n2.182000000000000000e+03,3.784701263755178316e-75,5.756537403022928057e-90\n2.183000000000000000e+03,3.499270409169649705e-75,5.240211935471503848e-90\n2.184000000000000000e+03,3.235365896313994272e-75,4.770197638990070728e-90\n2.185000000000000000e+03,2.991364272850104672e-75,4.342340690649760078e-90\n2.186000000000000000e+03,2.765764522361724970e-75,3.952859839506512230e-90\n2.187000000000000000e+03,2.557178830603046385e-75,3.598312989219970739e-90\n2.188000000000000000e+03,2.364324048129978389e-75,3.275566778002744793e-90\n2.189000000000000000e+03,2.186013796793125121e-75,2.981768887058780967e-90\n2.190000000000000000e+03,2.021151171536529630e-75,2.714322832781005752e-90\n2.191000000000000000e+03,1.868721992604236409e-75,2.470865019932399189e-90\n2.192000000000000000e+03,1.727788566645339289e-75,2.249243853013009445e-90\n2.193000000000000000e+03,1.597483918338337367e-75,2.047500721207029317e-90\n2.194000000000000000e+03,1.477006457048381992e-75,1.863852688861414486e-90\n2.195000000000000000e+03,1.365615045710009722e-75,1.696676738520456746e-90\n2.196000000000000000e+03,1.262624441599524157e-75,1.544495427262031321e-90\n2.197000000000000000e+03,1.167401080950744132e-75,1.405963829570451372e-90\n2.198000000000000000e+03,1.079359181482771771e-75,1.279857651352596915e-90\n2.199000000000000000e+03,9.979571388629555664e-76,1.165062410052353094e-90\n2.200000000000000000e+03,9.226941949383257382e-76,1.060563585241282000e-90\n2.201000000000000000e+03,8.531073572387389239e-76,9.654376526398260693e-91\n2.202000000000000000e+03,7.887685508019169095e-76,8.788439223308314138e-91\n2.203000000000000000e+03,7.292819847995589957e-76,8.000171090343458095e-91\n2.204000000000000000e+03,6.742817177642936225e-76,7.282605687824954095e-91\n2.205000000000000000e+03,6.234294064402637176e-76,6.629401422221765114e-91\n2.206000000000000000e+03,5.764122244084551116e-76,6.034785501352867962e-91\n2.207000000000000000e+03,5.329409376831019069e-76,5.493502916456899305e-91\n2.208000000000000000e+03,4.927481254410150918e-76,5.000770000251885954e-91\n2.209000000000000000e+03,4.555865349379519957e-76,4.552232150547081160e-91\n2.210000000000000000e+03,4.212275604924972208e-76,4.143925345782772064e-91\n2.211000000000000000e+03,3.894598371802858765e-76,3.772241112386509568e-91\n2.212000000000000000e+03,3.600879405876201590e-76,3.433894634337592569e-91\n2.213000000000000000e+03,3.329311846258856407e-76,3.125895723105707411e-91\n2.214000000000000000e+03,3.078225100110536920e-76,2.845522391404257222e-91\n2.215000000000000000e+03,2.846074565708937390e-76,2.590296797213152420e-91\n2.216000000000000000e+03,2.631432130575575529e-76,2.357963345472578165e-91\n2.217000000000000000e+03,2.432977386205862125e-76,2.146468753918128020e-91\n2.218000000000000000e+03,2.249489505357117001e-76,1.953943906886016172e-91\n2.219000000000000000e+03,2.079839731927333017e-76,1.778687336718958718e-91\n2.220000000000000000e+03,1.922984437225437452e-76,1.619150186786267376e-91\n2.221000000000000000e+03,1.777958699915982450e-76,1.473922523227722245e-91\n2.222000000000000000e+03,1.643870370146080318e-76,1.341720874448285479e-91\n2.223000000000000000e+03,1.519894581337566929e-76,1.221376888242406694e-91\n2.224000000000000000e+03,1.405268675883458442e-76,1.111827006303464894e-91\n2.225000000000000000e+03,1.299287513533616142e-76,1.012103064865223916e-91\n2.226000000000000000e+03,1.201299133607330601e-76,9.213237384072134816e-92\n2.227000000000000000e+03,1.110700744349441962e-76,8.386867508060341758e-92\n2.228000000000000000e+03,1.026935014756853619e-76,7.634617850980531817e-92\n2.229000000000000000e+03,9.494866460644402864e-77,6.949840291919778636e-92\n2.230000000000000000e+03,8.778792017995205238e-77,6.326483004907477907e-92\n2.231000000000000000e+03,8.116721769037254722e-77,5.759036974981633025e-92\n2.232000000000000000e+03,7.504582878933315017e-77,5.242487311430095893e-92\n2.233000000000000000e+03,6.938609673873389770e-77,4.772268927929991491e-92\n2.234000000000000000e+03,6.415320475907804763e-77,4.344226197902623772e-92\n2.235000000000000000e+03,5.931496184829793382e-77,3.954576228529831235e-92\n2.236000000000000000e+03,5.484160475345674320e-77,3.599875428863146743e-92\n2.237000000000000000e+03,5.070561487717916804e-77,3.276989076564178799e-92\n2.238000000000000000e+03,4.688154899243403466e-77,2.983063614318525247e-92\n2.239000000000000000e+03,4.334588272430396270e-77,2.715501431088406453e-92\n2.240000000000000000e+03,4.007686583590457891e-77,2.471937905329429838e-92\n2.241000000000000000e+03,3.705438842818815759e-77,2.250220507287845037e-92\n2.242000000000000000e+03,3.425985723057612637e-77,2.048389775690569245e-92\n2.243000000000000000e+03,3.167608122137031234e-77,1.864662000708060649e-92\n2.244000000000000000e+03,2.928716587433214251e-77,1.697413460146961671e-92\n2.245000000000000000e+03,2.707841538087721588e-77,1.545166069557919880e-92\n2.246000000000000000e+03,2.503624224636681073e-77,1.406574319439152862e-92\n2.247000000000000000e+03,2.314808370438907243e-77,1.280413384091304663e-92\n2.248000000000000000e+03,2.140232443481716456e-77,1.165568297033750322e-92\n2.249000000000000000e+03,1.978822511024127908e-77,1.061024097318651171e-92\n2.250000000000000000e+03,1.829585633122095753e-77,9.658568596587869185e-93\n2.251000000000000000e+03,1.691603754393448142e-77,8.792255290972598898e-93\n2.252000000000000000e+03,1.564028056448477330e-77,8.003644880561821402e-93\n2.253000000000000000e+03,1.446073736242794218e-77,7.285767900747261268e-93\n2.254000000000000000e+03,1.337015178231249146e-77,6.632280004386327689e-93\n2.255000000000000000e+03,1.236181490623968684e-77,6.037405892667976633e-93\n2.256000000000000000e+03,1.142952378284031203e-77,5.495888275029732902e-93\n2.257000000000000000e+03,1.056754326879414506e-77,5.002941407052297467e-93\n2.258000000000000000e+03,9.770570748144341529e-78,4.554208795713374852e-93\n2.259000000000000000e+03,9.033703512376013287e-78,4.145724698217769200e-93\n2.260000000000000000e+03,8.352408600594417651e-78,3.773879074141269274e-93\n2.261000000000000000e+03,7.722494914262784444e-78,3.435385681148585369e-93\n2.262000000000000000e+03,7.140087434967211102e-78,3.127253032326213403e-93\n2.263000000000000000e+03,6.601603386596985730e-78,2.846757958461151760e-93\n2.264000000000000000e+03,6.103730195305224449e-78,2.591421541618567044e-93\n2.265000000000000000e+03,5.643405111661274183e-78,2.358987207326496461e-93\n2.266000000000000000e+03,5.217796369639679681e-78,2.147400781755619418e-93\n2.267000000000000000e+03,4.824285766543408334e-78,1.954792337645098630e-93\n2.268000000000000000e+03,4.460452556694896222e-78,1.779459668535621630e-93\n2.269000000000000000e+03,4.124058559818943408e-78,1.619853245260567830e-93\n2.270000000000000000e+03,3.813034392505422723e-78,1.474562521746003209e-93\n2.271000000000000000e+03,3.525466738054052321e-78,1.342303469094886513e-93\n2.272000000000000000e+03,3.259586576390461240e-78,1.221907227786288904e-93\n2.273000000000000000e+03,3.013758301645245817e-78,1.112309777701118870e-93\n2.274000000000000000e+03,2.786469660454151524e-78,1.012542534682431805e-93\n2.275000000000000000e+03,2.576322449080608226e-78,9.217237905253847571e-94\n2.276000000000000000e+03,2.382023912133575640e-78,8.390509207466918382e-94\n2.277000000000000000e+03,2.202378789969071541e-78,7.637932912685109969e-94\n2.278000000000000000e+03,2.036281965851859905e-78,6.952858013284864060e-94\n2.279000000000000000e+03,1.882711667647209562e-78,6.329230055505454734e-94\n2.280000000000000000e+03,1.740723182220094001e-78,5.761537632290539723e-94\n2.281000000000000000e+03,1.609443043875670188e-78,5.244763675389752884e-94\n2.282000000000000000e+03,1.488063661090682395e-78,4.774341116253719986e-94\n2.283000000000000000e+03,1.375838348480010111e-78,4.346112523870183001e-94\n2.284000000000000000e+03,1.272076733438117753e-78,3.956293362834249001e-94\n2.285000000000000000e+03,1.176140509197435721e-78,3.601438546940359323e-94\n2.286000000000000000e+03,1.087439508178424670e-78,3.278411992708165261e-94\n2.287000000000000000e+03,1.005428071476161326e-78,2.984358903767522328e-94\n2.288000000000000000e+03,9.296016921489117321e-79,2.716680541160193696e-94\n2.289000000000000000e+03,8.594939116603024433e-79,2.473011256588917350e-94\n2.290000000000000000e+03,7.946734503822447515e-79,2.251197585640183053e-94\n2.291000000000000000e+03,7.347415545067804545e-79,2.049279216214507315e-94\n2.292000000000000000e+03,6.793295430461221009e-79,1.865471663969691668e-94\n2.293000000000000000e+03,6.280965398302937676e-79,1.698150501668624723e-94\n2.294000000000000000e+03,5.807273765510347228e-79,1.545837003056367976e-94\n2.295000000000000000e+03,5.369306539516638570e-79,1.407185074391362337e-94\n2.296000000000000000e+03,4.964369492362268913e-79,1.280969358137184170e-94\n2.297000000000000000e+03,4.589971586706338490e-79,1.166074403678639344e-94\n2.298000000000000000e+03,4.243809651796464029e-79,1.061484809357067726e-94\n2.299000000000000000e+03,3.923754215133244637e-79,9.662762487035376729e-95\n2.300000000000000000e+03,3.627836402666897461e-79,8.796073015629012630e-95\n2.301000000000000000e+03,3.354235826942027037e-79,8.007120179150009114e-95\n2.302000000000000000e+03,3.101269388683297430e-79,7.288931486748037913e-95\n2.303000000000000000e+03,2.867380922930565783e-79,6.635159836472791904e-95\n2.304000000000000000e+03,2.651131626033019136e-79,6.040027421794793738e-95\n2.305000000000000000e+03,2.451191204609433309e-79,5.498274669359981953e-95\n2.306000000000000000e+03,2.266329692028580565e-79,5.005113756709148542e-95\n2.307000000000000000e+03,2.095409882065445136e-79,4.556186299167772988e-95\n2.308000000000000000e+03,1.937380333188532653e-79,4.147524831957550934e-95\n2.309000000000000000e+03,1.791268900443501732e-79,3.775517747122651027e-95\n2.310000000000000000e+03,1.656176755141932389e-79,3.436877375393612205e-95\n2.311000000000000000e+03,1.531272855568105238e-79,3.128610930909963017e-95\n2.312000000000000000e+03,1.415788834688009587e-79,2.847994062019247553e-95\n2.313000000000000000e+03,1.309014273412113608e-79,2.592546774404375282e-95\n2.314000000000000000e+03,1.210292330334905872e-79,2.360011513756136019e-95\n2.315000000000000000e+03,1.119015701065846122e-79,2.148333214293165251e-95\n2.316000000000000000e+03,1.034622882296036594e-79,1.955641136805056009e-95\n2.317000000000000000e+03,9.565947176174613624e-80,1.780232335709900824e-95\n2.318000000000000000e+03,8.844512038462482751e-80,1.620556609012999689e-95\n2.319000000000000000e+03,8.177485382037416376e-80,1.475202798160873079e-95\n2.320000000000000000e+03,7.560763881899642481e-80,1.342886316712563826e-95\n2.321000000000000000e+03,6.990553673554288704e-80,1.222437797611321084e-95\n2.322000000000000000e+03,6.463347014424513381e-80,1.112792758725141181e-95\n2.323000000000000000e+03,5.975900705391337354e-80,1.012982195323773713e-95\n2.324000000000000000e+03,5.525216139718190354e-80,9.221240163519568129e-96\n2.325000000000000000e+03,5.108520856623295954e-80,8.394152488151909301e-96\n2.326000000000000000e+03,4.723251486028974930e-80,7.641249413837303505e-96\n2.327000000000000000e+03,4.367037979565329850e-80,6.955877044988494597e-96\n2.328000000000000000e+03,4.037689030824667464e-80,6.331978298912788757e-96\n2.329000000000000000e+03,3.733178595177916046e-80,5.764039375421250629e-96\n2.330000000000000000e+03,3.451633426224434727e-80,5.247041027779776850e-96\n2.331000000000000000e+03,3.191321552207185849e-80,4.776414204351511411e-96\n2.332000000000000000e+03,2.950641621501131809e-80,4.347999668907688452e-96\n2.333000000000000000e+03,2.728113051633147757e-80,3.958011242743152626e-96\n2.334000000000000000e+03,2.522366921234213423e-80,3.603002343745990414e-96\n2.335000000000000000e+03,2.332137548892139890e-80,3.279835526703054546e-96\n2.336000000000000000e+03,2.156254707103183564e-80,2.985654755650053873e-96\n2.337000000000000000e+03,1.993636423423411705e-80,2.717860163218738748e-96\n2.338000000000000000e+03,1.843282324535782926e-80,2.474085073913005009e-96\n2.339000000000000000e+03,1.704267482288333877e-80,2.252175088254036846e-96\n2.340000000000000000e+03,1.575736723844957872e-80,2.050169042946351276e-96\n2.341000000000000000e+03,1.456899370948373327e-80,1.866281678798790625e-96\n2.342000000000000000e+03,1.347024375931643083e-80,1.698887863224445022e-96\n2.343000000000000000e+03,1.245435824557218622e-80,1.546508227883907120e-96\n2.344000000000000000e+03,1.151508778018785473e-80,1.407796094542262295e-96\n2.345000000000000000e+03,1.064665428526349867e-80,1.281525573595087380e-96\n2.346000000000000000e+03,9.843715448261257445e-81,1.166580730082334139e-96\n2.347000000000000000e+03,9.101331857883451867e-81,1.061945721443297255e-96\n2.348000000000000000e+03,8.414936618464863494e-81,9.666958198530615762e-97\n2.349000000000000000e+03,7.780307255959157357e-81,8.799892397996546207e-97\n2.350000000000000000e+03,7.193539742688172601e-81,8.010596986763430015e-97\n2.351000000000000000e+03,6.651024481070612162e-81,7.292096446423906670e-97\n2.352000000000000000e+03,6.149424098582743198e-81,6.638040919024269507e-97\n2.353000000000000000e+03,5.685652917359741794e-81,6.042650089227548468e-97\n2.354000000000000000e+03,5.256857972136378858e-81,5.500662099897073757e-97\n2.355000000000000000e+03,4.860401459758068846e-81,5.007287049631558428e-97\n2.356000000000000000e+03,4.493844512298758068e-81,4.558164661282698191e-97\n2.357000000000000000e+03,4.154932193959609896e-81,4.149325747341606505e-97\n2.358000000000000000e+03,3.841579629458776929e-81,3.777157131639695410e-97\n2.359000000000000000e+03,3.551859178575204728e-81,3.438369717353993904e-97\n2.360000000000000000e+03,3.283988577950143226e-81,3.129969419113043458e-97\n2.361000000000000000e+03,3.036319977199503610e-81,2.849230702311340268e-97\n2.362000000000000000e+03,2.807329801888395676e-81,2.593672495782491455e-97\n2.363000000000000000e+03,2.595609381011198484e-81,2.361036264954403291e-97\n2.364000000000000000e+03,2.399856281318158448e-81,2.149266051706369418e-97\n2.365000000000000000e+03,2.218866295181265769e-81,1.956490304525964254e-97\n2.366000000000000000e+03,2.051526032711984131e-81,1.781005338387514766e-97\n2.367000000000000000e+03,1.896806072558341003e-81,1.621260278176211573e-97\n2.368000000000000000e+03,1.753754629249351310e-81,1.475843352593082513e-97\n2.369000000000000000e+03,1.621491698128785200e-81,1.343469417411084438e-97\n2.370000000000000000e+03,1.499203641860590811e-81,1.222968597817425302e-97\n2.371000000000000000e+03,1.386138185204330311e-81,1.113275949466491474e-97\n2.372000000000000000e+03,1.281599787269037817e-81,1.013422046872166115e-97\n2.373000000000000000e+03,1.184945362778475558e-81,9.225244159624086024e-98\n2.374000000000000000e+03,1.095580326025366550e-81,8.397797350802408577e-98\n2.375000000000000000e+03,1.012954933178812384e-81,7.644567355062571736e-98\n2.376000000000000000e+03,9.365609004442493603e-82,6.958897387599242020e-98\n2.377000000000000000e+03,8.659282772712252997e-82,6.334727735647056767e-98\n2.378000000000000000e+03,8.006225553749212558e-82,5.766542204844919450e-98\n2.379000000000000000e+03,7.402419957863491586e-82,5.249319369029061198e-98\n2.380000000000000000e+03,6.844151574884623216e-82,4.778488192614331301e-98\n2.381000000000000000e+03,6.327986124353418080e-82,4.349887633371039647e-98\n2.382000000000000000e+03,5.850748328975064155e-82,3.959729868580518693e-98\n2.383000000000000000e+03,5.409502381376064727e-82,3.604566819574957252e-98\n2.384000000000000000e+03,5.001533883998115896e-82,3.281259678816940006e-98\n2.385000000000000000e+03,4.624333151031387219e-82,2.986951170210165576e-98\n2.386000000000000000e+03,4.275579769667425314e-82,2.719040297486197774e-98\n2.387000000000000000e+03,3.953128325694186865e-82,2.475159357504206071e-98\n2.388000000000000000e+03,3.654995205625946397e-82,2.253153015313754487e-98\n2.389000000000000000e+03,3.379346394175842146e-82,2.051059256053915447e-98\n2.390000000000000000e+03,3.124486192006695239e-82,1.867092045348119660e-98\n2.391000000000000000e+03,2.888846784356251661e-82,1.699625544953289897e-98\n2.392000000000000000e+03,2.670978596364152384e-82,1.547179744166949345e-98\n2.393000000000000000e+03,2.469541375772609768e-82,1.408407380006926056e-98\n2.394000000000000000e+03,2.283295948142289281e-82,1.282082030569766161e-98\n2.395000000000000000e+03,2.111096593865245178e-82,1.167087276340323906e-98\n2.396000000000000000e+03,1.951884000081374134e-82,1.062406833664263977e-98\n2.397000000000000000e+03,1.804678744139335049e-82,9.671155731864861669e-99\n2.398000000000000000e+03,1.668575268516285007e-82,8.803713438795498180e-99\n2.399000000000000000e+03,1.542736310130306960e-82,8.014075304056874218e-99\n2.400000000000000000e+03,1.426387749778184873e-82,7.295262780370921255e-99\n2.401000000000000000e+03,1.318813850012696720e-82,6.640923252583350206e-99\n2.402000000000000000e+03,1.219352852165011082e-82,6.045273895460678769e-99\n2.403000000000000000e+03,1.127392905426854279e-82,5.503050567091256871e-99\n2.404000000000000000e+03,1.042368302948592111e-82,5.009461286229391355e-99\n2.405000000000000000e+03,9.637560018000506642e-83,4.560143882431251776e-99\n2.406000000000000000e+03,8.910724053851566041e-83,4.151127444709099921e-99\n2.407000000000000000e+03,8.238703885172782147e-83,3.778797228001145687e-99\n2.408000000000000000e+03,7.617365468547331662e-83,3.439862707310783391e-99\n2.409000000000000000e+03,7.042886537752870374e-83,3.131328497191299005e-99\n2.410000000000000000e+03,6.511733090459162990e-83,2.850467879570648187e-99\n2.411000000000000000e+03,6.020637648226432833e-83,2.594798705965216174e-99\n2.412000000000000000e+03,5.566579156069879688e-83,2.362061461114558114e-99\n2.413000000000000000e+03,5.146764397940584568e-83,2.150199294171157312e-99\n2.414000000000000000e+03,4.758610813792841332e-83,1.957339840967746396e-99\n2.415000000000000000e+03,4.399730612539218008e-83,1.781778676714041836e-99\n2.416000000000000000e+03,4.067916083157536173e-83,1.621964252882724784e-99\n2.417000000000000000e+03,3.761126013590400934e-83,1.476484185163266697e-99\n2.418000000000000000e+03,3.477473133891832087e-83,1.344052771300416328e-99\n2.419000000000000000e+03,3.215212506372588252e-83,1.223499628504705361e-99\n2.420000000000000000e+03,2.972730791327590089e-83,1.113759350016295223e-99\n2.421000000000000000e+03,2.748536322309060754e-83,1.013862089410445827e-99\n2.422000000000000000e+03,2.541249929893000690e-83,9.229249894321472706e-100\n2.423000000000000000e+03,2.349596457490510336e-83,8.401443796104848597e-100\n2.424000000000000000e+03,2.172396917010143785e-83,7.647886736985785628e-100\n2.425000000000000000e+03,2.008561236117814083e-83,6.961919041686716547e-100\n2.426000000000000000e+03,1.857081552475983179e-83,6.337478366226775275e-100\n2.427000000000000000e+03,1.717026013711348511e-83,5.769046121033554269e-100\n2.428000000000000000e+03,1.587533044970945313e-83,5.251598699567280112e-100\n2.429000000000000000e+03,1.467806048801270010e-83,4.780563081432773836e-100\n2.430000000000000000e+03,1.357108504747393677e-83,4.351776417615795420e-100\n2.431000000000000000e+03,1.254759438525189944e-83,3.961449240670015112e-100\n2.432000000000000000e+03,1.160129232895096382e-83,3.606131974721897886e-100\n2.433000000000000000e+03,1.072635754467594824e-83,3.282684449318404174e-100\n2.434000000000000000e+03,9.917407726129344965e-84,2.988248147692351026e-100\n2.435000000000000000e+03,9.169466484464590536e-84,2.720220944185134237e-100\n2.436000000000000000e+03,8.477932735204482929e-84,2.476234107564839517e-100\n2.437000000000000000e+03,7.838552393906977628e-84,2.254131367003508504e-100\n2.438000000000000000e+03,7.247392206461588755e-84,2.051949855704852355e-100\n2.439000000000000000e+03,6.700815553023145562e-84,1.867902763770293814e-100\n2.440000000000000000e+03,6.195460076743793952e-84,1.700363546994279599e-100\n2.441000000000000000e+03,5.728216999677012695e-84,1.547851552032136398e-100\n2.442000000000000000e+03,5.296211998614530508e-84,1.409018930900636655e-100\n2.443000000000000000e+03,4.896787523212008766e-84,1.282638729166163387e-100\n2.444000000000000000e+03,4.527486447626493562e-84,1.167594042548005959e-100\n2.445000000000000000e+03,4.186036955100834223e-84,1.062868146106808978e-100\n2.446000000000000000e+03,3.870338562505390559e-84,9.675355087828631779e-101\n2.447000000000000000e+03,3.578449198868925192e-84,8.807536138745488666e-101\n2.448000000000000000e+03,3.308573258406817968e-84,8.017555131686319102e-101\n2.449000000000000000e+03,3.059050554554304922e-84,7.298430489186228108e-101\n2.450000000000000000e+03,2.828346107054415711e-84,6.643806837693619358e-101\n2.451000000000000000e+03,2.615040699271854007e-84,6.047898840988324473e-101\n2.452000000000000000e+03,2.417822147647313536e-84,5.505440071392352190e-101\n2.453000000000000000e+03,2.235477229582617193e-84,5.011636466912119045e-101\n2.454000000000000000e+03,2.066884220100705752e-84,4.562123962986178678e-101\n2.455000000000000000e+03,1.911005991369031098e-84,4.152929924399818382e-101\n2.456000000000000000e+03,1.766883632635356049e-84,3.780438036516309998e-101\n2.457000000000000000e+03,1.633630551329784037e-84,3.441356345545544375e-101\n2.458000000000000000e+03,1.510427019043477127e-84,3.132688165401039207e-101\n2.459000000000000000e+03,1.396515128833404607e-84,2.851705594030169809e-101\n2.460000000000000000e+03,1.291194132832510425e-84,2.595925405164648710e-101\n2.461000000000000000e+03,1.193816131482765592e-84,2.363087102429674245e-101\n2.462000000000000000e+03,1.103782087873960381e-84,2.151132941863286191e-101\n2.463000000000000000e+03,1.020538142668766681e-84,1.958189746290617972e-101\n2.464000000000000000e+03,9.435722069451753947e-85,1.782552350835327633e-101\n2.465000000000000000e+03,8.724108119968484606e-85,1.622668533265303065e-101\n2.466000000000000000e+03,8.066161967116960706e-85,1.477125295992239501e-101\n2.467000000000000000e+03,7.457836146120480318e-85,1.344636378490422257e-101\n2.468000000000000000e+03,6.895388439895466062e-85,1.224030889773170359e-101\n2.469000000000000000e+03,6.375358858182477846e-85,1.114242960465590960e-101\n2.470000000000000000e+03,5.894548352844227176e-85,1.014302323021601483e-101\n2.471000000000000000e+03,5.449999138389379126e-85,9.233257368367174065e-102\n2.472000000000000000e+03,5.038976496666276823e-85,8.405091824746919125e-102\n2.473000000000000000e+03,4.658951953790522584e-85,7.651207560232947299e-102\n2.474000000000000000e+03,4.307587725818570786e-85,6.964942007819985685e-102\n2.475000000000000000e+03,3.982722337483375737e-85,6.340230191169972089e-102\n2.476000000000000000e+03,3.682357325520127044e-85,5.771551124458720551e-102\n2.477000000000000000e+03,3.404644944789184425e-85,5.253879019823699073e-102\n2.478000000000000000e+03,3.147876801565307164e-85,4.782638871198144985e-102\n2.479000000000000000e+03,2.910473344070338237e-85,4.353666021998165308e-102\n2.480000000000000000e+03,2.690974145599350208e-85,3.963169359335900916e-102\n2.481000000000000000e+03,2.488028920463097621e-85,3.607697809481884439e-102\n2.482000000000000000e+03,2.300389217482440555e-85,3.284109838475771921e-102\n2.483000000000000000e+03,2.126900739933787871e-85,2.989545688340868440e-102\n2.484000000000000000e+03,1.966496244701379907e-85,2.721402103537899375e-102\n2.485000000000000000e+03,1.818188976954855771e-85,2.477309324297594148e-102\n2.486000000000000000e+03,1.681066599962946421e-85,2.255110143507807833e-102\n2.487000000000000000e+03,1.554285582703292195e-85,2.052840842067122120e-102\n2.488000000000000000e+03,1.437066010741412859e-85,1.868713834218208515e-102\n2.489000000000000000e+03,1.328686788457723766e-85,1.701101869486401233e-102\n2.490000000000000000e+03,1.228481203108644025e-85,1.548523651605990231e-102\n2.491000000000000000e+03,1.135832823432365500e-85,1.409630747338567619e-102\n2.492000000000000000e+03,1.050171707570100383e-85,1.283195669489121753e-102\n2.493000000000000000e+03,9.709708969740300550e-86,1.168101028800952154e-102\n2.494000000000000000e+03,8.977431747347091410e-86,1.063329658857931635e-102\n2.495000000000000000e+03,8.300380683854146342e-86,9.679556267213889847e-103\n2.496000000000000000e+03,7.674390787460626531e-86,8.811360498567188828e-103\n2.497000000000000000e+03,7.095611177596576698e-86,8.021036470307117564e-103\n2.498000000000000000e+03,6.560481395591216164e-86,7.301599573466398901e-103\n2.499000000000000000e+03,6.065709501922979449e-86,6.646691674898141132e-103\n2.500000000000000000e+03,5.608251825307414612e-86,6.050524926305528598e-103\n"
  },
  {
    "path": "CIP-0161/graph/scenario-cost-cross-thresholds.py",
    "content": "import numpy as np\nimport matplotlib.pyplot as plt\nfrom matplotlib.patches import Patch\n\n# Define the range for rho (Grinding Depth)\nrho = np.linspace(1, 256, 1000)\nf = 0.05\ncost_per_cpu_hour = 0.01\nw_O = 20 * (2 * rho - 1)\nw_O_hours = w_O / 3600\nepsilon = 1e-100  # Avoid log(0)\n\n# Praos cost functions\ndef ant_glance_praos(rho): return 5e-10 * 2**(rho - 2)\ndef ant_patrol_praos(rho): return 5e-10 * 2**(rho - 1) + 2.16e-2 * 2**(rho - 1) / rho\ndef owl_stare_praos(rho): return 5e-10 * 2**(rho - 2) + 5e-2 * 2**(rho - 1) / rho\ndef owl_survey_praos(rho): return 5e-10 * 2**(rho - 2) + 7.16e-2 * 2**(rho - 1) / rho\n\n# Phalanx cost function\ndef phalanx_cost(rho, scale): return (scale * 2**(rho - 1)) / rho\n\n# Compute log10(Cost) from CPU count\ndef log_cost(n_cpu): return np.log10(np.maximum(n_cpu * cost_per_cpu_hour * w_O_hours, epsilon))\n\n# Curves for Praos\npraos_curves = {\n    'Ant Glance Praos': ('blue', log_cost(ant_glance_praos(rho))),\n    'Ant Patrol Praos': ('orange', log_cost(ant_patrol_praos(rho))),\n    'Owl Stare Praos': ('green', log_cost(owl_stare_praos(rho))),\n    'Owl Survey Praos': ('red', log_cost(owl_survey_praos(rho))),\n}\n\n# Curves for Phalanx configurations\nphalanx_curves = {\n    'Phalanx$_{1/100}$': ('#6A5ACD', log_cost(phalanx_cost(rho, 2.16e2))),\n    'Phalanx$_{1/10}$': ('#228B22', log_cost(phalanx_cost(rho, 2.16e3))),\n    'Phalanx$_{max}$': ('#B22222', log_cost(phalanx_cost(rho, 2.16e4))),\n}\n\n# Feasibility zones\nzones = [\n    (-10, 4, 'green', 'Trivial'),\n    (4, 6, 'yellow', 'Feasible'),\n    (6, 9, '#FFA07A', 'Possible'),\n    (9, 12, '#FF6347', 'Borderline Infeasible'),\n    (12, 90, 'red', 'Infeasible')\n]\n\n# Function to find crossing points and annotate\ndef annotate_crossings(log_costs, color, threshold, position='above'):\n    # Find indices where the curve crosses the threshold\n    indices = np.where((log_costs[:-1] < threshold) & (log_costs[1:] >= threshold))[0]\n    if len(indices) > 0:\n        idx = indices[0]\n        rho_val = rho[idx]\n        plt.scatter(rho_val, threshold, color=color, marker='o', s=50, zorder=5)\n        # Position above or below based on the curve\n        if position == 'below':\n            plt.annotate(f'{rho_val:.1f}',\n                         xy=(rho_val, threshold),\n                         xytext=(rho_val + 1.1, threshold - 0.4),\n                         fontsize=8, color=color)\n        elif position == 'green':\n            plt.annotate(f'{rho_val:.1f}',\n                         xy=(rho_val, threshold),\n                         xytext=(rho_val - 0.6, threshold - 0.9),\n                         fontsize=8, color=color)\n        else:\n            plt.annotate(f'{rho_val:.1f}',\n                         xy=(rho_val, threshold),\n                         xytext=(rho_val - 1, threshold + 0.3),\n                         fontsize=8, color=color)\n\n\n# # Annotate where curves cross threshold lines\n# def annotate_crossings(log_costs, color, threshold, position='above'):\n#     indices = np.where((log_costs[:-1] < threshold) & (log_costs[1:] >= threshold))[0]\n#     if len(indices) > 0:\n#         idx = indices[0]\n#         rho_val = rho[idx]\n#         plt.scatter(rho_val, threshold, color=color, marker='o', s=50, zorder=5)\n#         offset = {'above': (1, 0.5), 'below': (1.1, -0.4), 'green': (-0.6, -0.9)}.get(position, (1, 0.5))\n#         plt.annotate(f'{rho_val:.1f}', xy=(rho_val, threshold),\n#                      xytext=(rho_val + offset[0], threshold + offset[1]),\n#                      fontsize=8, color=color)\n\n# Unified curve list for annotation logic\ncurves = [\n    (praos_curves['Ant Glance Praos'][1], 'blue', 'above'),\n    (praos_curves['Ant Patrol Praos'][1], 'orange', 'below'),\n    (praos_curves['Owl Stare Praos'][1], 'green', 'green'),\n    (praos_curves['Owl Survey Praos'][1], 'red', 'above'),\n    (phalanx_curves['Phalanx$_{1/100}$'][1], '#6A5ACD', 'above'),\n    (phalanx_curves['Phalanx$_{1/10}$'][1], '#228B22', 'above'),\n    (phalanx_curves['Phalanx$_{max}$'][1], '#B22222', 'above')\n]\n\n# Plotting\nplt.figure(figsize=(12, 7))\n\n# Plot each Praos and Phalanx curve\nfor label, (color, values) in praos_curves.items():\n    plt.plot(rho, values, label=label, color=color, linewidth=2)\nfor label, (color, values) in phalanx_curves.items():\n    plt.plot(rho, values, label=label, color=color, linestyle='--', linewidth=2)\n\n# Add feasibility zones\nfor y0, y1, color, label in zones:\n    plt.axhspan(y0, y1, color=color, alpha=0.1, label=label)\n\n# Annotate crossings\nfor threshold, _, _, _ in zones:\n    for log_costs, color, position in curves:\n        annotate_crossings(log_costs, color, threshold, position)\n\n# Axis labels and title\nplt.xlabel(r'$\\rho$ (Grinding Depth)', fontsize=14)\nplt.ylabel(r'$\\log_{10}(\\mathrm{Cost\\ (USD)})$', fontsize=14)\nplt.title('Cost of Grinding Attacks Across Praos and Phalanx Scenarios', fontsize=16)\nplt.grid(True, linestyle='--', alpha=0.7)\nplt.xlim(0, 256)\ny_max = max(np.max(v[np.isfinite(v)]) for _, v in list(praos_curves.values()) + list(phalanx_curves.values())) + 5\nplt.ylim(-5, y_max)\n\n# Custom legend\nlegend_elements = [\n    *[plt.Line2D([0], [0], color=color, lw=2, label=label) for label, (color, _) in praos_curves.items()],\n    *[plt.Line2D([0], [0], color=color, lw=2, linestyle='--', label=label) for label, (color, _) in phalanx_curves.items()],\n    *[Patch(facecolor=color, alpha=0.1, label=label) for _, _, color, label in zones]\n]\nplt.legend(handles=legend_elements, fontsize=10, loc='lower right',\n           bbox_to_anchor=(1, 0), ncol=2, handletextpad=0.5, columnspacing=1.5)\n\n# Final layout and save\nplt.subplots_adjust(left=0.1, right=0.95, top=0.9, bottom=0.2)\n\nplt.show()\n"
  },
  {
    "path": "CIP-0161/graph/scenario_cost_praos_vs_phalanx-full-scenarios.py",
    "content": "import numpy as np\nimport matplotlib.pyplot as plt\nfrom matplotlib.patches import Patch\n\n# Range for rho (Grinding Depth)\nrho = np.linspace(1, 256, 1000)\nf = 0.05\ncost_per_cpu_hour = 0.01  # $0.01 per CPU-hour\n\n# Time window for computation (w_O)\nw_O = 20 * (2 * rho - 1)\nw_O_hours = w_O / 3600\n\n# PRAOS cost functions\ndef ant_glance_praos(rho): return 5e-10 * 2**(rho - 2)\ndef ant_patrol_praos(rho): return ant_glance_praos(rho) + 2.16e-2 * 2**(rho - 1) / rho\ndef owl_stare_praos(rho): return ant_glance_praos(rho) + 5e-2 * 2**(rho - 1) / rho\ndef owl_survey_praos(rho): return ant_glance_praos(rho) + 7.16e-2 * 2**(rho - 1) / rho\n\n# PHALANX curves (generalized)\ndef phalanx_curve(multiplier):\n    return lambda rho: (multiplier * 2**(rho - 1)) / rho\n\nphalanx_1_100 = phalanx_curve(2.16e2)\nphalanx_1_10 = phalanx_curve(2.16e3)\nphalanx_max = phalanx_curve(2.16e4)\n\n# Convert to log10 cost\ndef compute_log_cost(n_cpu):\n    return np.log10(np.maximum(n_cpu * cost_per_cpu_hour * w_O_hours, 1e-100))\n\n# Scenario definitions\nscenarios = {\n    \"Ant Glance Praos\": compute_log_cost(ant_glance_praos(rho)),\n    \"Ant Patrol Praos\": compute_log_cost(ant_patrol_praos(rho)),\n    \"Owl Stare Praos\": compute_log_cost(owl_stare_praos(rho)),\n    \"Owl Survey Praos\": compute_log_cost(owl_survey_praos(rho)),\n    \"Phalanx$_{1/100}$\": compute_log_cost(phalanx_1_100(rho)),\n    \"Phalanx$_{1/10}$\": compute_log_cost(phalanx_1_10(rho)),\n    \"Phalanx$_{max}$\": compute_log_cost(phalanx_max(rho)),\n}\n\n# Color map for plot lines\ncolor_map = {\n    \"Ant Glance Praos\": \"blue\",\n    \"Ant Patrol Praos\": \"orange\",\n    \"Owl Stare Praos\": \"green\",\n    \"Owl Survey Praos\": \"red\",\n    \"Phalanx$_{1/100}$\": '#6A5ACD',\n    \"Phalanx$_{1/10}$\": '#228B22',\n    \"Phalanx$_{max}$\": \"#B22222\"\n}\n\n# Feasibility zones\nzones = [\n    (-10, 4, 'green', 'Trivial'),\n    (4, 6, 'yellow', 'Feasible'),\n    (6, 9, '#FFA07A', 'Possible'),\n    (9, 12, '#FF6347', 'Borderline Infeasible'),\n    (12, 90, 'red', 'Infeasible')\n]\n\n# Plot\nplt.figure(figsize=(12, 7))\n\n# Draw curves\nfor label, log_cost in scenarios.items():\n    style = \"-\" if \"Praos\" in label else \"--\"\n    plt.plot(rho, log_cost, label=label, color=color_map[label], linestyle=style, linewidth=2)\n\n# Draw feasibility zones\nfor y0, y1, color_zone, label in zones:\n    plt.axhspan(y0, y1, color=color_zone, alpha=0.1, label=label)\n\n# Axis labels and title\nplt.xlabel(r'$\\rho$ (Grinding Depth)', fontsize=14)\nplt.ylabel(r'$\\log_{10}(\\mathrm{Cost\\ (USD)})$', fontsize=14)\nplt.title('Cost of Grinding Attacks: Praos vs Phalanx Configurations', fontsize=16)\nplt.grid(True, linestyle='--', alpha=0.7)\nplt.xlim(0, 256)\ny_max = max(np.max(v[np.isfinite(v)]) for v in scenarios.values()) + 5\nplt.ylim(-5, y_max)\n\n# Delta annotations\ndef draw_delta(rho_val, praos_label, phalanx_label, x_offset=3):\n    idx = np.argmin(np.abs(rho - rho_val))\n    delta = scenarios[phalanx_label][idx] - scenarios[praos_label][idx]\n    mid = scenarios[phalanx_label][idx] - delta / 2\n    plt.annotate('', xy=(rho_val, scenarios[phalanx_label][idx]),\n                 xytext=(rho_val, scenarios[praos_label][idx]),\n                 arrowprops=dict(arrowstyle='<->', color='black', lw=1))\n    plt.text(rho_val + x_offset, mid, f'$\\\\Delta \\\\approx {delta:.1f}$', fontsize=12, color='black',\n             bbox=dict(facecolor='white', alpha=0.8, edgecolor='none'), verticalalignment='center')\n\ndraw_delta(50, \"Ant Glance Praos\", \"Phalanx$_{1/100}$\")\ndraw_delta(125, \"Owl Survey Praos\", \"Phalanx$_{1/100}$\")\ndraw_delta(150, \"Owl Survey Praos\", \"Phalanx$_{1/10}$\")\ndraw_delta(175, \"Owl Survey Praos\", \"Phalanx$_{max}$\")\n\n# Legend\nlegend_elements = [\n    plt.Line2D([0], [0], color='blue', lw=2, label='Ant Glance Praos'),\n    plt.Line2D([0], [0], color='orange', lw=2, label='Ant Patrol Praos'),\n    plt.Line2D([0], [0], color='green', lw=2, label='Owl Stare Praos'),\n    plt.Line2D([0], [0], color='red', lw=2, label='Owl Survey Praos'),\n    plt.Line2D([0], [0], color='#6A5ACD', lw=2, linestyle='--', label='Phalanx$_{1/100}$'),\n    plt.Line2D([0], [0], color='#228B22', lw=2, linestyle='--', label='Phalanx$_{1/10}$'),\n    plt.Line2D([0], [0], color='#B22222', lw=2, linestyle='--', label='Phalanx$_{max}$'),\n    *[Patch(facecolor=color, alpha=0.1, label=label) for _, _, color, label in zones]\n]\nplt.legend(handles=legend_elements, fontsize=10, loc='lower right', bbox_to_anchor=(1, 0), ncol=2)\n\nplt.subplots_adjust(left=0.1, right=0.95, top=0.9, bottom=0.2)\nplt.show()\n"
  },
  {
    "path": "CIP-0161/graph/scenario_cost_praos_vs_phalanx.py",
    "content": "import numpy as np\nimport matplotlib.pyplot as plt\nfrom matplotlib.patches import Patch\n\n# Define the range for rho (Grinding Depth)\nrho = np.linspace(1, 256, 1000)\nf = 0.05\ncost_per_cpu_hour = 0.01  # $0.01 per CPU-hour\n\n# Compute w_O in seconds and hours\nw_O = 20 * (2 * rho - 1)\nw_O_hours = w_O / 3600\n\n# N_CPU functions with corrected Phalanx_{1/100} expressions\ndef ant_glance_praos(rho):\n    return 5e-10 * 2**(rho - 2)\n\ndef ant_glance_phalanx(rho):\n    return ant_glance_praos(rho) + 216 * 2**(rho - 1) / rho\n\ndef ant_patrol_praos(rho):\n    return ant_glance_praos(rho) + 2.16e-2 * 2**(rho - 1) / rho\n\ndef ant_patrol_phalanx(rho):\n    return ant_patrol_praos(rho) + 216 * 2**(rho - 1) / rho\n\ndef owl_stare_praos(rho):\n    return ant_glance_praos(rho) + 5e-2 * 2**(rho - 1) / rho\n\ndef owl_stare_phalanx(rho):\n    return owl_stare_praos(rho) + 216 * 2**(rho - 1) / rho\n\ndef owl_survey_praos(rho):\n    return ant_glance_praos(rho) + 7.16e-2 * 2**(rho - 1) / rho\n\ndef owl_survey_phalanx(rho):\n    return owl_survey_praos(rho) + 216 * 2**(rho - 1) / rho\n\n# Compute N_CPU and costs\ndef compute_log_cost(n_cpu):\n    return np.log10(np.maximum(n_cpu * cost_per_cpu_hour * w_O_hours, 1e-100))\n\nscenarios = {\n    \"Ant Glance Praos\": compute_log_cost(ant_glance_praos(rho)),\n    \"Ant Glance Phalanx$_{1/100}$\": compute_log_cost(ant_glance_phalanx(rho)),\n    \"Ant Patrol Praos\": compute_log_cost(ant_patrol_praos(rho)),\n    \"Ant Patrol Phalanx$_{1/100}$\": compute_log_cost(ant_patrol_phalanx(rho)),\n    \"Owl Stare Praos\": compute_log_cost(owl_stare_praos(rho)),\n    \"Owl Stare Phalanx$_{1/100}$\": compute_log_cost(owl_stare_phalanx(rho)),\n    \"Owl Survey Praos\": compute_log_cost(owl_survey_praos(rho)),\n    \"Owl Survey Phalanx$_{1/100}$\": compute_log_cost(owl_survey_phalanx(rho)),\n}\n\n# Plot\nplt.figure(figsize=(12, 7))\ncolors = {\"Ant Glance\": \"blue\", \"Ant Patrol\": \"orange\", \"Owl Stare\": \"green\", \"Owl Survey\": \"red\"}\n\nfor label, log_cost in scenarios.items():\n    name = label.split()[0] + \" \" + label.split()[1]\n    style = \"--\" if \"Phalanx\" in label else \"-\"\n    plt.plot(rho, log_cost, label=label, color=colors[name], linestyle=style, linewidth=2)\n\n# Feasibility zones\nzones = [\n    (-10, 4, 'green', 'Trivial'),\n    (4, 6, 'yellow', 'Feasible'),\n    (6, 9, '#FFA07A', 'Possible'),\n    (9, 12, '#FF6347', 'Borderline Infeasible'),\n    (12, 90, 'red', 'Infeasible')\n]\nfor y0, y1, color, label in zones:\n    plt.axhspan(y0, y1, color=color, alpha=0.1, label=label)\n\n# Labels and layout\nplt.xlabel('$\\\\rho$ (Grinding Depth)', fontsize=14)\nplt.ylabel('$\\\\log_{10}(\\\\text{Cost (USD)})$', fontsize=14)\nplt.title('Cost of Grinding Attacks: Praos vs Phalanx$_{1/100}$ Scenarios', fontsize=16)\nplt.grid(True, linestyle='--', alpha=0.7)\nplt.xlim(0, 256)\ny_max = max(np.max(v[np.isfinite(v)]) for v in scenarios.values()) + 5\nplt.ylim(-5, y_max)\n\n# Delta annotations\ndef draw_delta(rho_val, praos_label, phalanx_label, x_offset=3):\n    idx = np.argmin(np.abs(rho - rho_val))\n    delta = scenarios[phalanx_label][idx] - scenarios[praos_label][idx]\n    mid = scenarios[phalanx_label][idx] - delta / 2\n    plt.annotate('', xy=(rho_val, scenarios[phalanx_label][idx]),\n                 xytext=(rho_val, scenarios[praos_label][idx]),\n                 arrowprops=dict(arrowstyle='<->', color='black', lw=1))\n    plt.text(rho_val + x_offset, mid, f'$\\\\Delta \\\\approx {delta:.1f}$', fontsize=12, color='black',\n             bbox=dict(facecolor='white', alpha=0.8, edgecolor='none'), verticalalignment='center')\n\ndraw_delta(50,\"Ant Glance Praos\" , \"Owl Survey Phalanx$_{1/100}$\" )\ndraw_delta(100, \"Owl Survey Praos\", \"Owl Survey Phalanx$_{1/100}$\" )\n\n# Legend\nlegend_elements = [\n    plt.Line2D([0], [0], color='blue', lw=2, label='Ant Glance Praos'),\n    plt.Line2D([0], [0], color='blue', lw=2, linestyle='--', label='Ant Glance Phalanx$_{1/100}$'),\n    plt.Line2D([0], [0], color='orange', lw=2, label='Ant Patrol Praos'),\n    plt.Line2D([0], [0], color='orange', lw=2, linestyle='--', label='Ant Patrol Phalanx$_{1/100}$'),\n    plt.Line2D([0], [0], color='green', lw=2, label='Owl Stare Praos'),\n    plt.Line2D([0], [0], color='green', lw=2, linestyle='--', label='Owl Stare Phalanx$_{1/100}$'),\n    plt.Line2D([0], [0], color='red', lw=2, label='Owl Survey Praos'),\n    plt.Line2D([0], [0], color='red', lw=2, linestyle='--', label='Owl Survey Phalanx$_{1/100}$'),\n    *[Patch(facecolor=color, alpha=0.1, label=label) for _, _, color, label in zones]\n]\nplt.legend(handles=legend_elements, fontsize=10, loc='lower right',\n           bbox_to_anchor=(1, 0), ncol=2, handletextpad=0.5, columnspacing=1.5)\n\nplt.subplots_adjust(left=0.1, right=0.95, top=0.9, bottom=0.2)\nplt.show()\n"
  },
  {
    "path": "CIP-0161/graph/settlement-time-phalanx.py",
    "content": "import numpy as np\nimport matplotlib.pyplot as plt\nimport matplotlib.ticker as ticker\n\n# Provided data\nK_data = np.array([i for i in range(1, 101)])\nErrorUB_data = np.array([0.8676736300353218, 0.7665170928550862, 0.6892413553587529, 0.6233636971643736,\n                         0.5657163917284088, 0.5148322413203136, 0.4695420424714478, 0.42897234102210713,\n                         0.3924626607691574, 0.35948902156200147, 0.32962278029962017, 0.3025063659506419,\n                         0.27783698249825733, 0.25535514591273023, 0.23483635661765484, 0.2160848560472272,\n                         0.19892882408177393, 0.18321660886850946, 0.1688137167962222, 0.15560037467673365,\n                         0.14346953077207325, 0.13232519782380092, 0.12208106635957837, 0.11265933425039264,\n                         0.10398971121778951, 0.09600856630132028, 0.08865819321256681, 0.08188617370925678,\n                         0.07564482309177875, 0.06989070498353891, 0.06458420493919947, 0.05968915429847635,\n                         0.05517249718980014, 0.05100399477754493, 0.047155961805507976, 0.043603031268163416,\n                         0.04032194367801183, 0.03729135792136073, 0.03449168112865765, 0.031904915346616804,\n                         0.029514519101649903, 0.02730528219838205, 0.025263212311976303, 0.023375432115528862,\n                         0.02163008583947576, 0.02001625429329978, 0.018523877494483327, 0.01714368414861849,\n                         0.015867127310310914, 0.014686325629034798, 0.013594009649070085, 0.012583472689500249,\n                         0.011648525880117402, 0.010783456972956714, 0.009982992587887582, 0.009242263584923428,\n                         0.008556773286253361, 0.007922368297970843, 0.007335211705481949, 0.006791758438006847,\n                         0.006288732616743953, 0.0058231067184273, 0.0053920824014072844, 0.0049930728552227905,\n                         0.0046236865470955305, 0.004281712250008304, 0.003965105247171995, 0.003671974616856373,\n                         0.003400571509858656, 0.0031492783394076493, 0.0029165988101272316, 0.002701148718882468,\n                         0.0025016474659702898, 0.002316910220247162, 0.0021458406864612394, 0.0019874244273183433,\n                         0.0018407226967006522, 0.0017048667440089573, 0.0015790525528455637, 0.001462535980224325,\n                         0.0013546282652105925, 0.0012546918783826707, 0.0011621366857862258, 0.0010764164031429315,\n                         0.0009970253179921987, 0.0009234952592045347, 0.0008553927949202647, 0.0007923166414519593,\n                         0.0007338952670522856, 0.0006797846757031187, 0.000629666357234632, 0.0005832453911440828,\n                         0.0005402486924603261, 0.0005004233888988434, 0.000463535319379835, 0.00042936764474434813,\n                         0.0003977195622058752, 0.0003684051157223931, 0.0003412520950705765, 0.00031610101695421933])\nErrorLB_data = np.array([0.8121889413522433, 0.6876416416654816, 0.5976483327753178, 0.5254324374189145,\n                         0.4645063982661716, 0.4123629938648501, 0.3673985960267712, 0.3283163309200733,\n                         0.2940989122957397, 0.2639674748869409, 0.23731513349944836, 0.21365535630042634,\n                         0.1925895067761664, 0.17378603461408476, 0.15696596625862824, 0.14189226025810497,\n                         0.12836183039592358, 0.11619947047643561, 0.10525314223559275, 0.09539025430277556,\n                         0.08649467767079334, 0.07846432047056445, 0.07120913531665457, 0.06464946639023633,\n                         0.05871466691555115, 0.05334193434216965, 0.04847532258446165, 0.04406489953310157,\n                         0.04006602469376975, 0.03643872686089284, 0.03314716563020274, 0.030159163591783687,\n                         0.02744579843693806, 0.024981046110909504, 0.022741467662164762, 0.020705933661954723,\n                         0.018855381059125348, 0.017172598143457285, 0.015642033953809715, 0.014249629014225416,\n                         0.01298266473472342, 0.011829629191657766, 0.0107800973193869, 0.009824623811787224,\n                         0.008954647257799136, 0.008162404226884964, 0.0074408521837850275, 0.006783600251963899,\n                         0.006184846965458831, 0.005639324252597922, 0.005142246984816187, 0.0046892675016852355,\n                         0.0042764345910511585, 0.003900156462313562, 0.003557167302609378, 0.003244497051022336,\n                         0.0029594440657968193, 0.0026995503946340197, 0.0024625793891173684, 0.002246495431690644,\n                         0.0020494455678550915, 0.0018697428577553032, 0.0017058512804271969, 0.0015563720409779223,\n                         0.0014200311461102907, 0.001295668126913479, 0.001182225799908241, 0.0010787409681255011,\n                         0.0009843359736577389, 0.0008982110217798201, 0.0008196372045025135, 0.0007479501583952579,\n                         0.0006825442977817404, 0.0006228675700485774, 0.0005684166848811588, 0.0005187327738111813,\n                         0.0004733974405802858, 0.0004320291665403726, 0.0003942800386652276, 0.0003598327707770982,\n                         0.0003283979913287651, 0.00029971177355593483, 0.00027353338605271704, 0.00024964324384800285,\n                         0.00022784104189382066, 0.00020794405453700824, 0.000189785586049734, 0.00017321355865768014,\n                         0.000158089225740669, 0.0001442859990014865, 0.00013168837941555155, 0.00012019098269693178,\n                         0.00010969765085385743, 0.00010012064216746174, 9.137989261820874e-05, 8.34023424119521e-05,\n                         7.612132182768348e-05, 6.947599112718069e-05, 6.341082973775746e-05, 5.787517034753198e-05])\n\n# Log-linear fit for ErrorUB (ln(y) = ln(a) - b * K)\nlog_y_UB = np.log(ErrorUB_data)\ncoeff_UB = np.polyfit(K_data, log_y_UB, 1)  # slope = -b, intercept = ln(a)\nb_UB = -coeff_UB[0]\na_UB = np.exp(coeff_UB[1])\n\nprint(f\"Fitted for ErrorUB: a={a_UB:.6f}, b={b_UB:.6f}\")\n\n# Log-linear fit for ErrorLB\nlog_y_LB = np.log(ErrorLB_data)\ncoeff_LB = np.polyfit(K_data, log_y_LB, 1)\nb_LB = -coeff_LB[0]\na_LB = np.exp(coeff_LB[1])\n\nprint(f\"Fitted for ErrorLB: a={a_LB:.6f}, b={b_LB:.6f}\")\n\n# Generate extended K values (101 to 2500)\nK_extended = np.arange(101, 2501)\n\n# Extrapolate\nErrorUB_extended = a_UB * np.exp(-b_UB * K_extended)\nErrorLB_extended = a_LB * np.exp(-b_LB * K_extended)\n\n# Combine original and extended data\nK_all = np.concatenate((K_data, K_extended))\nErrorUB_all = np.concatenate((ErrorUB_data, ErrorUB_extended))\nErrorLB_all = np.concatenate((ErrorLB_data, ErrorLB_extended))\n\n# Save to CSV\ndata = np.column_stack((K_all, ErrorUB_all, ErrorLB_all))\nnp.savetxt('extended_error_series_corrected.csv', data, delimiter=',', \n           header='Number of Blocks,ErrorUB,ErrorLB', comments='')\n\n# Plot for verification with professional legend and power of 2 y-axis\nfig, ax = plt.subplots(figsize=(10, 6))\nax.semilogy(K_all, ErrorUB_all, 'b-', label='Upper Bound')\nax.semilogy(K_all, ErrorLB_all, 'k-', label='Lower Bound')\n\n# Set y-axis to base 2\nax.set_yscale('log', base=2)\n\n# Formatter for y-ticks as 2^{exponent}\ndef formatter(y, pos):\n    if y <= 0:\n        return '0'\n    exponent = np.log2(y)\n    return r'$2^{{{:.0f}}}$'.format(exponent)\n\nax.yaxis.set_major_formatter(ticker.FuncFormatter(formatter))\n\n# Minor ticks for finer grid\nax.yaxis.set_minor_locator(ticker.LogLocator(base=2.0, subs=np.arange(2, 10) * .1, numticks=100))\n\nax.set_xlabel('Number of Blocks (K)', fontsize=12)\nax.set_ylabel('Probability of Failure', fontsize=12)\nax.set_title('Cardano PoS Settlement Failure (30% Adversary, 5s Delay)', fontsize=14)\nax.legend(loc='upper right', fontsize=12)\nax.grid(True, which='both', linestyle='--', linewidth=0.5)\nax.set_ylim([2**(-150), 1])  # Adjusted to show down to 2^{-150}\n\n# Add horizontal line at 2^{-60}\ntarget_prob_60 = 2**(-60)\nax.axhline(y=target_prob_60, color='r', linestyle='--', label='Without Grinding($2^{-60}$)')\n\n# Add horizontal line at 2^{-139.4}\ntarget_prob_1394 = 2**(-139.4)\nax.axhline(y=target_prob_1394, color='m', linestyle='--', label='Praos($2^{-139.4}$)')\n\n# Add horizontal line at 2^{-105.4}\ntarget_prob_1054 = 2**(-105.4)\nax.axhline(y=target_prob_1054, color='c', linestyle='--', label='$Phalanx_{1/100}$($2^{-105.4}$)')\n\n# Add horizontal line at 2^{-102.9}\ntarget_prob_1029 = 2**(-102.9)\nax.axhline(y=target_prob_1029, color='orange', linestyle='--', label='$Phalanx_{1/100}$($2^{-102.9}$)')\n\n# Add horizontal line at 2^{-99.5}\ntarget_prob_995 = 2**(-99.5)\nax.axhline(y=target_prob_995, color='purple', linestyle='--', label='$Phalanx_{max}$($2^{-99.5}$)')\n\n# Find approximate K where curves cross 2^{-60}\nK_UB_60 = np.interp(np.log(target_prob_60), np.log(ErrorUB_all)[::-1], K_all[::-1])  # Reverse for increasing log\nK_LB_60 = np.interp(np.log(target_prob_60), np.log(ErrorLB_all)[::-1], K_all[::-1])\n\n# Find approximate K where curves cross 2^{-139.4}\nK_UB_1394 = np.interp(np.log(target_prob_1394), np.log(ErrorUB_all)[::-1], K_all[::-1])\nK_LB_1394 = np.interp(np.log(target_prob_1394), np.log(ErrorLB_all)[::-1], K_all[::-1])\n\n# Find approximate K where curves cross 2^{-105.4}\nK_UB_1054 = np.interp(np.log(target_prob_1054), np.log(ErrorUB_all)[::-1], K_all[::-1])\nK_LB_1054 = np.interp(np.log(target_prob_1054), np.log(ErrorLB_all)[::-1], K_all[::-1])\n\n# Find approximate K where curves cross 2^{-102.9}\nK_UB_1029 = np.interp(np.log(target_prob_1029), np.log(ErrorUB_all)[::-1], K_all[::-1])\nK_LB_1029 = np.interp(np.log(target_prob_1029), np.log(ErrorLB_all)[::-1], K_all[::-1])\n\n# Find approximate K where curves cross 2^{-99.5}\nK_UB_995 = np.interp(np.log(target_prob_995), np.log(ErrorUB_all)[::-1], K_all[::-1])\nK_LB_995 = np.interp(np.log(target_prob_995), np.log(ErrorLB_all)[::-1], K_all[::-1])\n\n# Add vertical lines and annotations for 2^{-60}\nax.axvline(x=K_UB_60, color='b', linestyle=':', alpha=0.5)\nax.axvline(x=K_LB_60, color='k', linestyle=':', alpha=0.5)\nax.annotate(f'Upper Bound K ≈ {K_UB_60:.0f}', xy=(K_UB_60, target_prob_60), xytext=(K_UB_60 + 150, target_prob_60 * 2**10),\n            arrowprops=dict(facecolor='blue', shrink=0.05, width=2, headwidth=8), fontsize=12, color='b', bbox=dict(facecolor='white', edgecolor='blue', boxstyle='round,pad=0.5'))\nax.annotate(f'Lower Bound K ≈ {K_LB_60:.0f}', xy=(K_LB_60, target_prob_60), xytext=(K_LB_60 - 450, target_prob_60 / 2**10),\n            arrowprops=dict(facecolor='black', shrink=0.05, width=2, headwidth=8), fontsize=12, color='k', bbox=dict(facecolor='white', edgecolor='black', boxstyle='round,pad=0.5'))\n\n\n# Add vertical lines and annotations for 2^{-139.4}\nax.axvline(x=K_UB_1394, color='b', linestyle=':', alpha=0.5)\nax.axvline(x=K_LB_1394, color='k', linestyle=':', alpha=0.5)\nax.annotate(f'Upper Bound K ≈ {K_UB_1394:.0f}', xy=(K_UB_1394, target_prob_1394), xytext=(K_UB_1394 + 50, target_prob_1394 * 2**10 ),\n            arrowprops=dict(facecolor='blue', shrink=0.05, width=2, headwidth=8), fontsize=12, color='b', bbox=dict(facecolor='white', edgecolor='blue', boxstyle='round,pad=0.5'))\nax.annotate(f'Lower Bound K ≈ {K_LB_1394:.0f}', xy=(K_LB_1394, target_prob_1394), xytext=(K_LB_1394 - 450, target_prob_1394 / 2**10),\n            arrowprops=dict(facecolor='black', shrink=0.05, width=2, headwidth=8), fontsize=12, color='k', bbox=dict(facecolor='white', edgecolor='black', boxstyle='round,pad=0.5'))\n\n# Add vertical lines and annotations for 2^{-105.4}\nax.axvline(x=K_UB_1054, color='b', linestyle=':', alpha=0.5)\nax.axvline(x=K_LB_1054, color='k', linestyle=':', alpha=0.5)\nax.annotate(f'Upper Bound K ≈ {K_UB_1054:.0f}', xy=(K_UB_1054, target_prob_1054), xytext=(K_UB_1054 + 150, target_prob_1054 * 2**3),\n            arrowprops=dict(facecolor='blue', shrink=0.05, width=2, headwidth=8), fontsize=12, color='b', bbox=dict(facecolor='white', edgecolor='blue', boxstyle='round,pad=0.5'))\nax.annotate(f'Lower Bound K ≈ {K_LB_1054:.0f}', xy=(K_LB_1054, target_prob_1054), xytext=(K_LB_1054 - 450, target_prob_1054 / 2**15),\n            arrowprops=dict(facecolor='black', shrink=0.05, width=2, headwidth=8), fontsize=12, color='k', bbox=dict(facecolor='white', edgecolor='black', boxstyle='round,pad=0.5'))\n\n# Add vertical lines and annotations for 2^{-102.9}\nax.axvline(x=K_UB_1029, color='b', linestyle=':', alpha=0.5)\nax.axvline(x=K_LB_1029, color='k', linestyle=':', alpha=0.5)\nax.annotate(f'Upper Bound K ≈ {K_UB_1029:.0f}', xy=(K_UB_1029, target_prob_1029), xytext=(K_UB_1029 + 150, target_prob_1029 * 2**10),\n            arrowprops=dict(facecolor='blue', shrink=0.05, width=2, headwidth=8), fontsize=12, color='b', bbox=dict(facecolor='white', edgecolor='blue', boxstyle='round,pad=0.5'))\nax.annotate(f'Lower Bound K ≈ {K_LB_1029:.0f}', xy=(K_LB_1029, target_prob_1029), xytext=(K_LB_1029 - 450, target_prob_1029 / 2**10),\n            arrowprops=dict(facecolor='black', shrink=0.05, width=2, headwidth=8), fontsize=12, color='k', bbox=dict(facecolor='white', edgecolor='black', boxstyle='round,pad=0.5'))\n\n# Add vertical lines and annotations for 2^{-99.5}\nax.axvline(x=K_UB_995, color='b', linestyle=':', alpha=0.5)\nax.axvline(x=K_LB_995, color='k', linestyle=':', alpha=0.5)\nax.annotate(f'Upper Bound K ≈ {K_UB_995:.0f}', xy=(K_UB_995, target_prob_995), xytext=(K_UB_995 + 150, target_prob_995 * 2**15),\n            arrowprops=dict(facecolor='blue', shrink=0.05, width=2, headwidth=8), fontsize=12, color='b', bbox=dict(facecolor='white', edgecolor='blue', boxstyle='round,pad=0.5'))\nax.annotate(f'Lower Bound K ≈ {K_LB_995:.0f}', xy=(K_LB_995, target_prob_995), xytext=(K_LB_995 - 450, target_prob_995 / 2**3),\n            arrowprops=dict(facecolor='black', shrink=0.05, width=2, headwidth=8), fontsize=12, color='k', bbox=dict(facecolor='white', edgecolor='black', boxstyle='round,pad=0.5'))\n\nax.legend(fontsize=12)  # Update legend with the new lines\n\nplt.show()"
  },
  {
    "path": "CIP-0161/graph/settlement-time-praos.py",
    "content": "import numpy as np\nimport matplotlib.pyplot as plt\nimport matplotlib.ticker as ticker\n\n# Provided data\nK_data = np.array([i for i in range(1, 101)])\nErrorUB_data = np.array([0.8676736300353218, 0.7665170928550862, 0.6892413553587529, 0.6233636971643736,\n                         0.5657163917284088, 0.5148322413203136, 0.4695420424714478, 0.42897234102210713,\n                         0.3924626607691574, 0.35948902156200147, 0.32962278029962017, 0.3025063659506419,\n                         0.27783698249825733, 0.25535514591273023, 0.23483635661765484, 0.2160848560472272,\n                         0.19892882408177393, 0.18321660886850946, 0.1688137167962222, 0.15560037467673365,\n                         0.14346953077207325, 0.13232519782380092, 0.12208106635957837, 0.11265933425039264,\n                         0.10398971121778951, 0.09600856630132028, 0.08865819321256681, 0.08188617370925678,\n                         0.07564482309177875, 0.06989070498353891, 0.06458420493919947, 0.05968915429847635,\n                         0.05517249718980014, 0.05100399477754493, 0.047155961805507976, 0.043603031268163416,\n                         0.04032194367801183, 0.03729135792136073, 0.03449168112865765, 0.031904915346616804,\n                         0.029514519101649903, 0.02730528219838205, 0.025263212311976303, 0.023375432115528862,\n                         0.02163008583947576, 0.02001625429329978, 0.018523877494483327, 0.01714368414861849,\n                         0.015867127310310914, 0.014686325629034798, 0.013594009649070085, 0.012583472689500249,\n                         0.011648525880117402, 0.010783456972956714, 0.009982992587887582, 0.009242263584923428,\n                         0.008556773286253361, 0.007922368297970843, 0.007335211705481949, 0.006791758438006847,\n                         0.006288732616743953, 0.0058231067184273, 0.0053920824014072844, 0.0049930728552227905,\n                         0.0046236865470955305, 0.004281712250008304, 0.003965105247171995, 0.003671974616856373,\n                         0.003400571509858656, 0.0031492783394076493, 0.0029165988101272316, 0.002701148718882468,\n                         0.0025016474659702898, 0.002316910220247162, 0.0021458406864612394, 0.0019874244273183433,\n                         0.0018407226967006522, 0.0017048667440089573, 0.0015790525528455637, 0.001462535980224325,\n                         0.0013546282652105925, 0.0012546918783826707, 0.0011621366857862258, 0.0010764164031429315,\n                         0.0009970253179921987, 0.0009234952592045347, 0.0008553927949202647, 0.0007923166414519593,\n                         0.0007338952670522856, 0.0006797846757031187, 0.000629666357234632, 0.0005832453911440828,\n                         0.0005402486924603261, 0.0005004233888988434, 0.000463535319379835, 0.00042936764474434813,\n                         0.0003977195622058752, 0.0003684051157223931, 0.0003412520950705765, 0.00031610101695421933])\nErrorLB_data = np.array([0.8121889413522433, 0.6876416416654816, 0.5976483327753178, 0.5254324374189145,\n                         0.4645063982661716, 0.4123629938648501, 0.3673985960267712, 0.3283163309200733,\n                         0.2940989122957397, 0.2639674748869409, 0.23731513349944836, 0.21365535630042634,\n                         0.1925895067761664, 0.17378603461408476, 0.15696596625862824, 0.14189226025810497,\n                         0.12836183039592358, 0.11619947047643561, 0.10525314223559275, 0.09539025430277556,\n                         0.08649467767079334, 0.07846432047056445, 0.07120913531665457, 0.06464946639023633,\n                         0.05871466691555115, 0.05334193434216965, 0.04847532258446165, 0.04406489953310157,\n                         0.04006602469376975, 0.03643872686089284, 0.03314716563020274, 0.030159163591783687,\n                         0.02744579843693806, 0.024981046110909504, 0.022741467662164762, 0.020705933661954723,\n                         0.018855381059125348, 0.017172598143457285, 0.015642033953809715, 0.014249629014225416,\n                         0.01298266473472342, 0.011829629191657766, 0.0107800973193869, 0.009824623811787224,\n                         0.008954647257799136, 0.008162404226884964, 0.0074408521837850275, 0.006783600251963899,\n                         0.006184846965458831, 0.005639324252597922, 0.005142246984816187, 0.0046892675016852355,\n                         0.0042764345910511585, 0.003900156462313562, 0.003557167302609378, 0.003244497051022336,\n                         0.0029594440657968193, 0.0026995503946340197, 0.0024625793891173684, 0.002246495431690644,\n                         0.0020494455678550915, 0.0018697428577553032, 0.0017058512804271969, 0.0015563720409779223,\n                         0.0014200311461102907, 0.001295668126913479, 0.001182225799908241, 0.0010787409681255011,\n                         0.0009843359736577389, 0.0008982110217798201, 0.0008196372045025135, 0.0007479501583952579,\n                         0.0006825442977817404, 0.0006228675700485774, 0.0005684166848811588, 0.0005187327738111813,\n                         0.0004733974405802858, 0.0004320291665403726, 0.0003942800386652276, 0.0003598327707770982,\n                         0.0003283979913287651, 0.00029971177355593483, 0.00027353338605271704, 0.00024964324384800285,\n                         0.00022784104189382066, 0.00020794405453700824, 0.000189785586049734, 0.00017321355865768014,\n                         0.000158089225740669, 0.0001442859990014865, 0.00013168837941555155, 0.00012019098269693178,\n                         0.00010969765085385743, 0.00010012064216746174, 9.137989261820874e-05, 8.34023424119521e-05,\n                         7.612132182768348e-05, 6.947599112718069e-05, 6.341082973775746e-05, 5.787517034753198e-05])\n\n# Log-linear fit for ErrorUB (ln(y) = ln(a) - b * K)\nlog_y_UB = np.log(ErrorUB_data)\ncoeff_UB = np.polyfit(K_data, log_y_UB, 1)  # slope = -b, intercept = ln(a)\nb_UB = -coeff_UB[0]\na_UB = np.exp(coeff_UB[1])\n\nprint(f\"Fitted for ErrorUB: a={a_UB:.6f}, b={b_UB:.6f}\")\n\n# Log-linear fit for ErrorLB\nlog_y_LB = np.log(ErrorLB_data)\ncoeff_LB = np.polyfit(K_data, log_y_LB, 1)\nb_LB = -coeff_LB[0]\na_LB = np.exp(coeff_LB[1])\n\nprint(f\"Fitted for ErrorLB: a={a_LB:.6f}, b={b_LB:.6f}\")\n\n# Generate extended K values (101 to 2500)\nK_extended = np.arange(101, 2501)\n\n# Extrapolate\nErrorUB_extended = a_UB * np.exp(-b_UB * K_extended)\nErrorLB_extended = a_LB * np.exp(-b_LB * K_extended)\n\n# Combine original and extended data\nK_all = np.concatenate((K_data, K_extended))\nErrorUB_all = np.concatenate((ErrorUB_data, ErrorUB_extended))\nErrorLB_all = np.concatenate((ErrorLB_data, ErrorLB_extended))\n\n# Save to CSV\ndata = np.column_stack((K_all, ErrorUB_all, ErrorLB_all))\nnp.savetxt('extended_error_series_corrected.csv', data, delimiter=',', \n           header='Number of Blocks,ErrorUB,ErrorLB', comments='')\n\n# Plot for verification with professional legend and power of 2 y-axis\nfig, ax = plt.subplots(figsize=(10, 6))\nax.semilogy(K_all, ErrorUB_all, 'b-', label='Upper Bound')\nax.semilogy(K_all, ErrorLB_all, 'k-', label='Lower Bound')\n\n# Set y-axis to base 2\nax.set_yscale('log', base=2)\n\n# Formatter for y-ticks as 2^{exponent}\ndef formatter(y, pos):\n    if y <= 0:\n        return '0'\n    exponent = np.log2(y)\n    return r'$2^{{{:.0f}}}$'.format(exponent)\n\nax.yaxis.set_major_formatter(ticker.FuncFormatter(formatter))\n\n# Minor ticks for finer grid\nax.yaxis.set_minor_locator(ticker.LogLocator(base=2.0, subs=np.arange(2, 10) * .1, numticks=100))\n\nax.set_xlabel('Number of Blocks (K)', fontsize=12)\nax.set_ylabel('Probability of Failure', fontsize=12)\nax.set_title('Cardano PoS Settlement Failure (30% Adversary, 5s Delay)', fontsize=14)\nax.legend(loc='upper right', fontsize=10)\nax.grid(True, which='both', linestyle='--', linewidth=0.5)\nax.set_ylim([2**(-150), 1])  # Adjusted to show down to 2^{-150}\n\n\n# Add horizontal line at 2^{-60}\ntarget_prob_60 = 2**(-60)\nax.axhline(y=target_prob_60, color='r', linestyle='--', label='Without Grinding($2^{-60}$)')\n\n# Add horizontal line at 2^{-117.7}\ntarget_prob_1177 = 2**(-117.7)\nax.axhline(y=target_prob_1177, color='g', linestyle='--', label='Owl Survey Praos ($2^{-117.7}$)')\n\n# Add horizontal line at 2^{-139.4}\ntarget_prob_1394 = 2**(-139.4)\nax.axhline(y=target_prob_1394, color='m', linestyle='--', label='Ant Glance($2^{-139.4}$)')\n\n# Find approximate K where curves cross 2^{-60}\nK_UB_60 = np.interp(np.log(target_prob_60), np.log(ErrorUB_all)[::-1], K_all[::-1])  # Reverse for increasing log\nK_LB_60 = np.interp(np.log(target_prob_60), np.log(ErrorLB_all)[::-1], K_all[::-1])\n\n# Find approximate K where curves cross 2^{-117.7}\nK_UB_1177 = np.interp(np.log(target_prob_1177), np.log(ErrorUB_all)[::-1], K_all[::-1])\nK_LB_1177 = np.interp(np.log(target_prob_1177), np.log(ErrorLB_all)[::-1], K_all[::-1])\n\n# Find approximate K where curves cross 2^{-139.4}\nK_UB_1394 = np.interp(np.log(target_prob_1394), np.log(ErrorUB_all)[::-1], K_all[::-1])\nK_LB_1394 = np.interp(np.log(target_prob_1394), np.log(ErrorLB_all)[::-1], K_all[::-1])\n\n# Add vertical lines and annotations for 2^{-60}\nax.axvline(x=K_UB_60, color='b', linestyle=':', alpha=0.5)\nax.axvline(x=K_LB_60, color='k', linestyle=':', alpha=0.5)\nax.annotate(f'Upper Bound K ≈ {K_UB_60:.0f}', xy=(K_UB_60, target_prob_60), xytext=(K_UB_60 + 150, target_prob_60 * 2**10),\n            arrowprops=dict(facecolor='blue', shrink=0.05, width=2, headwidth=8), fontsize=12, color='b', bbox=dict(facecolor='white', edgecolor='blue', boxstyle='round,pad=0.5'))\nax.annotate(f'Lower Bound K ≈ {K_LB_60:.0f}', xy=(K_LB_60, target_prob_60), xytext=(K_LB_60 - 300, target_prob_60 / 2**10),\n            arrowprops=dict(facecolor='black', shrink=0.05, width=2, headwidth=8), fontsize=12, color='k', bbox=dict(facecolor='white', edgecolor='black', boxstyle='round,pad=0.5'))\n\n# Add vertical lines and annotations for 2^{-117.7}\nax.axvline(x=K_UB_1177, color='b', linestyle=':', alpha=0.5)\nax.axvline(x=K_LB_1177, color='k', linestyle=':', alpha=0.5)\nax.annotate(f'Upper Bound K ≈ {K_UB_1177:.0f}', xy=(K_UB_1177, target_prob_1177), xytext=(K_UB_1177 + 150, target_prob_1177 * 2**10),\n            arrowprops=dict(facecolor='blue', shrink=0.05, width=2, headwidth=8), fontsize=12, color='b', bbox=dict(facecolor='white', edgecolor='blue', boxstyle='round,pad=0.5'))\nax.annotate(f'Lower Bound K ≈ {K_LB_1177:.0f}', xy=(K_LB_1177, target_prob_1177), xytext=(K_LB_1177 - 300, target_prob_1177 / 2**10),\n            arrowprops=dict(facecolor='black', shrink=0.05, width=2, headwidth=8), fontsize=12, color='k', bbox=dict(facecolor='white', edgecolor='black', boxstyle='round,pad=0.5'))\n\n# Add vertical lines and annotations for 2^{-139.4}\nax.axvline(x=K_UB_1394, color='b', linestyle=':', alpha=0.5)\nax.axvline(x=K_LB_1394, color='k', linestyle=':', alpha=0.5)\nax.annotate(f'Upper Bound K ≈ {K_UB_1394:.0f}', xy=(K_UB_1394, target_prob_1394), xytext=(K_UB_1394 + 150, target_prob_1394 * 2**10),\n            arrowprops=dict(facecolor='blue', shrink=0.05, width=2, headwidth=8), fontsize=12, color='b', bbox=dict(facecolor='white', edgecolor='blue', boxstyle='round,pad=0.5'))\nax.annotate(f'Lower Bound K ≈ {K_LB_1394:.0f}', xy=(K_LB_1394, target_prob_1394), xytext=(K_LB_1394 - 300, target_prob_1394 / 2**10),\n            arrowprops=dict(facecolor='black', shrink=0.05, width=2, headwidth=8), fontsize=12, color='k', bbox=dict(facecolor='white', edgecolor='black', boxstyle='round,pad=0.5'))\n\nax.legend(fontsize=12)  # Update legend with the new lines\n\nplt.show()"
  },
  {
    "path": "CIP-0161/graph/settlement-time-without-grinding.py",
    "content": "import numpy as np\nimport matplotlib.pyplot as plt\nimport matplotlib.ticker as ticker\n\n# Provided data\nK_data = np.array([i for i in range(1, 101)])\nErrorUB_data = np.array([0.8676736300353218, 0.7665170928550862, 0.6892413553587529, 0.6233636971643736,\n                         0.5657163917284088, 0.5148322413203136, 0.4695420424714478, 0.42897234102210713,\n                         0.3924626607691574, 0.35948902156200147, 0.32962278029962017, 0.3025063659506419,\n                         0.27783698249825733, 0.25535514591273023, 0.23483635661765484, 0.2160848560472272,\n                         0.19892882408177393, 0.18321660886850946, 0.1688137167962222, 0.15560037467673365,\n                         0.14346953077207325, 0.13232519782380092, 0.12208106635957837, 0.11265933425039264,\n                         0.10398971121778951, 0.09600856630132028, 0.08865819321256681, 0.08188617370925678,\n                         0.07564482309177875, 0.06989070498353891, 0.06458420493919947, 0.05968915429847635,\n                         0.05517249718980014, 0.05100399477754493, 0.047155961805507976, 0.043603031268163416,\n                         0.04032194367801183, 0.03729135792136073, 0.03449168112865765, 0.031904915346616804,\n                         0.029514519101649903, 0.02730528219838205, 0.025263212311976303, 0.023375432115528862,\n                         0.02163008583947576, 0.02001625429329978, 0.018523877494483327, 0.01714368414861849,\n                         0.015867127310310914, 0.014686325629034798, 0.013594009649070085, 0.012583472689500249,\n                         0.011648525880117402, 0.010783456972956714, 0.009982992587887582, 0.009242263584923428,\n                         0.008556773286253361, 0.007922368297970843, 0.007335211705481949, 0.006791758438006847,\n                         0.006288732616743953, 0.0058231067184273, 0.0053920824014072844, 0.0049930728552227905,\n                         0.0046236865470955305, 0.004281712250008304, 0.003965105247171995, 0.003671974616856373,\n                         0.003400571509858656, 0.0031492783394076493, 0.0029165988101272316, 0.002701148718882468,\n                         0.0025016474659702898, 0.002316910220247162, 0.0021458406864612394, 0.0019874244273183433,\n                         0.0018407226967006522, 0.0017048667440089573, 0.0015790525528455637, 0.001462535980224325,\n                         0.0013546282652105925, 0.0012546918783826707, 0.0011621366857862258, 0.0010764164031429315,\n                         0.0009970253179921987, 0.0009234952592045347, 0.0008553927949202647, 0.0007923166414519593,\n                         0.0007338952670522856, 0.0006797846757031187, 0.000629666357234632, 0.0005832453911440828,\n                         0.0005402486924603261, 0.0005004233888988434, 0.000463535319379835, 0.00042936764474434813,\n                         0.0003977195622058752, 0.0003684051157223931, 0.0003412520950705765, 0.00031610101695421933])\nErrorLB_data = np.array([0.8121889413522433, 0.6876416416654816, 0.5976483327753178, 0.5254324374189145,\n                         0.4645063982661716, 0.4123629938648501, 0.3673985960267712, 0.3283163309200733,\n                         0.2940989122957397, 0.2639674748869409, 0.23731513349944836, 0.21365535630042634,\n                         0.1925895067761664, 0.17378603461408476, 0.15696596625862824, 0.14189226025810497,\n                         0.12836183039592358, 0.11619947047643561, 0.10525314223559275, 0.09539025430277556,\n                         0.08649467767079334, 0.07846432047056445, 0.07120913531665457, 0.06464946639023633,\n                         0.05871466691555115, 0.05334193434216965, 0.04847532258446165, 0.04406489953310157,\n                         0.04006602469376975, 0.03643872686089284, 0.03314716563020274, 0.030159163591783687,\n                         0.02744579843693806, 0.024981046110909504, 0.022741467662164762, 0.020705933661954723,\n                         0.018855381059125348, 0.017172598143457285, 0.015642033953809715, 0.014249629014225416,\n                         0.01298266473472342, 0.011829629191657766, 0.0107800973193869, 0.009824623811787224,\n                         0.008954647257799136, 0.008162404226884964, 0.0074408521837850275, 0.006783600251963899,\n                         0.006184846965458831, 0.005639324252597922, 0.005142246984816187, 0.0046892675016852355,\n                         0.0042764345910511585, 0.003900156462313562, 0.003557167302609378, 0.003244497051022336,\n                         0.0029594440657968193, 0.0026995503946340197, 0.0024625793891173684, 0.002246495431690644,\n                         0.0020494455678550915, 0.0018697428577553032, 0.0017058512804271969, 0.0015563720409779223,\n                         0.0014200311461102907, 0.001295668126913479, 0.001182225799908241, 0.0010787409681255011,\n                         0.0009843359736577389, 0.0008982110217798201, 0.0008196372045025135, 0.0007479501583952579,\n                         0.0006825442977817404, 0.0006228675700485774, 0.0005684166848811588, 0.0005187327738111813,\n                         0.0004733974405802858, 0.0004320291665403726, 0.0003942800386652276, 0.0003598327707770982,\n                         0.0003283979913287651, 0.00029971177355593483, 0.00027353338605271704, 0.00024964324384800285,\n                         0.00022784104189382066, 0.00020794405453700824, 0.000189785586049734, 0.00017321355865768014,\n                         0.000158089225740669, 0.0001442859990014865, 0.00013168837941555155, 0.00012019098269693178,\n                         0.00010969765085385743, 0.00010012064216746174, 9.137989261820874e-05, 8.34023424119521e-05,\n                         7.612132182768348e-05, 6.947599112718069e-05, 6.341082973775746e-05, 5.787517034753198e-05])\n\n# Log-linear fit for ErrorUB (ln(y) = ln(a) - b * K)\nlog_y_UB = np.log(ErrorUB_data)\ncoeff_UB = np.polyfit(K_data, log_y_UB, 1)  # slope = -b, intercept = ln(a)\nb_UB = -coeff_UB[0]\na_UB = np.exp(coeff_UB[1])\n\nprint(f\"Fitted for ErrorUB: a={a_UB:.6f}, b={b_UB:.6f}\")\n\n# Log-linear fit for ErrorLB\nlog_y_LB = np.log(ErrorLB_data)\ncoeff_LB = np.polyfit(K_data, log_y_LB, 1)\nb_LB = -coeff_LB[0]\na_LB = np.exp(coeff_LB[1])\n\nprint(f\"Fitted for ErrorLB: a={a_LB:.6f}, b={b_LB:.6f}\")\n\n# Generate extended K values (101 to 2500)\nK_extended = np.arange(101, 2501)\n\n# Extrapolate\nErrorUB_extended = a_UB * np.exp(-b_UB * K_extended)\nErrorLB_extended = a_LB * np.exp(-b_LB * K_extended)\n\n# Combine original and extended data\nK_all = np.concatenate((K_data, K_extended))\nErrorUB_all = np.concatenate((ErrorUB_data, ErrorUB_extended))\nErrorLB_all = np.concatenate((ErrorLB_data, ErrorLB_extended))\n\n# Save to CSV\ndata = np.column_stack((K_all, ErrorUB_all, ErrorLB_all))\nnp.savetxt('extended_error_series_corrected.csv', data, delimiter=',', \n           header='Number of Blocks,ErrorUB,ErrorLB', comments='')\n\n# Plot for verification with professional legend and power of 2 y-axis\nfig, ax = plt.subplots(figsize=(10, 6))\nax.semilogy(K_all, ErrorUB_all, 'b-', label='Upper Bound')\nax.semilogy(K_all, ErrorLB_all, 'k-', label='Lower Bound')\n\n# Set y-axis to base 2\nax.set_yscale('log', base=2)\n\n# Formatter for y-ticks as 2^{exponent}\ndef formatter(y, pos):\n    if y <= 0:\n        return '0'\n    exponent = np.log2(y)\n    return r'$2^{{{:.0f}}}$'.format(exponent)\n\nax.yaxis.set_major_formatter(ticker.FuncFormatter(formatter))\n\n# Minor ticks for finer grid\nax.yaxis.set_minor_locator(ticker.LogLocator(base=2.0, subs=np.arange(2, 10) * .1, numticks=100))\n\nax.set_xlabel('Number of Blocks (K)', fontsize=12)\nax.set_ylabel('Probability of Failure', fontsize=12)\nax.set_title('Cardano PoS Settlement Failure (30% Adversary, 5s Delay)', fontsize=14)\nax.legend(loc='upper right', fontsize=12)\nax.grid(True, which='both', linestyle='--', linewidth=0.5)\nax.set_ylim([2**(-100), 1])  # Adjust to show down to very low probabilities (e.g., 2^{-100})\n\n# Add horizontal line at 2^{-60}\ntarget_prob = 2**(-60)\nax.axhline(y=target_prob, color='r', linestyle='--', label='$2^{-60}$')\n\n# Find approximate K where curves cross 2^{-60}\nK_UB_60 = np.interp(np.log(target_prob), np.log(ErrorUB_all)[::-1], K_all[::-1])  # Reverse for increasing log\nK_LB_60 = np.interp(np.log(target_prob), np.log(ErrorLB_all)[::-1], K_all[::-1])\n\n# Add vertical lines and annotations\nax.axvline(x=K_UB_60, color='b', linestyle=':', alpha=0.5)\nax.axvline(x=K_LB_60, color='k', linestyle=':', alpha=0.5)\nax.annotate(f'Upper Bound K ≈ {K_UB_60:.0f}', xy=(K_UB_60, target_prob), xytext=(K_UB_60 + 150, target_prob * 2**10),\n            arrowprops=dict(facecolor='blue', shrink=0.05, width=2, headwidth=8), fontsize=12, color='b', bbox=dict(facecolor='white', edgecolor='blue', boxstyle='round,pad=0.5'))\nax.annotate(f'Lower Bound K ≈ {K_LB_60:.0f}', xy=(K_LB_60, target_prob), xytext=(K_LB_60 - 300, target_prob / 2**10),\n            arrowprops=dict(facecolor='black', shrink=0.05, width=2, headwidth=8), fontsize=12, color='k', bbox=dict(facecolor='white', edgecolor='black', boxstyle='round,pad=0.5'))\n\nax.legend(fontsize=12)  # Update legend with the new line\n\nplt.show()"
  },
  {
    "path": "CIP-0161/graph/vdf_benches.py",
    "content": "import secrets\nimport time\nfrom statistics import stdev\nfrom tabulate import tabulate\n\nfrom chiavdf import create_discriminant, prove, verify_wesolowski\n\n\ndef bench_prove_and_verify():\n    discriminant_challenge = secrets.token_bytes(10)\n\n    discriminant_sizes = [256, 512, 1024]\n    iterations = [100_000, 200_000, 500_000, 1_000_000, 2_000_000, 5_000_000, 10_000_000]\n    benches = 100\n    table = []\n\n    for d in discriminant_sizes:\n        for iters in iterations:\n            res_prove = []\n            res_verify = []\n            for b in range(benches):\n                discriminant = create_discriminant(discriminant_challenge, d)\n                form_size = 100\n                initial_el = b\"\\x08\" + (b\"\\x00\" * 99)\n\n                t1 = time.time()\n                result = prove(discriminant_challenge, initial_el, d, iters, \"\")\n                t2 = time.time()\n                res_prove.append(t2-t1)\n                result_y = result[:form_size]\n                proof = result[form_size : 2 * form_size]\n\n                tv_1 = time.time()\n                is_valid = verify_wesolowski(\n                    str(discriminant),\n                    initial_el,\n                    result_y,\n                    proof,\n                    iters,\n                )\n                tv_2 = time.time()\n                res_verify.append(tv_2 - tv_1)\n                assert is_valid\n            proving_time =  \"{:.2E}\".format(sum(res_prove)/len(res_prove))\n            proving_deviation = \"{:.2E}\".format(stdev(res_prove))\n            ips = \"{:_.3f}\".format(iters /  (sum(res_prove) / len(res_prove)))\n            verification_time = \"{:.2E}\".format(1000 *(sum(res_verify)/len(res_verify)))\n            verification_deviation = \"{:.2E}\".format(1000 * stdev(res_verify))\n            table.append([d, ips, proving_time, proving_deviation, verification_time, verification_deviation ])\n    headers = [\"Size Discriminant\", \"IPS\", \"Proving time (s)\", \"σ proving\", \"Verification time (ms)\", \"σ verification\"]\n    print(tabulate(table, headers, tablefmt='orgtbl'))\n\nbench_prove_and_verify()\n"
  },
  {
    "path": "CIP-0162/README.md",
    "content": "---\nCIP: 162\nTitle: URI Scheme - DRep Links\nCategory: Wallets\nStatus: Proposed\nAuthors:\n    - Mad Orkestra <mad@madorkestra.com>\nImplementors: []\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pull/1069\nCreated: 2025-07-31\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP proposes a new [CIP-0013](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013) extension: A new URI scheme authority named `drep` under `web+cardano` to enable Cardano mobile wallets and wallet extensions to create and submit a DRep delegation transaction for a given DRep-Id, using a standardized, interoperable URI format.\n\n## Motivation: Why is this CIP necessary?\n\nWith Cardano Governance now in full effect a high level of participation / DRep delegation is needed to solidify and secure the consensus mechanisms put in place and ensure decentralisation of power. Delegating to a DRep however - especially on mobile devices - can be a cumbersome task involving multiple steps from copying or typing a complicated DRep-Id or visiting a dedicated website, search for DRep by Id or Name, create and sign a transaction - or use in-app DRep explorers which some wallets offer right now, others don’t.\n\nThe goal of this CIP is to make DRep delegation as easy as clicking a button on desktop browsers or scanning a QR-Code with your mobile device, which automatically opens the user's preferred wallet via deep-linking compatible method and create a DRep-delegation transaction for the transmitted DRep-Id for the user to review, sign and submit the transaction.\n\nWith the existing `web+cardano://` URIs for almost all other methods of participation in the Cardano ecosystem such as payments and Stake Pool delegation already defined, this proposed extension adds another missing piece of the puzzle.\n\nThis CIP will enable fast, frictionless and error-prone DRep delegation and will provide DReps at the same time with another way to promote themselves without the need of lengthy DRep-Ids, specific governance websites or dedicated DRep browsers/interfaces inside of wallets.\n\nEspecially for real world events this will provide a feasible solution for instant DRep-delegation in environments where copy & pasting a DRep-Id isn't an option. It will also mitigate some of the painpoints for wallets to implement their own way of DRep discovery and delegation by providing an ecosystem-wide standard for One-Click-Delegation.\n\n## Specification\n\nThis extension to the [CIP-0013](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013) URN scheme defines the `drep` authority for Cardano URIs.\n\n### URI Format\n\n`web+cardano://drep/<DRep-Id>`\n\n- Authority (REQUIRED): `drep`\n- DRep-Id (REQUIRED): Bech32 [CIP-0129](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0129) `<DRep-Id>` | `always_abstain` | `always_no_confidence`\n\n### Example URIs\n\n`web+cardano://drep/always_abstain`\n\n### Wallet Behavior\n\n- Parse and validate the given DRep-Id against [CIP-0129](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0129) or one of the default options\n- Check on-chain if the given DRep-Id belongs to a registered and/or active DRep\n- Create a DRep delegation transaction\n- Display the DRep-Id (and registration/active status) to the user and prompt to sign and submit the delegation transaction\n\n### Security Considerations\n\n- Wallets SHOULD validate if the given DRep-Id is a valid [CIP-0129](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0129) DRep-Id, otherwise provide a warning to the user\n- Wallets SHOULD validate if the given DRep-Id belongs to a registered/active DRep - otherwise provide a warning to the user.\n\n## Rationale: How does this CIP achieve its goals?\n\nA dedicated `drep` authority isolates app navigation from other authorities such as `pay`, `browse` or `stake`, improving clarity and interoperability.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [*] Community feedback with CIP text updated accordingly\n- [ ] Two or more wallets or public services support this new `drep` authority\n\n### Implementation Plan\n\nLeveraging existing connections within the ecosystem; the author(s) will find willing partners to integrate this proposal and deploy a proof of concept integration.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0163/README.md",
    "content": "---\nCIP: 163\nTitle: Time-Bound Delegation with Dynamic Rewards\nCategory: Ledger\nStatus: Proposed\nAuthors:\n  - Ryan Wiley rian222@gmail.com\nImplementors: []\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/1077\nCreated: 2025-08-15\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nCardano’s staking and on‑chain voting have drifted toward passivity. As described in CPS-0022, long‑lived “set‑and‑forget” delegations let rewards and governance weight ossify, particularly in wallets that have been permanently lost, diluting staking rewards and voting power engaged participants and harming network security. This CIP reframes delegation as an **active, periodically affirmed contribution to network security** and realigns incentives so rewards flow to those presently and capable of participating. At a high level, it introduces (i) **reward-account liveness with inactivity expiry** (proof-of-life via any witness-bearing action on the staking credential), and (ii) **full-pot reward distribution** to currently eligible delegators and pools each epoch.\n\nIf the network’s total staking ratio remains roughly unchanged, these changes are expected to increase rewards for all delegators and stake pool operators by a small annual percent. Together, these changes encourage ongoing engagement, reduce sticky/lost‑stake externalities, and keep realized emissions consistent with monetary policy while respecting user property rights.\n\n## Motivation: why is this CIP necessary?\n\nMany users interpret staking rewards as akin to bank interest. If that were the intent, the ledger would not need operator selection, delegation, or performance‑based rewards. Yield could simply accrue automatically. In Cardano, **staking is voluntary and active**. It is how the protocol decides who gets to make blocks, and rewards compensate the combination of (a) **committing stake** to secure the network and (b) **selecting and monitoring** a competent, honest operator. \"On a high level, the goal of the incentives mechanism is to incentivize stakeholders to follow the protocol and thereby to guarantee the secure and efficient operation of Cardano\" (SL‑D5 §5.1)\n\n- Delegation is a liquid vote for a pool operator. Delegators are expected to reevaluate and move if performance, fees, or behavior change.\n- Lost or inactive stake no longer contributes to present‑day security yet can lock in block‑production influence and siphon rewards from active participants.\n\nThis CIP addresses the broader drift toward **passive and indifferent delegations.** Securing the network is an **active act**, periodically affirmed by the holder, and rewarded accordingly. Reward-account inactivity introduces a light-touch **proof-of-life** via any witness-bearing action on the staking credential, covering both stake pool and dRep participation. Furthermore, full‑pot distribution provides a stabilizing incentive: if total stake falls low enough to threaten security, yields rise automatically for active delegators and SPOs, encouraging new delegation rather than letting rewards drip back to reserves.\n\n## Specification\n\n#### Current behavior (for context)\n\n- **Indefinite delegations.** Delegation certificates today have no expiry. Once a stake credential delegates to a stake pool or a dRep, that delegation remains valid indefinitely until the holder submits a new delegation (or deregisters the stake key).\n- **Rewards return-to-reserves.** After monetary expansion and fees are combined and the treasury cut is taken, the distributable rewards pot is scaled by the network’s active‑stake ratio; only that fraction is paid out, and the remainder is returned to reserves. This occurs because rewards are computed using only the active stake snapshot and any residual R not assigned to reward accounts (∆r₂ = R − Σrs) is returned to reserves, per the epoch‑boundary and reward‑update rules (SL‑D5 §11.1, §11.5, §11.8–§11.10).\n\nThis CIP intentionally limits itself to two changes to the ledger rules. All other reward mechanics (e.g., pledge influence, saturation, treasury cut) are unchanged:\n\n### 1) Reward-account inactivity expiry (proof-of-life)\n\n- Add a **single protocol parameter** (measured in epochs), to be set via governance:\n  - `delegatorInactivity`\n- **Scope & terminology.** A *reward account* (i.e., staking credential) is the object that delegates, accrues, and withdraws rewards. The ledger maintains an `expirationEpoch` for each registered reward account.\n- **Inactivity rule.** During epoch transitions, when stake and voting power are computed, **expired reward accounts** (those with `expirationEpoch < currentEpoch`) are **ignored** for pool leader election, rewards distribution, and governance tallying.\n- **Proof-of-life.** Any action that requires a **witness by the reward account** resets its expiration to `currentEpoch + delegatorInactivity`. Examples include: reward withdrawal, (re)delegation to an SPO, (re)delegation to a dRep, and stake-key registration or deregistration. (Wallets commonly withdraw rewards when submitting any transaction, so ordinary usage renews automatically.)\n- **Ineligible for rewards.** For epochs in which a reward account is inactive, its epoch reward share is **not credited** to that account. Those uncredited rewards are instead distributed with the rest of the rewards pot (see next section).\n- **Migration.** On activation, determine the epoch that the last witness occurred for each rewards account.  Then initialize each account's `expirationEpoch` to that epoch plus `delegatorInactivity`.\n\n### 2) Full‑pot reward distribution\n\n- In each epoch, distribute the **full rewards pot** (monetary expansion + fees, less the treasury cut, blocks not produced [Eta], and unmet pledge) to eligible delegators and pools without returning any remainder to reserves **(i.e., eliminate the residual ∆r₂ described in SL‑D5 §11.10 and distribute that proportion as well)**.\n- “Eligibility” remains exactly as today, except that stake controlled by an **expired reward account** does **not** earn rewards (and expired reward accounts contribute **no** governance voting power).\n\n**Note:** The initial numeric value for `delegatorInactivity` is intentionally **left undefined** here and will be chosen through community governance and deliberation. Potential jittering or lottery mechanisms to stagger per-epoch expiries are not mentioned in this proposal, but may be considered separately if operational data warrants it.\n\n## Rationale: how does this CIP achieve its goals?\n\n- **Active security & correct economics.** Periodic renewal makes delegation an affirmative act of securing the network. Engaged holders are compensated for informed operator selection, not mere passage of time.\n- **Mitigate sticky stake.** Long‑dormant delegations can prop up legacy control of block production. Expirations reduce that inertia by requiring a simple, periodic affirmation from real, reachable owners.\n- **Curbing ossification & compounding.** Expirations prevent unreachable wallets from indefinitely accumulating rewards or voting power without threatening their principal investment.\n- **Dynamic & responsive yields.** Full‑pot distribution increases pool/delegator yield when participation drops and compresses it when participation rises, creating a simple and transparent balancing mechanism.\n- **Alignment with policy.** Realized emissions track the monetary expansion set by Rho more closely (rather than being artificially reduced by the active‑stake ratio).\n- **Respect for property.** No seizure or clawback occurs. Inactive accounts simply stop earning until the account becomes active againn.\n- **Governance clarity.** Because expired reward accounts contribute zero voting power, governance power reflects currently affirmed participation (CIP-1694’s “inactive dRep” guardrails remain complementary but insufficient on their own).\n- **Sharper SPO accountability.** Periodic renewal nudges delegators to review operator fees, performance, and conduct. If a pool underperforms or raises costs, stake can organically reallocate on renewal.\n- **Fairer path for new pools.** Expirations free stake that would otherwise remain inert with incumbents, reducing entrenched advantages from lost delegations and lowering barriers for competent new operators to attract delegation.\n\n### Option to adjust Rho\n\nDistributing the full-rewards pot will stop sending residual rewards back to reserves. If Rho is left unchanged, reserves will deplete faster by roughly that amount and true emissions will track much closer to the monetary expansion set by Rho. As a result, this will cause active participants to see a small boost to their annual yields. If the community prefers to preserve the current rate of emissions, the community can instead reduce Rho to offset this through a parameter change governance action. However, this will trade away the increase in rewards. This CIP intentionally leaves this choice out of scope.\n\nA key practical advantage of distributing the full rewards pot while tightening eligibility for rewards (e.g., by requiring a witness within `delegatorInactivity` epochs) and optionally lowering `Rho` to compensate is that it slows the depletion of reserves, yet still marginally increases rewards for active delegators and SPOs. Empirical projections (e.g., Leios/CPS modeling and CPS‑22 forecasts) suggest sustaining current reward trajectories could require materially higher transaction throughput or faster reserve drawdown. By excluding long‑dormant credentials from the payout base we simply avoid paying rewards to wallets that are unlikely to ever reuse them. That reduction in the set of eligible reward accounts lengthens reserve lifetime in a predictable way while still delivering higher per‑unit yields to genuinely active delegators and SPOs.\n \nThis is a policy lever with clear tradeoffs: the community can preserve the nominal emission schedule by lowering `Rho`, which maintains the same long‑term reserve trajectory but gives up the near‑term yield uplift for active participants; or the community can keep `Rho` and accept faster nominal depletion while shifting more reward flow to active participants today. Because the change is expressed as an eligibility rule rather than a confiscation, it preserves property rights and is operationally simple to reason about.  It therefore offers a modest, low‑risk way to buy more runway for broader, longer‑term value‑creation efforts (e.g., higher fees/tx volume, DeFi growth) that are the real sustainable solution.\n\n### Prior rationale and revised censorship assessment\n\nThe Shelley-era design explicitly worried about an incentive for large pools to **censor delegation certificates** if rewards were distributed in ways that made existing actors worse off when new delegations appeared. To mitigate this, the specification chose (a) to normalize reward shares by **total stake** rather than active stake so that new delegations do not dilute incumbents’ proportional rewards. Also, (b) to send **undistributed** rewards back to reserves. See *Shelley Delegation & Incentives Design Spec.*, SL‑D1 v1.21 (2020‑07‑23), §5.5.1 “Relative Stake: Active vs Total” (p. 35), and change log rev. 17 (“undistributed rewards go to the reserves”). The spec also anticipated concerns about pools rejecting or disadvantaging delegation transactions (Appendix D.2, p. 52).\n\n**Why this is acceptable to revisit now.** Today’s network conditions and incentives make sustained censorship of delegation renewals economically implausible and strategically dominated by other attack vectors:\n\n- **Healthy stake distribution & coordination threshold.** With broad dispersion of block‑producing power, a would‑be censor would need to withhold a large number of small delegation transactions across many blocks and coordinate with many other producers to move rewards meaningfully. Any unilateral attempt simply fails whenever other producers include those transactions.\n- **Externality of “success.”** Under full‑pot distribution, even a successful bout of censorship raises everyone else’s yields, not just the censor’s. This dilutes the payoff while increasing incentives for others to defect and include the transactions.\n- **Richer targets exist.** In a DeFi‑enabled ecosystem, selective censorship of high‑value transactions (e.g., liquidations/arbitrages) offers a concentrated, private payoff from censoring few targeted transactions, whereas delegation censorship requires suppressing many of them for marginal gains.\n- **Operational risk and visibility.** Prolonged, coordinated censorship would be conspicuous, invite social and governance backlash, and likely degrade a censor’s reputation and delegation flow, offsetting any transient gain.\n\nThese factors, together with periodic account-liveness expiry/renewal that naturally spreads liveness-reset actions over time, support removing the “return to reserves” scaling while keeping incentives aligned with **active participation**.\n\n### Security consideration: participation shocks after large expirations\n\nIntroducing inactivity expiry could, in the short term, allow portions of stake to lapse if large wallets forget or delay renewal. This temporarily reduces the **active‑stake ratio**, widening the gap between total and active stake. In such windows, the cost for an adversary to assemble a large share of active stake is lower than usual, and block production can concentrate among a smaller set of pools until new delegations occur.\n\n**Balancing mechanism in this CIP.** The proposal deliberately pairs expirations with full‑pot reward distribution. Because the entire pot is distributed over the then‑active stake, the per‑unit yield rises automatically when participation drops and compresses when it rises. This creates a fast, transparent negative‑feedback loop:\n\n- If active stake decreases, epoch yield increases for active delegators/SPOs. Capital is attracted back until the security margin normalizes.\n- Likewise if active stake increases, epoch yield decreases. Though without changes to Rho the net result of this CIP will still increase rewards all the way up to 100% of active-stake ratio.\n\nThis dynamic couples network security to real participation and reduces the risk of active-stake dropping too low.\n\n### Evidence and modeling\n\n- **Reserves trajectory** will be closer to true Rho after this CIP is implemented\n  - Red = ADA in reserves if we followed Rho exactly\n  - Yellow = ADA in reserves account for actual blocks produced (Eta) and missing pledge. This is the track the reserves is expected to follow after the inclusion of this CIP.\n  - Green = Actual amount of ADA in reserves\n\n  ![Reserve Depletion)](Fig1.png)\n\n*Source: [https://x.com/C1cADA_Markus/status/1636023370532749314](https://x.com/C1cADA_Markus/status/1636023370532749314)*\n\n- Estimated **~1% APY uplift** from full‑pot distribution:\n\nGiven:\n\nWe can calculate the expected ROI for an average pool with 35M stake and 1M pledge before this CIP as follows:\n\n**Constants:**\n\n- $S = 35,698,219,658$ (circulating supply)  \n- $\\text{Reserves} = 6,955,875,027$  \n- $k = 500 \\;\\Rightarrow\\; z_0 = 0.002$  \n- $a_0 = 0.3$  \n- $\\rho = 0.003$  \n- $\\tau = 0.2$  \n\n**Epoch rewards pot after treasury (not accounting for fees or missed blocks):**\n\n$$\nR = (\\rho \\cdot \\mathrm{Reserves}) \\cdot (1 - \\tau) = 16{,}694{,}100.0648\n$$\n\n**Pool (average pool with 35M stake and 1M pledge):**\n\n- $x = 35,000,000$ (stake)  \n- $y = 1,000,000$ (pledge)  \n\n$$\nz = \\frac{35{,}000{,}000}{35{,}698{,}219{,}658} = 0.000980441051\n$$\n\n$$\ns = \\frac{1{,}000{,}000}{35{,}698{,}219{,}658} = 0.000028012601\n$$\n\n$$\nz' = \\min(z, z_{0}), \\quad s' = \\min(s, z_{0})\n$$\n\n**Base reward (from Shelley formula):**\n\n$$\nB = \\frac{R}{1+a_{0}} \\left(\nz' + s' \\cdot a_{0} \\cdot \\frac{\\,z' - s' \\cdot \\frac{(z_{0}-z')}{z_{0}}\\,}{z_{0}}\n\\right)\n$$\n\n**For this pool:**\n\n$$\nB = 12{,}642.580060\n$$\n\n**Standard distribution (spec):** distributes $R$ to active pools and returns the rest to reserves\n\n$$\nf_{\\mathrm{std}} = B = 12{,}642.580060\n$$\n\n```math\n\\begin{aligned}\n\\mathrm{ROI}_{\\mathrm{pool,std}} &= \\frac{f_{\\mathrm{std}}}{x+y} \\\\\n&= \\frac{12{,}642.580060}{36{,}000{,}000} \\\\\n&= 0.000351182779\n\\end{aligned}\n```\n\n```math\n\\begin{aligned}\n\\mathrm{Annual\\ ROI} &= \\left(1 + \\mathrm{ROI}_{\\mathrm{pool,std}}\\right)^{73} - 1 \\\\\n&= 0.025963163 \\;\\; (\\approx 2.5963\\%)\n\\end{aligned}\n```\n\nThis gives us about **2.60% Annual ROI** for that pool.\n\n---\n\n**Full pot rewards distribution: distribute all of $R$ with no residual**\n\nLet $W = \\sum_i B_i$ over all eligible pools (whole circulation). Typically $W \\approx 1$.\n\nThen normalize:\n\n$$\nf_{\\mathrm{full}} = R \\cdot \\frac{B}{W} \\;\\approx\\; (1+a_{0}) \\cdot B = 16{,}435.354078\n$$\n\n```math\n\\begin{aligned}\n\\mathrm{ROI}_{\\mathrm{epoch,full}} &= \\frac{f_{\\mathrm{full}}}{x+y} \\\\\n&= \\frac{16{,}435.354078}{36{,}000{,}000} \\\\\n&= 0.000456537613\n\\end{aligned}\n```\n\n```math\n\\begin{aligned}\n\\mathrm{ROI}_{\\mathrm{annual,full}} &= \\left(1 + \\mathrm{ROI}_{\\mathrm{epoch,full}}\\right)^{73} - 1 \\\\\n&= 0.033880957 \\;\\; (\\approx 3.3881\\%)\n\\end{aligned}\n```\n\nThe result is about **3.39% Annual ROI**. Roughly a 0.79% increase.\n\n**Note:** These calculations do not take into account any collected transaction fees, pool performance, or pool fees.\n\nThese effects are also modeled in the open source tool available at [https://spo-incentives.vercel.app/](https://spo-incentives.vercel.app/). Setting the rewards formula radio button to “Current” represents the current rewards calculation behavior. Setting it to “Full” represents the rewards calculation after applying this CIP. It is also recommended to experiment with the “Staked Ratio” slider under both of those settings to see how it will affect rewards.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- **CIP Editor Approval** – Cardano CIP Editors must confirm that the specification is complete, unambiguous, and internally consistent with existing CIPs.\n- **Consensus on initial parameter value(s)** – An initial value for the new protocol parameter `delegatorInactivity` in epochs must be agreed upon before hard-fork combinator (HFC) activation. The choice should consider operational viability, empirical analyses, and community feedback.\n- **Endorsement by Technical Bodies** – The Cardano Parameter-Change Proposals (PCP) Committee and the Intersect Technical Steering Committee (TSC) should both recommend the proposal as technically sound and aligned with the protocol’s long-term roadmap.\n- **Stakeholder Concurrence** – A majority of stake pool operators (SPOs), ecosystem tooling maintainers, dReps, and other infrastructure providers must signal readiness to upgrade.\n- **Governance Ratification** – The on-chain Hard-Fork Governance Action must pass the requisite dRep and Constitutional Committee thresholds, establishing legal-constitutional legitimacy and stakeholder support for the change.\n\n### Implementation Plan\n\n- **Community Deliberation (Preparation Phase)**\n  - Publish the finalized CIP revision and present it to the PCP committee, TSC, CIP Editors, and wider community channels (Discord, X, Cardano Forum, etc.).\n  - Collect structured feedback, particularly on candidate values for the new parameter values and iterate until broad technical consensus emerges.\n- **Specification & Code Integration (Development Phase)**\n  - Once initial parameter values are determined, integrate the new rewards calculation logic, delegation certificate expiry, and governance features for the new parameters into cardano-node and related libraries (ledger, CLI, wallet APIs).\n  - Submit pull requests to the canonical repositories; obtain code reviews from IOG, CF, and community contributors.\n  - Release a new protocol version that includes the changes made in this CIP.\n  - Use a dedicated pre-production testnet that mirrors main-net parameters but enforces the new changes, allowing SPOs and exchanges to test end-to-end flows.\n- **Readiness Sign-off (Testing Phase)**\n  - Require at least two weeks of uninterrupted testnet stability plus green results from regression and property-based tests.\n  - Monitor ecosystem dApps and tooling to confirm that major node implementations, explorers, wallets, and exchange integrations support the new rule set.\n- **On-chain Governance (Ratification Phase)**\n  - File the Hard-Fork Governance Action on-chain with the agreed initial parameter values tagged for the next hard fork event.\n  - Modify the existing Cardano Constitution to include definitions and guardrails for the new protocol parameters and have it ratified by the tripartite government of Cardano.\n  - Mobilize dRep outreach to ensure quorum and super-majority passage; concurrently, the Constitutional Committee validates procedural compliance.\n- **Hard-Fork Activation (Deployment Phase)**\n  - Upon successful vote, the hard fork event is automatically triggered upon epoch turnover.\n  - Monitor main-net metrics during the changeover epoch; provide real-time support for any late-upgrading SPOs.\n\n## References\n\n- Kant, P.; Brünjes, L.; Coutts, D. *Design Specification for Delegation and Incentives in Cardano — Shelley* (SL‑D1 v1.21, 23 Jul 2020). Especially §5.5.1 “Relative Stake: Active vs Total” (p. 35); Appendix D.2 “Won’t stake pools reject delegation certificates that delegate away from them?” (p. 52); and change log rev. 17 (“Undistributed rewards go to the reserves, not to the treasury.”).\n- Corduan, J.; Vinogradova, P.; Güdemann, M. *A Formal Specification of the Cardano Ledger* (Shelley Ledger: SL‑D5 v1.0, updated 23 Mar 2023). Section 11: Rewards and the Epoch Boundary — overview (§11.1), snapshots (§11.5), epoch transition (§11.8), rewards distribution (§11.9), and reward update/return‑to‑reserves residual (∆r₂) (§11.10).\n- Wiley, R. *CPS-0022: Sticky Stake and Time-Bound Delegation* (2025). Available at: https://github.com/Cerkoryn/CIPs/blob/sticky-stake/CPS-0022/README.md.\n\n## Acknowledgements\n\nThis CIP could not have been created without the support, assistance, and input of all participants in the community-led SPO Incentives Working Group.\n\n- Stef M [RABIT]\n- Rich Manderino [ECP] \n- Wayne Cataldo [OTG]\n- Homer [AAA]\n- Chad [BBHMM]\n- Mark H [UPSTR]\n- Carlos Lopez de Lara [Input|Output]\n- Pedro Lucas\n- Seomon\n- OYSTR Pool\n\n## Copyright\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)."
  },
  {
    "path": "CIP-0164/README.md",
    "content": "---\nCIP: 164\nTitle: Ouroboros Linear Leios - Greater transaction throughput\nStatus: Proposed\nCategory: Consensus\nAuthors:\n  - William Wolff <william.wolff@iohk.io>\n  - Brian W Bush <brian.bush@iohk.io>\n  - Sebastian Nagel <sebastian.nagel@iohk.io>\n  - Nicolas Frisby <nick.frisby@iohk.io>\n  - Giorgos Panagiotakos <giorgos.panagiotakos@iohk.io>\n  - Andre Knipsel <andre.knispel@iohk.io>\n  - Yves Hauser <yves.hauser@iohk.io>\n  - Simon Gellis <simon@sundae.fi>\nImplementors:\n  - Input Output Engineering\nDiscussions:\n  - https://github.com/input-output-hk/ouroboros-leios/discussions\n  - https://github.com/cardano-foundation/CIPs/pull/1078\nSolution-To:\n  - CPS-0018\nCreated: 2025-03-07\nLicense: Apache-2.0\n---\n\n## Abstract\n\nThe anticipated growth of the Cardano ecosystem necessitates a fundamental\nenhancement of network throughput to accommodate increasing transaction volumes\nand support complex decentralized applications.\n\nWe propose Ouroboros Leios, an optimistic consensus protocol designed for\nhigh-throughput operation while preserving Ouroboros Praos security properties.\nBlock producers simultaneously create both a standard Praos block and a larger\nsecondary block referencing additional transactions. Secondary blocks undergo\ncommittee validation before ledger inclusion, enabling significantly higher\nthroughput.\n\nFor a quick 5-minute overview of Ouroboros Leios, see our\n[summary document](SUMMARY.md).\n\nFor comprehensive research documentation, development history, and additional\ntechnical resources, visit the Leios Innovation R&D site at\n[leios.cardano-scaling.org][leios-website].\n\n<details>\n  <summary><h2>Table of contents</h2></summary>\n\n- [Abstract](#abstract)\n- [Motivation: why is this CIP necessary?](#motivation-why-is-this-cip-necessary)\n- [Specification](#specification)\n  - [Protocol Flow](#protocol-flow)\n    - [Step 1: Block Production](#step-1-block-production)\n    - [Step 2: EB Distribution](#step-2-eb-distribution)\n    - [Step 3: Committee Validation](#step-3-committee-validation)\n    - [Step 4: Certification](#step-4-certification)\n    - [Step 5: Chain Inclusion](#step-5-chain-inclusion)\n  - [Protocol Parameters](#protocol-parameters)\n    - [Timing parameters](#timing-parameters)\n    - [Size parameters](#size-parameters)\n  - [Protocol Security](#protocol-security)\n  - [Protocol Artifacts](#protocol-artifacts)\n    - [Ranking Blocks (RBs)](#ranking-blocks-rbs)\n    - [Endorser Blocks (EBs)](#endorser-blocks-ebs)\n    - [Votes and Certificates](#votes-and-certificates)\n  - [Node Behavior](#node-behavior)\n    - [Transaction Diffusion](#transaction-diffusion)\n    - [RB Block Production and Diffusion](#rb-block-production-and-diffusion)\n    - [EB Diffusion](#eb-diffusion)\n    - [Voting \\& Certification](#voting--certification)\n    - [Next Block Production](#next-block-production)\n    - [Ledger Management](#ledger-management)\n    - [Epoch Boundary](#epoch-boundary)\n    - [Operational certificate issue numbers](#operational-certificate-issue-numbers)\n  - [Network](#network)\n    - [Praos Mini-Protocols](#praos-mini-protocols)\n    - [Leios Mini-Protocols](#leios-mini-protocols)\n  - [Incentives](#incentives)\n    - [Adaptive EB production](#adaptive-eb-production)\n    - [Hardware upgrade](#hardware-upgrade)\n  - [Clients](#clients)\n- [Rationale: how does this CIP achieve its goals?](#rationale-how-does-this-cip-achieve-its-goals)\n  - [How Leios addresses CPS-18](#how-leios-addresses-cps-18)\n  - [Evidence](#evidence)\n    - [Performance Metrics](#performance-metrics)\n    - [Simulation Results](#simulation-results)\n  - [Feasible Protocol Parameters](#feasible-protocol-parameters)\n  - [Trade-offs \\& Limitations](#trade-offs--limitations)\n  - [Design Decisions](#design-decisions)\n    - [Transaction References in Endorser Blocks](#transaction-references-in-endorser-blocks)\n  - [Alternatives \\& Extensions](#alternatives--extensions)\n- [Path to active](#path-to-active)\n  - [Acceptance criteria](#acceptance-criteria)\n  - [Implementation plan](#implementation-plan)\n- [Versioning](#versioning)\n- [References](#references)\n- [Appendix](#appendix)\n- [Copyright](#copyright)\n\n</details>\n\n<details>\n  <summary><h2>Index of figures and tables</h2></summary>\n\n**Figures**\n\n- [Figure 1: Forecast of rewards on Cardano mainnet](#figure-1)\n- [Figure 2: SPO profitability under Praos if the Reserves did not contribute to rewards](#figure-2)\n- [Figure 3: Leios chain structure showing Ranking Blocks, Endorser Blocks, and Certificates](#figure-3)\n- [Figure 4: Detailed timing mechanism showing timing constraints for EB certification](#figure-4)\n- [Figure 5: Up- and downstream interactions of a node](#figure-5)\n- [Figure 6: LeiosNotify mini-protocol state machine](#figure-6)\n- [Figure 7: LeiosFetch mini-protocol state machine](#figure-7)\n- [Figure 8: SPO profitability forecast under Leios](#figure-8)\n- [Figure 9: Time for transaction to reach the ledger](#figure-9)\n- [Figure 10: Transactions reaching the ledger](#figure-10)\n- [Figure 11: Number of TX references](#figure-11)\n- [Figure 12: Disposition of transactions in blocks](#figure-12)\n- [Figure 13: Size of transactions referenced by EBs](#figure-13)\n- [Figure 14: Leios throughput vs load](#figure-14)\n- [Figure 15: Delivery time and Leios delay](#figure-15)\n- [Figure 16: Processing cost per TX: CPU and network](#figure-16)\n- [Figure 17: Arrival delays for TX, RB, VT, and EB](#figure-17)\n- [Figure 18: Mean network ingress and CPU load](#figure-18)\n- [Figure 19: Mean CPU load across nodes](#figure-19)\n- [Figure 20: Fate of Plutus-heavy transactions](#figure-20)\n- [Figure 21: CPU usage in Plutus-heavy workloads](#figure-21)\n- [Figure 22: Leios variants comparison](#figure-22)\n\n**Tables**\n\n- [Table 1: Network Characteristics](#table-1)\n- [Table 2: Ledger Characteristics](#table-2)\n- [Table 3: Protocol Parameters](#table-3)\n- [Table 4: Leios Information Exchange Requirements (IER) table](#table-4)\n- [Table 5: Performance Metrics](#table-5)\n- [Table 6: Leios efficiency at different throughputs](#table-6)\n- [Table 7: Feasible Protocol Parameters](#table-7)\n- [Table 8: Operating Costs by Transaction Throughput](#table-8)\n- [Table 9: Required TPS for Infrastructure Cost Coverage](#table-9)\n- [Table 10: Required TPS for Current Reward Maintenance](#table-10)\n\n</details>\n\n## Motivation: why is this CIP necessary?\n\nCardano's current throughput generally satisfies the immediate needs of its\nusers. However, the Ouroboros Praos consensus protocol imposes inherent\nscalability limitations. To ensure timely and reliable global propagation of new\nblocks, the protocol requires that blocks be distributed across the network\nwithin a short time frame. This requirement forces a careful balance,\nrestricting both the maximum size of individual blocks and the computational\nresources available for validating transactions and Plutus scripts. As a result,\nthere is a fixed ceiling on the network's transaction throughput that cannot be\nraised by adjusting protocol parameters alone.\n\nHowever, the dynamic growth of the Cardano ecosystem is increasingly revealing\nthe practical consequences of these inherent limitations. The Cardano mainnet\nperiodically experiences periods of significant congestion, where the volume of\ntransactions awaiting processing surpasses the network's ability to include them\nin a timely manner. This congestion can lead to a tangible degradation in the\nuser experience, manifesting as delays in transaction confirmation. Moreover, it\nposes substantial obstacles for specific use cases that rely on the efficient\nprocessing of large volumes of transactions, such as the distribution of tokens\nvia airdrops, or the rapid and consistent updating of data by decentralized\noracles or partner chains.\n\nThe semi-sequential nature of block propagation in Ouroboros Praos, where blocks\nare relayed from one block producer to the next across potentially\ngeographically distant nodes, is a key factor contributing to these limitations.\nThe necessity of completing this global dissemination within the few-second\nperiod places a fundamental constraint on the rate at which new blocks, and\nconsequently the transactions they contain, can be added to the blockchain. This\narchitectural characteristic stands in contrast to the largely untapped\npotential of the network's underlying infrastructure, where the computational\nand bandwidth resources of individual nodes often remain significantly\nunderutilized.\n\nTo transcend these inherent scaling barriers and unlock the latent capacity of\nthe Cardano network, a fundamental systematic evolution of the core consensus\nalgorithm is imperative. Ouroboros Leios maintains Praos' sequential transaction\nprocessing model while introducing mechanisms for additional transaction\ncapacity through Endorser Blocks, parallel validation workflows, and more\nefficient aggregation of transaction data. By reorganizing how transactions are\nproposed, validated, and ultimately recorded on the blockchain, this protocol\nupgrade seeks to achieve a substantial increase in the network's overall\nthroughput, enabling it to handle a significantly greater volume of transactions\nwithin a given timeframe.\n\nThe Cardano Problem Statement [CPS-18 Greater Transaction Throughput][cps-18]\nfurther motivates the need for higher transaction throughput and marshals\nquantitative evidence of existing mainnet bottlenecks. Realizing higher\ntransaction rates is also necessary for long-term Cardano techno-economic\nviability as rewards contributions from the Reserve pot diminish: fees from more\ntransactions will be needed to make up that deficit and keep sound the finances\nof stake pool operations.\n\nA major protocol upgrade like Leios will take significant time to implement,\ntest, and audit. It is therefore critical to have begun implementation well\nbefore transaction demand on mainnet exceeds the capabilities of Ouroboros\nPraos. The plot below shows the historically diminishing rewards and a forecast\nof their continued reduction: the forecast is mildly uncertain because the\nfuture pattern of staking behavior, transaction fees, and node efficiency might\nvary considerably.\n\n<div align=\"center\">\n<a name=\"figure-1\" id=\"figure-1\"></a>\n<p>\n  <img src=\"images/reward-forecast-bau.svg\" alt=\"Forecast of rewards on Cardano mainnet\">\n</p>\n\n<em>Figure 1: Forecast of rewards on Cardano mainnet</em>\n\n</div>\n\nOuroboros Praos cannot support the high transaction volume needed to generate\nthe fees that will eventually be needed to offset the diminishing rewards.\nHowever, as sustained throughput of transactions grows beyond\n[50 transactions per second](https://github.com/input-output-hk/ouroboros-leios/blob/d5f1a9bc940e69f406c3e25c0d7d9aa58cf701f8/docs/cost-estimate/README.md#required-tps-for-current-reward-maintenance),\nthere is more opportunity for simultaneously reducing fees, augmenting the\nTreasury, and increasing SPO and delegator rewards.\n\n<div align=\"center\">\n<a name=\"figure-2\" id=\"figure-2\"></a>\n<p>\n  <img src=\"images/spo-profitability.svg\" alt=\"SPO profitability under Praos, as a function of transaction volume\">\n</p>\n\n<em>Figure 2: SPO profitability under Praos if the Reserves did not contribute\nto rewards, as a function of transaction volume.[^profitability]</em>\n\n</div>\n\nThe Leios protocol specified in this document represents a balance between\nimmediate scalability needs and long-term protocol evolution. The approach\nprioritizes practical deployment and ecosystem compatibility while establishing\nthe foundation for subsequent protocol versions with higher throughput capacity.\n\n## Specification\n\nOuroboros Leios achieves higher transaction throughput by allowing block\nproducers to create additional blocks alongside the regular Praos chain. These\nsupplementary blocks, called **Endorser Blocks (EBs)**, reference extra\ntransactions that would otherwise wait for the standard Praos blocks (called\n**Ranking Blocks** or **RBs** in this protocol) in future active slots. To\nensure data availability and correctness, these blocks undergo committee\nvalidation before their transactions become part of the permanent ledger.\n\nThe key insight is that we can maintain Praos' security guarantees while\nprocessing more transactions by carefully managing when and how these additional\nblocks are validated and included in the chain.\n\n> [!NOTE]\n>\n> The Agda formal specification for the proposed Leios protocol is available\n> [here][linear-leios-formal-spec].\n\n<div align=\"center\">\n  <a name=\"figure-3\" id=\"figure-3\"></a>\n  <p name=\"protocol-overview\">\n    <img src=\"images/protocol-overview.svg\" alt=\"Leios Chain Structure\">\n  </p>\n\n<em>Figure 3: Leios chain structure showing the relationship between Ranking\nBlocks, Endorser Blocks, and Certificates</em>\n\n</div>\n\nThe horizontal spacing in Figure 3 reflects the opportunistic nature of EB\ninclusion: some EBs get certified and are included in the chain (green), while\nothers cannot be certified in time (gray). This happens because Praos block\nproduction is probabilistic - some RBs will naturally occur before there has\nbeen sufficient time for the preceding EB to gather the necessary votes and\ncertification, invalidating these EBs to become adopted. The key insight is that\nproposed Leios utilizes the natural intervals between Praos blocks to perform\nadditional work on transaction processing without interfering with the base\nchain operation.\n\nEB inclusion is therefore opportunistic rather than guaranteed, depending on the\nrandom timing of block production relative to the certification process. The\nprecise timing mechanism is detailed in the following section.\n\n### Protocol Flow\n\nThe protocol operates through five sequential steps that involve three critical\ntiming constraints. Figure 4 visualizes the precise timing mechanism that\ngoverns when certificates can be safely included in the chain, showing both the\nunderlying network characteristics ($\\Delta$ values) and the protocol parameters\n($L$ values) that inform their design.\n\n<div align=\"center\">\n  <a name=\"figure-4\" id=\"figure-4\"></a>\n  <p name=\"protocol-flow-figure\">\n    <img src=\"images/protocol-flow.svg\" alt=\"Leios Protocol Flow\">\n  </p>\n\n<em>Figure 4: Detailed timing mechanism showing the three critical timing\nconstraints for EB certification</em>\n\n</div>\n\n#### Step 1: Block Production\n\nLeios preserves the existing Praos chain structure while adding additional\ntransaction capacity through EBs. When a stake pool wins slot leadership, it may\ncreate two objects:\n\n1. **[Ranking Block (RB)](#ranking-blocks-rbs)** A standard Praos block with\n   extended header fields to optionally certify one previously announced EB and\n   optionally announce one EB for the next subsequent RB (i.e., `RB'`) to\n   optionally certify.\n1. **[Endorser Block (EB)](#endorser-blocks-ebs)** A larger block containing\n   references to additional transactions.\n\nThe RB chain continues to be distributed exactly as in Praos, while Leios\nintroduces separate distribution mechanisms for EB headers (for rapid discovery\nand <a id=\"equivocation\" href=\"#equivocation-detection\">equivocation\ndetection</a>), EB bodies, and their referenced transactions.\n\nDue to the voting overhead per EB, EBs should only be announced if a transaction\ncannot be included in the base RB. Empty EBs should not be announced in the\nnetwork as they induce a non-zero cost. Note that whether an RB is full is not\nsolely determined by its byte size; in particular, the per-block Plutus limits\ncould be the reason an RB cannot contain additional transactions. The lower\nlatency provided by RBs naturally incentivizes their use first, enabling gradual\nadoption of Leios capabilities.\n\n#### Step 2: EB Distribution\n\nNodes receiving the RB header discover the announced EB and fetch its body. The\nEB body contains references to transactions. If a node does not already possess\na transaction referenced in the EB, it explicitly requests that transaction from\npeers. The whole process of propagating EBs and referenced transactions is\ncalled EB transmission. Only minimal validation is done before forwarding this\ndata to ensure rapid dissemination while full validity is determined by the\n[voting committee](#step-3-committee-validation).\n\nMinimal validation includes basic structural and cryptographic integrity checks\n(VRF verification, block hash validation, and header format verification).\n\n#### Step 3: Committee Validation\n\nAfter the [equivocation detection period](#equivocation-detection) of\n$3 L_\\text{hdr}$ slots, a voting committee of stake pools validates the EB and\nvotes within a [voting period](#voting-period) $L_\\text{vote}$. Committee\nmembers are [selected via sortition](#committee-structure) based on the slot\nnumber of the RB that announced the EB. A committee member votes for an EB only\nif:\n\n1. The RB header arrived within $L_\\text{hdr}$,\n2. It has **not** detected any equivocating RB header for the same slot,\n3. It finished validating the EB before $3 \\times L_\\text{hdr} + L_\\text{vote}$\n   slots after the EB slot,\n4. The EB is the one announced by the latest RB in the voter's current chain,\n5. The EB's transactions form a **valid** extension of the RB that announced it,\n6. For non-persistent voters, it is eligible to vote based on sortition using\n   the announcing RB's slot number as the election identifier,\n7. The EB contains at least one transaction (i.e., is not empty), as specified\n   in the [formal specification][leios-formal-spec-empty-eb].\n\nwhere $L_\\text{hdr}$ and $L_\\text{vote}$ are\n<a href=\"#protocol-parameters\">protocol parameters</a> represented by a number\nof slots.\n\n#### Step 4: Certification\n\nDuring the voting period, if enough committee votes are collected such that the\ntotal stake exceeds a **high threshold** parameter ($\\tau$), for example 75%,\nthe EB becomes **certified**:\n\n$$\n\\sum_{v \\in \\text{votes}} \\text{stake}(v) \\geq \\tau \\times \\text{stake}_{\\text{total-active}}\n$$\n\nThe **high voting threshold** (e.g., 75%) ensures that any certified EB is\nalready known to a large portion of the network (>25% even with 50% adversarial\nstake) by the end of the voting period. This widespread initial knowledge\nenables the network assumption that the EB will reach all honest parties within\nthe additional diffusion period $L_\\text{diff}$. See\n[Protocol Parameters](#protocol-parameters) for details. A ranking block (RB)\nproducer can then construct a compact certificate proving the EB's validity by\naggregating the collected votes.\n\n#### Step 5: Chain Inclusion\n\nBlock producers creating subsequent RBs (`RB'`) may only include valid\ncertificates for the EB announced by a preceding block (`RB`) if sufficient time\nhas elapsed. See also Figure 4. Concretely, the inclusion rules are:\n\n1. `RB'` contains **either**\n\n   a. a certificate for the EB announced in `RB`, **or**\n\n   b. a list of transactions forming a valid extension of `RB`.\n\n2. Any included certificate must be valid as defined in\n   [Certificate Validation](#certificate-validation).\n\n3. A certificate may only be included if `RB'` is at least\n   $3 \\times\n   L_\\text{hdr} + L_\\text{vote} + L_\\text{diff}$ slots after `RB`.\n\n4. Regardless of whether `RB'` includes a certificate, it may optionally\n   announce its own EB for future certification.\n\nwhere $L_\\text{hdr}$, $L_\\text{vote}$ and $L_\\text{diff}$ are\n<a href=\"#protocol-parameters\">protocol parameters</a> represented by a number\nof slots.\n\nThe certificate inclusion delay ensures certified EBs have sufficient time to\ndiffuse throughout the network and do not impact\n[protocol security](#protocol-security). When a certificate is included, no\nfurther transactions are allowed in the RB for the same reason.\n\nIf transactions next to the certificate would be allowed, a validating node\nwould need to build the ledger state from all endorsed transactions before it\ncan validate the transactions in the same block, resulting in much stricter\ntiming constraints to ensure [protocol security](#protocol-security).\n\nIf the next RB is produced before this minimum delay has elapsed, the EB\ncertificate cannot be included and the EB is discarded.\n\n### Protocol Parameters\n\nThe protocol parameters are tunable values that can be adjusted via governance.\nThese parameters fall into two categories: timing parameters derived from the\nnetwork characteristics below and timing constraints, and size/resource\nparameters that manage throughput.\n\nThe certificate inclusion process (Steps 3-5) involves three timing constraints\nthat work together to maintain Praos' security assumptions while enabling higher\nthroughput. These constraints prevent scenarios where honest nodes would be\nforced to delay chain adoption due to missing data.\n\n<a id=\"network-characteristics\"></a>**Network Characteristics**\n\nThe protocol timing is built upon observed network characteristics that describe\nhow quickly different types of data propagate. All timing parameters target\npropagation to ~95% of honest stake, which represents practical network-wide\navailability:\n\n<div align=\"center\">\n<a name=\"table-1\" id=\"table-1\"></a>\n\n| Characteristic                                                       |            Symbol             | Description                                                                                                                 | Observed Range by Simulations |\n| -------------------------------------------------------------------- | :---------------------------: | --------------------------------------------------------------------------------------------------------------------------- | :---------------------------: |\n| <a id=\"delta-hdr\" href=\"#delta-hdr\"></a>Header propagation           |      $\\Delta_\\text{hdr}$      | Time for constant size headers (< 1,500 bytes) to propagate network-wide                                                    |          < 1 second           |\n| <a id=\"delta-rb\" href=\"#delta-rb\"></a>RB diffusion                   |      $\\Delta_\\text{RB}$       | Complete ranking block propagation and adoption time                                                                        |          < 5 seconds          |\n| <a id=\"delta-eb-H\" href=\"#delta-eb-H\"></a>EB optimistic diffusion    | $\\Delta_\\text{EB}^{\\text{O}}$ | EB **diffusion** time (transmission + processing) under favorable network conditions                                        |          1-3 seconds          |\n| <a id=\"delta-eb-A\" href=\"#delta-eb-A\"></a>EB worst-case transmission | $\\Delta_\\text{EB}^{\\text{W}}$ | EB **transmission** time for certified EBs starting from >25% network coverage (processing already completed during voting) |         15-20 seconds         |\n\n<em>Table 1: Network Characteristics</em>\n\n</div>\n\n> [!NOTE]\n>\n> **Network Condition**\n>\n> The exact definition of \"optimistic\" and \"worst-case\" network conditions may\n> be refined based on empirical measurements and deployment experience. For\n> example, optimistic conditions might be defined as \"no fresher RB\" or \"at most\n> 2 fresher RBs\", depending on how these conditions impact throughput and\n> $\\Delta_\\text{EB}^{\\text{W}}$. The specific thresholds should be determined\n> through testnet validation and performance analysis.\n\n<div align=\"center\">\n<a name=\"table-2\" id=\"table-2\"></a>\n\n| Characteristic                                                           |          Symbol          | Description                                                     | Observed Range by Simulations |\n| ------------------------------------------------------------------------ | :----------------------: | --------------------------------------------------------------- | :---------------------------: |\n| <a id=\"delta-reapply\" href=\"#delta-reapply\"></a>EB reapplication         | $\\Delta_\\text{reapply}$  | Certified EB reapplication with minimal checks and UTxO updates |          < 1 second           |\n| <a id=\"delta-applytxs\" href=\"#delta-applytxs\"></a>Transaction validation | $\\Delta_\\text{applyTxs}$ | Standard Praos transaction validation time for RB processing    |           ~1 second           |\n\n<em>Table 2: Ledger Characteristics</em>\n\n</div>\n\n**Protocol Parameters**\n\n<div align=\"center\">\n<a name=\"table-3\" id=\"table-3\"></a>\n\n| Parameter                                                      |      Symbol      |    Units     | Description                                                                                 | Rationale                                                                                                                                                                                                                                        |\n| -------------------------------------------------------------- | :--------------: | :----------: | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| <a id=\"l-hdr\" href=\"#l-hdr\"></a>Header diffusion period length |  $L_\\text{hdr}$  |     slot     | Duration for RB headers to propagate network-wide                                           | Per [equivocation detection](#equivocation-detection): must accommodate header propagation for equivocation detection.                                                                                                                           |\n| <a id=\"l-vote\" href=\"#l-vote\"></a>Voting period length         | $L_\\text{vote}$  |     slot     | Duration during which committee members can vote on endorser blocks                         | Per [voting period](#voting-period): must accommodate EB propagation and validation time. Set to minimum value that ensures honest parties can participate in voting                                                                             |\n| <a id=\"l-diff\" href=\"#l-diff\"></a>Diffusion period length      | $L_\\text{diff}$  |     slot     | Additional period after voting to ensure network-wide EB availability                       | Per [diffusion period](#diffusion-period): derived from the fundamental safety constraint. Leverages the network assumption that data known to >25% of nodes propagates fully within this time                                                   |\n| Ranking block max size                                         |  $S_\\text{RB}$   |    bytes     | Maximum size of a ranking block                                                             | Limits RB size to ensure timely diffusion                                                                                                                                                                                                        |\n| Endorser-block referenceable transaction size                  | $S_\\text{EB-tx}$ |    bytes     | Maximum total size of transactions that can be referenced by an endorser block              | Limits total transaction payload to ensure timely diffusion within stage length                                                                                                                                                                  |\n| Endorser block max size                                        |  $S_\\text{EB}$   |    bytes     | Maximum size of an endorser block itself                                                    | Limits EB size to ensure timely diffusion; prevents issues with many small transactions                                                                                                                                                          |\n| Mean committee size                                            |       $n$        |   parties    | Average number of stake pools selected for voting                                           | Ensures sufficient decentralization and security                                                                                                                                                                                                 |\n| Quorum size                                                    |      $\\tau$      |   fraction   | Minimum fraction of committee votes required for certification                              | High threshold ensures certified EBs are known to >25% of honest nodes even with 50% adversarial stake. This widespread initial knowledge enables the network assumption that certified EBs will reach all honest parties within $L_\\text{diff}$ |\n| Maximum Plutus steps per endorser block                        |        -         |  step units  | Maximum computational steps allowed for Plutus scripts in a single endorser block           | Limits computational resources per EB to ensure timely validation                                                                                                                                                                                |\n| Maximum Plutus memory per endorser block                       |        -         | memory units | Maximum memory allowed for Plutus scripts in a single endorser block                        | Limits memory resources per EB to ensure timely validation                                                                                                                                                                                       |\n\n<em>Table 3: Protocol Parameters</em>\n\n</div>\n\n> [!NOTE]\n>\n> While per-transaction limits _could_ be increased based on the\n> [evidence](#resource-requirements), the choice was made to deliberately **only\n> introduce per-endorser-block limits** to avoid escalation of a threat:\n> throughput-lowering attacks on certification would violate liveness of high\n> plutus budget transactions.\n>\n> For example, a 26% stake attacker can trivially attack leios throughput with a\n> 75% certification threshold. If an application would rely on higher (than what\n> is available in praos) plutus demand transactions, those would not get\n> included at all during such an attack.\n>\n> Despite, an application can work around this by splitting intense plutus work\n> into multiple transactions and chaining them into, potentially, the same\n> endorser block.\n\n#### Timing parameters\n\nThere are three key parameters related to time, which are important for\n[protocol security](#protocol-security). All relevant quantities are depicted in\n[Figure 4](#figure-4).\n\n<a id=\"equivocation-detection\"></a>\n\n**Equivocation Detection ($3 L_\\text{hdr}$)**\n\n**Equivocation** is the malicious behavior where a block producer creates\nmultiple conflicting blocks for the same slot and distributes different versions\nto different parts of the network. This attack aims to split the honest vote,\npotentially preventing certification of any block or allowing certification of\nan adversarial block if honest nodes vote on different versions.\n\nThis period starts exactly when an RB announces an EB. During this time, the\nnetwork detects any attempts by adversaries to create multiple conflicting\nblocks for the same slot. The equivocation detection mechanism ensures that\nhonest nodes can reliably identify and reject equivocating behavior before\nparticipating in voting. The equivocation detection period is $3 L_\\text{hdr}$,\nderived from the header diffusion parameter $L_\\text{hdr}$.\n\n**Equivocation Attack Model**: An adversary controlling a block production slot\nmay attempt to create multiple conflicting EBs and distribute different versions\nto different parts of the network. This could potentially split the honest vote,\npreventing certification of any EB, or worse, allow certification of an\nadversarial EB if honest nodes vote on different versions.\n\n**Detection Mechanism**: The protocol defends against equivocation through a\nmulti-step detection process that must accommodate the worst-case propagation\nscenario:\n\n1. **$L_\\text{hdr}$**: Initial header propagation — the first (honest or\n   adversarial) RB header reaches all honest nodes\n2. **$L_\\text{hdr}$**: Conflicting header propagation — any equivocating header\n   from the same slot reaches honest nodes\n3. **$L_\\text{hdr}$**: Equivocation evidence propagation — proof of conflicting\n   headers propagates network-wide, allowing all honest nodes to detect the\n   equivocation\n\nTherefore, the equivocation detection period is $3 L_\\text{hdr}$ to ensure\nreliable detection before voting begins. This constraint is derived from the\nnetwork model where headers must propagate within $L_\\text{hdr}$ to maintain\nPraos security assumptions.\n\n**Security Guarantee**: By waiting $3 L_\\text{hdr}$ slots before voting begins,\nthe protocol ensures that if any equivocation occurred soon enough to matter,\nall honest nodes will have detected it and will refuse to vote for any EB from\nan RB slot where equivocation was detected. This prevents adversaries from\nexploiting network partitions to gain unfair advantages in the voting process,\nas honest nodes will only vote for EBs where no equivocation was detected during\nthe detection period.\n\nNote that EB diffusion (but not voting) continues to happen during this phase.\n\n> [!NOTE]\n>\n> **Comparison with Research Paper**: The [Leios research paper][leios-paper]\n> describes a more complex protocol variant that requires $5\\Delta_\\text{hdr}$\n> for equivocation detection due to additional coordination mechanisms between\n> Input Blocks (a third block type in the research paper, eliminated in this\n> specification) and Endorser Blocks. This specification's simplified approach,\n> where EBs are directly announced by RBs, reduces the equivocation detection\n> requirement to $3\\Delta_\\text{hdr}$ while maintaining the same security\n> guarantees against equivocation attacks.\n\n<a id=\"voting-period\"></a>\n\n**Voting Period ($L_\\text{vote}$)**\n\nThe voting period must accommodate EB diffusion (transmission and processing):\n\n$$3 \\times L_\\text{hdr} + L_\\text{vote} > \\Delta_\\text{EB}^{\\text{O}}$$\n\nwhere $\\Delta_\\text{EB}^{\\text{O}}$ (optimistic EB diffusion time including\ntransmission and processing) is defined in the\n[network characteristics](#network-characteristics) section.\n\nThis ensures all honest committee members can participate by having sufficient\ntime to:\n\n1. Receive the EB from the network\n2. Fully validate it (verify signatures, execute scripts, update state)\n\n<a id=\"diffusion-period\"></a>\n\n**Diffusion Period ($L_\\text{diff}$)**\n\nThe diffusion period ensures network-wide EB availability through a combination\nof factors: the high quorum threshold ensures certified EBs are initially known\nto >25% of honest nodes, and the network assumption that data with such\nwidespread initial knowledge propagates fully within this period. The diffusion\nperiod must satisfy:\n\n$$L_\\text{diff} \\geq \\Delta_\\text{EB}^{\\text{W}} + \\Delta_\\text{reapply} - \\Delta_\\text{RB} - 3 \\times L_\\text{hdr} - L_\\text{vote}$$\n\nThis ensures certified EBs reach all honest parties before any `RB'` that\nincludes their certificate needs processing.\n\n#### Size parameters\n\nTwo separate parameters control EB sizes:\n\n- $S_\\text{EB}$ limits the size of the EB data structure itself, preventing\n  issues when many small transactions create large numbers of transaction\n  references (32 bytes each)\n- $S_\\text{EB-tx}$ limits the total size of transactions that can be referenced,\n  controlling the actual transaction payload\n\nNote that $S_\\text{EB-tx}$ does not change the maximum size of individual\ntransactions. The existing `maxTxSize` parameter remains unchanged and continues\nto limit individual transaction sizes. The purpose of $S_\\text{EB-tx}$ is to\nlimit the total computational work required for validation and ledger state\nupdates when processing an EB, since the EB size itself does not account for the\nfull size of all referenced transaction data that must be validated.\n\nFor example, an EB referencing 10,000 transactions of 100 bytes each would have\n$S_\\text{EB-tx} = 1$ MB but the EB itself would be at least 320 KB for the\ntransaction hashes alone.\n\n### Protocol Security\n\nLeios security reduces to Praos security. The key insight is ensuring that any\nRB containing an EB certificate is processed within the same $\\Delta_\\text{RB}$\ntime bound as standard Praos blocks.\n\n<a id=\"eb-reapplication-constraint\"></a>\n\n**1. EB Reapplication Constraint**\n\nReapplying a certified EB cannot cost more than standard transaction processing.\n\n$$\\Delta_\\text{reapply} < \\Delta_\\text{applyTxs}$$\n\n<a id=\"certified-eb-transmission-constraint\"></a>\n\n**2. Certified EB Transmission Constraint**\n\nAny certified EB referenced by an RB must be transmitted (but not necessarily be\nprocessed) before that RB needs to be processed.\n\n$$\\Delta_\\text{EB}^{\\text{W}} < 3 \\times L_\\text{hdr} + L_\\text{vote} + L_\\text{diff} + (\\Delta_\\text{RB} - \\Delta_\\text{applyTxs})$$\n\nThe security argument can now be described. For simplicity, the analysis focuses\non the case where a single RB (referencing an EB) is diffused, and nodes have\nalready computed the ledger state that this RB extends.\n\nThe argument proceeds as follows: (i) The certified EB that the RB references\nwill be received within $\\Delta_\\text{RB} - \\Delta_\\text{applyTxs}$ from the\ninitial diffusion time of the RB. This follows directly from\n[Constraint 2](#certified-eb-transmission-constraint) and the fact that the RB\nwas generated at least $3 \\times L_\\text{hdr} + L_\\text{vote} + L_\\text{diff}$\nslots after the EB was generated. (ii) The RB will be processed within\n$\\Delta_\\text{RB}$ slots, due to the fact that it is received within\n$\\Delta_\\text{RB} - \\Delta_\\text{applyTxs}$ from its initial diffusion time, and\nprocessing in the worst-case takes\n$\\Delta_\\text{reapply} (< \\Delta_\\text{applyTxs})$ slots according to\n[Constraint 1](#eb-reapplication-constraint).\n\nGiven that nodes are caught up when they are about to produce or process an RB,\nPraos safety and liveness is thus preserved.\n\n### Protocol Artifacts\n\nThe protocol extends Praos blocks, introduces endorser blocks, Leios votes and\ncertificates. While already introduced briefly, this section specifies these\nartifacts in more detail.\n\n#### Ranking Blocks (RBs)\n\nRBs are Praos blocks extended to support Leios by optionally announcing EBs in\ntheir headers and embedding EB certificates in their bodies.\n\n1. **Header additions**:\n   - `announced_eb` (optional): Hash of the EB created by this block producer\n   - `announced_eb_size` (optional): Size in bytes of the announced EB (4 bytes)\n   - `certified_eb` (optional): Single bit indicating whether this RB certifies\n     the EB announced by the previous RB (the EB hash is already available via\n     the previous header's `announced_eb` field)\n\n2. **Body additions**:\n   - `eb_certificate` (optional): aggregated certificate proving EB validity\n   - Transactions (when no certificate is included)\n\nA [CDDL for ranking blocks](#ranking-block-cddl) is available in Appendix B.\n\n<a id=\"rb-inclusion-rules\" href=\"#rb-inclusion-rules\"></a>**Inclusion Rules**:\n\n- When an RB header sets `certified_eb` to true, the corresponding body must\n  include a matching `eb_certificate`\n- The content rules for RBs are detailed as part of\n  [Step 5: Chain Inclusion](#step-5-chain-inclusion)\n- The `certified_eb` bit enables syncing nodes to predict the total size of\n  valid responses to their requests for batches of EBs certified on the\n  historical chain.\n- If the `announced_eb_size` field of an RB header is incorrect, then neither\n  the RB header nor the RB are invalid. But no honest node should vote for the\n  EB.\n\n#### Endorser Blocks (EBs)\n\nEBs are produced by the same stake pool that created the corresponding\nannouncing RB and reference additional transactions to increase throughput\nbeyond what is permitted to be included directly in the RB.\n\n<a id=\"eb-structure\" href=\"#eb-structure\"></a>**EB Structure**: EBs have a\nsimple structure:\n\n- `transaction_references`: Ordered map from transaction hash to transaction\n  size, preserving insertion order while preventing duplicate entries and\n  ensuring deterministic serialization\n\nA [CDDL for endorser blocks](#endorser-block-cddl) is available in Appendix B.\n\nThe hash referenced in RB headers (`announced_eb` field) is computed from the\ncomplete EB structure and serves as the unique identifier for the EB.\n\n#### Votes and Certificates\n\nLeios employs a voting and certificate scheme where committee members cast votes\nthat reference specific EBs, which are then aggregated into compact certificates\nfor inclusion in RBs. This specification uses BLS signatures as the\nimplementation example, though the protocol is designed to accommodate any\nefficient aggregate signature scheme that Cardano may adopt.\n\nThe implementation meets the <a href=\"#appendix-a-requirements\">requirements for\nvotes and certificates</a> specified in Appendix A. Alternative schemes\nsatisfying these requirements could be substituted, enabling unified voting\ninfrastructure across Ouroboros Leios, Ouroboros Peras, and other protocols.\n\nTo participate in the Leios protocol as voting member/ block producing node,\nstake pool operators must register one additional cryptographic key for the\nvoting scheme alongside their existing VRF and KES keys. In the BLS\nimplementation described here, this would be a BLS key over the BLS12-381\nelliptic curve.\n\n<a id=\"committee-structure\" href=\"#committee-structure\"></a>**Committee\nStructure**: Two types of voters validate EBs, balancing security,\ndecentralization, and efficiency:\n\n- **Persistent Voters**: Selected once per epoch using [Fait Accompli\n  sortition][fait-accompli-sortition], vote in every election, identified by\n  compact identifiers\n- **Non-persistent Voters**: Selected per EB via local sortition with\n  Poisson-distributed stake-weighted probability\n\nThis dual approach prevents linear certificate size growth by leveraging\nnon-uniform stake distribution, enabling faster certificate diffusion while\nmaintaining broad participation. With efficient aggregate signature schemes like\nBLS, certificate sizes remain compact (under 10 kB) even with large committees,\nas shown in the [BLS certificates specification][bls-spec].\n\n<a id=\"vote-structure\" href=\"#vote-structure\"></a>**Vote Structure**: All votes\ninclude the `endorser_block_hash` field that uniquely identifies the target EB:\n\n- **Persistent votes**:\n  - `election_id`: Identifier for the voting round (derived from the slot number\n    of the RB that announced the target EB)\n  - `persistent_voter_id`: Epoch-specific pool identifier\n  - `endorser_block_hash`: Hash of the RB header that announced the target EB\n  - `vote_signature`: Cryptographic signature (BLS in this implementation)\n- **Non-persistent votes**:\n  - `election_id`: Identifier for the voting round (derived from the slot number\n    of the RB that announced the target EB)\n  - `pool_id`: Pool identifier\n  - `eligibility_signature`: Cryptographic proof of sortition eligibility (BLS\n    in this implementation)\n  - `endorser_block_hash`: Hash of the RB header that announced the target EB\n  - `vote_signature`: Cryptographic signature (BLS in this implementation)\n\nThe `endorser_block_hash` identifies the header that announces the EB instead of\nidentifying the EB's hash directly. This ensures the voters validated the EB\nagainst the same ledger state that it extends when certified on chain; recall\nthat multiple RB headers could announce the same EB.\n\nA [CDDL for votes and certificates](#votes-certificates-cddl) is available in\nAppendix B.\n\n<a id=\"certificate-validation\" href=\"#certificate-validation\"></a>**Certificate\nValidation**: When an RB includes an EB certificate, nodes must validate the\nfollowing before accepting the block:\n\n1. **CDDL Format Compliance**: Certificate structure matches the specification\n   format defined in the <a href=\"#votes-certificates-cddl\">Votes and\n   Certificates CDDL specification</a> in Appendix B\n2. **Cryptographic Signatures**: The cryptographic signature is valid (BLS\n   signatures in this implementation)\n\n3. **Voter Eligibility**:\n   - Persistent voters must have been selected as such by the [Fait Accompli\n     scheme][fait-accompli-sortition] for the current epoch\n   - Non-persistent voters have provided valid sortition proofs based on the\n     `election_id`\n\n   **Vote Eligibility Determination**: For non-persistent voters, sortition\n   eligibility is determined using the `election_id` derived from the slot\n   number of the RB that announced the target EB. This ensures that vote\n   eligibility is verifiable and deterministic — nodes can independently agree\n   on which stake pools are eligible to vote for a specific EB based solely on\n   the EB's announcing RB slot, preventing multiple voting opportunities across\n   different slots for the same EB. This requirement stems from the BLS\n   sortition mechanism which uses the election identifier as input to the VRF\n   calculation for non-persistent voter selection.\n\n4. **Stake Verification**: Total voting stake meets the required quorum\n   threshold\n5. **EB Consistency**: Certificate references the correct EB hash announced in\n   the preceding RB\n\nDetailed specifications, performance, and benchmarks are available in the [BLS\ncertificates specification][bls-spec].\n\n> [!NOTE]\n>\n> **Vote Bundling**\n>\n> The linked BLS specification mentions vote bundling as an optimization.\n> However, this only applies when EB production is decoupled from RBs, which is\n> not the case in this specification where each EB is announced by an RB.\n\n### Node Behavior\n\nThe Leios protocol introduces new node responsibilities and message flows beyond\nthose in Praos, reflecting the additional steps of EB creation and announcement,\ncommittee voting, and certificate aggregation. The following sections detail the\nspecific behaviors that nodes must implement.\n\n<div align=\"center\">\n<a name=\"figure-5\" id=\"figure-5\"></a>\n<p>\n  <img src=\"images/node-behavior-sequence.svg\" alt=\"Node Behavior Sequence\">\n</p>\n\n<em>Figure 5: Up- and downstream interactions of a node (simplified)</em>\n\n</div>\n\nThe diagram above illustrates the Leios protocol in a simplified sequential\norder. In practice, these operations occur concurrently and the actual execution\norder depends on network conditions, timing, and node state. While many steps\nintroduce new behaviors, several core Praos mechanisms remain unchanged.\n\n#### Transaction Diffusion\n\n<a id=\"transaction-propagation\" href=\"#transaction-propagation\"></a>**Transaction\nPropagation**: Uses the TxSubmission mini-protocol exactly as implemented in\nPraos. Transactions flow from downstream to upstream nodes through diffusion,\nwhere they are validated against the current ledger state before being added to\nlocal mempools. The protocol maintains the same FIFO ordering and\nduplicate-detection mechanisms.\n\n<a id=\"mempool-design\" href=\"#mempool-design\"></a>**Mempool Design**: The\nmempool follows the same design as current Praos deployment with increased\ncapacity to support both RB and EB production. A node's mempool capacity must\naccommodate expanded transaction volume:\n\n<div align=\"center\">\n\n$\\text{Mempool} \\geq 2 \\times (S_\\text{RB} + S_\\text{EB-tx})$\n\n</div>\n\nNodes maintain a set $S$ of transactions seen in EBs to enable validation work\nreuse, with detailed processing rules specified in the\n<a href=\"#eb-transaction-handling\">EB transaction handling</a> section.\n\n#### RB Block Production and Diffusion\n\nWhen a stake pool wins slot leadership (step 1), they create a Ranking Block\n(RB) and **optionally** an Endorser Block (EB) based on the\n[chain inclusion rules](#step-5-chain-inclusion). The RB is a standard Praos\nblock with extended header fields to reference one EB and announce another EB\nwhen such is created. The optional EB is a larger block containing references to\nadditional transactions. The RB chain continues to be distributed exactly as in\nPraos, while Leios introduces a separate mechanism to distribute the same\nheaders for rapid EB discovery and\n<a href=\"#equivocation-detection\">equivocation detection</a>.\n\n<a id=\"rb-header-diffusion\" href=\"#rb-header-diffusion\"></a>**RB Header\nDiffusion**: RB headers diffuse independently of standard ChainSync (steps 2a\nand 2b). This separate mechanism enables rapid EB discovery within the strict\ntiming bound $\\Delta_\\text{hdr}$. EBs are diffused freshest-first to facilitate\ntimely EB delivery, with nodes propagating at most two headers per (slot,\nissuer) pair to detect <a href=\"#equivocation-detection\">equivocation</a> -\nwhere an attacker creates multiple EBs for the same block generation opportunity\n— while limiting network overhead. The header contains the EB hash when the\nblock producer created an EB, allowing peers to discover the corresponding EB.\n\n<a id=\"rb-body-diffusion\" href=\"#rb-body-diffusion\"></a>**RB Body Diffusion**:\nAfter receiving headers, nodes fetch RB bodies via standard BlockFetch protocol\n(step 3). This employs ChainSync and BlockFetch protocols without modification\nfor fetching complete ranking blocks after headers are received. The pipelining\nand batching optimizations for block body transfer remain unchanged from Praos.\n\n<a id=\"rb-validation-adoption\" href=\"#rb-validation-adoption\"></a>**Validation\nand Adoption**: Nodes validate the RB and any included EB certificate before\nadopting the block (step 4). This includes cryptographic verification of\ncertificates and ensuring they correspond to properly announced EBs. The\ncomplete validation procedure is detailed in\n[Step 5: Chain Inclusion](#step-5-chain-inclusion). The node serves RBs to\ndownstream peers using standard Praos block distribution mechanisms (step 5),\nwhich are permitted to include diffusion pipelining with delayed validation.\n\n#### EB Diffusion\n\nWhenever an EB is announced through an RB header, nodes must fetch the EB\ncontent promptly (step 6), such that they receive it within\n$3 \\times L_\\text{hdr} + L_\\text{vote}$ and consequently enables them to vote.\nEBs are fetched freshest-first to ensure timely delivery within the voting\nwindow. Only the EB body corresponding to the first EB announcement/RB header\nreceived for a given RB creation opportunity shall be downloaded. The EB\ncontains references to transactions.\n\n<a id=\"eb-chain-selection\" href=\"#eb-chain-selection\"></a>**EB Propagation for\nChain Selection**: To support efficient chain selection, nodes must receive\n**all EBs from competing forks**, not only those in their current preferred\nchain. This ensures that when a node switches to a different fork due to the\nlongest-chain rule, it can immediately validate the new chain without additional\nEB propagation delays. However, nodes do not need to fetch EBs from forks that\nhave diverged from the locally preferred chain older than the Praos security\nparameter, as such forks cannot affect chain selection decisions. EBs are\nforwarded before complete validity checks are performed.\n\n<a id=\"transaction-retrieval\" href=\"#transaction-retrieval\"></a>**Transaction\nRetrieval**: Nodes check their local mempool for the transactions referenced by\nan EB and fetch any missing ones from peers (steps 6a and 7a). Once a node has\nsuccessfully secured all of the referenced transactions, it can serve the EB to\nits downstream peers (step 7). This guarantees that when a peer receives an EB\nfrom it, all the referenced transaction data is already available at the source.\n\n<a id=\"eb-transaction-validation\" href=\"#eb-transaction-validation\"></a>**Transaction\nValidation**: As endorsed transactions become available, nodes validate them in\nthe endorsed sequence against the appropriate ledger state (step 8), ensuring\nthe transactions form a valid extension of the announcing RB and meet size\nconstraints.\n\n<a id=\"eb-transaction-handling\" href=\"#eb-transaction-handling\"></a> To optimize\nvalidation work, nodes maintain a set $S$ of transactions seen in recently\nreceived EBs. Each entry in $S$ contains:\n\n1. The transaction itself\n2. A validation flag indicating whether the transaction has been verified\n   (signatures, scripts, etc.)\n\nTransactions are only validated when they are seen the first time, either in the\nmempool or as part of an EB, and validity information is retained to avoid\nredundant fetching and validation.\n\n#### Voting & Certification\n\n<a id=\"VotingEB\" href=\"#VotingEB\"></a>**Voting Process**: Committee members\n[selected through a lottery process](#votes-and-certificates) vote on EBs as\nsoon as [vote requirements](#step-3-committee-validation) are met according to\nprotocol (step 9). An honest node casts only one vote for the EB extending its\ncurrent longest chain.\n\n<a id=\"VoteDiffusion\" href=\"#VoteDiffusion\"></a>**Vote Propagation**: Votes\npropagate through the network during the vote diffusion period $L_\\text{diff}$\nslots (steps 10 and 10a). While nodes forward votes on EBs across all candidate\nchains, they only forward at most one vote per committee member per slot.\n\nNodes maintain and relay votes for a bounded duration to limit resource usage.\nSince freshest-first delivery ensures that newer votes are prioritized over\nolder ones, the exact bound is not critical for protocol correctness. A\nconservative bound of a few minutes is sufficient to handle network delays while\nallowing nodes to discard votes that are no longer relevant.\n\n<a id=\"CertificateAggregation\" href=\"#CertificateAggregation\"></a>**Certificate\nConstruction**: All nodes receive votes from upstream peers, maintaining a\nrunning tally for each EB to track progress toward the quorum threshold (step\n11). However, only RB producers create certificates when they are about to\nproduce a new ranking block. Block producing nodes know their own leadership\nschedule, so they know when they are eligible to construct a certificate for an\nupcoming RB they will produce. When enough votes are collected during the vote\ndiffusion period, the RB producer aggregates them into a compact certificate.\nThis certificate is embedded directly in the RB body and serves as cryptographic\nproof that the EB has received sufficient committee approval.\n\n#### Next Block Production\n\n<a id=\"certificate-inclusion\" href=\"#certificate-inclusion\"></a>**Certificate\nInclusion**: Block producers creating new RBs include certificates for EBs where\nat least $3 \\times L_\\text{hdr} + L_\\text{vote} + L_\\text{diff}$ slots have\nelapsed since the slot of the RB that announced the EB (step 12). This timing\nconstraint ensures the certified EB has had sufficient time to diffuse\nthroughout the network. See the protocol flow section for detailed\n[block production and inclusion rules](#step-5-chain-inclusion).\n\n#### Ledger Management\n\n<a id=\"ledger-formation\" href=\"#ledger-formation\"></a>**Ledger Formation**: The\nledger follows the same design as Praos with the addition of certificate\nhandling and EB attachment references. The ledger state is updated according to\nthe same validation rules used in Praos, with phase-1 and phase-2 validation\napplying equally to both RB and EB transactions.\n\n<a id=\"ledger-state-transitions\" href=\"#ledger-state-transitions\"></a>**State\nTransitions**: EBs add transactions to the ledger only when properly certified\nand included via RB references. RBs can include both certificates and their own\ntransactions. The ledger state for validating RB transactions is constructed\nbased on either the predecessor RB (when no EB certificate is included) or the\ncertified EB (when a valid certificate is present). Note that EB transactions\nare validated against the ledger state from the RB that announced the EB (i.e.,\nthe predecessor RB of the certifying RB), ensuring the predecessor RB's\ntransactions are relevant in both validation scenarios.\n\n<a id=\"chain-selection\" href=\"#chain-selection\"></a>**Chain Selection**: Chain\nselection follows the densest chain rule as in Ouroboros Genesis. EBs are\ntreated as auxiliary data that do not affect chain validity or selection\ndecisions. Fork choice depends solely on RB chain density, with EB certificates\nserving only as inclusion proofs for transaction content. The\n[EB propagation for chain selection](#eb-chain-selection) requirement ensures\nthat nodes already possess all necessary EBs from alternative forks, eliminating\nadditional propagation delays during fork switches.\n\n#### Epoch Boundary\n\n<a id=\"persistent-voter-computation\" href=\"#persistent-voter-computation\"></a>**Persistent\nVoter Computation**: Nodes must compute the set of persistent voters for each\nepoch using the [Fait Accompli scheme][fait-accompli-sortition]. This\ncomputation uses the stake distribution that becomes available at the epoch\nboundary and represents a minimal computational overhead based on current\n[BLS certificates benchmarks](https://github.com/input-output-hk/ouroboros-leios/blob/d5f1a9bc940e69f406c3e25c0d7d9aa58cf701f8/crypto-benchmarks.rs/Specification.md#benchmarks-in-rust).\nNodes complete this computation well before voting begins in the new epoch to\nensure seamless participation.\n\n#### Operational certificate issue numbers\n\nEach node must relay at most two EB announcements that equivocate the same Praos\nelection. This would be trivial for senders and receivers to enforce, if it were\nnot for\n[operational certificates](https://docs.cardano.org/stake-pool-operators/creating-keys-and-certificates#creating-an-operational-certificate-and-registering-a-stake-pool),\nwhich complicate the notion of which sets of headers qualify as equivocating.\n\nWith the current Praos system, an SPO is free to issue an arbitrary operational\ncertificate issue number (OCIN) every time they issue an RB header, but honest\nSPOs will only increment their OCIN when they need to. Whether the OCIN carried\nby some header is valid depends on the chain it extends, because the Praos\nprotocol rules along a single chain only allow an SPO's OCIN to be incremented\nat most once per header issued by that SPO.\n\nThe Leios protocol, in contrast, is expected to diffuse contemporary EBs\nregardless of which chain they are on, and so cannot assume that it has seen the\npredecessor header of every EB announcement. It also cannot simply require that\nit has seen all headers, because that would complicate the timing restrictions\nand require tracking a potentially unbounded number of forks. Thus, neither of\nthe following simple extremes would be acceptable for Leios.\n\n- If Leios ignores OCINs, then a leaked hot key would let the adversary issue\n  impersonating EBs whenever the stake pool is elected until that KES period\n  expires, which can be up to 90 days later on Cardano mainnet. That's\n  unacceptably long. (Significantly shortening the KES period is not an option,\n  because that would excessively burden SPOs by forcing them to utilize their\n  cold key more often.)\n- If Leios instead over-interprets distinct OCINs as separate elections, then\n  any adversary can diffuse any number of EB announcements per actual election,\n  with arbitrary OCINs. Those announcements would be an unacceptable unbounded\n  burst of work for honest nodes to relay throughout the entire network, even if\n  they still only relayed at most one EB body per actual election.\n\nThere is no simple compromise between those extrema. In particular, if there's\nany way for the adversary to have revealed incremented OCINs to some nodes but\ndefinitely not all, then the worst-case diffusion behavior of adversarial EBs\nmight be worse than that of honest EBs, which would complicate the acceptable\nlower bound on $L_\\text{diff}$, for example. On the other hand, if every OCIN\nincrement — even those disallowed by Praos — is always eventually relayed to all\nnodes, then an adversary can create unbounded work by constantly incrementing\ntheir OCINs. In the absence of the context provided by forks, there's no bound\non the OCINs the Leios protocol would relay.\n\nThus, the diffusion of EB announcements (regardless of who issued them) is only\ntractable and robust if it is restricted to a bounded set of OCINs that all\nhonest nodes almost certainly agree on. For this reason, the Leios node should\nignore an EB announcement that is less than the OCIN on its settled ledger state\nor more than one greater than that OCIN. After not ignoring two announcements\nwith the same election, the Leios node should ignore (including not relaying)\nany subsequent announcements for that election.\n\nWith this rule, a node will crucially disconnect if and only if a peer sends\nmore than two announcements with the same election. It will also ignore headers\nfrom leaked hot keys once the SPO increments their OCIN, but unfortunately — and\nin contrast to Praos — not immediately. The Leios node will only ignore\nunincremented OCINs after all honest nodes necessarily agree that the SPO\nincremented their OCIN. In the strictest case, that could require the increment\nto be at least 36 hr old on Cardano mainnet before Leios ignores the\nunincremented OCIN. It seems plausible that the agreement could sometimes be\nassumed sooner (e.g., after a certificate includes the incremented OCIN), but\nfurther details are not a blocker for this CIP; 36 hr is already an acceptable\nimprovement over 90 days, and SPOs already must not frequently leak their hot\nkeys.\n\n### Network\n\nUnlike Ouroboros Praos, where the RB chain contains all necessary data, Leios\nrequires additional message types to:\n\n- **Reconstruct ledger state**: EBs containing certified transactions\n- **Participate in consensus**: Vote on EBs and construct certificates\n- **Detect equivocation**: RB headers from competing forks\n\n#### Praos Mini-Protocols\n\nAs described in [Node Behavior](#node-behavior), existing Praos mini-protocols\ncontinue to operate with only minor modifications to support Leios. ChainSync\nexchanges RB headers that now include optional fields for EB announcements\n(`announced_eb`) and certifications (`certified_eb`). BlockFetch retrieves RB\nbodies that may contain BLS aggregate certificates (`eb_certificate`) alongside\nstandard transactions. TxSubmission remains unchanged except for expanded\nmempool capacity to support both RB and EB transaction pools.\n\n#### Leios Mini-Protocols\n\nLeios must introduce new mini-protocols to handle the additional message types\nrequired for EB distribution, voting, and certificate construction. Despite the\nprecedent for some CIPs to leave those concrete details for implementors to\ndecide, the difficulty of satisfying all of the requirements on a Leios\nimplementation motivates including a concrete proposal in this CIP.\n\nIn addition, this section summarizes the requirements for the proposed\nmini-protocols and why they're satisfied. This demonstrates the collective\nrequirements are satisfiable — that some implementation is feasible and not\nprohibitively complicated.\n\n**Requirements**\n\nAny Leios implementation must satisfy the following requirements. Alternative\nmessage exchange designs that meet these requirements may be considered as the\nprotocol evolves, with updates to this specification reflecting proven\nimprovements.\n\n- **Leios Correctness**: The nodes must exchange the Leios data while\n  prioritizing younger over older as implied by Leios' freshest-first delivery\n  assumption. Because Leios is about improved resource utilization, wasting\n  resources via unnecessary overhead/latency/etc can be considered a correctness\n  violation, even more so than in Praos.\n- **Praos Independence**. The Cardano network must grow RB chains — both\n  adversarial and honest — of the same shape (i.e., forks and their lengths)\n  regardless of whether it is executing the Leios overlay. In other words, the\n  shape of all RB forks that exist at some instant would ideally not provide any\n  indication whether the Leios overlay is being executed. Moreover, the honest\n  majority must still have the same control over which transactions are included\n  by the RBs on the best chain.\n- **Existing Resources**: The Leios overlay enables Cardano to increase\n  utilization of existing resources. The Leios overlay will use more resources\n  than Praos does, but it simultaneously will not inherently require today's\n  Cardano SPOs or users to provision additional resources, beyond some minor\n  exceptions. The necessary resources already exist; Praos just cannot utilize\n  them all.\n- **Tolerable Implementation Complexity**: The above requirements must admit an\n  implementation without incurring prohibitive costs for development and future\n  maintenance. For example, at least the centralized logic to choose when to\n  send each request in this mini-protocol will be very similar to TxSubmission,\n  Peras vote requests, Mithril's Decentralized Message Queue, and likely\n  additional protocols in the future. There is opportunity for significant code\n  reuse even if the mini-protocols themselves are separate.\n\n**Discussion**\n\n**Existing Resources**: Because Praos cannot already fully utilize the existing\nCardano infrastructure, this CIP can increase utilization without disrupting\nPraos; the currently unutilized resources are sufficient for Leios. More\naggressive Leios deployments/extensions in the future will have to navigate that\ntrade-off, but simulations indicate that it is not already required by this CIP,\nwith two exceptions. First, nodes will require additional disk capacity as a\ndirect result of the increased throughput. Second, parties with significant\nstake will need to provision more resources across their relays since each of\nthe hundreds of downstream peers becomes more demanding on average.\n\n**Praos Independence**. To prevent Leios from accidentally depriving Praos of\nresources, the node implementation must prioritize Praos over Leios. For\nexample, when a node simultaneously issues an RB and the EB it announces, the\ndiffusion of the EB should not delay the diffusion of the RB; that RB is\nstrictly more urgent than that EB.\n\n_Remark_. In contrast, the EB certified by an RB that also includes some\ntransactions is exactly as urgent as that RB, because the RB cannot be selected\nwithout the EB. The $L_\\text{diff}$ parameter prevents such urgency inversion\nfrom occurring enough to matter, as explained in the\n[Security Argument](#protocol-security) section, assuming nodes automatically\neventually recover when it does happen.\n\nIn reality, the prioritization of Praos over Leios does not need to be perfectly\nstrict (and in fact could never be on hardware and software infrastructure that\nis mostly commodity and partly public). The fundamental requirement is that the\nnetwork assumptions that were originally used to parameterize Praos must still\nbe valid — up to some tolerated error probability — when the same nodes are\nsimultaneously executing the Leios overlay. Concretely, the worst case delay\nbetween an honest block producer issuing a uniquely best RB and the last honest\nblock producer selecting that RB (i.e., Praos' $\\Delta$) must not be protracted\nby Leios so much that the existing Praos parameter values (e.g., the stability\nwindow of 36 hr) are no longer sufficient.\n\n**Leios Correctness**: The implementation of freshest-first delivery also does\nnot need to be perfect. The prioritization of young over old merely needs to be\nrobust enough to justify the chosen values of $L_\\text{vote}$ and\n$L_\\text{diff}$ even during a burst of withheld-but-valid messages.\n\n**Concrete Proposal and its Feasibility**\n\nThe following two new mini-protocols are proposed for the Leios implementation.\nThis is not the only feasible solution, but this CIP should be amended as\nimplementors refine these mini-protocols.\n\nIf the general structure and semantics of mini-protocols is not already\nfamiliar, see the Chapter 2 \"Multiplexing mini-protocols\" and Chapter 3\n\"Mini-Protocols\" of the `ouroboros-network`'s\n[Ouroboros Network Specification PDF](https://ouroboros-network.cardano.intersectmbo.org/pdfs/network-spec/network-spec.pdf).\nA brief summary is that a mini-protocol is a state machine that two nodes\ncooperatively navigate; each node only sends a message when it has _agency_, and\nat most one node has agency in any state. The agencies are indicated in this\ndocument as green or blue. The green agency is the client, the downstream peer\nthat initiated the connection, and blue is the server (black means no agency).\nIf some of a node's upstream peers are also downstream peers, then there are two\ninstances of the mini-protocol running independently for each such peer, with\nthe node as the client in one and the server in the other. Recall that Cardano's\ntopology results in each relay having many more downstream peers than upstream\npeers. Syncing peers will be discussed below.\n\n<div align=\"center\">\n<a name=\"figure-6\" id=\"figure-6\"></a>\n\n```mermaid\n---\ntitle: LeiosNotify\n---\ngraph LR\n   style StIdle fill:PaleGreen,stroke:DarkGreen;\n   style StBusy fill:PowderBlue,stroke:DarkBlue;\n   style StDone fill:SeaShell,stroke:DimGray;\n\n   StIdle -->|MsgLeiosNotificationRequestNext| StBusy\n   StBusy -->|MsgLeiosBlockAnnouncement| StIdle\n   StBusy -->|MsgLeiosBlockOffer| StIdle\n   StBusy -->|MsgLeiosBlockTxsOffer| StIdle\n   StBusy -->|MsgLeiosVotesOffer| StIdle\n\n   StIdle -->|MsgDone| StDone\n```\n\n<em>Figure 6: LeiosNotify mini-protocol state machine</em>\n\n</div>\n\n<div align=\"center\">\n<a name=\"figure-7\" id=\"figure-7\"></a>\n\n```mermaid\n---\ntitle: LeiosFetch\n---\ngraph LR\n   style StIdle fill:PaleGreen,stroke:DarkGreen;\n   style StBlock fill:PowderBlue,stroke:DarkBlue;\n   style StBlockTxs fill:PowderBlue,stroke:DarkBlue;\n   style StDone fill:SeaShell,stroke:DimGray;\n   style StVotes fill:PowderBlue,stroke:DarkBlue;\n   style StBlockRange fill:PowderBlue,stroke:DarkBlue;\n\n   StIdle -->|MsgLeiosBlockRequest| StBlock -->|MsgLeiosBlock| StIdle\n   StIdle -->|MsgLeiosBlockTxsRequest| StBlockTxs -->|MsgLeiosBlockTxs| StIdle\n   StIdle -->|MsgLeiosVotesRequest| StVotes -->|MsgLeiosVotes| StIdle\n   StIdle -->|MsgLeiosBlockRangeRequest| StBlockRange -->|MsgLeiosNextBlockAndTxsInRange| StBlockRange -->|MsgLeiosLastBlockAndTxsInRange| StIdle\n\n   StIdle -->|MsgDone| StDone\n```\n\n<em>Figure 7: LeiosFetch mini-protocol state machine</em>\n\n</div>\n\nThe primary messages will carry information that is directly required by the\nLeios description above: headers, blocks, transactions referenced by blocks, and\nvotes for blocks. However, some lower-level information must also be carried by\nsecondary messages, e.g. indicating when the peer is first able to send the\nblock.\n\nThe required exchanges between two neighboring nodes is captured by the\nfollowing Information Exchange Requirements table (IER table). For the sake of\nminimizing this proposal, each row is a mini-protocol message, but that\ncorrespondence does not need to remain one-to-one as the mini-protocols evolve\nover time. Note that the table does not list the messages in the anticipated\nchronological order; they're grouped by request/response semantics. The\nmini-protocols permit the client to react to some messages before it has\nreceived all messages related to an EB. For example, the client can send\nMsgLeiosBlockRequest as soon as it receives MsgLeiosBlockOffer, even if it has\nnot yet received MsgLeiosBlockTxsOffer.\n\n<div align=\"center\">\n<a name=\"table-4\" id=\"table-4\"></a>\n\n| Sender  | Name                            | Arguments                                                    | Semantics                                                                                                                                                                                                                             |\n| ------- | ------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Client→ | MsgLeiosNotificationRequestNext | $\\emptyset$                                                  | Requests one Leios notifications, the announcement of an EB or delivery offers for blocks, transactions, and votes.                                                                                                                   |\n| ←Server | MsgLeiosBlockAnnouncement       | RB header that announces an EB                               | The server has seen this EB announcement.                                                                                                                                                                                             |\n| ←Server | MsgLeiosBlockOffer              | slot and Leios hash                                          | The server can immediately deliver this block.                                                                                                                                                                                        |\n| ←Server | MsgLeiosBlockTxsOffer           | slot and Leios hash                                          | The server can immediately deliver any transaction referenced by this block.                                                                                                                                                          |\n| ←Server | MsgLeiosVotesOffer              | list of slot and vote-issuer-id pairs                        | The server can immediately deliver votes with these identifiers.                                                                                                                                                                      |\n| Client→ | MsgLeiosBlockRequest            | slot and Leios hash                                          | The server must now deliver this block.                                                                                                                                                                                               |\n| ←Server | MsgLeiosBlock                   | EB block                                                     | The block from an earlier MsgLeiosBlockRequest.                                                                                                                                                                                       |\n| Client→ | MsgLeiosBlockTxsRequest         | slot, Leios hash, and map from 16-bit index to 64-bit bitmap | The server must now deliver these transactions. The given bitmap identifies which of 64 contiguous transactions are requested, and the offset of the transaction corresponding to the bitmap's first bit is 64 times the given index. |\n| ←Server | MsgLeiosBlockTxs                | list of transactions                                         | The transactions from an earlier MsgLeiosBlockTxsRequest.                                                                                                                                                                             |\n| Client→ | MsgLeiosVotesRequest            | list of slot and vote-issuer-id                              | The server must now deliver these votes.                                                                                                                                                                                              |\n| ←Server | MsgLeiosVoteDelivery            | list of votes                                                | The votes from an earlier MsgLeiosVotesRequest.                                                                                                                                                                                       |\n| Client→ | MsgLeiosBlockRangeRequest       | two slots and two RB header hashes                           | The server must now deliver the EBs certified by the given range of RBs, in order.                                                                                                                                                    |\n| ←Server | MsgLeiosNextBlockAndTxsInRange  | an EB and all of its transactions                            | The next certified block from an earlier MsgLeiosBlockRangeRequest.                                                                                                                                                                   |\n| ←Server | MsgLeiosLastBlockAndTxsInRange  | an EB and all of its transactions                            | The last certified block from an earlier MsgLeiosBlockRangeRequest.                                                                                                                                                                   |\n\n<em>Table 4: Leios Information Exchange Requirements table (IER table)</em>\n\n</div>\n\nThis mini-protocol pair satisfies the above requirements in the following ways.\n\n- These mini-protocols have less width than the LocalStateQuery mini-protocol\n  and less depth than the TxSubmission mini-protocol. Thus, its structure is not\n  prohibitively complicated, and e.g. per-state timeouts can be tuned\n  analogously to existing protocols.\n- ChainSync, BlockFetch, and TxSubmission are unchanged. Moreover, they can\n  progress independently of the Leios mini-protocols because they are separate\n  mini-protocols.\n- Depending on how severely the node must prioritize Praos over Leios, the\n  separation of their mini-protocols may simplify the prioritization mechanism.\n  However, urgency inversion means that at least MsgLeiosBlockRangeRequest,\n  MsgLeiosNextBlockAndTxsInRange, and MsgLeiosLastBlockAndTxsInRange may\n  occasionally need to have the same priority as Praos. If it would benefit the\n  prioritization implementation, those three messages could be isolated in a\n  third Leios mini-protocol that has equal priority as the Praos mini-protocols.\n- LeiosNotify and LeiosFetch can also progress independently, because they are\n  separate mini-protocols. A client can therefore receive notifications about\n  new Leios data and when it could be fetched from this peer even while a large\n  reply is arriving via LeiosFetch. This avoids unnecessary increases in the\n  latency of Leios messages.\n- The client can prioritize the youngest of outstanding offers from the peer\n  when deciding which LeiosFetch request to send next, as freshest-first\n  delivery requires.\n- Because the client only has agency in one state, it can pipeline its requests\n  for the sake of latency hiding.\n- The client can request multiple transactions at once, which avoids wasting\n  resources on overhead due to the potentially thousands of transactions\n  exchanged per EB. (Most EBs' transactions will usually have already arrived\n  via the Mempool, but the adversary can prevent that for their EBs.) The\n  bitmap-based addressing scheme allows for compact requests for even thousands\n  of transactions: a few hundred bytes of MsgLeiosBlockTxsRequest can request\n  every transaction in even the largest EB, while a MsgLeiosBlockTxsRequest for\n  a single transaction would only cost tens of bytes. Without a compact\n  addressing scheme, a node that requires every transaction for some EB would\n  essentially need to send a request that's the same size as the EB itself,\n  which is large enough to be considered an unnecessary risk of increased\n  latency.\n- The client can request multiple votes at once, which avoids wasting resources\n  on overhead due to the hundreds of votes exchanged per EB. Because the first\n  vote in a bundle could have arrived sooner than the last vote in a bundle if\n  it had not been bundled, maximal bundling risks unnecessary increases in\n  latency. Some heuristic will balance the overhead decrease and latency\n  increase, such as the client gradually stops bundling its vote requests as its\n  set of received votes approaches a quorum.\n- The server can do the same when bundling vote offers, but it should be more\n  conservative, in case the client is already closer to a quorum than the former\n  is.\n- MsgLeiosBlockRangeRequest lets syncing nodes avoid wasting resources on\n  overhead due to the (hopefully) high rate of EBs per RB. BlockFetch already\n  bundles its RB requests when syncing, and this message lets LeiosFetch do the\n  same. The starvation detection and avoidance mechanism used by Ouroboros\n  Genesis' Devoted BlockFetch variant can be easily copied for\n  MsgLeiosBlockRangeRequest if Ouroboros Genesis is enabled.\n- Recall that the `certified_eb` bit enables the client to correctly predict the\n  total payload size of the valid replies to a MsgLeiosBlockRangeRequest. This\n  enables the client to manage its receive buffers, balance load across peers,\n  etc.\n- A server should disconnect if the client requests an EB (or its transactions)\n  the server does not have. For young EBs, a client can avoid this by waiting\n  for MsgLeiosBlockOffer (or MsgLeiosBlockTxsOffer) before sending a request.\n  For old EBs, a ChainSync MsgRollForward for an RB that certifies its\n  predecessor's EB would also imply the server has selected that EB, and so must\n  be able to serve it. Whether additional restrictions would be useful is not\n  yet clear. For example, it seems natural to restrict MsgLeiosBlockRequest and\n  MsgLeiosBlockTxsRequest to young EBs (and perhaps also\n  MsgLeiosBlockRangeRequest to old EBs), but it's not already clear what the\n  benefit would be.\n- If MsgLeiosBlockRequest and MsgLeiosBlockTxsRequest were restricted to young\n  EBs, then MsgLeiosBlockRangeRequest would not only enable syncing nodes but\n  also the unfortunate node that suffers from a $\\Delta^\\text{W}_\\text{EB}$\n  violation. The protocol design requires that that event is rare or at least\n  confined to a small portion of honest stake at a time. But it will\n  occasionally happen to some honest nodes, and they must be able to recover\n  automatically and with minimal disruption.\n- Every Leios object is associated with the slot of an EB, and so has an\n  explicit age. This enables freshest-first delivery prioritization. In\n  addition, votes of a certain age should no longer diffuse; they are no longer\n  relevant once they are somewhat older than $L_\\text{vote}$. Similarly, EBs\n  above some age are no longer relevant unless they're on the historical chain.\n  Because equivocation detection limits the amount of Leios traffic per Praos\n  election and Praos elections have a stochastically low arrival rate, this\n  memory bound is low enough to admit existing Cardano infrastructure.\n\nThe mini-protocol pair does not already address the following challenges, but\nthe corresponding enrichments — if necessary — would not contradict the\nTolerable Implementation Complexity requirement.\n\n- Depending on how severely the node must prioritize younger Leios traffic over\n  older, the mini-protocols' states might need to be less granular. Because\n  distinct client requests transition to distinct blue states, the server is\n  unable to reply to the client's requests in a different order than the client\n  sent them. If a client pipelined several requests and then learned of a new\n  youngest EB and requested it, the server — if timing allows — could\n  conceptually reply to that last request before the others, for the sake of\n  freshest-first delivery. But it cannot do so if the mini-protocol's structure\n  prevents those replies, as the existing granular states do. The existing\n  support for pipelined requests within the Cardano mini-protocol infrastructure\n  was only concerned about latency hiding, and so does not explicitly support\n  server-side request reordering. It is already achievable with the existing\n  infrastructure, but only by splitting the mini-protocol's requests and\n  responses into different mini-protocols, which might be prohibitively\n  obfuscated.\n- With server-side reordering, LeiosFetch could also be free to interleave small\n  replies to vote requests with large replies to block/transaction requests.\n  Without it, however, the collocation of small replies and large replies in a\n  single mini-protocol with granular states incurs head-of-line blocking. That\n  risks occasionally increasing some key latencies, thereby threatening\n  freshest-first delivery or even motivating inflations of $L_\\text{vote}$\n  and/or $L_\\text{diff}$. One easy mitigation would run two instances of\n  LeiosFetch and reserve one for requests that are small and urgent (e.g., small\n  blocks, a few missing transactions, or perhaps any vote); the existing\n  infrastructure would naturally interleave those with the larger and/or less\n  urgent requests.\n\n### Incentives\n\nLeios does not require any changes to incentives in Cardano.\n\nThe current reward structure used on Cardano tracks the number of blocks created\nby each SPO compared to the expected number of blocks they should have created.\nIt does not directly track the number of transactions in a block and empty\nblocks count the same. The intent is to detect whether a party is offline or\nnot. Block producers are further incentivized to fill blocks with transactions,\nfor it increases fees flowing into the overall reward and thus their individual\nrewards.\n\nThis indirect incentive to fill blocks holds the same with Leios, where\nendorsing and voting would be equally incentivized by having more fee paying\ntransactions reach the ledger.\n\nThe current and unchanged specification of rewards is part of the\n[ledger specification](https://intersectmbo.github.io/formal-ledger-specifications/site/Ledger.Conway.Specification.Rewards.html)\nand more details on the\n[design of incentives can be found here](https://github.com/intersectmbo/cardano-ledger/releases/latest/download/shelley-delegation.pdf#section.5).\n\n#### Adaptive EB production\n\nIn time of low-traffic demand, the protocol will naturally incentivize usage of\nRBs over EBs due to the lower inclusion latency. Only transactions which would\nnot fit into an RB (in terms of size or Plutus budgets) would be processed\nthrough Leios via an EB. When traffic levels can be adequately served by RBs\nalone within both size and computational constraints, no EBs are announced,\nreducing operational costs to Praos levels. This mechanism ensures that cost\nstructure scales with actual throughput demand rather than imposing fixed\noverhead regardless of network utilization.\n\n#### Hardware upgrade\n\nThe increased computational and bandwidth requirements for Leios operation are\noffset by higher potential rewards from increased transaction throughput. As\ndemonstrated in the [operating costs analysis](#operating-costs), SPO\nprofitability improves significantly once sustained throughput exceeds 30-50\nTPS, providing clear economic incentives for infrastructure upgrades.\n\n### Clients\n\nChanges proposed for Ouroboros Leios will require changes to the node-to-client\n(N2C) mini-protocols used by client applications throughout the ecosystem.\nConcrete decisions will likely naturally surface through various\nimplementations, however some care should be taken to minimize ecosystem\ndisruption.\n\nAn [Impact Analysis][impact-analysis] has been done and continued discussion is\nnecessary. One recommendation is to serve a modified block with \"inline\" EB\ntransactions over LocalChainSync. Additional queries and ledger state may be\nextended to provide Leios specific information to applications. It is assumed\nnodes providing client interfaces will provide the modified block to clients.\n\nA [CDDL for merged blocks](#merged-block-cddl) is available in Appendix B.\n\n## Rationale: how does this CIP achieve its goals?\n\nOuroboros Leios introduces a committee-based voting layer over Nakamoto-style\nconsensus to handle transaction surplus beyond current Praos block limits,\nenabling substantial throughput increases while preserving existing security\nproperties.\n\n### How Leios addresses CPS-18\n\nThe [Leios research paper][leios-paper] describes a highly concurrent protocol\nwith three block types — Input Blocks (IBs), Endorser Blocks (EBs), and Ranking\nBlocks (RBs) — produced independently across decoupled, pipelined stages. This\nspecification simplifies that design by eliminating IBs and coupling EB\nproduction with RB production, reducing complexity while preserving substantial\nthroughput gains.\n\nThis simplification avoids the complexity and ecosystem disruption of\nimplementing massive throughput increases immediately, while still delivering\nsubstantial gains to address [CPS-18 Greater Transaction Throughput][cps-18]\nchallenges. Four strategic design priorities guided this approach:\n\n1. [Economic sustainability](#economic-sustainability)\n2. [Reasonable time to market](#time-to-market)\n3. [Minimal downstream impact](#downstream-impact)\n4. [Competitive positioning](#competitiveness)\n\n<a name=\"economic-sustainability\"></a>**1. Economic sustainability: Capacity\nwithout utilization risk**\n\nOn one hand, this approach avoids over-engineering massive throughput capacity\nwithout proven demand. Creating fundamental system changes to support multiple\norders of magnitude more throughput adds to the cost of running a more\nexpensive, more capable system that does not pay for itself until utilization\nincreases.\n\nOn the other hand, the minimum economic requirement establishes the lower bound.\nAs the Cardano Reserve diminishes, transaction fees must replace rewards to\nmaintain network security and SPO profitability. Currently, the Reserve\ncontributes more than 85% of epoch rewards, with less than 15% coming from\ntransaction fees. By 2029, to compensate for Reserve depletion, the network\nrequires approximately 36-50 TPS with average-sized transactions — roughly 10\ntimes current mainnet throughput. This conservative lower bound represents the\nbreakeven point for running the protocol sustainably while maintaining the same\nlevel of decentralization.\n\nHowever, TPS is not an appropriate metric for defining these bounds. To properly\nassess economic breakeven points, we measure throughput in Transaction Bytes per\nsecond (TxB/s) rather than Transactions per second (TPS). TPS does not account\nfor transaction size or computational complexity, making systems with smaller\ntransactions appear \"faster\" while providing less utility. Current Cardano\nmainnet provides 4,500 TxB/s, while this specification targets 140,000-300,000\nTxB/s (equivalent to roughly 100-200 TPS) — a 30-65x increase sufficient for\neconomic sustainability.\n\n<div align=\"center\">\n<a name=\"figure-8\" id=\"figure-8\"></a>\n<p>\n  <img src=\"images/leios-forecast-sqrt-fill.svg\" alt=\"SPO profitability forecast under Leios\">\n</p>\n\n<em>Figure 8: SPO profitability forecast under Leios showing clear economic\nbenefits once sustained throughput exceeds 50-70 TxkB/s (36-50 TPS\nequivalent)</em>\n\n</div>\n\n<a name=\"time-to-market\"></a>**2. Reasonable time to market: Complexity\ntrade-offs**\n\nThe research protocol design is optimal in its usage of available network and\ncompute resources. However, it comes at the cost of significantly increased\ninclusion latency and a high level of concurrency. Both of which are undesirable\nin a real-world deployment onto the Cardano mainnet and need to be carefully\nweighed against the throughput increase.\n\nHigh concurrency allows for higher throughput by doing more transaction\nprocessing at the same time. In the published design and otherwise discussed\nvariants concurrency is introduced by allowing agreement on sequences of\ntransactions independently of the Praos block production. This is the case for\nwhen endorser blocks would be announced separately from Praos blocks or input\nblocks be produced on a completely separate schedule. While such protocol\ndesigns often result in higher latency due to more rounds, concurrency in itself\ngives rise to the dedicated problem of _conflicting transactions_.\n\nWhile some level of conflicting transactions and the network/compute waste\ncoming with it may be handled by the consensus protocol without giving\nadversaries an edge, perpetually storing transactions that do not execute (only\none of multiple conflicting transactions can be applied), is a significant cost\nfactor. Techniques for minimizing conflicts arising through concurrent block\nproduction like sharding, collateralization or sophisticated mempool\ncoordination have massive impacts on the ecosystem and could delay deployment by\nyears.\n\nThe proposed variant without concurrency and linearized processing, achieves\nhigh enough throughput without changing transaction semantics, deterministic\nordering, and predictable finality patterns that existing dApps and\ninfrastructure depend on today.\n\n<a name=\"downstream-impact\"></a>**3. Minimal downstream impact: Ecosystem\npreservation**\n\nBeyond preserving transaction behavior, the design minimizes infrastructure and\noperational disruption for the existing ecosystem. The proposed protocol still\nfunctions as an overlay extending Praos — like the research paper version,\nallowing SPOs to upgrade progressively without coordinated migrations.\n\nThe most obvious approach to increasing throughput while minimizing disruption\nwould be increasing Praos block sizes. However, this naive alternative would\ncreate proportionally longer propagation times that violate Praos timing\nassumptions and lack sufficient scalability for long-term viability.\nAdditionally, Praos blocks larger than approximately 3 MB would pose security\nrisks by increasing the frequency of short forks that adversaries could exploit\nto compromise the common prefix property and enable attacks such as\ndouble-spending. Nonetheless, improved Praos block times would be an improvement\nalso benefiting [Leios](#alternatives--extensions).\n\n<a name=\"competitiveness\"></a>**4. Competitive positioning**\n\nThe coupled block production design can be extended towards higher concurrency\nmodels, as demonstrated in simulation results. It maintains compatibility with\nmore aggressive scaling approaches including full Leios variants, EB and IB\n(input block) decoupling, and sharding extensions, ensuring current throughput\ngains do not preclude 100x+ improvements when chain growth solutions mature and\nonce the ecosystem is ready to tackle the complexity coming with it.\n\n<a name=\"optimal-tradeoffs\"></a>**Conclusion**\n\nThis linearization proposal balances all four priorities. A delivered 30-65x\nimprovement provides substantially more value than the research paper's\nhigher-concurrency variants, which would impose major changes on the ecosystem\nand take significantly longer to build.\n\nThe following evidence section shall provide quantitative support for these\ntrade-offs and validate the protocol's performance under realistic network\nconditions.\n\n### Evidence\n\nThis section provides protocol simulation results, feasible protocol parameters\nwith justifications, node-level simulation results, and operating cost analysis\nthat support the design decisions outlined in the rationale.\n\n#### Performance Metrics\n\nThe performance of a protocol like Leios can be characterized in terms of its\nefficient use of resources, its total use of resources, the probabilities of\nnegative outcomes due to the protocol's design, and the resilience to adverse\nconditions. Metrics measuring such performance depend upon the selection of\nprotocol parameters, the network topology, and the submission of transactions.\nThe table below summarizes key metrics for evaluating Leios as a protocol and\nindividual scenarios (parameters, network, and load). Estimates for many of\nthese appear in the following section on Simulation Results. Additionally,\nfuture implementations of Leios can be assessed in these terms.\n\n<div align=\"center\">\n<a name=\"table-5\" id=\"table-5\"></a>\n\n|  Category  | Metric                                             | Measurement                                                                                           |\n| :--------: | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |\n| Efficiency | Spatial efficiency, $\\epsilon_\\text{spatial}$      | Ratio of total transactions size to persistent storage                                                |\n|            | Temporal efficiency, $\\epsilon_\\text{temporal}(s)$ | Time to include transaction on ledger                                                                 |\n|            | Network efficiency, $\\epsilon_\\text{network}$      | Ratio of total transaction size to node-averaged network usage                                        |\n|  Protocol  | TX inclusion, $\\tau_\\text{inclusion}$              | Mean number of slots for a transaction being included in any EB                                       |\n|            | Voting failure, $p_\\text{noquorum}$                | Probability of sortition failure to elect sufficient voters for a quorum                              |\n|  Resource  | Network egress, $q_\\text{egress}$                  | Rate of bytes transmitted by a node                                                                   |\n|            | Disk usage, $q_\\text{disk}$                        | Rate of persistent bytes stored by a node                                                             |\n|            | I/O operations, $\\bar{q}_\\text{iops}(b)$           | Mean number of I/O operations per second, where each operation writes a filesystem block of $b$ bytes |\n|            | Mean CPU usage, $\\bar{q}_\\text{vcpu}$              | Mean virtual CPU cores used by a node                                                                 |\n|            | Peak CPU usage, $\\hat{q}_\\text{vcpu}$              | Maximum virtual CPU cores used by a node over a one-slot window                                       |\n| Resilience | Adversarial stake, $\\eta_\\text{adversary}(s)$      | Fractional loss in throughput due to adversarial stake of $s$                                         |\n\n<em>Table 5: Performance Metrics</em>\n\n</div>\n\n**_Spatial efficiency:_** Leios necessarily imposes some disk overhead beyond\nthe raw bytes needed to store transactions themselves. This overhead includes\nthe EBs and RBs associated with storing transactions. The spatial efficiency\nmetric is defined as the ratio of the total bytes of transactions included in\nthe ledger to the total persistent storage required by the protocol.\n\n$$\n\\epsilon_\\text{spatial} = \\frac{\\text{total bytes of transactions included in the ledger}}{\\text{total bytes of EBs and RBs}}\n$$\n\n**_Temporal efficiency:_** As is true for Praos, there is a delay between\nsubmitting a transaction and its being included in the ledger and there is a\nfinite chance that it never is included in the ledger. Before a transaction is\nendorsed, it must be validated and placed in the memory pool. It is cleanest to\nmeasure the time from the transaction reaching the local memory pool of the node\nwhere it was submitted to the time when it is included in the ledger, via a\nPraos block. The same metric applies both to Praos and to Leios. In aggregate,\nwe measure the temporal efficiency as the fraction of transactions that reach\nthe ledger, as function of the number of slots elapsed. The quantity\n$\\epsilon_\\text{temporal}(\\infty)$ is the fraction of submitted transactions\nthat ever reach the ledger.\n\n$$\n\\epsilon_\\text{temporal}(s) = \\text{fraction of transactions included in the ledger within } s \\text{ slots of their inclusion in a local memory pool}\n$$\n\n**_Network efficiency:_** Effective utilization of the network can be\ncharacterized by the ratio of bytes of transactions reaching the ledger to the\naverage network traffic per node. (This could also be computed individually for\neach node and used as a local metric.)\n\n$$\n\\epsilon_\\text{network} = \\frac{(\\text{bytes of valid transactions reaching the ledger}) \\cdot (\\text{number of nodes in the network})}{\\text{total bytes of network traffic}}\n$$\n\n**_TX inclusion:_** In Leios, it is possible that a transaction might have to\nwait for multiple EB production opportunities before being included in an EB.\nThe characteristic time for such inclusion in an EB depends on the EB production\nrate and mempool management. This is correlated with how long the transaction\nwaits in the memory pool before being selected for inclusion.\n\n$$\n\\tau_\\text{inclusion} = \\text{mean number of slots for a transaction to be included in any EB}\n$$\n\n**_Voting failure:_** An unlucky set of VRF evaluations might result in\ninsufficient voters being selected for a given EB, thus making it impossible to\ncertify that EB.\n\n$$\np_\\text{noquorum} = \\text{probability of sufficient voters to achieve a quorum for a given EB}\n$$\n\n**_Network egress:_** Cloud service providers typically charge for network\negress rather than for network ingress. The quantity $q_\\text{egress}$ is the\nnumber of bytes sent from a node per unit time.\n\n**_Disk usage:_** Leios requires that EBs and RBs be stored permanently; votes\nneed not be stored permanently, however. The quantity $q_\\text{disk}$ is the\ntotal number of EB and RB bytes generated per unit time.\n\n**_I/O operations:_** Some cloud service providers limit or bill input/output\noperations on a per-second capacity basis. The number of I/O operations depends\nupon the filesystem's block size $b$, not on the logical number of writes to\ndisk by the protocol: e.g., writing an EB of 32,768 bytes might consist of 64\nI/O operations on a filesystem having a 512-byte block size. We assume that disk\ncaching and delayed writes smooth out the unevenness in I/O operations, so that\nthe mean $\\bar{q}_\\text{iops}$ is the best metric here.\n\n**_Mean CPU usage:_** Computation resources consumed by the number are\nquantified as $\\bar{q}_\\text{vcpu}$, which is the mean number of virtual CPU\ncores utilized by the protocol.\n\n**_Peak CPU usage:_** Because CPU usage varies depending upon the node's\nactivity, the maximum number of virtual CPU cores utilized by the protocol\nduring any slot, $\\hat{q}_\\text{vcpu}$, provides a useful indication of\ncomputational burstiness and of how a virtual machine should be sized for Leios.\n\n**_Adversarial stake:_** Similarly, when adversarial stake is appreciable and\nactive, the throughput of Leios might drop.\n\n$$\n\\eta_\\text{adversary}(s) = \\frac{\\text{bytes of transactions reaching the ledger without adversarial activity}}{\\text{bytes of transactions reaching the ledger with adversarial activity given fraction } s \\text{ of the total stake}}\n$$\n\n#### Simulation Results\n\nThe [Leios paper][leios-paper] provides a rigorous theoretical analysis of the\nsafety and throughput of the protocol. That has been reinforced and demonstrated\nby prototype simulations written in Haskell and Rust.\n\nThe simulation results use a [mainnet-like topology][mainnet-topology] that\naccurately reflects the characteristics of the Cardano mainnet. This includes a\nrealistic distribution of stake and a representative number of stake pools. The\nnetwork is designed with a total of 10,000 nodes\n[pseudo-mainnet][pseudo-mainnet] or 750 nodes [mini-mainnet][mini-mainnet],\nwhere each block producer is connected exclusively to two dedicated relays.\nFurthermore, the topology incorporates realistic latencies based on the [RIPE\nAtlas][ripe-atlas] ping dataset and bandwidth that aligns with the lower end of\nwhat is typically found in cloud data centers. The node connectivity and\ngeographic distribution (across various countries and autonomous systems) are\nalso consistent with real-world measurements. [A simulation\nstudy][topology-comparison] has demonstrated that analysis conclusions deriving\nfrom the `mini-mainnet` topology are also valid for the `pseudo-mainnet`\ntopology; the advantage of using the former is that simulations run much more\nquickly. Simulated RB diffusion is consistent with the Praos performance\nmodel.[^praosp] For instructions on how to recreate these simulation results,\nsee [^sim-recreation].\n\n[^mnrm]:\n    [Mainnet-like topologies for Leios](https://github.com/input-output-hk/ouroboros-leios/blob/6d8619c53cc619a25b52eac184e7f1ff3c31b597/data/simulation/pseudo-mainnet/ReadMe.md)\n\n[^sim-recreation]:\n    [How to recreate simulation results](https://github.com/input-output-hk/ouroboros-leios/blob/main/analysis/sims/ReadMe.md)\n\n[^pseudo]:\n    [Leios pseudo-mainnet topology](https://github.com/input-output-hk/ouroboros-leios/blob/6d8619c53cc619a25b52eac184e7f1ff3c31b597/data/simulation/pseudo-mainnet/topology-v1.md)\n\n[^mini]:\n    [Leios mini-mainnet topology](https://github.com/input-output-hk/ouroboros-leios/blob/6d8619c53cc619a25b52eac184e7f1ff3c31b597/data/simulation/pseudo-mainnet/topology-v2.md)\n\n[^ripe]: [RIPE Atlas](https://atlas.ripe.net/)\n\n[^mncp]:\n    https://github.com/input-output-hk/ouroboros-leios/blob/6d8619c53cc619a25b52eac184e7f1ff3c31b597/analysis/sims/2025w30b/analysis.ipynb\n\n[^praosp]:\n    https://github.com/IntersectMBO/cardano-formal-specifications/blob/6d4e5cfc224a24972162e39a6017c273cea45321/src/performance/README.md\n\nThe simulation results in the remainder of this section use the Rust simulator\nwith a set of protocol parameters suitable for running Leios at 200 kB/s of\ntransactions, which corresponds to approximately 150 tx/s of transactions of\nsizes typical on the Cardano mainnet. The maximum size of transactions\nreferenced by an EB is 12 MB and the stage lengths are\n$3 \\times L_\\text{hdr} = 3 \\text{ slots}$, $L_\\text{vote} = 4$, and\n$L_\\text{diff} = 7 \\text{ slots}$. In order to illustrate the minimal\ninfrastructure resources used by Leios at these throughputs, we have limited\nnodes to 4 virtual CPUs each and limited inter-node bandwidth to 10 Mb/s. We\nvary the throughput to illustrate the protocol's behavior in light vs congested\ntransaction loads, and inject transaction from the 60th through 960th slots of\nthe simulation; the simulation continues until the 1500th slot, so that the\neffects of clearing the memory pool are apparent. The table below summarizes the\nresults of the simulation experiment. We see that a transaction at the front of\nthe memory pool can become referenced by an EB in as few as 20 seconds when the\nsystem is lightly or moderately loaded and that it can reach certification on\nthe ledger in about one minute. These times more than double under congested\nconditions. In all cases there is little overhead, relative to the total bytes\nof transactions, in data that must be stored permanently as the ledger history.\n\n<div align=\"center\">\n<a name=\"table-6\" id=\"table-6\"></a>\n\n| Throughput [TxMB/s] | TPS at 1500 B/tx | Conditions    | Mempool to EB [s] | Mempool to ledger [s] | Space efficiency [%] |\n| ------------------: | ---------------: | ------------- | ----------------: | --------------------: | -------------------: |\n|               0.150 |            100.0 | light load    |              17.9 |                  55.9 |                 92.3 |\n|               0.200 |            133.3 | moderate load |              22.6 |                  64.5 |                 97.2 |\n|               0.250 |            166.7 | heavy load    |              22.9 |                  62.0 |                 97.5 |\n|               0.300 |            200.0 | congestion    |              43.1 |                  83.8 |                 97.5 |\n|               0.350 |            233.3 | over capacity |             135.5 |                 176.9 |                 96.9 |\n\n<em>Table 6: Leios efficiency at different throughputs</em>\n\n</div>\n\nThe first plot below demonstrates that most transactions reach the ledger in\nunder two minutes in these simulations when the system is not congested. This\ntransaction lifecycle time lengthens as congestion increases. The plot colors\ntransactions by the minute when they were submitted so that one can see that the\ndistribution of delays is independent of the submission time in the uncongested\ncases, but that there are \"lucky\" or \"unlucky\" periods in the congested cases.\nThe variability arises from the randomness of the RB production scheduled.\nFirst, a transaction may has to wait for an RB to be forged; second, a\ntransaction referenced by an EB has to wait for the following RB to be forged.\nThe EB is discarded, however, if the second RB is produced in fewer than\n$3 \\times L_\\text{hdr} + L_\\text{vote} + L_\\text{diff}$ slots after the first\nRB. Thus, both the time to the next RB and the RB following that introduce\nunpredictability in a transaction reaching the ledger under even lightly loaded\nconditions. When the sortition happens to produce RBs too close together,\ntransactions will accumulate in the memory pool, awaiting favorable sortition\nconditions. If too many accumulate, there is not room for all of them to be\nincluded in the next EB. The second plot below illustrates that all transactions\neventually do arrive on the ledger, but that they may have to wait long during\ncongestion. During light load a transaction takes one or two minutes to reach\nthe ledger, but in heavier load it might take three minutes or even longer. The\ncapacity parameter $S_\\text{EB-tx}$ (12 MB/EB in these simulations)\nfundamentally limits the amortized maximum throughput of Leios: furthermore, it\naffects how long it takes transactions to reach the ledger as the throughput\napproaches the capacity. Note that 300 TxkB/s is just below the theoretical\nlimit of throughput for the protocol parameters used in the simulation; at that\nrate, runs of unlucky sortition will delay some transactions reaching the\nledger, even though those transactions eventually do reach it when sortition\nbecomes luckier. At 350 TxkB/s, transactions will backup up in the memory pool\nand clients, taking longer and longer to reach the ledger: the bottom row of the\nfirst plot illustrates that when transactions stop being submitted in the 16th\nminute of the simulation, those queued up in the memory pool and clients do\neventually reach the ledger, as expected for a protocol exhibiting\n\"backpressure\" on clients when load exceeds capacity. A realistic prototype or\nan actual Leios node implementation would not exhibit the long delays that one\nsees in the bottom row of Figure 9, which is an artifact of the simulator having\nan unbounded memory pool; instead, the times from the memory pool to ledger\nwould exhibit the behavior of the 300 TxkB/s row above it, where the memory pool\nnever gets fuller than can be cleared by one or two successful EBs. (Note that\nPraos is subject to this same behavior where the larger the memory pool, the\nlonger the delay from the memory pool to ledger, under conditions of demand that\nexceeds capacity.)\n\n<div align=\"center\">\n<a name=\"figure-9\" id=\"figure-9\"></a>\n\n![Time for transaction to reach the ledger](images/reach-rb-tx.svg)\n\n<em>Figure 9: Time for transaction to reach the ledger</em>\n\n</div>\n\n<div align=\"center\">\n<a name=\"figure-10\" id=\"figure-10\"></a>\n\n![Transactions reaching the ledger](images/temporal-efficiency-bar.svg)\n\n<em>Figure 10: Transactions reaching the ledger</em>\n\n</div>\n\nThe effect of EBs being discarded when RBs are too close together is evidenced\nin the following plot. A transaction referenced only once by an EB is one that\nreaches the ledger on the first attempt. If a transaction is referenced by more\nthan one EB, it means that several attempts were made to before a relevant EB's\ncertificate was included in an RB. The subsequent plot shows Leios' irregular\nrhythm of forging, sometimes discarding, and certifying EB. (Note that RBs are\nso small relative to most EBs that they are difficult to see in the histogram.)\nThe diagram also provides a sense of the intermittency of successful\ncertification and the presence of periods of unfavorable sortition where RBs are\nnot produced or are produced too close together. The same phenomenon occurs in\nPraos, but Leios amplifies the intermittency.\n\n<div align=\"center\">\n<a name=\"figure-11\" id=\"figure-11\"></a>\n\n![Number of TX references](images/references-tx.svg)\n\n<em>Figure 11: Number of TX references</em>\n\n</div>\n\n<div align=\"center\">\n<a name=\"figure-12\" id=\"figure-12\"></a>\n\n![Disposition of transactions in blocks](images/disposition-size-timeseries.svg)\n\n<em>Figure 12: Disposition of transactions in blocks (RBs are so small as not to\nbe visible in the histograms. When an EB is generated, it is labeled in the plot\nas to whether it will eventually be certified (\"EB later certified\") or not (\"EB\nlater not certified\"). When the certificate is included in an RB, the EB is\nlabeled \"EB now certified\".)</em>\n\n</div>\n\nWhen demand is not high relative to capacity, the total size of transactions\nreferenced by an EB varies randomly and rarely reaches the maximum size of 12\nMB/EB: see the following figure. One can see that at higher demands fully\nutilized blocks predominate. The presence of those full blocks means that other\ntransactions are waiting in the memory pool for referencing by a subsequent EB.\nThus the capacity parameter provides a natural form of backpressure that limits\nthe potential EB-related work a node must do when demand is high.\n\n<div align=\"center\">\n<a name=\"figure-13\" id=\"figure-13\"></a>\n\n![Size of transactions referenced by EBs](images/contents-ebs-size.svg)\n\n<em>Figure 13: Size of transactions referenced by EBs</em>\n\n</div>\n\nBecause of the aforementioned backpressure, diffusion occurs in Leios in an\norderly manner even when demand is high. The following set of plots show\nhistograms of diffusion time (i.e., the time from a transaction's, RB's, EB's,\nor vote's creation to its reaching the nodes in the network). Transactions and\nvotes typically diffuse rapidly throughout the whole network in fractions of a\nsecond, due to their small sizes, often small enough to fit in a single TCP\ntransmission unit. RBs diffuse in approximately one second, with the empty RBs\nat the start and end of the simulation diffusing fastest. Similarly, EBs diffuse\nfast when empty or when demand is low, but once full EBs are diffusing, it can\ntake up to two seconds for them to diffuse. All of the distributions have long\ntails where messages arrive much later for nodes with unfavorably topological\nlocations. The Leios protocol possesses the important property that traffic in\ntransactions, RBs, votes, and EBs do not interfere with one another: for\nexample, delays in EBs and high throughput do not also delay RBs in those cases.\n\n<div align=\"center\">\n<a name=\"figure-17\" id=\"figure-17\"></a>\n\n|                                                 |                                                 |\n| ----------------------------------------------- | ----------------------------------------------- |\n| ![Arrival delay for TXs](images/elapsed-TX.svg) | ![Arrival delay for RBs](images/elapsed-RB.svg) |\n| ![Arrival delay for VTs](images/elapsed-VT.svg) | ![Arrival delay for EBs](images/elapsed-EB.svg) |\n\n<em>Figure 17: Arrival delays for transactions (\"TX\", upper left), ranking\nblocks (\"RB\", upper right), votes (\"VT\", lower left), and endorser blocks (\"EB\",\nlower right)</em>\n\n</div>\n\n##### Behavior under varying load\n\nThe simulation results also provide evidence that Leios operates as a\nwell-behaved protocol, conforming to three specific desirable properties.\n\n1. _Throughput is proportional to load until it plateaus when capacity is\n   reached:_ Figure 14 illustrates the near equality of throughput to load up\n   until the approximately 300 TxkB/s capacity (determined by the protocol\n   parameters) is reached, beyond which throughput stays constant. (Note that\n   the randomness of sortition and the finite duration of the simulation results\n   in some jitter and uncertainty in the data points even though the trend is\n   clear.) It is particularly important that the throughput does not degrade at\n   very high demand: instead Leios provides backpressure on clients, via the\n   memory pool, so that the protocol operates at capacity even though demand is\n   higher.\n2. _Transaction delivery time and its variance remains constant up until the\n   protocol's capacity is reached:_ The left side of Figure 15 demonstrates that\n   the observed range of transaction delivery time, which is defined in these\n   plots as the time from being submitted to the time of reaching the ledger,\n   stays essentially constant nearly until capacity is reached. Because the\n   Leios simulator has an unbounded (unlimited) memory pool, one sees that times\n   increase beyond that due to the memory pool growing ever larger. Near\n   capacity, fluctuations from sortitition result in uncertainty. The right side\n   of Figure 15 shows the additional time imposed by Leios relative to Praos: at\n   very low demand, Leios does not often forge EBs and the delay is small, but\n   at moderate and high loads a nearly constant delay is associated with most\n   transactions appearing in EBs. This property is important in that Leios\n   performance does not degrate as demand approaches or exceeds capacity.\n3. _The processing cost per transaction decreases or levels off as load\n   increases:_ Figure 16 evidences that the CPU and network used per transaction\n   generally drops as load (i.e., demand) increases. (Once again there are\n   uncertainties in this plot due to the randomness or sortition and design\n   choices in the Leios simulator.) This property is important in that the\n   per-transaction consumption of resources should not lower efficiency, which\n   would lead to disproportional stress on resources as load increases.\n\n<div align=\"center\">\n<a name=\"figure-14\" id=\"figure-14\"></a>\n\n![Leios throughput is proportional to load until it plateaus when capacity is reached.](images/load-throughput.svg)\n\n<em>Figure 14: Leios throughput (bytes reaching the ledger) as a function of\nload (i.e., demand). Points are uncertain due to the randomness of block\nproduction in these simulations of twenty minutes. Note that the simulator's\nunlimited memory pool starts empty.</em>\n\n</div>\n\n<div align=\"center\">\n<a name=\"figure-15\" id=\"figure-15\"></a>\n\n|                                                                                                      |                                                                          |\n| ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |\n| ![The variability of delivery times plateaus until capacity is reached.](images/load-txvariance.svg) | ![Transaction delay to ledger for Leios vs Praos](images/load-delay.svg) |\n\n<em>Figure 15: (left) time from a transaction's being submitted to the memory\npool to its reaching the ledger (10th, 50th, and 90th percentiles) as a function\nof load; (right) Additional time it takes a transaction to reach the ledger in\nLeios, relative to the time it would have taken in Praos, as a function of\ndemand. Points are uncertain due to the randomness of block production in these\nsimulations of twenty minutes. Note that the simulator's unlimited memory pool\nstarts empty.</em>\n\n</div>\n\n<div align=\"center\">\n<a name=\"figure-16\" id=\"figure-16\"></a>\n\n|                                                                                                                              |                                                                                                                                     |\n| ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |\n| ![The CPU cost of processing per transaction either remains the same or goes down as the load goes up.](images/load-cpu.svg) | ![The network cost of processing per transaction either remains the same or goes down as the load goes up.](images/load-egress.svg) |\n\n<em>Figure 16: The resource cost of Leios processing per transaction as a\nfunction of load (i.e., demand): (left) CPU usage; (right) network egress.\nPoints are uncertain due to the randomness of block production in these\nsimulations of twenty minutes. Note that the simulator's unlimited memory pool\nstarts empty.</em>\n\n</div>\n\n##### Resource requirements\n\nThe resource requirements for operating Leios nodes have been estimated from\nbenchmarking and simulation studies. The assumed values for various Leios\noperations come either from measurements of the [cryptography\nprototype][leioscrypto], from the IOG benchmarking cluster for the Cardano node,\nor analysis of the Cardano mainnet ledger using the `db-analyser` tool. These\nwere input to the Haskell and Rust simulators for Leios to make holistic\nestimates of resource usage of operating nodes.\n\nIn terms of resource usage, the throughputs in these simulations do no stress\nthe four virtual CPUs of each node or saturate the 10 Mb/s available bandwidth\nbetween nodes. The figures below show that bandwidth usage does not exceed 4\nMb/s and that most of that is consumed by diffusion of transactions among the\nnodes. Furthermore, vCPU usage stays below 100% (i.e., the equivalent of one\nvCPU operating fully), though it is very bursty because of the uneven workload\nof cryptographic and ledger operations. The last figure quantifies how\ntransaction and EB body validation dominate CPU usage. Averaged over time, CPU\nusage is low: there may be opportunities in the implementation of the Leios node\nfor lazy computations, caching, etc. that will spread out the occasional spikes\nin CPU usage over time.\n\n<div align=\"center\">\n<a name=\"figure-18\" id=\"figure-18\"></a>\n\n|                                                        |                                                                  |\n| ------------------------------------------------------ | ---------------------------------------------------------------- |\n| ![Mean nodal ingress](images/ingress-average-area.svg) | ![Mean CPU load among all nodes](images/cpu-mean-timeseries.svg) |\n\n<em>Figure 18: Mean nodal ingress (left) and Mean CPU load among all nodes\n(right)</em>\n\n</div>\n\n<div align=\"center\">\n<a name=\"figure-19\" id=\"figure-19\"></a>\n\n![Mean CPU load among all nodes](images/cpu-mean-histogram.svg)\n\n<em>Figure 19: Mean CPU load among all nodes (\"Gen\" = generated, \"Val\" =\nvalidated, \"RH\" = ranking block header, \"RB\" = ranking block body, \"EH\" =\nendorser block header, \"EB\" = endorser block body\", \"TX\" = transaction)</em>\n\n</div>\n\nNote that the transaction workload in the simulations above was modeled upon the\n_average_ amount of Plutus computation typical of the Cardano mainnet. The low\ntime-averaged CPU usage in the simulations (i.e., less than 15% of a vCPU)\nsuggests that the per-transaction and/or per-block Plutus budget could be\nsignificantly increased under Leios: either every transaction could have a\nmodestly higher budget, or some transactions could use an order of magnitude\nmore Plutus execution units.\n\nStatistical analysis of [CPU usage in ledger operations][timings] using the\n[db-analyser tool][dbanalyser] on Cardano mainnet from epoch 350 through 573\nyields the following simple models of the CPU cost of validating signatures and\nexecuting Plutus in the transactions of a block. Because of the noisiness in the\nraw mainnet data, these estimates are uncertain.\n\n- Ledger \"apply\" operation, consisting of phase 1 & 2 validation along with\n  updating the current ledger state:\n  - CPU per transaction in a block: `620.1 μs/tx`.\n  - Linear model that accounts for Plutus:\n    `(262.4 μs/tx) * (number of transactions) + (948.7 μs/Gstep) * (billions of Plutus execution steps)`.\n- Ledger \"reapply\" operation, consisting of updating the current ledger state,\n  omitting previously performed phase 1 & 2 validation:\n  - Linear model: `(353.9 μs) + (21.51 μs/kB) * (size of the block)`\n  - Linear model that accounts for Plutus:\n    `(347.8 μs) + (19.43 μs/kB) * (size of the block) + (21.27 μs/Gstep) * (billions of Plutus execution steps)`\n\nThe Leios simulators perform the \"apply\" operation when a transaction is first\nseen, either when it is received for the memory pool or when it is fetched after\nfirst being seen in an RB or EB; they perform the \"reapply\" operation when a\nblock is being generated or validated. A more nuanced model of CPU usage in the\nsimulators would account for Plutus execution explicitly, but the linear models\ndescribed above are used to account for Plutus workloads implicitly. The\nfollowing plot of simulation results limit each node to 4 vCPU cores and suggest\nthat workloads of 10<sup>13</sup> Plutus execution steps per EB may be feasible:\nthis is 500 times the current Cardano mainnet limit of 2×10<sup>10</sup> steps\nfor Praos blocks. The subsequent plot shows the 4 vCPUs becoming progressively\nmore saturated with heavier Plutus execution. Although these results suggest\nthat Leios's _block-level_ Plutus budget can safely be 2000 billion steps, it is\nimportant to remember that this is for conditions where honest nodes faithfully\nand promptly diffuse the transactions requiring the relatively expensive phase 2\n(Plutus) validation: adversarial nodes could attempt to delay diffusion of\ntransactions in order to overwhelm honest nodes with the sudden arrival of many\nheavy Plutus transactions and little time to validate them all before voting\nupon the newly seen EB. Experiments with prototype Leios nodes will be necessary\nto more precisely quantify how much the Plutus budget could safely be increased.\n\n<div align=\"center\">\n<a name=\"figure-20\" id=\"figure-20\"></a>\n\n![Fate of Plutus-heavy transactions in Leios](images/plutus-temporal-efficiency-bar.svg)\n\n<em>Figure 20: Fate of Plutus-heavy transactions in Leios</em>\n\n</div>\n\n<div align=\"center\">\n<a name=\"figure-21\" id=\"figure-21\"></a>\n\n|                                                                                             |                                                                                             |\n| ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |\n| ![Mean CPU usage in Plutus-heavy workloads for Leios](images/plutus-cpu-mean-histogram.svg) | ![Peak CPU usage in Plutus-heavy workloads for Leios](images/plutus-cpu-peak-histogram.svg) |\n\n<em>Figure 21: CPU usage in Plutus-heavy workloads for Leios</em>\n\n</div>\n\nIn summary, Leios will require a modest increase of the [recommended hardware\nrequirements][spohw]: a four-core machine will be required, but a network\nupgrade will not be needed, as 10 Mb/s is well below the bandwidth of standard\nnetwork connections. At throughput much higher than 200 kB/s, network egress can\nbecome a significant cost for nodes hosted on some cloud-computing providers.\nThe Leios simulations do not model memory or disk. With the advent of\n[UTxO-HD][utxohd], 16 GB of memory will remain be sufficient for Leios if the\n`OnDisk` option is used for the UTxO set. Disk requirements depend upon the\ngrowth of the ledger, but a sustained 0.150 MB/s throughput amounts to ledger\nsize increasing by 4.7 TB each year: see the [section below](operating-costs) on\nOperating Costs for further discussion.\n\n### Feasible Protocol Parameters\n\n**Parameter Relationships and Network Assumptions**\n\nThe key relation in the proposed protocol is between the voting threshold\n($\\tau = 75\\\\%$) and propagation delay of EBs ($\\Delta_\\text{EB}$). The high\nvoting threshold ensures that any certified EB is already known to at least 25%\nof honest nodes by the end of $L_\\text{vote}$, even assuming 50% adversarial\nstake. This widespread initial knowledge enables the critical network\nassumption: an EB evidently known to >25% of the network will reach the\nremaining (online) honest stake within $L_\\text{diff}$ and $\\Delta_\\text{RB}$,\nso to not impact blockchain safety and liveness.\n\n**Example Parameter Calculation**\n\nTo illustrate how these relationships translate into concrete parameters,\nconsider the following example based on simulated network measurements:\n\n**Given Network Characteristics:**\n\nBased on the [network timing measurements](#network-characteristics):\n\n- $\\Delta_\\text{hdr} = 1$ second, $\\Delta_\\text{RB} = 5$ seconds - Cardano\n  mainnet assumption for Praos security\n- $\\Delta_\\text{EB}^{\\text{O}} = 3$ seconds - EB diffusion: transmission +\n  processing\n- $\\Delta_\\text{EB}^{\\text{W}} = 15$ seconds - EB transmission time for\n  certified EBs\n- $\\Delta_\\text{reapply} = 1$ second - EB reapplication time\n\n**Timing Parameter Calibration:**\n\n- $L_\\text{hdr} = 1$ slot: Header diffusion period, where equivocation detection\n  period is $3 \\times L_\\text{hdr} = 3$ slots (per\n  [equivocation detection](#equivocation-detection))\n- $L_\\text{vote} = 4$ slots: Since voting begins after $3 \\times L_\\text{hdr}$,\n  and EB propagation can occur during equivocation detection, nodes only need 4\n  additional slots after $3 \\times L_\\text{hdr}$ for validation plus margin (per\n  [voting period](#voting-period))\n- $L_\\text{diff} = 7$ slots: Using the [diffusion period](#diffusion-period)\n  constraint with typical values gives minimum of 4 slots, we use 7 for safety\n  margin\n- **Total certificate inclusion delay:**\n  $3 \\times L_\\text{hdr} + L_\\text{vote} + L_\\text{diff} = 3 + 4 + 7 = 14$ slots\n\n**Simulation-Tested Parameters**\n\nThe table below documents protocol parameters that provided high throughput and\nreasonably fast settlement in prototype Haskell and Rust simulations. The exact\nchoice of parameters for Cardano mainnet must be subject to discussion and\nconsideration of tradeoffs.\n\n<div align=\"center\">\n<a name=\"table-7\" id=\"table-7\"></a>\n\n| Parameter                                     |      Symbol      |   Feasible value   | Justification                                                                                                                                                                          |\n| --------------------------------------------- | :--------------: | :----------------: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Header diffusion period length                |  $L_\\text{hdr}$  |       1 slot       | Per [equivocation detection](#equivocation-detection): accommodates header propagation for equivocation detection. Equivocation detection period is $3 \\times L_\\text{hdr}$.           |\n| Voting period length                          | $L_\\text{vote}$  |      4 slots       | Per [voting period](#voting-period): accommodates EB propagation and validation time, with equivocation detection handled separately by $3 \\times L_\\text{hdr}$.                       |\n| Diffusion period length                       | $L_\\text{diff}$  |      7 slots       | Per [diffusion period](#diffusion-period): minimum calculated as 4 slots with typical network values, use 7 for safety margin.                                                         |\n| Endorser-block referenceable transaction size | $S_\\text{EB-tx}$ |       12 MB        | Simulations indicate that 200 kB/s throughput is feasible at this block size.                                                                                                          |\n| Endorser block max size                       |  $S_\\text{EB}$   |       512 kB       | Endorser blocks must be small enough to diffuse and be validated within the voting period $L_\\text{vote}$.                                                                             |\n| Maximum Plutus steps per endorser block       |        -         |  2000G step units  | Simulations at high transaction-validation CPU usage, but an even higher limit may be possible.                                                                                        |\n| Maximum Plutus memory per endorser block      |        -         | 7000M memory units | Simulations at high transaction-validation CPU usage, but an even higher limit may be possible.                                                                                        |\n| Ranking block max size                        |  $S_\\text{RB}$   |    90,112 bytes    | This is the current value on the Cardano mainnet.                                                                                                                                      |\n| Mean committee size                           |       $n$        |  600 stake pools   | Modeling of the proposed certificate scheme indicates that certificates reach their minimum size of ~8 kB at this committee size, given a realistic distribution of stake among pools. |\n| Quorum size                                   |      $\\tau$      |        75%         | High threshold ensures certified EBs are known to >25% of honest nodes even with 50% adversarial stake. This enables the network assumption for safe diffusion within L_diff.          |\n\n<em>Table 7: Feasible Protocol Parameters</em>\n\n</div>\n\nThis design trades a slightly longer total certification time (typically 13-15\nslots) for significant protocol simplification by eliminating complex correction\nmechanisms and ensuring all RB transactions are always valid.\n\nSimulations on mainnet-like topologies indicate that seven slots is more than\nsufficient to diffuse the transactions, blocks, and votes required by Leios.\nMost nodes receive these in one second or less and even the tardiest nodes\nreceive them in under two seconds. The additional diffusion period provides\nample margin for worst-case scenarios while maintaining acceptable latency.\nHigher-fidelity simulators, better empirical data on mainnet performance, and\nLeios testnet operations will test the appropriateness of these parameters and\nrefine their values for final recommendations.\n\nThe aforementioned simulations also demonstrate that Leios operates up to 0.2\nTxMB/s without experiencing congestion, provided endorser blocks reference no\nmore than 12 MB of transactions. Even under adversarial conditions, where\nmalicious nodes release transactions from their private memory pool at the same\ntime that they forge a ranking block and an endorser block, simulations\ndemonstrate that 12 MB of transactions diffuse rapidly enough for the protocol\nto operate smoothly, achieving a quorum of votes before the voting period ends.\nIt is important to limit the number of transactions referenced by an endorser\nblock because the transaction-execution bitmap in a subsequent ranking block may\nhave to record information about conflicted transactions. A limit of 512 kB on\nthe size of the endorser block itself ensures fast diffusion and limits its\ncontents to 16,000 transactions, since each transaction hash is 32 bytes. That\nlimit keeps the size of the bitmap in the few-kilobyte range, ensuring that it\neasily fits in the ranking block. The combination of 12 MB of transaction data\nand 16,000 transactions implies an average transaction size of 2000 bytes when\nboth limits are reached: this is higher than the recent average transaction size\non Cardano mainnet.\n\nEstimating the feasible limits for Plutus execution requires a more solid\ngrounding, than currently exists, of the Plutus cost model in terms of actual\nCPU resources required to execute Plutus steps and memory. The empirical\nanalysis and simulations presented above suggest that the per-block Plutus\nbudget could be substantially increased. Results indicate that 2000 billion\nPlutus steps would consume less than two CPU-seconds of computation on typical\nnode hardware. On a four-core machine there would be sufficient resources to\nevaluate the Plutus rapidly enough so as not to interfere with voting for\nendorser blocks.\n\nAlthough the Praos maximum block size could be modestly raised in Leios and the\nactive-slot coefficient adjusted slightly, there is no compelling reason to\nalter these. They could, however, be re-evaluated in the context of the Leios\ntestnet.\n\nThe analysis [Committee size and quorum requirement][committee-size-analysis] in\nthe first Leios Technical Report indicates that the Leios committee size should\nbe no smaller than 500 votes and the quorum should be at least 60% of those\nvotes. However, the proposed [Fait Accompli][fait-accompli-sortition] scheme\nwFA<sup>LS</sup> achieves compact certificates that do not become larger as the\nnumber of voters increases, so larger committee sizes might be permitted for\nbroader SPO participation and higher security. The committee size should be\nlarge enough that fluctuations in committee membership do not create an\nappreciable probability of an adversarial quorum when the adversarial stake is\njust under 50%. The quorum size should be kept just large enough above 50% so\nthat those same fluctuations do not prevent an honest quorum. Larger committees\nrequire more network traffic, of course.\n\n<a name=\"operating-costs\"></a>**Operating costs**\n\nApproximate Leios operating costs are estimated based on the detailed cost\nanalysis of Leios deployment in [Leios node operating costs][cost-estimate], the\nsimulation results, and the hardware recommendation for Leios. However, these\ncosts depend on the specific choice of cloud provider hardware and the current\nmarket conditions. The estimates below were made in April 2025 for the median\npricing of ten common hyperscale and discount cloud providers. The cost of a\n10,000-node Leios network can be computed from the cost per node. Storage costs\nincrease each month as the ledger becomes larger.\n\n<div align=\"center\">\n<a name=\"table-8\" id=\"table-8\"></a>\n\n| Throughput | Average-size transactions | Small transactions | Per-node operation | Per-node storage<br/>($) | Per-node storage<br/>(GB) | 10k-node network<br/>(first year) | 10k-node network<br/>(first year) |\n| ---------: | ------------------------: | -----------------: | -----------------: | -----------------------: | ------------------------: | --------------------------------: | --------------------------------: |\n| 150 TxkB/s |                  100 Tx/s |           500 Tx/s |      $119.01/month |            $26.35/month² |              394 GB/month |                            $15.9M |                       $217k/epoch |\n| 200 TxkB/s |                  133 Tx/s |           667 Tx/s |      $127.60/month |            $37.64/month² |              526 GB/month |                            $17.6M |                       $241k/epoch |\n| 250 TxkB/s |                  167 Tx/s |           833 Tx/s |      $132.24/month |            $43.92/month² |              657 GB/month |                            $18.5M |                       $253k/epoch |\n| 300 TxkB/s |                  200 Tx/s |          1000 Tx/s |      $138.88/month |            $54.64/month² |              788 GB/month |                            $19.8M |                       $271k/epoch |\n| 350 TxkB/s |                  233 Tx/s |          1167 Tx/s |      $148.47/month |            $65.59/month² |              920 GB/month |                            $21.8M |                       $298k/epoch |\n\n<em>Table 8: Operating Costs by Transaction Throughput</em>\n\n</div>\n\n_Required TPS for Infrastructure Cost Coverage:_ Using average transaction sizes\nand fees, we can calculate the required TPS to generate enough fees to cover\ninfrastructure costs. Note that only about 20% of fees currently accrue to SPOs,\nbut the table assumes 100% would accrue to them; to maintain the current 80%-20%\nsplit, fives times as much fee would have to be collected compared to what is\nlisted in the table.\n\n<div align=\"center\">\n<a name=\"table-9\" id=\"table-9\"></a>\n\n| Infrastructure cost | Required ADA<br/>@ $0.45/ADA | Required transactions<br/>(average size)<br/>@ $0.45/ADA | Required transactions<br/>(small size)<br/>@ $0.45/ADA |\n| ------------------: | ---------------------------: | -------------------------------------------------------: | -----------------------------------------------------: |\n|         $15.9M/year |               483k ADA/epoch |                                                5.15 Tx/s |                                              6.71 Tx/s |\n|         $17.6M/year |               535k ADA/epoch |                                                5.70 Tx/s |                                              7.44 Tx/s |\n|         $18.5M/year |               563k ADA/epoch |                                                6.00 Tx/s |                                              7.83 Tx/s |\n|         $19.8M/year |               603k ADA/epoch |                                                6.43 Tx/s |                                              8.39 Tx/s |\n|         $21.8M/year |               622k ADA/epoch |                                                7.06 Tx/s |                                              9.21 Tx/s |\n\n<em>Table 9: Required TPS for Infrastructure Cost Coverage</em>\n\n</div>\n\n_Required TPS for Current Reward Maintenance:_ To maintain current reward levels\n(~48 million ADA monthly) through transaction fees as the Reserve depletes.\n\n<div align=\"center\">\n<a name=\"table-10\" id=\"table-10\"></a>\n\n| Year | Reserve Depletion | Rewards from Fees (ADA) | Required TPS (Average size) | Required Throughput |\n| ---: | ----------------: | ----------------------: | --------------------------: | ------------------: |\n| 2025 |               ~0% |                       0 |                           0 |            0 TxkB/s |\n| 2026 |              ~13% |               6,240,000 |                        10.9 |           15 TxkB/s |\n| 2027 |              ~24% |              11,520,000 |                        20.1 |           28 TxkB/s |\n| 2028 |              ~34% |              16,320,000 |                        28.5 |           40 TxkB/s |\n| 2029 |              ~43% |              20,640,000 |                        36.1 |           51 TxkB/s |\n| 2030 |              ~50% |              24,000,000 |                        41.9 |           59 TxkB/s |\n\n<em>Table 10: Required TPS for Current Reward Maintenance</em>\n\n</div>\n\nNote that by 2029, to compensate for Reserve depletion, the network would need\nto process approximately 36 TPS with average-sized transactions, requiring a\ntransaction throughput of around 51 TxkB/s, roughly 20 times the current mainnet\nthroughput. Leios' design would comfortably support this increased throughput\nwhile maintaining decentralization.\n\nWhile the empirical evidence demonstrates Leios' performance capabilities, any\nprotocol modification introduces new attack vectors and operational constraints\nthat must be carefully assessed. The following section examines potential\nsecurity risks and practical constraints that inform deployment considerations.\n\n### Trade-offs & Limitations\n\nHigh-throughput blockchain protocols require fundamental trade-offs between\nthroughput, latency, complexity, and security. The proposed specification\nbalances these competing dimensions to achieve substantial throughput gains\nwhile preserving ecosystem compatibility.\n\n<div align=\"center\">\n<a name=\"figure-22\" id=\"figure-22\"></a>\n\n![Leios Variants Comparison](images/leios-variants-comparison-radar.svg)\n\n<em>Figure 22: Comparison: Praos (red), proposed Leios (teal), and research\nLeios (orange)</em>\n\n</div>\n\nThe comparison illustrates the fundamental trade-off between throughput capacity\nand ecosystem disruption. While the research paper's approach (orange) achieves\nhigher throughput, it requires extensive ecosystem changes, significantly longer\nconfirmation times (2-3 minutes), and extended development timelines (2.5-3\nyears). The proposed specification (teal) strikes a strategic balance,\ndelivering substantial throughput improvements while maintaining manageable\nlatency increases and ecosystem compatibility.\n\n**Key Trade-offs:**\n\n- **Throughput**: 30-65x increase (from ~4.5 TxkB/s to ~140-300 TxkB/s)\n  addresses economic sustainability and Reserve depletion timeline\n- **Transaction Inclusion Latency**: Increases from ~20 seconds to 45-60 seconds\n- **Infrastructure**: Requires modest hardware upgrades (4-core machines) and\n  cryptographic key registration, offset by enhanced rewards\n- **Time to Market**: ~1-1.5 years for deployment versus 2.5-3 years for\n  higher-concurrency alternatives\n\n**Protocol Limitations:**\n\nThe specification involves operational constraints including timing dependencies\nthat require careful parameter tuning, confirmation complexity through multiple\ntransaction states, and interdependent protocol parameters requiring ongoing\noptimization. These represent acceptable trade-offs for achieving substantial\nthroughput improvements while maintaining familiar transaction structures and\necosystem compatibility.\n\n**Security Considerations:**\n\nThe proposed specification maintains Praos security properties through formal\ntiming constraints that ensure RB processing stays within Praos bounds. The\nhigh-participation design (75% voting threshold) eliminates invalid transactions\nin RBs and provides strong network assumptions for certified EB propagation. New\nthreats include equivocation by EB producers/voters and transaction availability\nattacks, mitigated through cryptographic validation, equivocation detection, and\nthe high voting threshold requirement. Comprehensive analysis is documented in\nthe [Protocol Security](#protocol-security) section and\n[threat model](https://github.com/input-output-hk/ouroboros-leios/blob/d5f1a9bc940e69f406c3e25c0d7d9aa58cf701f8/docs/threat-model.md).\n\n### Design Decisions\n\n#### Transaction References in Endorser Blocks\n\nEBs contain transaction references rather than full transaction bodies to avoid\nre-transmitting data already diffused through the network. Nodes fetch only\ntransactions they don't possess, reducing bandwidth and avoiding redundant\nvalidation when transactions are endorsed by multiple EBs. Complete transaction\ndata remains available through network diffusion and local storage for immutable\nchain purposes.\n\n### Alternatives & Extensions\n\nThe presented Leios specification provides a solid foundation for progressive\nenhancement towards higher throughput while maintaining ecosystem compatibility.\nSeveral alternative ideas and protocol variants were considered, which are\nlisted as possible extensions in this section.\n\nAs ecosystem priorities change, any of the following pathways could become more\nattractive to implement, each offering distinct trade-offs in terms of user\nexperience, implementation cost, security considerations, and throughput\npotential.\n\nFurthermore, most aspects build incrementally upon the base protocol and may\nform a roadmap of next steps.\n\n**Increase Praos Parameters**\n\nEnhancing Praos parameters through bigger blocks and higher active slot\ncoefficients offers a direct pathway to improved throughput. [Δ Q\nanalysis][praos-delta-q] and [simulations][praos-simulations] confirm there is\nroom for improvement, with analysis of 50 Tx/s and 100 Tx/s scenarios (84 TxkB/s\nand 172 TxkB/s respectively) demonstrating feasibility within current network\nconstraints. The 50 Tx/s case would provide economically sustainable throughput,\nthough RB diffusion approaches the $\\Delta$ assumption limits and leads to\nincreased network forks. While this change alone does not provide significant\nroom for future growth, it establishes a foundation for further enhancements.\n\nAs an extension, more frequent blocks rather than larger blocks could enhance\nLeios variants by enabling more frequent certifications and lower inclusion\nlatency. This approach requires tighter constraints on EB diffusion but provides\nbetter user experience through reduced transaction confirmation times.\n\n**Relax EB diffusion constraints**\n\nThe current design requires $\\Delta_\\text{EB}^{\\text{W}}$ (worst case) to be\nfairly small to enable selection of reasonable $L_\\text{diff}$ values that\nensure certified EBs do not impact Praos safety while maintaining frequent\nenough certification for high throughput. Should worst-case EB diffusion prove\nmuch larger than average or optimistic cases, introducing an additional recovery\nperiod $L_\\text{recover}$ after certificate inclusion could allow EBs to remain\nunavailable for extended periods.\n\nThis approach provides greater freedom in selecting $L_\\text{diff}$ parameters,\npotentially allowing values as low as zero. However, the security argument must\naccount for nodes being unable to validate blocks within $L_\\text{recover}$\nperiods. To preserve Praos safety and liveness, this requires relaxed chain\nvalidity rules where potentially invalid transactions could be permitted in\nranking blocks during recovery periods.\n\nThe increased protocol optimism enables higher throughput at the cost of\nsignificant complexity and downstream impacts on chain validity semantics. Light\nnode use cases would be particularly affected, requiring full ledger state to\ndetermine transaction validity during $L_\\text{recover}$ periods. Correction\nmechanisms through invalid transaction lists in subsequent certified EBs or\nranking blocks could mitigate these issues, though at the expense of additional\nprotocol complexity.\n\n**Transaction Groups**\n\nTransaction grouping mechanisms offer natural throughput optimization by\nreducing reference overhead in Endorser Blocks. Rather than individual\ntransaction references, EBs could reference transaction groups, enabling\ninclusion of more transaction bytes within existing block size constraints. This\nenhancement requires no fundamental protocol changes if nested transaction\napproaches like [CIP-118](https://github.com/cardano-foundation/CIPs/pull/862)\nprovide the underlying grouping infrastructure. The approach maintains full\ncompatibility with existing transaction validation while improving space\nefficiency.\n\n**Interaction with Peras**\n\nThe integration pathway with Peras remains an active area of research, focusing\non optimizing the interaction between Leios' enhanced throughput mechanisms and\nPeras' finality guarantees. Key considerations include synchronizing committee\nselection processes, coordinating voting mechanisms to avoid redundancy, and\nensuring that enhanced throughput periods align effectively with finality\ncheckpoints. This integration could provide both higher throughput and stronger\nfinality assurances than either protocol achieves independently.\n\n**Decoupling EB Production**\n\nIntroducing independent scheduling for Endorser Block production represents the\nfirst step toward concurrent block production. This approach separates EB\ncadence from Ranking Block timing through dedicated VRF lotteries or\ndeterministic schedules, providing greater flexibility in optimizing diffusion\ntimings and reducing censorship opportunities for stake-based attackers. While\nthis introduces potential conflicts between transactions in RBs and those\nendorsed in EBs, the enhanced scheduling flexibility enables better parameter\ntuning for diverse network conditions.\n\n**EBs Referencing EBs**\n\nBuilding chains of certified Endorser Blocks before anchoring them to the main\nchain enables more granular transaction processing and improved inclusion\nlatency. This approach allows multiple smaller EBs instead of monolithic blocks,\nreusing validation and voting work already performed while continuing\ntransaction processing during periods of poor chain quality. The shorter\npossible cadence particularly benefits scenarios with unfavorable RB sortition,\nproviding more consistent transaction inclusion opportunities.\n\n**Input Block Production**\n\nFull concurrent block production through Input Blocks represents the highest\nthroughput pathway but introduces significant complexity. This approach\nfront-loads validation and diffusion work across multiple concurrent streams,\nsubstantially increasing transaction conflict likelihood even under honest\noperation. Resolution mechanisms include accepting conflicts with fee collection\nfrom non-executed transactions, reducing conflict probability through ledger\nsharding or controlled IB production, and implementing reconciliation systems\nwith tombstoning to manage storage efficiency. While offering the greatest\nthroughput potential, this pathway requires careful analysis of economic\nincentives and conflict resolution trade-offs.\n\n## Path to active\n\n### Acceptance criteria\n\nThe proposal will be considered active once the following criteria are met:\n\n- [ ] Protocol performance validated through load tests in a representative\n      environment.\n- [ ] Required changes are documented in an implementation-independent way via\n      the\n      [Cardano blueprint](https://cardano-scaling.github.io/cardano-blueprint/)\n      including conformance tests.\n- [ ] Formal specification of the consensus and ledger changes is available.\n- [ ] ΔQSD model available for Leios parameter selection.\n- [ ] Community agreement on initial Leios protocol parameters.\n- [ ] A peer-reviewed implementation of a Leios-enabled node is available.\n- [ ] Successful operation with open participation in testnet environments over\n      several months.\n- [ ] Key infrastructure signaled readiness for Leios-enhanced throughput.\n- [ ] Hard-fork enabling Leios is successfully executed on mainnet.\n\n### Implementation plan\n\nKey steps on the roadmap to realize Leios, somewhat ordered but not sequential,\nare:\n\n- [x] Simulations to confirm general feasibility using a model of mainnet.\n- [x] Ecosystem impact analysis and establish a threat model.\n- [ ] Coordinate with related activities on other protocol enhancements\n      (Phalanx, Peras, Mithril).\n- [ ] Detailed node-level (as opposed to this protocol-level) technical\n      specification.\n- [ ] Complete ΔQSD analysis of new/changed network interactions.\n- [ ] [Complete formal protocol specification in Agda][linear-leios-formal-spec]\n      of ledger and consensus changes.\n- [ ] Create network prototypes and conduct large scale experiments.\n  - Load tests in a controlled topology\n  - Validate protocol parameters\n  - Stake- and network-based attacks\n- [ ] Develop node-level, but implementation-independent conformance test suites\n      (blueprint).\n- [ ] Create a public Leios-specific testnet with repeated load tests and\n      encourage dependant infrastructure updates.\n- [ ] Implement / integrate necessary changes to `cardano-node` and other node\n      implementations (this is big).\n- [ ] Audit protocol and implementation changes.\n- [ ] Align on node releases and hard-fork schedule to mature pre-releases\n      through preview and preprod testnets.\n\n## Versioning\n\nLeios changes the consensus algorithm used to create a valid chain on Cardano\nand thus requires a new major protocol version. As the block format will change,\na new ledger era is also required and\n[CIP-84](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0084)\napplies. A hard-fork event will enable Leios on the Cardano network and the\nusual mechanisms of governing a hard-fork will be employed.\n\n## References\n\n**Primary Documents**\n\n- **CPS-18: Greater transaction throughput** — [CPS-0018][cps-18]\n- **Ouroboros Leios: Design Goals and Concepts** — [Research Paper][leios-paper]\n\n**Leios Resources**\n\n- **Leios R&D website** — [leios.cardano-scaling.org][leios-website]\n- **Leios Discord channel** — [IOG Discord][leios-discord]\n- **Leios R&D repository** — [GitHub][leios-github]\n- **Leios formal specification** — [GitHub][leios-formal-spec]\n- **Leios Agda formal specification** — [Agda\n  specification][linear-leios-formal-spec]\n- **Leios cryptography prototype** — [GitHub][leioscrypto]\n\n**Technical Specifications**\n\n- **BLS certificates specification** — [Specification][bls-spec]\n- **BLS certificates benchmarks** — [Benchmarks][bls-benchmarks]\n- **Fait Accompli sortition** — [Specification][fait-accompli-sortition]\n\n**Technical Reports**\n\n- **Committee size and quorum requirement** -\n  [Analysis][committee-size-analysis]\n- **Threat model** — [Report #1][threat-model]\n- **Leios attack surface** — [Report #2][threat-model-report2]\n- **Node operating costs** — [Cost estimate][cost-estimate]\n- **Impact analysis** - [Impact][impact-analysis]\n\n**Related**\n\n- **CPS-0017** — [Settlement layer CPS][cps-17]\n- **Praos performance model** — [Specification][praos-performance]\n\n**Simulation Resources**\n\n- **Synthetic mainnet** — [Mainnet-like topologies for Leios][mainnet-topology]\n- **10k-node network** — [Leios pseudo-mainnet topology][pseudo-mainnet]\n- **750-node network** — [Leios mini-mainnet topology][mini-mainnet]\n- **Comparison of 10k-node and 750-node networks** — [Mainnet comparison\n  study][topology-comparison]\n- **Validation times** — [Analysis of mainnet transaction validation\n  times][timings]\n\n**External**\n\n- **RIPE Atlas** — [Network measurements][ripe-atlas]\n- **Ledger analyser tool** — [db-analyser][dbanalyser]\n- **UTXO-HD** — [Cardano Node 10.5.1][utxohd]\n- **SPO hardware requirements** — [Minimum hardware requirements to run a stake\n  pool][spohw]\n\n<!-- Reference Index - DO NOT REMOVE -->\n<!-- The following reference definitions enable consistent linking throughout the document -->\n\n<!-- Primary references -->\n\n[cps-18]:\n  https://github.com/cardano-foundation/CIPs/blob/master/CPS-0018/README.md\n  \"CPS-18: Greater transaction throughput\"\n[leios-paper]:\n  https://eprint.iacr.org/2025/1115.pdf\n  \"Ouroboros Leios: Design Goals and Concepts\"\n[fait-accompli-sortition]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/d5f1a9bc940e69f406c3e25c0d7d9aa58cf701f8/crypto-benchmarks.rs/Specification.md#sortition\n  \"Fait Accompli sortition specification\"\n\n<!-- Project resources -->\n\n[leios-website]: https://leios.cardano-scaling.org/ \"Leios R&D web site\"\n[leios-discord]:\n  https://discord.com/channels/826816523368005654/1247688618621927505\n  \"Leios channel on IOG Discord\"\n[leios-github]:\n  https://github.com/input-output-hk/ouroboros-leios\n  \"Github repository for Leios R&D\"\n[leios-formal-spec]:\n  https://github.com/input-output-hk/ouroboros-leios-formal-spec\n  \"Github repository for Leios formal specification\"\n[linear-leios-formal-spec]:\n  https://github.com/input-output-hk/ouroboros-leios-formal-spec/blob/V1.0/formal-spec/Leios/Linear.lagda.md\n  \"Leios formal specification in Agda\"\n[leios-formal-spec-empty-eb]:\n  https://github.com/input-output-hk/ouroboros-leios-formal-spec/blob/c7f8d61865360cd16e04c7c3f0fd481c8081deff/formal-spec/Leios/Linear.lagda.md#L135\n  \"Formal specification requirement: EndorserBlockOSig.txs eb ≢ []\"\n\n<!-- Technical specifications and benchmarks -->\n\n[bls-spec]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/d5f1a9bc940e69f406c3e25c0d7d9aa58cf701f8/crypto-benchmarks.rs/Specification.md\n  \"BLS certificates specification\"\n[bls-benchmarks]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/d5f1a9bc940e69f406c3e25c0d7d9aa58cf701f8/crypto-benchmarks.rs/Specification.md#benchmarks-in-rust\n  \"BLS certificates benchmarks\"\n\n<!-- Technical reports and documentation -->\n\n[committee-size-analysis]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/d5f1a9bc940e69f406c3e25c0d7d9aa58cf701f8/docs/technical-report-1.md#committee-size-and-quorum-requirement\n  \"Committee size and quorum requirement\"\n[threat-model]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/d5f1a9bc940e69f406c3e25c0d7d9aa58cf701f8/docs/technical-report-1.md#threat-model\n  \"Threat model\"\n[threat-model-report2]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/d5f1a9bc940e69f406c3e25c0d7d9aa58cf701f8/docs/technical-report-2.md#notes-on-the-leios-attack-surface\n  \"Comments on Leios attack surface\"\n[cost-estimate]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/d5f1a9bc940e69f406c3e25c0d7d9aa58cf701f8/docs/cost-estimate/README.md\n  \"Leios node operating costs\"\n[impact-analysis]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/4603cfd0b545cccf3d7c8fddc75e6e0f182f132a/docs/ImpactAnalysis.md\n  \"Impact Analysis\"\n\n<!-- Other protocol references -->\n\n[cps-17]:\n  https://github.com/cardano-scaling/CIPs/blob/settlement-cps/CPS-0017/README.md\n  \"CPS-0017\"\n[praos-performance]:\n  https://github.com/IntersectMBO/cardano-formal-specifications/blob/6d4e5cfc224a24972162e39a6017c273cea45321/src/performance/README.md\n  \"Praos performance model\"\n\n<!-- Simulation topology -->\n\n[mainnet-topology]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/6d8619c53cc619a25b52eac184e7f1ff3c31b597/data/simulation/pseudo-mainnet/ReadMe.md\n  \"Mainnet-like topology documentation\"\n[pseudo-mainnet]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/6d8619c53cc619a25b52eac184e7f1ff3c31b597/data/simulation/pseudo-mainnet/topology-v1.md\n  \"Pseudo-mainnet topology\"\n[mini-mainnet]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/6d8619c53cc619a25b52eac184e7f1ff3c31b597/data/simulation/pseudo-mainnet/topology-v2.md\n  \"Mini-mainnet topology\"\n[topology-comparison]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/6d8619c53cc619a25b52eac184e7f1ff3c31b597/analysis/sims/2025w30b/analysis.ipynb\n  \"Topology comparison study\"\n[praos-simulations]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/d5f1a9bc940e69f406c3e25c0d7d9aa58cf701f8/analysis/sims/2025w26/analysis-praos.ipynb\n[leioscrypto]:\n  https://github.com/input-output-hk/ouroboros-leios/tree/19990728e09fd1d863f888a494d1930b59e5a0d7/crypto-benchmarks.rs\n  \"Leios cryptography prototype implementation\"\n[timings]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/d5f1a9bc940e69f406c3e25c0d7d9aa58cf701f8/analysis/timings/ReadMe.ipynb\n  \"Analysis of mainnet transaction validation times\"\n\n<!-- External resources -->\n\n[ripe-atlas]: https://atlas.ripe.net/ \"RIPE Atlas\"\n[spohw]:\n  https://developers.cardano.org/docs/operate-a-stake-pool/hardware-requirements\n  \"Minimum hardware requirements to run a stake pool\"\n[utxohd]:\n  https://ouroboros-consensus.cardano.intersectmbo.org/docs/references/miscellaneous/utxo-hd/\n  \"UTXO-HD documentation\"\n[dbanalyser]:\n  https://github.com/IntersectMBO/ouroboros-consensus/blob/main/ouroboros-consensus-cardano/README.md#db-analyser\n  \"Cardano instantiation of the Consensus Layer: db-analyser\"\n[praos-delta-q]:\n  https://github.com/IntersectMBO/cardano-formal-specifications/tree/main?tab=readme-ov-file#performance-model\n  \"Praos performance model\"\n\n<!-- License -->\n\n[apache-2.0]: http://www.apache.org/licenses/LICENSE-2.0 \"Apache License 2.0\"\n\n<!-- Footnotes -->\n\n[^fasort]: The Fait Accompli sortition scheme\n\n[^2]: Leios: Dynamic Availability for Blockchain Sharding (2025)\n\n[^leioscrypto]: Leios cryptography prototype implementation\n\n[^profitability]:\n    Analysis documented in the\n    [Praos profitability notebook](https://github.com/input-output-hk/ouroboros-leios/blob/main/analysis/profitability-praos.ipynb)\n\n[praos-delta-q]:\n  https://github.com/IntersectMBO/cardano-formal-specifications/tree/main?tab=readme-ov-file#performance-model\n[praos-simulations]:\n  https://github.com/input-output-hk/ouroboros-leios/blob/d5f1a9bc940e69f406c3e25c0d7d9aa58cf701f8/analysis/sims/2025w26/analysis-praos.ipynb\n\n## Appendix\n\n<h3 id=\"appendix-a-requirements\">Appendix A: Requirements for votes and certificates</h3>\n\nThe voting and certificate scheme for Leios must satisfy the following\nrequirements to ensure security, efficiency, and practical deployability:\n\n1. **Succinct registration of keys:** The registration of voting keys should not\n   involve excessive data transfer or coordination between parties. Ideally,\n   such registration would occur as part of the already existing operational\n   certificates and not unduly increase their size.\n\n2. **Key rotation:** The cryptographic keys used to sign Leios votes and\n   certificates _do not_ need to be rotated periodically because the constraints\n   on Leios voting rounds and the key rotation already present in Praos secure\n   the protocol against attacks such as replay and key compromise.\n\n3. **Deterministic signatures:** While deterministic signatures can provide\n   additional protection against attacks that exploit weak randomness in\n   signature generation, they are not strictly required for protocol security.\n   The main requirement for deterministic randomness is in the lottery\n   mechanism, which is satisfied by the use of VRFs.\n\n4. **Local lottery:** Selection of the voting committee should not be so\n   deterministic and public as to open attack avenues such as denial-of-service\n   or subversion.\n\n5. **Liveness:** Adversaries with significant stake (e.g., more than 35%) should\n   not be able to thwart an honest majority from reaching a quorum of votes for\n   an EB.\n\n6. **Soundness:** Adversaries with near majority stake (e.g., 49%) should not be\n   able to form an adversarial quorum that certifies the EB of their choice.\n\n7. **Small votes:** Because vote traffic is large and frequent in Leios, the\n   votes themselves should be small. Note that the large size of Praos KES\n   signatures precludes their use for signing Leios votes.\n\n8. **Small certificates:** Because Leios certificates are frequent and must fit\n   inside Praos blocks, they should be small enough so there is plenty of room\n   for other transactions in the Praos blocks. Note once again that certificates\n   based on Praos KES signatures are too large for consideration in Leios.\n\n9. **Fast cryptography:** The computational burden of creating and verifying\n   voting eligibility, the votes themselves, and the resulting certificate must\n   be small enough to fit within the CPU budget for Leios stages.\n\nThe aggregate signature scheme implementation specified in this document (using\nBLS as an example) satisfies all these requirements, as evidenced by the\nperformance characteristics and certificate sizes documented in the\n[Votes and Certificates](#votes-and-certificates) section.\n\n<h3 id=\"appendix-b-cddl\">Appendix B: Wire Format Specifications (CDDL)</h3>\n\nThis appendix contains the complete CDDL specifications for all Leios protocol\nmessages and data structures. These definitions specify the exact wire format\nfor network communication. This appendix also defines the CDDL encodings for the\nBLS cryptographic objects (verification keys, signatures, and\nproofs-of-possession) used by Leios voting and certification.\n\n<a id=\"ranking-block-cddl\" href=\"#ranking-block-cddl\">**Ranking Block**</a>\n\n```diff\n ranking_block =\n   [ header                   : block_header\n   , transaction_bodies       : [* transaction_body]\n   , transaction_witness_sets : [* transaction_witness_set]\n   , auxiliary_data_set       : {* transaction_index => auxiliary_data}\n   , invalid_transactions     : [* transaction_index]\n+  , ? eb_certificate         : leios_certificate\n   ]\n\nblock_header =\n   [ header_body              : block_header_body\n   , body_signature           : kes_signature\n   ]\n\n block_header_body =\n   [ block_number             : uint\n   , slot                     : slot_no\n   , prev_hash                : hash32\n   , issuer_vkey              : vkey\n   , vrf_vkey                 : vrf_vkey\n   , vrf_result               : vrf_cert\n   , block_body_size          : uint\n   , block_body_hash          : hash32\n+  , ? ( announced_eb         : hash32\n+      , announced_eb_size    : uint32\n+      )\n+  , ? certified_eb           : bool\n   ]\n```\n\n<a id=\"endorser-block-cddl\" href=\"#endorser-block-cddl\">**Endorser Block**</a>\n\n```cddl\nendorser_block =\n  [ transaction_references   : omap<hash32, uint16>\n  ]\n\n; Ordered map type definition\n; An omap behaves like a map but preserves insertion order and prevents duplicate keys\n; This ensures deterministic serialization while maintaining transaction sequence\nomap<K, V> = {* K => V}  ; Order-preserving map with unique keys\n\n; Legacy reference structure (for documentation)\n; tx_reference =\n;   [ tx_hash                  : hash32     ; Hash of complete transaction bytes\n;   , tx_size                  : uint16     ; Transaction size in bytes\n;   ]\n```\n\n<a id=\"merged-block-cddl\" href=\"#merged-block-cddl\">**Merged Block**</a>\n\n```diff\n+ merged_block =\n+   [ header                   : block_header\n+   , transaction_bodies       : [* transaction_body]\n+   , transaction_witness_sets : [* transaction_witness_set]\n+   , auxiliary_data_set       : {* transaction_index => auxiliary_data}\n+   , ? eb_certificate         : leios_certificate\n+   , ? eb_tx_references       : [* tx_reference]\n+   ]\n\n+ block_header =\n+   [ header_body              : block_header_body\n+   , body_signature           : kes_signature\n+   ]\n\n+ block_header_body =\n+   [ block_number             : uint\n+   , slot                     : slot_no\n+   , prev_hash                : hash32\n+   , issuer_vkey              : vkey\n+   , vrf_vkey                 : vrf_vkey\n+   , vrf_result               : vrf_cert\n+   , block_body_size          : uint\n+   , block_body_hash          : hash32\n+   , ? ( announced_eb         : hash32\n+       , announced_eb_size    : uint32\n+       )\n+   , ? certified_eb           : bool\n+   ]\n\n+ ; Reference structures\n+ tx_reference =\n+  [ tx_hash                  : hash32     ; Hash of complete transaction bytes\n+  , tx_size                  : uint16     ; Transaction size in bytes\n+  ]\n```\n\n<a id=\"votes-certificates-cddl\" href=\"#votes-certificates-cddl\">**Votes and\nCertificates**</a>\n\n```cddl\nleios_certificate =\n  [ election_id              : election_id\n  , endorser_block_hash      : hash32\n  , persistent_voters        : [* persistent_voter_id]\n  , nonpersistent_voters     : {* pool_id => leios_bls_signature}\n  , aggregated_vote_sig      : leios_bls_signature\n  ]\n\nleios_vote = persistent_vote / non_persistent_vote\n\npersistent_vote =\n  [ 0\n  , election_id\n  , persistent_voter_id\n  , endorser_block_hash\n  , vote_signature : leios_bls_signature\n  ]\n\nnon_persistent_vote =\n  [ 1\n  , election_id\n  , pool_id\n  , eligibility_signature : leios_bls_signature\n  , endorser_block_hash\n  , vote_signature : leios_bls_signature\n  ]\n```\n\nLeios uses **BLS12-381 MinSig** (small signature, large verification key):\n\n- Verification key: compressed G2 = 96 bytes\n- Signature: compressed G1 = 48 bytes\n- Proof-of-possession: compressed G1 = 48 bytes\n\nMinSig is chosen because:\n\n- Certificate size is ~8 kB vs >12 kB for MinPk\n- Network propagation and storage are significantly improved\n\n```cddl\n; BLS12-381 MinSig encodings for Leios\nleios_bls_verification_key = bytes .size 96\nleios_bls_signature        = bytes .size 48\nleios_bls_pop              = bytes .size 96\n```\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0][apache-2.0].\n"
  },
  {
    "path": "CIP-0164/SUMMARY.md",
    "content": "# Ouroboros Leios Summary\n\n> [!NOTE]\n>\n> This summary provides a comprehensive overview of Ouroboros Leios. For the\n> complete technical specification, see [CIP-0164](README.md).\n\n## What is Ouroboros Leios?\n\nOuroboros Leios is a revolutionary consensus protocol designed to dramatically\nincrease Cardano's transaction throughput while maintaining the security\nguarantees of Ouroboros Praos. It's an optimistic protocol that operates\nalongside the existing Praos chain, enabling Cardano to support the transaction\nvolumes needed for long-term economic sustainability.\n\n## The problem it solves\n\nCardano's current throughput limitations pose a significant challenge as the\necosystem grows. With increasing transaction volumes and complex decentralized\napplications, the network needs a fundamental enhancement to accommodate future\ndemand without compromising security.\n\n## How It Works: The 5-Step Process\n\n### 1. **EB Proposal**\n\nWhen a stake pool wins slot leadership, it creates:\n\n- A standard **Ranking Block (RB)** - the normal Praos block\n- An optional **Endorser Block (EB)** - containing references to additional\n  transactions\n\n### 2. **EB Distribution**\n\nThe EB and its referenced transactions are rapidly distributed across the\nnetwork using optimized diffusion protocols.\n\n### 3. **Committee Validation**\n\nA randomly selected committee of stake pools validates the EB within a specific\nvoting period, ensuring network consensus.\n\n### 4. **Certification**\n\nIf enough committee members vote (≥75% threshold), the EB becomes certified and\nready for inclusion.\n\n### 5. **Chain Inclusion**\n\nCertified EBs are applied to the ledger just before their certifying RB, but the\nEB transactions themselves are not registered on-chain as separate blocks.\n\n## Key Characteristics\n\n### **Massive Throughput Increase**\n\n- Achieving 30-65x improvement over current mainnet (140-300 TxkB/s, equivalent\n  to ~100-200 TPS depending on average transaction sizes)\n- Each EB can reference significantly more transactions than standard blocks\n- Configurable via protocol parameters to optimize for different network\n  conditions\n- Simulations demonstrate substantial throughput improvements\n\n### **Opportunistic Inclusion**\n\n- Not all EBs get certified due to timing constraints\n- This ensures sufficient network diffusion periods for Praos security\n  guarantees\n- Balances throughput with security requirements\n\n### **Security Preservation**\n\n- Maintains all Praos security guarantees\n- Committee-based validation ensures network consensus\n- Careful timing constraints prevent security vulnerabilities\n\n## Economic Benefits\n\n### **Balanced Scalability**\n- increased transaction capacity with moderate increase in confirmation time (45-60 seconds)\n- Supports sustainable rewards as Reserve depletes, requiring ~36 TPS by 2029\n- Maintains economic sustainability\n- Minimal added complexity through few new protocol elements\n\n### **Future-Proof Design**\n\n- Designed to support Cardano's long-term growth\n- Configurable parameters allow adaptation to changing needs\n- Preserves existing economic incentives\n\n## Implementation Strategy\n\n### **Backward Compatibility**\n\n- Operates alongside existing Praos chain\n- No disruption to current network operations\n- Gradual rollout possible\n\n### **Protocol Parameters**\n\nThe system includes configurable parameters for:\n\n- **Timing parameters**: Control validation and diffusion periods\n- **Size parameters**: Determine EB capacity and committee sizes\n- **Security parameters**: Maintain safety guarantees\n\n## Research and Development\n\nThis specification presents the first version of the Ouroboros Leios protocol\nfamily. For comprehensive research documentation, development history, and\nadditional technical resources, visit the Leios Innovation R&D site at\n[leios.cardano-scaling.org](https://leios.cardano-scaling.org).\n\n## What's Next?\n\nOuroboros Leios represents a significant step forward in blockchain scalability.\nThe protocol is designed to:\n\n- Support Cardano's growing ecosystem\n- Enable complex decentralized applications\n- Maintain security and decentralization\n- Provide economic sustainability for long-term growth\n\n---\n\nRead the complete [CIP-0164 specification](README.md) for in-depth technical\ndocumentation, protocol artifacts, security analysis, and implementation\ndetails.\n"
  },
  {
    "path": "CIP-0165/README.md",
    "content": "---\nCIP: 165\nTitle: Canonical Ledger State\nCategory: Ledger\nStatus: Proposed\nAuthors:\n  - Nicholas Clarke <nicholas.clarke@moduscreate.com>\n  - Aleksandr Vershilov <alexander.vershilov@moduscreate.com>\n  - João Santos Reis <joao.reis@moduscreate.com>\n  - Christopher Harrison <christopher.harrison@moduscreate.com>\nImplementors:\n  - Nicholas Clarke <nicholas.clarke@moduscreate.com>\n  - Aleksandr Vershilov <alexander.vershilov@moduscreate.com>\n  - João Santos Reis <joao.reis@moduscreate.com>\n  - Christopher Harrison <christopher.harrison@moduscreate.com>\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/1083\nCreated: 2025-08-18\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis proposal defines the Standard Canonical Ledger State (SCLS), a stable, versioned, and verifiable file format for representing the Cardano ledger state. It specifies a segmented binary container with deterministic CBOR encodings, per-chunk commitments, and a manifest that enables identical snapshots across implementations, supports external tools (e.g., Mithril), and future-proofs distribution and verification of state.\n\nThis CIP specifies a canonical interchange format for the ledger state. It does not define, prescribe, or constrain the internal storage or representation of the ledger state within any node implementation. Internal formats remain an implementation detail; the canonical format applies only to the export, interchange, and verification of the ledger state consistency.\n\n## Motivation: why is this CIP necessary?\n\nLedger state serialisations are currently implementation details that may change over time. This makes them unsuitable as stable artifacts for distribution, signing, fast sync, or external tooling (e.g., db-sync, conformance testing, and Mithril checkpoints). Without a canonical format, two nodes at the same chain point can legitimately produce different byte streams for the same state, complicating verification and opening room for error in multi-implementation ecosystems.\n\nSCLS addresses these problems by:\n\n- specifying a canonical, language-agnostic container and encoding rules;\n- enabling streaming builds and data consistency validation (per-namespace roots);\n- being extensible (e.g., optional indexes/Bloom filters) without breaking compatibility;\n- supporting solutions that store updates in incremental (delta) formats (e.g. UTxO-HD/LSM).\n\nVersioning and Upgrade Complexity: the proposed format defines a solution that will be able to support future protocol extensions with new eras without changing this CIP. The chosen approach allows implementers to define a client that will be interested only in particular parts of the state, but will not prevent it from storing, loading and verifying the interesting parts of the state.\n\nThe concrete use-case scenarios for this CIP are:\n\n- allow building a dump of the Cardano Ledger node state in a canonical format, so any two nodes would generate the same file. This would allow persistence, faster bootstrap and verification.\n- such a state can be verified by another node against its own local state and independently signed. This enables full utilization of Mithril, as each node can sign the same state snapshot independently. To make this possible,\n- full conformance testing. Any implementation would be able to reuse the test-suite of the Haskell node by importing data applying the test transaction and exporting data back.\n\n## Specification\n\nThe Standard Canonical Ledger State (SCLS) is a segmented file format for Cardano ledger states, designed to support streaming and verifiability. Records are sequential, each tagged by type and independently verifiable by hash. Multi-byte values use network byte order (big-endian).\n\n### File Structure\n\n1. Sequence of records `(S, D)*` where `S` is a 32-bit size and `D` is the payload stored in typed record.\n1. Each payload begins with a one-byte type tag, defining its type.\n\nUnsupported record types are skipped; core data remains accessible.\n\n### Namespaces and Entries\n\nIn order to provide types of the values and be able to store and verify only partial state, a notion of namespaces is introduced. Each SCLS file may store values from one or more namespaces.\n\n#### Supported Namespaces\n\nEach logical table/type is a namespace identified by a canonical string (e.g., `\"utxo\"`, `\"gov\"`). Namespace identifiers are UTF-8 encoded; all comparisons and ordering use bytewise (lexicographic by Unicode codepoint) ordering on the UTF-8 byte representation.\n\n| Shortname           | Content                         |\n| ------------------- | ------------------------------- |\n| blocks/v0           | Blocks created                  |\n| gov/committee/v0    | Governance action state         |\n| gov/constitution/v0 | Constitution                    |\n| gov/pparams/v0      | Protocol parameters             |\n| gov/proposals/v0    | Update proposals                |\n| pool_stake/v0       | Stake delegation                |\n| nonce/v0            | Nonces                          |\n| snapshots/v0        | snapshots                       |\n| utxo/v0             | UTXOs                           |\n\nNew namespaces may and will be introduced in the future. With new eras and features, new types of the data will be introduced and stored. In order to define what data is stored in the SCLS file, tools fill the `MANIFEST` record and define namespaces. The order of the namespaces does not change the signatures and other integrity data.\n\n### Record Types\n\n| Code | Name     | Purpose                                                                       |\n| ---- | -------- | ----------------------------------------------------------------------------- |\n| 0x00 | HDR      | File header: magic, version, network, namespaces                              |\n| 0x01 | MANIFEST | Global commitments, chunk table, summary                                      |\n| 0x10 | CHUNK    | Ordered entries with per-chunk footer + hash                                  |\n| 0x11 | DELTA    | Incremental updates overlay (reserved for future)                             |\n| 0x20 | BLOOM    | Per-chunk Bloom filter (reserved for future)                                  |\n| 0x21 | INDEX    | Optional key→offset or value-hash indexes (reserved for future)               |\n| 0x30 | DIR      | Directory footer with offsets to metadata/index regions (reserved for future) |\n| 0x31 | META     | Opaque metadata entries (e.g., signatures, notes)                             |\n\nProposed file layout:\n\n```text\nHDR,\n(CHUNK[, BLOOM])*,\nMANIFEST,\n[INDEX]*,\n[META]*\n[DIR],\n[ (DELTA[, BLOOM])* , MANIFEST, [INDEX]*, [DIR] ]*\n```\n\nAt the first steps of implementation it would be enough to have the simpler structure:\n\n```text\nHDR,\n(CHUNK)*,\nMANIFEST\n```\n\nAll the other record types allow the introduction of additional features, like delta-states, querying data and may be omitted in case the user does not want those functionalities.\n\nFor the additional record types (all except `HDR, CHUNK, MANIFEST`) it's possible to keep such records outside of the file and build them iteratively, outside of the main dump process. This is especially useful for indices.\n\n#### HDR Record\n\n**Purpose:** identify file, version, and global properties.\n\n**Structure:**\n\n`REC_HDR` (once at start of file)\n\n- `magic` : `b\"SCLS\"`\n- `version` : `u16` (start with `1`)\n\n**Policy:**\n\n- appears once in the file header;\n- must be read and verified first;\n- supports magic bytes for file recognition.\n\n#### CHUNK Record\n\n**Purpose:** group entries for streaming and integrity; maintain global canonical order, see namespace and entries for more details.\n\n**Structure:**\n\n- `chunk_seq` : `u64` — sequence number of the record\n- `chunk_format` : `u8` - format of the chunks, indicating compression scheme (see data compression table below)\n- `namespace` : `bstr` — namespace of the values stored in the CHUNK\n- `entries` : `DataEntry` — list of length-prefixed data entries\n- `footer {entries_count: u32, chunk_hash: blake28}` — hash value of the chunk of data, is used to keep integrity of the file.\n\n`DataEntry` is a blob of a key-valued data. The structure of the `DataEntry` is the following:\n\n- `size` : `u32` - size of the data\n- `key` : `fixed size` - key is a fixed size blob where size depends on the namespace\n- `value` : `bstr` — cbor data entry\n\nWhile the format requires each entry to have a key, it's still possible to support hierarchical structures, either by normalizing them\nand keeping a path or hash as a key or by introducing an artificial key and keeping the entire hierarchy in a single key. The choice depends on each\nnamespace. If there are ways to express and support updating of a part of the tree, it is worth normalizing the tree. If the data is kept\nand updated as a whole, a single artificial key can be used.\n\n**Policy:**\n\n- chunk size \\~8–16MiB; footer required;\n- data is stored in deterministically defined global order; in the lexical order of the keys;\n- all keys in the record must be unique;\n- all key-values in the record must refer to the same namespace;\n- `CHUNK` records are ordered by namespace using bytewise (UTF-8 lexicographic) ordering; all `CHUNK` records for a given namespace appear consecutively and before any `CHUNK` records for a namespace that sorts later;\n- within a namespace, all keys in `CHUNK` `n` must be lexicographically lower than all keys in `CHUNK` `n+1`;\n- readers should verify footer before relying on the data;\n- `chunk_hash = H(concat [ digest(e) | e in entries ])`;\n\nThe format proposes support of data compression. For future-compatibility the format is described by the `chunk_format` field, and following variants are introduced:\n\n| Code | Name  | Description                                   |\n| ---- | ----- | --------------------------------------------- |\n| 0x00 | RAW   | Raw CBOR Entries                              |\n| 0x01 | ZSTD  | All entries are compressed with seekable zstd |\n| 0x02 | ZSTDE | Compress each value independently             |\n\nWhen calculating and verifying hashes, its built over the uncompressed data.\n\n#### MANIFEST Record\n\n**Purpose:** index of chunks and information for file integrity check.\n\n**Structure:**\n\n- `slot_no` : `u64` identifier of the blockchain point (slot number).\n- `total_entries`: `u64` — number of data entries in the file (integrity purpose only)\n- `total_chunks`: `u64` — number of chunks in the file (integrity purpose only)\n- `root_hash`: `Digest` - **global Merkle root**, computed over the per-namespace Merkle roots in lexicographic namespace order (see [Verification](#verification) section for details)\n- `namespace_info`: a list of `{ entries_count, chunks_count, name, digest }` for each namespace in the file, where:\n  - `entries_count`: `u64` — number of entries in the namespace\n  - `chunks_count`: `u64` — number of chunks for the namespace\n  - `name`: `bstr` — namespace name\n  - `digest`: `Digest` - Merkle root of all `entry_e` in the namespace\n- `prev_manifest`: `u64` — offset of the previous manifest (used with delta files), zero if there is no previous manifest entry\n- `summary`: `{ created_at, tool, comment? }`\n\n`Digest` is defined as a fixed-size 224-bit (28-byte) Blake2b hash.\n\n**Policy:** used to verify all the chunks.\n\n#### DELTA Record\n\nDelta records are reserved for future use, where the node wishes to incrementally update an existing CLS file rather than writing a new one.\n\n**Purpose:** Delta records are used to build iterative updates when a base format has been created and we want to store additional transactions efficiently. Delta records are designed to be compatible with UTxO-HD, LSM-Tree, or other storage types where it is possible to stream a list of updates. This means that instead of serializing the entire ledger state, a node may only need to store a list of entry changes.\n\nUpdating the file in place is unsafe, so instead we store a list of updates, i.e. removed and inserted items.\n\nAll updates are written in the following way:\n\n- to update a value, a new entry with the same key should be stored;\n- to remove a value, a special tombstone entry for the key should be stored.\n\n**Structure:**\n\n- `namespace:` `bstr` — namespace name\n- `changes:` `CBOR` — array of the entries, either tombstone entry or value entry\n- `footer:` `{entries_count, chunk_hash}`\n\n**Policy:**\n\n- chunk size \\~8–16MiB; footer required;\n- reader should verify hash before relying on data;\n- dead entries are marked by the special tombstone entry;\n- there must be only one element for the given key in the delta record.\n\nEach set of DELTA records are followed by the MANIFEST slot, that keeps the information about the current slot and state.\n\n#### BLOOM Record\n\nBloom record is reserved for the future use, in case if search in the file will be required by the downstream.\n\n**Purpose:** additional information for allowing fast search and negative search.\n\n**Structure:**\n\n- `chunk_seq: u64` sequence number of the record.\n- `m`: `u32` - total number of bits in the Bloom filter’s bitset (the length of the bit array).\n- `k`: `u8` - number of independent hash functions used to map a key into bit positions in that array.\n- `bitset`: `bytes[ceil(m/8)]` — actual bitset.\n\n#### INDEX Record\n\nIndex record is reserved for future use, in case a search in the file will be required by downstream.\n\n**Purpose:** allows fast search based on the value of the entries.\n\nThe general idea is that we may want to write a query to the raw data using common format like `json-path` but that will run against CBOR. In this case while building we may build an index. Later queries can use indexes instead of direct traversal.\n\n**Policy:**\n\n- Indices are completely optional and do not change the hash of the entries in data.\n\n#### DIR Record\n\nDirectory record is reserved for the future use, in case if index records or delta records will be implemented.\n\n**Purpose**: If a file has index records then they will be stored after the records with actual data, and directory record allow a fast way to find them. Directory record is intended to be the last record of the file and has a fixed size footer.\n\n**Structure:**\n\n- `metadata_offset:` `u64` offset of the previous metadata record, zero if there is no record\n- `index_offset:` `u64` offset of the last index record, zero if there is no record\n\n#### META Record\n\n**Purpose:** record with extra metadata that can be used to store 3rd party data, like signatures for Mithril, metadata information. This is an additional record that may be required for additional scenarios.\n\n**Structure:**\n\n- `entries: Entry[]` list of metadata entries, stored in lexicographical order\n- `footer: {entries_count: u64, entries_hash}`\n\nEntry:\n\n- `subject: URI` — subject stored in the `URI` format\n- `value: cbor` — data stored by the metadata entry owner.\n\n**Policy:**\n\n- Meta chunks are completely optional and do not change the hash of the entries in data.\n- `entries_hash = H(concat (digest e for e in entries))`\n\n### Entries\n\nData is stored in the list of `Entries`, each entry consist of the namespace and its data:\n\n- `size` : `u32` — length of the entry, stored in big endian;\n- `key` : `bstr` - CBOR-encoded string key;\n- `dom` : `bstr` – CBOR-encoded data (canonical form).\n\n`size` is used in a fast search scenario, this way its possible to skip values without interpretation.\n\nThe exact definition of the domain data is left out in this CIP. We propose that the ledger team would propose a canonical representation for the types in each new era. For the types they must be in a canonical [CBOR format](https://datatracker.ietf.org/doc/html/rfc8949) with restrictions from [deterministic cbor](https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor). Values must not be derivable, that is, if some part of the state can be computed based on another part, then only the base one should be in the state.\"\n\nAll concrete formats should be stored in an attachment to this CIP and stored in `namespaces/{namespace}.cddl` for each namespace. All the changes should be introduced using current CIP update process.\n\n### Canonicalization Rules\n\n- CBOR maps must be deterministic with sorted keys and no duplicates.\n- Numbers use minimal encoding.\n- Arrays follow a fixed order.\n\n### Verification\n\nManifest stores an overall global root and per-namespace commitments. Verification uses a two-level Merkle structure: each namespace has its own Merkle tree built over its entries, and the global Merkle tree is then built over the per-namespace roots, not directly over entries.\n\n#### Per-namespace Merkle trees\n\nFor each namespace, a Merkle tree is constructed over all live entry digests in canonical key order; tombstones are excluded, last-writer-wins for overlays.\n\nThe digest of each entry (the leaf hash), defined as a `(key,value)` pair for a namespace `ns_str`, is `H(0x01 || ns_str || key || value)`, where `H` is Blake2b-224 and `ns_str` is the UTF-8 encoded namespace name. Internal nodes are hashed as `H(0x00 || left || right)`. The `0x00` and `0x01` domain separators make leaf and internal-node hashes structurally distinct, preventing second pre-image attacks.\n\nThe Merkle tree is unbalanced. During construction, entries are inserted in canonical order; whenever two subtrees at the same depth exist they are immediately merged into a node one depth up. On finalization, any remaining trailing subtrees are processed from shallowest to deepest: a trailing subtree whose depth is lower than its successor's is promoted -- its depth counter is incremented with its hash left unchanged -- until the depths match, at which point they are merged with `H(0x00 || left || right)`. This repeats until a single root digest remains.\n\nAn empty namespace (zero entries) produces `H(\"\")` as its root.\n\nBasic chunks store all the values in canonical key order; the namespace Merkle tree is built over all values in this order.\n\nThe rule of thumb is that when we calculate a hash of the data we take into account only the live (non deleted) values in canonical order. In the case when there is a single dump without delta records, this is exactly the order of how values are stored. But when delta—records appear we need to take into account that in the following records there may be values that are smaller than the ones in the base and some values may be deleted or updated. As a result writer should calculate a live-set of values, which can be done by running a streaming multi-merge algorithm (when we search for a minimal value from multiple records). In the case a value exists in multiple records we use a last—writer—wins rule. If there is a tombstone, we consider a value deleted and do not include it in a live-set.\n\n#### Global Merkle tree\n\nThe global Merkle tree is constructed from the per-namespace Merkle roots, not from entries directly. Namespace roots are taken in lexicographic (bytewise UTF-8) order of namespace name. Each namespace root is a leaf with digest `H(0x01 || namespace_root)`, where `namespace_root` is the 28-byte per-namespace Merkle root. (Note that the namespace name is _not_ included in the global tree leaf hash, unlike the entry hashes.) Internal nodes are formed identically to the per-namespace trees: `H(0x00 || left || right)` with the same unbalanced finalization procedure.\n\nAn empty file (no namespaces) produces `H(\"\")` as the global root.\n\n### Extensibility\n\n- Unknown fields in `HDR` or unknown chunk types can be skipped by readers.\n- Allows future extension (e.g., index chunks, metadata) without breaking compatibility.\n\n## Rationale: How does this CIP achieve its goals?\n\nThis CIP achieves its goals by:\n\n1. Define a canonical format that has the following properties: the format is very simple, it would be easy to write an implementation in any language.\n2. The format is extensible and agnostic, it provides a versioned format that simplifies ledger evolution.\n3. Removes ambiguity, allows signed checkpoints, and improves auditability\n\nFormat defines canonical format and ordering for the stored data, thus allowing reproducible and verifiable hashing of the data. It supports Mithril and fast node bootstrap use cases.\n\n### Prior Work and Alternatives\n\n#### Global alternatives:\n\n- **CIP PR #9 by Jean-Philippe Raynaud**:\nthe CIP that discusses the state and integration with Mithril a lot. Without much details CIP discusses immutable db and indices. Current CIP discussing adding indices as well, we believe that we can combine the approaches from the [work](https://github.com/cardano-scaling/CIPs/pull/9) and related work with our own and use the best of both words.\n\n- **CIP draft by Paul Clark**:\nthis was an early work of the CIP of the canonical ledger state. The work was more targeted towards what is stored in the files. Proposal also uses deterministic CBOR (canonical CBOR in this CIP). The proposal opens a discussion and rules about how and when snapshots should be created by the nodes, that is deliberately not discussed in the current CIP, as we do not want to impose restrictions on the nodes, and the format allow the nodes not to have any agreement on those rules. As a solution for extensibility and partiality the CIP proposes using a file per \"namespace\" (in the terminology of the current CIP), in our work we proposed to have a single chunked file that is more friendly for the producer. Currently we are considering at least to have an option for extracting multi-files version. See discussion in open questions.\n\n- **Do Nothing**: rejected due to interoperability and Mithril requirements.\n\n#### Implementation alternatives\n\n##### Container format\n\nMore common container file formats: many container formats were evaluated, but most implementations do not meet all the required properties. The container format closest to the required properties are CARv2 and gitpack-files, but they are more complex and would require additional tooling and language support for all node implementations. For simplicity and ease of adoption, a straightforward binary format was chosen. It's still possible to express the current approach in both CARv2 and gitpack files, if it will be shown that the approach is superior.\n\n##### Data encoding\n\n- **gRPC**: current Haskell node is using CBOR-based ecosystem, so nodes have to support CBOR anyway. In contrast to self-describing CBOR, gRPC requires schema to read the document, and that may be a problem for future compatibility.\n- **Plain CBOR stream**: easier decoding, but prevents skipping unwanted chunks needed for filtering and additional properties, like querying the data in the file.\n\n**JSON vs CBOR for Canonical Ledger State**\n\nThere are strong reasons to prefer CBOR over JSON for representing the canonical ledger state. The ledger state is large and contains binary data; a binary format is therefore much more compact and efficient than JSON.\n\nWhile JSON libraries are widely available in nearly every language, JSON lacks a notion of canonical form. Two JSON serializations of the same object are not guaranteed to be byte-identical, so additional tooling and specification would be required to achieve determinism.\n\nBy contrast, CBOR has a defined deterministic encoding (see [RFC 8949](https://datatracker.ietf.org/doc/html/rfc8949#section-4.2) and [restrictions](https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor)), making it suitable for a canonical format. CBOR also has mature implementations across many programming languages (list [here](https://cbor.io/impls.html)).\n\nImportantly, RFC 8949 also defines a mapping between CBOR and JSON. This allows us to specify a JSON view of the format so that downstream applications can consume the data using standard JSON tooling, while the canonical form remains CBOR.\n\n##### Multi-file or single file?\n\nWe considered using single file because it's more friendly to the producer, because it's possible to ensure required atomicity and durability properties, together with footers-in records, it's possible to validate that the data was actually written and is correct. In case of failure it's possible to find out exactly the place where the failure happened.\n\nHowever, we agree that for the consumer who wants to get partial states in will be much simpler to use multiple files.\n\nThe proposed SCLS format does not contradict having multiple files, on the contrary for things like additional indices we suggest using additional files, it will work as the records have sequential numbers and we can reconstruct full file and have an order. In this proposal we would file to set an additional constraint of the tooling that will come with the libraries: that the tool should be able to generate multi-files on a request and convert formats between those\n\n##### Should files be byte-identical?\n\nCurrent approach does not provide byte-identical files, only the domain data that is stored and it's hashes are canonical. It means that tools like Mithril will have to use additional tooling or recalculate hash on their own. It's done for the purpose, this way software may add additional metadata entries, e.g. Mithril can add its own signatures to the file without violating validation properties. Other implementation may add records that are required for them to operate or bootstrap. It's true that other [approaches](https://hackmd.io/Q9eSEMYESICI9c4siTnEfw), does solve that issue by creating multiple files, each of them will be byte-identical.\n\nThere are few solutions that we propose:\n\n1. allow tooling to export (or even generate) raw cbor files, that will have required byte-identical property\n2. set additional restrictions on the policies for the records, and instead of defining variable size records require all the records to have exact number of entries inside. It will harm some properties of the hardware but the files will be byte-identical in case if they have similar metadata. Or the metadata we can place it in separate file, then everything will be byte-identical.\n\n## Open Questions\n\n**What is the exact implementation for data compression, especially for indexing and search?**\n\nThere are many ways to write indices, hashtables or btrees, each of them may have interesting\nproperties. It's an open question which of them do we want to support.\n\n**Do we want the file be optimized for querying with external tools? If so how to achieve that?**\n\nWe are proposing adding additional records types:\n\n- bloom records — they would allow faster search of the values by the key, still require file traversal;\n- index records - it would allow faster search by key without full file traversal.\n\nBoth changes will not change the structure of the file.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] Expert review and consensus from Ledger Committee, IOG, and Node teams.\n- [ ] Reference implementation in Cardano node with CLI tool for export/import.\n- [ ] Verified test vectors showing identical output across implementations, including Mithril compatibility.\n- [ ] Full documentation and CDDL schemas.\n\n### Implementation Plan\n\n1. [ ] Prototype SCLS writer/reader.\n1. [ ] Refine specification and finalise CDDL.\n1. [ ] Integrate into Cardano node CLI.\n1. [ ] Validate with Mithril.\n1. [ ] Rollout and ecosystem tooling.\n\n## References\n\n1. [CARv2 format documentation](https://ipld.io/specs/transport/car/carv2/)\n1. [Draft Canonical ledger state snapshot and immutable data formats CIP](https://github.com/cardano-scaling/CIPs/pull/9)\n1. [Mithril](https://docs.cardano.org/developer-resources/scalability-solutions/mithril)\n1. [Canonical ledger state CIP draft by Paul Clark](https://hackmd.io/Q9eSEMYESICI9c4siTnEfw)\n1. [Deterministically Encoded CBOR in CBOR RFC](https://datatracker.ietf.org/doc/html/rfc8949#section-4.2)\n1. [A Deterministic CBOR Application Profile](https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor)\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/).\n"
  },
  {
    "path": "CIP-0165/format/format.ksy",
    "content": "meta:\n  id: scls_file\n  title: Container for the cardano ledger state\n  file-extension: scls\n  ks-version: 0.9\n  endian: be\n\ndoc: |\n  A seekable, versioned container for CBOR payloads whose structure is defined\n  by an external CDDL schema.\n\nseq:\n  - id: record\n    type: scls_record\n    doc: Typed records with data\n    repeat: eos\n\ntypes:\n  scls_record:\n    seq:\n      - id: len_payload\n        type: u4\n        doc: Size of the record, including size and record type\n      - id: payload\n        type: scls_record_data\n        doc: payload of the record\n        size: len_payload\n  scls_record_data:\n    seq:\n      - id: record_type\n        type: u1\n        doc: Type of the record\n      - id: record_data\n        doc: Record payload\n        # size: _parent.len_payload - sizeof<record_type>\n        size-eos: true\n        type:\n          switch-on: record_type\n          cases:\n            0x00: rec_header\n            0x01: rec_manifest\n            0x10: rec_chunk\n            0x31: rec_metadata\n  rec_header:\n    doc: Header record\n    seq:\n      - id: magic\n        contents: SCLS\n        doc: Magic bytes \"SCLS\"\n      - id: version\n        type: u4\n        doc: Version of the file format\n  rec_manifest:\n    doc: Manifest — is a trailer in the file that describes information of about the file contents\n    seq:\n      - id: slot_no\n        type: u8\n        doc: Slot number that this manifest refers to\n      - id: total_entries\n        type: u8\n        doc: total amount of entries in the file\n      - id: total_chunks\n        type: u8\n        doc: total amount of chunks in the file\n      - id: summary\n        type: summary\n        doc: information about the file\n      - id: namespace_info\n        type: namespace_info\n        repeat: until\n        repeat-until: _.len_ns == 0\n        doc: information about the namespaces\n      - id: prev_manifest\n        type: u8\n        doc: absolute offset of the previous manifest, zero if there is no\n      - id: root_hash\n        type: digest\n        doc: merkle tree root of the live entries\n      - id: offset\n        type: u4\n        doc: relative offset to the beginning of this record (this can be used to find the manifest by reading the last 4 bytes of the file)\n  rec_chunk:\n    doc: Chunk - is a record with data\n    seq:\n      - id: seqno\n        type: u8\n        doc: Sequential number of the chunk\n      - id: format\n        type: u1\n        enum: chunk_format\n      - id: len_ns\n        type: u4\n        doc: size of the namespace\n      - id: ns\n        type: str\n        encoding: UTF-8\n        doc: namespace name\n        size: len_ns\n      - id: len_key\n        type: u4\n        doc: key size for this namespace\n      - id: data\n        type: entries_record(len_key)\n        size: len_data                # substream; entries parse to EOS here\n        doc: payload parsed as entries\n      - id: entries_count\n        type: u4\n        doc: Number of entries in the chunk\n      - id: digest\n        type: digest\n        doc: blake28 hash of the entries in the record\n    instances:\n      # size of record_data for this scls_record (total - record_type:u1)\n      rec_payload_size:\n        value: _parent._parent.len_payload - 1\n      ns_size:\n        value: 4 + len_ns\n      len_data:\n        value: rec_payload_size - (8 + 1 + ns_size + 4 + 28 + 4)\n        doc: seqno=8, format=1, entries_count=4, digest=28, 4=len_key.\n  rec_metadata:\n    doc: Metadata record containing URI-indexed entries with CBOR-encoded values\n    seq:\n      - id: data\n        type: entries_metadata_record\n        doc: payload parsed as entries\n        size: len_data\n      - id: footer\n        type: metadata_footer\n    instances:\n      # size of record_data for this scls_record (total - record_type:u1)\n      rec_payload_size:\n        value: _parent._parent.len_payload - 1\n      len_data:\n        value: rec_payload_size - sizeof<metadata_footer>\n        doc: entries_count=8, digest=28.\n  entries_record:\n    params:\n      - id: len_key\n        type: u2\n    seq:\n      - id: entries\n        type: entry(len_key)\n        repeat: eos\n  entry:\n    params:\n      - id: len_key\n        type: u2\n    seq:\n      - id: len_body\n        type: u4\n      - id: body\n        type: entry_body(len_key)\n        size: len_body\n  entry_body:\n    doc: Body of the entry with the key of the fixes size, that depends on the namespace\n    params:\n      - id: len_key\n        type: u2\n    seq:\n      - id: key\n        doc: fixed size key\n        size: len_key\n      - id: value\n        doc: cbor encoded entry\n        size-eos: true\n  summary:\n    doc: Summary\n    seq:\n       - id: created_at\n         doc: absolute timestamp when file was generated in ISO8601 format\n         type: tstr\n       - id: tool_bytes\n         doc: name of the tool that has generated the file\n         type: tstr\n       - id: comment\n         doc: optional comment\n         type: tstr\n  namespace_info:\n    seq:\n      - id: len_ns\n        type: u4\n      - id: ns_info\n        type: ns_info\n        if: len_ns != 0\n  ns_info:\n    seq:\n      - id: entries_count\n        type: u8\n        doc: number of entries in the namespace\n      - id: chunks_count\n        type: u8\n        doc: number of chunks in the namespace\n      - id: name\n        type: str\n        size: _parent.len_ns\n        doc: namespace name\n        encoding: UTF-8\n      - id: digest\n        doc: merkle-tree hash of the alive entries in the namespace\n        type: digest\n  tstr:\n    seq:\n      - id: len_data\n        type: u4\n        doc: size of the string\n      - id: data\n        type: str\n        encoding: UTF-8\n        doc: value of the string\n        size: len_data\n  digest:\n    doc: Digest of the data\n    seq:\n      - id: data\n        doc: blake28 hash of data\n        size: 28\n  entries_metadata_record:\n    seq:\n      - id: entries\n        type: entry_metadata\n        repeat: eos\n  entry_metadata:\n    seq:\n      - id: len_subject\n        type: u4\n      - id: subject\n        size: len_subject\n        doc: subject of entry (URI)\n      - id: len_value\n        type: u4\n      - id: value\n        size: len_value\n        doc: cbor encoded value\n  metadata_footer:\n    doc: Metadata footer with entry count and digest\n    seq:\n      - id: entries_count\n        type: u8\n        doc: Number of entries in the record\n      - id: digest\n        type: digest\n        doc: blake28 hash of the entries in the record\nenums:\n  chunk_format:\n    0: raw\n    1: zstd\n    2: zstde\n"
  },
  {
    "path": "CIP-0165/format/scls_file.html",
    "content": "\n<!doctype html>\n<html lang=\"en\">\n  <head>\n    <!-- Required meta tags -->\n    <meta charset=\"utf-8\">\n    <meta name=\"viewport\" content=\"width=device-width, initial-scale=1, shrink-to-fit=no\">\n\n    <!-- Bootstrap CSS -->\n    <link rel=\"stylesheet\" href=\"https://stackpath.bootstrapcdn.com/bootstrap/4.2.1/css/bootstrap.min.css\" integrity=\"sha384-GJzZqFGwb1QTTN6wy59ffF1BuGJpLSa9DkKMp0DgiMDm4iYMj70gZWKYbI706tWS\" crossorigin=\"anonymous\">\n\n    <title>SclsFile format specification</title>\n  </head>\n  <body>\n           <div class=\"container\">\n  <h1>SclsFile format specification</h1>\n\n      \n<a name='type-scls_file'></a>\n<h1>Type: SclsFile</h1>\n\n<p>A seekable, versioned container for CBOR payloads whose structure is defined\nby an external CDDL schema.\n</p>\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>record</td>\n<td><a href=\"#type-scls_file-scls_record\">SclsRecord</a></td>\n<td>Typed records with data</td>\n</tr>\n</table>\n<a name='enum-scls_file-chunk_format'></a>\n<h2>Enum: chunk_format</h2>\n\n<table class=\"table\">\n<tr>\n<th>ID</th><th>Name</th><th>Note</th>\n</tr>\n<tr>\n<td>0</td><td>raw</td><td></td></tr>\n</tr>\n<tr>\n<td>1</td><td>zstd</td><td></td></tr>\n</tr>\n<tr>\n<td>2</td><td>zstde</td><td></td></tr>\n</tr>\n</table>\n<a name='enum-scls_file-network_id'></a>\n<h2>Enum: network_id</h2>\n\n<table class=\"table\">\n<tr>\n<th>ID</th><th>Name</th><th>Note</th>\n</tr>\n<tr>\n<td>0</td><td>mainnet</td><td></td></tr>\n</tr>\n<tr>\n<td>1</td><td>testnet</td><td></td></tr>\n</tr>\n</table>\n<a name='type-scls_file-digest'></a>\n<h2>Type: Digest</h2>\n\n<p>Digest of the data</p>\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>data</td>\n<td></td>\n<td>blake28 hash of data</td>\n</tr>\n</table>\n<a name='type-scls_file-entries_metadata_record'></a>\n<h2>Type: EntriesMetadataRecord</h2>\n\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>entries</td>\n<td><a href=\"#type-scls_file-entry_metadata\">EntryMetadata</a></td>\n<td></td>\n</tr>\n</table>\n<a name='type-scls_file-entries_record'></a>\n<h2>Type: EntriesRecord</h2>\n\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>entries</td>\n<td><a href=\"#type-scls_file-entry\">Entry</a></td>\n<td></td>\n</tr>\n</table>\n<a name='type-scls_file-entry'></a>\n<h2>Type: Entry</h2>\n\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>len_body</td>\n<td>u4be</td>\n<td></td>\n</tr>\n<tr>\n<td>4</td>\n<td>...</td>\n<td>body</td>\n<td><a href=\"#type-scls_file-entry_body\">EntryBody</a></td>\n<td></td>\n</tr>\n</table>\n<a name='type-scls_file-entry_body'></a>\n<h2>Type: EntryBody</h2>\n\n<p>Body of the entry with the key of the fixes size, that depends on the namespace</p>\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>key</td>\n<td></td>\n<td>fixed size key</td>\n</tr>\n<tr>\n<td>???</td>\n<td>...</td>\n<td>value</td>\n<td></td>\n<td>cbor encoded entry</td>\n</tr>\n</table>\n<a name='type-scls_file-entry_metadata'></a>\n<h2>Type: EntryMetadata</h2>\n\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>len_subject</td>\n<td>u4be</td>\n<td></td>\n</tr>\n<tr>\n<td>4</td>\n<td>...</td>\n<td>subject</td>\n<td></td>\n<td>subject of entry (URI)</td>\n</tr>\n<tr>\n<td>???</td>\n<td>...</td>\n<td>len_value</td>\n<td>u4be</td>\n<td></td>\n</tr>\n<tr>\n<td>???</td>\n<td>...</td>\n<td>value</td>\n<td></td>\n<td>cbor encoded value</td>\n</tr>\n</table>\n<a name='type-scls_file-metadata_footer'></a>\n<h2>Type: MetadataFooter</h2>\n\n<p>Metadata footer with entry count and digest</p>\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>entries_count</td>\n<td>u8be</td>\n<td>Number of entries in the record</td>\n</tr>\n<tr>\n<td>8</td>\n<td>...</td>\n<td>digest</td>\n<td><a href=\"#type-scls_file-digest\">Digest</a></td>\n<td>blake28 hash of the entries in the record</td>\n</tr>\n</table>\n<a name='type-scls_file-namespace_info'></a>\n<h2>Type: NamespaceInfo</h2>\n\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>len_ns</td>\n<td>u4be</td>\n<td></td>\n</tr>\n<tr>\n<td>4</td>\n<td>...</td>\n<td>ns_info</td>\n<td><a href=\"#type-scls_file-ns_info\">NsInfo</a></td>\n<td></td>\n</tr>\n</table>\n<a name='type-scls_file-ns_info'></a>\n<h2>Type: NsInfo</h2>\n\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>entries_count</td>\n<td>u8be</td>\n<td>number of entries in the namespace</td>\n</tr>\n<tr>\n<td>8</td>\n<td>...</td>\n<td>chunks_count</td>\n<td>u8be</td>\n<td>number of chunks in the namespace</td>\n</tr>\n<tr>\n<td>16</td>\n<td>...</td>\n<td>name</td>\n<td>str(UTF-8)</td>\n<td>namespace name</td>\n</tr>\n<tr>\n<td>???</td>\n<td>...</td>\n<td>digest</td>\n<td><a href=\"#type-scls_file-digest\">Digest</a></td>\n<td>merkle-tree hash of the alive entries in the namespace</td>\n</tr>\n</table>\n<a name='type-scls_file-rec_chunk'></a>\n<h2>Type: RecChunk</h2>\n\n<p>Chunk - is a record with data</p>\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>seqno</td>\n<td>u8be</td>\n<td>Sequential number of the chunk</td>\n</tr>\n<tr>\n<td>8</td>\n<td>...</td>\n<td>format</td>\n<td>u1→ChunkFormat</td>\n<td></td>\n</tr>\n<tr>\n<td>9</td>\n<td>...</td>\n<td>len_ns</td>\n<td>u4be</td>\n<td>size of the namespace</td>\n</tr>\n<tr>\n<td>13</td>\n<td>...</td>\n<td>ns</td>\n<td>str(UTF-8)</td>\n<td>namespace name</td>\n</tr>\n<tr>\n<td>???</td>\n<td>...</td>\n<td>data</td>\n<td><a href=\"#type-scls_file-entries_record\">EntriesRecord</a></td>\n<td>payload parsed as entries</td>\n</tr>\n<tr>\n<td>???</td>\n<td>...</td>\n<td>entries_count</td>\n<td>u4be</td>\n<td>Number of entries in the chunk</td>\n</tr>\n<tr>\n<td>???</td>\n<td>...</td>\n<td>digest</td>\n<td><a href=\"#type-scls_file-digest\">Digest</a></td>\n<td>blake28 hash of the entries in the record</td>\n</tr>\n</table>\nvalue instance: ValueInstanceSpec(InstanceIdentifier(len_data),List(types, rec_chunk, instances, len_data),BinOp(Name(identifier(rec_payload_size)),Sub,BinOp(BinOp(BinOp(BinOp(IntNum(8),Add,IntNum(1)),Add,Name(identifier(ns_size))),Add,IntNum(4)),Add,IntNum(28))),None,Some(CalcIntType),DocSpec(Some(seqno=8, format=1, entries_count=4, digest=28.),List()))\nvalue instance: ValueInstanceSpec(InstanceIdentifier(len_key),List(types, rec_chunk, instances, len_key),IfExp(Compare(Name(identifier(ns)),Eq,Str(utxo/v0)),IntNum(34),IfExp(Compare(Name(identifier(ns)),Eq,Str(stake)),IntNum(28),IfExp(Compare(Name(identifier(ns)),Eq,Str(pool)),IntNum(28),IntNum(0)))),None,Some(Int1Type(true)),DocSpec(None,List()))\nvalue instance: ValueInstanceSpec(InstanceIdentifier(ns_size),List(types, rec_chunk, instances, ns_size),BinOp(IntNum(4),Add,Name(identifier(len_ns))),None,Some(CalcIntType),DocSpec(None,List()))\nvalue instance: ValueInstanceSpec(InstanceIdentifier(rec_payload_size),List(types, rec_chunk, instances, rec_payload_size),BinOp(Attribute(Attribute(Name(identifier(_parent)),identifier(_parent)),identifier(len_payload)),Sub,IntNum(1)),None,Some(CalcIntType),DocSpec(None,List()))\n<a name='type-scls_file-rec_header'></a>\n<h2>Type: RecHeader</h2>\n\n<p>Header record</p>\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>magic</td>\n<td></td>\n<td>Magic bytes \"SCLS\"</td>\n</tr>\n<tr>\n<td>4</td>\n<td>...</td>\n<td>version</td>\n<td>u4be</td>\n<td>Version of the file format</td>\n</tr>\n</table>\n<a name='type-scls_file-rec_manifest'></a>\n<h2>Type: RecManifest</h2>\n\n<p>Manifest — is a trailer in the file that describes information of about the file contents</p>\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>slot_no</td>\n<td>u8be</td>\n<td>Slot number that this manifest refers to</td>\n</tr>\n<tr>\n<td>8</td>\n<td>...</td>\n<td>total_entries</td>\n<td>u8be</td>\n<td>total amount of entries in the file</td>\n</tr>\n<tr>\n<td>16</td>\n<td>...</td>\n<td>total_chunks</td>\n<td>u8be</td>\n<td>total amount of chunks in the file</td>\n</tr>\n<tr>\n<td>24</td>\n<td>...</td>\n<td>summary</td>\n<td><a href=\"#type-scls_file-summary\">Summary</a></td>\n<td>information about the file</td>\n</tr>\n<tr>\n<td>???</td>\n<td>...</td>\n<td>namespace_info</td>\n<td><a href=\"#type-scls_file-namespace_info\">NamespaceInfo</a></td>\n<td>information about the namespaces</td>\n</tr>\n<tr>\n<td>???</td>\n<td>...</td>\n<td>prev_manifest</td>\n<td>u8be</td>\n<td>absolute offset of the previous manifest, zero if there is no</td>\n</tr>\n<tr>\n<td>???</td>\n<td>...</td>\n<td>root_hash</td>\n<td><a href=\"#type-scls_file-digest\">Digest</a></td>\n<td>merkle tree root of the live entries</td>\n</tr>\n<tr>\n<td>???</td>\n<td>...</td>\n<td>offset</td>\n<td>u4be</td>\n<td>relative offset to the beginning of the record</td>\n</tr>\n</table>\n<a name='type-scls_file-rec_metadata'></a>\n<h2>Type: RecMetadata</h2>\n\n<p>Metadata record containing URI-indexed entries with CBOR-encoded values</p>\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>data</td>\n<td><a href=\"#type-scls_file-entries_metadata_record\">EntriesMetadataRecord</a></td>\n<td>payload parsed as entries</td>\n</tr>\n<tr>\n<td>???</td>\n<td>...</td>\n<td>footer</td>\n<td><a href=\"#type-scls_file-metadata_footer\">MetadataFooter</a></td>\n<td></td>\n</tr>\n</table>\nvalue instance: ValueInstanceSpec(InstanceIdentifier(len_data),List(types, rec_metadata, instances, len_data),BinOp(Name(identifier(rec_payload_size)),Sub,ByteSizeOfType(typeId(false,List(metadata_footer),false))),None,Some(CalcIntType),DocSpec(Some(entries_count=8, digest=28.),List()))\nvalue instance: ValueInstanceSpec(InstanceIdentifier(rec_payload_size),List(types, rec_metadata, instances, rec_payload_size),BinOp(Attribute(Attribute(Name(identifier(_parent)),identifier(_parent)),identifier(len_payload)),Sub,IntNum(1)),None,Some(CalcIntType),DocSpec(None,List()))\n<a name='type-scls_file-scls_record'></a>\n<h2>Type: SclsRecord</h2>\n\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>len_payload</td>\n<td>u4be</td>\n<td>Size of the record, including size and record type</td>\n</tr>\n<tr>\n<td>4</td>\n<td>...</td>\n<td>payload</td>\n<td><a href=\"#type-scls_file-scls_record_data\">SclsRecordData</a></td>\n<td>payload of the record</td>\n</tr>\n</table>\n<a name='type-scls_file-scls_record_data'></a>\n<h2>Type: SclsRecordData</h2>\n\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>record_type</td>\n<td>u1</td>\n<td>Type of the record</td>\n</tr>\n<tr>\n<td>1</td>\n<td>...</td>\n<td>record_data</td>\n<td>SwitchType(Name(identifier(record_type)),TreeMap(IntNum(0) -> UserTypeFromBytes(List(rec_header),None,List(),BytesEosType(None,false,None,None),None), IntNum(1) -> UserTypeFromBytes(List(rec_manifest),None,List(),BytesEosType(None,false,None,None),None), IntNum(16) -> UserTypeFromBytes(List(rec_chunk),None,List(),BytesEosType(None,false,None,None),None), IntNum(49) -> UserTypeFromBytes(List(rec_metadata),None,List(),BytesEosType(None,false,None,None),None), Name(identifier(_)) -> BytesEosType(None,false,None,None)),true,false)</td>\n<td>Record payload</td>\n</tr>\n</table>\n<a name='type-scls_file-summary'></a>\n<h2>Type: Summary</h2>\n\n<p>Summary</p>\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>created_at</td>\n<td><a href=\"#type-scls_file-tstr\">Tstr</a></td>\n<td>absolute timestamp when file was generated in ISO8601 format</td>\n</tr>\n<tr>\n<td>???</td>\n<td>...</td>\n<td>tool_bytes</td>\n<td><a href=\"#type-scls_file-tstr\">Tstr</a></td>\n<td>name of the tool that has generated the file</td>\n</tr>\n<tr>\n<td>???</td>\n<td>...</td>\n<td>comment</td>\n<td><a href=\"#type-scls_file-tstr\">Tstr</a></td>\n<td>optional comment</td>\n</tr>\n</table>\n<a name='type-scls_file-tstr'></a>\n<h2>Type: Tstr</h2>\n\n<table class=\"table\">\n<tr><th>Offset</th><th>Size</th><th>ID</th><th>Type</th><th>Note</th></tr>\n<tr>\n<td>0</td>\n<td>...</td>\n<td>len_data</td>\n<td>u4be</td>\n<td>size of the string</td>\n</tr>\n<tr>\n<td>4</td>\n<td>...</td>\n<td>data</td>\n<td>str(UTF-8)</td>\n<td>value of the string</td>\n</tr>\n</table>\n\n  </div>\n    <!-- Optional JavaScript -->\n    <!-- jQuery first, then Popper.js, then Bootstrap JS -->\n    <script src=\"https://code.jquery.com/jquery-3.3.1.slim.min.js\" integrity=\"sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo\" crossorigin=\"anonymous\"></script>\n    <script src=\"https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.6/umd/popper.min.js\" integrity=\"sha384-wHAiFfRlMFy6i5SRaxvfOCifBUQy1xHdJ/yoi7FRNXMRBu5WHdZYu1hA6ZOblgut\" crossorigin=\"anonymous\"></script>\n    <script src=\"https://stackpath.bootstrapcdn.com/bootstrap/4.2.1/js/bootstrap.min.js\" integrity=\"sha384-B0UglyR+jN6CkvvICOB2joaf5I4l3gm9GU6Hc1og6Ls7i6U/mkkaduKaBhlAXv9k\" crossorigin=\"anonymous\"></script>\n  </body>\n</html>\n      \n"
  },
  {
    "path": "CIP-0165/namespaces/README.md",
    "content": "# Namespaces\n\nThis is directory of the supported namespaces.\n\nEach namespace defines a non-intersecting slices of the data.\n\n| Shortname            | Content                         | Key size | Key description |\n| -------------------- | ------------------------------- | -------- | --------------- |\n| blocks/v0            | Blocks created                  | 36       | keyhash of the stake pool |\n| gov/committee/v0     | Governance action state         | 8        | epoch |\n| gov/constitution/v0  | Constitution                    | 8        | epoch |\n| gov/pparams/v0       | Protocol parameters             | 4        | current, previous, or future |\n| gov/proposals/v0     | Update proposals                | 34       | address of the proposal in transactions |\n| pool_stake/v0        | Stake delegation                | 28       | stake pool keyhash |\n| nonce/v0             | Nonces                          | 1        | zero key |\n| snapshots/v0         | snapshots                       | 32       | key type, stage, value type (see docs) |\n| utxo/v0              | UTXOs                           | 34       | utxo address in the transaction |\n\nKey specifications are described in cddl specification comments.\n"
  },
  {
    "path": "CIP-0165/namespaces/blocks_v0.cddl",
    "content": "; This file was auto-generated from huddle.\n; Source: https://github.com/tweag/cardano-cls/blob/main/scls-cardano/cddl-src/Cardano/SCLS/Namespace/Blocks.hs\n\n;  Values for the blocks.\n;\n;  Key definition:\n;\n;  ```\n;  meta:\n;    endian: be\n;\n;  seq:\n;    - id: key\n;      type: blocks\n;\n;  types:\n;    block:\n;      seq:\n;        - id: keyhash_stakepool\n;          doc: keyhash of the stake pool\n;          size: 28\n;        - id: epoch\n;          doc: epoch\n;          type: u8\n;  ```\nrecord_entry = int\n\n"
  },
  {
    "path": "CIP-0165/namespaces/gov_committee_v0.cddl",
    "content": "; This file was auto-generated from huddle.\n; Source: https://github.com/tweag/cardano-cls/blob/main/scls-cardano/cddl-src/Cardano/SCLS/Namespace/GovCommittee.hs\n\n;  The key for the namespace\n;\n;  ```\n;  meta:\n;    endian: be\n;\n;  seq:\n;    - id: key\n;      type: gov_committee\n;\n;  types:\n;    gov_committee:\n;      seq:\n;        - id: epoch\n;          doc: epoch\n;          type: u8\n;  ```\nrecord_entry = committee\n\n;  Storage of the committee members\ncommittee = {* credential => committee_authorization}\n\ncredential = [0, addr_keyhash// 1, script_hash]\n\naddr_keyhash = hash28\n\nhash28 = bytes .size 28\n\n;  To compute a script hash, note that you must prepend\n;  a tag to the bytes of the script before hashing.\n;  The tag is determined by the language.\n;  The tags in the Conway era are:\n;   - \"\\x00\" for multisig scripts\n;   - \"\\x01\" for Plutus V1 scripts\n;   - \"\\x02\" for Plutus V2 scripts\n;   - \"\\x03\" for Plutus V3 scripts\nscript_hash = hash28\n\n;  0 - hot committee member\n;  1 - resignation\ncommittee_authorization = [0, credential// 1, anchor/ nil]\n\n;\n;  Signed url\nanchor = [anchor_url : url, anchor_data_hash : bytes]\n\nurl = text .size (0 .. 128)\n\n"
  },
  {
    "path": "CIP-0165/namespaces/gov_constitution_v0.cddl",
    "content": "; This file was auto-generated from huddle.\n; Source: https://github.com/tweag/cardano-cls/blob/main/scls-cardano/cddl-src/Cardano/SCLS/Namespace/GovConstitution.hs\n\n;  Constitution record entry\n;\n;  ```\n;  meta:\n;    endian: be\n;\n;  seq:\n;    - id: key\n;      type: gov_constitution\n;\n;  gov_constitution:\n;    seq:\n;      - id: epoch\n;        doc: Current epoch.\n;        type: u8\n;  ```\nrecord_entry = constitution\n\n;  address of the constition\nconstitution = [anchor, script_hash/ nil]\n\n;\n;  Signed url\nanchor = [anchor_url : url, anchor_data_hash : bytes]\n\nurl = text .size (0 .. 128)\n\n;  To compute a script hash, note that you must prepend\n;  a tag to the bytes of the script before hashing.\n;  The tag is determined by the language.\n;  The tags in the Conway era are:\n;   - \"\\x00\" for multisig scripts\n;   - \"\\x01\" for Plutus V1 scripts\n;   - \"\\x02\" for Plutus V2 scripts\n;   - \"\\x03\" for Plutus V3 scripts\nscript_hash = hash28\n\nhash28 = bytes .size 28\n\n"
  },
  {
    "path": "CIP-0165/namespaces/gov_pparams_v0.cddl",
    "content": "; This file was auto-generated from huddle.\n; Source: https://github.com/tweag/cardano-cls/blob/main/scls-cardano/cddl-src/Cardano/SCLS/Namespace/GovPParams.hs\n\n;  Specification for parameters\n;\n;  ```\n;  meta:\n;    endian: be\n;\n;  seq:\n;    - id: key\n;      type: gov_pparams\n;\n;  types:\n;    gov_pparams:\n;      seq:\n;        - id: value\n;          type: strz\n;          size: 4\n;          encoding: ASCII\n;        - id: valiant\n;          size: 0\n;          type:\n;            switch-on: value\n;            cases:\n;              '\"prev\"': kprev\n;              '\"curr\"': kcurr\n;              '\"fut0\"': kfut0\n;              '\"fut1\"': kfut1\n;    kprev:\n;      doc: previous values\n;    kcurr:\n;      doc: current values\n;    kfut0:\n;      doc: possible future\n;    kfut1:\n;      doc: definitive future\n;  ```\n;\n;  fut0 with missig parameters should be omitted.\nrecord_entry = gov_pparams_out\n\n;  Governance protocol parameters\ngov_pparams_out =\n  { 0  : coin\n                            ; min_fee_a: the linear factor for the minimum fee calculation\n  , 1  : coin\n                            ; min_fee_b: the constant factor for the minimum fee calculation\n  , 2  : uint .size 4\n                    ; max_block_size: maximal block body size in bytes\n  , 3  : uint .size 4           ; max_tx_size: maximal transaction size in bytes\n  , 4  : uint .size 2\n                    ; max_block_header_size: maximal block header size in bytes\n  , 5  : coin\n                            ; key_deposit: The amount of a key registration deposit\n  , 6  : coin\n                            ; pool_deposit: The amount of a pool registration deposit\n  , 7  : epoch_interval         ; maximum_epoch: maximum epoch\n  , 8  : uint .size 2           ; n_opt: desired number of pools\n  , 9  : nonnegative_interval   ; a0: pool pledge influence factor\n  , 10 : unit_interval          ; rho: monetary expansion rate\n  , 11 : unit_interval          ; tau: treasury expansion\n  , 16 : coin                   ; min_pool_cost: minimum pool cost\n  , 17 : coin\n                            ; ada_per_utxo_byte: Cost in ada per 1 byte of UTxO storage instead of _coinsPerUTxOWord\n  , 18 : cost_models\n                     ; cost_models: Cost models for non-native script languages\n  , 19 : ex_unit_prices\n                  ; prices: Prices of execution units for non-native script languages\n  , 20 : ex_units\n                        ; max_tx_ex_units: Max total script execution resources units allowed per tx\n  , 21 : ex_units\n                        ; max_block_ex_units: Max total script execution resources units allowed per block\n  , 22 : uint .size 4\n                    ; max_value_size: Max size of a Value in an output\n  , 23 : uint .size 2\n                    ; collateral_percentage: The scaling percentage of the collateral relative to the fee\n  , 24 : uint .size 2\n                    ; max_collateral_inputs: Maximum number of collateral inputs allowed in a transaction\n  , 25 : pool_voting_thresholds ; pool voting thresholds\n  , 26 : drep_voting_thresholds ; drep voting thresholds\n  , 27 : uint .size 2           ; min committee size\n  , 28 : epoch_interval         ; committee term limit\n  , 29 : epoch_interval         ; goveranance action validity period\n  , 30 : coin                   ; governance action deposit\n  , 31 : coin                   ; drep deposit\n  , 32 : epoch_interval         ; drep inactivity period\n  , 33 : nonnegative_interval\n            ; min_fee_ref_script_cost_per_byte: Reference scripts fee for the minimum fee calculation\n  }\n\nnonnegative_interval = #6.30([uint, positive_int])\n\npositive_int = 1 .. 18446744073709551615\n\n; NOTE: The real unit_interval is: #6.30([uint, uint])\n;\n;  A unit interval is a number in the range between 0 and 1, which\n;  means there are two extra constraints:\n;     1. numerator <= denominator\n;     2. denominator > 0\nunit_interval =\n  #6.30([uint .le 18446744073709551615, uint .le 18446744073709551615])\n\nex_unit_prices =\n  [mem_price : nonnegative_interval, step_price : nonnegative_interval]\n\nepoch_interval = uint .size 4\n\ncoin = uint\n\n; The format for cost_models is flexible enough to allow adding\n; Plutus built-ins and language versions in the future.\n;\n; Plutus v1: only 166 integers are used, but more are accepted (and ignored)\n; Plutus v2: only 175 integers are used, but more are accepted (and ignored)\n; Plutus v3: only 223 integers are used, but more are accepted (and ignored)\n;\n; Any 8-bit unsigned number can be used as a key.\ncost_models =\n  {? 0 : [* int64], ? 1 : [* int64], ? 2 : [* int64], * 3 .. 255 => [* int64]}\n\nint64 = -9223372036854775808 .. 9223372036854775807\n\nex_units = [mem : uint, steps : uint]\n\n;\n;  0 - motion no confidence\n;  1 - committee normal\n;  2 - committee no confidence\n;  3 - hard fork initiation\n;  4 - security relevant parameter voting threshold\npool_voting_thresholds =\n  [unit_interval, unit_interval, unit_interval, unit_interval, unit_interval]\n\n;\n;  0 - motion no confidence\n;  1 - committee normal\n;  2 - committee no confidence\n;  3 - update constitution\n;  4 - hard fork initiation\n;  5 - PP network group\n;  6 - PP economic group\n;  7 - PP technical group\n;  8 - PP governance group\n;  9 - treasury withdrawal\ndrep_voting_thresholds =\n  [ unit_interval\n  , unit_interval\n  , unit_interval\n  , unit_interval\n  , unit_interval\n  , unit_interval\n  , unit_interval\n  , unit_interval\n  , unit_interval\n  , unit_interval\n  ]\n\n\n"
  },
  {
    "path": "CIP-0165/namespaces/gov_proposals_v0.cddl",
    "content": "; This file was auto-generated from huddle.\n; Source: https://github.com/tweag/cardano-cls/blob/main/scls-cardano/cddl-src/Cardano/SCLS/Namespace/GovProposals.hs\n\n;  Size of the key\n;\n;  ```\n;  meta:\n;    endian: be\n;\n;  seq:\n;    - id: key\n;      type: gov_proposals\n;\n;  gov_proposals:\n;    seq:\n;      - id: tx_addr\n;        doc: transaction\n;        type: bytes\n;        size: 28\n;      - id: tx_idx\n;        doc: index inside transaction\n;        type: u4\n;      - id: gov_action_idx\n;        doc: governance action index\n;        type: u2\n;  ```\n;\nrecord_entry = proposal\n\nproposal =\n  { drep_votes         : {* credential => vote}\n  , proposed_in        : epoch_no\n  , expires_after      : epoch_no\n  , committee_votes    : {* committee_cold_credential => vote}\n  , stake_pool_votes   : {* pool_keyhash => vote}\n  , proposal_procedure : proposal_procedure\n  }\n\n\ncredential = [0, addr_keyhash// 1, script_hash]\n\naddr_keyhash = hash28\n\nhash28 = bytes .size 28\n\n;  To compute a script hash, note that you must prepend\n;  a tag to the bytes of the script before hashing.\n;  The tag is determined by the language.\n;  The tags in the Conway era are:\n;   - \"\\x00\" for multisig scripts\n;   - \"\\x01\" for Plutus V1 scripts\n;   - \"\\x02\" for Plutus V2 scripts\n;   - \"\\x03\" for Plutus V3 scripts\nscript_hash = hash28\n\nvote = 0 .. 2\n\nepoch_no = uint .size 8\n\ncommittee_cold_credential = credential\n\npool_keyhash = hash28\n\nproposal_procedure =\n  { anchor         : anchor\n  , deposit        : coin\n  , gov_action     : gov_action\n  , return_address : reward_account\n  }\n\n\n;\n;  Signed url\nanchor = [anchor_url : url, anchor_data_hash : bytes]\n\nurl = text .size (0 .. 128)\n\ncoin = uint\n\ngov_action =\n  [  0\n  , purpose : gov_action_id/ nil\n  , update  : gov_pparams_update\n  , hash    : script_hash/ nil\n  // 1\n  , gov_action_id/ nil\n  , protocol_version\n  // 2\n  , withdrawls        : {* reward_account => coin}\n  , script_hash/ nil\n  // 3\n  , purpose : gov_action_id/ nil\n  // 4\n  , purpose   : gov_action_id/ nil\n  , removed   : set<credential>\n  , added     : {* credential => epoch_no}\n  , threshold : unit_interval\n  // 5\n  , purpose      : gov_action_id/ nil\n  , constitution : constitution\n  // 6\n  , nil\n  ]\n\n\ngov_action_id = [transaction_id : hash32, gov_action_index : uint .size 2]\n\nhash32 = bytes .size 32\n\n;  Governance protocol parameters\ngov_pparams_update =\n  { ? 0  : coin\n                              ; min_fee_a: the linear factor for the minimum fee calculation\n  , ? 1  : coin\n                              ; min_fee_b: the constant factor for the minimum fee calculation\n  , ? 2  : uint .size 4\n                      ; max_block_size: maximal block body size in bytes\n  , ? 3  : uint .size 4\n                      ; max_tx_size: maximal transaction size in bytes\n  , ? 4  : uint .size 2\n                      ; max_block_header_size: maximal block header size in bytes\n  , ? 5  : coin\n                              ; key_deposit: The amount of a key registration deposit\n  , ? 6  : coin\n                              ; pool_deposit: The amount of a pool registration deposit\n  , ? 7  : epoch_interval         ; maximum_epoch: maximum epoch\n  , ? 8  : uint .size 2           ; n_opt: desired number of pools\n  , ? 9  : nonnegative_interval   ; a0: pool pledge influence factor\n  , ? 10 : unit_interval          ; rho: monetary expansion rate\n  , ? 11 : unit_interval          ; tau: treasury expansion\n  , ? 16 : coin                   ; min_pool_cost: minimum pool cost\n  , ? 17 : coin\n                              ; ada_per_utxo_byte: Cost in ada per 1 byte of UTxO storage instead of _coinsPerUTxOWord\n  , ? 18 : cost_models\n                       ; cost_models: Cost models for non-native script languages\n  , ? 19 : ex_unit_prices\n                    ; prices: Prices of execution units for non-native script languages\n  , ? 20 : ex_units\n                          ; max_tx_ex_units: Max total script execution resources units allowed per tx\n  , ? 21 : ex_units\n                          ; max_block_ex_units: Max total script execution resources units allowed per block\n  , ? 22 : uint .size 4\n                      ; max_value_size: Max size of a Value in an output\n  , ? 23 : uint .size 2\n                      ; collateral_percentage: The scaling percentage of the collateral relative to the fee\n  , ? 24 : uint .size 2\n                      ; max_collateral_inputs: Maximum number of collateral inputs allowed in a transaction\n  , ? 25 : pool_voting_thresholds ; pool voting thresholds\n  , ? 26 : drep_voting_thresholds ; drep voting thresholds\n  , ? 27 : uint .size 2           ; min committee size\n  , ? 28 : epoch_interval         ; committee term limit\n  , ? 29 : epoch_interval         ; goveranance action validity period\n  , ? 30 : coin                   ; governance action deposit\n  , ? 31 : coin                   ; drep deposit\n  , ? 32 : epoch_interval         ; drep inactivity period\n  , ? 33 : nonnegative_interval\n              ; min_fee_ref_script_cost_per_byte: Reference scripts fee for the minimum fee calculation\n  }\n\n\nepoch_interval = uint .size 4\n\nnonnegative_interval = #6.30([uint, positive_int])\n\npositive_int = 1 .. 18446744073709551615\n\n; NOTE: The real unit_interval is: #6.30([uint, uint])\n;\n;  A unit interval is a number in the range between 0 and 1, which\n;  means there are two extra constraints:\n;     1. numerator <= denominator\n;     2. denominator > 0\nunit_interval =\n  #6.30([uint .le 18446744073709551615, uint .le 18446744073709551615])\n\nex_unit_prices =\n  [mem_price : nonnegative_interval, step_price : nonnegative_interval]\n\nepoch_interval = uint .size 4\n\n; The format for cost_models is flexible enough to allow adding\n; Plutus built-ins and language versions in the future.\n;\n; Plutus v1: only 166 integers are used, but more are accepted (and ignored)\n; Plutus v2: only 175 integers are used, but more are accepted (and ignored)\n; Plutus v3: only 223 integers are used, but more are accepted (and ignored)\n;\n; Any 8-bit unsigned number can be used as a key.\ncost_models =\n  {? 0 : [* int64], ? 1 : [* int64], ? 2 : [* int64], * 3 .. 255 => [* int64]}\n\nint64 = -9223372036854775808 .. 9223372036854775807\n\nex_units = [mem : uint, steps : uint]\n\n;\n;  0 - motion no confidence\n;  1 - committee normal\n;  2 - committee no confidence\n;  3 - update constitution\n;  4 - hard fork initiation\n;  5 - PP network group\n;  6 - PP economic group\n;  7 - PP technical group\n;  8 - PP governance group\n;  9 - treasury withdrawal\ndrep_voting_thresholds =\n  [ unit_interval\n  , unit_interval\n  , unit_interval\n  , unit_interval\n  , unit_interval\n  , unit_interval\n  , unit_interval\n  , unit_interval\n  , unit_interval\n  , unit_interval\n  ]\n\n;\n;  0 - motion no confidence\n;  1 - committee normal\n;  2 - committee no confidence\n;  3 - hard fork initiation\n;  4 - security relevant parameter voting threshold\npool_voting_thresholds =\n  [unit_interval, unit_interval, unit_interval, unit_interval, unit_interval]\n\nprotocol_version = [major_protocol_version, uint]\n\nmajor_protocol_version = uint\n\n;  28 bytes hash and one byte for the network type\nreward_account = bytes .size 29\n\nset<a0> = #6.258([* a0])\n\n;  address of the constition\nconstitution = [anchor, script_hash/ nil]\n\n"
  },
  {
    "path": "CIP-0165/namespaces/nonces_v0.cddl",
    "content": "; This file was auto-generated from huddle.\n; Source: https://github.com/tweag/cardano-cls/blob/main/scls-cardano/cddl-src/Cardano/SCLS/Namespace/Nonces.hs\n\n;  Key is just zero\n;\n;  ```\n;  meta:\n;    endian: be\n;\n;  seq:\n;    - id: key\n;      type: nonce\n;\n;  types:\n;    nonce:\n;      doc: Nonce value\n;      size: 1\n;      type: u1\n;      const: 0\n;  ```\n;\nrecord_entry = nonces\n\n;  List of nonces used in the protocol state\n;\nnonces =\n  { lab_nonce              : nonce\n  , last_slot              : with_origin<slot_no>\n  , epoch_nonce            : nonce\n  , cert_counters          : {* keyhash28 => word64}\n  , evolving_nonce         : nonce\n  , candidate_nonce        : nonce\n  , last_epoch_block_nonce : nonce\n  }\n\n\nnonce = neutral_nonce/ just_nonce\n\nneutral_nonce = [0]\n\njust_nonce = [1, hash32]\n\nhash32 = bytes .size 32\n\nwith_origin<a0> = [0// 1, a0]\n\nslot_no = uint .size 8\n\nkeyhash28 = hash28\n\nhash28 = bytes .size 28\n\nword64 = uint .size 8\n\n"
  },
  {
    "path": "CIP-0165/namespaces/pool_stake_v0.cddl",
    "content": "; This file was auto-generated from huddle.\n; Source: https://github.com/tweag/cardano-cls/blob/main/scls-cardano/cddl-src/Cardano/SCLS/Namespace/PoolStake.hs\n\n;  The key for the entry is one of the following:\n;\n;  ```\n;  meta:\n;    endian: be\n;\n;  seq:\n;    - id: key\n;      type: pool_stake\n;\n;  types:\n;    pool_stake:\n;      seq:\n;        - id: keyhash\n;          doc: stake pool keyhash\n;          size: 28\n;  ```\n;\nrecord_entry = individual_pool_stake\n\n; Individual pool stake information\n;\n; Fields:\n;   - vrf: VRF verification key hash for the pool\n;   - total: Total stake delegated to the pool\nindividual_pool_stake = {vrf : vrf_keyhash, total : coin}\n\nvrf_keyhash = hash32\n\nhash32 = bytes .size 32\n\ncoin = uint\n\n"
  },
  {
    "path": "CIP-0165/namespaces/snapshots_v0.cddl",
    "content": "; This file was auto-generated from huddle.\n; Source: https://github.com/tweag/cardano-cls/blob/main/scls-cardano/cddl-src/Cardano/SCLS/Namespace/Snapshots.hs\n\n;  The key for the entry is one of the following:\n;\n;  ```\n;  meta:\n;    endian: be\n;\n;  seq:\n;    - id: key\n;      type: snapshot\n;\n;  types:\n;    snapshot:\n;      seq:\n;        - id: key_type\n;          type: u1\n;        - id: keyhash\n;          size: 29\n;          type:\n;            switch-on: key_type\n;            cases:\n;              0: credential\n;              1: keyhash\n;        - id: stage\n;          type: u1\n;          enum: snapshot_value\n;        - id: value_type\n;          type: u1\n;          enum: snapshot_value\n;\n;    credential:\n;      seq:\n;        - id: cred_data\n;          size: 28\n;\n;    keyhash:\n;      seq:\n;        - id: keyhash_data\n;          size: 28\n;        - id: dummy\n;          size: 1\n;\n;  enums:\n;    snapshot_stage:\n;      0: mark\n;      1: set\n;      2: go\n;    snapshot_value:\n;      0: coin\n;      1: address\n;      2: pool_params\n;  ```\nrecord_entry = snapshot_out\n\n;  Value maybe be one of the following:\n;   - Coin value\n;   - Keyhash of an delegation address\n;   - Pool parameters\nsnapshot_out = [0, coin// 1, keyhash28// 2, pool_params]\n\ncoin = uint\n\nkeyhash28 = hash28\n\nhash28 = bytes .size 28\n\npool_params =\n  { cost           : coin\n  , margin         : unit_interval\n  , pledge         : coin\n  , relays         : [* relay]\n  , operator       : pool_keyhash\n  , pool_owners    : set<addr_keyhash>\n  , vrf_keyhash    : vrf_keyhash\n  , pool_metadata  : pool_metadata/ nil\n  , reward_account : reward_account\n  }\n\n\n; NOTE: The real unit_interval is: #6.30([uint, uint])\n;\n;  A unit interval is a number in the range between 0 and 1, which\n;  means there are two extra constraints:\n;     1. numerator <= denominator\n;     2. denominator > 0\nunit_interval =\n  #6.30([uint .le 18446744073709551615, uint .le 18446744073709551615])\n\nrelay = [0, single_host_addr]/ [1, single_host_name]/ [2, multi_host_name]\n\n;  A single host address relay\nsingle_host_addr = (port/ nil, ipv4/ nil, ipv6/ nil)\n\nport = uint .le 65535\n\nipv4 = bytes .size 4\n\nipv6 = bytes .size 16\n\nsingle_host_name = (port/ nil, dns_name)\n\ndns_name = text .size (0 .. 128)\n\nmulti_host_name = (dns_name)\n\npool_keyhash = hash28\n\nset<a0> = #6.258([* a0])\n\naddr_keyhash = hash28\n\nvrf_keyhash = hash32\n\nhash32 = bytes .size 32\n\npool_metadata = [url, pool_metadata_hash]\n\nurl = text .size (0 .. 128)\n\npool_metadata_hash = bytes\n\n;  28 bytes hash and one byte for the network type\nreward_account = bytes .size 29\n\n"
  },
  {
    "path": "CIP-0165/namespaces/utxo_v0.cddl",
    "content": "; This file was auto-generated from huddle.\n; Source: https://github.com/tweag/cardano-cls/blob/main/scls-cardano/cddl-src/Cardano/SCLS/Namespace/UTxO.hs\n\n;  The key for the entry is one of the following:\n;\n;  ```\n;  meta:\n;    endian: be\n;\n;  seq:\n;    - id: key\n;      type: utxo_key\n;\n;  types:\n;    utxo_key:\n;      seq:\n;       - id: tx_addr\n;         doc: transaction\n;         type: bytes\n;         size: 28\n;       - id: tx_idx\n;         doc: index inside transaction\n;         type: u4\n;  ```\n;\nrecord_entry = tx_out\n\ntx_out = bytes .cbor rule\n\nrule = shelley_tx_out/ babbage_tx_out\n\nshelley_tx_out = [address, amount : value, ? datum_hash : hash32]\n\naddress = bytes\n\nvalue = coin/ [coin, multiasset<positive_coin>]\n\ncoin = uint\n\nmultiasset<a0> = {* policy_id => {+ asset_name => a0}}\n\npolicy_id = hash28\n\nhash28 = bytes .size 28\n\nasset_name = bytes .size (0 .. 32)\n\npositive_coin = 1 .. 18446744073709551615\n\nhash32 = bytes .size 32\n\n; NEW starting with babbage\n;   datum_option\n;   script_ref\nbabbage_tx_out = {0 : address, 1 : value, ? 2 : datum_option, ? 3 : script_ref}\n\ndatum_option = [0, hash32// 1, data]\n\ndata = #6.24(bytes .cbor plutus_data)\n\nplutus_data =\n  constr<plutus_data>\n  / {* plutus_data => plutus_data}\n  / [* plutus_data]\n  / big_int\n  / bytes\n\n; NEW\n;   #6.102([uint, [* a]]): For tag range 6.1280 .. 6.1400 inclusive\nconstr<a0> =\n  #6.122([* a0])\n  / #6.123([* a0])\n  / #6.124([* a0])\n  / #6.125([* a0])\n  / #6.126([* a0])\n  / #6.127([* a0])\n  / #6.1280([* a0])\n  / #6.1281([* a0])\n  / #6.1282([* a0])\n  / #6.1283([* a0])\n  / #6.1284([* a0])\n  / #6.1285([* a0])\n  / #6.1286([* a0])\n  / #6.1287([* a0])\n  / #6.1288([* a0])\n  / #6.1289([* a0])\n  / #6.1290([* a0])\n  / #6.1291([* a0])\n  / #6.1292([* a0])\n  / #6.1293([* a0])\n  / #6.1294([* a0])\n  / #6.1295([* a0])\n  / #6.1296([* a0])\n  / #6.1297([* a0])\n  / #6.1298([* a0])\n  / #6.1299([* a0])\n  / #6.1300([* a0])\n  / #6.1301([* a0])\n  / #6.1302([* a0])\n  / #6.1303([* a0])\n  / #6.1304([* a0])\n  / #6.1305([* a0])\n  / #6.1306([* a0])\n  / #6.1307([* a0])\n  / #6.1308([* a0])\n  / #6.1309([* a0])\n  / #6.1310([* a0])\n  / #6.1311([* a0])\n  / #6.1312([* a0])\n  / #6.1313([* a0])\n  / #6.1314([* a0])\n  / #6.1315([* a0])\n  / #6.1316([* a0])\n  / #6.1317([* a0])\n  / #6.1318([* a0])\n  / #6.1319([* a0])\n  / #6.1320([* a0])\n  / #6.1321([* a0])\n  / #6.1322([* a0])\n  / #6.1323([* a0])\n  / #6.1324([* a0])\n  / #6.1325([* a0])\n  / #6.1326([* a0])\n  / #6.1327([* a0])\n  / #6.1328([* a0])\n  / #6.1329([* a0])\n  / #6.1330([* a0])\n  / #6.1331([* a0])\n  / #6.1332([* a0])\n  / #6.1333([* a0])\n  / #6.1334([* a0])\n  / #6.1335([* a0])\n  / #6.1336([* a0])\n  / #6.1337([* a0])\n  / #6.1338([* a0])\n  / #6.1339([* a0])\n  / #6.1340([* a0])\n  / #6.1341([* a0])\n  / #6.1342([* a0])\n  / #6.1343([* a0])\n  / #6.1344([* a0])\n  / #6.1345([* a0])\n  / #6.1346([* a0])\n  / #6.1347([* a0])\n  / #6.1348([* a0])\n  / #6.1349([* a0])\n  / #6.1350([* a0])\n  / #6.1351([* a0])\n  / #6.1352([* a0])\n  / #6.1353([* a0])\n  / #6.1354([* a0])\n  / #6.1355([* a0])\n  / #6.1356([* a0])\n  / #6.1357([* a0])\n  / #6.1358([* a0])\n  / #6.1359([* a0])\n  / #6.1360([* a0])\n  / #6.1361([* a0])\n  / #6.1362([* a0])\n  / #6.1363([* a0])\n  / #6.1364([* a0])\n  / #6.1365([* a0])\n  / #6.1366([* a0])\n  / #6.1367([* a0])\n  / #6.1368([* a0])\n  / #6.1369([* a0])\n  / #6.1370([* a0])\n  / #6.1371([* a0])\n  / #6.1372([* a0])\n  / #6.1373([* a0])\n  / #6.1374([* a0])\n  / #6.1375([* a0])\n  / #6.1376([* a0])\n  / #6.1377([* a0])\n  / #6.1378([* a0])\n  / #6.1379([* a0])\n  / #6.1380([* a0])\n  / #6.1381([* a0])\n  / #6.1382([* a0])\n  / #6.1383([* a0])\n  / #6.1384([* a0])\n  / #6.1385([* a0])\n  / #6.1386([* a0])\n  / #6.1387([* a0])\n  / #6.1388([* a0])\n  / #6.1389([* a0])\n  / #6.1390([* a0])\n  / #6.1391([* a0])\n  / #6.1392([* a0])\n  / #6.1393([* a0])\n  / #6.1394([* a0])\n  / #6.1395([* a0])\n  / #6.1396([* a0])\n  / #6.1397([* a0])\n  / #6.1398([* a0])\n  / #6.1399([* a0])\n  / #6.1400([* a0])\n  / #6.121([* a0])\n  / #6.102([uint, [* a0]])\n\nbig_int = int/ big_uint/ big_nint\n\nbig_uint = #6.2(bounded_bytes)\n\n; The real bounded_bytes does not have this limit. it instead has\n; a different limit which cannot be expressed in CDDL.\n;\n; The limit is as follows:\n;  - bytes with a definite-length encoding are limited to size 0..64\n;  - for bytes with an indefinite-length CBOR encoding, each chunk is\n;    limited to size 0..64\n;  ( reminder: in CBOR, the indefinite-length encoding of\n;  bytestrings consists of a token #2.31 followed by a sequence\n;  of definite-length encoded bytestrings and a stop code )\nbounded_bytes = bytes .size (0 .. 64)\n\nbig_nint = #6.3(bounded_bytes)\n\nscript_ref = #6.24(bytes .cbor script)\n\nscript =\n  [  0, native_script\n  // 1\n  , bytes\n  // 2\n  , bytes\n  // 3\n  , bytes\n  ]\n\n\nnative_script =\n  [  script_pubkey\n  // script_all\n  // script_any\n  // script_n_of_k\n  // invalid_before\n  // invalid_hereafter\n  ]\n\n\nscript_pubkey = (0, hash28)\n\nscript_all = (1, [* native_script])\n\nscript_any = (2, [* native_script])\n\nscript_n_of_k = (3, n : int64, [* native_script])\n\nint64 = -9223372036854775808 .. 9223372036854775807\n\ninvalid_before = (4, slot_no)\n\nslot_no = uint .size 8\n\ninvalid_hereafter = (5, slot_no)\n\n"
  },
  {
    "path": "CIP-0167/README.md",
    "content": "---\nCIP: 167\nTitle: Remove `isValid` from transactions\nCategory: Ledger\nAuthors:\n  - Teodora Danciu <teodora.danciu@iohk.io>\n  - Alexey Kuleshevich <alexey.kuleshevich@iohk.io>\nImplementors: N/A\nStatus: Proposed\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/1089\nCreated: 2025-09-01\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nWe propose removing the `isValid` boolean from the CBOR encoding of standalone transactions (e.g. for mempool).\nThis would not affect the serialization of the transactions within blocks, since isValid flag is already stored separately from the transaction\n\n## Motivation: why is this CIP necessary?\n\nThe `isValid` flag in standalone transaction CBOR is not intrinsic to the protocol or to the ledger-consensus boundary:\n  * it is not signed by the transaction creator, so anyone can set it to any value they like.\n  * for block validation: the value that is used is the one that was set by the consensus protocol\n  * for remote submissions from untrusted nodes: the node ignores the incoming flag, evaluates the transaction as if `isValid = True`, if phase-2 fails for that reason alone - admits it to the mempool with `isValid = False` so collateral can be collected.\n\nThe only remaining use is local submission from trusted clients (like cardano-cli), where the node reads the flag to avoid unintended collateral burn.\nThis use is important, but perhaps the transaction bytes are not the best layer to encode that intent.\n\nRemoving the flag simplifies encoding/decoding, slightly reduces on-wire size, and eliminates semantic ambiguity. Futhermore, because the flag is non-witnessed (excluded from the transaction ID), it cannot be trusted; keeping it invites inconsistency and confusion.\n\n## Specification\n\nCurrently, a stand-alone transaction is serialized like this:\n\n```cddl\ntransaction = [transaction_body, transaction_witness_set, bool, auxiliary_data/ nil]\n```\n\nThe proposal is to change it to:\n```cddl\ntransaction = [transaction_body, transaction_witness_set, auxiliary_data/ nil]\n```\n\n## Rationale: how does this CIP achieve its goals?\n\nRemoving the `isValid` flag from standalone transaction serialization simplifies the wire format without changing consensus or ledger semantics.\n\nThe trusted local client submission use case might be better expressed in a different way (for example, as a Node-to-Client submit parameter), rather than embedded in the transaction bytes.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] Transaction serializers and deserializers in [cardano-ledger](https://github.com/IntersectMBO/cardano-ledger) are implemented such that they follow the cddl specification described above, and reflected in the cddl specs\n- [ ] The feature is integrated into [cardano-node](https://github.com/IntersectMBO/cardano-node) with necessary adjustments made to [ouroboros-consensus](https://github.com/IntersectMBO/ouroboros-consensus) and released as part of the Dijkstra era hard fork\n\n### Implementation Plan\n\nThe implementation of this CIP should not proceed without an assessment of the potential impact on all the components that deserialise standalone transactions.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0170/README.md",
    "content": "---\nCIP: 170\nTitle: KERI-backed metadata attestations\nCategory: Metadata\nStatus: Proposed\nAuthors:\n    - Fergal O'Connor <fergal.oconnor@cardanofoundation.org>\n    - Thomas Kammerlocher <thomas.kammerlocher@cardanofoundation.org>\nImplementors: \n  - reeve.technology\n  - veridian.id\nDiscussions:\n    - Original PR: https://github.com/cardano-foundation/CIPs/pull/1113\nCreated: 2025-11-05\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nAccountability is essential for legal entities, organizations, and authorities operating in regulated environments. To establish accountability on the Cardano blockchain, it must be possible to prove the identity of entities responsible for on-chain actions in a verifiable and interoperable way.\n\nThis CIP defines a standardized mechanism to embed KERI ([Key Event Receipt Infrastructure](https://trustoverip.github.io/kswg-keri-specification/)) identifiers within Cardano transaction metadata. KERI provides self-certifying, portable, and decentralized identifiers known as Autonomic Identifiers (AIDs) that can be anchored to various roots of trust—such as verifiable Legal Entity Identifiers (vLEIs), organizational registries, or domain-specific trust frameworks.\n\nBy including KERI identifiers in transaction metadata, Cardano enables a flexible, trust-agnostic approach to identity binding. This approach supports accountability, legal and regulatory compliance, and interoperability with existing and emerging global identity ecosystems, while remaining compatible with self-sovereign identity principles.\n\n## Motivation: Why is this CIP necessary?\n\nThe demand for auditable and verifiable identifiers is increasing as accountability, traceability, and transparency become fundamental requirements for entities operating within regulated environments. Without a standardized mechanism, it is difficult to reliably associate on-chain activity with persistent and legally recognized identities.\n\nKERI (Key Event Receipt Infrastructure) addresses this challenge by introducing a decentralized, key-oriented identifier system that supports secure, portable, and self-certifying digital identities. Instead of relying on centralized registries, KERI establishes identifiers through cryptographically verifiable event logs, enabling secure key rotation, continuity of control, and tamper-evident auditability. This approach ensures that an identifier can consistently represent the same entity over time, while remaining interoperable with verifiable credentials and roots of trust such as verifiable Legal Entity Identifiers (vLEIs).\n\nBy embedding KERI identifiers into Cardano transaction metadata, this proposal enables a standardized and verifiable linkage between on-chain actions and off-chain accountability frameworks. This allows transactions to be cryptographically bound to a specific identifier and, through verifiable credential chains, to a legally recognized entity, thereby enhancing trust and compliance across decentralized and regulated ecosystems.\n\n\n## Specification\n\nBelow a generic solution is defined to enable metadata signing where a particular ecosystem or use-case may leverage a root of trust of its choosing – each most likely with its own credential chain format.\n\nThe credentials used in the KERI ecosystem are known as ACDCs, or [Authentic Chained Data Containers](https://trustoverip.github.io/kswg-acdc-specification/). This CIP will not explain at depth how KERI and ACDCs work due to their technical complexity. The [Appendix](#appendix) will however include some expanded explanations to help provide clarity.\n\n> [!NOTE]\n> The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"NOT RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in BCP 14 [RFC2119](https://www.rfc-editor.org/rfc/rfc2119) [RFC8174](https://www.rfc-editor.org/rfc/rfc8174) when, and only when, they appear in all capitals, as shown here.\n\n### Key Event Log Discovery\nIn order to verify the validity of credential chains and metadata transactions, Key Event Logs, or KELs, for all issuing and holding identifiers in the credential chain must be made available to a verifier. KELs may live off-chain for interoperability and scalability reasons, so this CIP does not make assumptions on which medium the KELs are published.\n\nA KERI watcher network SHOULD be used to discover up-to-date KELs for a given identifier for certain security reasons. Discovery of the watcher network relevant to a given ecosystem depends on the ecosystem itself.\n\nHowever, as KERI is a maturing technology, wide-spread deployment of watcher networks is not yet guaranteed. Until then, the interim solution is to publish an [Out-of-Band-Introduction](#discovery-via-out-of-band-introductions-oobis) via a known persistent channel for the specific project for discovery, and this may be used by a verifier to discover and query for KEL events and updates.\n\nIn one way or another, chain indexers must query for Key Event Log updates to validate credential chains and metadata transactions during the process of verification.\n\n### Visualized Identity Lifecycle\nThe following diagram illustrates the lifecycle of signing authority for a KERI identifier on Cardano. It demonstrates how [attestations](#creation-of-verifiable-records) (`ATTEST`) are invalid before [authority is established](#establishment-of-signing-authority) (`AUTH_BEGIN`), become valid during the authenticated period, and become invalid again after [revocation](#revoking-of-signing-authority) (`AUTH_END`).\n\n```mermaid\n---\nconfig:\n  theme: redux\n---\nsequenceDiagram\n  participant Legal Entity as Legal Entity\n  participant Cardano as Cardano\n  participant Indexer as Indexer\n  Legal Entity ->> Cardano: ATTEST\n  Cardano ->> Indexer: Identity invalid\n  Note right of Indexer: ❌ No valid credential\n  Legal Entity ->> Cardano: AUTH_BEGIN\n  Cardano ->> Indexer: Credential known\n  Note right of Indexer: ✅ Identifier established\n  Legal Entity ->> Cardano: ATTEST\n  Cardano ->> Indexer: Identity verified\n  Note right of Indexer: ✅ Valid signature\n  Legal Entity ->> Cardano: AUTH_END\n  Cardano ->> Indexer: Credential revoked\n  Note right of Indexer: ⚠️ Identifier revoked\n  Legal Entity ->> Cardano: ATTEST\n  Cardano ->> Indexer: Identity invalid\n  Note right of Indexer: ❌ No valid credential\n```\n### Establishment of signing authority\nBefore attesting to any transactions, the relevant [credential chain](#credential-chains) for the controller must be published on-chain with the following attributes – most of which are used to help simplify indexing:\n- **t** — A transaction type of `AUTH_BEGIN` is used to establish a signer’s authority using a credential chain.\n- **i** — The identifier of the signer in the CESR qb64 variant. This MUST match the issuee of the leaf credential in the chain.\n- **s** — The schema identifier of the leaf credential in the chain in the CESR qb64 variant. This MUST match the schema of the [leaf credential](#identifying-a-credential-chain-type) in the chain.\n- **c** — The byte-stream of the credential chain in the CESR qb2 or qb64b variant, for brevity.\n- **v** - Version of the CIP and minimum version of KERI and ACDC to ensure compatibility.\n- **m** —  An optional metadata block used to simplify indexing for a particular use-case. For example, the LEI of a legal entity could be contained here.\n\nThe credential chain should contain all credentials, relevant registry events and attachments. There are various types of ACDC registries, so for simplicity: the credential chain MUST validate with an ACDC v1 or v2 verifier, assuming that KEL events are already available.\n\nThese attributes can be embedded in the metadata of a transaction using a fixed metadata label. Compact field labels are used for brevity.\n\nThe metadata is structured as follows:\n```JSON\n{\n  \"170\":\n  {\n    \"t\": \"AUTH_BEGIN\",\n    \"s\": \"{{saidOfLeafCredentialSchema}}\",\n    \"i\": \"{{aidOfSigner}}\",\n    \"c\": \"{{byteStream}}\",\n    \"v\": {\n      \"v\": \"{{CIP Version String}}\",\n      \"k\": \"{{KERI Version String}}\",\n      \"a\": \"{{ACDC Version String}}\"\n    },\n    \"m\": \"{{optionalMetadataBlock}}\"\n  }\n}\n```\nIf valid for a given ecosystem, this transaction establishes the signing authority for `i` from this transaction onwards in the chain. The issuance date of the leaf credential SHOULD be ignored.\n\n### Creation of verifiable records\nTo create a persistent signature over data with KERI, signers can anchor a digest of the data in their KEL, typically using an interaction event. Anchoring ensures that data remains verifiable even if the controller later rotates their keys.\n\n The relevant data recorded for each event includes:\n- **t** — A transaction type of `ATTEST` is to create a verifiable record.\n- **i** — The identifier of the signer in the CESR qb64 variant.\n- **d** — The digest of the data being signed in the CESR qb64 variant.\n- **s** — The sequence number of the KERI event, encoded as a hex string.\n- **v** - Version of the CIP. KERI and ACDC version isn't needed here.\nIf the KEL of identifier `i` contains an event at sequence number `s` which has a seal value of `{ d: \"{{digest}}\" }`, it serves as cryptographically verifiable proof that the data was effectively signed by the controller.\n\nA reference to this event in a metadata transaction is structured as follows:\n```JSON\n{\n    \"170\": {\n    \"t\": \"ATTEST\",\n    \"i\": \"{{aidOfSigner}}\", \n    \"d\": \"{{digest}}\",\n    \"s\": \"{{hexEncodedSequenceNumber}}\",\n    \"v\": {\n      \"v\": \"{{CIP Version String}}\"\n    },\n    },\n    \"YYYY\": \"{{someApplicationMetadata}}\"\n}\n```\nSuch transactions are only considered valid if the digest value is correct, and can be found anchored in the KEL of the controller at the given sequence number.\n\n### Revoking of signing authority\nSigning authority may be removed after a period of time by revoking the relevant credential and publishing this revocation on-chain. As such, the validity of transactions associated with that credential chain are for all valid `ATTEST` transactions between issuance (`AUTH_BEGIN`) and revocation (`AUTH_END`).\n\nThe following attributes are used:\n- **t** — A transaction type of `AUTH_END` is used to remove a signer’s authority with revocation registry events.\n- **i** — The identifier of the signer in the CESR qb64 variant. This MUST match the issuee of the leaf credential in the chain.\n- **s** — The schema identifier of the leaf credential in the chain in the CESR qb64 variant. This MUST match the schema of the leaf credential in the chain.\n- **c** — The byte-stream of the revocation registry events in the CESR qb2 or qb64b variant, for brevity.\n- **v** - Version of the CIP and minimum version of KERI and ACDC to ensure compatibility.\n- **m** — An optional metadata block used to simplify indexing for a particular use-case. For example, the LEI of a legal entity could be contained here.\n\nA reference to this event in a metadata transaction is structured as follows:\n```JSON\n{\n  \"170\":\n  {\n    \"t\": \"AUTH_END\",\n    \"s\": \"{{saidOfLeafCredentialSchema}}\",\n    \"i\": \"{{aidOfSigner}}\",\n    \"c\": \"{{byteStream}}\",\n    \"v\": {\n      \"v\": \"{{CIP Version String}}\",\n      \"k\": \"{{KERI Version String}}\",\n      \"a\": \"{{ACDC Version String}}\"\n    },\n    \"m\": \"{{optionalMetadataBlock}}\"\n  }\n}\n\n```\nIf the successful parsing of the revocation events results in a credential chain that no longer gives authority to the signer, any later `ATTEST` transactions for this credential chain should be ignored (unless there is another subsequent `AUTH_START`).\n\n\n### Reference Example - vLEI\n\nThe Global Legal Entity Identifier Foundation (GLEIF) serves as the root of trust for Legal Entity Identifiers (LEIs) worldwide. Their verifiable variant, the vLEI, is based on the KERI and ACDC standards, and are issued by Qualified vLEI Issuers (QVIs).\n\nLegal entities holding valid vLEI credentials may issue other credentials chained to their vLEI which allows them to delegate authority to other persons or machines.\n\nAs a reference example, we define a `vLEICardanoMetadataSigner` credential. For a given use-case, the issuee of this credential is allowed to sign transaction metadata on Cardano on behalf of a particular legal entity. The LEI of this legal entity is embedded in their Legal Entity vLEI credential.\n\n```mermaid\ngraph LR\n    GLEIF[\"GLEIF Root<br/>(Root of Trust)\"]\n    QVI[\"Qualified vLEI Issuer<br/>Credential\"]\n    LE[\"Legal Entity vLEI<br/>Credential<br/>(contains LEI)\"]\n    SIGNER[\"Cardano Metadata Signer<br/>Credential<br/>(contains metadata labels)\"]\n    \n    GLEIF -->|issues| QVI\n    QVI -->|issues| LE\n    LE -->|issues| SIGNER\n    \n    SIGNER -.->|signs metadata<br/>transactions on| CARDANO[\"Cardano Blockchain\"]\n    \n    style GLEIF fill:#e1f5ff,stroke:#0066cc,stroke-width:2px\n    style QVI fill:#fff4e1,stroke:#cc8800,stroke-width:2px\n    style LE fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px\n    style SIGNER fill:#fce4ec,stroke:#c2185b,stroke-width:2px\n    style CARDANO fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px\n```\n\nThe above diagram contains 3 credentials which are cryptographically chained:\n- **Qualified vLEI Issuer**: Issued by GLEIF to QVI entities.\n- **Legal Entity vLEI**: Issued by a QVI to legal entities.\n- **Cardano Metadata Signer**: Issued by the legal entity to a person or machine who may sign on behalf of the entity.\n\nThe schema for the signer credential may be found here. It contains an attribute `labels` which is an array of metadata label numbers for which the signer has the authority to create verifiable records over.\n\n### Establishment of signing authority\nFor this example, a signer controlling the identifier `EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL` is holding a metadata signer credential valid for label `1447`.\n\nThe following is the expected transaction format to publish the credential chain:\n```JSON\n{\n  \"170\":\n  {\n    \"t\": \"AUTH_BEGIN\",\n    \"s\": \"EJVgEQO8BEhGGM7GcAjlqoKG1upeuBZj9WjvjZo353sQ\",\n    \"i\": \"EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL\",\n    \"c\": \"{{credentialChainByteStream}}\",\n    \"v\": {\n      \"v\": \"1.0\",\n      \"k\": \"KERI10\",\n      \"a\": \"ACDC10\"\n    },\n    \"m\":\n    {\n      \"l\": [1447],\n      \"LEI\": \"50670047U83746F70E20\"\n    }\n  }\n}\n```\nFor ease of indexing, the metadata block is used to contain the LEI of the legal entity, as well as an array of all relevant metadata labels. As such, an indexer can filter based on interested metadata labels, or based on a particular set of legal entities.\n\nThe credential chain `c` should be a qb2 CESR stream containing:\n- Each ACDC credential and corresponding issuance event (`iss`)\n- Registry events for each revocation registry (`vcp`)\n- All necessary CESR attachments\n\nA test example may be found [here](example-credential-chain.cesr) in qb64 format - this should be converted to qb2 before being pushed on-chain.\n\nAfter verifying the validity of the credential chain with an ACDC verifier, there are a number of extra validation steps to complete as business logic:\n1. `EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL` is the issuee of the metadata signer credential with a schema ID of `EJVgEQO8BEhGGM7GcAjlqoKG1upeuBZj9WjvjZo353sQ`.\n2. The label attribute of the credential is `[1447]`.\n3. The LEI attribute of the Legal Entity vLEI credential is `50670047U83746F70E20`.\n4. The Qualified vLEI Issuer credential is issued by GLEIF’s External identifier - [more information](#root-of-trust-discovery)\n\n### Creation of verifiable records\nThe following is an attestation transaction for metadata label `1447`.\n```JSON\n{\n    \"170\": {\n    \"t\": \"ATTEST\",\n    \"i\": \"EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL\", \n    \"d\": \"ELC5L3iBVD77d_MYbYGGCUQgqQBju1o4x1Ud-z2sL-ux\",\n    \"s\": \"1a\",\n    \"v\": {\n      \"v\": \"1.0\"\n    }\n    },\n    \"1447\": \"{{someApplicationMetadata}}\"\n}\n```\n\nValidation steps:\n1. `EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL` currently has signing authority over label 1447.\n2. The CESR digest of the data at label 1447 is `ELC5L3iBVD77d_MYbYGGCUQgqQBju1o4x1Ud-z2sL-ux`.\n3. The event in the controller’s KEL at sequence number `1a` (26th event) is `{ d: “ELC5L3iBVD77d_MYbYGGCUQgqQBju1o4x1Ud-z2sL-ux” }`.\n\n### Revoking signing authority\n\nWhen a credential must be revoked (for example, due to employee termination, credential compromise, or policy changes) the legal entity publishes an `AUTH_END` transaction containing the revocation registry events. A sample revocation event stream can be found [here](example-revocation-event.cesr).\nThe following is an example revocation transaction:\n```JSON\n{\n  \"170\":\n  {\n    \"t\": \"AUTH_END\",\n    \"s\": \"EJVgEQO8BEhGGM7GcAjlqoKG1upeuBZj9WjvjZo353sQ\",\n    \"i\": \"EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL\",\n    \"c\": \"{{revocationRegistryEventsByteStream}}\",\n    \"v\": {\n      \"v\": \"1.0\",\n      \"k\": \"KERI10\",\n      \"a\": \"ACDC10\"\n    },\n    \"m\":\n    {\n      \"l\": [1447],\n      \"LEI\": \"50670047U83746F70E20\"\n    }\n  }\n}\n```\n\nThe revocation registry events in `c` should contain the necessary ACDC registry events that mark the credential as revoked. Once processed by the indexer, the following validation logic applies:\n\n1. The indexer parses the revocation events and validates them against the credential chain.\n\nIf the revocation is valid, the identifier `EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL` loses signing authority for label `1447` from this transaction forward. Any subsequent `ATTEST` transactions using this identifier will be ignored and treated as unverified.\n\nFor example, if the following transaction appears after revocation:\n```JSON\n{\n    \"170\": {\n    \"t\": \"ATTEST\",\n    \"i\": \"EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL\", \n    \"d\": \"ELC5L3iBVD77d_MYbYGGCUQgqQBju1o4x1Ud-z2sL-ux\",\n    \"s\": \"1b\",\n    \"v\": {\n      \"v\": \"1.0\"\n    }\n    },\n    \"1447\": \"{{someApplicationMetadata}}\"\n}\n```\n\nThe indexer will reject this attestation because:\n1. The credential chain for `EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL` has been revoked.\n2. No valid signing authority exists for this identifier on label `1447`.\n3. The transaction is marked as **unverified** and should not be trusted by any application relying on the indexer.\n\nOnly if a new `AUTH_BEGIN` transaction is published with a fresh, valid credential chain would the identifier regain signing authority.\n\n\n## Rationale: How does this CIP achieve its goals?\n\nThis CIP enables entities (including legal entities, organizations, DAOs, and individuals) to cryptographically prove their identity on Cardano by linking verifiable credential chains (such as vLEIs) to on-chain transactions. This connection establishes accountability and transparency, enabling blockchain adoption in highly regulated environments where transactions must be traceable to recognized entities, while also supporting flexible identity frameworks for various use cases beyond traditional corporate structures.\n\n### Achieving Accountability Through Verifiable Identity\n\nThe core goal of establishing accountability is achieved through several key mechanisms:\n\n**Persistent Identity Binding**: By anchoring KERI identifiers in transaction metadata, this CIP creates an immutable, publicly auditable link between a transaction and a specific entity. Unlike traditional blockchain addresses which are pseudonymous, KERI identifiers can be verified against credential chains that ultimately connect to legally recognized entities (e.g., through LEIs issued by GLEIF). This transforms anonymous blockchain activity into accountable actions.\n\n**Temporal Authority Control**: The `AUTH_BEGIN` and `AUTH_END` lifecycle allows precise control over when an identifier has signing authority. This supports real-world scenarios like employee onboarding/offboarding or credential expiration, ensuring that only authorized representatives can act on behalf of an entity at any given time. Indexers can deterministically verify whether any attestation was made during a valid authority period.\n\n**Multi-Layer Verification**: The credential chain structure enables verification at multiple levels—from cryptographic signature validity, to credential issuance by authorized issuers, to the root of trust (e.g., GLEIF). This layered approach means that breaking accountability would require compromising multiple independent systems, not just a single private key.\n\n### Design Trade-offs\n\nThe metadata-based approach was chosen for its simplicity and flexibility:\n\n**Advantages:**\n- Straightforward implementation for wallets and transaction builders\n- Flexible credential schemas without protocol changes\n- Full backward compatibility with existing infrastructure\n\n**Limitations:**\n- Validation must occur off-chain through indexers (smart contracts cannot enforce credential checks) - This limitation can be solved by writing another CIP or extending this\n- Requires additional infrastructure (indexers, KERI watcher networks)\n\nThe metadata is immutably recorded on-chain, and anyone can independently verify the cryptographic proofs by validating the credential chains against published Key Event Logs.\n\n### Cryptographic Trust\n\nUnlike oracle networks that rely on consensus among multiple nodes, KERI-based verification relies purely on cryptographic signatures and tamper-evident event logs. Verifiers can independently validate credentials without trusting any third party—the only trust assumption is in the root of trust (e.g., GLEIF for vLEIs), which is already established in real-world legal frameworks.\n\nBy adopting KERI, an existing standard from the Trust over IP Foundation, this CIP ensures interoperability across ecosystems, credential portability, and alignment with emerging regulatory requirements for digital identity. This standards-based approach means that implementations can leverage existing tooling, benefit from ongoing security research, and maintain compatibility as the KERI ecosystem evolves.\n\n## Path to Active \n\n### Acceptance Criteria\n\nIn order for this standard to be considered Active, the following MUST be true:\n\n- [ ] At least one production-grade implementation of KERI-backed metadata attestations is available on mainnet (e.g. in a wallet, identity service, or infrastructure component).\n- [ ] At least one independent Cardano dApp or off-chain service is using these KERI-backed attestations in its business logic (e.g. access control, compliance/audit trail, or identity-bound actions).\n- [ ] At least one independent identity verifier operated by the Cardano Foundation (or another recognized governance/standards body) is publishing and maintaining KERI identifiers and corresponding ACDC credential chains for Cardano-related entities.\n- [ ] The specification is stable and implementers report no blocking ambiguities in representing KERI identifiers or ACDC chains within Cardano metadata.\n\n### Implementation Plan\n\n- [ ] Coordinate with at least infrastructure provider (e.g. **reeve.technology**, **veridian.id**) to ship a reference mainnet implementation of this CIP.\n- [ ] Deploy and operate an identity verifier instance under the Cardano Foundation (or equivalent) that issues and maintains KERI identifiers and ACDC credential chains for Cardano ecosystem entities.\n- [ ] Engage with at least one entity to integrate KERI-backed metadata attestations for a real use case (e.g. vLEI-backed authorization, regulated workflow, or enterprise audit logging).\n- [ ] Collect feedback from implementers and, if needed, submit minor, backwards-compatible clarifications to this CIP before requesting status transition to Active.\n\n## Appendix\n\n### Credential chains\n\nACDCs can be chained together cryptographically in a similar manner to traditional X.509 certificate chains, yet with far more power and flexibility.\n\nFor a given ecosystem, there may be a particular credential chain type that can be used to create bindings between controllers and entities or people. For example, in the vLEI ecosystem, credential chains may be used to create a binding between a legal entity and one of its employees that has the authority to sign transactions on its behalf. The root of trust in the vLEI ecosystem is GLEIF.\n\n### Identifying a credential chain type\n\nVarious credential chain types may represent various forms of compliance or bindings so it's important to be able to differentiate between credential chain types so that chain indexers can more easily filter out irrelevant transactions.\n\nFor this, the schema ID of the leaf credential in the credential chain may be used - that is, the credential which will be held by the person or software attesting to the metadata transaction. This is the strongest indicator of the credential chain type as child credential schemas reference parent credential schemas in a cryptographically strong manner.\n\n### Discovery via Out-of-Band-Introductions (OOBIs)\n\nIn the context of this CIP, an OOBI provides a mechanism to discover verifiable information related to an identifier at an endpoint, such as the Key Event Log related to that identifier. All data is still verifiably signed, but a watcher network should be used to reduce the risk of discovering a forked, but verifiable version of a KEL.\n\n### Root of trust discovery\n\nGLEIF serves as the root of trust in the vLEI ecosystem. Discovery of their GLEIF Root identifier therefore must be carefully managed to avoid a Man-in-the-Middle attack where an attacker redirects a verifier to a different root identifier that is also verifiable.\n\nGLEIF has published their identifiers in various mediums such as various GitHub organizations, websites and hardcopy publications to mitigate the risk of an attacker compromising each medium, and [here](https://gleif-it.github.io/.well-known/) is one such location. The issuer of production QVI credentials is the GLEIF External, which is delegated from the GLEIF Root.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n"
  },
  {
    "path": "CIP-0170/example-credential-chain.cesr",
    "content": "{\n    \"v\": \"KERI10JSON000113_\",\n    \"t\": \"vcp\",\n    \"d\": \"EFfQPwW9s8HQV-zq2NTGks_WYT79Z046mhIJwPQxlfn0\",\n    \"i\": \"EFfQPwW9s8HQV-zq2NTGks_WYT79Z046mhIJwPQxlfn0\",\n    \"ii\": \"EOosFLj1gOfRFEx5g5TSCPdpml9jM9_jIaWI5pZO5YCU\",\n    \"s\": \"0\",\n    \"c\": [\n        \"NB\"\n    ],\n    \"bt\": \"0\",\n    \"b\": [],\n    \"n\": \"AFltXlPUmiWy8_v8d9f6jj1E2l7LX1UWjU7hGtrp-1xW\"\n}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAABEKiuK7uqunvbRxirmi9gqfuOGfQSZuqCT9b0WEVFx_Cf\n{\n    \"v\": \"KERI10JSON000113_\",\n    \"t\": \"vcp\",\n    \"d\": \"EOzV2Oj64Wwe9QetkB_FCmIvoTI_6OKn7nB4W51wJQ-a\",\n    \"i\": \"EOzV2Oj64Wwe9QetkB_FCmIvoTI_6OKn7nB4W51wJQ-a\",\n    \"ii\": \"EARtegK3M61uNJ5wyuznNjngYP0kJm1-KHv5fh-8UFWS\",\n    \"s\": \"0\",\n    \"c\": [\n        \"NB\"\n    ],\n    \"bt\": \"0\",\n    \"b\": [],\n    \"n\": \"AM0aXrE5B79nt1_FOffK7N_rMw1VkYLRe1KB60rwRplM\"\n}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAABEPQN2EE4bNWu6-1vXoLMfTUumlHFEAr9-p4_CeoxfchP\n{\n    \"v\": \"KERI10JSON000113_\",\n    \"t\": \"vcp\",\n    \"d\": \"EOWTJBCuCpDtamFQrepwyC2WwbsOzWIP0fhRnT8eZeLC\",\n    \"i\": \"EOWTJBCuCpDtamFQrepwyC2WwbsOzWIP0fhRnT8eZeLC\",\n    \"ii\": \"EF--c3_VLg-aaoI-y9kKc0XSQD2-bZoiyk0U7Vym9p-l\",\n    \"s\": \"0\",\n    \"c\": [\n        \"NB\"\n    ],\n    \"bt\": \"0\",\n    \"b\": [],\n    \"n\": \"AG_SUFGr-Nvk_t1Z7QUAjwsjoFw9GF4tZEt8IcNwrjFe\"\n}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAABEFVhm8TjehsDvAJGxlI5ufy_Mxd5j-B1KSqB-YLC1JWV\n{\n    \"v\": \"KERI10JSON0000ed_\",\n    \"t\": \"iss\",\n    \"d\": \"EOkDhM2BZL2dXuWydnDvIl7kWj5q2bVZXnPNLtr1Wtop\",\n    \"i\": \"EIUaX_JLblNtJQQg0gh7Ka4h64gbwOhqlPl9QC-7M6DZ\",\n    \"s\": \"0\",\n    \"ri\": \"EFfQPwW9s8HQV-zq2NTGks_WYT79Z046mhIJwPQxlfn0\",\n    \"dt\": \"2025-11-10T11:43:47.242000+00:00\"\n}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAACEDFK7pUh-Ez7kk0knpLl1m8iA59_BE4_Rkv8QtHMbRuE\n{\n    \"v\": \"KERI10JSON0000ed_\",\n    \"t\": \"iss\",\n    \"d\": \"ELlER5cq0f8sPsZKjz_jcdegz65uErDiCqfbYlYQHlim\",\n    \"i\": \"EBK-BG-8-ZhvQ7ml52PWOVJn30IUviSeC7VepeU_mZXK\",\n    \"s\": \"0\",\n    \"ri\": \"EOzV2Oj64Wwe9QetkB_FCmIvoTI_6OKn7nB4W51wJQ-a\",\n    \"dt\": \"2025-11-10T11:43:51.081000+00:00\"\n}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAACEIXsXeDBh9kSbE4pvn3uCPzKxE9Pkg4t-JuRKyLGrUI9\n{\n    \"v\": \"KERI10JSON0000ed_\",\n    \"t\": \"iss\",\n    \"d\": \"EOyo58VXZv4qVVs8jczoTmFlwffJDC8yirqpqecFW3jj\",\n    \"i\": \"EPSkZ1-E6ojESV9mt20vA0YUfoYAD8dxYyn4-ochHMtV\",\n    \"s\": \"0\",\n    \"ri\": \"EOWTJBCuCpDtamFQrepwyC2WwbsOzWIP0fhRnT8eZeLC\",\n    \"dt\": \"2025-11-10T11:43:58.630000+00:00\"\n}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAACEFuQPJfiOsO71geAaItT4DGH7xr0ZtaDs8ycsnpxki6k\n{\n    \"v\": \"ACDC10JSON000197_\",\n    \"d\": \"EIUaX_JLblNtJQQg0gh7Ka4h64gbwOhqlPl9QC-7M6DZ\",\n    \"i\": \"EOosFLj1gOfRFEx5g5TSCPdpml9jM9_jIaWI5pZO5YCU\",\n    \"ri\": \"EFfQPwW9s8HQV-zq2NTGks_WYT79Z046mhIJwPQxlfn0\",\n    \"s\": \"EBfdlu8R27Fbx-ehrqwImnK-8Cm79sqbAQ4MmvEAYqao\",\n    \"a\": {\n        \"d\": \"EC9iDB-5CIrhu_R68eXQ9HgDT_vxTqSPZXU-TPVzr6-F\",\n        \"i\": \"EARtegK3M61uNJ5wyuznNjngYP0kJm1-KHv5fh-8UFWS\",\n        \"dt\": \"2025-11-10T11:43:47.242000+00:00\",\n        \"LEI\": \"50670047U83746F70E20\"\n    }\n}-IABEIUaX_JLblNtJQQg0gh7Ka4h64gbwOhqlPl9QC-7M6DZ0AAAAAAAAAAAAAAAAAAAAAAAEOkDhM2BZL2dXuWydnDvIl7kWj5q2bVZXnPNLtr1Wtop\n{\n    \"v\": \"ACDC10JSON0005c8_\",\n    \"d\": \"EBK-BG-8-ZhvQ7ml52PWOVJn30IUviSeC7VepeU_mZXK\",\n    \"i\": \"EARtegK3M61uNJ5wyuznNjngYP0kJm1-KHv5fh-8UFWS\",\n    \"ri\": \"EOzV2Oj64Wwe9QetkB_FCmIvoTI_6OKn7nB4W51wJQ-a\",\n    \"s\": \"ENPXp1vQzRF6JwIuS-mp2U8Uf1MoADoP_GqQ62VsDZWY\",\n    \"a\": {\n        \"d\": \"EB9PCr5APfA1o9LRkO45kijrvoQuH1N5Te4U5JhjpzOO\",\n        \"i\": \"EF--c3_VLg-aaoI-y9kKc0XSQD2-bZoiyk0U7Vym9p-l\",\n        \"dt\": \"2025-11-10T11:43:51.081000+00:00\",\n        \"LEI\": \"50670047U83746F70E20\"\n    },\n    \"e\": {\n        \"d\": \"EC4U5Yxjv1TbJm6fVwi9b_mPr1kpqyv0EQM9Gb0AKDz8\",\n        \"qvi\": {\n            \"n\": \"EIUaX_JLblNtJQQg0gh7Ka4h64gbwOhqlPl9QC-7M6DZ\",\n            \"s\": \"EBfdlu8R27Fbx-ehrqwImnK-8Cm79sqbAQ4MmvEAYqao\"\n        }\n    },\n    \"r\": {\n        \"d\": \"EGZ97EjPSINR-O-KHDN_uw4fdrTxeuRXrqT5ZHHQJujQ\",\n        \"usageDisclaimer\": {\n            \"l\": \"Usage of a valid, unexpired, and non-revoked vLEI Credential, as defined in the associated Ecosystem Governance Framework, does not assert that the Legal Entity is trustworthy, honest, reputable in its business dealings, safe to do business with, or compliant with any laws or that an implied or expressly intended purpose will be fulfilled.\"\n        },\n        \"issuanceDisclaimer\": {\n            \"l\": \"All information in a valid, unexpired, and non-revoked vLEI Credential, as defined in the associated Ecosystem Governance Framework, is accurate as of the date the validation process was complete. The vLEI Credential has been issued to the legal entity or person named in the vLEI Credential as the subject; and the qualified vLEI Issuer exercised reasonable care to perform the validation process set forth in the vLEI Ecosystem Governance Framework.\"\n        }\n    }\n}-IABEBK-BG-8-ZhvQ7ml52PWOVJn30IUviSeC7VepeU_mZXK0AAAAAAAAAAAAAAAAAAAAAAAELlER5cq0f8sPsZKjz_jcdegz65uErDiCqfbYlYQHlim\n{\n    \"v\": \"ACDC10JSON000230_\",\n    \"d\": \"EPSkZ1-E6ojESV9mt20vA0YUfoYAD8dxYyn4-ochHMtV\",\n    \"i\": \"EF--c3_VLg-aaoI-y9kKc0XSQD2-bZoiyk0U7Vym9p-l\",\n    \"ri\": \"EOWTJBCuCpDtamFQrepwyC2WwbsOzWIP0fhRnT8eZeLC\",\n    \"s\": \"EJVgEQO8BEhGGM7GcAjlqoKG1upeuBZj9WjvjZo353sQ\",\n    \"a\": {\n        \"d\": \"EKGU79bIkzxFsr-ZcoOLyZyX5mD4ScRbylGNNVbeiOW3\",\n        \"i\": \"EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL\",\n        \"dt\": \"2025-11-10T11:43:58.630000+00:00\",\n        \"labels\": [\n            1447\n        ]\n    },\n    \"e\": {\n        \"d\": \"EPvTf6H9kJBJ87jDXR-IM-jSwWoGwQ_AhuwnIpq0lhqG\",\n        \"le\": {\n            \"n\": \"EBK-BG-8-ZhvQ7ml52PWOVJn30IUviSeC7VepeU_mZXK\",\n            \"s\": \"ENPXp1vQzRF6JwIuS-mp2U8Uf1MoADoP_GqQ62VsDZWY\"\n        }\n    }\n}-IABEPSkZ1-E6ojESV9mt20vA0YUfoYAD8dxYyn4-ochHMtV0AAAAAAAAAAAAAAAAAAAAAAAEOyo58VXZv4qVVs8jczoTmFlwffJDC8yirqpqecFW3jj"
  },
  {
    "path": "CIP-0170/example-revocation-event.cesr",
    "content": "{\n    \"v\": \"KERI10JSON000120_\",\n    \"t\": \"rev\",\n    \"d\": \"EIYQA02v1cjNrPn1KhIZXof56LRLmCNPWnaeSyZ87KeU\",\n    \"i\": \"EPSkZ1-E6ojESV9mt20vA0YUfoYAD8dxYyn4-ochHMtV\",\n    \"s\": \"1\",\n    \"ri\": \"EOWTJBCuCpDtamFQrepwyC2WwbsOzWIP0fhRnT8eZeLC\",\n    \"p\": \"EOyo58VXZv4qVVs8jczoTmFlwffJDC8yirqpqecFW3jj\",\n    \"dt\": \"2025-11-10T13:00:40.243000+00:00\"\n}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAADEDNyGD0Vt0UgfX3NZuf3JhHY34kTzxGZfhApeISBCBUI"
  },
  {
    "path": "CIP-0170/version_1.cddl",
    "content": "cardano_keri_metadata = {\n  ? uint => auth_event\n}\n\nauth_event = \n  auth_begin /\n  auth_end /\n  attest\n\nauth_begin = {\n  t: \"AUTH_BEGIN\",\n  s: text,          ; SAID of leaf credential schema\n  i: text,          ; AID of signer\n  c: bytes,         ; Byte stream payload\n  ? m: metadata_map ; Optional metadata\n}\n\nattest = {\n  t: \"ATTEST\",\n  i: text,          ; AID of signer\n  d: text,          ; Digest\n  s: text           ; Hex-encoded sequence number\n}\n\nauth_end = {\n  t: \"AUTH_END\",\n  s: text,          ; SAID of leaf credential schema\n  i: text,          ; AID of signer\n  c: bytes,         ; Byte stream payload\n  ? m: metadata_map ; Optional metadata\n}\n\nmetadata_map = {\n  * text => any\n}\n"
  },
  {
    "path": "CIP-0170/version_1.json",
    "content": "{\n    \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n    \"title\": \"Cardano KERI Accountability Metadata\",\n    \"description\": \"Metadata schema for embedding KERI identifiers and authentication events (AUTH_BEGIN, ATTEST, AUTH_END) within Cardano transactions.\",\n    \"type\": \"object\",\n    \"patternProperties\": {\n        \"^[0-9]+$\": {\n            \"description\": \"Metadata label key (integer as string).\",\n            \"oneOf\": [\n                {\n                    \"type\": \"object\",\n                    \"properties\": {\n                        \"t\": {\n                            \"const\": \"AUTH_BEGIN\"\n                        },\n                        \"s\": {\n                            \"type\": \"string\",\n                            \"description\": \"Self-addressing identifier (SAID) of the leaf credential schema.\"\n                        },\n                        \"i\": {\n                            \"type\": \"string\",\n                            \"description\": \"Autonomic Identifier (AID) of the signer.\"\n                        },\n                        \"c\": {\n                            \"type\": \"string\",\n                            \"description\": \"Byte stream representing the credential or context.\"\n                        },\n                        \"m\": {\n                            \"type\": \"object\",\n                            \"description\": \"Optional metadata block.\",\n                            \"additionalProperties\": true\n                        }\n                    },\n                    \"required\": [\n                        \"t\",\n                        \"s\",\n                        \"i\",\n                        \"c\"\n                    ],\n                    \"additionalProperties\": false\n                },\n                {\n                    \"type\": \"object\",\n                    \"properties\": {\n                        \"t\": {\n                            \"const\": \"ATTEST\"\n                        },\n                        \"i\": {\n                            \"type\": \"string\",\n                            \"description\": \"Autonomic Identifier (AID) of the signer.\"\n                        },\n                        \"d\": {\n                            \"type\": \"string\",\n                            \"description\": \"Digest referencing the authenticated data.\"\n                        },\n                        \"s\": {\n                            \"type\": \"string\",\n                            \"pattern\": \"^[0-9A-Fa-f]+$\",\n                            \"description\": \"Hex-encoded sequence number.\"\n                        }\n                    },\n                    \"required\": [\n                        \"t\",\n                        \"i\",\n                        \"d\",\n                        \"s\"\n                    ],\n                    \"additionalProperties\": false\n                },\n                {\n                    \"type\": \"object\",\n                    \"properties\": {\n                        \"t\": {\n                            \"const\": \"AUTH_END\"\n                        },\n                        \"s\": {\n                            \"type\": \"string\",\n                            \"description\": \"Self-addressing identifier (SAID) of the leaf credential schema.\"\n                        },\n                        \"i\": {\n                            \"type\": \"string\",\n                            \"description\": \"Autonomic Identifier (AID) of the signer.\"\n                        },\n                        \"c\": {\n                            \"type\": \"string\",\n                            \"description\": \"Byte stream representing the credential or closing context.\"\n                        },\n                        \"m\": {\n                            \"type\": \"object\",\n                            \"description\": \"Optional metadata block.\",\n                            \"additionalProperties\": true\n                        }\n                    },\n                    \"required\": [\n                        \"t\",\n                        \"s\",\n                        \"i\",\n                        \"c\"\n                    ],\n                    \"additionalProperties\": false\n                }\n            ]\n        }\n    },\n    \"additionalProperties\": false\n}"
  },
  {
    "path": "CIP-0170/vlei-cardano-metadata-signer-credential.json",
    "content": "{\n    \"$id\": \"EJVgEQO8BEhGGM7GcAjlqoKG1upeuBZj9WjvjZo353sQ\",\n    \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n    \"title\": \"vLEI Cardano Metadata Signer Credential\",\n    \"description\": \"A vLEI Cardano Metadata Signer Credential issued to a person or machine which may sign metadata embedded in Cardano transactions on behalf of a Legal Entity\",\n    \"type\": \"object\",\n    \"credentialType\": \"vLEICardanoMetadataSignerCredential\",\n    \"version\": \"1.0.0\",\n    \"properties\": {\n        \"v\": {\n            \"description\": \"Version\",\n            \"type\": \"string\"\n        },\n        \"d\": {\n            \"description\": \"Credential SAID\",\n            \"type\": \"string\"\n        },\n        \"i\": {\n            \"description\": \"Issuer AID\",\n            \"type\": \"string\"\n        },\n        \"ri\": {\n            \"description\": \"Credential status registry\",\n            \"type\": \"string\"\n        },\n        \"s\": {\n            \"description\": \"Schema SAID\",\n            \"type\": \"string\"\n        },\n        \"a\": {\n            \"oneOf\": [\n                {\n                    \"description\": \"Attributes block SAID\",\n                    \"type\": \"string\"\n                },\n                {\n                    \"$id\": \"EBCRiKplQ_uucawOH7lVt0PErQs_9Y2coohaC12zy8f3\",\n                    \"description\": \"Attributes block\",\n                    \"type\": \"object\",\n                    \"properties\": {\n                        \"d\": {\n                            \"description\": \"Attributes block SAID\",\n                            \"type\": \"string\"\n                        },\n                        \"i\": {\n                            \"description\": \"Issuee AID\",\n                            \"type\": \"string\"\n                        },\n                        \"dt\": {\n                            \"description\": \"Issuance date time\",\n                            \"type\": \"string\",\n                            \"format\": \"date-time\"\n                        },\n                        \"labels\": {\n                            \"description\": \"Array of metadata labels that can be signed\",\n                            \"type\": \"array\",\n                            \"items\": {\n                                \"type\": \"number\"\n                            }\n                        }\n                    },\n                    \"additionalProperties\": false,\n                    \"required\": [\n                        \"i\",\n                        \"dt\",\n                        \"labels\"\n                    ]\n                }\n            ]\n        },\n        \"e\": {\n            \"oneOf\": [\n                {\n                    \"description\": \"Edges block SAID\",\n                    \"type\": \"string\"\n                },\n                {\n                    \"$id\": \"EHeZGaLBhCc_-sAcyAEgFFeCkxgnqCubPOBuEvoh9jHX\",\n                    \"description\": \"Edges block for issuance from Legal Entity\",\n                    \"type\": \"object\",\n                    \"properties\": {\n                        \"d\": {\n                            \"description\": \"SAID of edges block\",\n                            \"type\": \"string\"\n                        },\n                        \"le\": {\n                            \"description\": \"Chain to legal entity vLEI credential\",\n                            \"type\": \"object\",\n                            \"properties\": {\n                                \"n\": {\n                                    \"description\": \"SAID of the ACDC to which the edge connects\",\n                                    \"type\": \"string\"\n                                },\n                                \"s\": {\n                                    \"description\": \"SAID of required schema of the credential pointed to by this node\",\n                                    \"type\": \"string\",\n                                    \"const\": \"ENPXp1vQzRF6JwIuS-mp2U8Uf1MoADoP_GqQ62VsDZWY\"\n                                }\n                            },\n                            \"additionalProperties\": false,\n                            \"required\": [\n                                \"n\",\n                                \"s\"\n                            ]\n                        }\n                    },\n                    \"additionalProperties\": false,\n                    \"required\": [\n                        \"d\",\n                        \"le\"\n                    ]\n                }\n            ]\n        }\n    },\n    \"additionalProperties\": false,\n    \"required\": [\n        \"v\",\n        \"i\",\n        \"ri\",\n        \"s\",\n        \"d\",\n        \"a\",\n        \"e\"\n    ]\n}"
  },
  {
    "path": "CIP-0171/README.md",
    "content": "---\nCIP: 171\nTitle: On-chain Smart Contract Bytecode Verification\nCategory: Metadata\nStatus: Proposed\nAuthors:\n    - Giovanni Gargiulo <gargiulo.gianni@gmail.com>\nImplementors: []\nDiscussions:\n    - Forum Discussion: https://forum.cardano.org/t/cip-idea-smart-contract-source-code-verification-metadata/152403\n    - Original PR: https://github.com/cardano-foundation/CIPs/pull/1136\nCreated: 2026-01-19\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis CIP defines a decentralized, on-chain metadata standard for linking Cardano script hashes to their published source code. Using transaction metadata label `1984`, anyone can publish records containing the source repository URL, git commit hash, compiler type and version, and script parameters. Verifiers can then independently compile the source and confirm that the resulting script hash matches an on-chain script, establishing a verified link between the deployed script and its source code origin.\n\nUnlike centralized verification services that act as trusted intermediaries, this standard enables permissionless verification where anyone can submit and validate records without relying on third parties. The design is intentionally spam-resistant: invalid or fabricated submissions are harmless because non-matching script hashes simply have no corresponding on-chain scripts to link to.\n\nThis standard supports multiple Cardano smart contract compilers including Aiken, Plutarch, PlutusTx, Scalus, plu-ts, and OpShin, with a mechanism for adding new compilers as they emerge.\n\n## Motivation: Why is this CIP necessary?\n\n### The Problem\n\nUsers regularly interact with Cardano smart contracts without any practical way to verify that an on-chain script was produced from source code they have reviewed or that has been audited. This creates a trust gap: users must either blindly trust contract deployers or rely on third-party verification services.\n\nOn other blockchain platforms like Ethereum, verification typically depends on centralized services such as Etherscan. While functional, this approach introduces a single point of trust and potential failure. Cardano currently lacks any standardized mechanism for linking scripts to their source code, centralized or otherwise.\n\n### Why Decentralization Matters\n\nCentralized verification services present several concerns:\n\n- **Single point of failure**: Service downtime means no verification\n- **Trust assumption**: Users must trust the service operator\n- **Gatekeeping potential**: Services can choose what to verify or display\n- **Permanence risk**: Services may discontinue or change policies\n\nA decentralized standard stores verification data on-chain, making it permanently available, independently verifiable, and free from any single party's control.\n\n### Permissionless Design\n\nThis standard allows anyone to submit verification metadata, not just the original contract deployer. This permissionless approach provides several benefits:\n\n- **Third-party verification**: Auditors, security researchers, or community members can submit verification records for scripts they have analyzed\n- **No gatekeeper**: Deployers who neglect or refuse to verify their scripts can still have their code verified by others\n- **Spam resistance**: Invalid submissions are self-invalidating. If someone submits fabricated metadata, the resulting script hash will not match any on-chain script. These orphaned records are harmless noise that verifiers simply ignore.\n\n### Use Cases\n\n- **Wallets**: Display verification status before users sign transactions interacting with a script\n- **Block explorers**: Show verified source code alongside script details\n- **dApp developers**: Provide cryptographic proof linking their on-chain scripts to published source\n- **Auditors**: Confirm that an on-chain script was produced from audited source code\n- **Security researchers**: Independently verify the source origin of any on-chain script\n\n## Specification\n\n### Metadata Label\n\nThis standard uses transaction metadata label **1984**, registered in CIP-0010.\n\nThe label was chosen for its cultural reference to themes of trust and transparency, and for being easily memorable.\n\n### Data Structure Overview\n\nVerification metadata is encoded as CBOR PlutusData and stored under metadata label 1984. Due to Cardano's 64-byte limit on individual metadata bytestrings, the PlutusData is serialized to CBOR, split into chunks of at most 64 bytes, and stored as an array.\n\nThe top-level structure is:\n\n```\n{ 1984: [ <chunk1>, <chunk2>, ..., <chunkN> ] }\n```\n\nWhen reassembled, the chunks form a PlutusData structure using a constructor to identify the compiler type.\n\n### Compiler and Schema Versioning\n\nCompilers and their metadata schema versions are identified by PlutusData constructor IDs. Each constructor uniquely identifies both the compiler and the schema version used to encode the verification metadata.\n\n| Constructor ID | Compiler | Schema Version | Language |\n|----------------|----------|----------------|----------|\n| 0 | Aiken | 1 | Aiken |\n| 1 | Plutarch | 1 | Haskell |\n| 2 | PlutusTx | 1 | Haskell |\n| 3 | Scalus | 1 | Scala |\n| 4 | plu-ts | 1 | TypeScript |\n| 5 | OpShin | 1 | Python |\n\nThis design allows each compiler's metadata schema to evolve independently. If a compiler requires changes to its field layout (adding, removing, or reordering fields), a new constructor ID is assigned for the updated schema version. Implementations encountering an unrecognized constructor SHOULD ignore the record rather than fail.\n\nNew compilers or schema versions may be added by submitting a pull request to this CIP. Constructor IDs are assigned sequentially and MUST NOT be reused or reassigned.\n\n### Field Layout\n\nThe constructor's fields contain the following data in order:\n\n| Index | Field | Type | Required | Description |\n|-------|-------|------|----------|-------------|\n| 0 | sourceUrl | Bytes (UTF-8) | Yes | Git-compatible repository URL |\n| 1 | commitHash | Bytes | Yes | Git commit hash (20 bytes for SHA-1, 32 bytes for SHA-256) |\n| 2 | sourcePath | Bytes (UTF-8) | No | Path to source file within repository (empty if root) |\n| 3 | compilerVersion | Bytes (UTF-8) | Yes | Exact compiler version string (e.g., \"v1.1.3\") |\n| 4 | parameters | Map | No | Script hash to parameter data mappings |\n\n#### Source URL\n\nThe `sourceUrl` field accepts any URL compatible with `git clone`. This includes but is not limited to:\n\n- GitHub: `https://github.com/org/repo`\n- GitLab: `https://gitlab.com/org/repo`\n- Codeberg: `https://codeberg.org/org/repo`\n- Self-hosted: `https://git.example.com/repo`\n- SSH URLs: `git@github.com:org/repo.git`\n\nImplementations MUST NOT assume any particular git hosting provider.\n\n#### Commit Hash\n\nThe `commitHash` field contains the raw bytes of the git commit hash. Standard git repositories use SHA-1 (20 bytes), while repositories with SHA-256 enabled use 32 bytes.\n\n#### Compiler Version\n\nThe `compilerVersion` field MUST contain the exact version string required to reproduce the compilation. Partial versions (e.g., \"v1.x\" or \"latest\") are invalid.\n\n#### Parameters\n\nThe `parameters` field maps script hashes to their initialization parameters. This supports parameterized scripts where the same source code produces different script hashes depending on input parameters.\n\nStructure:\n```\nMap<ScriptHash, List<PlutusData>>\n```\n\nWhere:\n- `ScriptHash` is the 28-byte Blake2b-224 hash of the compiled script\n- `List<PlutusData>` contains the parameters applied to produce that specific script\n\n### CDDL Schema\n\n```cddl\nverification_metadata = { 1984: chunked_plutus_data }\n\nchunked_plutus_data = [ + bounded_bytes ]\n\nbounded_bytes = bytes .size (1..64)\n\n; When chunks are concatenated and decoded as CBOR:\n; Constructor ID encodes both compiler and schema version\nverification_data = #6.121([compiler_fields])  ; Constructor 0 = Aiken, schema v1\n                  / #6.122([compiler_fields])  ; Constructor 1 = Plutarch, schema v1\n                  / #6.123([compiler_fields])  ; Constructor 2 = PlutusTx, schema v1\n                  / #6.124([compiler_fields])  ; Constructor 3 = Scalus, schema v1\n                  / #6.125([compiler_fields])  ; Constructor 4 = plu-ts, schema v1\n                  / #6.126([compiler_fields])  ; Constructor 5 = OpShin, schema v1\n                  ; Future schema versions will be assigned new constructor IDs\n\ncompiler_fields = [\n    source_url,\n    commit_hash,\n    source_path / null,\n    compiler_version,\n    ? parameters\n]\n\nsource_url = bytes          ; UTF-8 encoded URL\ncommit_hash = bytes         ; 20 or 32 bytes\nsource_path = bytes         ; UTF-8 encoded path\ncompiler_version = bytes    ; UTF-8 encoded version string\n\nparameters = { * script_hash => parameter_list }\nscript_hash = bytes .size 28\nparameter_list = [ * plutus_data ]\n\nplutus_data = #6.121([* plutus_data])   ; Constr 0\n            / #6.122([* plutus_data])   ; Constr 1\n            / { * plutus_data => plutus_data }\n            / [ * plutus_data ]\n            / int\n            / bytes\n```\n\n### Verification Process\n\nTo verify a script using this metadata:\n\n1. **Retrieve metadata**: Query the blockchain for transactions containing metadata label 1984\n2. **Reassemble chunks**: Concatenate the bytestring array and decode as CBOR PlutusData\n3. **Extract fields**: Parse the constructor ID (compiler type) and fields\n4. **Clone source**: Clone the repository at the specified commit hash\n5. **Compile**: Using the specified compiler and version, compile the source with any provided parameters\n6. **Compute script hash**: Calculate the Blake2b-224 hash of the resulting UPLC bytecode\n7. **Match**: If the computed script hash matches an on-chain script hash, the link is verified\n\nA script's source is considered **verified** if and only if the script hash derived from compiling the referenced source exactly matches the on-chain script hash.\n\n### Compiler Reproducibility Requirements\n\nAchieving reproducible builds requires precise control over the compilation environment. Different compiler flags, optimization levels, or even minor version differences can produce different bytecode from identical source code.\n\nCompiler developers integrating with this standard SHOULD document:\n\n1. **Deterministic compilation flags**: Any flags or parameters required to produce deterministic output\n2. **Environment constraints**: Required runtime versions, dependencies, or system configurations\n3. **Known non-determinism sources**: Any compiler behaviors that may produce varying output and how to mitigate them\n\nVerification tool implementers SHOULD maintain documentation linking to compiler-specific reproducibility guidance.\n\nVerification metadata submitters MUST use the exact compiler version string that produces the matching bytecode. Using approximate versions will result in verification failures.\n\n## Rationale: How does this CIP achieve its goals?\n\n### Why Transaction Metadata?\n\nTransaction metadata provides an ideal storage mechanism for verification records:\n\n- **Lightweight**: No UTxO creation or consumption required\n- **Permanent**: Data persists on-chain indefinitely\n- **Queryable**: Indexers can efficiently filter by metadata label\n- **Established pattern**: Follows precedent set by CIP-0010, CIP-0025, CIP-0088, and others\n\nAlternative approaches were considered and rejected:\n\n- **Datum storage**: Requires UTxO management and incurs higher costs\n- **Off-chain databases**: Introduces trust assumptions and availability concerns\n- **Centralized registries**: Contradicts decentralization goals\n\n### Why Permissionless Submission?\n\nRequiring deployer signatures for verification would limit the standard's utility:\n\n- Deployers may neglect verification\n- Deployers may become unreachable\n- Third-party auditors could not independently verify scripts\n\nThe permissionless model allows anyone with access to the source code to submit verification records. This maximizes coverage while maintaining integrity through hash matching.\n\nInvalid submissions pose no threat to the system. A malicious actor submitting fabricated metadata gains nothing: the script hash computed from their fake source will not match any on-chain script. Verifiers simply ignore non-matching records.\n\n### Why Constructor-Based Compiler and Schema Encoding?\n\nUsing PlutusData constructors to identify both compiler and schema version provides several advantages:\n\n- **Compact**: Single integer vs. multiple fields for compiler name and schema version\n- **Self-describing**: The constructor alone tells parsers exactly how to decode the fields\n- **Unambiguous**: No string matching or normalization required\n- **Extensible**: New constructors can be added without breaking existing parsers\n- **Independent evolution**: Each compiler's schema can evolve independently by adding new constructor IDs\n- **Type-safe**: Unrecognized constructor IDs are cleanly ignored\n\nString-based compiler names would require case normalization, typo handling, and version disambiguation that constructors avoid entirely. A separate schema version field would add bytes to every record and require parsers to read the version before knowing how to decode the remaining fields.\n\n### Git URL Flexibility\n\nEarly feedback requested that the standard not assume GitHub as the hosting provider. The `sourceUrl` field accepts any git-compatible URL, supporting:\n\n- Major hosting platforms (GitHub, GitLab, Bitbucket, Codeberg)\n- Self-hosted git servers\n- SSH and HTTPS protocols\n\nThis ensures the standard remains useful regardless of where developers choose to host their code.\n\n### Backward Compatibility\n\nThis CIP introduces a new metadata label and does not modify any existing standards. Scripts deployed before this standard's adoption can still have their source linked by submitting metadata referencing their original source repositories and commits.\n\nThe standard is purely additive and has no impact on existing scripts, wallets, or infrastructure that do not implement it.\n\n### Related Work\n\n#### CIP-0072: Cardano dApp Registration & Discovery\n\n[CIP-0072](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0072) defines a standard for dApp developers to register application-level metadata (name, logo, company, categories) and list the script hashes their dApp uses.\n\nThis CIP complements CIP-0072 by operating at a different level:\n\n| | CIP-0072 | CIP-0171 |\n|--|----------|----------|\n| **Scope** | dApp (application) | Script (code) |\n| **Purpose** | Discovery & metadata | Source verification |\n| **Trust model** | Requires trusting the claimant | Trustless - cryptographic verification |\n\nCIP-0072 lists script hashes but does not verify their origin. This CIP provides the missing link: a cryptographic proof that a script hash was produced from specific source code. The two standards can work together - a dApp registers via CIP-0072, and its scripts are independently verified via CIP-0171, giving users confidence in both the application metadata and the code provenance.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] Metadata format specification complete and reviewed by the community\n- [ ] CDDL schema validated against reference implementation\n- [ ] At least one verification tool implementing the standard deployed and operational\n- [ ] At least three Cardano protocols have registered verification metadata on mainnet\n- [ ] Integration documentation published enabling third-party implementations\n\n### Implementation Plan\n\n- A reference implementation is available at [uplc-link](https://github.com/easy1staking-com/uplc-link)\n- Coordination with block explorer teams for potential integration\n- Outreach to smart contract developers and protocols for adoption\n- Collaboration with compiler maintainers to document reproducibility requirements\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0176/README.md",
    "content": "---\nCIP: 176\nTitle: Non-segregated Block Body Serialization\nCategory: Ledger\nAuthors:\n  - Teodora Danciu <teodora.danciu@iohk.io>\n  - Alexey Kuleshevich <alexey.kuleshevich@iohk.io>\nImplementors: N/A\nStatus: Proposed\nDiscussions:\n  - Ledger issue: https://github.com/IntersectMBO/cardano-ledger/issues/5046\n  - Original PR: https://github.com/cardano-foundation/CIPs/pull/1084\nCreated: 2025-07-30\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nWe propose changing the CBOR encoding of a block body from a segregated layout to a plain sequence of transactions.\nCurrent layout: all transaction bodies are concatenated and encoded first, followed by their witness sets, then followed by auxiliary-data hashes, and finally followed by validity flags.\nProposed layout: each transaction is serialized in full before the next transaction is written to the stream.\n\n## Motivation: Why is this CIP necessary?\n\nSegregated serialization of [CIP-0118? | Nested Transactions](https://github.com/cardano-foundation/CIPs/pull/862) would be challenging both to specify and implement.\nSeparating and concatenating components across nested and non-nested transactions introduces complexity that is error-prone and potentially inefficient, as it may require tracking offsets and performing additional buffering and copying at runtime.\n\nCurrently, segregated serialization also complicates the logic used by Consensus to estimate transaction sizes when selecting transactions to fit within a block. Switching to a format where full transactions are encoded sequentially would simplify this process.\n\nConsidering - in hindsight - the original motivation for adopting segregated serialization rather than the more natural and predictable way of serializing a list of transactions - it's unclear whether it provides any real benefit.\nThe intent was to enable static validation of a transaction without decoding its witnesses. However, this benefit conflicts with the need for strict field evaluation, which is essential to prevent space leaks caused by retaining the original block bytes for an indeterminate period.\n\nMoreover, the current segregated layout, if it was used for its intended purpose mentioned above, conflicts with incremental decoding of blocks being received over the wire - for which there is a need.\nOur decoders consume bytes on demand until the entire BlockBody structure is exhausted. As a result, the node decodes the full block - including all witness data - in a single pass. The segregated format therefore provides no practical benefit for partial or streaming validation.\n\nMoreover, time spent doing deserialization amounts to a small fraction of the whole time spent applying the whole block to the ledger state, even when it is done without validating transactions.\n\nA significant benefit that we will get from the proposed change is reduction in complexity, both for the cardano-node core components, as well as various tools that handles chain data in some capacity.\n\n## Specification\n\nCurrently, a block is serialized like this:\n\n```cddl\nblock =\n  [ header\n  , transaction_bodies       : [* transaction_body]\n  , transaction_witness_sets : [* transaction_witness_set]\n  , auxiliary_data_set       : {* transaction_index => auxiliary_data}\n  , invalid_transactions     : [* transaction_index]\n  ]\n```\n\nThe proposal is to change it to:\n```cddl\nblock =\n  [ header\n  , block_body\n  ]\n\nblock_body =\n  [ invalid_transactions : [* transaction_index]\n  , transactions : [* transaction]\n  ]\n\ntransaction =\n  [  transaction_body, transaction_witness_set, true, auxiliary_data/ nil\n  // transaction_body, transaction_witness_set, auxiliary_data/ nil\n  ]\n```\n\nNote that we propose keeping invalid transaction indices separately, because:\n  * the `isValid` flag - which determines validity -  is controlled by the block producing node, not by the transaction creator;\n  * it's more efficient: we serialize indices only for invalid transactions, which are a small minority.\n\nAlso, note that `invalid_transactions` indices precede `transactions` in the proposed layout, so that consumers can determine the validity of transactions without having to scan through the entire transaction list.\n\n## Rationale: How does this CIP achieve its goals?\n\nSerializing transactions in sequence directly supports more complex constructs - such as nested transactions - by eliminating the need to coordinate disjointed segments across different levels of structure.\n\n### Ecosystem Impact\n\nThis change only impacts tools that work directly with block (de)serialization, such as alternative nodes and indexers. These tools make up a relatively small part of the Cardano tooling ecosystem. For them, the change is beneficial: without it, nested transactions would lead to a much more complex and error-prone block serialization format.\n\nNo transaction construction, serialization, or submission tooling is affected by this CIP.\n\nThis change slightly simplifies the implementation of [Merkle Root of Transactions in Block Header](https://github.com/cardano-foundation/CIPs/pull/964).\n\nThis change also simplifies the computation of the block body hash. <br/>\nCurrently, the block body hash is derived indirectly by hashing and combining several separately serialized components (transaction bodies, witnesses, auxiliary data, and validity flags).<br/> With the proposed layout, the block body hash becomes a single hash over the serialized block_body as a whole:\n```code\nblockBodyHash = hash(block_body)\n```\nThe simplification is particularly relevant for Peras and Leios, where additional certificates will be added to the block body, and can be naturally incorporated without further changes to the hashing scheme.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] Block serializers and deserializers in [cardano-ledger](https://github.com/IntersectMBO/cardano-ledger) are implemented such that they follow the cddl specification described above, and reflected in the cddl specs\n- [ ] The feature is integrated into [cardano-node](https://github.com/IntersectMBO/cardano-node) and released as part of the Dijkstra era hard fork\n\n### Implementation Plan\n\nThe implementation of this CIP should not proceed without an assessment of the potential impact on all the components that deserialise blocks.\nLeios and Peras R&D teams should also be aware of these changes.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-0381/README.md",
    "content": "---\nCIP: 0381\nTitle: Plutus support for Pairings over BLS12-381\nStatus: Active\nCategory: Plutus\nAuthors:\n  - Iñigo Querejeta-Azurmendi <inigo.querejeta@iohk.io>\nImplementors:\n  - Kenneth MacKenzie <kenneth.mackenzie@iohk.io>\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/220\n  - https://github.com/cardano-foundation/CIPs/pull/506\nCreated: 2022-02-11\nLicense: Apache-2.0\n---\n\n## Abstract\nThis CIP proposes an extension of the current plutus functions to provide support for basic operations over BLS12-381 \ncurve to the plutus language. We expose a candidate implementation, and describe clearly the benefits that this \nwould bring. In a nutshell, pairing friendly curves will enable a large number of cryptographic primitives that will \nbe essential for the scalability of Cardano. \n\n## Motivation: why is this CIP necessary?\nPairing Friendly Curves are a type of curves that provide the functionality of computing pairings. A pairing is a \nbinary function that maps two points from two groups to a third element in a third target group. For a more in-depth \nintroduction to pairings, we recommend reading [Pairings for Beginners](https://www.craigcostello.com.au/tutorials) or \n[Pairings for Cryptographers](https://eprint.iacr.org/2006/165). For level of detail required in this document, it is \nsufficient to understand that a pairing is a map: e:G1 X G2 -> GT, which satisfies the following properties:\n\n* Bilinearity: for all a,b in F^*_q, for all P in G1, Q in G2: e(aP,bQ)=e(P,Q)^(ab)\n* Non-degeneracy: e != 1\n* Computability: There exists an efficient algorithm to compute e\n\nwhere G1, G2 and GT are three distinct groups of order a prime q.\nPairing computation is an expensive operation. However, they enable a range of interesting \ncryptographic primitives which can be used for scaling Cardano and many other use cases. We now\nprovide a list of use cases of pairings as well as an estimated operation count to understand the number of \n'expensive' operations that need to be computed for each of them (a preliminary benchmark can be found in \nSection 'Costing of function').\n\n* **Sidechains** are a crucial component for the scalability of Cardano, and its interoperability with other \nchains/tokens/smart contracts. However, sidechains need to periodically commit their state to the Cardano mainnet to \nprovide the same security guarantees as the latter. This periodical commitment is performed through a threshold \nsignature by the dynamic committee of the Sidechain. The most interesting construction for medium sized committees \nis ATMS, presented in the paper [Proof of Stake Sidechains](https://cointhinktank.com/upload/Proof-of-Stake%20Sidechains.pdf), \nin Section 5.3, which requires pairings. We have yet not found an efficient solution that does not require pairings.\nATMS is a k-of-t threshold signature scheme (meaning that we need at least k signers to participate). \n* **Zero Knowledge Proofs** are an incredibly powerful tool. There exist different types of zero knowledge proofs, \nbut the most succinct (and cheaper to verify) rely on pairings for verification. Zero knowledge proofs can be used \nto make Mithril certificates, or sidechain checkpoints even more succinct, or to create layer 2 solutions to provide \nscalability (by the means of [ZK-Rollups](https://ethereum.org/en/developers/docs/scaling/layer-2-rollups/), which \nare used to scale Ethereum, e.g. [Loopring](https://loopring.org/#/), [zkSync](https://zksync.io/) or \n[Aztec](https://aztec.network/) among others). Plonk verification is quite complex, and differs depending on the \nnumber of custom gates. Implementations may differ, and adding custom gates or blinders will affect these estimates. \nPairing evaluations would not be affected, but scalar multiplications and additions over G1 will increase linearly with\nrespect to the additional gates and blinders. In general, it is not expected that the number of custom gates is larger\nthan a few dozens. In this section we expose the verifier complexity as described\n[here](https://eprint.iacr.org/2019/953.pdf) (version last checked April 2022). We count every challenge computation\nas a single hash evaluation. We omit the `scalar X scalar` multiplications and additions.We assume that point validation\nis performed by the external C library, and therefore do not count that in this estimate. The computation is the following:\n  * 6 hash computations\n  * 1 vanishing polynomial (1 scalar exponentiation)\n  * Quotient polynomial evaluation (1 scalar inverse)\n  * First part of batch poly commitment (9 scalar mults and 9 additions in G1)\n  * Fully batched poly commitment (5 scalar mults and 5 additions over G1)\n  * Group encoded batch verification (1 scalar mult over G1)\n  * Batch-validate all evaluations (3 scalar mults and 4 additions over G1, plus two Miller loops + final verify)\n* **Hydra** is another crucial component for scalability of Cardano (there is a series of blog posts available, with a \ngood summary of the solution [here](https://iohk.io/en/blog/posts/2021/09/17/hydra-cardano-s-solution-for-ultimate-scalability/)). \nHydra relies on a multisignature scheme, where all participants of the side channel need to agree on the new state. \nThis can be achieved with non-pairing friendly curves (as it is currently designed), but pairing based signature schemes \nprovide much more elegant constructions that reduce interaction among signers. Moreover, Hydra tails could benefit from\nSNARKs for proving correct spending of a set of transactions. For costing multisignatures we use BLS, whose verification \nis relatively simple. One only needs to compute 2 Miller loops and a final verify operation.Some applications might be \ninterested in a smart contract aggregating signatures or keys. For this, we require n\ngroup additions over G1 and G2 respectively, for n the number of submitted signatures.\n* **Mithril** currently does not require plutus support. However, Mithril, as a technology, allows for signature generation\nrepresenting all stakeholders of Cardano (or any proof of stake system). These types of certificates might eventually \nbe used for certifying sidechains, and plutus support will be crucial. Again, Mithril relies on pairing based signatures.\nLet k be the number of submitted signatures (as above, k is a security parameter determining the number of\nrequired signatures). However, in mithril k << N where N is the total number of eligible signers. Mithril\nverification goes as follows:\n  * Check the k is large enough\n  * k G1 additions\n  * k G2 additions\n  * k (log_2(N) hash computations + equality checks)\n  * 2 Miller loops + final verify\n* **ATALA** is a decentralized identification mechanism. One of the properties they want to provide is anonymity: users \ncan selectively disclose attributes of their certificate or prove statements regarding them without disclosing their identity. \nUp to date, the most recent, efficient and interesting solutions to provide these are pairing based \n([Hyperledger Fabric/Idemix standardisation effort](https://hyperledger-fabric.readthedocs.io/en/release-2.2/idemix.html#underlying-cryptographic-protocols), \n[coconut credentials used by Nym](https://blog.nymtech.net/nyms-coconut-credentials-an-overview-4aa4e922cd51), among \nothers). We use Coconut certs as an example. There is no decision on what type of construction we will\neventually use. Coconut credentials (and other types of credentials we are looking at) are built in a way that\nit is efficient to prove statements about attributes. To this end, it is required to build, and be able to verify,\nrelations over discrete logarithm values. However, for sake of simplicity in this computation, we consider the\nsimplest form of anonymous credentials, which contains no attributes. We note that proving statements regarding\nattributes does not require further pairing evaluations.\n  * Proof verification reduces to a relation involving elements in G1 and G2. This verification does not require the\n    pairing evaluation, but does require G1 and G2 additions and multiplications.\n  * 2 Miller loops + final verify\n\n## Specification\nWe now provide the technical specification. \n\n### Names and types/kinds for the new functions or types\nThe added types will be the following, all of which can be represented as a byte array. Even if these types are \nequivalent to byte arrays of a given size, it makes sense to include these types, to enforce deserialization, and \ntherefore some checks on the data used by the smart contract. In particular, `bls12_381_G1_element` and\n`bls12_381_G2_element` can only be generated \nwith byte arrays that represent a point which is part of the prime order subgroup. On the other hand, \n`bls12_381_MlResult` can only be generated as a result of the `bls12_381_millerLoop` computatio.\n\n* `bls12_381_G1_element`\n* `bls12_381_G2_element`\n* `bls12_381_MlResult`\n\nWe need to support the binary operation of G1 and G2 (which are additive groups), as well as the binary operation \nover MlResult (which is represented as a multiplicative group). We also want to enable hashing to G1 and G2.\nIn particular, we expose the hash to curve (which we denote with `hashToGroup`) algorithm as described in \n[hash to curve draft](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hash-to-curve#section-8), \nusing `BLS12381G1_XMD:SHA-256_SSWU_RO_` and `BLS12381G2_XMD:SHA-256_SSWU_RO_` for G1 and G2 respectively.\nWe do not include the type of the Scalar, nor operations related to it. These type of operations can already be \nperformed with the `Integer` type. In particular, we need the following functions: \n\n* Group operations: \n    * `bls12_381_G1_add :: bls12_381_G1_element -> bls12_381_G1_element -> bls12_381_G1_element`\n    * `bls12_381_G1_scalarMul :: Integer -> bls12_381_G1_element -> bls12_381_G1_element`\n    * `bls12_381_G1_neg :: bls12_381_G1_element -> bls12_381_G1_element`\n    * `bls12_381_G2_add :: bls12_381_G2_element -> bls12_381_G2_element -> bls12_381_G2_element`\n    * `bls12_381_G2_scalarMul :: Integer -> bls12_381_G2_element -> bls12_381_G2_element`\n    * `bls12_381_G2_neg :: bls12_381_G2_element -> bls12_381_G2_element`\n    * `bls12_381_mulMlResult :: bls12_381_MlResult -> bls12_381_MlResult -> bls12_381_MlResult`\n* Pairing operations:\n    * `bls12_381_millerLoop :: bls12_381_G1_element -> bls12_381_G2_element -> bls12_381_MlResult`\n    * `bls12_381_finalVerify :: bls12_381_MlResult -> bls12_381_MlResult -> Bool` This performs the final \n  exponentiation (see section `An important note on MlResult elements` below).\n* Hash to curve. We include hash-to-curve functions, as per [Hashing to Elliptic Curves](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hash-to-curve)\n  internet draft. Refer to [this](#hash-to-curve) section for further details: \n  * `bls12_381_G1_hashToGroup :: ByteString -> ByteString -> bls12_381_G1_element`\n  * `bls12_381_G2_hashToGroup :: ByteString -> ByteString -> bls12_381_G2_element`\n\nOn top of the elliptic curve operations, we also need to include deserialization functions, and equality definitions\namong the G1 and G2 types. \n\n* Deserialisation (more information of the choice of compressed form over uncompressed form [here](#compressed-vs-decompressed)): \n  * `bls12_381_G1_compress :: bls12_381_G1_element -> ByteString`\n  * `bls12_381_G1_uncompress :: ByteString -> bls12_381_G1_element`\n  * `bls12_381_G2_compress :: bls12_381_G2_element -> ByteString`\n  * `bls12_381_G2_uncompress :: ByteString -> bls12_381_G2_element`\n* Equality functions:\n  * `bls12_381_G1_equal :: bls12_381_G1_element -> bls12_381_G1_element -> Bool`\n  * `bls12_381_G2_equal :: bls12_381_G2_element -> bls12_381_G2_element -> Bool`\n\nThis makes a total of 17 new functions and three new types. \n\nWe follow the [ZCash Bls12-381 specification](https://github.com/supranational/blst#serialization-format) for the\nserialization of elements:\n* Fq elements are encoded in big-endian form. They occupy 48 bytes in this form.\n* Fq2 elements are encoded in big-endian form, meaning that the Fq2 element c0 + c1 * u is represented by the Fq\n  element c1 followed by the Fq element c0. This means Fq2 elements occupy 96 bytes in this form.\n* The group G1 uses Fq elements for coordinates. The group G2 uses Fq2 elements for coordinates.\n* G1 and G2 elements are encoded in compressed form (just the x-coordinate). G1 elements occupy 48 bytes and\n  G2 elements occupy 96 bytes.\n\nThe most-significant three bits of a G1 or G2 encoding should be masked away before the coordinate(s) are\ninterpreted. These bits are used to unambiguously represent the underlying element:\n* The most significant bit, when set, indicates that the point is in compressed form.\n* The second-most significant bit indicates that the point is at infinity. If this bit is set, the remaining bits of\n  the group element's encoding should be set to zero.\n* The third-most significant bit is set if (and only if) this point is in compressed form, and it is not the point at\n  infinity and its y-coordinate is the lexicographically largest of the two associated with the encoded x-coordinate.\n\nWe include the serialisation of the generator of G1 and the generator of G2:\n* generator G1:\n```\n[151, 241, 211, 167, 49, 151, 215, 148, 38, 149, 99, 140, 79, 169, 172, 15, 195, 104, 140, 79, 151, 116, 185, \n5, 161,78, 58, 63, 23, 27, 172, 88, 108, 85, 232, 63, 249, 122, 26, 239, 251, 58, 240, 10, 219, 34, 198, 187]\n```\n* generator G2:\n```\n[147, 224, 43, 96, 82, 113, 159, 96, 125, 172, 211, 160, 136, 39, 79, 101, 89, 107, 208, 208, 153, 32, 182, \n26, 181, 218, 97, 187, 220, 127, 80, 73, 51, 76, 241, 18, 19, 148, 93, 87, 229, 172, 125, 5, 93, 4, 43, 126, \n2, 74, 162, 178, 240, 143, 10, 145, 38, 8, 5, 39, 45, 197, 16, 81, 198, 228, 122, 212, 250, 64, 59, 2, 180, \n81, 11, 100, 122, 227, 209, 119, 11, 172, 3, 38, 168, 5, 187, 239, 212, 128, 86, 200, 193, 33, 189, 184]\n```\n\n#### Hash to curve\nWe expose the hash-to-curve functions following the [Hashing to Elliptic Curves](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hash-to-curve)\ninternet draft. The function signature takes as input two `ByteString`s and returns a point. The first \n`ByteString` is the message to be hashed, while the second `ByteString` is the Domain Separation Tag (DST). \nFor more information on the DST, see [section 3.1](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hash-to-curve#name-domain-separation-requireme)\nof the internet draft. We limit the DST to be at most 255 bytes, following the standard specification. If \napplications require a domain separation tag that is longer than 255 bytes, they should convert it to a smaller\nDST following the instructions of the standard draft (see [section 5.3.3](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hash-to-curve#name-using-dsts-longer-than-255-)).\n\nSome libraries expose the possibility to use yet another `ByteString` when calling the hash-to-curve function. \nSee for example the [`blst` library](https://github.com/supranational/blst/blob/master/src/hash_to_field.c#L121).\nWe choose not to include this extra `ByteString` in the function signature, because it is not part of the standard\ndraft. In the case where we want to match a hash that did use this `aug` `ByteString`, one simply needs to prepend\nthat value to the message. One can verify that by running the test-vector generation script introduced in \n[cardano-base](https://github.com/input-output-hk/cardano-base/blob/master/cardano-crypto-tests/bls12-381-test-vectors/src/main.rs#L222..L231).\n\n#### Compressed vs Decompressed\nTo recap, we have types `bls12_381_G1_element` and `bls12_381_G2_element` each of which is essentially a pair \nof values `(x,y)` that satisfy an equation of the form `y^2 = x^3+ax+b`.  The blst library provides two \nserialisation formats for these:\n\n* The serialised format, where you have a bytestring encoding both the `x` and `y` coordinates of a point.  \n  A serialised `bls12_381_G1_element` takes up 96 bytes and a serialised `bls12_381_G2_element` takes up 192 \n  bytes.\n* The compressed format, where you have a bytestring that only contains the `x` coordinate.  When you \n  uncompress a compressed point to get an in-memory point, the `y` coordinate has to be calculated from \n  the equation of the curve.  A compressed `bls12_381_G1_element` takes up 48 bytes and a compressed \n  `bls12_381_G2_element` takes 92 bytes.\n\nThe PLC implementation currently uses the compressed format for serialising `bls12_381_G1_element` and \n`bls12_381_G1_element`s.  There are at least three places where this is (or could be) used:\n\n* Storing a group element as a bytestring inside a Data object which will be passed as a parameter to a script.\n* During flat serialisation of PLC scripts (constants from G1 and G2 are converted into bytestrings and then \n  flat deals with these as usual).\n* In the concrete PLC/UPLC syntax, where constants are written as hex strings representing compressed points.\n\nThe serialised format could also be used for all of these.  The advantage of doing that is that deserialisation \nis much cheaper than uncompression (which involves calculating a square root in a finite field, which is \nexpensive in general), but the disadvantage is that the serialised format requires twice as much space as \nthe compressed form.  We ran some benchmarks to determine CPU costs (in ExUnits) for both \ndeserialisation, and uncompression and came up with the following:\n```\nbls12_381_G1_deserialize : 701442\nbls12_381_G1_uncompress  : 16511372\n\nbls12_381_G2_deserialize : 1095773\nbls12_381_G2_uncompress  : 33114723\n```\n\nFor G1 uncompression is about 23 times more expensive than deserialisation, and for G2 uncompression is about \n30 times more expensive than deserialisation.  The maximum CPU budget per script is currently 1,000,000,000, \nso a single G2 uncompression is about 0.3% of the total allowance, whereas a G2 deserialisation is about 0.01%.\nThis might seem like a compelling reason to prefer serialisation over compression, but our claim is that the time \nsaving is not worthwhile because you can't fit enough serialised points into a script to make the speed gain \nsignificant. The bls12-381-costs program runs a number of benchmarks for execution costs of scripts that exercise \nthe BLS builtins. One of these creates UPLC scripts which include varying numbers of compressed points and \nat run-time uncompresses them and adds them all together; bls-381-costs runs these scripts and prints out their \ncosts as fractions of the maximum CPU budget and maximum script size (currently 16384). Here are the results:\n\nUncompress n G1 points and add the results\n```\n  n     script size             CPU usage               Memory usage\n----------------------------------------------------------------------\n  -      68   (0.4%)             100   (0.0%)             100   (0.0%) \n 10     618   (3.8%)       185801250   (1.9%)           45642   (0.3%)\n 20    1168   (7.1%)       371912820   (3.7%)           88002   (0.6%)\n 30    1718  (10.5%)       558024390   (5.6%)          130362   (0.9%)\n 40    2268  (13.8%)       744135960   (7.4%)          172722   (1.2%)\n 50    2818  (17.2%)       930247530   (9.3%)          215082   (1.5%)\n 60    3368  (20.6%)      1116359100  (11.2%)          257442   (1.8%)\n 70    3918  (23.9%)      1302470670  (13.0%)          299802   (2.1%)\n 80    4468  (27.3%)      1488582240  (14.9%)          342162   (2.4%)\n 90    5018  (30.6%)      1674693810  (16.7%)          384522   (2.7%)\n100    5568  (34.0%)      1860805380  (18.6%)          426882   (3.0%)\n110    6118  (37.3%)      2046916950  (20.5%)          469242   (3.4%)\n120    6668  (40.7%)      2233028520  (22.3%)          511602   (3.7%)\n130    7218  (44.1%)      2419140090  (24.2%)          553962   (4.0%)\n140    7768  (47.4%)      2605251660  (26.1%)          596322   (4.3%)\n150    8318  (50.8%)      2791363230  (27.9%)          638682   (4.6%)\n```\n\nUncompress n G2 points and add the results\n```\n  n     script size             CPU usage               Memory usage\n----------------------------------------------------------------------\n  -      68   (0.4%)             100   (0.0%)             100   (0.0%) \n 10    1098   (6.7%)       363545910   (3.6%)           45984   (0.3%)\n 20    2128  (13.0%)       728715130   (7.3%)           88704   (0.6%)\n 30    3158  (19.3%)      1093884350  (10.9%)          131424   (0.9%)\n 40    4188  (25.6%)      1459053570  (14.6%)          174144   (1.2%)\n 50    5218  (31.8%)      1824222790  (18.2%)          216864   (1.5%)\n 60    6248  (38.1%)      2189392010  (21.9%)          259584   (1.9%)\n 70    7278  (44.4%)      2554561230  (25.5%)          302304   (2.2%)\n 80    8308  (50.7%)      2919730450  (29.2%)          345024   (2.5%)\n 90    9338  (57.0%)      3284899670  (32.8%)          387744   (2.8%)\n100   10368  (63.3%)      3650068890  (36.5%)          430464   (3.1%)\n110   11398  (69.6%)      4015238110  (40.2%)          473184   (3.4%)\n120   12428  (75.9%)      4380407330  (43.8%)          515904   (3.7%)\n130   13458  (82.1%)      4745576550  (47.5%)          558624   (4.0%)\n140   14488  (88.4%)      5110745770  (51.1%)          601344   (4.3%)\n150   15518  (94.7%)      5475914990  (54.8%)          644064   (4.6%)\n```\n\nIt's clear from these figures that the limiting factor is the script size: about 300 G1 points or 150 G2 points\ncan be processed in a single script before exceeding the script size limit, but the maximum CPU usage is only 55% \nof the the maximum CPU budget. If the serialisation (involving both x- and y-coordinates) was used instead then \nthere would be some saving in execution time, but a single script would only be able to process about half as \nmany points and it's unlikely that the time savings would compensate for that. For example, uncompressing 50 G2 \npoints would cost about 1,655,000,000 CPU ExUnits and deserialising them would cost about 54,788,000, which is \n1,600,000,000 ExUnits cheaper. At the time of writing, this equates to 0.27 Ada. However, 50 serialised G2 \npoints take up 4800 more bytes than 50 compressed ones, and the extra bytes would cost 0.36 Ada. Thuis using \nserialisation would cost 0.09 Ada more than using compression for the same number of points.\n\nIn summary: even though uncompression is a lot more expensive per point than deserialisation, the size savings \ndue to compression actually outweigh the speed gains due to serialisation because bytes per script are a lot \nmore expensive than ExUnits per script in real terms. For this reason, we propose to support the compressed \nformat and only the compressed format.\n\n#### An important note on MlResult elements\nWe intentionally limit what can be done with the MlResult element. In fact, the only way that one can generate a\nMlResult element is using the `bls12_381_millerLoop` function. Then these elements can only be used for operations among \nthem (multiplication) and a final equality check (denoted `finalVerify`). In other words, MlResult elements are only there to eventually\nperform some equality checks. We thought of including the inverse\nfunction to allow division, but given that we simply allow for equality checks, if one needs to divide by `A`, \nthen `A` can simply move to the other side of the equality sign. These limitations allow us for a performance \ntrick, which is also used for the verification of BLS signatures. In a nutshell, a pairing is divided into two \noperations: (i) Miller loop, and (ii) final exponentiation. Both are expensive, but what we can do is first \ncompute the Miller loop, which already maps two points from G1 and G2 to MlResult. Then we can use this result \nto perform the operations over these points (multiplications). Finally, when we want to check for equality, we invert \none of the two points (or equivalently in this case we compute the conjugate), and multiply the result by the \nother point. Only now we compute the final exponentiation\nand verify that the result is the identity element. In other words: \n* the 'partial pairing' function, `bls12_381_millerLoop` simply\ncomputes the Miller loop\n* the equality check function, `bls12_381_finalVerify`, first\ncomputes an inverse, then a multiplication, a final exponentiation and checks that the element is the identity. \n\nWhile the results of the Miller loop are already elements in Fp12, they are not necessarily part of the group. This\nis why we call the type used in the built-ins `bls12_381_MlResult` rather than `bls12_381_GT`.\n\nUsing the estimates in the section `Costing of functions`, we can see how this representation of\nGT elements is beneficial. Assume that we want to check the following relation: \n`e(A,B) * e(C,D) =? e(E,F) * e(G,H)`. The Miller loop takes around 330us, and the final exponentiation\naround 370us. A full pairing would be 700us, and therefore checking this relation would cost around\n2,8ms. If, instead, we break down the pairing into a Miller loop and a final exponentiation, and only\ncompute the latter once, the cost of the relation above would be 330 * 4 + 370 = 1.7ms. \n\nFor this reason it is important to limit what can be done with `bls12_381_MlResult`, as the pairing really is not the full\npairing operation, but only the Miller loop. \n### Source implementation\n* [BLST](https://github.com/supranational/blst) library, providing the algebraic operations.\n* [cardano-base](https://github.com/input-output-hk/cardano-base/tree/master/cardano-crypto-class/src/Cardano/Crypto/EllipticCurve)\nwith the haskell FFI to the BLST library.\n* [plutus](https://github.com/input-output-hk/plutus/pull/5231)\n\nOther libraries of interest\n* [Ethereum support for BLS12-381](https://eips.ethereum.org/EIPS/eip-2537). Not directly relevant as this is an \nEthereum Improvement Proposal for a precompiled solidity contracts.\n\n### Comparison with existing functions\nWe present what would be the alternatives of using pairings in the different use cases presented above. \n\n* Sidechain bridges using the current technology would rely on either of the two possibilities: \n    * Require the bridge committee to interact during signature, or to rely on a precomputation phase. Current \n  solutions only support non-robust signature schemes, meaning that if one signer misbehaves, the whole signature \n  procedure needs to be restarted. This could seriously hinder sidechains.\n    * Non-aggregation of signatures. This would result in a linear \"checkpoint certificate\" with respect to the \n    number of signers (both in communication and computation complexity). Basically, all committee members need to \n    submit their signature, and the smart contract needs to verify all ed25519 signatures. \n* Zero Knowledge Proofs cannot be verified with current functions available in Plutus. There exist proofs that can \nbe instantiated over non-pairing friendly curves, but these result in logarithmic sized proofs and linear verification \nwith respect to the computation to prove, while solutions that rely on pairings can be represented more concisely, and \nare cheaper to verify. \n\n### Reason for exposing curve operations API\nOne might be concerned of why we are exposing such low-level primitives, instead of exposing higher level protocol \nfunctions, such as `VerifyBlsSignature` or `VerifyZKP`. The motivation behind that is because pairings can enable a \nbig number of use cases, and covering all of those can considerably extend the list of required functions. \n\n### Curve specifications\nThe BLS12-381 curve is fully defined by the following set of parameters (coefficient A=0 for all BLS12 curves). Taken from \n[EIP 2537](https://eips.ethereum.org/EIPS/eip-2537):\n```\nBase field modulus = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab\nB coefficient = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004\nMain subgroup order = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001\nExtension tower\nFp2 construction:\nFp quadratic non-residue = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaaa\nFp6/Fp12 construction:\nFp2 cubic non-residue c0 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001\nFp2 cubic non-residue c1 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001\nTwist parameters:\nTwist type: M\nB coefficient for twist c0 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004\nB coefficient for twist c1 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004\nGenerators:\nG1:\nX = 0x17f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb\nY = 0x08b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e1\nG2:\nX c0 = 0x024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb8\nX c1 = 0x13e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e\nY c0 = 0x0ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801\nY c1 = 0x0606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be\nPairing parameters:\n|x| (Miller loop scalar) = 0xd201000000010000\nx is negative = true\n```\nOne should note that base field modulus is equal to 3 mod 4 that allows an efficient square root extraction.\n\n### Rationale: how does this CIP achieve its goals?\nThe reason for choosing the BLS12-381 over the BN256 curve is that the former is claimed to provide 128 bits of security,\nwhile the latter was reduced to 100 bits of security after the extended number field sieve (a new algorithm to compute\nthe discrete logarithm) was [shown to reduce the security](https://eprint.iacr.org/2016/1102.pdf) of these curves.\n\nAn [EIP](https://eips.ethereum.org/EIPS/eip-2537) for precompiles of curve BLS12-381 already exists, but has been\nstagnant for a while. Nonetheless, Zcash, MatterLabs and Consensys support BLS12-381 curve, so it is certainly widely\nused in the space.\n\nFurther reading regarding curve BLS12-381 can be found [here](https://hackmd.io/@benjaminion/bls12-381) and the\nreferences thereof cited. \n\n### Trustworthiness of implementations\n* [BLST](https://github.com/supranational/blst) library—\n[audited by NCC Group](https://research.nccgroup.com/wp-content/uploads/2021/01/NCC_Group_EthereumFoundation_ETHF002_Report_2021-01-20_v1.0.pdf) \nand [being formally verified](https://github.com/GaloisInc/BLST-Verification) by Galois.\n\nWe also have an [analysis by Duncan Coutts](https://github.com/cardano-foundation/CIPs/pull/220#issuecomment-1508306896https://github.com/cardano-foundation/CIPs/pull/220#issuecomment-1508306896)\nfor effects of including this library for continuous integration and long term maintainability:\n\nIn addition to security audits on the proposed implementation, it is important that we review the inclusion of \nthe library for practical issues of build systems, and long term maintainability.\n\nIn particular in this case the library will be used in the chain format and in chain verification. This means \nwe have special constraints that the format and verification logic must never change. Or more specifically: \nit must be possible forever to be able to verify the existing uses on the chain. So even if there are upgrades \nor format changes in future, it must still be possible to decode and verify the old uses. This is not a \nconstraint that most software has, and so many libraries are not designed to work within that constraint.\n\nThe proposed implementation is https://github.com/supranational/blst\n\n* The implementation is in C and assembly for x86 and ARM v8. This is good for the existing Haskell \n  implementation of the Cardano node because integrating with C libraries is relatively straightforward, it's \n  well supported by the build and CI system and does not pull in too many extra dependencies. (Contrast for \n  example if it were a Rust library where we would have serious practical problems on this front.)\n* The implementation appears to have been designed with blockchain implementations in mind. This is a good \n  sign for the long term maintainability because it probably means that the library authors will continue to \n  support the existing format and semantics even if there are changes or improvements.\n* The implementation is claimed to be compliant with draft IETF specifications. There is a risk that the \n  specs may change before being declared final, and the library may be updated to follow. There is a risk \n  that the Cardano community will have to support the old version forever. Though given the point above, \n  it's probably the case that library updates would still provide compatibility with the current IETF drafts \n  and serialisation formats.\n\nSo overall this seems like something the core development team and Cardano community could support long term \nwithout too high a cost. Though we should be aware of the risk that we may have to support an old version of \nthe library, if the library gets changed in incompatible ways.\n\nTo ensure no compatibility surprises, it is worth considering forking the repository at a specific commit/version \nand building the node using that version. This is to guarantee the version remains available. Then for any future \nupdates, the fork repo could be updated to a new version explicitly, with appropriate compatibility checks to \nensure the existing on-chain uses are still compatible.\n### Costing of function\n\nWe did some [preliminary costing](https://github.com/input-output-hk/plutus/tree/kwxm/BLS12_381/prototype/plutus-benchmark/bls-benchmarks) \nof the BLS functions and the following cost of the new built-in functions: \n```\nbls12_381_G1_compress    : 3341914\nbls12_381_G1_uncompress  : 16511372\nbls12_381_G1_add         : 1046420\nbls12_381_G1_equal       : 545063\nbls12_381_G1_hashToCurve : 66311195 + 23097*x\nbls12_381_G1_scalarMul   : 94607019 + 87060*x (we use 94955259, with x = 4)\nbls12_381_G1_neg         : 292890\nbls12_381_G2_compress    : 3948421\nbls12_381_G2_uncompress  : 33114723\nbls12_381_G2_add         : 2359410\nbls12_381_G2_equal       : 1102635\nbls12_381_G2_hashToCurve : 204557793 + 23271*x\nbls12_381_G2_scalarMul   : 190191402 + 85902*x\nbls12_381_G2_neg         : 307813\nbls12_381_GT_finalVerify : 388656972\nbls12_381_GT_millerLoop  : 402099373\nbls12_381_GT_mul         : 2533975\nblake2b_256                     : 358499 + 10186*x (521475, with x = 16)\naddInteger                      : 85664 + 712*max(x,y) (88512, with x = y = 4)\nmultiplyInteger                 : 1000 + 55553*(x+y) (641924, with x = y = 4, and we include the price of modular reduction, as we need one per mult)\ndivideInteger                   : if x>y\nthen  809015 + 577*x*y\nelse  196500\nmodInteger                      : 196500  \nexpInteger                      : We estimate 32 mults and adds (23373952)\n```\n\nUsing these preliminary benchmarks, we performed some estimates of how much it would cost to verify Groth16 or Plonk \nproofs using the bindings. Details can be found [here](https://hackmd.io/X80zXoxWQrqSLaO0nizjaA). The estimates for\nGroth16 (~23% of the execution budget required for a proof verification) were confirmed by the benchmarks shared above.\n\n### Plutus implementor\nIOG internal. PR open for Plutus bindings https://github.com/input-output-hk/plutus/pull/5231\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Confirmation from IOG Plutus Team that this curve support is included in a scheduled Plutus release.\n  - Included within the Chang #1 hardfork \n\n### Implementation Plan\n\n- [x] Confirmation from IOG Plutus Team that [CIP-0035 Processes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0035#processes) for changes to Plutus have been satisfied.\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0).\n"
  },
  {
    "path": "CIP-1694/README.fr.md",
    "content": "---\nCIP: 1694\nSource: https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md\nTitle: Un premier pas vers une gouvernance décentralisée on-chain\nRevision: 5a2fc66\nTranslators:\n    - Mike Hornan <mike.hornan@able-pool.io>\n    - Alexandre Lafleur <alexandre.lafleur@able-pool.io>\nLanguage: fr\n---\n\n## Résumé\n\nNous proposons une révision du système de gouvernance on-chain de Cardano pour répondre aux nouvelles exigences de Voltaire.\nLa prise en charge de gouvernance spécialisée existante pour les mises à jour des paramètres de protocole et les certificats MIR sera supprimée,\net deux nouveaux champs seront ajoutés aux corps de transaction normaux pour:\n\n1. Actions de gouvernance\n2. Votes\n\n**Tout utilisateur Cardano** sera autorisé à soumettre une **action de gouvernance**.\nNous introduisons également trois organes de gouvernance distincts qui ont des fonctions spécifiques dans ce nouveau cadre de gouvernance :\n\n1. Un comité constitutionnel\n2. un groupe de représentants délégués (ci-après dénommé **DReps**)\n3. les opérateurs de pool de participation (ci-après appelés **SPO**)\n\nChaque mesure de gouvernance doit être ratifiée par au moins deux de ces trois organes de gouvernance en utilisant leurs **votes** en chaîne.\nLe type d’action et l’état du système de gouvernance déterminent quels organes doivent le ratifier.\n\nLes actions ratifiées sont ensuite **promulguées** sur la chaîne, suivant un ensemble de règles bien définies.\n\nComme pour les pools de participations, tout détenteur d’Ada peut s’inscrire pour être un DRep et donc choisir de\nse représenter soi-même et/ou représenter les autres. En outre, comme pour les pools de participations, les détenteurs d’Ada peuvent, à la place, déléguer leur\ndroits de vote à tout autre DRep.\nLes droits de vote seront basés sur l’Ada totale qui est déléguée, comme un nombre entier de Lovelace.\n\nL’aspect le plus crucial de cette proposition est donc la notion de **«un Lovelace = une voix»**.\n\nPour les nombreux contributeurs à cette proposition, voir [Remerciements](#remerciements).\n## Motivation : pourquoi ce CIP est-il nécessaire ?\n\n+ [Objectif](#objectif)\n+ [Conception actuelle](#conception-actuelle-du-mécanisme-de-gouvernance)\n+ [Lacunes de la conception de la gouvernance Shelley](#lacunes-de-la-conception-de-la-gouvernance-shelley)\n+ [Hors champ d’application](#hors-champ-dapplication)\n\n### Objectif\n\nNous entrons dans l’ère de Voltaire, jetant les bases d’une prise de décision décentralisée.\nCe CIP décrit un mécanisme de gouvernance on-chain qui sous-tendra la phase Voltaire de Cardano.\nLe CIP s’appuie sur le schéma de gouvernance Cardano original qui reposait sur un nombre fixe de clés de gouvernance et l’étend.\nIl vise à fournir une **première étape** qui est à la fois précieuse et, surtout, techniquement réalisable\nà **court terme** dans le cadre du système de gouvernance Voltaire proposé.\n\nIl vise également à servir de point de départ pour la participation continue de la communauté,\ny compris sur les paramètres de seuil appropriés et d’autres paramètres on-chain.\n\nLes propositions subséquentes pourraient adapter et élargir cette proposition pour répondre aux nouveaux besoins en matière de gouvernance.\n\n### Conception actuelle du mécanisme de gouvernance\n\nLe mécanisme de gouvernance Cardano en chaîne qui a été introduit à l’ère du grand livre Shelley est capable de:\n\n1. Modifier les valeurs des paramètres du protocole (y compris lancer des « hard forks »)\n2. transférer Ada hors des réserves et du trésor (et également déplacer Ada entre les réserves et le trésor)\n\nDans le schéma actuel, les mesures de gouvernance sont initiées par des transactions spéciales qui nécessitent des autorisations de  `Quorum-Many`\nà partir des clés de gouvernance (5 sur 7 sur le réseau principal Cardano)[^1].\nLes champs de l’organisme de transaction fournissent des détails sur la mesure de gouvernance proposée :\nsoit i) les changements de paramètres du protocole; ou ii) initier des transferts de fonds.\nChaque transaction peut déclencher les deux types d’actions de gouvernance, et une seule action peut avoir plus d’un effet (par exemple, la modification de deux paramètres de protocole ou plus).\n\n- Les mises à jour des paramètres de protocole utilisent le [champ de transaction nº6](https://github.com/input-output-hk/cardano-ledger/blob/8884d921c8c3c6e216a659fca46caf729282058b/eras/babbage/test-suite/cddl-files/babbage.cddl#L56) du corps de la transaction.\n- Les mouvements de la trésorerie et des réserves utilisent [Déplacer les certificats de récompenses instantanées(abrégé MIR)](https://github.com/input-output-hk/cardano-ledger/blob/8884d921c8c3c6e216a659fca46caf729282058b/eras/babbage/test-suite/cddl-files/babbage.cddl#L180).\n\nLes mesures de gouvernance dûment autorisées sont appliquées à une limite d’époque (elles sont **adoptées**).\n\n#### Hard Forks\n\nL’un des paramètres du protocole est suffisamment important pour mériter une attention particulière :\nLa modification de la version majeure du protocole permet à Cardano d’adopter des hard forks contrôlés.\nCe type de mise à jour des paramètres de protocole a donc un statut particulier, puisque les pools de mise\ndoivent mettre à niveau leurs nœuds afin de pouvoir prendre en charge la nouvelle version du protocole une fois le hard fork adopté.\n\n### Lacunes de la conception de la gouvernance Shelley\n\nLa conception de la gouvernance Shelley visait à fournir une approche simple et transitoire de la gouvernance.\nLa présente proposition vise à remédier à un certain nombre de lacunes de cette conception.\nqui sont apparents lorsque nous entrons dans Voltaire.\n\n1. La conception de la gouvernance Shelley ne laisse aucune place à la participation active des détenteurs d’Ada sur la chaîne.\nBien que les modifications apportées au protocole soient généralement le résultat de discussions avec des acteurs communautaires sélectionnés,\nLe processus est actuellement mené principalement par les entités fondatrices.\nS’assurer que tout le monde peut exprimer ses préoccupations est fastidieux et peut parfois être perçu comme arbitraire.\n\n2. Les mouvements du Trésor constituent un sujet critique et sensible.\nCependant, ils peuvent être difficiles à suivre. Il est important d’avoir plus de transparence\net plus de couches de contrôle sur ces mouvements.\n\n3. Bien qu’ils doivent être traités spécialement par les SPO, les hard forks ne sont pas différenciés des autres changements de paramètres de protocole.\n\n4. Enfin, bien qu’il existe actuellement une vision quelque peu commune pour _Cardano_ qui est partagée par ses entités fondatrices ainsi que par de nombreux membres de la communauté,\nIl n’y a pas de document clairement défini où ces principes directeurs sont consignés.\nIl est logique de tirer parti de la blockchain Cardano pour enregistrer la philosophie Cardano partagée de manière immuable, en tant que constitution Cardano formelle.\n\n### Hors champ d’application\n\nLes sujets suivants sont considérés comme ne relevant pas de la portée de ce CIP.\n\n#### Le contenu de la constitution\n\nCe CIP se concentre uniquement sur les mécanismes en chaîne. Les dispositions de la constitution initiale sont extrêmement importantes, de même que tous les processus qui\npermettra de le modifier. Ceux-ci méritent leur propre discussion séparée et ciblée.\n\n#### La composition du comité constitutionnel\n\nIl s’agit d’un problème hors chaîne.\n\n#### Questions juridiques\n\nToute application légale potentielle du protocole Cardano ou de la Constitution Cardano est complètement hors de portée de ce CIP.\n\n\n#### Normes hors chaîne pour les actions de gouvernance\n\nLa communauté Cardano doit réfléchir profondément aux normes et processus appropriés pour gérer la création des actions de gouvernance spécifiées dans ce CIP.\nEn particulier, le rôle du projet Catalyst dans la création d’actions de retrait de trésorerie est complètement en dehors du champ d’application de ce CIP.\n\n\n#### Ada holdings et délégation\n\nComment les entreprises privées, les institutions publiques ou privées, les particuliers, etc. choisir de détenir ou de déléguer leur Ada, y compris la délégation aux pools de participation ou DReps, n’entre pas dans le champ d’application de ce CIP.\n\n## Spécification\n\n+ [La Constitution Cardano](#la-constitution-cardano)\n+ [Le comité constitutionnel](#le-comité-constitutionnel)\n  - [État de non-confiance](#état-de-non-confiance)\n  - [Clés du comité constitutionnel](#clés-du-comité-constitutionnel)\n  - [Remplacement du comité constitutionnel](#remplacement-du-comité-constitutionnel)\n  - [Taille du comité constitutionnel](#taille-du-comité-constitutionnel)\n  - [Mandat](#mandat)\n  - [Script de rambardes](#script-de-rambardes)\n+ [Représentants délégués (DReps)](#représentants-délégués-dreps)\n  - [Options de vote prédéfinies](#options-de-vote-prédéfinies)\n  - [DReps enregistrés](#dreps-enregistrés)\n  - [Nouvelle distribution de la mise pour DReps](#nouvelle-distribution-de-la-mise-pour-dreps)\n  - [Incitatifs pour les détenteurs d’Ada à déléguer une mise de vote](#incitatifs-pour-les-détenteurs-dada-à-déléguer-une-mise-de-vote)\n  - [Incitatifs DRep](#incitatifs-drep)\n+ [Actions de gouvernance](#actions-de-gouvernance)\n  - [Ratification](#ratification)\n    * [Exigences](#exigences)\n    * [Restrictions](#restrictions)\n  - [Promulgation](#promulgation)\n  - [Cycle de vie](#cycle-de-vie)\n  - [Contenu](#contenu)\n  - [Groupes de paramètres de protocole](#groupes-de-paramètres-de-protocole)\n+ [Votes](#votes)\n  - [État de gouvernance](#état-de-gouvernance)\n  - [Modifications apportées à l'instantané de mise](#modifications-apportées-à-linstantané-de-mise)\n  - [Définitions relatives à la participation de vote](#définitions-relatives-à-la-participation-de-vote)\n\n### La Constitution Cardano\n\nLa Constitution de Cardano est un document texte qui définit les valeurs communes et les principes directeurs de Cardano.\nÀ ce stade, la Constitution est un document d’information qui capture sans ambiguïté les valeurs fondamentales de Cardano\net agit pour assurer sa viabilité à long terme.\nÀ un stade ultérieur, nous pouvons imaginer que la Constitution évolue peut-être vers un ensemble de règles basées sur des contrats intelligents qui régissent l’ensemble du cadre de gouvernance.\nPour l’instant, cependant, la Constitution restera un document hors chaîne dont la valeur de condensation de hachage sera enregistrée sur la chaîne.\nComme nous l’avons vu plus haut, la Constitution n’est pas encore définie et son contenu n’entre pas dans le champ d’application de ce CIP.\n\n<!--------------------------- Comité constitutionnel ------------------------>\n\n### Le comité constitutionnel\n\nNous définissons un _comité constitutionnel_ qui représente un ensemble d’individus ou d’entités\n(chacun associé à un identifiant Ed25519 ou un identifiant de script natif ou Plutus) qui sont collectivement responsables de **veiller à ce que la Constitution soit respectée**.\n\nBien qu’il **ne puisse pas être appliqué en chaîne**, le comité constitutionnel est **seulement** censé voter\nsur la constitutionnalité des actions de gouvernance (qui devraient ainsi assurer la viabilité à long terme de la blockchain) et devraient être remplacées\n(via l’action **non-confiance**) s’ils dépassent cette limite.\nAutrement dit, il existe un contrat social entre le comité constitutionnel et les acteurs du réseau.\nBien que le comité constitutionnel puisse rejeter certaines actions de gouvernance (en votant « non »),\nils ne devraient le faire que lorsque ces mesures de gouvernance sont contraires à la Constitution.\n\nPar exemple, si nous considérons la règle hypothétique de la Constitution « Le réseau Cardano doit toujours être capable de produire de nouveaux blocs »,\nEnsuite, une mesure de gouvernance qui réduirait la taille maximale du bloc à `0` serait, en fait,\ninconstitutionnelle et pourrait donc ne pas être ratifiée par le Comité constitutionnel. La règle\nCependant, ne pas spécifier la plus petite taille maximale acceptable de bloc, de sorte que le Comité constitutionnel devrait déterminer ce nombre\net votez en conséquence.\n\n#### État de non-confiance\n\nLe comité constitutionnel est considéré comme se trouvant à tout moment dans l’un des deux États suivants:\n\n1. un état normal (c’est-à-dire un état de confiance)\n2. un état de non-confiance\n\nDans un _état de non-confiance_, le comité actuel n’est plus en mesure de participer aux mesures de gouvernance\net doivent être remplacés avant que toute mesure de gouvernance puisse être ratifiée (voir ci-dessous).\n\n#### Clés du comité constitutionnel\n\nLe comité constitutionnel utilisera une configuration de clé chaude et froide, similaire au mécanisme existant de « certificat de délégation genesis ».\n\n#### Remplacement du comité constitutionnel\n\nLe comité constitutionnel peut être remplacé via une action de gouvernance spécifique\n(\"Mise à jour du comité\", décrit ci-dessous) qui requiert l'approbation à la fois\ndes **SPOs** et des **DReps**\nLe seuil de ratification peut être différent dépendamment de si la gouvernance est\ndans un état normal ou dans un état de non-confiance.\n\nLe nouveau comité constitutionnel pourrait, en principe, être identique ou partiellement chevaucher le comité sortant tant que l’action est dûment ratifiée.\nCela pourrait se produire, par exemple, si les électeurs ont une confiance collective dans tout ou une partie du comité et souhaitent prolonger son mandat.\n\n\n#### Taille du comité constitutionnel\n\nContrairement à la conception de la gouvernance Shelley, la taille du comité constitutionnel n’est pas fixe et peut être n’importe quel nombre non négatif.\nIl peut être modifié chaque fois qu’un nouveau comité est élu (« Mise à jour du comité »).\nDe même, le seuil du comité (la fraction des votes `Yes` du comité qui sont nécessaires pour ratifier les mesures de gouvernance) n’est pas fixe et\npeut également varier en fonction de la mesure de gouvernance.\nCela donne beaucoup de flexibilité à la composition du comité.\nEn particulier, il est possible d’élire un comité vide si la communauté souhaite supprimer entièrement le comité constitutionnel. Notez que cela est différent d’un état de non-confiance et constitue toujours un système de gouvernance capable de mettre en oeuvre des propositions.\n\nIl y aura un nouveau paramètre du protocole pour la taille minimale du comité,\nlui-même un nombre non négatif appelé `committeeMinSize`.\n\n#### Mandat\n\nChaque comité constitutionnel nouvellement élu aura un mandat.\nLes mandats par membre permettent un système de rotation, par exemple un tiers du comité\nexpirant chaque année.\nLes membres expirés ne peuvent plus voter.\nLe membre peut également volontairement démissionner plus tôt, ce qui sera marqué sur la chaîne comme un membre expiré.\n\nSi le nombre de membres non expirés du comité tombe en dessous de la taille minimale\ndu comité, le comité constitutionnel ne pourra pas ratifier \nles actions de gouvernance. Cela signifie que seules les actions de gouvernance \nqui ne nécessitent pas le vote du comité constitutionnel peuvent toujours \nêtre ratifiées.\n\nPar exemple, un comité de cinq membres avec un seuil de 60%, une taille minimale \nde trois et deux membres expirés peut toujours\nadopter des mesures de gouvernance si deux membres non expirés votent `Yes`.\nCependant, si un autre membre expire alors le comité constitutionnel devient\nincapable de ratifier d’autres actions de gouvernance.\n\nLa durée maximale du mandat est un paramètre du protocole de gouvernance, spécifié en nombre d'époques.\nPendant un état de non-confiance, aucune action ne peut être ratifiée,\nle comité devrait donc prévoir son propre remplacement s'il souhaite éviter les perturbations.\n\n#### Script de rambardes\n\nBien que la constitution soit un document informel hors chaîne, il y aura\négalement un script facultatif qui pourra appliquer certaines directives. Ce scénario\nagit pour compléter le comité constitutionnel en restreignant certains\ntypes de propositions. Par exemple, si la communauté souhaite avoir des règles\nstrictes pour la trésorerie qui ne peuvent être violées, un script qui applique\nces règles peut être voté en tant que script de rambardes.\n\nLe script de rambardes s'applique uniquement aux propositions de mise à jour des paramètres du protocole et \nde retrait de trésorerie.\n\n<!---------------------------           DReps          -------------------------->\n\n### Représentants délégués (DReps)\n\n> **Warning**\n> CIP-1694 DReps **ne doit pas être confondu** avec Project Catalyst DReps.\n\n#### Options de vote prédéfinies\n\nAfin de participer à la gouvernance, un justificatif d’identité de mise doit être délégué à un DRep.\nLes détenteurs d’Ada délégueront généralement leurs droits de vote à un DRep enregistré\nqui voteront en leur nom. De plus, deux options de vote prédéfinies sont disponibles :\n\n* `Abstain`\n\n  Si un détenteur d’Ada délègue à `Abstain`, alors sa mise est activement marquée\n  comme ne participant pas à la gouvernance.\n\n  L’effet de la délégation de `Abstain` sur la chaîne est que la participation déléguée *ne sera pas* considérée comme\n  une partie de la participation active de vote. Toutefois, la participation *sera* considérée comme enregistrée pour\n  l’objectif des incitations décrites dans [Incitations pour les détenteurs d’Ada à déléguer une mise de vote](#incitatifs-pour-les-détenteurs-dada-à-déléguer-une-mise-de-vote).\n\n* `No Confidence`\n\n  Si un détenteur d’Ada délègue à `No Confidence`, sa participation est comptée comme\n  un vote `Yes` pour chaque action de `No Confidence` et un vote `No` pour toute autre action.\n  La participation déléguée *sera* considérée comme faisant partie de la participation au vote actif.\n  Il sert également de mesure directement vérifiable de la confiance des détenteurs d’Ada envers le comité\n  constitutionel.\n\n\n> **Note**\n> Les options de vote prédéfinis ne votent pas à l'intérieur des transactions, leur comportement est pris en compte au niveau du protocole.\n> L'option `Abstain` peut être choisi pour diverses raisons, y compris le désir de ne pas\n> participer au système de gouvernance.\n\n> **Note**\n> Tout détenteur d'Ada peut s'inscrire en tant que DRep et se déléguer s'il souhaite participer activement à\n> vote.\n\n> **Note**\n> Tout portefeuille servant de portefeuille de récompenses enregistré pour un pool de participation peut être délégué à l'une de ces options de vote prédéfinies et servira ainsi d'option de vote par défaut sélectionnée par le SPO pour tous les votes d'action de gouvernance, à l'exception des actions de gouvernance de hard fork. En raison de la nécessité d'un consensus robuste autour des initiations de hard fork, ces votes doivent être respectés en pourcentage de la participation détenue par tous les pools de participation.\n\n#### DReps enregistrés\n\nDans Voltaire, les références de mise existantes seront\nen mesure de déléguer leur participation à des DReps à des fins de vote,\nen plus de la délégation actuelle aux pools de participation pour la production de blocs.\nLa délégation DRep imitera les mécanismes de délégation de mise existants (via des certificats on-chain).\nDe même, l’enregistrement des DReps imitera les mécanismes existants d’enregistrement des mise.\nDe plus, les DReps inscrits devront voter régulièrement pour être toujours considérés comme actifs.\nPlus précisément, si un DRep ne soumet aucun vote pour `drepActivity` - plusieurs époques, le DRep est considéré comme inactif,\noù `drepActivity` est un nouveau paramètre de protocole.\nLes DReps inactifs ne comptent plus dans la participation active des votes, et peut redevenir actif durant un nombre \n`drepActivity` d'époques en votant sur n’importe quel actions de gouvernance ou en soumettant une de mise à jour du certificat de DRep.\nLa raison pour laquelle les DReps sont marqués comme inactifs est que les DReps qui cessent de participer mais qui ont encore\nla mise qui leur est déléguée ne laisse finalement pas le système dans un état où aucune action de\ngouvernance peut passer.\n\nLes DReps enregistrés sont identifiés par un justificatif d’identité qui peut être :\n\n* Une clé de vérification (Ed25519)\n* Un script natif ou Plutus\n\nLe condensé de hachage blake2b-224 d’une informations d’identification DRep sérialisées est appelé _DRep ID_.\n\nLes nouveaux types de certificats suivants seront ajoutés pour les DReps :\nles certificats d’inscription DRep, les certificats de retraite DRep, et\ncertificats de délégation de vote.\n\n##### Certificats d’enregistrement DRep\n\nLes certificats d’inscription DRep comprennent :\n\n* un ID DRep\n* un dépôt\n* une ancre en option\n\nUne **ancre** est une paire de :\n\n* une URL vers une charge utile JSON de métadonnées\n* un hachage du contenu de l’URL des métadonnées\n\nLa structure et le format de ces métadonnées sont délibérément laissés ouverts dans ce CIP.\nLes règles on-chain ne vérifieront ni l’URL ni le hachage.\nLes applications clientes doivent toutefois effectuer les vérifications d’intégrité habituelles lors de la récupération de contenu à partir de l’URL fournie.\n\n\n##### Certificats de retraite DRep\n\nLes certificats de retraite DRep comprennent :\n\n* un ID DRep\n\nNotez qu'un DRep est mis à la retraite dès que la chaîne accepte un certificat de retraite,\net le dépôt est restitué dans le cadre de la transaction qui soumet le certificat de retrait\n(de la même manière que les dépôts d'enregistrement du justificatif de participation sont retournés).\n\n##### Certificats de délégation de vote\n\nLes certificats de délégation de vote comprennent :\n\n* l’ID DRep auquel la participation doit être déléguée\n* les informations d’identification de mise pour le délégant\n\n> **Note**\n>\n> La délégation DRep mappe toujours un justificatif d'identité de mise à un justificatif d'identité DRep.\n> Cela signifie qu'un DRep ne peut pas déléguer une mise de vote à un autre DRep.\n\n##### Schémas d’autorisation de certificat\n\nLe système d’autorisation (c’est-à-dire quelles signatures sont requises pour l’enregistrement, le retrait ou la délégation) imite le système existant d’autorisation de délégation de mise.\n\n<!-- TODO: Fournir la spécification CBOR dans l’annexe pour ces nouveaux certificats. -->\n\n\n#### Nouvelle distribution de la mise pour DReps\n\nEn plus de la distribution existante par délégation de mise et de la\ndistribution par pool de participation, le grand livre déterminera désormais également la distribution de la mise par DRep.\nCette répartition déterminera le montant de la mise par laquelle chaque vote d'un DRep\nest soutenu.\n\n> **Warning**\n>\n> **Contrairement à** la distribution utilisée pour la production de blocs, nous utiliserons toujours la plus\n> récente version de la distribution de mise par DRep telle qu’elle est donnée sur la limite d’époque.\n>\n> Cela signifie que **pour tout sujet qui intéresse profondément les électeurs,\n> ils ont le temps de déléguer à eux-mêmes comme DRep et de voter directement**.\n> Cependant, cela signifie qu’il peut y avoir une différence entre la mise utilisé pour la production\n> de bloc et la mise utilisée pour voter à une époque donnée.\n\n\n#### Incitatifs pour les détenteurs d’Ada à déléguer une mise de vote\n\nIl y aura une courte [phase d’amorçage] (#bootstrapping-phase) au cours de laquelle des récompenses seront gagnées\npour la délégation de mise, etc. et peut être retiré à tout moment.\nAprès cette phase, bien que des récompenses continueront d’être gagnées pour la délégation de blocs, etc., les comptes de récompense seront\n**empêché de retirer des récompenses** à moins que leurs informations d’identification de mise associées ne soient également déléguées à un DRep ou à une option de vote prédéfinie.\nCela contribue à assurer une participation élevée et, par conséquent, une légitimité.\n\n> **Note**\n>\n> Même si les récompenses ne peuvent pas être retirées, elles ne sont pas perdues. Dès qu’un justificatif de mise est délégué\n> (y compris à une option de vote prédéfinie), les récompenses peuvent être retirées.\n\n#### Incitatifs DRep\n\nLes DReps ont sans doute besoin d’être rémunérés pour leur travail. La recherche sur les modèles incitatifs est toujours en cours,\net nous ne souhaitons pas retarder la mise en oeuvre de ce CIP pendant que ce problème est résolu.\n\nNotre proposition provisoire est donc l'entiercement de Lovelace de la trésorerie Cardano existante jusqu’à ce\nqu'une décision extrêmement importante peut être convenue par la communauté, à travers le mécanisme de gouvernance en chaîne\nen cours d’élaboration.\n\nAlternativement, les DReps pourraient se payer par le biais d’instances de l’action de gouvernance « retrait du Trésor ».\nUne telle action serait vérifiable sur la chaîne et devrait refléter un accord hors chaîne entre DReps et les délégants.\n\n<!---------------------------           DReps          ------------------------>\n<!--------------------------- Mesures de gouvernance -------------------------->\n\n### Actions de gouvernance\n\nNous définissons sept types différents d'**actions de gouvernance**.\nUne action de gouvernance est un événement en chaîne qui est déclenché par une transaction et a une date limite après lequel il ne peut être promulgué.\n\n- Une action est dite **ratifiée** lorsqu’elle recueille suffisamment de votes en sa faveur (grâce aux règles et paramètres détaillés ci-dessous).\n- Une action qui ne parvient pas à être ratifiée avant sa date limite est dite **expirée**.\n- Une action qui a été ratifiée est dite **promulguée** une fois qu’elle a été activée sur le réseau.\n\n\n| Action                                                | Description                                                                                                                                                   |\n| :-----------------------------------------------------| :-------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 1. Motion de censure                                  | Une motion pour créer un _état de non-confiance_ au sein du comité constitutionnel actuel                                                                     |\n| 2. Nouveau comité constitutionnel et/ou nouveau seuil | Modification des membres du comité constitutionnel et/ou de son seuil de signature et/ou limites de mandat                                                    |\n| 3. Mises à jour de la Constitution                    | Une modification de la Constitution off-chain, enregistrée en tant que hachage on-chain du document texte                                                     |\n| 4. Hard-Fork[^2] Initiation                           | Déclenche une mise à niveau non rétrocompatible du réseau ; Nécessite une mise à niveau logicielle préalable                                                  |\n| 5. Modifications des paramètres du protocole          | Tout changement **d’un ou de plus** paramètres de protocole pouvant être mis à jour, excluant les changements aux versions majeures du protocole (hard forks) |\n| 6. Retraits de trésorerie                             | Retraits de la trésorerie                                                                                                                                     |\n| 7. Infos                                              | Action qui n’a aucun effet sur la chaîne, autre qu’un enregistrement sur la chaîne.                                                                           |\n\n**Tout détenteur d’Ada** peut soumettre une action de gouvernance à la chaîne.\nIls doivent fournir un dépôt de `govActionDeposit` Lovelace, qui sera retourné lorsque l’action sera finalisée\n(s’il est **ratifié** ou **a expiré**).\nLe montant du dépôt sera ajouté au _pot de dépôt_, similaire aux dépôts clés de mise.\nIl sera également pris en compte dans la mise de l’adresse de récompense à laquelle il sera remboursé, afin de ne pas réduire le pouvoir de vote du déposant pour voter sur ses propres actions (et concurrentes).\n\nSi un script de rambardes est présente, la transaction doit inclure ce\nscript dans le témoin soit directement, soit via des entrées de référence,\net toutes les autres exigences imposées par le script de rambardes doivent être\nsatisfaites.\n\nNotez qu’une motion de non-confiance est une mesure extrême qui permet aux détenteurs d’Ada de révoquer le pouvoir\nqui a été accordé à l’actuel Comité constitutionnel.\n\n> **Note**\n> Une **seule** action de gouvernance peut contenir **plusieurs** mises à jour des paramètres de protocole. De nombreux paramètres sont interconnectés et peuvent nécessiter d'être déplacés en synchronisme.\n\n#### Ratification\n\nLes mesures de gouvernance sont **ratifiées** par le biais d’actions de vote en chaîne.\nDifférents types d'action de gouvernance ont des exigences de ratification différentes, mais impliquent toujours **deux des trois** organes de gouvernance,\nà l’exception d’une initiative de hard fork et paramètres de protocole liés à la sécurité, qui nécessite la ratification de tous les organes de gouvernance.\nSelon le type d’action de gouvernance, une action sera donc ratifiée lorsqu’une combinaison des éléments suivants se produit :\n\n* le comité constitutionnel approuve l’action (le nombre de membres qui votent `Yes` atteint le seuil du comité constitutionnel)\n* les DReps approuvent l’action (la participation contrôlée par les DReps qui votent `Yes` atteint un certain seuil de la mise totale active des votes)\n* les SPO approuvent l'action (la participation contrôlée par les SPO qui votent « Oui » atteint un certain seuil de la participation totale de vote active, à l'exception des actions de gouvernance Hard Fork)\n\n> **Warning**\n> Comme expliqué ci-dessus, différentes distributions de mise s’appliquent aux DReps et aux SPO.\n\nUne motion de non-confiance réussie, la mise à jour du comité constitutionnel,\nun changement constitutionnel, ou un hard fork, retarde\nla ratification de toutes les autres mesures de gouvernance jusqu’à la première époque suivant leur promulgation. Cela donne\nà un comité constitutionnel mis à jour suffisamment de temps pour voter sur les propositions actuelles, réévaluer les propositions existantes\nà l’égard d’une nouvelle constitution, et veille à ce que les changements sémantiques arbitraires de principe entraîné\nen adoptant un hard-fork n’ont pas de conséquences imprévues en combinaison avec d’autres actions.\n\n##### Exigences\n\nLe tableau suivant détaille les exigences de ratification pour chaque scénario d’action de gouvernance. Les colonnes représentent :\n\n* **Type d’action de gouvernance**<br/>\n Type de mesure de gouvernance. Notez que les mises à jour des paramètres de protocole sont regroupées en quatre catégories.\n\n* **Comité constitutionnel (abréviation CC)**<br/>\n Une valeur de ✓ indique que le comité constitutionnel doit approuver cette action.<br/>\n Une valeur de - signifie que les votes du comité constitutionnel ne s’appliquent pas.\n\n* **DReps**<br/>\n Le seuil de vote DRep qui doit être atteint en pourcentage de la *participation de vote active*.\n\n* **SPO**<br/>\n Le seuil de vote SPO doit être atteint en tant que certain seuil de la participation totale active au vote, à l'exception des actions de gouvernance Hard Fork. En raison de la nécessité d'un consensus solide autour des initiations Hard Fork, ces votes doivent être atteints en tant que pourcentage de la participation détenue par tous les pools de participation.<br/>\n Une valeur de - signifie que les votes SPO ne s’appliquent pas.\n\n| Type d’action de gouvernance                                                    | CC  | DReps    | SPOs     |\n|:--------------------------------------------------------------------------------|:----|:---------|:---------|\n| 1. Motion de non-confiance                                                      | \\-  | $P_1$    | $Q_1$    |\n| 2<sub>a</sub>. Mise à jour du comité/seuil (_état normal_)                      | \\-  | $P_{2a}$ | $Q_{2b}$ |\n| 2<sub>b</sub>. Mise à jour du comité/seuil (_état de non-confiance_)            | \\-  | $P_{2b}$ | $Q_{2b}$ |\n| 3. Nouvelle Constitution ou script de rambardes                                 | ✓   | $P_3$    | \\-       |\n| 4. Initiation du hard fork                                                      | ✓   | $P_4$    | $Q_4$    |\n| 5<sub>a</sub>. Modifications des paramètres de protocole, groupe réseau         | ✓   | $P_{5a}$ | \\-       |\n| 5<sub>b</sub>. Modifications des paramètres du protocole, groupe économique     | ✓   | $P_{5b}$ | \\-       |\n| 5<sub>c</sub>. Modifications des paramètres de protocole, groupe technique      | ✓   | $P_{5c}$ | \\-       |\n| 5<sub>d</sub>. Modifications des paramètres de protocole, groupe de gouvernance | ✓   | $P_{5d}$ | \\-       |\n| 6. Retrait du Trésor                                                            | ✓   | $P_6$    | \\-       |\n| 7. Infos                                                                        | ✓   | $100$    | $100$    |\n\nChacun de ces seuils est un paramètre de gouvernance. Il y a un \nseuil supplémentaire, « Q5 », lié aux paramètres de protocole pertinents pour la sécurité, \nqui est expliqué ci-dessous.\nLes seuils initiaux devraient être choisis par la communauté Cardano dans son ensemble.\nTous les seuils de l'action Info sont définis à 100 % car le fixer plus bas\nentraînerait l'impossibilité de sonder au-dessus du seuil.\n\nCertains paramètres sont pertinents pour les propriétés de sécurité du système. Toute\nproposition tentant de modifier un tel paramètre nécessite un vote supplémentaire \ndes SPOs, avec le seuil `Q5`.\n\nLes paramètres de protocole pertinents pour la sécurité sont :\n* `maxBlockBodySize`\n* `maxTxSize`\n* `maxBlockHeaderSize`\n* `maxValueSize`\n* `maxBlockExecutionUnits`\n* `txFeePerByte`\n* `txFeeFixed`\n* `utxoCostPerByte`\n* `govActionDeposit`\n* `minFeeRefScriptCostPerByte`\n\n> **Note**\n> Il peut être logique que certains ou tous les seuils s’adaptent en ce qui concerne le Lovelace qui est activement inscrit pour voter.\n> Par exemple, un seuil pourrait varier entre 51 % pour un niveau élevé d’enregistrement et 75 % pour un niveau d’enregistrement faible.\n> En outre, le seuil de trésorerie pourrait également être adaptatif, en fonction du Lovelace total qui est retiré,\n> ou différents seuils pourraient être fixés pour différents niveaux de retrait.\n\n> **Note**\n> Pour atteindre la légitimité, le seuil minimum acceptable ne devrait pas être inférieur à 50% de la mise déléguée.\n\n\n##### Restrictions\n\nOutre _Retrait du trésor_ et _Infos_, nous incluons un mécanisme pour assurer que les actions de gouvernance\ndu même type ne se heurtent pas accidentellement de manière inattendue.\n\nChaque action de gouvernance doit inclure l’ID de l’action de gouvernance de l’action la plus récente adoptée de son type donné.\nCela signifie que deux actions du même type peuvent être promulguées en même temps,\nMais ils doivent être *délibérément* conçus pour le faire.\n\n\n#### Promulgation\n\nLes actions qui ont été ratifiées à l’époque actuelle sont classées par ordre de priorité comme suit pour la promulgation :\n\n1. Motion de non-confiance\n2. Mise à jour du comité/seuil\n3. Nouvelle Constitution ou script de rambardes\n4. Initiation du hard fork\n5. Modifications des paramètres du protocole\n6. Retraits du Trésor\n7. Infos\n\n> **Note** La promulgation des actions _Info_ est une action nulle, car elles n’ont aucun effet sur le protocole.\n\n##### Ordre de promulgation\n\nLes actions de gouvernance sont mises en oeuvre par ordre d’acceptation dans la chaîne.\nCela résout les conflits où, par exemple, il y a deux changements de paramètres concurrents.\n\n#### Cycle de vie\n\nLes actions de gouvernance ne sont vérifiées pour ratification que sur une limite d’époque.\nUne fois ratifiée, des actions sont organisées en vue de leur promulgation.\n\nToutes les actions de gouvernance soumises seront donc soit :\n\n1. **ratifié**, puis **promulgué**\n2. ou **expirée** après un certain nombre d’époques\n\nDans tous ces cas, les dépôts sont retournés immédiatement.\n\nToutes les actions de gouvernance sont adoptées à la frontière de l'époque après leur ratification.\n\n#### Contenu\n\nChaque mesure de gouvernance comprendra les éléments suivants :\n\n* un montant de dépôt (enregistré puisque le montant du dépôt est un paramètre de protocole pouvant être mis à jour)\n* une adresse de récompense pour recevoir le dépôt lorsqu’il est remboursé\n* une ancre pour toutes les métadonnées nécessaires pour justifier l’action\n* une valeur de condensé de hachage pour éviter les collisions avec des actions concurrentes du même type (comme décrit précédemment)\n\n<!-- TODO: Fournir une spécification CBOR dans l’annexe pour ces nouvelles entités sur la chaîne -->\n\nDe plus, chaque action comprendra certains éléments spécifiques à son type :\n\n| Type d’action de gouvernance                                  | Données supplémentaires                                                                                                                            |\n|:--------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------|\n| 1. Motion de non-confiance                                    | Aucune                                                                                                                                             |\n| 2. Mise à jour du comité/seuil                                | L’ensemble des résumés de hachage de clé de vérification (membres à supprimer), une carte des résumés de hachage de clé de vérification aux numéros d'époque (nouveaux membres et leur limite de mandat) et une fraction (nouveau seuil)                                                                                                                               |\n| 3. Nouvelle Constitution ou script de rambardes               | Un condensé de hachage du document constitutionnel                                                                                                 |\n| 4. Initiation du hard fork                                    | La nouvelle version majeure du protocole                                                                                                           |\n| 5. Modifications des paramètres du protocole                  | Les paramètres modifiés                                                                                                                            |\n| 6. Retrait du Trésor                                          | Une carte d’identification de mise à un nombre positif de Lovelace                                                                                 |\n| 7. Infos                                                      | Aucune                                                                                                                                             |\n\n> **Note**\n> La nouvelle version majeure du protocole doit être précisément supérieure d’une à la version actuelle du protocole.\n> Deux époques consécutives quelconques auront donc soit la même version de protocole majeure, soit le\n> plus tard, on aura une version de protocole majeure qui est une plus grande.\n\n> **Note**\n> Il ne peut y avoir de doublons entre les membres d’un comité - chaque paire de clé de références dans un comité doit être unique.\n\nChaque action de gouvernance acceptée sur la chaîne se verra attribuer un identifiant unique (alias l'**ID de l’action de gouvernance**),\ncomposé du hachage de transaction qui l’a créé et de l’index dans le corps de la transaction qui pointe vers lui.\n\n#### Groupes de paramètres de protocole\n\nNous avons regroupé les changements de paramètres de protocole par type,\npermettant de fixer différents seuils pour chaque groupe.\n\nToutefois, nous ne limitons pas chaque action de gouvernance des paramètres de protocole à un seul groupe.\nDans le cas où une action de gouvernance contient des mises à jour pour plusieurs paramètres de différents groupes,\nle seuil maximal de tous les groupes concernés s’appliquera à toute mesure de gouvernance donnée.\n\nLes groupes de paramètres _réseaux_, _économique_ et _technique_ collectent les paramètres de protocole existants qui ont été introduits pendant les ères Shelley, Alonzo et Babbage.\nDe plus, nous introduisons un nouveau groupe _gouvernance_ qui est spécifique aux nouveaux paramètres de gouvernance qui seront introduits par le CIP-1694.\n\nLe **groupe de réseaux** se compose de :\n* taille maximale du corps du bloc (`maxBlockBodySize`)\n* taille maximale de la transaction (`maxTxSize`)\n* taille maximale de l’en-tête de bloc (`maxBlockHeaderSize`)\n* taille maximale d’une valeur de ressource sérialisée (`maxValueSize`)\n* nombre maximal d’unités d’exécution de script dans une seule transaction (`maxTxExecutionUnits`)\n* nombre maximal d’unités d’exécution de script dans un seul bloc (`maxBlockExecutionUnits`)\n* nombre maximal d’entrées collatérales (`maxCollateralInputs`)\n\nLe **groupe économique** comprend :\n* coefficient de redevance minimal (`txFeePerByte`)\n* constante de frais minimum (`txFeeFixed`)\n* clé de délégation Lovelace dépôt (`stakeAddressDeposit`)\n* inscription à la piscine Dépôt Lovelace (`stakePoolDeposit`)\n* expansion monétaire (`monetaryExpansion`)\n* expansion de la trésorerie (`treasuryCut`)\n* réduction des primes fixes minimales pour les pools (`minPoolCost`)\n* dépôt minimum de Lovelace par octet d’UTxO sérialisé (`utxoCostPerByte`)\n* prix des unités d’exécution de Plutus (`executionUnitPrices`)\n\nLe **groupe technique** est composé de :\n* l'influence du pool pledge (`poolPledgeInfluence`)\n* époque maximale du retrait du pool (`poolRetireMaxEpoch`)\n* nombre souhaité de pools (`stakePoolTargetNum`)\n* modèles de coûts d’exécution de Plutus (`costModels`)\n* proportion de collatéral nécessaire pour les scripts (`collateralPercentage`)\n\nLe **groupe de gouvernance** comprend tous les nouveaux paramètres de protocole introduits dans ce CIP :\n* seuils de vote de gouvernance ($P_1$, $P_{2a}$, $P_{2b}$, $P_3$, $P_4$, $P_{5a}$, $P_{5b}$, $P_{5c}$, $P_{5d}$, $P_6$, $Q_1$, $Q_{2a}$, $Q_{2b}$, $Q_4$, $Q_5$)\n* durée de vie maximale de l'action de gouvernance en époques (`govActionLifetime`)\n* dépôt d'action de gouvernance (`govActionDeposit`)\n* montant du dépôt DRep (`dRepDeposit`)\n* période d’activité DRep en époques (`dRepActivity`)\n* taille minimale du comité constitutionnel (`committeeMinSize`)\n* durée maximale du mandat (en époques) des membres du comité constitutionnel (`committeeMaxTermLength`)\n\n<!-- À faire :\n - Décider des valeurs initiales des nouveaux paramètres de gouvernance\n \n - Décider des conditions de cohérence des seuils de vote.\n Par exemple, le seuil d’une motion de censure devrait sans doute être plus élevé que celui d’un retrait mineur du Trésor.\n-->\n\n<!--------------------------- Actions de Gouvernance -------------------------->\n\n<!---------------------------          Votes           ------------------------>\n\n### Votes\n\nChaque transaction de vote comprend les éléments suivants :\n\n* un ID d’action de gouvernance\n* un rôle - membre du comité constitutionnel, DRep ou SPO\n* un témoin d’informations d’identification de gouvernance pour le rôle\n* une ancre en option (tel que défini ci-dessus) pour les renseignements pertinents au vote;\n* un vote 'Oui'/'Non'/'Abstention'\n\nPour les SPO et les DReps, le nombre de votes exprimés (que ce soit 'Oui', 'Non' ou 'Abstention') est proportionnel au Lovelace qui leur est déléguée au moment où\nl’action est vérifiée pour ratification. Pour les membres du comité constitutionnel, chaque membre actuel du comité dispose d’un vote.\n\n> **Warning** Les votes 'Abstention' ne sont pas inclus dans la « participation active ».\n>\n> Notez qu’un vote explicite pour s’abstenir diffère de l’abstention de voter.\n> La mise non enregistré qui n’a pas voté se comporte comme un vote 'Abstention',\n> alors que la mise enregistré qui n’a pas voté se comporte comme un vote 'non'.\n> Pour éviter toute confusion, nous n’utiliserons le mot 'Abstention' qu’à partir de maintenant pour signifier un vote en chaîne pour s’abstenir.\n\nLe témoin d’informations d’identification de gouvernance déclenchera les vérifications appropriées dans le registre conformément à la règle de registre « UTxOW » existante\n(c’est-à-dire une vérification de signature pour les clés de vérification, et une exécution de validateur avec un rédempteur de vote spécifique et un nouvel objectif de script Plutus pour les scripts).\n\nLes votes peuvent être exprimés plusieurs fois pour chaque action de gouvernance par un seul témoin d’informations d’identification.\nLes votes correctement soumis remplacent tous les votes plus anciens pour les mêmes informations d’identification et le même rôle.\nC’est-à-dire que l’électeur peut changer sa position sur n’importe quelle action s’il le souhaite.\nDès qu’une mesure de gouvernance est ratifiée, le vote prend fin et les transactions contenant d’autres votes sont invalides.\n\n#### État de gouvernance\n\nLorsqu’une action de gouvernance est soumise avec succès à la chaîne, sa progression sera suivie par l’état du grand livre.\nEn particulier, les éléments suivants seront suivi :\n\n* l’ID de l’action de gouvernance\n* l’époque à laquelle l’action expire\n* le montant du dépôt\n* l’adresse des récompenses qui recevra le dépôt lorsqu’il sera retourné\n* le total des votes 'Oui'/'Non'/'Abstention' du comité constitutionnel pour cette action\n* le total des votes 'Oui'/'Non'/'Abstention' des DReps pour cette action\n* le total des votes 'Oui'/'Non'/'Abstention' des SPO pour cette action\n\n\n#### Modifications apportées à l’instantané de mise\n\nÉtant donné que l’instantané de mise change à chaque limite d’époque, un nouveau décompte doit être calculé lorsque chaque mesure de gouvernance non ratifiée\nest vérifié pour la ratification. Cela signifie qu’une action pourrait être promulguée même si les votes DRep ou SPO n’ont pas changé\n(puisque la délégation de vote aurait pu changer).\n\n#### Définitions relatives à la participation de vote\n\nNous définissons un certain nombre de nouveaux termes liés à la participation de vote :\n\n* Lovelace contenu dans une sortie de transaction est considéré comme **actif pour le vote** (c’est-à-dire qu’il forme la « participation de vote active ») :\n  * Il contient une identification de mise enregistrée.\n  * L’accréditation de mise enregistrée a délégué ses droits de vote à un DRep.\n* Par rapport à un certain pourcentage `P`, un seuil de vote DRep (SPO) **a été atteint** si la somme de la mise relative qui a été déléguée aux DReps (SPO)\n qui votent `Yes` à une mesure de gouvernance\n est au moins `P`.\n\n## Raison d’être\n\n+ [Rôle du comité constitutionnel](#rôle-du-comité-constitutionnel)\n+ [Omission intentionnelle de la vérification de l’identité](#omission-intentionnelle-de-la-vérification-didentité)\n+ [Réduire le pouvoir des entités avec de grandes quantités d’Ada](#réduire-la-puissance-des-entités-avec-de-grandes-quantités-dada)\n+ [Greffage sur la distribution des mises du pool de participation](#greffage-sur-la-distribution-des-mises-du-pool-de-participation)\n+ [Séparation de l’initiation du hard-fork des modifications des paramètres de protocole standard](#séparation-de-linitiation-du-hard-fork-des-modifications-des-paramètres-du-protocole-standard)\n+ [Le but des DReps](#le-but-des-dreps)\n+ [Tableau des exigences de ratification](#tableau-des-exigences-de-ratification)\n+ [Motion de non-confiance](#motion-de-non-confiance)\n+ [Mise à jour du comité/seuil (état de non-confiance)](#mide-à-jours-du-comitéseuil-état-de-non-confiance)\n+ [La polyvalence de l’action de gouvernance de l'information](#la-polyvalence-de-laction-de-gouvernance-de-linformation)\n+ [Initiation hard-fork](#initiation-hard-fork)\n+ [Nouvelles structures de métadonnées](#nouvelles-structures-de-métadonnées)\n+ [Contrôle du nombre d’actions de gouvernance actives](#contrôle-du-nombre-dactions-de-gouvernance-actives)\n+ [Pas d’AVST](#pas-davst)\n\n### Rôle du comité constitutionnel\n\nÀ première vue, le comité constitutionnel peut sembler être un comité spécial qui s’est vu accorder un pouvoir supplémentaire sur les DReps.\nCependant, étant donné que DReps peut remplacer le comité constitutionnel à tout moment et que les votes DRep sont également nécessaires pour ratifier chaque action de gouvernance,\nle comité constitutionnel n’a pas plus (et peut, en fait, avoir moins) de pouvoir que le DReps.\nDans ce contexte, quel rôle le comité joue-t-il et pourquoi n’est-il pas superflu?\nLa réponse est que le comité résout le problème d’amorçage du nouveau cadre de gouvernance.\nEn effet, dès que nous appuyons sur la gâchette et permettons à ce cadre de devenir actif sur la chaîne, alors sans comité constitutionnel,\nil faudrait rapidement qu’il y ait suffisamment de DReps, afin que le système ne repose pas uniquement sur les votes SPO.\nNous ne pouvons pas encore prédire à quel point la communauté sera active dans l’inscription en tant que DReps, ni dans quelle mesure les autres détenteurs d’Ada seront réactifs en ce qui concerne la délégation de votes.\n\nAinsi, le comité constitutionnel entre en jeu pour s’assurer que le système peut passer de\nson état actuel dans une gouvernance entièrement décentralisée en temps voulu.\nDe plus, à long terme, le comité peut jouer un rôle de mentorat et de conseil dans les décisions de gouvernance\nen étant un ensemble de représentants élus qui sont mis sous les projecteurs pour leur jugement et leur orientation dans les décisions de gouvernance.\nPar-dessus tout, le comité est tenu à tout moment de respecter la Constitution et de ratifier les propositions conformément aux dispositions de la Constitution.\n\n### Omission intentionnelle de la vérification d’identité\n\nNotez que ce CIP ne mentionne aucun type de validation ou de vérification d’identité pour les membres du comité constitutionnel ou du DReps.\n\nC’est intentionnel.\n\nNous espérons que la communauté envisagera fortement de ne voter que pour et de déléguer aux DReps qui fournissent quelque chose comme un DID pour s’identifier.\nCependant, l’application de la vérification d’identité est très difficile sans un oracle centralisé, que nous considérons comme un pas dans la mauvaise direction.\n\n### Réduire la puissance des entités avec de grandes quantités d’Ada\n\nDivers mécanismes, tels que le vote quadratique, ont été proposés pour se prémunir contre les entités ayant une grande influence.\nDans un système basé sur « 1 Lovelace, 1 vote », cependant, il est trivialement facile de diviser la mise en petits montants et d’annuler les protections.\nSans un système de vérification d’identité en chaîne, nous ne pouvons pas adopter de telles mesures.\n\n### Greffage sur la distribution des mises du pool de participation\n\nLe protocole Cardano est basé sur un mécanisme de consensus Proof-of-Stake, il est donc judicieux d’utiliser une approche de gouvernance basée sur les enjeux.\nCependant, il existe de nombreuses façons de définir comment enregistrer la répartition des mises entre les participants.\nPour rappel, les adresses réseau peuvent actuellement contenir deux ensembles d’informations d’identification : une pour identifier qui peut débloquer des fonds à une adresse\n(alias informations d’identification de paiement) et qui peut être délégué à un pool de participations (alias informations d’identification de délégation).\n\nPlutôt que de définir un troisième ensemble d’informations d’identification, nous proposons plutôt de réutiliser les informations d’identification de délégation existantes,\nUtilisation d’un nouveau certificat on-chain pour déterminer la répartition des mise de gouvernance. Cela implique que l’ensemble des DReps peut (et sera probablement) différent de l’ensemble des SPO,\ncréant ainsi un équilibre. D’un autre côté, cela signifie que la répartition des mise de gouvernance souffre des mêmes lacunes que celle de la production en blocs :\npar exemple, les fournisseurs de logiciels de portefeuille doivent prendre en charge les systèmes de multidélégation et doivent faciliter le partitionnement de la mise en sous-comptes si un détenteur d’Ada souhaite déléguer à plusieurs DReps,\nou un détenteur d’Ada doit diviser manuellement sa mise si son portefeuille ne le prend pas en charge.\n\nCependant, ce choix limite également les efforts futurs de mise en oeuvre pour les fournisseurs de portefeuilles et minimise l’effort nécessaire pour que les utilisateurs finaux participent au protocole de gouvernance.\nCette dernière préoccupation est suffisamment importante pour justifier la décision. En se greffant sur la structure existante,\nLe système reste familier aux utilisateurs et raisonnablement facile à configurer. Cela maximise à la fois les chances de succès et le taux de participation au cadre de gouvernance.\n\n### Séparation de l’initiation du hard fork des modifications des paramètres du protocole standard\n\nContrairement aux autres mises à jour des paramètres de protocole, les hard forks (ou, plus exactement, les modifications apportées au numéro de version majeure du protocole) nécessitent beaucoup plus d’attention.\nEn effet, alors que d’autres modifications des paramètres de protocole peuvent être effectuées sans modifications logicielles significatives,\nun hard fork suppose qu’une super-majorité du réseau a mis à niveau le noeud Cardano pour prendre en charge le nouvel ensemble de fonctionnalités introduites par la mise à niveau.\nCela signifie que le calendrier d’un événement hard fork doit être communiqué bien à l’avance à tous les utilisateurs de Cardano et nécessite une coordination entre les opérateurs de pool de participations, les fournisseurs de portefeuille, les développeurs DApp et l’équipe de libération des noeuds.\n\nPar conséquent, cette proposition, contrairement au schéma Shelley, encourage les initiations de hard fork en tant qu’action de gouvernance autonome, distincte des mises à jour des paramètres de protocole.\n\n### Le but des DReps\n\nRien dans cette proposition n’empêche les SPO de devenir des DReps.\nPourquoi avons-nous des DReps?\nLa réponse est que les SPO sont choisis uniquement pour la production de blocs et que tous les SPO ne voudront pas devenir DReps.\nLes électeurs peuvent choisir de déléguer leur vote aux DReps sans avoir à se demander s’ils sont\négalement un bon producteur de blocs, et les SPO peuvent choisir de représenter les détenteurs d’Ada ou non.\n\n### Tableau des exigences de ratification\n\nLes conditions énoncées dans le [tableau des conditions de ratification](#exigences) sont expliquées ici.\nLa plupart des actions de gouvernance ont le même type d’exigences :\nle comité constitutionnel et le DReps doivent atteindre un nombre suffisant de\nVotes 'Oui'.\nCela inclut les actions suivantes :\n* Mise à jour du comité/seuil (état normal)\n* Nouvelle Constitution\n* Modifications des paramètres de protocole\n* Retrait du Trésor\n\n### Motion de non-confiance\n\nUne motion de censure représente un manque de confiance de la part de la communauté de Cardano à l’égard de la\nLe Comité constitutionnel actuel et, par conséquent, le Comité constitutionnel ne devraient pas\nêtre inclus dans ce type de mesure de gouvernance.\nDans cette situation, les SPOs et les DReps sont laissés à représenter la volonté de la communauté.\n\n### Mise à jour du comité/seuil (état de non-confiance)\n\nSemblable à la motion de non-confiance, l’élection d’un comité constitutionnel\ndépend à la fois des SPOs et des DReps pour représenter la volonté de la communauté.\n\n### La polyvalence de l’action de gouvernance de l’information\n\nBien qu’elle ne soit pas contraignante pour la chaîne, l’action de gouvernance de l’information pourrait être utile dans un certain nombre de\nSituations. Il s’agit notamment des éléments suivants :\n\n* ratifier un CIP\n* Décider du fichier Genesis pour une nouvelle ère de grand livre\n* consigner les commentaires initiaux pour les futures mesures de gouvernance\n\n### Initiation Hard-Fork\n\nIndépendamment de tout mécanisme de gouvernance, la participation des SPO est nécessaire pour tout hard fork car ils doivent mettre à niveau leur logiciel de noeud.\nPour cette raison, nous rendons leur coopération explicite dans l’action de gouvernance d’initiation hard fork,\nen exigeant toujours leur vote.\nLe comité constitutionnel vote également, signalant la constitutionnalité d’un hard fork.\nLes DReps votent également, pour représenter la volonté de chaque partie prenante.\n\n### Nouvelles structures de métadonnées\n\nLes actions de gouvernance, les votes et les certificats et la Constitution utilisent de nouveaux champs de métadonnées,\nsous forme d’URL et de hachages d’intégrité\n(reflétant la structure des métadonnées pour l’enregistrement du pool de participation).\nLes métadonnées sont utilisées pour fournir un contexte.\nLes actions de gouvernance doivent expliquer pourquoi elles sont nécessaires,\nquels experts ont été consultés, etc.\nÉtant donné que les contraintes de taille des transactions ne devraient pas limiter ces données explicatives,\nnous utilisons plutôt des URL.\n\nCela introduit toutefois de nouveaux problèmes.\nSi une URL ne se résout pas, à quoi faut-il s’attendre pour voter sur cette action ?\nDevrions-nous nous attendre à ce que tout le monde vote 'non'?\nS’agit-il d’un vecteur d’attaque contre le système de gouvernance ?\nDans un tel scénario, la pré-image de hachage pourrait être communiquée d’autres manières, mais nous devrions être\npréparé à la situation.\nDevrait-il y avoir un résumé de la justification sur la chaîne?\n\n#### Alternative : Utilisation des métadonnées de transaction\n\nAu lieu de champs dédiés spécifiques au format transactionnel, nous pourrions utiliser le champ de métadonnées de transaction existant.\n\nLes métadonnées liées à la gouvernance peuvent être clairement identifiées en enregistrant une étiquette de métadonnées CIP-10.\nDans ce cadre, la structure des métadonnées peut être déterminée par ce CIP (format exact à déterminer), à l’aide d’un index pour mapper l’ID de vote ou d’action de gouvernance à l’URL et au hachage des métadonnées correspondants.\n\nCela évite d’avoir à ajouter des champs supplémentaires au corps de la transaction, au risque de faciliter l’ignorance des déposants.\nToutefois, étant donné que les métadonnées requises peuvent être vides (ou peuvent pointer vers une URL non résolue),\nIl est déjà facile pour les auteurs de fournir des métadonnées, et il n’est donc pas clair si cela aggrave la situation.\n\nNotez que les métadonnées de transaction ne sont jamais stockées dans l’état du grand livre, de sorte que ce serait aux clients de décider.\npour coupler les métadonnées avec les actions et les votes dans cette alternative, et ne serait pas disponible\nen tant que requête d’état du grand livre.\n\n### Contrôle du nombre d’actions de gouvernance actives\n\nÉtant donné que les actions de gouvernance peuvent être soumises par tous, nous avons besoin d’un mécanisme pour empêcher\nles personnes responsables du vote de ne pas être submergées par un flot de propositions.\nUn dépôt important est l’un de ces mécanismes, mais cela se fait au prix malheureux d’être un obstacle\npour certaines personnes qui souhaiteraient soumettent une action.\nNotez cependant que le crowd-sourcing avec un script Plutus est toujours une option pour collecter le dépôt.\n\nNous pourrions, alternativement, accepter la possibilité d’un grand nombre d’actions actives à un temps donné\net plutôt dépendre de la socialisation hors chaîne pour guider l’attention des électeurs vers ceux qui le méritent.\nDans ce scénario, le comité constitutionnel pourrait choisir de n’examiner que les propositions qui ont\na déjà recueilli suffisamment de votes de la part des DReps.\n\n### Pas d’AVST\n\nUne version antérieure de ce CIP incluait la notion d’un « seuil de mise active » ou AVST.\nLe but de l’AVST était d’assurer la légitimité de chaque vote, en éliminant la possibilité que, par exemple,\n9 Lovelace sur 10 pourraient décider du sort de millions d’entités sur Cardano.\nIl y a vraiment deux préoccupations ici, qui méritent d’être séparées.\n\nLa première préoccupation est celle de l’amorçage du système, c’est-à-dire d’atteindre le moment initial où\nUne participation suffisante est enregistrée pour voter.\nLa deuxième préoccupation est que le système pourrait perdre sa participation au fil du temps.\nL’un des problèmes de l’AVST est qu’elle incite les SPOs à souhaiter un faible taux d’enregistrement au vote.\n(puisque leurs votes ont alors plus de poids).\nCe n’est absolument pas un affront aux SPOs existants, mais un problème avec de mauvaises incitations.\n\nNous avons donc choisi de résoudre les deux préoccupations différemment.\nNous résolvons le problème d’amorçage comme décrit dans la section sur l’amorçage.\nNous résolvons le problème de la participation à long terme en n’autorisant pas les retraits de récompenses\n(après la phase bootstrap) sauf si la participation est déléguée à un DRep\n(y compris les deux cas particuliers, à savoir 'Abstention' et 'Non-confiance').\n\n### Journal des modifications\n\n#### Modifications après l'atelier Longmont (Mars 2023)\n\n* Remerciez les participants à l'atelier.\n* Nous avons ajouté les termes du Comité constitutionnel.\n* Deux nouvelles options de vote « prédéfinies » : abstention et non-confiance.\n* Nouvelle action de gouvernance « Info ».\n* Utilisez la distribution de participation DRep la plus récente pour la ratification.\n  Cela signifie que si jamais votre DRep vote comme vous ne l'aimez pas,\n  vous pouvez immédiatement vous faire un DRep et voter comme vous le souhaitez.\n* Récupérez une partie de l'ADA de la trésorerie actuelle pour d'éventuelles\n  incitations DRep futures.\n* Supprimez les actions de trésorerie à plusieurs niveaux au profit de quelque chose d'adaptatif\n  (le seuil du « Yes » dépendrait donc de :\n      1) combien d'ada,\n      2) quel est le montant de la mise de participation enregistrée, et peut-être\n      3) combien d'ada est libéré à chaque époque\n* Divisez les mises à jour des paramètres de protocole en quatre groupes :\n  réseau, économique, technique et gouvernemental.\n* La plupart des actions de gouvernance peuvent être promulguées (après ratification)\n  immédiatement. Tout sauf : les paramètres de protocole et les hard forks.\n* Supprimez la restriction « une action par type et par époque » en faveur du\n  suivi du dernier ID d'action de chaque type, et de son inclusion\n  dans l'action.\n* Pas d'AVST.\n* Phase d'amorçage : jusqu'à ce que X % des ADA soient inscrits pour voter ou que Y époques se\n  soient écoulées, seuls les changements de paramètres et les hard forks peuvent se produire.\n  Les changements du PP ont juste besoin du seuil du CC, les HF ont besoin du CC et des SPOs.\n  Après la phase de bootstrap, nous mettons en place l'incitation à maintenir des\n  DReps bas, mais ce mécanisme se détend **automatiquement**.\n* Nouvel objectif de script plutus pour DReps.\n* Retraits multiples du Trésor en une seule époque.\n* Une section sur le problème récursif du \"comment ratifier ce CIP\".\n* Modifications apportées au protocole local de requête d'état.\n* Nouvelles idées, si le temps le permet :\n  * Pesez d'une manière ou d'une autre le vote des enjeux SPO par par le « pledge ».\n  * Les DReps peuvent spécifier quel autre DRep recevra ses délégants\n    au cas ou ils se retire.\n* Dépôt réduit pour action gouvernementale si un membre du CC\n  l'approuve (ce qui signifie probablement qu'il a suivi un certain processus).\n* Inclure le hachage de (future) configuration Genesis dans la proposition de HF.\n\n#### Modifications après l'atelier d'Édimbourg (Juillet 2023)\n\n* Ajoutez un script de rambardes, qui peut contrôler quels retraits de trésorerie et\n  modifications des paramètres de protocole sont autorisés.\n* Supprimer l'abandon des actions de gouvernance. Le seul effet que cela a est que si\n  une mesure de censure est adoptée, les actions restent\n  en place. Cependant, seules les nouvelles propositions du comité\n  conçues pour s’appuyer sur cette mesure de censure peuvent être\n  adoptées. Si un nouveau comité est élu alors que certaines de ces actions\n  n'ont pas expiré, ces actions peuvent être ratifiées mais le nouveau comité\n  doit les approuver.\n* All governance actions are enacted one epoch after they are ratified.\n* Déplacez les restrictions post-bootstrapping vers « Autres idées ».\n* Ajoutez une section sur les différents montants de dépôt à « Autres idées ».\n* Ajoutez une section pour un AVS minimum à « Autres idées ».\n* Renommez certains paramètres de protocole.\n* Renommez `TALLY` en `GOV`.\n* Transformez la Constitution en une ancre.\n* Retravaillez quelles ancres sont requises et lesquelles sont facultatives.\n* Nettoyez diverses incohérences et restes des anciennes versions.\n\n#### Modifications liées à la sécurité et autres correctifs (Janvier 2024)\n\n* Protégez les modifications liées à la sécurité derrière les votes SPO.\n* Le système n’entre pas dans un état de non-confiance avec un nombre insuffisant\n  de membres actifs du CC, le CC devient tout simplement incapable d’agir.\n* Précisez que les membres du CC peuvent utiliser n’importe quel type d’identifiant.\n\n#### Mai 2024\n\n* Mise à jour de la section sur la période d'amorçage.\n* Mention du paramètre `Q_5` manquant.\n* Diverses petites corrections/changements de cohérence.\n  \n## Chemin vers Actif\n\n### Critères d’acceptation\n\n- [x] Une nouvelle ère du grand livre est activée sur le réseau principal Cardano, qui implémente la spécification ci-dessus.\n- Gouvernance de la phase d'amorçage via le hardfork Chang #1\n- Gouvernance complète via le hardfork Plomin\n\n### Plan de mise en oeuvre\n\nLes fonctionnalités de ce CIP nécessitent un hard fork.\n\nCe document décrit un changement ambitieux dans la gouvernance de Cardano.\nNous proposons de mettre en œuvre les changements via deux hard forks : le premier\ncontenant toutes les nouvelles fonctionnalités mais certaines étant désactivées pendant une période de démarrage\net le second permettant toutes les fonctionnalités.\n\nDans les sections suivantes, nous donnons plus de détails sur les différents éléments de travail de mise en œuvre qui ont déjà été identifiés.\nEn outre, la dernière section expose quelques questions ouvertes qui devront être finalisées.\nNous espérons que ces questions pourront être abordées dans le cadre d’ateliers et de discussions communautaires.\n\n#### Ratification de cette proposition\n\nLa ratification de cette proposition est en quelque sorte un problème circulaire: nous avons besoin d’une forme de cadre de gouvernance afin de nous mettre d’accord sur ce que devrait être le cadre de gouvernance final.\nComme on l’a dit à maintes reprises, les CIP ne font pas autorité et ne constituent pas un mécanisme de gouvernance.\nIls décrivent plutôt des solutions techniques qui ont été jugées saines (d’un point de vue technique) par la communauté d’experts.\n\nLe CIP-1694 va sans doute au-delà de la portée habituelle du processus de CIP et il y a un fort désir de ratifier ce CIP par le biais de _un processus_.\nToutefois, ce processus n’a pas encore été défini et reste une question ouverte.\nLe processus de ratification finale sera probablement un mélange de diverses idées, telles que:\n\n- [x] Recueillir les opinions des ateliers communautaires, semblables à l’atelier du Colorado de février-mars 2023.\n- [ ] Exercer des actions de vote sur un réseau de test public, avec une participation suffisante.\n- [ ] Interrogez les fournisseurs de services établis.\n- [ ] Tirer parti de Project Catalyst pour recueillir les contributions de la communauté électorale existante (bien que petite en termes de participation active).\n\n#### Modifications apportées au corps de la transaction\n\n- [x] De nouveaux éléments seront ajoutés au corps de la transaction, et les fonctionnalités de mise à jour et MIR existantes seront supprimées. En particulier\n\n Les actions de gouvernance et les votes comprendront deux nouveaux champs d’organe de transaction.\n\n- [x] Trois nouveaux types de certificats seront ajoutés en plus des certificats existants :\n\n  * Inscription DRep\n  * Désinscription DRep\n  * Délégation de vote\n\n De même, les certificats MIR et genesis actuels seront supprimés.\n\n- [x] Un nouvel objectif `Voting` sera ajouté aux contextes de script Plutus.\n Cela prévoira, en particulier, le vote aux scripts on-chain.\n\n> **Warning** Comme d’habitude, nous fournirons une spécification CDDL pour chacune de ces modifications.\n\n#### Modifications apportées aux règles existantes du grand livre\n\n* La règle de transition `PPUP` sera réécrite et déplacée de la règle `UTxO` vers la règle `LEDGER` en tant que nouvelle règle `GOV`.\n\n Il traitera et enregistrera les actions de gouvernance et les votes.\n\n* La règle de transition `NEWEPOCH` sera modifiée.\n* La sous-règle `MIR` sera supprimée.\n* Une nouvelle règle `RATIFY` sera introduite pour mettre en scène les actions de gouvernance en vue de leur promulgation.\n\n Il ratifiera les mesures de gouvernance et les mettra en oeuvre en vue de leur promulgation à l’époque actuelle ou à l’époque suivante, selon le cas.\n\n* Une nouvelle règle de `ENACTMENT` sera appelée immédiatement après la règle `EPOCH` . Cette règle édictera des mesures de gouvernance qui ont déjà été ratifiées.\n* La règle `EPOCH` n’appellera plus la sous-règle `NEWPP` ni ne calculera si le quorum est atteint sur l’état PPUP.\n\n#### Modifications apportées au protocole de requête d’état local\n\nLa charge de travail de gouvernance sur la chaîne est importante, mais la charge de travail hors chaîne pour les outils et les applications sera sans doute encore plus importante.\nPour construire un écosystème de gouvernance efficace, le grand livre devra fournir des interfaces avec divers éléments de gouvernance.\n\nAlors que les votes et les (dé)inscriptions DReps sont directement visibles dans les blocs et seront donc accessibles via les protocoles de synchronisation de la chaîne locale existants; Nous devrons mettre à niveau le protocole de requête d’état local pour fournir des informations supplémentaires sur les informations qui sont plus difficiles à déduire des blocs (c’est-à-dire celles qui nécessitent le maintien d’un état de grand livre). Les nouvelles requêtes d’état doivent couvrir (au moins) :\n\n- Les actions de gouvernance actuellement mises en œuvre\n- Les actions de gouvernance en cours de ratification, avec le total et le pourcentage de mise « oui », de mise « non » et de mise « abstention »\n- Le comité constitutionnel actuel et le condensé de hachage de la constitution\n\n#### Phase d’amorçage\n\nNous devrons faire attention à la façon dont nous amorcerons ce gouvernement naissant. Toutes les parties\nqui sont impliqués auront besoin de suffisamment de temps pour s’inscrire et se familiariser avec le processus.\n\nDes dispositions spéciales s’appliqueront dans la phase initiale de bootstrap.\nTout d’abord, pendant la phase d’amorçage, un vote du comité constitutionnel\nest suffisant pour modifier les paramètres du protocole.\nDeuxièmement, pendant la phase d’amorçage, un vote du comité constitutionnel,\navec un vote SPO suffisant, est suffisant pour initier un hard fork.\nTroisièmement, des actions d'information seront disponibles.\nAucune autre action autre que celles mentionnées dans ce paragraphe n’est possible pendant la phase d’amorçage.\n\nLa phase d'amorçage se termine lorsque le Comité constitutionnel et les SPOs\nratifieront un hard fork ultérieur, permettant les actions de \nde gouvernance restantes et la participation des DReps.\nCela se produira probablement plusieurs mois après le hard fork de Chang.\nBien que toutes les fonctionnalités soient techniquement disponibles à ce stade, des exigences\nsupplémentaires pour l'utilisation de chaque fonctionnalité peuvent être spécifiées dans la constitution.\n\nDe plus, il y aura un comité constitutionnel intérimaire pour une durée déterminée,\négalement spécifié dans le fichier de configuration de la prochaine ère du \"ledger\".\nLe calendrier de rotation du premier comité non intérimaire pourrait être inclus dans la constitution elle-même.\nNotez toutefois que, puisque le comité constitutionnelle ne vote jamais sur de nouveaux comités,\nil ne peut pas réellement imposer la rotation.\n\n#### Autres idées / Questions ouvertes\n\n##### Vote des SPO pondérés par les engagements\n\nLe vote du SPO pourrait en outre être pondéré par l’engagement de chaque SPO.\nCela fournirait un mécanisme permettant à ceux qui ont un intérêt littéral dans le jeu d’avoir un vote plus fort.\nLa pondération doit être choisie avec soin.\n\n##### Redélégation automatique des DReps\n\nUn DRep pourrait éventuellement indiquer un autre identifiant DRep dans son certificat d’enregistrement.\nÀ la retraite, toutes les délégations du DRep seraient automatiquement transférées vers\nles informations d’identification DRep choisi. Si ce DRep avait déjà pris sa retraite, la délégation serait transférée\nà l'option de vote 'Abstention'.\n\n##### Pas d’inscription DRep\n\nÉtant donné que l’enregistrement DRep ne remplit aucune fonction nécessaire,\nles certificats pour (dés)enregistrer DReps pourraient être supprimés. Ceci\nrend la démocratie plus liquide puisqu’elle supprime une partie de la bureaucratie et\nélimine également le besoin du dépôt DRep, au détriment du déplacement de l’ancre qui fait partie du\ncertificat d’enregistrement DRep dans les métadonnées de transaction.\n\n##### Réduction des dépôts pour certaines actions gouvernementales\n\nLe dépôt qui est attaché aux actions de gouvernance existe pour prévenir un flot d'actions de gouvernance non sérieuse,\ndont chacune nécessiterait du temps et de l’attention de la part de la communauté de Cardano.\nNous pourrions réduire ce dépôt pour les propositions qui passent par un processus convenu hors chaîne.\nCela serait marqué sur la chaîne par l’approbation d’au moins un membre du comité constitutionnel.\nL’inconvénient de cette idée est qu’elle donne plus de pouvoir au comité constitutionnel.\n\n##### Différents montants de dépôt pour différentes actions de gouvernance\n\nPlusieurs ateliers de ce CIP ont proposé d'introduire un montant de dépôt différent\npour chaque type d'action de gouvernance. Il n’est pas clair\nsi une majorité est favorable à cette idée, mais elle pourrait être\nenvisagée s’il apparaît clairement que cela est nécessaire.\n\n##### Participation minimale de vote actif\n\nComme garantie supplémentaire pour garantir que les actions de gouvernance ne peuvent pas être proposées\njuste avant un hard fork, être votées par un DRep avec une grande quantité\nde participation et être adoptées immédiatement, il pourrait y avoir une exigence\nsupplémentaire selon laquelle un certain montant absolu fixe de participation\ndoit voter « oui » sur l'action à adopter.\n\nCela ne semble pas nécessaire dans la conception actuelle, puisque la participation de\ntous les DReps enregistrés se comporte comme un vote « non » jusqu'à ce qu'ils aient effectivement\nvoté. Cela signifie que pour que ce scénario se produise, l’acteur malveillant\ndoit au moins contrôler la fraction de la participation du DRep\ncorrespondant au seuil pertinent, auquel cas cela pourrait tout aussi bien être \nconsidéré comme une action légitime.\n\n##### Inclure le hachage de la (future) configuration de la genèse dans la proposition de hard-fork\n\nCertains hard-forks nécessitent de nouvelles configurations de genèse.\nCela a été le cas pour les hard forks Shelley et Alonzo (mais pas Allegra, Mary, Vasil ou Valentine), ce sera peut-être le cas à l’avenir.\nPour le moment, cette proposition ne dit rien sur une telle configuration de genèse :\nIl est implicitement supposé qu’il s’agit d’un accord hors chaîne.\nNous pourrions cependant faire en sorte que (le hachage) d’une configuration de genèse spécifique soit également capturé dans une action de gouvernance hard-fork.\n\n##### Seuils adaptatifs\n\nComme nous l’avons vu plus haut, il peut être logique que certains ou tous les seuils s’adaptent à l’égard du Lovelace qui est activement inscrit pour voter,\nafin que le système offre une plus grande légitimité lorsqu’il n’y a qu’un faible niveau de participation active des votes.\nLe mécanisme d’amorçage proposé ci-dessus peut toutefois englober cela en veillant à ce que le système de gouvernance soit activé\nuniquement lorsqu’un niveau minimum de mise a été délégué à DReps.\n\n\n##### Renommer DReps / état de non-confiance ?\n\nIl a été dit à plusieurs reprises que « DReps » tel que présenté ici, pourrait être confondu avec Project Catalyst DReps.\nDe même, certaines personnes ont exprimé une confusion entre l’état de non-confiance, la motion de non-confiance et l'option de vote non-confiance.\n\nNous pourrions imaginer trouver de meilleurs termes pour ces concepts.\n\n##### Mouvements de trésorerie limitant les taux\n\nRien n’empêche de retirer de l’argent du Trésor autre que les votes proposés et les seuils de vote. Étant donné que le Trésor Cardano est une composante tout à fait fondamentale de sa politique monétaire, nous pourrions imaginer appliquer (au niveau du protocole) le montant maximum qui peut être retiré du Trésor sur une période donnée.\n\n##### Mesure de sécurité finale, post-bootstrapping\n\nDe nombreuses personnes ont déclaré qu'elles pensaient que le taux de participation réel ne serait pas si important\nqu'il constituerait une pression sur le débit du système.\nNous pensons également que cela sera probablement le cas, mais lorsque la phase d'amorçage se terminera, nous pourrions\nmettre en place une dernière mesure de sécurité temporaire (cela nous permettra également de justifier un faible montant de dépôt DRep).\n\nPour les valeurs de $X$ et $Y$ qui restent à déterminer,\ndès la fin de la phase bootstrapping,\nlorsque nous calculerons la distribution des enjeux DReps pour la prochaine limite d'époque,\nnous considérerons _uniquement_ les DReps qui sont _soit_ dans le les meilleurs $X$ - de nombreux DReps classés par montant de mise,\nou les DReps qui ont au moins $Y$ Lovelace.\nÀ chaque époque, la valeur de $X$ _augmentera_ et la valeur de $Y$ diminuera,\nde sorte qu'à terme $X$ sera effectivement infini et $Y$ sera nul.\nNotez qu'il ne s'agit que d'une incitation et que rien n'empêche réellement un DRep d'exprimer\nson vote (même s'il ne sera pas pris en compte s'il ne répond pas aux exigences).\n\nSi la communauté décide à un moment donné qu’il y a effectivement un problème de congestion,\nalors un hard fork pourrait être adopté pour limiter le nombre de DReps de manière plus restrictive.\n\nDes chiffres raisonnables pour la valeur initiale de X$ sont probablement compris entre 5 000 et 10 000.\nLes nombres raisonnables pour la valeur initiale de $Y$ sont probablement le nombre total de Lovelace\ndivisé par la valeur initiale de $X$.\n\nLe mécanisme devrait être assoupli à un rythme où la restriction serait complètement supprimée\naprès une période de six mois à un an.\n\n## Remerciements\n\n<details>\n <summary><strong>Première ébauche</strong></summary>\n\nDe nombreuses personnes ont commenté et contribué à la première ébauche de ce document, qui a été publiée en novembre 2022.\nNous tenons particulièrement à remercier les personnes suivantes pour leur sagesse et leurs idées :\n\n * Jack Briggs\n * Tim Harrison\n * Philippe Lazos\n * Michael Madoff\n * Evangelos Markakis\n * Joël Telpner\n * Thomas Upfield\n\nNous tenons également à remercier ceux qui ont commenté via Github et d’autres canaux.\n</details>\n\n<details>\n <summary><strong>2023 Atelier du Colorado (28/02 → 01/03)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l’atelier qui s’est tenu à Longmont, Colorado, les 28 février et 1er mars 2023 pour leurs précieuses contributions\nà ce CIP, et pour leur défense active de la vision de Cardano pour une gouvernance minimale viable. Cela inclue:\n\n* Adam Rusch, ADAO & Summon\n* Addie Girouard\n* Andrew Westberg\n* Darlington Wleh, LidoNation\n* Eystein Hansen\n* James Dunseith, Gimbalabs\n* Juana Attieh\n* Kenric Nelson\n* Lloyd Duhon, DripDropz\n* Marcus Jay Allen\n* Marek Mahut, 5 binaires\n* Markus Gufler\n* Matthieu Capps\n* Miséricorde, Wada\n* Michael Dogali\n* Michael Madoff\n* Patrick Tobler, NMKR\n* Philippe Lazos\n* π Lanningham, SundaeSwap\n* Rick McCracken\n* Romain Pellerin\n* Sergio Sanchez Ferreros\n* Tim Harrison\n* Tsz Wai Wu\n</details>\n\n<details>\n  <summary><strong>2023 Mexico, Atelier du Mexique (20/05)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Mexico, au Mexique, le 20 mai 2023 pour leurs précieuses contributions\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Donovan Riaño\n* Cristian Jair Rojas\n* Victor Hernández\n* Ramón Aceves\n* Sergio Andrés Cortés\n* Isaías Alejandro Galván\n* Abigail Guzmán\n* Jorge Fernando Murguía\n* Luis Guillermo Santana\n\n</details>\n\n<details>\n  <summary><strong>2023 Buenos Aires, Atelier de l'Argentine (20/05)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Buenos Aires, Argentine le 20 mai 2023 pour leurs précieuses contributions\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Lucas Macchiavelli\n* Alejando Pestchanker\n* Juan Manuel Castro Pippo\n* Federico Weill\n* Jose Otegui\n* Mercedes Ruggeri\n* Mauro Andreoli\n* Elias Aires\n* Jorge Nasanovsky\n* Ulises Barreiro\n* Martin Ochoa\n* Facundo Lopez\n* Vanina Estrugo\n* Luca Pestchanker\n</details>\n\n<details>\n  <summary><strong>2023 Johannesburg, Atelier d'Afrique du Sud(25/05)</strong></summary>\n\nEn outre, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Johannesburg, en Afrique du Sud, le 25 mai 2023, pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Celiwe Ngwenya\n* Bernard Sibanda\n* Dumo Mbobo\n* Shaolyn Dzwedere\n* Kunoshe Muchemwa\n* Siphiwe Mbobo\n* Lucas Sibindi\n* DayTapoya\n* Mdu Ngwenya\n* Lucky Khumalo\n* Skhangele Malinga\n* Joyce Ncube\n* Costa Katenhe\n* Bramwell Kasanga\n* Precious Abimbola\n* Ethel Q Tshuma\n* Panashe Sibanda\n* Radebe Tefo\n* Kaelo Lentsoe\n* Richmond Oppong\n* Israel Ncube\n* Sikhangele Malinga\n* Nana Safo\n* Ndaba Delsie\n* Collen Tshepang\n* Dzvedere Shaolyn\n* Thandazile Sibanda\n* Ncube Joyce\n* Lucas Sibindi\n* Pinky Ferro\n* Ishmael Ntuta\n* Khumalo Lucky\n* Fhulufelo\n* Thwasile Ngwenya\n* Kunashe Muchemwa\n* Dube Bekezela\n* Tinyiko Baloi\n* Dada Nomathemba\n</details>\n\n\n<details>\n  <summary><strong>2023 Bogota, Atelier de Colombie (27/05)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Bogota, en Colombie, le 27 mai 2023 pour leurs précieuses contributions\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Alvaro Moncada\n* Jaime Andres Posada Castro\n* Jose Miguel De Gamboa\n* Nicolas Gomez\n* Luis Restrepo (Moxie)\n* Juanita Jaramillo R.\n* Daniel Vanegas\n* Ernesto Rafael Pabon Moreno\n* Carlos Eduardo Escobar\n* Manuel Fernando Briceño\n* Sebastian Pabon\n</details>\n\n<details>\n  <summary><strong>2023 Caracas, Atelier du Venezuela (27/05)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Caracas, Venezuela le 27 mai 2023 pour leurs précieuses contributions\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Jean Carlo Aguilar\n* Wilmer Varón\n* José Erasmo Colmenares\n* David Jaén\n* Félix Dávila\n* Yaneth Duarte\n* Nando Vitti\n* Wilmer Rojas\n* Andreina García\n* Carmen Galban\n* Osmarlina Agüero\n* Ender Linares\n* Carlos A. Palacios R\n* Dewar Rodríguez\n* Lennys Blanco\n* Francys García\n* Davidson Arenas\n</details>\n\n<details>\n  <summary><strong>2023 Manizales, Atelier de Colombie (27/05)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Manizales, en Colombie, le 27 mai 2023 pour leurs précieuses contributions\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Yaris Cruz\n* Yaneth Duarte\n* Ciro Gelvez\n* Kevin Chacon\n* Juan Sierra\n* Caue Chianca\n* Sonia Malagon\n* Facundo Ramirez\n* Hope R.\n</details>\n\n<details>\n  <summary><strong>2023 Addis-Abeba, Atelier d'Éthiopie (27/05 & 28/5)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Addis-Abeba, en Éthiopie, les 27 et 28 mai 2023 pour leurs précieuses contributions.\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Kaleb Dori\n* Eyassu Birru\n* Matthew Thornton\n* Tamir Kifle\n* Kirubel Tabu\n* Bisrat Miherete\n* Emmanuel Khatchadourian\n* Tinsae Teka\n* Yoseph Ephrem\n* Yonas Eshetu\n* Hanna Kaleab\n* Tinsae Teka\n* Robee Meseret\n* Matias Tekeste\n* Eyasu Birhanu\n* yonatan berihun\n* Nasrallah Hassan\n* Andinet Assefa\n* Tewodros Sintayehu\n* KIDUS MENGISTEAB\n* Djibril Konate\n* Nahom Mekonnen\n* Eyasu Birhanu\n* Eyob Aschenaki\n* Tinsae Demissie\n* Yeabsira Tsegaye\n* Tihitna Miroche\n* Mearaf Tadewos\n* Yab Mitiku\n* Habtamu Asefa\n* Dawit Mengistu\n* Nebiyu Barsula\n* Nebiyu Sultan\n* Nathan Samson\n</details>\n\n<details>\n  <summary><strong>2023 Kyoto et Fukuoka, Atelier du Japon (27/05 & 10/06 )</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Kyoto et à Fukuoka, au Japon, les 27 mai et 10 juin 2023 pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Arimura\n* Hidemi\n* Nagamaru(SASApool)\n* shiodome47(SODMpool)\n* Wakuda(AID1pool)\n* Yuta(Yuki Oishi)\n* Andrew\n* BANCpool\n* Miyatake\n* Muen\n* Riekousagi\n* SMAN8(SA8pool)\n* Tatsuya\n* カッシー\n* 松\n* ポンタ\n* リサ\n* Mako\n* Ririco\n* ながまる\n* Baku\n* マリア\n* たりふん\n* JUNO\n* Kinoko\n* Chikara\n* ET\n* Akira555\n* Kent\n* Ppp\n* Shiodome47\n* Sam\n* ポール\n* Concon\n* Sogame\n* ハンド\n* Demi\n* Nonnon\n* banC\n* SMAN8(SA8pool)\n* りんむ\n* Kensin\n* りえこうさぎ\n* アダマンタイト\n* の/ゆすけ\n* MUEN\n* いちごだいふく\n* Ranket\n* A.yy\n* N S\n* Kazuya\n* Daikon\n</details>\n\n<details>\n  <summary><strong>2023 Monterey, Atelier de Californie (28/05)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Monterey, en Californie, le 28 mai 2023, pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Shane Powser\n* Rodrigo Gomez\n* Adam K. Dean\n* John C. Valdez\n* Kyle Solomon\n* Erick \"Mag\" Magnana\n* Bryant Austin\n* John Huthmaker\n* Ayori Selassie\n* Josh Noriega\n* Matthias Sieber\n</details>\n\n<details>\n  <summary><strong>2023 Tlaxcala, Atelier du Mexique (01/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Tlaxcala, au Mexique, le 1er juin 2023, pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Victor Hernández\n* Cristian Jair Rojas\n* Miriam Mejia\n* Josmar Cabañas\n* Lizbet Delgado\n* José Alberto Sánchez\n* Fátima Valeria Zamora\n* Julio César Montiel\n* Jesús Pérez\n* José Adrián López\n* Lizbeth Calderón\n* Zayra Molina\n* Nayelhi Pérez\n* Josué Armas\n* Diego Talavera\n* Darían Gutiérrez\n</details>\n\n<details>\n  <summary><strong>2023 Atelier virtuel LATAM (03/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier virtuel LATAM le 3 juin 2023 pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Juan Sierra\n* @CaueChianca\n* Ernesto Rafael\n* Pabon Moreno\n* Sonia Malagon\n* Facundo Ramírez\n* Mercedes Ruggeri\n* Hope R.\n* Yaris Cruz\n* Yaneth Duarte\n* Ciro Gélvez\n* Kevin Chacon\n* Juanita Jaramillo\n* Sebastian Pabon\n</details>\n\n<details>\n  <summary><strong>2023 Worcester, Atelier du Massachusetts (08/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Worcester, Massachusetts le 8 juin 2023 pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* CardanoSharp\n* Kenric Nelson\n* Matthias Sieber\n* Roberto Mayen\n* Ian Burzynski\n* omdesign\n* Chris Gianelloni\n</details>\n\n<details>\n  <summary><strong>2023 Chicago, Atelier d'Illinois (10/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Chicago, Illinois le 10 juin 2023 pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Adam Rusch\n* Jose Martinez\n* Michael McNulty\n* Vanessa Villanueva Collao\n* Maaz Jedh\n</details>\n\n<details>\n  <summary><strong>2023 Atelier virtuel (12/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu virtuellement le 12 juin 2023 pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Rojo Kaboti\n* Tommy Frey\n* Tevo Saks\n* Slate\n* UBIO OBU\n</details>\n\n<details>\n  <summary><strong>2023 Toronto, Atelier du Canada (15/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Toronto, au Canada, le 15 juin 2023, pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* John MacPherson\n* Lawrence Ley\n</details>\n\n<details>\n  <summary><strong>2023 Philadelphie, Atelier de Pennsylvanie (17/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Philadelphie, en Pennsylvanie, le 17 juin 2023, pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* NOODZ\n* Jarhead\n* Jenny Brito\n* Shepard\n* BONE Pool\n* type_biggie\n* FLAWWD\n* A.I. Scholars\n* Eddie\n* Joker\n* Lex\n* Jerome\n* Joey\n* SwayZ\n* Cara Mia\n* PHILLY 1694\n</details>\n\n<details>\n  <summary><strong>2023 Atelier de Santiago du Chili (17/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Santiago du Chili le 17 juin 2023 pour leurs précieuses contributions\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Rodrigo Oyarsun\n* Sebastián Aravena\n* Musashi Fujio\n* Geo Gavo\n* Lucía Escobar\n* Juan Cruz Franco\n* Natalia Rosa\n* Cristian M. García\n* Alejandro Montalvo\n</details>\n\n<details>\n  <summary><strong>2023 Atelier virtuel (17/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu virtuellement le 17 juin 2023 pour leurs précieuses contributions\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Juana Attieh\n* Nadim Karam\n* Amir Azem\n* Rami Hanania\n* LALUL Stake Pool\n* HAWAK Stake Pool\n</details>\n\n<details>\n  <summary><strong>2023 Taipai, Atelier de Taïwan (18/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Taipai, Taiwan le 18 juin 2023 pour leurs précieuses contributions\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Michael Rogero\n* Ted Chen\n* Mic\n* Jeremy Firster \n* Eric Tsai\n* Dylan Chiang\n* JohnsonCai\n* DavidCHIEN\n* Zach Gu\n* Jimmy WANG\n* JackTsai\n* Katherine Hung\n* Will Huang\n* Kwicil\n</details>\n\n<details>\n  <summary><strong>2023 Midgard Vikingcenter Horten, Atelier de Norvège (19/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Midgard Vikingcenter Horten, en Norvège, le 19 juin 2023 pour leurs précieuses contributions.\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Daniel D. Johnsen\n* Thomas Lindseth\n* Eystein Hansen\n* Gudbrand Tokerud \n* Lally McClay\n* $trym\n* Arne Rasmussen\n* Lise WesselTVVIN\n* Bjarne \n* Jostein Aanderaa\n* Ken-Erik Ølmheim\n* DimSum\n</details>\n\n<details>\n  <summary><strong>2023 Atelier Virtuel (19/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu virtuellement le 19 juin 2023 pour leurs précieuses contributions\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Nicolas Cerny\n* Nils Peuser\n* Riley Kilgore\n* Alejandro Almanza\n* Jenny Brito\n* John C. Valdez\n* Rhys\n* Thyme\n* Adam Rusch\n* Devryn\n</details>\n\n<details>\n  <summary><strong>2023 New York, Atelier de New York (20/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu dans la ville de New York, le 20 juin 2023 pour leurs précieuses contributions\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* John Shearing\n* Geoff Shearing\n* Daniela Balaniuc\n* SDuffy\n* Garry Golden\n* Newman\n* Emmanuel Batse\n* Ebae\n* Mojira\n</details>\n\n<details>\n  <summary><strong>2023 La Cumbre, Atelier d'Argentine (23/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à La Cumbre, Argentine le 23 juin 2023 pour leurs précieuses contributions\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Ulises Barreiro\n* Daniel F. Rodriguez\n* Dominique Gromez\n* Leandro Chialvo\n* Claudia Vogel\n* Guillermo Lucero\n* Funes, Brian Carrasco\n* Melisa Carrasco\n* Carlos Carrasco\n</details>\n\n<details>\n  <summary><strong>2023 Minneapolis, Atelier du Minnesota (23/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Minneapolis, Minnesota le 23 juin 2023 pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Stephanie King\n* Darlington Wleh\n</details>\n\n<details>\n  <summary><strong>2023 La Plata, Atelier d'Argentine (23/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à La Plata, Argentine le 23 juin 2023 pour leurs précieuses contributions\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Mauro Andreoli\n* Rodolfo Miranda\n* Agustin Francella\n* Federico Sting\n* Elias Aires\n* Lucas Macchiavelli\n* Pablo Hernán Mazzitelli\n</details>\n\n<details>\n  <summary><strong>2023 Puerto Madryn, Atelier d'Argentine (23/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Puerto Madryn, en Argentine, le 23 juin 2023, pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Andres Torres Borda\n* Federico Ledesma Calatayud\n* Maximiliano Torres\n* Federico Prado\n* Domingo Torres\n* Floriana Pérez Barria\n* Martin Real\n* Florencia García\n* Roberto Neme\n</details>\n\n<details>\n  <summary><strong>2023 Accra,  Atelier du Ghana (24/06)</strong></summary>\n\nEn outre, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Accra, au Ghana, le 24 juin 2023, pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Wada\n* Laurentine\n* Christopher A.\n* Nathaniel D.\n* Edufua\n* Michael\n* Augusta\n* Jeremiah\n* Boaz\n* Mohammed\n* Richmond O.\n* Ezekiel\n* Megan\n* Josue\n* Michel T.\n* Bineta\n* Afia O.\n* Mercy\n* Enoch\n* Kofi\n* Awura\n* Emelia\n* Richmond S.\n* Solomon\n* Phillip\n* Faakor\n* Manfo\n* Josh\n* Daniel\n* Mermose\n</details>\n\n<details>\n  <summary><strong>2023 Atelier Virtuel (24/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu virtuellement le 24 juin 2023 pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Jonas Riise\n* Thomas Lindseth\n* André \"Eilert\" Eilertsen\n* Eystein Hansen\n</details>\n\n<details>\n  <summary><strong>2023 Séoul, Atelier de la Corée du Sud (24/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Séoul, en Corée du Sud, le 24 juin 2023, pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Oscar Hong (JUNGI HONG)\n* SPO_COOL (Kevin Kordano)\n* SPO_KTOP (KT OH)\n* WANG JAE LEE\n* JAE HYUN AN\n* INYOUNG MOON (Penny)\n* HOJIN JEON\n* SEUNG KYU BAEK\n* SA SEONG MAENG\n* JUNG MYEONG HAN\n* BRIAN KIM\n* JUNG HOON KIM\n* SEUNG WOOK JUNG (Peter)\n* HYUNG WOO PARK\n* EUN JAE CHOI\n* NA GYEONG KIM\n* JADEN CHOI\n</details>\n\n<details>\n  <summary><strong>2023 Abu Dhabi, UAE Workshop (25/06)</strong></summary>\n\nEn outre, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Abu Dhabi, Émirats arabes unis le 25 juin 2023 pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Amir Azem\n* Ian Arden\n* Madina Abdibayeva\n* BTBF (Yu Kagaya)\n* محمد الظاهري\n* Tegegne Tefera\n* Rami Hanania\n* Tania Debs\n* Khalil Jad\n* Mohamed Jamal\n* Ruslan Yakubov\n* OUSHEK Mohamed eisa\n* Shehryar\n* Wael Ben Younes\n* Santosh Ray\n* Juana Attieh\n* Nadim Karam\n* DubaistakePool\n* HAWAK Pool\n* LALKUL Stake Pools\n</details>\n\n<details>\n  <summary><strong>2023 Williamsburg, Atelier de New York (25/06)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Williamsburg, New York le 25 juin 2023 pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Pi\n* Joseph\n* Skyler\n* Forrest\n* Gabriel\n* Newman\n</details>\n\n<details>\n  <summary><strong>2023 Lagos, Atelier de Nigéria (28/06)</strong></summary>\n\nEn outre, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Lagos, au Nigeria, le 28 juin 2023, pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Jonah Benson\n* Augusta\n* Ubio Obu\n* Olumide Hrosuosegbe\n* Veralyn Chinenye\n* Ona Ohimer\n* William Ese\n* Ruth Usoro\n* William P\n* Esther Simi\n* Daniel Effiom\n* Akinkurai Toluwalase\n</details>\n\n<details>\n  <summary><strong>2023 Sao Paulo, Atelier du Brésil (01/07)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu à Sao Paulo, au Brésil, le 1er juillet 2023, pour leurs précieuses contributions à ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Otávio Lima\n* Rodrigo Pacini\n* Maria Carmo\n* Cauê Chianca\n* Daniela Alves\n* Jose Lins Dias\n* Felipe Barcelos\n* Rosana Melo\n* Johnny Oliveira\n* Lucas Ravacci\n* Cristofer Ramos\n* Weslei Menck\n* Leandro Tsutsumi\n* Izaias Pessoa\n* Gabriel Melo\n* Yuri Nabeshima\n* Alexandre Fernandes\n* Vinicius Ferreiro\n* Lucas Fernandes\n* Alessandro Benicio\n* Mario Cielho\n* Lory Fernandes Lima\n* Larissa Nogueira\n* Latam Cardano Community\n</details>\n\n<details>\n  <summary><strong>2023 Atelier virtuel du Brésil (04/07)</strong></summary>\n\nDe plus, nous tenons à remercier tous les participants à l'atelier qui s'est tenu au Brésil le 4 juillet 2023 pour leurs précieuses contributions\nà ce CIP et pour s'être fait champion actif de la vision de Cardano pour une gouvernance minimale viable. Ceux-ci inclus:\n\n* Lincon Vidal\n* Thiago da Silva Nunes\n* Rodrigo Pacini\n* Livia Corcino de Albuquerque\n* Cauê Chianca\n* Otávio Lima\n</details>\n\n## Droit d’auteur\n\nCe CIP est sous licence [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n\n[^1]: Une description formelle des règles actuelles pour les actions de gouvernance est donnée dans la [spécification du registre Shelley](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/shelley-ledger.pdf).\n\n    - Pour les modifications des paramètres de protocole (y compris les hard forks), la règle de transition `PPUP` (Figure 13) décrit comment les mises à jour des paramètres de protocole sont traitées, et la règle de transition `NEWPP` (Figure 43) décrit comment les modifications apportées aux paramètres de protocole sont mises en œuvre.\n\n    - Pour les transferts de fonds, la règle de transition `DELEG` (figure 24) décrit la manière dont les certificats MIR sont traités, et la règle de transition `MIR` (figure 55) décrit comment les mouvements de trésorerie et de réserves sont promulgués.\n\n    > **Note**\n    > Les capacités de la règle de transition `MIR` ont été étendues dans la [spécification du registre Alonzo](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/alonzo-ledger.pdf)\n\n\n[^2]: Il existe de nombreuses définitions différentes du terme « hard fork » dans l’industrie de la blockchain. Les hard forks font généralement référence à des mises à jour non rétrocompatibles d’un réseau. Dans Cardano, nous formalisons un peu plus la définition en appelant toute mise à niveau qui conduirait à la validation de _more blocks_ un « hard fork » et forçons les noeuds à se conformer à la nouvelle version du protocole, obsolant ainsi les noeuds incapables de gérer la mise à niveau.\n\n[^3]: Il s’agit de la définition utilisée dans « participation active » pour la délégation de participation aux pools de participations, voir Section 17.1, Calcul de la mise totale, de la [spécification du grand livre Shelley](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/shelley-ledger.pdf).\n"
  },
  {
    "path": "CIP-1694/README.md",
    "content": "---\nCIP: 1694\nTitle: A First Step Towards On-Chain Decentralized Governance\nStatus: Active\nCategory: Ledger\nAuthors:\n    - Jared Corduan <jared.corduan@iohk.io>\n    - Andre Knispel <andre.knispel@iohk.io>\n    - Matthias Benkort <matthias.benkort@cardanofoundation.org>\n    - Kevin Hammond <kevin.hammond@iohk.io>\n    - Charles Hoskinson <charles.hoskinson@iohk.io>\n    - Samuel Leathers <samuel.leathers@iohk.io>\nDiscussions:\n    - <https://github.com/cardano-foundation/CIPs/pull/380>\n    - <https://forum.cardano.org/t/swarm-session-cip-1694/114453>\n    - <https://twitter.com/IOHK_Charles/status/1632211417221701632>\n    - <https://twitter.com/RichardMcCrackn/status/1632514347195850752>\n    - <https://twitter.com/RichardMcCrackn/status/1633135124500865024>\n    - <https://twitter.com/_KtorZ_/status/1632356766368382976>\n    - <https://twitter.com/_KtorZ_/status/1630087586193584128>\n    - <https://twitter.com/_KtorZ_/status/1631430933219012608>\n    - <https://twitter.com/technologypoet/status/1632158736985866241>\n    - <https://twitter.com/danny_cryptofay/status/1631606919071776768>\n    - <https://www.youtube.com/watch?v=2hCnmMG1__8>\n    - <https://www.youtube.com/watch?v=KiLhhOVXQOg>\n    - <https://github.com/cardano-foundation/CIPs/pull/916>\nCreated: 2022-11-18\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nWe propose a revision of Cardano's on-chain governance system to support the new requirements for Voltaire.\nThe existing specialized governance support for protocol parameter updates and MIR certificates will be removed,\nand two new fields will be added to normal transaction bodies for:\n\n1. governance actions\n2. votes\n\n**Any Cardano user** will be allowed to submit a **governance action**.\nWe also introduce three distinct governance bodies that have specific functions in this new governance framework:\n\n1. a constitutional committee\n2. a group of delegated representatives (henceforth called **DReps**)\n3. the stake pool operators (henceforth called **SPOs**)\n\nEvery governance action must be ratified by at least two of these three governance bodies using their on-chain **votes**.\nThe type of action and the state of the governance system determines which bodies must ratify it.\n\nRatified actions are then **enacted** on-chain, following a set of well-defined rules.\n\nAs with stake pools, any Ada holder may register to be a DRep and so choose to\nrepresent themselves and/or others.  Also, as with stake pools, Ada holders may, instead, delegate their voting\nrights to any other DRep.\nVoting rights will be based on the total Ada that is delegated, as a whole number of Lovelace.\n\nThe most crucial aspect of this proposal is therefore the notion of **\"one Lovelace = one vote\"**.\n\nFor the many contributors to this proposal, see [Acknowledgements](#acknowledgements).\n## Motivation: why is this CIP necessary?\n\n+ [Goal](#goal)\n+ [Current design](#current-governance-mechanism-design)\n+ [Shortcomings of the Shelley governance design](#shortcomings-of-the-shelley-governance-design)\n+ [Out of scope](#out-of-scope)\n\n### Goal\n\nWe're heading into the age of Voltaire, laying down the foundations for decentralized decision-making.\nThis CIP describes a mechanism for on-chain governance that will underpin the Voltaire phase of Cardano.\nThe CIP builds on and extends the original Cardano governance scheme that was based on a fixed number of governance keys.\nIt aims to provide a **first step** that is both valuable and, importantly, is also technically achievable\nin the **near term** as part of the proposed Voltaire governance system.\n\nIt also seeks to act as a jumping-off point for continuing community input,\nincluding on appropriate threshold settings and other on-chain settings.\n\nSubsequent proposals may adapt and extend this proposal to meet emerging governance needs.\n\n### Current governance mechanism design\n\nThe on-chain Cardano governance mechanism that was introduced in the Shelley ledger era is capable of:\n\n1. modifying the values of the protocol parameters (including initiating \"hard forks\")\n2. transferring Ada out of the reserves and the treasury (and also moving Ada between the reserves and the treasury)\n\nIn the current scheme, governance actions are initiated by special transactions that require `Quorum-Many` authorizations\nfrom the governance keys (5 out of 7 on the Cardano mainnet)[^1].\nFields in the transaction body provide details of the proposed governance action:\neither i) protocol parameter changes; or ii) initiating funds transfers.\nEach transaction can trigger both kinds of governance actions, and a single action can have more than one effect (e.g. changing two or more protocol parameters).\n\n- Protocol parameter updates use [transaction field nº6](https://github.com/input-output-hk/cardano-ledger/blob/8884d921c8c3c6e216a659fca46caf729282058b/eras/babbage/test-suite/cddl-files/babbage.cddl#L56) of the transaction body.\n- Movements of the treasury and the reserves use [Move Instantaneous Rewards (abbrev. MIR) certificates](https://github.com/input-output-hk/cardano-ledger/blob/8884d921c8c3c6e216a659fca46caf729282058b/eras/babbage/test-suite/cddl-files/babbage.cddl#L180).\n\nProperly authorized governance actions are applied on an epoch boundary (they are **enacted**).\n\n#### Hard Forks\n\nOne of the protocol parameters is sufficiently significant to merit special attention:\nchanging the major protocol version enables Cardano to enact controlled hard forks.\nThis type of protocol parameter update therefore has a special status, since stake pools\nmust upgrade their nodes so they can support the new protocol version once the hard fork is enacted.\n\n### Shortcomings of the Shelley governance design\n\nThe Shelley governance design was intended to provide a simple, transitional approach to governance.\nThis proposal aims to address a number of shortcomings with that design\nthat are apparent as we move into Voltaire.\n\n1. The Shelley governance design gives no room for active on-chain participation of Ada holders.\nWhile changes to the protocol are usually the results of discussions with selected community actors,\nthe process is currently driven mainly by the founding entities.\nEnsuring that everyone can voice their concern is cumbersome, and can be perceived as arbitrary at times.\n\n2. Movements from the treasury constitute a critical and sensitive topic.\nHowever, they can be hard to track.  It is important to have more transparency\nand more layers of control over these movements.\n\n3. While they need to be treated specially by SPOs, hard forks are not differentiated from other protocol parameter changes.\n\n4. Finally, while there is currently a somewhat common vision for _Cardano_ that is shared by its founding entities and also by many community members,\nthere is no clearly defined document where these guiding principles are recorded.\nIt makes sense to leverage the Cardano blockchain to record the shared Cardano ethos in an immutable fashion, as a formal Cardano Constitution.\n\n### Out of scope\n\nThe following topics are considered to be out of the scope of this CIP.\n\n#### The contents of the constitution\n\nThis CIP focuses only on on-chain mechanisms.  The provisions of the initial constitution are extremely important, as are any processes that\nwill allow it to be amended.  These merit their own separate and focused discussion.\n\n#### The membership of the constitutional committee\n\nThis is an off-chain issue.\n\n#### Legal issues\n\nAny potential legal enforcement of either the Cardano protocol or the Cardano Constitution are completely out of scope for this CIP.\n\n\n#### Off chain standards for governance actions\n\nThe Cardano community must think deeply about the correct standards and processes for handling the creation of the governance actions that are specified in this CIP.\nIn particular, the role of Project Catalyst in creating treasury withdrawal actions is completely outside the scope of this CIP.\n\n\n#### Ada holdings and delegation\n\nHow any private companies, public or private institutions,  individuals etc. choose to hold or delegate their Ada, including delegation to stake pools or DReps, is outside the scope of this CIP.\n\n## Specification\n\n+ [The Cardano Constitution](#the-cardano-constitution)\n+ [The constitutional committee](#the-constitutional-committee)\n  - [State of no-confidence](#state-of-no-confidence)\n  - [Constitutional committee keys](#constitutional-committee-keys)\n  - [Replacing the constitutional committee](#replacing-the-constitutional-committee)\n  - [Size of the constitutional committee](#size-of-the-constitutional-committee)\n  - [Terms](#terms)\n  - [Guardrails Script](#guardrails-script)\n+ [Delegated representatives (DReps)](#delegated-representatives-dreps)\n  - [Pre-defined Voting Options](#pre-defined-voting-options)\n  - [Registered DReps](#registered-dreps)\n  - [New stake distribution for DReps](#new-stake-distribution-for-dreps)\n  - [Incentives for Ada holders to delegate voting stake](#incentives-for-ada-holders-to-delegate-voting-stake)\n  - [DRep incentives](#drep-incentives)\n+ [Governance actions](#governance-actions)\n  - [Ratification](#ratification)\n    * [Requirements](#requirements)\n    * [Restrictions](#restrictions)\n  - [Enactment](#enactment)\n  - [Lifecycle](#lifecycle)\n  - [Content](#content)\n  - [Protocol parameter groups](#protocol-parameter-groups)\n+ [Votes](#votes)\n  - [Governance state](#governance-state)\n  - [Changes to the stake snapshot](#changes-to-the-stake-snapshot)\n  - [Definitions relating to voting stake](#definitions-relating-to-voting-stake)\n\n### The Cardano Constitution\n\nThe Cardano Constitution is a text document that defines Cardano's shared values and guiding principles.\nAt this stage, the Constitution is an informational document that unambiguously captures the core values of Cardano\nand acts to ensure its long-term sustainability.\nAt a later stage, we can imagine the Constitution perhaps evolving into a smart-contract based set of rules that drives the entire governance framework.\nFor now, however, the Constitution will remain an off-chain document whose hash digest value will be recorded on-chain.\nAs discussed above, the Constitution is not yet defined and its content is out of scope for this CIP.\n\n<!--------------------------- Constitutional committee ------------------------>\n\n### The constitutional committee\n\nWe define a _constitutional committee_ which represents a set of individuals or entities\n(each associated with a Ed25519 or native or Plutus script credential) that are collectively responsible for **ensuring that the Constitution is respected**.\n\nThough it **cannot be enforced on-chain**, the constitutional committee is **only** supposed to vote\non the constitutionality of governance actions (which should thus ensure the long-term sustainability of the blockchain) and should be replaced\n(via the **no confidence** action) if they overstep this boundary.\nSaid differently, there is a social contract between the constitutional committee and the actors of the network.\nAlthough the constitutional committee could reject certain governance actions (by voting 'No' on them),\nthey should only do so when those governance actions are in conflict with the Constitution.\n\nFor example, if we consider the hypothetical Constitution rule \"The Cardano network must always be able to produce new blocks\",\nthen a governance action that would reduce the maximum block size to `0` would be, in effect,\nunconstitutional and so might not be ratified by the constitutional committee.  The rule does\nnot, however, specify the smallest acceptable maximum block size, so the constitutional committee would need to determine this number\nand vote accordingly.\n\n#### State of no-confidence\n\nThe constitutional committee is considered to be in one of the following two states at all times:\n\n1. a normal state (i.e. a state of confidence)\n2. a state of no-confidence\n\nIn a _state of no-confidence_, the current committee is no longer able to participate in governance actions\nand must be replaced before any governance actions can be ratified (see below).\n\n#### Constitutional committee keys\n\nThe constitutional committee will use a hot and cold key setup, similar to the existing \"genesis delegation certificate\" mechanism.\n\n#### Replacing the constitutional committee\n\nThe constitutional committee can be replaced via a specific governance action\n(\"Update committee\", described below) that requires the approval of both\nthe **SPOs** and the **DReps**.\nThe threshold for ratification might be different depending on if the governance is\nin a normal state or a state of no confidence.\n\nThe new constitutional committee could, in principle, be identical to or partially overlap the outgoing committee as long as the action is properly ratified.\nThis might happen, for example, if the electorate has collective confidence in all or part of the committee and wishes to extend its term of office.\n\n\n#### Size of the constitutional committee\n\nUnlike the Shelley governance design, the size of the constitutional committee is not fixed and can be any nonnegative number.\nIt may be changed whenever a new committee is elected (\"Update committee\").\nLikewise, the committee threshold (the fraction of committee `Yes` votes that are required to ratify governance actions) is not fixed and\ncan also be varied by the governance action.\nThis gives a great deal of flexibility to the composition of the committee.\nIn particular, it is possible to elect an empty committee if the community wishes to abolish the constitutional committee entirely. Note that this is different from a state of no-confidence and still constitutes a governance system capable of enacting proposals.\n\nThere will be a new protocol parameter for the minimal size of the committee,\nitself a nonnegative number called `committeeMinSize`.\n\n#### Terms\n\nEach newly elected constitutional committee will have a term.\nPer-member terms allow for a rotation scheme, such as a third of the committee\nexpiring every year.\nExpired members can no longer vote.\nMember can also willingly resign early, which will be marked on-chain as an expired member.\n\nIf the number of non-expired committee members falls below the minimal\nsize of the committee, the constitutional committee will be unable to\nratify governance actions. This means that only governance actions\nthat don't require votes from the constitutional committee can still\nbe ratified.\n\nFor example, a committee of size five with a threshold of 60% a minimum size\nof three and two expired members can still\npass governance actions if two non-expired members vote `Yes`.\nHowever, if one more member expires then the constitutional committee becomes\nunable to ratify any more governance actions.\n\nThe maximum term is a governance protocol parameter, specified as a number of epochs.\nDuring a state of no-confidence, no action can be ratified,\nso the committee should plan for its own replacement if it wishes to avoid disruption.\n\n#### Guardrails Script\n\nWhile the constitution is an informal, off-chain document, there will\nalso be an optional script that can enforce some guidelines. This script\nacts to supplement the constitutional committee by restricting some\nproposal types. For example, if the community wishes to have some hard\nrules for the treasury that cannot be violated, a script that enforces\nthese rules can be voted in as the guardrails script.\n\nThe guardrails script applies only to protocol parameter update and\ntreasury withdrawal proposals.\n\n<!---------------------------           DReps          ------------------------>\n\n### Delegated representatives (DReps)\n\n> **Warning**\n> CIP-1694 DReps **should not be conflated** with Project Catalyst DReps.\n\n#### Pre-defined Voting Options\n\nIn order to participate in governance, a stake credential must be delegated to a DRep.\nAda holders will generally delegate their voting rights to a registered DRep\nthat will vote on their behalf. In addition, two pre-defined voting options are available:\n\n* `Abstain`\n\n  If an Ada holder delegates to `Abstain`, then their stake is actively marked\n  as not participating in governance.\n\n  The effect of delegating to `Abstain` on chain is that the delegated stake *will not* be considered to be\n  a part of the active voting stake.  However, the stake *will* be considered to be registered for the\n  purpose of the incentives that are described in [Incentives for Ada holders to delegate voting stake](#incentives-for-ada-holders-to-delegate-voting-stake).\n\n* `No Confidence`\n\n  If an Ada holder delegates to `No Confidence`, then their stake is counted\n  as a `Yes` vote on every `No Confidence` action and a `No` vote on every other action.\n  The delegated stake *will* be considered part of the active voting stake.\n  It also serves as a directly auditable measure of the confidence of Ada holders in the constitutional\n  committee.\n\n\n> **Note**\n> The pre-defined voting options do not cast votes inside of transactions, their behavior is accounted for at the protocol level.\n> The `Abstain` option may be chosen for a variety of reasons, including the desire to not\n> participate in the governance system.\n\n> **Note**\n> Any Ada holder may register themselves as a DRep and delegate to themselves if they wish to actively participate in\n> voting.\n\n> **Note**\n> Any wallet serving as the Registered Reward Wallet for a Stake Pool can be delegated to one of these Pre-defined Voting Options and doing so will serve as the default voting option selected by the SPO for all Governance Action votes, excepting Hard Fork Governance Actions. Due to the need for robust consensus around Hard Fork initiations, these votes must be met as a percentage of the stake held by all stake pools. \n\n#### Registered DReps\n\nIn Voltaire, existing stake credentials will be\nable to delegate their stake to DReps for voting purposes,\nin addition to the current delegation to stake pools for block production.\nDRep delegation will mimic the existing stake delegation mechanisms (via on-chain certificates).\nSimilarly, DRep registration will mimic the existing stake registration mechanisms.\nAdditionally, registered DReps will need to vote regularly to still be considered active.\nSpecifically, if a DRep does not submit any votes for `drepActivity`-many epochs, the DRep is considered inactive,\nwhere `drepActivity` is a new protocol parameter.\nInactive DReps do not count towards the active voting stake anymore, and can become active again for\n`drepActivity`-many epochs by voting on any governance actions or submitting a DRep update certificate.\nThe reason for marking DReps as inactive is so that DReps who stop participating but still have\nstake delegated to them do not eventually leave the system in a state where no governance\naction can pass.\n\nRegistered DReps are identified by a credential that can be either:\n\n* A verification key (Ed25519)\n* A native or Plutus script\n\nThe blake2b-224 hash digest of a serialized DRep credential is called the _DRep ID_.\n\nThe following new types of certificates will be added for DReps:\nDRep registration certificates, DRep retirement certificates, and\nvote delegation certificates.\n\n##### DRep registration certificates\n\nDRep registration certificates include:\n\n* a DRep ID\n* a deposit\n* an optional anchor\n\nAn **anchor** is a pair of:\n\n* a URL to a JSON payload of metadata\n* a hash of the contents of the metadata URL\n\nThe structure and format of this metadata is deliberately left open in this CIP.\nThe on-chain rules will not check either the URL or the hash.\nClient applications should, however, perform the usual sanity checks when fetching content from the provided URL.\n\n\n##### DRep retirement certificates\n\nDRep retirement certificates include:\n\n* a DRep ID\n\nNote that a DRep is retired immediately upon the chain accepting a retirement certificate,\nand the deposit is returned as part of the transaction that submits the retirement certificate\n(the same way that stake credential registration deposits are returned).\n\n##### Vote delegation certificates\n\nVote delegation certificates include:\n\n* the DRep ID to which the stake should be delegated\n* the stake credential for the delegator\n\n> **Note**\n>\n> DRep delegation always maps a stake credential to a DRep credential.\n> This means that a DRep cannot delegate voting stake to another DRep.\n\n##### Certificate authorization schemes\n\nThe authorization scheme (i.e. which signatures are required for registration, retirement or delegation) mimics the existing stake delegation certificate authorization scheme.\n\n<!-- TODO: Provide CBOR specification in the annexe for those new certificates. -->\n\n\n#### New stake distribution for DReps\n\nIn addition to the existing per-stake-credential distribution and the\nper-stake-pool distribution, the ledger will now also determine the per-DRep stake\ndistribution. This distribution will determine how much stake each vote from a DRep\nis backed by.\n\n> **Warning**\n>\n> **Unlike** the distribution that is used for block production, we will always use the most\n> current version of the per-DRep stake distribution as given on the epoch boundary.\n>\n> This means that **for any topic which individual voters care deeply about,\n> they have time to delegate to themselves as a DRep and vote directly**.\n> However, it means that there may be a difference between the stake that is used for block\n> production and the stake that is used for voting in any given epoch.\n\n\n#### Incentives for Ada holders to delegate voting stake\n\nThere will be a short [bootstrapping phase](#bootstrapping-phase) during which rewards will be earned\nfor stake delegation etc. and may be withdrawn at any time.\nAfter this phase, although rewards will continue to be earned for block delegation etc., reward accounts will be\n**blocked from withdrawing any rewards** unless their associated stake credential is also delegated to a DRep or pre-defined voting option.\nThis helps to ensure high participation, and so, legitimacy.\n\n> **Note**\n>\n> Even though rewards cannot be withdrawn, they are not lost.  As soon as a stake credential is delegated\n> (including to a pre-defined voting option), the rewards can be withdrawn.\n\n#### DRep incentives\n\nDReps arguably need to be compensated for their work. Research on incentive models is still ongoing,\nand we do not wish to hold up implementation of this CIP while this is resolved.\n\nOur interim proposal is therefore to escrow Lovelace from the existing Cardano treasury until this\nextremely important decision can be agreed on by the community, through the on-chain governance\nmechanism that is being constructed.\n\nAlternatively, DReps could pay themselves through instances of the \"Treasury withdrawal\" governance action.\nSuch an action would be auditable on-chain, and should reflect an off-chain agreement between DReps and delegators.\n\n<!---------------------------           DReps          ------------------------>\n<!---------------------------    Governance Actions    ------------------------>\n\n### Governance actions\n\nWe define seven different types of **governance actions**.\nA governance action is an on-chain event that is triggered by a transaction and has a deadline after which it cannot be enacted.\n\n- An action is said to be **ratified** when it gathers enough votes in its favor (through the rules and parameters that are detailed below).\n- An action that fails to be ratified before its deadline is said to have **expired**.\n- An action that has been ratified is said to be **enacted** once it has been activated on the network.\n\n\n| Action                                                        | Description                                                                                                              |\n|:--------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------|\n| 1. Motion of no-confidence                                    | A motion to create a _state of no-confidence_ in the current constitutional committee                                    |\n| 2. Update committee and/or threshold and/or terms             | Changes to the members of the constitutional committee and/or to its signature threshold and/or terms                    |\n| 3. New Constitution or Guardrails Script                      | A modification to the Constitution or Guardrails Script, recorded as on-chain hashes                                       |\n| 4. Hard-Fork[^2] Initiation                                   | Triggers a non-backwards compatible upgrade of the network; requires a prior software upgrade                            |\n| 5. Protocol Parameter Changes                                 | Any change to **one or more** updatable protocol parameters, excluding changes to major protocol versions (\"hard forks\") |\n| 6. Treasury Withdrawals                                       | Withdrawals from the treasury                                                                                            |\n| 7. Info                                                       | An action that has no effect on-chain, other than an on-chain record                                                     |\n\n**Any Ada holder** can submit a governance action to the chain.\nThey must provide a deposit of `govActionDeposit` Lovelace, which will be returned when the action is finalized\n(whether it is **ratified** or has **expired**).\nThe deposit amount will be added to the _deposit pot_, similar to stake key deposits.\nIt will also be counted towards the stake of the reward address it will be paid back to, to not reduce the submitter's voting power to vote on their own (and competing) actions.\n\nIf a guardrails script is present, the transaction must include that\nscript in the witness set either directly, or via reference inputs,\nand any other requirements that the guardrails script makes must be\nsatisfied.\n\nNote that a motion of no-confidence is an extreme measure that enables Ada holders to revoke the power\nthat has been granted to the current constitutional committee.\n\n> **Note**\n> A **single** governance action might contain **multiple** protocol parameter updates. Many parameters are inter-connected and might require moving in lockstep.\n\n#### Ratification\n\nGovernance actions are **ratified** through on-chain voting actions.\nDifferent kinds of governance actions have different ratification requirements but always involve **two of the three** governance bodies,\nwith the exception of a hard-fork initiation and security-relevant protocol parameters, which requires ratification by all governance bodies.\nDepending on the type of governance action, an action will thus be ratified when a combination of the following occurs:\n\n* the constitutional committee approves of the action (the number of members who vote `Yes` meets the threshold of the constitutional committee)\n* the DReps approve of the action (the stake controlled by the DReps who vote `Yes` meets a certain threshold of the total active voting stake)\n* the SPOs approve of the action (the stake controlled by the SPOs who vote `Yes` meets a certain threshold of the total active voting stake, excepting Hard Fork Governance Actions)\n\n> **Warning**\n> As explained above, different stake distributions apply to DReps and SPOs.\n\nA successful motion of no-confidence, update of the constitutional committee,\na constitutional change, or a hard-fork, delays\nratification of all other governance actions until the first epoch after their enactment. This gives\nan updated constitutional committee enough time to vote on current proposals, re-evaluate existing proposals\nwith respect to a new constitution, and ensures that the in principle arbitrary semantic changes caused\nby enacting a hard-fork do not have unintended consequences in combination with other actions.\n\n##### Requirements\n\nThe following table details the ratification requirements for each governance action scenario. The columns represent:\n\n* **Governance action type**<br/>\n  The type of governance action. Note that the protocol parameter updates are grouped into four categories.\n\n* **Constitutional committee (abbrev. CC)**<br/>\n  A value of ✓ indicates that the constitutional committee must approve this action.<br/>\n  A value of - means that constitutional committee votes do not apply.\n\n* **DReps**<br/>\n  The DRep vote threshold that must be met as a percentage of *active voting stake*.\n\n* **SPOs**<br/>\n  The SPO vote threshold which must be met as a certain threshold of the total active voting stake, excepting Hard Fork Governance Actions. Due to the need for robust consensus around Hard Fork initiations, these votes must be met as a percentage of the stake held by all stake pools. <br/>\n  A value of - means that SPO votes do not apply.\n\n| Governance action type                                               | CC | DReps    | SPOs     |\n|:---------------------------------------------------------------------|:---|:---------|:---------|\n| 1. Motion of no-confidence                                           | \\- | $P_1$    | $Q_1$    |\n| 2<sub>a</sub>. Update committee/threshold (_normal state_)           | \\- | $P_{2a}$ | $Q_{2a}$ |\n| 2<sub>b</sub>. Update committee/threshold (_state of no-confidence_) | \\- | $P_{2b}$ | $Q_{2b}$ |\n| 3. New Constitution or Guardrails Script                             | ✓  | $P_3$    | \\-       |\n| 4. Hard-fork initiation                                              | ✓  | $P_4$    | $Q_4$    |\n| 5<sub>a</sub>. Protocol parameter changes, network group             | ✓  | $P_{5a}$ | \\-       |\n| 5<sub>b</sub>. Protocol parameter changes, economic group            | ✓  | $P_{5b}$ | \\-       |\n| 5<sub>c</sub>. Protocol parameter changes, technical group           | ✓  | $P_{5c}$ | \\-       |\n| 5<sub>d</sub>. Protocol parameter changes, governance group          | ✓  | $P_{5d}$ | \\-       |\n| 6. Treasury withdrawal                                               | ✓  | $P_6$    | \\-       |\n| 7. Info                                                              | ✓  | $100$    | $100$    |\n\nEach of these thresholds is a governance parameter. There is one\nadditional threshold, `Q5`, related to security relevant protocol\nparameters, which is explained below.\nThe initial thresholds should be chosen by the Cardano community as a whole.\nAll thresholds for the Info action are set to 100% since setting it any lower\nwould result in not being able to poll above the threshold.\n\nSome parameters are relevant to security properties of the system. Any\nproposal attempting to change such a parameter requires an additional\nvote of the SPOs, with the threshold `Q5`.\n\nThe security relevant protocol parameters are:\n* `maxBlockBodySize`\n* `maxTxSize`\n* `maxBlockHeaderSize`\n* `maxValueSize`\n* `maxBlockExecutionUnits`\n* `txFeePerByte`\n* `txFeeFixed`\n* `utxoCostPerByte`\n* `govActionDeposit`\n* `minFeeRefScriptCostPerByte`\n\n> **Note**\n> It may make sense for some or all thresholds to be adaptive with respect to the Lovelace that is actively registered to vote.\n> For example, a threshold could vary between 51% for a high level of registration and 75% for a low level registration.\n> Moreover, the treasury threshold could also be adaptive, depending on the total Lovelace that is being withdrawn,\n> or different thresholds could be set for different levels of withdrawal.\n\n> **Note**\n> To achieve legitimacy, the minimum acceptable threshold should be no less than 50% of the delegated stake.\n\n\n##### Restrictions\n\nApart from _Treasury withdrawals_ and _Infos_, we include a mechanism for ensuring that governance\nactions of the same type do not accidentally clash with each other in an unexpected way.\n\nEach governance action must include the governance action ID for the most recently enacted action of its given type.\nThis means that two actions of the same type can be enacted at the same time,\nbut they must be *deliberately* designed to do so.\n\n\n#### Enactment\n\nActions that have been ratified in the current epoch are prioritized as follows for enactment:\n\n1. Motion of no-confidence\n2. Update committee/threshold\n3. New Constitution or Guardrails Script\n4. Hard Fork initiation\n5. Protocol parameter changes\n6. Treasury withdrawals\n7. Info\n\n> **Note** _Info_ actions cannot be ratified or enacted, since they do not have any effect on the protocol.\n\n##### Order of enactment\n\nGovernance actions are enacted in order of acceptance to the chain.\nThis resolves conflicts where, e.g. there are two competing parameter changes.\n\n#### Lifecycle\n\nGovernance actions are checked for ratification only on an epoch boundary.\nOnce ratified, actions are staged for enactment.\n\nAll submitted governance actions will therefore either:\n\n1. be **ratified**, then **enacted**\n2. or **expire** after a number of epochs\n\nIn all of those cases, deposits are returned immediately.\n\nAll governance actions are enacted on the epoch boundary after their ratification.\n\n#### Content\n\nEvery governance action will include the following:\n\n* a deposit amount (recorded since the amount of the deposit is an updatable protocol parameter)\n* a reward address to receive the deposit when it is repaid\n* an anchor for any metadata that is needed to justify the action\n* a hash digest value to prevent collisions with competing actions of the same type (as described earlier)\n\n<!-- TODO: Provide a CBOR specification in the annexe for these new on-chain entities -->\n\nIn addition, each action will include some elements that are specific to its type:\n\n| Governance action type                             | Additional data                                                                                                                                                                                 |\n|:---------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 1. Motion of no-confidence                         | None                                                                                                                                                                                            |\n| 2. Update committee/threshold                      | The set of verification key hash digests (members to be removed), a map of verification key hash digests to epoch numbers (new members and their term limit), and a fraction (new threshold)    |\n| 3. New Constitution or Guardrails Script           | An anchor to the Constitution and an optional script hash of the Guardrails Script                                                                                                              |\n| 4. Hard-fork initiation                            | The new (greater) major protocol version                                                                                                                                                        |\n| 5. Protocol parameters changes                     | The changed parameters                                                                                                                                                                          |\n| 6. Treasury withdrawal                             | A map from stake credentials to a positive number of Lovelace                                                                                                                                   |\n| 7. Info                                            | None                                                                                                                                                                                            |\n\n> **Note**\n> The new major protocol version must be precisely one greater than the current protocol version.\n> Any two consecutive epochs will therefore either have the same major protocol version, or the\n> later one will have a major protocol version that is one greater.\n\n> **Note**\n> There can be no duplicate committee members - each pair of credentials in a committee must be unique.\n\nEach governance action that is accepted on the chain will be assigned a unique identifier (a.k.a. the **governance action ID**),\nconsisting of the transaction hash that created it and the index within the transaction body that points to it.\n\n#### Protocol Parameter groups\n\nWe have grouped the protocol parameter changes by type,\nallowing different thresholds to be set for each group.\n\nWe are not, however, restricting each protocol parameter governance action to be contained within one group.\nIn case where a governance action carries updates for multiple parameters from different groups,\nthe maximum threshold of all the groups involved will apply to any given such governance action.\n\nThe _network_,  _economic_ and _technical_ parameter groups collect existing protocol parameters that were introduced during the Shelley, Alonzo and Babbage eras.\nIn addition, we introduce a new _governance_ group that is specific to the new governance parameters that will be introduced by CIP-1694.\n\nThe **network group** consists of:\n* maximum block body size (`maxBlockBodySize`)\n* maximum transaction size (`maxTxSize`)\n* maximum block header size (`maxBlockHeaderSize`)\n* maximum size of a serialized asset value (`maxValueSize`)\n* maximum script execution units in a single transaction (`maxTxExecutionUnits`)\n* maximum script execution units in a single block (`maxBlockExecutionUnits`)\n* maximum number of collateral inputs (`maxCollateralInputs`)\n\nThe **economic group** consists of:\n* minimum fee coefficient (`txFeePerByte`)\n* minimum fee constant (`txFeeFixed`)\n* delegation key Lovelace deposit (`stakeAddressDeposit`)\n* pool registration Lovelace deposit (`stakePoolDeposit`)\n* monetary expansion (`monetaryExpansion`)\n* treasury expansion (`treasuryCut`)\n* minimum fixed rewards cut for pools (`minPoolCost`)\n* minimum Lovelace deposit per byte of serialized UTxO (`utxoCostPerByte`)\n* prices of Plutus execution units (`executionUnitPrices`)\n\nThe **technical group** consists of:\n* pool pledge influence (`poolPledgeInfluence`)\n* pool retirement maximum epoch (`poolRetireMaxEpoch`)\n* desired number of pools (`stakePoolTargetNum`)\n* Plutus execution cost models (`costModels`)\n* proportion of collateral needed for scripts (`collateralPercentage`)\n\nThe **governance group** consists of all the new protocol parameters that are introduced in this CIP:\n* governance voting thresholds ($P_1$, $P_{2a}$, $P_{2b}$, $P_3$, $P_4$, $P_{5a}$, $P_{5b}$, $P_{5c}$, $P_{5d}$, $P_6$, $Q_1$, $Q_{2a}$, $Q_{2b}$, $Q_4$, $Q_5$)\n* governance action maximum lifetime in epochs (`govActionLifetime`)\n* governance action deposit (`govActionDeposit`)\n* DRep deposit amount (`dRepDeposit`)\n* DRep activity period in epochs (`dRepActivity`)\n* minimal constitutional committee size (`committeeMinSize`)\n* maximum term length (in epochs) for the constitutional committee members (`committeeMaxTermLength`)\n\n<!-- TODO:\n  - Decide on the initial values for the new governance parameters\n\n  - Decide on coherence conditions on the voting thresholds.\n    For example, the threshold for a motion of no-confidence should arguably be higher than that of a minor treasury withdrawal.\n-->\n\n<!---------------------------    Governance Actions    ------------------------>\n\n<!---------------------------          Votes           ------------------------>\n\n### Votes\n\nEach vote transaction consists of the following:\n\n* a governance action ID\n* a role - constitutional committee member, DRep, or SPO\n* a governance credential witness for the role\n* an optional anchor (as defined above) for information that is relevant to the vote\n* a 'Yes'/'No'/'Abstain' vote\n\nFor SPOs and DReps, the number of votes that are cast (whether 'Yes', 'No' or 'Abstain') is proportional to the Lovelace that is delegated to them at the point the\naction is checked for ratification.  For constitututional committee members, each current committee member has one vote.\n\n> **Warning** 'Abstain' votes are not included in the \"active voting stake\".\n>\n> Note that an explicit vote to abstain differs from abstaining from voting.\n> Unregistered stake that did not vote behaves like an 'Abstain' vote,\n> while registered stake that did not vote behaves like a 'No' vote.\n> To avoid confusion, we will only use the word 'Abstain' from this point onward to mean an on-chain vote to abstain.\n\nThe governance credential witness will trigger the appropriate verifications in the ledger according to the existing `UTxOW` ledger rule\n(i.e. a signature check for verification keys, and a validator execution with a specific vote redeemer and new Plutus script purpose for scripts).\n\nVotes can be cast multiple times for each governance action by a single credential.\nCorrectly submitted votes override any older votes for the same credential and role.\nThat is, the voter may change their position on any action if they choose.\nAs soon as a governance action is ratified, voting ends and transactions containing further votes are invalid.\n\n#### Governance state\n\nWhen a governance action is successfully submitted to the chain, its progress will be tracked by the ledger state.\nIn particular, the following will be tracked:\n\n* the governance action ID\n* the epoch that the action expires\n* the deposit amount\n* the rewards address that will receive the deposit when it is returned\n* the total 'Yes'/'No'/'Abstain' votes of the constitutional committee for this action\n* the total 'Yes'/'No'/'Abstain' votes of the DReps for this action\n* the total 'Yes'/'No'/'Abstain' votes of the SPOs  for this action\n\n\n#### Changes to the stake snapshot\n\nSince the stake snapshot changes at each epoch boundary, a new tally must be calculated when each unratified governance action\nis checked for ratification.  This means that an action could be enacted even though the DRep or SPO votes have not changed\n(since the vote delegation could have changed).\n\n#### Definitions relating to voting stake\n\nWe define a number of new terms related to voting stake:\n\n* Lovelace contained in a transaction output is considered **active for voting** (that is, it forms the \"active voting stake\"):\n  * It contains a registered stake credential.\n  * The registered stake credential has delegated its voting rights to a DRep.\n* Relative to some percentage `P`, a DRep (SPO) **vote threshold has been met** if the sum of the relative stake that has been delegated to the DReps (SPOs)\n  that vote `Yes` to a governance action\n  is at least `P`.\n\n## Rationale\n\n+ [Role of the constitutional committee](#role-of-the-constitutional-committee)\n+ [Intentional omission of identity verification](#intentional-omission-of-identity-verification)\n+ [Reducing the power of entities with large amounts of Ada](#reducing-the-power-of-entities-with-large-amounts-of-ada)\n+ [Piggybacking on stake pool stake distribution](#piggybacking-on-stake-pool-stake-distribution)\n+ [Separation of hard-fork initiation from standard protocol parameter changes](#separation-of-hard-fork-initiation-from-standard-protocol-parameter-changes)\n+ [The purpose of the DReps](#the-purpose-of-the-dreps)\n+ [Ratification requirements table](#ratification-requirements-table)\n+ [Motion of no-confidence](#motion-of-no-confidence)\n+ [Update committee/threshold (state of no-confidence)](#update-committeethreshold-state-of-no-confidence)\n+ [The versatility of the info governance action](#the-versatility-of-the-info-governance-action)\n+ [Hard-fork initiation](#hard-fork-initiation)\n+ [New metadata structures](#new-metadata-structures)\n+ [Controlling the number of active governance actions](#controlling-the-number-of-active-governance-actions)\n+ [No AVST](#no-avst)\n\n### Role of the constitutional committee\n\nAt first sight, the constitutional committee may appear to be a special committee that has been granted extra power over DReps.\nHowever, because DReps can replace the constitutional committee at any time and DRep votes are also required to ratify every governance action,\nthe constitutional committee has no more (and may, in fact, have less) power than the DReps.\nGiven this, what role does the committee play, and why is it not superfluous?\nThe answer is that the committee solves the bootstrapping problem of the new governance framework.\nIndeed, as soon as we pull the trigger and enable this framework to become active on-chain, then without a constitutional committee,\nthere would rapidly need to be sufficient DReps, so that the system did not rely solely on SPO votes.\nWe cannot yet predict how active the community will be in registering as DReps, nor how reactive other Ada holders will be regarding delegation of votes.\n\nThus, the constitutional committee comes into play to make sure that the system can transition from\nits current state into fully decentralized governance in due course.\nFurthermore, in the long run, the committee can play a mentoring and advisory role in the governance\ndecisions by being a set of elected representatives who are put under the spotlight for their judgment and guidance in governance decisions.\nAbove all, the committee is required at all times to adhere to the Constitution and to ratify proposals in accordance with the provisions of the Constitution.\n\n### Intentional Omission of Identity Verification\n\nNote that this CIP does not mention any kind of identity validation or verification for the members of the constitutional committee or the DReps.\n\nThis is intentional.\n\nWe hope that the community will strongly consider only voting for and delegating to those DReps who provide something like a DID to identify themselves.\nHowever, enforcing identity verification is very difficult without some centralized oracle, which we consider to be a step in the wrong direction.\n\n### Reducing the power of entities with large amounts of Ada\n\nVarious mechanisms, such as quadratic voting, have been proposed to guard against entities with a large amount of influence.\nIn a system based on \"1 Lovelace, 1 vote\", however, it is trivially easy to split stake into small amounts and undo the protections.\nWithout an on-chain identity verification system we cannot adopt any such measures.\n\n### Piggybacking on stake pool stake distribution\n\nThe Cardano protocol is based on a Proof-of-Stake consensus mechanism, so using a stake-based governance approach is sensible.\nHowever, there are many ways that could be used to define how to record the stake distribution between participants.\nAs a reminder, network addresses can currently contain two sets of credentials: one to identify who can unlock funds at an address\n(a.k.a. payment credentials) and one that can be delegated to a stake pool (a.k.a. delegation credentials).\n\nRather than defining a third set of credentials, we instead propose to re-use the existing delegation credentials,\nusing a new on-chain certificate to determine the governance stake distribution. This implies that the set of DReps can (and likely will) differ from the set of SPOs,\nso creating balance. On the flip side, it means that the governance stake distribution suffers from the same shortcomings as that for block production:\nfor example, wallet software providers must support multi-delegation schemes and must facilitate the partitioning of stake into sub-accounts should an Ada holder desire to delegate to multiple DReps,\nor an Ada holder must manually split their holding if their wallet does not support this.\n\nHowever, this choice also limits future implementation effort for wallet providers and minimizes the effort that is needed for end-users to participate in the governance protocol.\nThe latter is a sufficiently significant concern to justify the decision. By piggybacking on the existing structure,\nthe system remains familiar to users and reasonably easy to set up. This maximizes both the chance of success of, and the rate of participation in, the governance framework.\n\n### Separation of Hard Fork Initiation from Standard Protocol Parameter Changes\n\nIn contrast to other protocol parameter updates, hard forks (or, more correctly, changes to the protocol's major version number) require much more attention.\nIndeed, while other protocol parameter changes can be performed without significant software changes,\na hard fork assumes that a super-majority of the network has upgraded the Cardano node to support the new set of features that are introduced by the upgrade.\nThis means that the timing of a hard fork event must be communicated well ahead of time to all Cardano users, and requires coordination between stake pool operators, wallet providers, DApp developers, and the node release team.\n\nHence, this proposal, unlike the Shelley scheme, promotes hard fork initiations as a standalone governance action, distinct from protocol parameter updates.\n\n### The purpose of the DReps\n\nNothing in this proposal limits SPOs from becoming DReps.\nWhy do we have DReps at all?\nThe answer is that SPOs are chosen purely for block production and not all SPOs will want to become DReps.\nVoters can choose to delegate their vote to DReps without needing to consider whether they are\nalso a good block producer, and SPOs can choose to represent Ada holders or not.\n\n### Ratification Requirements Table\n\nThe requirements in the [ratification requirement table](#requirements) are explained here.\nMost of the governance actions have the same kind of requirements:\nthe constitutional committee and the DReps must reach a sufficient number of\n'Yes' votes.\nThis includes these actions:\n* Update committee/threshold (normal state)\n* New Constitution\n* Protocol parameter changes\n* Treasury withdrawal\n\n### Motion of no-confidence\n\nA motion of no-confidence represents a lack of confidence by the Cardano community in the\ncurrent constitutional committee, and hence the constitutional committee should not\nbe included in this type of governance action.\nIn this situation, the SPOs and the DReps are left to represent the will of the community.\n\n### Update committee/threshold (state of no-confidence)\n\nSimilar to the motion of no-confidence, electing a constitutional committee\ndepends on both the SPOs and the DReps to represent the will of the community.\n\n### The versatility of the info governance action\n\nWhile not binding on chain, the Info governance action could be useful in an number of\nsituations.  These include:\n\n* ratifying a CIP\n* deciding on the genesis file for a new ledger era\n* recording initial feedback for future governance actions\n\n### Hard-Fork initiation\n\nRegardless of any governance mechanism, SPO participation is needed for any hard fork since they must upgrade their node software.\nFor this reason, we make their cooperation explicit in the hard fork initiation governance action,\nby always requiring their vote.\nThe constitutional committee also votes, signaling the constitutionality of a hard fork.\nThe DReps also vote, to represent the will of every stake holder.\n\n### New Metadata structures\n\nThe governance actions, the votes and the certificates and the Constitution use new metadata fields,\nin the form of URLs and integrity hashes\n(mirroring the metadata structure for stake pool registration).\nThe metadata is used to provide context.\nGovernance actions need to explain why the action is needed,\nwhat experts were consulted, etc.\nSince transaction size constraints should not limit this explanatory data,\nwe use URLs instead.\n\nThis does, however, introduce new problems.\nIf a URL does not resolve, what should be the expectation for voting on that action?\nShould we expect everyone to vote 'No'?\nIs this an attack vector against the governance system?\nIn such a scenario, the hash pre-image could be communicated in other ways, but we should be\nprepared for the situation.\nShould there be a summary of the justification on chain?\n\n#### Alternative: Use of transaction metadata\n\nInstead of specific dedicated fields in the transaction format, we could instead use the existing transaction metadata field.\n\nGovernance-related metadata can be clearly identified by registering a CIP-10 metadata label.\nWithin that, the structure of the metadata can be determined by this CIP (exact format TBD), using an index to map the vote or governance action ID to the corresponding metadata URL and hash.\n\nThis avoids the need to add additional fields to the transaction body, at the risk of making it easier for submitters to ignore.\nHowever, since the required metadata can be empty (or can point to a non-resolving URL),\nit is already easy for submitters to not provide metadata, and so it is unclear whether this makes the situation worse.\n\nNote that transaction metadata is never stored in the ledger state, so it would be up to clients\nto pair the metadata with the actions and votes in this alternative, and would not be available\nas a ledger state query.\n\n### Controlling the number of active governance actions\n\nSince governance actions are available for anyone to submit, we need some mechanism to prevent those\nindividuals responsible for voting from becoming overwhelmed with a flood of proposals.\nA large deposit is one such mechanism, but this comes at the unfortunate cost of being a barrier\nfor some people to submit an action.\nNote, however, that crowd-sourcing with a Plutus script is always an option to gather the deposit.\n\nWe could, alternatively, accept the possibility of a large number of actions active at any given\ntime, and instead depend on off-chain socialization to guide voters' attention to those that merit it.\nIn this scenario, the constitutional committee might choose to only consider proposals which have\nalready garnered enough votes from the DReps.\n\n### No AVST\n\nAn earlier draft of this CIP included the notion of an \"active voting stake threshold\", or AVST.\nThe purpose of AVST was to ensure the legitimacy of each vote, removing the possibility that, for example,\n9 out of 10 Lovelace could decide the fate of millions of entities on Cardano.\nThere are really two concerns here, which are worth separating.\n\nThe first concern is that of bootstrapping the system, i.e. reaching the initial moment when\nsufficient stake is registered to vote.\nThe second concern is that the system could lose participation over time.\nOne problem with the AVST is that it gives an incentive for SPOs to desire a low voting registration\n(since their votes then hold more weight).\nThis is absolutely not a slight on the existing SPOs, but an issue with bad incentives.\n\nWe have chosen, therefore, to solve the two concerns differently.\nWe solve the bootstrapping problem as described in the section on bootstrapping.\nWe solve the long-term participation problem by not allowing reward withdrawals\n(after the bootstrap phase) unless the stake is delegated to a DRep\n(including the two special cases, namely 'Abstain' and 'No confidence').\n\n### Changelog\n\n#### Changes post Longmont workshop (March 2023)\n\n* Thank the workshop attendees.\n* We have added Constitutional Committee terms.\n* Two new \"pre-defined\" voting options: abstain and no confidence.\n* New \"Info\" governance action.\n* Use the most recent DRep stake distribution for ratification.\n  This means that if ever your DRep votes how you do not like,\n  you can immediately make yourself a DRep and vote how you want.\n* Escrow some ADA from the current treasury for potential future DRep\n  incentives.\n* Remove the tiered treasury actions in favor of something adaptive\n  (so the \"yes\" threshold would depend on:\n    1) how much ada,\n    2) how high the registered voting stake, and maybe\n    3) how much ada is released every epoch\n* Split the protocol parameter updates into four groups:\n  network, economic, technical, and governmental.\n* Most governance actions can be enacted (upon ratification)\n  right away. All but: protocol parameters and hard forks.\n* Remove \"one action per type per epoch\" restriction in favor of\n  tracking the last action ID of each type, and including this in\n  the action.\n* No AVST.\n* Bootstrap phase: Until X% of ADA is registered to vote or Y epochs\n  have elapsed, only parameter changes and hard forks can happen.\n  PP changes just need CC threshold, HFs need CC and SPOs.\n  After the bootstrap phase, we put in place the incentive to keep low\n  DReps, but this mechanism **automatically** relaxes.\n* New plutus script purpose for DReps.\n* Multiple treasury withdrawals in one epoch.\n* A section on the recursive problem of \"how do we ratify this CIP\".\n* Changes to the local state-query protocol.\n* New ideas, time permitting:\n  * Weigh SPO stake vote by pledge somehow.\n  * DReps can specify which other DRep gets their delegators\n    in the event that they retire.\n  * Reduced government action deposit if one member of the CC signs off\n    on it (which presumably means it has gone through some process).\n  * Include hash of (future) genesis configuration within HF proposal.\n\n#### Changes post Edinburgh workshop (July 2023)\n\n* Add guardrails script, which can control what treasury withdrawals and\n  protocol parameter changes are allowed.\n* Remove dropping of governance actions. The only effect this has is\n  that in case a no confidence action passes, actions stay\n  around. However, only new committee proposals that have been\n  designed to build on top of that no confidence action can be\n  enacted. If a new committee gets elected while some of those actions\n  haven't expired, those actions can be ratified but the new committee\n  has to approve them.\n* All governance actions are enacted one epoch after they are ratified.\n* Move post-bootstrapping restrictions into 'Other Ideas'.\n* Add a section on different deposit amounts to 'Other Ideas'.\n* Add a section for a minimum AVS to 'Other Ideas'.\n* Rename some protocol parameters.\n* Rename `TALLY` to `GOV`.\n* Turn the Constitution into an anchor.\n* Rework which anchors are required and which are optional.\n* Clean up various inconsistencies and leftovers from older versions.\n\n#### Security-relevant changes and other fixes (January 2024)\n\n* Guard security-relevant changes behind SPO votes.\n* The system does not enter a state of no confidence with insufficient\n  active CC members, the CC just becomes unable to act.\n* Clarify that CC members can use any kind of credential.\n\n#### May 2024\n\n* Update the section on the bootstrap period.\n* Mention missing `Q_5` parameter.\n* Various small fixes/consistency changes.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] A new ledger era is enabled on the Cardano mainnet, which implements the above specification.\n - Bootstrapping phase governance via Chang #1 hardfork\n - Full governance via Plomin hardfork\n\n### Implementation Plan\n\nThe features in this CIP require a hard fork.\n\nThis document describes an ambitious change to Cardano governance.\nWe propose to implement the changes via two hard forks: the first\none containing all new features but some being disabled for a bootstrap period\nand the second one enabling all features.\n\nIn the following sections, we give more details about the various implementation work items that have already been identified.\nIn addition, the final section exposes a few open questions which will need to be finalized.\nWe hope that those questions can be addressed through community workshops and discussions.\n\n#### Ratification of this proposal\n\nThe ratification of this proposal is something of a circular problem: we need some form of governance framework in order to agree on what the final governance framework should be.\nAs has been stated many times, CIPs are not authoritative, nor are they a governance mechanism.\nRather, they describe technical solutions that have been deemed sound (from a technical standpoint) by community of experts.\n\nCIP-1694 arguably goes beyond the usual scope of the CIP process and there is a strong desire to ratify this CIP through _some process_.\nHowever, that process is yet to be defined and it remains an open question.\nThe final ratification process is likely to be a blend of various ideas, such as:\n\n- [x] Gather opinions from community-held workshops, akin to the Colorado workshop of February-March 2023.\n- [ ] Exercise voting actions on a public testnet, with sufficient participation.\n- [ ] Poll the established SPOs.\n- [ ] Leverage Project Catalyst to gather inputs from the existing voting community (albeit small in terms of active stake).\n\n#### Changes to the transaction body\n\n- [x] New elements will be added to the transaction body, and existing update and MIR capabilities will be removed. In particular,\n\n  The governance actions and votes will comprise two new transaction body fields.\n\n- [x] Three new kinds of certificates will be added in addition to the existing ones:\n\n  * DRep registration\n  * DRep de-registration\n  * Vote delegation\n\n  And similarly, the current MIR and genesis certificates will be removed.\n\n- [x] A new `Voting` purpose will be added to Plutus script contexts.\n  This will provide, in particular, the vote to on-chain scripts.\n\n> **Warning** As usual, we will provide a CDDL specification for each of those changes.\n\n#### Changes to the existing ledger rules\n\n* The `PPUP` transition rule will be rewritten and moved out of the `UTxO` rule and into the `LEDGER` rule as a new `GOV` rule.\n\n  It will process and record the governance actions and votes.\n\n* The `NEWEPOCH` transition rule will be modified.\n* The `MIR` sub-rule will be removed.\n* A new `RATIFY` rule will be introduced to stage governance actions for enactment.\n\n  It will ratify governance actions, and stage them for enactment in the current or next epoch, as appropriate.\n\n* A new `ENACTMENT` rule will be called immediately after the `EPOCH` rule. This rule will enact governance actions that have previously been ratified.\n* The `EPOCH` rule will no longer call the `NEWPP` sub-rule or compute whether the quorum is met on the PPUP state.\n\n#### Changes to the local state-query protocol\n\nThe on-chain governance workload is large, but the off-chain workload for tools and applications will arguably be even larger.\nTo build an effective governance ecosystem, the ledger will have to provide interfaces to various governance elements.\n\nWhile votes and DReps (de)registrations are directly visible in blocks and will, therefore, be accessible via the existing local-chain-sync protocols; we will need to upgrade the local-state-query protocol to provide extra insights on information which are harder to infer from blocks (i.e. those that require maintaining a ledger state). New state queries should cover (at least):\n\n- Governance actions currently staged for enactment\n- Governance actions under ratification, with the total and percentage of yes stake, no stake and abstain stake\n- The current constitutional committee, and constitution hash digest\n\n#### Bootstrapping Phase\n\nWe will need to be careful how we bootstrap this fledgling government.  All the parties\nthat are involved will need ample time to register themselves and to become familiar with the process.\n\nSpecial provisions will apply in the initial bootstrap phase.\nFirstly, during the bootstrap phase, a vote from the constitutional committee\nis sufficient to change the protocol parameters.\nSecondly, during the bootstrap phase, a vote from the constitutional committee,\ntogether with a sufficient SPO vote, is sufficient to initiate a hard fork.\nThirdly, info actions will be available.\nNo other actions other than those mentioned in this paragraph are possible during the bootstrap phase.\n\nThe bootstrap phase ends when the Constitutional Committee and SPOs\nratify a subsequent hard fork, enabling the remaining governance\nactions and DRep participation.\nThis is likely to be a number of months after the Chang hard fork.\nAlthough all features will be technically available at this point, additional\nrequirements for using each feature may be specified in the constitution.\n\nMoreover, there will be an interim Constitutional committee with a set term,\nalso specified in the next ledger era configuration file.\nThe rotational schedule of the first non-interim committee could be included in the constitution itself.\nNote, however, that since the constitutional committee never votes on new committees,\nit cannot actually enforce the rotation.\n\n#### Other Ideas / Open Questions\n\n##### Pledge-weighted SPO voting\n\nThe SPO vote could additionally be weighted by each SPO's pledge.\nThis would provide a mechanism for allowing those with literal stake in the game to have a stronger vote.\nThe weighting should be carefully chosen.\n\n##### Automatic re-delegation of DReps\n\nA DRep could optionally list another DRep credential in their registration certificate.\nUpon retirement, all of the DRep's delegations would be automatically transferred to the\ngiven DRep credential.  If that DRep had already retired, the delegation would be transfer\nto the 'Abstain' voting option.\n\n##### No DRep registration\n\nSince the DRep registration does not perform any necessary functions,\nthe certificates for (de-)registering DReps could be removed. This\nmakes the democracy more liquid since it removes some bureaucracy and\nalso removes the need for the DRep deposit, at the cost of moving the anchor that is part of the\nDRep registration certificate into the transaction metadata.\n\n##### Reduced deposits for some government actions\n\nThe deposit that is attached to governance actions exists to prevent a flood of non-serious governance\nactions, each of which would require time and attention from the Cardano community.\nWe could reduce this deposit for proposals which go through some agreed upon off-chain process.\nThis would be marked on-chain by the endorsement of at least one constitutional committee member.\nThe downside of this idea is that it gives more power to the constitutional committee.\n\n##### Different deposit amounts for different governance actions\n\nMultiple workshops for this CIP have proposed to introduce a different\ndeposit amount for each type of governance action. It was not clear\nwhether a majority was in favor of this idea, but this may be\nconsidered if it becomes clear that it is necessary.\n\n##### Minimum active voting stake\n\nAs a further guarantee to ensure governance actions cannot be proposed\nright before a hard fork, be voted on by one DRep with a large amount\nof stake and be enacted immediately, there could be an additional\nrequirement that a certain fixed absolute amount of stake needs to\ncast a 'Yes' vote on the action to be enacted.\n\nThis does not seem necessary in the current design, since the stake of\nall registered DReps behaves like a 'No' vote until they have actually\ncast a vote. This means that for this scenario to occur, the malicious\nactor needs at least to be in control of the fraction of DRep stake\ncorresponding to the relevant threshold, at which point this might as\nwell be considered a legitimate action.\n\n##### Include hash of (future) genesis configuration within hard-fork proposal\n\nSome hard-forks require new genesis configurations.\nThis has been the case for the Shelley and Alonzo hard forks (but not Allegra, Mary, Vasil or Valentine), may be the case in the future.\nAt the moment, this proposal doesn't state anything about such a genesis configuration:\nit is implicitly assumed to be an off-chain agreement.\nWe could however, enforce that (the hash of) a specific genesis configuration is also captured within a hard-fork governance action.\n\n##### Adaptive thresholds\n\nAs discussed above, it may make sense for some or all thresholds to be adaptive with respect to the Lovelace that is actively registered to vote,\nso that the system provides greater legitimacy when there is only a low level of active voting stake.\nThe bootstrapping mechanism that is proposed above may subsume this, however, by ensuring that the governance system is activated\nonly when a minimum level of stake has been delegated to DReps.\n\n\n##### Renaming DReps / state of no-confidence?\n\nIt has been stated several times that \"DReps\" as presented here, might be confused with Project Catalst DReps.\nSimilarly, some people have expressed confusion between the state of no-confidence, the motion of no-confidence and the no-confidence voting option.\n\nWe could imagine finding better terms for these concepts.\n\n##### Rate-limiting treasury movements\n\nNothing prevents money being taken out of the treasury other than the proposed votes and voting thresholds. Given that the Cardano treasury is a quite fundamental component of its monetary policy, we could imagine enforcing (at the protocol level) the maximum amount that can removed from the treasury over any period of time.\n\n##### Final safety measure, post bootstrapping\n\nMany people have stated that they believe that the actual voting turnout will not be so large\nas to be a strain on the throughput of the system.\nWe also believe that this is likely to be the case, but when the bootstrap phase ends we might\nput one final, temporary safety\tmeasure in place (this will also allow us to justify a low DRep deposit amount).\n\nFor values of $X$ and $Y$ that are still to be determined,\nas soon as the bootstrap phase has ended,\nwhen we calculate the DReps stake distribution for the next epoch boundary,\nwe will consider _only_ those DReps that are _either_ in the top $X$-many DReps ranked by stake amount,\nor those DReps that have at least $Y$ Lovelace.\nEvery epoch, the value of $X$ will _increase_ and the value of $Y$ will decrease,\nso that eventually $X$ will be effectively infinite and $Y$ will be zero.\nNote that this is only an incentive, and nothing actually stops any DRep from casting their\nvote (though it will not be counted if it does not meet the requirements).\n\nIf the community decides at some point that there is indeed a problem with congestion,\nthen a hard fork could be enacted that limits the number of DReps in a more restrictive way.\n\nReasonable numbers for the initial value of $X$ are probably 5,000-10,000.\nReasonable numbers for the initial value of $Y$ are probably the total number of Lovelace\ndivided by the initial value of $X$.\n\nThe mechanism should be set to relax at a rate where the restriction is completely eliminated after\na period of six months to one year.\n\n## Acknowledgements\n\n<details>\n  <summary><strong>First draft</strong></summary>\n\nMany people have commented on and contributed to the first draft of this document, which was published in November 2022.\nWe would especially like to thank the following people for providing their wisdom and insights:\n\n * Jack Briggs\n * Tim Harrison\n * Philip Lazos\n * Michael Madoff\n * Evangelos Markakis\n * Joel Telpner\n * Thomas Upfield\n\nWe would also like to thank those who have commented via Github and other channels.\n</details>\n\n<details>\n  <summary><strong>2023 Colorado Workshop (28/02 → 01/03)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Longmont, Colorado on February 28th and March 1st 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Adam Rusch, ADAO & Summon\n* Addie Girouard\n* Andrew Westberg\n* Darlington Wleh, LidoNation\n* Eystein Hansen\n* James Dunseith, Gimbalabs\n* Juana Attieh\n* Kenric Nelson\n* Lloyd Duhon, DripDropz\n* Marcus Jay Allen\n* Marek Mahut, 5 Binaries\n* Markus Gufler\n* Matthew Capps\n* Mercy, Wada\n* Michael Dogali\n* Michael Madoff\n* Patrick Tobler, NMKR\n* Philip Lazos\n* π Lanningham, SundaeSwap\n* Rick McCracken\n* Romain Pellerin\n* Sergio Sanchez Ferreros\n* Tim Harrison\n* Tsz Wai Wu\n</details>\n\n<details>\n  <summary><strong>2023 Mexico City, Mexico Workshop (20/05)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Mexico City, Mexico on May 20th 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Donovan Riaño\n* Cristian Jair Rojas\n* Victor Hernández\n* Ramón Aceves\n* Sergio Andrés Cortés\n* Isaías Alejandro Galván\n* Abigail Guzmán\n* Jorge Fernando Murguía\n* Luis Guillermo Santana\n\n</details>\n\n<details>\n  <summary><strong>2023 Buenos Aires, Argentina Workshop (20/05)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Buenos Aires, Argentina on May 20th 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Lucas Macchiavelli\n* Alejando Pestchanker\n* Juan Manuel Castro Pippo\n* Federico Weill\n* Jose Otegui\n* Mercedes Ruggeri\n* Mauro Andreoli\n* Elias Aires\n* Jorge Nasanovsky\n* Ulises Barreiro\n* Martin Ochoa\n* Facundo Lopez\n* Vanina Estrugo\n* Luca Pestchanker\n</details>\n\n<details>\n  <summary><strong>2023 Johannesburg, South Africa Workshop (25/05)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Johannesburg, South Africa on May 25th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Celiwe Ngwenya\n* Bernard Sibanda\n* Dumo Mbobo\n* Shaolyn Dzwedere\n* Kunoshe Muchemwa\n* Siphiwe Mbobo\n* Lucas Sibindi\n* DayTapoya\n* Mdu Ngwenya\n* Lucky Khumalo\n* Skhangele Malinga\n* Joyce Ncube\n* Costa Katenhe\n* Bramwell Kasanga\n* Precious Abimbola\n* Ethel Q Tshuma\n* Panashe Sibanda\n* Radebe Tefo\n* Kaelo Lentsoe\n* Richmond Oppong\n* Israel Ncube\n* Sikhangele Malinga\n* Nana Safo\n* Ndaba Delsie\n* Collen Tshepang\n* Dzvedere Shaolyn\n* Thandazile Sibanda\n* Ncube Joyce\n* Lucas Sibindi\n* Pinky Ferro\n* Ishmael Ntuta\n* Khumalo Lucky\n* Fhulufelo\n* Thwasile Ngwenya\n* Kunashe Muchemwa\n* Dube Bekezela\n* Tinyiko Baloi\n* Dada Nomathemba\n</details>\n\n\n<details>\n  <summary><strong>2023 Bogota, Colombia Workshop (27/05)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Bogota, Colombia on May 27th 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Alvaro Moncada\n* Jaime Andres Posada Castro\n* Jose Miguel De Gamboa\n* Nicolas Gomez\n* Luis Restrepo (Moxie)\n* Juanita Jaramillo R.\n* Daniel Vanegas\n* Ernesto Rafael Pabon Moreno\n* Carlos Eduardo Escobar\n* Manuel Fernando Briceño\n* Sebastian Pabon\n</details>\n\n<details>\n  <summary><strong>2023 Caracas, Venezuela Workshop (27/05)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Caracas, Venezuela on May 27th 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Jean Carlo Aguilar\n* Wilmer Varón\n* José Erasmo Colmenares\n* David Jaén\n* Félix Dávila\n* Yaneth Duarte\n* Nando Vitti\n* Wilmer Rojas\n* Andreina García\n* Carmen Galban\n* Osmarlina Agüero\n* Ender Linares\n* Carlos A. Palacios R\n* Dewar Rodríguez\n* Lennys Blanco\n* Francys García\n* Davidson Arenas\n</details>\n\n<details>\n  <summary><strong>2023 Manizales, Colombia Workshop (27/05)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Manizales, Colombia on May 27th 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Yaris Cruz\n* Yaneth Duarte\n* Ciro Gelvez\n* Kevin Chacon\n* Juan Sierra\n* Caue Chianca\n* Sonia Malagon\n* Facundo Ramirez\n* Hope R.\n</details>\n\n<details>\n  <summary><strong>2023 Addis Ababa, Ethiopia Workshop (27/05 & 28/5)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Addis Ababa, Ethiopia on May 27th and 28th 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Kaleb Dori\n* Eyassu Birru\n* Matthew Thornton\n* Tamir Kifle\n* Kirubel Tabu\n* Bisrat Miherete\n* Emmanuel Khatchadourian\n* Tinsae Teka\n* Yoseph Ephrem\n* Yonas Eshetu\n* Hanna Kaleab\n* Tinsae Teka\n* Robee Meseret\n* Matias Tekeste\n* Eyasu Birhanu\n* yonatan berihun\n* Nasrallah Hassan\n* Andinet Assefa\n* Tewodros Sintayehu\n* KIDUS MENGISTEAB\n* Djibril Konate\n* Nahom Mekonnen\n* Eyasu Birhanu\n* Eyob Aschenaki\n* Tinsae Demissie\n* Yeabsira Tsegaye\n* Tihitna Miroche\n* Mearaf Tadewos\n* Yab Mitiku\n* Habtamu Asefa\n* Dawit Mengistu\n* Nebiyu Barsula\n* Nebiyu Sultan\n* Nathan Samson\n</details>\n\n<details>\n  <summary><strong>2023 Kyoto and Fukuoka, Japan Workshop (27/05 & 10/06 )</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Kyoto and Fukuoka, Japan on May 27th and June 10th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Arimura\n* Hidemi\n* Nagamaru(SASApool)\n* shiodome47(SODMpool)\n* Wakuda(AID1pool)\n* Yuta(Yuki Oishi)\n* Andrew\n* BANCpool\n* Miyatake\n* Muen\n* Riekousagi\n* SMAN8(SA8pool)\n* Tatsuya\n* カッシー\n* 松\n* ポンタ\n* リサ\n* Mako\n* Ririco\n* ながまる\n* Baku\n* マリア\n* たりふん\n* JUNO\n* Kinoko\n* Chikara\n* ET\n* Akira555\n* Kent\n* Ppp\n* Shiodome47\n* Sam\n* ポール\n* Concon\n* Sogame\n* ハンド\n* Demi\n* Nonnon\n* banC\n* SMAN8(SA8pool)\n* りんむ\n* Kensin\n* りえこうさぎ\n* アダマンタイト\n* の/ゆすけ\n* MUEN\n* いちごだいふく\n* Ranket\n* A.yy\n* N S\n* Kazuya\n* Daikon\n</details>\n\n<details>\n  <summary><strong>2023 Monterey, California Workshop (28/05)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Monterey, California on May 28th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Shane Powser\n* Rodrigo Gomez\n* Adam K. Dean\n* John C. Valdez\n* Kyle Solomon\n* Erick \"Mag\" Magnana\n* Bryant Austin\n* John Huthmaker\n* Ayori Selassie\n* Josh Noriega\n* Matthias Sieber\n</details>\n\n<details>\n  <summary><strong>2023 Tlaxcala, Mexico Workshop (01/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Tlaxcala, Mexico on June 1st 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Victor Hernández\n* Cristian Jair Rojas\n* Miriam Mejia\n* Josmar Cabañas\n* Lizbet Delgado\n* José Alberto Sánchez\n* Fátima Valeria Zamora\n* Julio César Montiel\n* Jesús Pérez\n* José Adrián López\n* Lizbeth Calderón\n* Zayra Molina\n* Nayelhi Pérez\n* Josué Armas\n* Diego Talavera\n* Darían Gutiérrez\n</details>\n\n<details>\n  <summary><strong>2023 LATAM Virtual Workshop (03/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in LATAM Virtual on June 3rd 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Juan Sierra\n* @CaueChianca\n* Ernesto Rafael\n* Pabon Moreno\n* Sonia Malagon\n* Facundo Ramírez\n* Mercedes Ruggeri\n* Hope R.\n* Yaris Cruz\n* Yaneth Duarte\n* Ciro Gélvez\n* Kevin Chacon\n* Juanita Jaramillo\n* Sebastian Pabon\n</details>\n\n<details>\n  <summary><strong>2023 Worcester, Massachusetts Workshop (08/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Worcester, Massachusetts on June 8th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* CardanoSharp\n* Kenric Nelson\n* Matthias Sieber\n* Roberto Mayen\n* Ian Burzynski\n* omdesign\n* Chris Gianelloni\n</details>\n\n<details>\n  <summary><strong>2023 Chicago, Illinois Workshop (10/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Chicago, Illinois on June 10th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Adam Rusch\n* Jose Martinez\n* Michael McNulty\n* Vanessa Villanueva Collao\n* Maaz Jedh\n</details>\n\n<details>\n  <summary><strong>2023 Virtual Workshop (12/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held virtually on June 12th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Rojo Kaboti\n* Tommy Frey\n* Tevo Saks\n* Slate\n* UBIO OBU\n</details>\n\n<details>\n  <summary><strong>2023 Toronto, Canada Workshop (15/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Toronto, Canada on June 15th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* John MacPherson\n* Lawrence Ley\n</details>\n\n<details>\n  <summary><strong>2023 Philadelphia, Pennsylvania Workshop (17/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Philadelphia, Pennsylvania on June 17th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* NOODZ\n* Jarhead\n* Jenny Brito\n* Shepard\n* BONE Pool\n* type_biggie\n* FLAWWD\n* A.I. Scholars\n* Eddie\n* Joker\n* Lex\n* Jerome\n* Joey\n* SwayZ\n* Cara Mia\n* PHILLY 1694\n</details>\n\n<details>\n  <summary><strong>2023 Santiago de Chile Workshop (17/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Santiago de Chile on June 17th 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Rodrigo Oyarsun\n* Sebastián Aravena\n* Musashi Fujio\n* Geo Gavo\n* Lucía Escobar\n* Juan Cruz Franco\n* Natalia Rosa\n* Cristian M. García\n* Alejandro Montalvo\n</details>\n\n<details>\n  <summary><strong>2023 Virtual Workshop (17/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held virtually on June 17th 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Juana Attieh\n* Nadim Karam\n* Amir Azem\n* Rami Hanania\n* LALUL Stake Pool\n* HAWAK Stake Pool\n</details>\n\n<details>\n  <summary><strong>2023 Taipai, Taiwan Workshop (18/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Taipai, Taiwan on June 18th 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Michael Rogero\n* Ted Chen\n* Mic\n* Jeremy Firster \n* Eric Tsai\n* Dylan Chiang\n* JohnsonCai\n* DavidCHIEN\n* Zach Gu\n* Jimmy WANG\n* JackTsai\n* Katherine Hung\n* Will Huang\n* Kwicil\n</details>\n\n<details>\n  <summary><strong>2023 Midgard Vikingcenter Horten, Norway Workshop (19/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Midgard Vikingcenter Horten, Norway on June 19th 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Daniel D. Johnsen\n* Thomas Lindseth\n* Eystein Hansen\n* Gudbrand Tokerud \n* Lally McClay\n* $trym\n* Arne Rasmussen\n* Lise WesselTVVIN\n* Bjarne \n* Jostein Aanderaa\n* Ken-Erik Ølmheim\n* DimSum\n</details>\n\n<details>\n  <summary><strong>2023 Virtual Workshop (19/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held virtually on June 19th 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Nicolas Cerny\n* Nils Peuser\n* Riley Kilgore\n* Alejandro Almanza\n* Jenny Brito\n* John C. Valdez\n* Rhys\n* Thyme\n* Adam Rusch\n* Devryn\n</details>\n\n<details>\n  <summary><strong>2023 New York City, New York Workshop (20/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in New York City, New York on June 20th 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* John Shearing\n* Geoff Shearing\n* Daniela Balaniuc\n* SDuffy\n* Garry Golden\n* Newman\n* Emmanuel Batse\n* Ebae\n* Mojira\n</details>\n\n<details>\n  <summary><strong>2023 La Cumbre, Argentina Workshop (23/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in La Cumbre, Argentina on June 23rd 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Ulises Barreiro\n* Daniel F. Rodriguez\n* Dominique Gromez\n* Leandro Chialvo\n* Claudia Vogel\n* Guillermo Lucero\n* Funes, Brian Carrasco\n* Melisa Carrasco\n* Carlos Carrasco\n</details>\n\n<details>\n  <summary><strong>2023 Minneapolis, Minnesota Workshop (23/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Minneapolis, Minnesota on June 23rd 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Stephanie King\n* Darlington Wleh\n</details>\n\n<details>\n  <summary><strong>2023 La Plata, Argentina Workshop (23/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in La Plata, Argentina on June 23rd 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Mauro Andreoli\n* Rodolfo Miranda\n* Agustin Francella\n* Federico Sting\n* Elias Aires\n* Lucas Macchiavelli\n* Pablo Hernán Mazzitelli\n</details>\n\n<details>\n  <summary><strong>2023 Puerto Madryn, Argentina Workshop (23/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Puerto Madryn, Argentina on June 23rd 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Andres Torres Borda\n* Federico Ledesma Calatayud\n* Maximiliano Torres\n* Federico Prado\n* Domingo Torres\n* Floriana Pérez Barria\n* Martin Real\n* Florencia García\n* Roberto Neme\n</details>\n\n<details>\n  <summary><strong>2023 Accra, Ghana Workshop (24/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Accra, Ghana on June 24th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Wada\n* Laurentine\n* Christopher A.\n* Nathaniel D.\n* Edufua\n* Michael\n* Augusta\n* Jeremiah\n* Boaz\n* Mohammed\n* Richmond O.\n* Ezekiel\n* Megan\n* Josue\n* Michel T.\n* Bineta\n* Afia O.\n* Mercy\n* Enoch\n* Kofi\n* Awura\n* Emelia\n* Richmond S.\n* Solomon\n* Phillip\n* Faakor\n* Manfo\n* Josh\n* Daniel\n* Mermose\n</details>\n\n<details>\n  <summary><strong>2023 Virtual Workshop (24/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held virtually on June 24th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Jonas Riise\n* Thomas Lindseth\n* André \"Eilert\" Eilertsen\n* Eystein Hansen\n</details>\n\n<details>\n  <summary><strong>2023 Seoul, South Korea Workshop (24/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Seoul, South Korea on June 24th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Oscar Hong (JUNGI HONG)\n* SPO_COOL (Kevin Kordano)\n* SPO_KTOP (KT OH)\n* WANG JAE LEE\n* JAE HYUN AN\n* INYOUNG MOON (Penny)\n* HOJIN JEON\n* SEUNG KYU BAEK\n* SA SEONG MAENG\n* JUNG MYEONG HAN\n* BRIAN KIM\n* JUNG HOON KIM\n* SEUNG WOOK JUNG (Peter)\n* HYUNG WOO PARK\n* EUN JAE CHOI\n* NA GYEONG KIM\n* JADEN CHOI\n</details>\n\n<details>\n  <summary><strong>2023 Abu Dhabi, UAE Workshop (25/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Abu Dhabi, UAE on June 25th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Amir Azem\n* Ian Arden\n* Madina Abdibayeva\n* BTBF (Yu Kagaya)\n* محمد الظاهري\n* Tegegne Tefera\n* Rami Hanania\n* Tania Debs\n* Khalil Jad\n* Mohamed Jamal\n* Ruslan Yakubov\n* OUSHEK Mohamed eisa\n* Shehryar\n* Wael Ben Younes\n* Santosh Ray\n* Juana Attieh\n* Nadim Karam\n* DubaistakePool\n* HAWAK Pool\n* LALKUL Stake Pools\n</details>\n\n<details>\n  <summary><strong>2023 Williamsburg, New York Workshop (25/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Williamsburg, New York on June 25th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Pi\n* Joseph\n* Skyler\n* Forrest\n* Gabriel\n* Newman\n</details>\n\n<details>\n  <summary><strong>2023 Lagos, Nigeria Workshop (28/06)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Lagos, Nigeria on June 28th 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Jonah Benson\n* Augusta\n* Ubio Obu\n* Olumide Hrosuosegbe\n* Veralyn Chinenye\n* Ona Ohimer\n* William Ese\n* Ruth Usoro\n* William P\n* Esther Simi\n* Daniel Effiom\n* Akinkurai Toluwalase\n</details>\n\n<details>\n  <summary><strong>2023 Sao Paulo, Brazil Workshop (01/07)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Sao Paulo, Brazil on July 1st 2023 for their valuable contributions to this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Otávio Lima\n* Rodrigo Pacini\n* Maria Carmo\n* Cauê Chianca\n* Daniela Alves\n* Jose Lins Dias\n* Felipe Barcelos\n* Rosana Melo\n* Johnny Oliveira\n* Lucas Ravacci\n* Cristofer Ramos\n* Weslei Menck\n* Leandro Tsutsumi\n* Izaias Pessoa\n* Gabriel Melo\n* Yuri Nabeshima\n* Alexandre Fernandes\n* Vinicius Ferreiro\n* Lucas Fernandes\n* Alessandro Benicio\n* Mario Cielho\n* Lory Fernandes Lima\n* Larissa Nogueira\n* Latam Cardano Community\n</details>\n\n<details>\n  <summary><strong>2023 Brazil Virtual Workshop (04/07)</strong></summary>\n\nIn addition, we would like to thank all the attendees of the workshop that was held in Brazil on July 4th 2023 for their valuable contributions\nto this CIP, and for their active championing of Cardano's vision for minimal viable governance.  These include:\n\n* Lincon Vidal\n* Thiago da Silva Nunes\n* Rodrigo Pacini\n* Livia Corcino de Albuquerque\n* Cauê Chianca\n* Otávio Lima\n</details>\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)\n\n[^1]: A formal description of the current rules for governance actions is given in the [Shelley ledger specification](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/shelley-ledger.pdf).\n\n    - For protocol parameter changes (including hard forks), the `PPUP` transition rule (Figure 13) describes how protocol parameter updates are processed, and the `NEWPP` transition rule (Figure 43) describes how changes to protocol parameters are enacted.\n\n    - For funds transfers, the `DELEG` transition rule (Figure 24) describes how MIR certificates are processed, and the `MIR` transition rule (Figure 55) describes how treasury and reserve movements are enacted.\n\n    > **Note**\n    > The capabilities of the `MIR` transition rule were expanded in the [Alonzo ledger specification](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/alonzo-ledger.pdf)\n\n\n[^2]: There are many varying definitions of the term \"hard fork\" in the blockchain industry. Hard forks typically refer to non-backwards compatible updates of a network. In Cardano, we formalize the definition slightly more by calling any upgrade that would lead to _more blocks_ being validated a \"hard fork\" and force nodes to comply with the new protocol version, effectively obsoleting nodes that are unable to handle the upgrade.\n\n[^3]: This is the definition used in \"active stake\" for stake delegation to stake pools, see Section 17.1, Total stake calculation, of the [Shelley ledger specification](https://github.com/input-output-hk/cardano-ledger/releases/latest/download/shelley-ledger.pdf).\n"
  },
  {
    "path": "CIP-1852/CIP-1852.md",
    "content": "Moved to [CIP-1852/README.md](./README.md).\n"
  },
  {
    "path": "CIP-1852/README.md",
    "content": "---\nCIP: 1852\nTitle: HD (Hierarchy for Deterministic) Wallets for Cardano\nStatus: Active\nCategory: Wallets\nAuthors:\n  - Sebastien Guillemot <sebastien@emurgo.io>\n  - Matthias Benkort <matthias.benkort@cardanofoundation.org>\nImplementors: N/A\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/33\n  - https://forum.cardano.org/t/cip1852-hd-wallets-for-cardano/41740\nCreated: 2019-10-28\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nCardano extends the [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) by adding new chains used for different purposes. This document outlines how key derivation is done and acts as a registry for different chains used by Cardano wallets.\n\n## Motivation: why is this CIP necessary?\n\nFor Cardano, we use a new purpose field `1852'` instead of `44'` like in BIP44. There are three main reasons for this:\n\n1) During the Byron-era, `44'` was used. Since Byron wallets use a different algorithm for generating addresses from public keys, using a different purpose type allows software to easily know which address generation algorithm given just the derivation path (ex: given `m / 44' / 1815' / 0' / 0 / 0`, wallet software would know to handle this as a Byron-era wallet and not a Shelley-era wallet).\n2) Using a new purpose helps bring attention to the fact Cardano is using `BIP32-Ed25519` and not standard `BIP32`.\n3) Using a new purpose allows us to extend this registry to include more Cardano-specific functionality in the future\n\n`1852` was chosen as it is the year of death of Ada Lovelace (following the fact that the `coin_type` value for Cardano is `1815` for her year of birth)\n\n## Specification\n\nUsing `1852'` as the purpose field, we defined the following derivation path:\n\n```\nm / purpose' / coin_type' / account' / role / index\n```\n\nExample: `m / 1852' / 1815' / 0' / 0 / 0`\n\nHere, `role` can be the following\n\n| Name                              | Value | Description\n| ---                               | ----- | ------------\n| External chain                    | `0`   | Same as defined in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)\n| Internal chain                    | `1`   | Same as defined in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)\n| Staking Key                       | `2`   | See [CIP-0011](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0011/README.md)\n| DRep Key                          | `3`   | See [CIP-0105](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/README.md)\n| Constitutional Committee Cold Key | `4`   | See [CIP-0105](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/README.md)\n| Constitutional Committee Hot Key  | `5`   | See [CIP-0105](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/README.md)\n\nWallets **MUST** implement this new scheme using the master node derivation algorithm from Icarus with sequential addressing (see [CIP3](https://cips.cardano.org/cips/cip3) for more information)\n\n## Rationale: how does this CIP achieve its goals?\n\n### Derivation style\n\nCardano does not use [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) but actually uses [BIP32-Ed25519](https://input-output-hk.github.io/adrestia/static/Ed25519_BIP.pdf). The `-Ed25519` suffix is often dropped in practice (ex: we say the Byron release of Cardano supports [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) but in reality this is BIP44-Ed25519).\n\nThe Byron implementation of Cardano uses `purpose = 44'` (note: this was already a slight abuse of notation because Cardano implements BIP44-Ed25519 and not standard BIP44).\n\nThere are two (incompatible) implementations of BIP32-Ed25519 in Cardano:\n\n1) HD Random (notably used initially in Daedalus)\n2) HD Sequential (notably used initially in Icarus)\n\nThe difference is explained in more detail in [CIP-0003](../CIP-0003).\n\n### Future extensions\n\nAs a general pattern, new wallet schemes should use a different purpose if they intend to piggy-back on the same structure but for a different use-case (see for instance [CIP-1854](../CIP-1854)).\n\nThe `role` can however be extending with new roles so long as they have no overlapping semantic with existing roles. If they do, then they likely fall into the first category of extension and would better be done via a new purpose.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Standardisation of this derivation path among all wallets as of the Shelley ledger era.\n\n### Implementation Plan\n\n- [x] Common agreement on the above Motivation, Rationale and Specification during the planning of Cardano's Shelley release.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CIP-1853/CIP-1853.md",
    "content": "Moved to [CIP-1853/README.md](./README.md).\n"
  },
  {
    "path": "CIP-1853/README.md",
    "content": "---\nCIP: 1853\nTitle: HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano\nStatus: Proposed\nCategory: Wallets\nAuthors:\n  - Rafael Korbas <rafael.korbas@vacuumlabs.com>\nImplementors:\n    - Vacuum Labs <https://vacuumlabs.com/>\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/56\n  - https://forum.cardano.org/t/stake-pool-cold-keys-hd-derivation/43360\nCreated: 2020-12-14\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\n[CIP-1852] establishes how Shelley-era hierarchical deterministic (HD) wallets should derive their keys. This document is a follow-up of this CIP specifying how stake pool cold keys should be derived.\n\n## Motivation: why is this CIP necessary?\n\n(Hierarchical) deterministic derivation of stake pool cold keys enables their restorability from a seed and most importantly, their management on hardware wallet devices. This in turn mitigates man-in-the middle attacks to which pool operators would otherwise be vulnerable if they managed their stake pool cold keys on a device not specifically hardened against alteration of the data to be signed/serialized without operator's explicit consent.\n\n## Specification\n\nUsing `1853'` as the purpose field, we define the following derivation path structure for stake pool cold keys:\n\n```\nm / purpose' / coin_type' / usecase' / cold_key_index'\n```\n\nExample: `m / 1853' / 1815' / 0' / 0'`\n\nHere the `usecase` is currently fixed to `0'`.\n\nGiven that stake pool cold keys are cryptographically the same as wallet keys already covered in CIP-1852, the master node and subsequent child keys derivation **MUST** be implemented in the same way as specified for wallets in CIP-1852.\n\n## Rationale: how does this CIP achieve its goals?\n\n### Why introducing a new purpose?\n\nStake pools are not wallets and the core concept of \"accounts\" is not applicable to them, nor are they supposed to be related to a user's wallet in any meaningful way. Therefore treating stake pool cold keys as another \"chain\" within CIP-1852 specification would rather be a deviation from CIP-1852 than its logical extension. Hence we establish a separate purpose and path structure for stake pool cold keys, having their specifics and differences from standard \"wallet\" keys in mind.\n\n### Why keeping `coin_type` in the path?\n\n`coin_type` is kept in order to remain consistent with the \"parent\" CIP-1852 and also to leave space for the possibility that some Cardano hard-fork/clone in the future would reuse this specification to derive their own stake pool cold keys.\n\n### `usecase` field\n\nSimilarly as we have the `chain` path component in CIP-1852 paths for different types of wallet keys, it's plausible that in the future, there could be multiple varieties of stake pools. One such example of a possible future extension of this CIP could be pools managed by a group of operators instead of a single operator, for which a separate set of stake pool cold keys, driven by this parameter, could make sense both from logical and security perspective.\n\n### Hardened derivation at `cold_key_index`\n\nEach stake pool is supposed to be managed separately so there is currently no incentive to connect them via a parent public key.\n\n### Hardened derivation at `usecase`\n\nWe chose hardened derivation at the usecase index as there is no incentive to mix the stake pool cold keys with other potential usecases and if there was such incentive, it would most likely be more appropriate to create a separate usecase/purpose for that.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] Standardisation of this derivation path among three wallets as of the Shelley ledger era.\n    - Ledger App Cardano <https://github.com/LedgerHQ/app-cardano>\n\n### Implementation Plan\n\n- [x] Common agreement on the above Motivation, Rationale and Specification during the planning of Cardano's Shelley release.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[CIP-1852]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852\n"
  },
  {
    "path": "CIP-1854/CIP-1854.md",
    "content": "Moved to [CIP-1854/README.md](./README.md).\n"
  },
  {
    "path": "CIP-1854/README.md",
    "content": "---\nCIP: 1854\nTitle: Multi-signatures HD Wallets\nStatus: Active\nCategory: Wallets\nAuthors:\n  - Matthias Benkort <matthias.benkort@cardanofoundation.org>\n  - Pawel Jakubas <pawel.jakubas@cardanofoundation.org>\nImplementors:\n  - Round Table wallet\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/69\nCreated: 2021-02-23\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis document describes how to realize multi-parties transactions in Cardano. It is defined as an alternative to [CIP-1852] for Cardano HD wallets. This specification does not cover the transport and sharing of partially signed transactions which is / will be covered in another document.\n\n## Motivation: why is this CIP necessary?\n\n### Overview \n\nTerm     | Definition\n---      | ---\nHD       | Hierarchical Deterministic, refers to wallets as described in [BIP-0032].\nMultisig | Shorthand for Multi-party signature scheme. \n\nMultisig wallets are Cardano wallets capable of providing and tracking keys involved in multi-parties transactions. Such transactions are used to move funds from addresses where (typically) more than one user must sign transactions for its funds to be spent. A simple analogue is a joint bank account where two account holders must approve withdrawals from the account. Cardano has native support for multi-signature schemes: funds at a multi-signature script address are owned by a monetary script, which specifies one or more combinations of cryptographic signatures which must be present to unlock funds at the address (see the [Formal Ledger Spec, Figure 4: Multi-signature via Native Scripts][ledger-spec.pdf]). In a similar fashion, Cardano multisig scripts can also be used to capture stake rights on a particular address, shared between different parties.\n\nIn the Shelley era, Cardano offers six (partially overlapping) primitives for constructing monetary scripts which are summarized as the following grammar:\n\n```abnf\nSCRIPT \n  = SIGNATURE KEY-HASH\n  | ALL-OF 1*SCRIPT\n  | ANY-OF 1*SCRIPT\n  | N-OF UINT 1*SCRIPT\n  | AFTER SLOT-NO\n  | BEFORE SLOT-NO\n\nKEY-HASH = 28OCTET\n\nSLOT-NO = UINT\n```\n\nScripts are thereby recursive structures which can contain scripts themselves. For example, a joint account between two parties which specifies that any of the two members can spend from it would be defined in pseudo-code as:\n\n```abnf\nJOINT-ACCOUNT := ANY-OF [SIGNATURE key-hash#1, SIGNATURE key-hash#2]\n```\n\nIn order to spend from such script, one would have to provide a witness showing ownership of the key associated with either of `key-hash#1` or `key-hash#2` (or possibly, both).\n\n### Creation of a Multisig Script/Address\n\nThe creation of a multisig address will not be covered in this document. Such addresses are described in [Shelley design specification - section 3.2 - Addresses and Credentials][delegation_design.pdf] and are obtained by serializing and hashing a multisig script. This functionality is assumed to be available through existing tooling or piece of software in a variety of ways.\n\n### Spending From a Multisig Address\n\nIn order to spend from a multisig address, one must provide a special witness in the spending transaction called a \"multisig witness\". Such witness must be the exact script used as an input for creating the hash part of the multisig address. Then, any additional required verification key signatures specified by the script must be provided as separate verification key witnesses (i.e. signatures of the hashed transaction body for each signing key).\n\nThis means that a wallet software has access to the full script to validate and also identify verification key hashes present in transactions, but only does so when funds are being spent from a multisig address! From the Allegra era and beyond, it is also possible to include script pre-image in transaction auxiliary data. Softwares may use this to communicate scripts ahead of time. \n \n## Specification\n\n### HD Derivation\n\nWe consider the following HD derivation paths similarly to [CIP-1852]:\n\n```\nm / purpose' / coin_type' / account_ix' / role / index\n```\n\nTo associate multi-signature keys to a wallet, we reserve however `purpose=1854'` to distinguish multisig wallets from standard wallets. The coin type remains `coin_type=1815'` to identify Ada as registered in [SLIP-0044]. The account index (`account_ix`) may vary across the whole hardened domain. `role=0` is used to identify payment keys, whereas `role=2` identifies stake keys. `role=1` is left unused for multisig wallets. Finally, the last `index` may vary across the whole soft domain, but according to the following rules:\n\n- Wallet must derive multisig key indexes sequentially, starting from 0 and up to 2^31-1\n- Wallet must prevent the creation of new multisig keys before past keys are seen in an on-chain script.\n- Wallet should yet always provide up-to 20 consecutive unused multisig keys.\n\nWe can summarize the various paths and their respective domain in the following table:\n\n| `purpose` | `coin_type` | `account_ix`       | `role`     | `index`         |\n| ---       | ---         | ---                | ---        | ---             |\n| `1854'`   | `1815'`     | `[2^31 .. 2^32-1]` | `0` or `2` | `[0 .. 2^31-1]` |\n\n#### Examples\n\n- `m/1854’/1815’/0’/0/0`\n- `m/1854’/1815’/0’/2/14`\n- `m/1854’/1815’/0’/2/42`\n- `m/1854’/1815’/0’/0/1337`\n\n### User-facing encoding\n\nMulti-signatures payment verification and signing keys (`role=0`) with chain code should be presented bech32-encoded using `addr_shared_xvk` and `addr_shared_xsk` prefixes respectively, as specified in [CIP-5]. When represented without chain-code, `addr_shared_vk` and `addr_shared_sk` should be used instead.\n\nSimilarly we use `stake_shared_xvk`, `stake_shared_xsk`, `stake_shared_vk` and `stake_shared_sk` for multi-signatures stake verification and signing keys (`role=2`).\n\n#### Examples\n\n```yaml=\n- base16: | \n    179be1ac9e63abb5fe4666df03007b07\n    33a3b63cdd08cd3635b8d364e16aaf26\n    49856f2ba513786afdbe5c7a07565c02\n    9ba7a4290d20aa3c80ecc1835841ed78\n  bech32:\n    addr_shared_xvk1z7d7rty7vw4mtljxvm0sxqrmque68d3um5yv6d34hrfkfct24unynpt09wj3x7r2lkl9c7s82ewq9xa85s5s6g928jqwesvrtpq767qs66fnu\n```\n\n### Multisig Wallets\n\n#### Templates\n\nTo define a multisig wallet, participants must provide: \n\n- A payment script template.\n- A delegation script template (possibly null).\n- All the cosigners role=0 and role=2 (4th level) public keys involved in templates. Alternatively, cosigners may also share their account public key (3rd level) directly. \n\nA script template is a script where key hashes are replaced by a cosigner tag which captures the relation between the cosigners. \n\n> **NOTE 1**: How an application represents tags is an implementation detail. Only the instantiated script appears on the blockchain. \n>\n> **NOTE 2**: As a reminder, a Cardano address is made of two parts: a payment part and a delegation part. The latter is optional and so is the delegation script template. If none is provided then the address does not contain any delegation part. Wallet softwares should decide whether they want to allow or forbid this but this proposal does not take position. \n\nThere must be a strict one-to-one mapping between the tags used in the template and the cosigner account keys provided. When a new address is needed, the software must instantiate the script by using keys derived from the relevant account. To instantiate a script from a template, a wallet software must abide by the following rules:\n\n1. When deriving new keys, the same indexes must be used for all account involved in the template.\n2. If a tag appears in multiple place in the script, then the same index must also be used for all instances of that tag.\n\n(1) and (2) implies that a given instance of a script is associated to one and only one derivation index. \n\n> **NOTE 3**: Wallet software should not authorize users to update the script templates after an address has been used. \n\nFor example, considering the joint-account example from above, an example of payment template can simply be:\n\n```abnf\nJOINT-ACCOUNT-TEMPLATE := ANY-OF \n    [ SIGNATURE cosigner#1\n    , SIGNATURE cosigner#2\n    ]\n```\n\nand an instantiation of that template for e.g. an index equals to 1 could be:\n\n```abnf\nJOINT-ACCOUNT := ANY-OF \n    [ SIGNATURE addr_shared_vkh1rcw47lrnczf8d4gt7d8vp6z95l8effslyejszez7069z6fa469v\n    , SIGNATURE addr_shared_vkh1f8vd0s83hr7y2r96gct785e4d0d77ep9jn5wqfa4d6r4kqzxd65\n    ]\n```\n\nKeys used in the instantiated template all come from the same derivation index for all cosigners. This allows all wallets to easily find back what indexes other cosigners used to derive a particular key (the same as they use for a particular address). \n\n### Sending Transactions\n\nIn case the wallet needs a change address internally, it must use the smallest unused indexes known, in ascending order. An index is considered unused if there's no transaction in the ledger with a script using its corresponding key hash. When constructing a transaction, a wallet should use UTxOs associated with script addresses only (hybrid transactions using non-shared UTxOs are forbidden). \n\nOnce constructed, a transaction must be signed with all required private keys from the initiator. The initiator must also include all instances of scripts necessary (typically one per input) and then either broadcast the transaction to its cosigners or submits it to the network if valid. The mean by which the transaction is broadcast is out of the scope of this specification. \n\nUpon receiving a partially signed transaction, wallets must for each input:\n\n1. Find the script associated with the input in the transaction witnesses\n2. Verify that the script matches the wallet's template(s)\n3. Identify the derivation index used to instantiate the script from its known keys\n4. Derive the public keys of each other co-signers from that same derivation index and the cosigners parent keys\n5. Verify that there's at least one signature from another co-signer\n6. Verify all signatures provided by co-signers with their associated public keys\n\n> **NOTE** The step (5) is crucial and implies that wallets initiating transactions have to sign them before broadcasting them as a proof of provenance. Otherwise it is possible for attackers to broadcast a \"fake\" transaction to all cosigners who may not pay attention to its details. \n\n\nWhen valid, the wallet should prompt the user for signing. The transaction can be submitted by any of the cosigners who deems it valid (it could be that only a subset of the cosigners is required to sign). Several cosigners may submit the transaction concurrently without issue, the ledger will ensure that only one transaction eventually get through.\n\n> **NOTE:** The management of change addresses is an implementation detail of the wallet so long as all change addresses abide by the rules described earlier in this section. A wallet may choose to generate a single change address per transaction, while another may chose to generate many. \n\n### Foreign Script Discovery \n\nWallets should warn users when discovering known keys in scripts which non-matching templates. Such addresses should not be included as part of the wallet's UTxO and should be treated as anomalies in the wallet. As a matter of facts, everything described in this document is a mere convention between wallets. There's however nothing at the protocol level that enforces that this specification is followed. It is therefore very much possible for advanced users to use their multisig keys in scripts that are different from the template. So long as indexes used are discoverable by the wallet, then such scripts are also discoverable. \n\nHowever, because such scripts / addresses would not have been created by the wallet, they are considered not being part of the it altogether and would not count towards the wallet's balance. Software should however as much as possible alert users about the existence of such anomalies. \n\n### Example\n\nFor example, if Alice and Bob wants to share a wallet by requiring a signature from each other on every payment, they can define the following payment script template:\n\n```\nALL-OF (SIGNATURE alice) (SIGNATURE bob) \n```\n\nAfter exchanging their corresponding public keys, both wallets should be initialized and present to Alice and Bob exactly `20` identical addresses, where each address is associated with exactly one derivation index. The first address will use one key from Alice's wallet at path `m/1854’/1815’/0’/0/0` and a key from Bob's at exactly the same path. The next address will use keys at path `m/1854’/1815’/0’/0/1` and so forth. \n\nWhen Alice initiates a transaction from this wallet, she'll construct the transaction body, sign it with her corresponding private key, include an instance of the script as witness and broadcast the transaction to Bob via Telegram. Upon reception, Bob is able to verify that the transaction was indeed signed by Alice using her private key at index #0 (Bob has indeed Alice's parent public key in its possession and is therefore able to derive a child key at index #0 to verify the signature on the transaction). Bob proceeds with the payment by signing the transaction in return and submitting it. \n\n## Rationale: how does this CIP achieve its goals?\n\n- Multisig keys are scoped to accounts, which allows wallet's owners to separate their activity easily.\n\n- We use a different purpose for mainly two reasons:\n\n  - It prevents mixing up standard wallets with shared wallets, which would be undesirable and become rapidly a nightmare for software to maintain. In particular, it also makes it possible to share an intermediary account key with co-signers without disclosing any information about non-shared keys in our wallet. \n\n  - It makes it easier to extend any of the 1852' or 1854' in a similar manner. The addition of a new role can be done in both scheme very consistently. \n\n  Using a different purpose also fits well the use-case on hardware wallets who can still rely on a single root seed to manage many types of wallets. \n\n- One or many keys can be created from a parent public key via soft-derivation. This allows participant to easily share their multisig keys to participate in a multisig script without having to fetch for their hardware device. The device is still required for signing.\n\n### Related Work\n\nDescription                                  | Link\n---                                          | ---\nBIP-0032 - HD Wallets                        | https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki\nCIP-5 - Common Bech32 Prefixes               | https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005\nCIP-1852 - Cardano HD Wallets                | https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852\nA Formal Specification of the Cardano Ledger | https://github.com/input-output-hk/cardano-ledger/releases/latest/download/shelley-ledger.pdf\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Document at least one case of a community adopted CIP-1852 compliant multisig wallet:\n  - [x] [Round Table wallet](https://round-table.vercel.app)\n\n### Implementation Plan\n\n- [x] Community developed reference implementation: [github:ADAOcommunity/round-table](https://github.com/ADAOcommunity/round-table)\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[rfc8610]: https://tools.ietf.org/html/rfc8610\n[rfc8152]: https://tools.ietf.org/html/rfc8152\n[BIP-0032]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki\n[CIP-5]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005\n[CIP-1852]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852\n[CIP-11]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0011\n[ledger-spec.pdf]: https://github.com/input-output-hk/cardano-ledger/releases/latest/download/shelley-ledger.pdf\n[SLIP-0044]: https://github.com/satoshilabs/slips/blob/master/slip-0044.md\n"
  },
  {
    "path": "CIP-1855/CIP-1855.md",
    "content": "Moved to [CIP-1855/README.md](./README.md).\n"
  },
  {
    "path": "CIP-1855/README.md",
    "content": "---\nCIP: 1855\nTitle: Forging policy keys for HD Wallets\nStatus: Proposed\nCategory: Wallets\nAuthors:\n  - Samuel Leathers <samuel.leathers@iohk.io>\n  - John Lotoski <john.lotoski@iohk.io>\n  - Michael Bishop <michael.bishop@iohk.io>\n  - David Arnold <david.arnold@iohk.io>\nImplementors: []\nDiscussions:\n  - https://github.com/cardano-foundation/CIPs/pull/96\n  - https://github.com/cardano-foundation/CIPs/pull/194\nCreated: 2021-06-02\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThis document describes how to derive forging policy keys used for minting/burning tokens.\n\n## Motivation: why is this CIP necessary?\n\nForging tokens is derived from a script policy. The script policy includes hashes of keys needed to forge new tokens and must be witnessed by these keys in such a way as the script stipulates.\nThis CIP defines the derivation path at wich parties are expected to derive such keys.\n\n## Specification\n\nTerm     | Definition\n---      | ---\nHD       | Hierarchical Deterministic, refers to wallets as described in [BIP-0032].\n\n### HD Derivation\n\nWe consider the following HD derivation paths similarly to [CIP-1852]:\n\n```\nm / purpose' / coin_type' / policy_ix'\n```\n\n\nTo associate policy keys to a wallet, we reserve however `purpose=1855'` for policy keys for forging tokens. The coin type remains `coin_type=1815'` to identify Ada as registered in [SLIP-0044]. We use a hardened index for each policy key as derivation is not needed.\n\nWe can summarize the various paths and their respective domain in the following table:\n\n| `purpose` | `coin_type` | `policy_ix`         |\n| ---       | ---         | ---                 |\n| `1855'`   | `1815'`     | `[2^31 .. 2^32-1]` |\n\n### CIP-0005 prefixes\n\nTo distinguish such keys & derived material in the human readable prefix of the bech32 representation, we introduce the following prefixes for insertion into CIP-0005:\n\n#### Keys\n\n| Prefix             | Meaning                                            | Contents                           |\n| ---                | ---                                                | ---                                |\n| `policy_sk`        | CIP-1855's policy private key                      | Ed25519 private key                |\n| `policy_vk`        | CIP-1855's policy public key                       | Ed25519 public key                 |\n\n#### Hashes\n\n| Prefix             | Meaning                                            | Contents                                               |\n| ---                | ---                                                | ---                                                    |\n| `policy_vkh`       | CIP-1855's Policy verification key hash            | blake2b\\_224 digest of a policy verification key       |\n\n### Examples\n\n- `m/1855’/1815’/0’`\n- `m/1855’/1815’/1’`\n- `m/1855’/1815’/2’`\n\n## Rationale: how does this CIP achieve its goals?\n\n- ERC20 Converter IOHK is developing needs to keep track of policy keys. Rather than having randomly generated policy keys, a policy key can be associated with a mnemonic which is easier to backup.\n- A 3rd party may want to have multiple tokens tied to same mnemonic, so we allow an index to specify the token.\n- Contrary to CIP 1852, we don't use the `role` and `index` levels of the derivation path, since index is expressed at the 3rd level and no roles for policy signing keys are currently anticipated.\n\n- No prefixes are defined for extended keys, since currently this CIP does not define further derivations.\n\n- We use a different purpose for mainly two reasons:\n\n  - It prevents mixing up standard wallets with policy keys used for forging.\n\n  - Using a different purpose also fits well the use-case on hardware wallets who can still rely on a single root seed to manage many types of wallets. \n\n### Related Work\n\nDescription                                  | Link\n---                                          | ---\nBIP-0032 - HD Wallets                        | https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki\nCIP-5 - Common Bech32 Prefixes               | https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005\nCIP-1852 - Cardano HD Wallets                | https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852\nA Formal Specification of the Cardano Ledger | https://github.com/input-output-hk/cardano-ledger/releases/latest/download/shelley-ledger.pdf\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [ ] Standardisation of this derivation path among three wallets as of the Shelley ledger era.\n\n### Implementation Plan\n\n- [x] Common agreement on the above Motivation, Rationale and Specification during the planning of Cardano's Shelley release.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[BIP-0032]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki\n[CIP-0005]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005\n[CIP-1852]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852\n[ledger-spec.pdf]: https://github.com/input-output-hk/cardano-ledger/releases/latest/download/shelley-ledger.pdf\n[SLIP-0044]: https://github.com/satoshilabs/slips/blob/master/slip-0044.md\n"
  },
  {
    "path": "CIP-9999/README.md",
    "content": "---\nCIP: 9999\nTitle: Cardano Problem Statements\nCategory: Meta\nStatus: Active\nAuthors:\n    - Matthias Benkort <matthias.benkort@cardanofoundation.org>\n    - Michael Peyton Jones <michael.peyton-jones@iohk.io>\nImplementors: N/A\nDiscussions:\n    - https://github.com/cardano-foundation/CIPs/pulls/366\nCreated: 2022-10-14\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nA Cardano Problem Statement (CPS) is a formalized document for the Cardano ecosystem and the name of the process by which such documents are produced and listed. CPSs are meant to complement CIPs and live side-by-side in the CIP repository as first-class citizens.\n\n> [!NOTE]\n> Read this CIP's number as \"CIP minus 1\" (in [tens' complement](https://en.wikipedia.org/wiki/Method_of_complements#Decimal_example))\n\n## Motivation: why is this CIP necessary?\n\nA common friction point regarding complex CIPs is how their main problems are stated. For example, the _'Motivation'_ section in CIPs is sometimes not sufficient -- or simply underused -- to describe the various aspects of a problem, its scope, and its constraints in the necessary detail. This lack of clarity leads, in the end, to poorly defined issues and unfruitful debates amongst participants who understand problems differently.\n\nThe introduction of the **Cardano Problem Statements** (CPSs) addresses this gap by defining a formal template and structure around the description of problems. CPSs are meant to replace the more elaborate motivation of complex CIPs. However, they may also exist on their own as requests for proposals from ecosystem actors who've identified a problem but are yet to find any suitable solution.\n\nOver time, CPSs may complement grant systems that want to target well-known problems of the ecosystem; they can, for example, serve as the foundation for RFP (Request For Proposals) documents. We hope they may also help make some discussions more fluid by capturing a problem and its various constraints well.\n\n## Specification\n\n### CPS\n\n#### Structure\n\nCPSs are, first and foremost, documents that capture a problem and a set of constraints and hypotheses. Documents are [Markdown][Markdown] files with a front matter _Preamble_ and pre-defined sections. CPS authors must abide by the general structure, though they are free to organize each section as they see fit.\n\nThe structure of a CPS file is summarized in the table below:\n\nName               | Description\n---                | ---\nPreamble           | Headers containing metadata about the CPS ([see below](#header-preamble)).\nAbstract           | A short (\\~200 word) description of the target goals and the technical obstacles to those goals.\nProblem            | A more detailed description of the problem and its context. This section should explain what motivates the writing of the CPS document.\nUse cases          | A concrete set of examples written from a user's perspective, describing what and why they are trying to do. When they exist, this section should give a sense of the current alternatives and highlight why they are unsuitable.\nGoals              | A list of goals and non-goals a project is pursuing, ranked by importance. These goals should help understand the design space for the solution and what the underlying project is ultimately trying to achieve. <br/><br/>Goals may also contain requirements for the project. For example, they may include anything from a deadline to a budget (in terms of complexity or time) to security concerns. <br/><br/>Finally, goals may also serve as evaluation metrics to assess how good a proposed solution is.\nOpen Questions     | A set of questions to which any proposed solution should find an answer. Questions should help guide solutions design by highlighting some foreseen vulnerabilities or design flaws. Solutions in the form of CIP should thereby include these questions as part of their _'Rationale'_ section and provide an argued answer to each.\n_optional sections_| If necessary, these sections may also be included in any order:<br/>**References**<br/>**Appendices**<br/>**Acknowledgements**<br>Do not add material in an optional section if it pertains to one of the standard sections.\nCopyright                                       | The CPS must be explicitly licensed under acceptable copyright terms (see [Licensing](#licensing)).\n\n##### Header preamble\n\nEach CIP must begin with a YAML key:value style header preamble (also known as 'front matter data'), preceded and followed by three hyphens (`---`).\n\nField                | Description\n---                  | ---\n`CPS`                | CPS number (without leading 0), or \"\\?\" before being assigned\n`Title`              | A succinct and descriptive title\n`Category`           | One registered or well-known category covering one area of the ecosystem.\n`Status`             | Open \\| Solved \\| Inactive (..._reason_...)\n`Authors`            | A list of authors' real names and email addresses (e.g. John Doe <john.doe@email.domain>)\n`Proposed Solutions` | A list of labelled CIPs addressing the problem, if any\n`Discussions`        | A list of labelled links where major technical discussions regarding this CPS happened. Links should include any discussion before submission, a link to the pull request that created the CPS, and any pull request that modifies it.\n`Created`            | Date created on, in ISO 8601 (YYYY-MM-DD) format\n`License`            | Abbreviation of an approved license(s)\n\nFor example:\n\n```yaml\n---\nCPS: 1\nTitle: The Blockchain Trilemma\nCategory: Consensus\nStatus: Open\nAuthors:\n    - Alice <alice@domain.org>\n    - Bob <bob@domain.org>\nProposed Solutions:\n    - CIP-1234 | Solve the Trilemma: https://github.com/cardano-foundation/CIPs/tree/master/CIP-1234\nDiscussions:\n    - Forum discussion: https://forum.cardano.org/t/solving-the-blockchain-trilemma/107720\n    - Original pull request: https://github.com/cardano-foundation/cips/pulls/9999\nCreated: 2009-02-14\nLicense: CC-BY-4.0\n---\n```\n\n> **Note** A reference template is available in [.github/CPS-TEMPLATE.md][CPS-TEMPLATE.md]\n\n##### Repository Organization\n\nA CPS must be stored in a specific folder named after its number and in a file called `README.md`. Before a number is assigned, use `????` as a placeholder name (thus naming new folders as `CPS-????`). After a number has been assigned, rename the folder.\n\nAdditional supporting files (such as diagrams, binary specifications, dialect grammars, JSON schemas etc.) may be added to the CPS's folder under freely chosen names.\n\nFor example:\n\n```\nCPS-0001\n├── README.md\n└── requirements.toml\n```\n\n#### Statuses\n\nFrom its creation onwards, a problem statement evolves around the following statuses.\n\nStatus       | Description\n---          | ---\nOpen         | Any problem statement that is fully formulated but for which there still exists no solution that meets its goals. Problems that are only partially solved shall remain _'Open'_ and list proposed solutions so far in their header's preamble.\nSolved       | Problems for which a complete solution has been found[^1] and implemented. When solved via one or multiple CIPs, the solved status should indicate it as such: `Solved: by <CIP-XXXX>[,<CIP-YYYY>,...]`.\nInactive    | The statement is deemed obsolete or withdrawn for another reason. A short reason must be given between parentheses. For example: `Inactive (..._reason_...).\n\n> [!NOTE]\n> There is no \"draft\" status: a proposal which has not been merged (and hence exists in a PR) is a draft CPS. Draft CPSs should include the status they aim for on acceptance, typically but not always; this will be _'Open'_.\n\n#### Categories\n\nAs defined in [CIP-0001][].\n\n#### Licensing\n\nCPSs are licensed in the public domain. More so, they must be licensed under one of the following licenses. Each new CPS must identify at least one acceptable license in its preamble. In addition, each license must be referenced by its respective abbreviation below in the _\"Copyright\"_ section.\n\n| Purpose             | Recommended License                                                                    |\n| ---                 | ---                                                                                    |\n| For software / code | Apache-2.0 - [Apache License, version 2.0][Apache-2.0]                                 |\n| For documentation   | CC-BY-4.0 - [Creative Commons Attribution 4.0 International Public License][CC-BY-4.0] |\n\n> [!WARNING]\n> All licenses not explicitly included in the above lists are not acceptable terms for a Cardano Problem Statement unless a later CIP extends this one to add them.\n\n### The CPS Process\n\n#### 1. Early stages (same as CIP-0001)\n\n##### 1.a. Authors open pull requests with their problem statement [(as defined in CIP-0001)](https://cips.cardano.org/cips/cip1#authors-a-open-pull-requests)\n\n##### 1.b. Authors seek feedback [(as defined in CIP-0001)](https://cips.cardano.org/cips/cip1#authors-seek-feedback)\n\n#### 2. Editors' role (same as CIP-0001)\n\n##### 2.a. Triage in bi-weekly meetings [(as defined in CIP-0001)](https://cips.cardano.org/cips/cip1##triage-in-bi--weekly-meetings)\n\n##### 2.b. Reviews [(as defined in CIP-0001)](https://cips.cardano.org/cips/cip1#reviews)\n\n#### 3. Merging CPSs in the repository\n\nA statement must be well-formulated (i.e. unambiguous) and demonstrate an existing problem (for which use cases exist with no suitable alternatives). When related to a current project, the problem statement must also have been acknowledged by its respective project maintainers. In some cases, problem statements may be written after the facts and be merged directly as _'Solved'_ should they document in more depth what motivated an existing solution.\n\nProblem statements deemed unclear, for which alternatives exist with no significant drawbacks or establish unrealistic goals, shall be rejected (i.e. pull request closed without merge) with justifications or withdrawn by their authors.\n\nSimilarly, problems that appear abandoned by their authors shall also be rejected until resurrected by their authors or another community member.\n\n##### 4. Actors of the ecosystem design and work on possible solutions\n\nOnce merged, authors, project maintainers, or any other ecosystem actors may propose solutions addressing the problem in the form of CIP. They add their CIP to the _'Proposed Solutions'_ field in the CPS' _'Preamble'_ once a solution has been fully implemented and reaches the goals fixed in the original statement.\n\nOf course, a solution may only partially address a problem. In this case, one can alter the problem statement to incorporate the partial solutions and reflect the remaining issue(s) to solve.\n\n### Editors\n\nAs defined in [CIP-0001][].\n\n## Rationale: how does this CIP achieve its goals?\n\n### Goals\n\nGoals make it easier to assess whether a solution solves a problem. Goals also give a direction for projects to follow and can help navigate the design space. The section is purposely flexible -- which we may want to make more rigid in the future if it is proven hard for authors to articulate their intents. Ideally, goals capture high-level requirements.\n\n### Use Cases\n\nUse cases are essential to understanding a problem and showing that a problem addresses a need. Without use cases, there is, in fact, no problem, and merely disliking a design doesn't make it problematic. A use case is also generally user-driven, which encourages the ecosystem to open a dialogue with users to build a system that is useful to others and not only well-designed for the mere satisfaction of engineers.\n\n### Open Questions\n\nThis section is meant to _save time_, especially for problem statement authors who will likely be the ones who end up reviewing proposed solutions. Open questions allow authors to state upfront elements they have already thought of and that any solution should consider in its design. Moreso, it is an opportunity to mention, for example, security considerations or common pitfalls that solutions should avoid.\n\n## Path to Active\n\n### Acceptance Criteria\n\n- [x] Review this proposal with existing actors of the ecosystem\n- [x] Formulate at least one problem statement following this process\n    - [CPS-0001: Metadata Discoverability & Trust](https://github.com/cardano-foundation/CIPs/pull/371)\n    - [CPS-0002: Pointer Addresses](https://github.com/cardano-foundation/CIPs/pull/374)\n\n### Implementation Plan\n\n- [x] Confirm after repeated cycles of CPS submissions, reviews, and merges that the CPS process is both effective and accessible to the community.\n\n## Copyright\n\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[^1]: A problem may be only _partially solved_, in which case it remains in status _'Open'_. Authors are encouraged to amend the document to explain what part of the problem remains to be solved. Consequently, CPS that are _'Solved'_ are considered fully addressed.\n\n[Apache-2.0]: http://www.apache.org/licenses/LICENSE-2.0\n[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n[CIP-0001]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001\n[CPS-TEMPLATE.md]: https://github.com/cardano-foundation/CIPs/tree/master/.github/CPS-TEMPLATE.md\n[CODE_OWNERS]: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners\n[CPS]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-9999\n[Discussions:editors]: https://github.com/cardano-foundation/CIPs/discussions/new?category=editors\n[Markdown]: https://en.wikipedia.org/wiki/Markdown\n[PullRequest]: https://github.com/cardano-foundation/CIPs/pulls\n[RFC 822]: https://www.ietf.org/rfc/rfc822.txt\n[Repository]: https://github.com/cardano-foundation/CIPs/pulls\n[CoC]: https://github.com/cardano-foundation/CIPs/tree/master/CODE_OF_CONDUCT.md\n[Discord]: https://discord.gg/Jy9YM69Ezf\n"
  },
  {
    "path": "CODE_OF_CONDUCT.md",
    "content": "# Contributor Covenant Code of Conduct\n\n## Our Pledge\n\nIn the interest of fostering an open and welcoming environment, we as\ncontributors and maintainers pledge to making participation in our project and\nour community a harassment-free experience for everyone, regardless of age, body\nsize, disability, ethnicity, sex characteristics, gender identity and expression,\nlevel of experience, education, socio-economic status, nationality, personal\nappearance, race, religion, or sexual identity and orientation.\n\n## Our Standards\n\nExamples of behavior that contributes to creating a positive environment\ninclude:\n\n* Using welcoming and inclusive language\n* Being respectful of differing viewpoints and experiences\n* Gracefully accepting constructive criticism\n* Focusing on what is best for the community\n* Showing empathy towards other community members\n\nExamples of unacceptable behavior by participants include:\n\n* The use of sexualized language or imagery and unwelcome sexual attention or\n advances\n* Trolling, insulting/derogatory comments, and personal or political attacks\n* Public or private harassment\n* Publishing others' private information, such as a physical or electronic\n address, without explicit permission\n* Other conduct which could reasonably be considered inappropriate in a\n professional setting\n\n## Our Responsibilities\n\nProject maintainers are responsible for clarifying the standards of acceptable\nbehavior and are expected to take appropriate and fair corrective action in\nresponse to any instances of unacceptable behavior.\n\nProject maintainers have the right and responsibility to remove, edit, or\nreject comments, commits, code, wiki edits, issues, and other contributions\nthat are not aligned to this Code of Conduct, or to ban temporarily or\npermanently any contributor for other behaviors that they deem inappropriate,\nthreatening, offensive, or harmful.\n\n## Scope\n\nThis Code of Conduct applies both within project spaces and in public spaces\nwhen an individual is representing the project or its community. Examples of\nrepresenting a project or community include using an official project e-mail\naddress, posting via an official social media account, or acting as an appointed\nrepresentative at an online or offline event. Representation of a project may be\nfurther defined and clarified by project maintainers.\n\n## Enforcement\n\nInstances of abusive, harassing, or otherwise unacceptable behavior may be\nreported by contacting the project team at cip@cardanofoundation.org. All\ncomplaints will be reviewed and investigated and will result in a response that\nis deemed necessary and appropriate to the circumstances. The project team is\nobligated to maintain confidentiality with regard to the reporter of an incident.\nFurther details of specific enforcement policies may be posted separately.\n\nProject maintainers who do not follow or enforce the Code of Conduct in good\nfaith may face temporary or permanent repercussions as determined by other\nmembers of the project's leadership.\n\n## Attribution\n\nThis Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,\navailable at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html\n\n[homepage]: https://www.contributor-covenant.org\n\nFor answers to common questions about this code of conduct, see\nhttps://www.contributor-covenant.org/faq\n"
  },
  {
    "path": "CONTRIBUTING",
    "content": "See project Wiki: https://github.com/cardano-foundation/CIPs/wiki\n\nTo view the Wiki offline:\n\n1) git clone https://github.com/cardano-foundation/CIPs.wiki.git\n2) Read Home.md first, then remaining pages in lexicographic order.\n"
  },
  {
    "path": "CPS-0003/README.md",
    "content": "---\nCPS: 3\nTitle: Smart Tokens\nCategory: Tokens\nStatus: Open\nAuthors:\n    - Istvan Szentandrasi <szist@zoeldev.com>\n    - Robert Phair <rphair@cosd.com>\nProposed Solutions:\n    - CIP-0113?: https://github.com/cardano-foundation/CIPs/pull/444\nDiscussions:\n    - Original abandoned pull request (closed): https://github.com/cardano-foundation/CIPs/pull/382\n    - Resuscitate pull request (merged): https://github.com/cardano-foundation/CIPs/pull/947\n    - CIP-0113 | Removed potential implementation (issue): https://github.com/cardano-foundation/CIPs/issues/969\nCreated: 2022-11-20\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThe aim of this problem statement is to raise the issue around the ability to control a native token's lifecycle at more points in time.\nCurrently only forging of the tokens can be controlled, but not interactions with them. Extending the blockchain to support other interactions is non-trivial and might require many tradeoffs.\n\n## Problem\n\nThe Mary era introduced native tokens, that could be minted/burned using native scripts. These native scripts for example could allow defining basic conditions to allow forging like required signatures or time validity range. The native tokens are identified with `policyId` and `assetName`. The `policyId` identifies the \"publisher\" or \"publishers\" while `assetName` can be an arbitrary.\n\nWith the Alonzo era, plutus scripts were introduced. They allowed extending the functionality of the native scripts with more generic logic scoped at the transaction level. The format and shape of native tokens didn't change - the `policyId` became the hash of the plutus scripts pushing the \"publisher\" role responsibility to smart contracts.\n\nSkipping ahead, although Babbage didn't add any additional functionality directly, the addition of reference inputs indirectly opened additional use-cases to the the token's lifecycle. To be specific an example: imagine an decentralized bridge with a wrapped token that gets dynamically minted or burned. As a safeguard they would introduce a global UTxO (e.g. with a datum including signature by a multisig wallet or validity token) controlled by recognized members or governance voting mechanism that includes an `enable` flag. The enable flag could be checked by the wrapped token minting policy through a reference input. When a governance vote would pass, the UTxO datum could be changed and the flag could be set to freeze the token.\n\nEven in the Babbage era, after the token is minted, there is no way to control the token after it leaves a smart-contract environment. Users can freely exchange tokens and transfer among each other. This allows cheaper, more efficient and more open ecosystem. In contrast with this, ERC-20 tokens are smart-contracts that fully control any interaction with a token.\n\nSimilar to how UTxO addresses can be optionally fully controlled by smart-contracts, there could be potential also to optionally control other lifecycle points of a token than just forging on Cardano.\n\n## Use Cases\n\nThere are multiple use-cases that would benefit from having the ability to validate token interactions.\n\nFrom the **NFT space**, having royalties for tokens is currently a social contract where the publisher provides the royalty information while minting the tokens. The marketplaces can choose to honor this information and transfer part of the token sales towards the author. The problem is, this is not enforced and \"black market\" can thrive. As an author of an art NFT, I would like to benefit from any token transfers that involve smart contracts (a marketplace platform).\n\nFrom the **dapp-space**, consider validity and authorization tokens. For example, liquidity pools the liquidity provider token minting can be authorized by a validity token. This token _should_ be fully controlled by the liquidity pool smart contracts. If it were to leak out of the liquidity pool smart contract, it would give the ability to anyone to mint LP tokens and drain liquidity pools of the actual funds (as seen in the Minswap security vulnerability). IF the authorization token was itself controlled by a smart contract, even after it left the liquidity pool, the vulnerability could be avoided.\n\nAnother use-case comes up around **bridged wrapped tokens**. Due to regulations, some publishers might require the ability to freeze or selectively allow specific flow directions for the token at times. These issues were raised also at the `interoperability working group`. Bridges bridging stables from Ethereum would like more control over the wrapped bridged tokens to be in-line with regulations and help with security.\n\nWhen it comes to regulations, also **native stable coins** are another case, where the publisher might want to control the ability to freeze or require authorization with interactions of their tokens.\n\n## Goals\n\nThe first main goal is to **achieve a consensus** if having more control over the tokens is actually something that would be in-line with the values and direction of Cardano. There are multiple tradeoffs from the usability perspective. Having validated lifecycle for tokens would have an impact on all dapps and all wallets.\n\nThe second main goal is **create a CIP** with the technical direction how smart tokens could function. Below is a potential direction and possible issues and roadblocks that would need to be addressed in the CIP.\n\n## Open Questions\n\n1. How to support wallets to start supporting validators?\n1. How would wallets know how to interact with these tokens? - smart contract registry?\n1. Is there a possibility to have a transition period, so users won't have their funds blocked until the wallets start supporting smart tokens?\n1. Can this be achieved without a hard fork?\n1. How to make validator scripts generic enough without impacting costs significantly?\n1. Can we introduce smart tokens without significantly increasing Cardano's attack surface?\n\n## Copyright\n\nThis CPS is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CPS-0005/README.md",
    "content": "---\nCPS: 5\nTitle: Plutus Script Usability\nCategory: Plutus\nStatus: Open\nAuthors:\n  - Michael Peyton Jones <michael.peyton-jones@iohk.io>\nProposed Solutions:\n  - CIP-0038?: https://github.com/cardano-foundation/CIPs/pull/309\n  - CIP-0057: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0057\n  - CIP-0069: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0069\n  - CIP-0087?: https://github.com/cardano-foundation/CIPs/pull/440\nDiscussions:\n  - Original pull request: https://github.com/cardano-foundation/CIPs/pull/497\n  - Developer Experience Working Group: https://github.com/input-output-hk/Developer-Experience-working-group\nCreated: 2023-04-04\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThe EUTXO model in Cardano makes it possible to implement a wide variety of rich and complex applications on top of Cardano.\nHowever, it does not necessarily make it easy, and there are a number of usability issues that make it difficult for both users and automated systems to work with Plutus scripts in particular.\n\n## Problem\n\nThere are a constellation of related issues around using Plutus scripts in practice and sending money to them.\nIn this CPS we restrict ourselves to usability issue with the _base_ experience of using Plutus scripts, i.e. not issues with implementing complex applications on top of Cardano, but issues with the basic actions of creating and spending outputs locked with Plutus scripts.\n\n### 1. Plutus scripts need datums\n\nSending money to Plutus script addresses is harder than to other addresses because of the need for a datum in addition to the address and the value.\nMoreover, the datum is mandatory, and if it is not included, the output will be unspendable.\n\nOn the flip side, many Plutus scripts don’t actually need datums.\nSince they are forced to have one, they have to use a trivial fake datum, which just makes things harder for them.\n\n### 2. It is not possible to know from the address whether a datum is required\n\nPlutus scripts require datums otherwise they are unspendable.\nNative scripts do not require datums.\nBut both Plutus script addresses and native script addresses are represented by “script addresses”.\nSo it’s possible to tell that an address is not a public key address, but not which kind of script address it is.\n\nThat means it’s not possible to know whether or not you need to provide a datum when creating  an output.\nSince the cost of not including the datum when you need to is high (the output becomes unspendable), this can lead to overly cautious UX from wallets.\nCurrently some wallets warn when sending money to a native script address without a datum, because they can’t know that it’s not a Plutus script address!\n\n### 3. Users are not familiar with the EUTXO concepts\n\nUsers are typically aware of the concept of addresses, but are much less likely to be aware of the concept of datums.\nThus, anything that requires them to think or operate with them is likely to be confusing, counterintuitive, and error-prone (at least at first).\n\n### 4. Difficulty of communicating datums\n\nApplication developers often need to tell users to send money to a Plutus script address in order to participate in the application in some way (e.g. paying some money into the contract).\nIn order to do this, the user will need to provide a datum.\nBut it is difficult to communicate this to the user, because the most common format for making payments is to just provide an address and the amount to transfer.\nThis doesn’t accommodate adding a datum.\n\nPlus, since users are not generally familiar with EUTXO concepts, attempts to communicate what they have to do via less direct means are difficult.\n\nThere are some tools that can help smooth this over, like the Dapp Connector, but they are not used universally.\n\n### 5. Lack of affordances for EUTXO concepts\n\nMany systems for working with Cardano don’t account for the need for datums or don’t make it easy to provide them.\nA key example is wallets, but more generally many systems that can take an address to send funds to needs to explicitly accommodate datums, otherwise it will not be possible to use Plutus script addresses with it (see the Catalyst use case for an example).\nThis is often not obvious to the designers of the system!\n\n### 6. Interaction models for Plutus scripts are obscure\n\nInteracting with Plutus scripts is hard for everyone: users, wallets, and applications.\nIn base Cardano:\n\n- You can’t find out how to form the datum and redeemer objects correctly\n- You can’t find out what kind of actions you can take with a script\n- You can’t find out how to take particular actions that you want to take\n\nAll of this makes it hard for both humans and computer systems to know whether they are interacting with the script correctly, which increases the risk of error significantly.\nIt also makes generic discoverability impossible, which forces application developers to provide lots of custom logic for every application in order to present users and systems with a comprehensible interface.\n\n## Use Cases\n\n### Simple escrow\n\nAlice wants to escrow money using an escrow script S.\nS requires a datum that indicates where to send the money back if the escrow fails to complete by the timeout.\nIt is difficult for the Alice to know a) that the datum is required, b) what the format is, c) how to actually enter it and make the payment.\n\n### Catalyst payouts\n\nCatalyst proposals include where to send the funds if the proposal is successful… in the form of an address.\nThis doesn’t support datums, so Plutus script addresses cannot be used to receive Catalyst funds.\nThus one cannot, for example, have the funds go directly into a DAO or similar system.\n\n### DAO contribution\n\nBob wants to pay some money into a DAO or similar system which is supposed to reward them for their contributions with some special tokens.\nIn order for this to be enforced on-chain, we need a Plutus script output with a datum that records who the contributor was, so that their reward can be routed to them.\n\nThis means that Bob needs to construct a Plutus script output with a datum at some point, and that Bob cares about the content of the datum and cannot fully trust another party to construct it for them (otherwise they might just route the reward to themselves).\nSo Bob needs to somehow ensure that the correct output is created, and to verify the content of the datum.\n\n### Ada Handles\n\nThe Ada Handle system works as follows:\n\n1. Try to resolve handle H\n2. Look for a specific NFT T that is related to H\n3. H resolves to the address of the output at which T is held\n\nThis resolves the handle to an address, but as we have seen this is not enough to know how to make a payment to that address if it is a Plutus script address (which you can’t know).\nA naive system which assumes it can send money to the address directly may create unspendable outputs if the handle token is held at a Plutus script address.\n\n### Native script payments\n\nCharlie wants to make a payment to a native script address.\nThis doesn’t require a datum, so they can do it simply based on the address, but their wallet gives them a scary warning because it doesn’t know that the address isn’t a Plutus script address that requires a datum.\n\n### Smart contract wallet\n\nEve has no idea about key security, but cares about custodianship and hence prefers to use a wallet which allows her to recover funds using a social recovery key sharing scheme.\nThis system uses a Plutus script to be the “owner” of the funds.\nWhen Eve wants to receive funds, her friends should not need to know what kind of wallet she is using - she should be able to provide them with a simple way to pay that is not meaningfully harder or different to paying into a normal wallet.\n\n## Goals\n\n### Avoid the need for users to know about datums in simple cases\n\nIdeally users should be able to mostly not know about datums unless they actually want to determine the content of the datum themselves.\n\n### Avoid forcing datums on scripts that don’t need them\n\nIf a script doesn’t want or need the facility to have datum then it shouldn’t be forced to have one, even if that makes things more consistent for the ledger.\n\n### Uniform handling of payments to non-script addresses and script addresses\n\nThere should be a straightforward path for a system that deals with payments to support both non-script and script addresses correctly without additional effort.\n\n### Single string for payments to script addresses\n\nThere should be a way to provide a user or system with a single string that contains all the information needed to make payment, whether it is to a Plutus script address or otherwise.\n\n### Reduce the risk of accidentally making unspendable outputs\n\nTry to make it less likely that users will accidentally create unspendable outputs, at least in some parts of the problem space (e.g. scripts that don’t “actually” need a datum).\n\n## Open Questions\n\n### Do we need to modify Cardano itself?\n\nMany of the listed problems are about users interacting with Cardano.\nThat suggests that it may be possible to mitigate the problems in the systems that users use for interacting with Cardano (wallets, applications, etc.).\n\nMore generally, it’s unclear to what degree we should be aiming for excellent UX in Layer 1 itself.\nBut if we can make simple changes in Layer 1 that make it much easier for supporting systems to provide good UX, that might well be worth it.\n\n### How many solutions do we need?\n\nThis CPS lists a lot of problems.\nIt’s not clear whether we will be able to come up with “big” solutions that solve many of the problems together, or whether we will need many “small” solutions that solve specific problems.\n\n### How does this relate to generic metadata problems?\n\nThere has long been a problem of how to establish metadata about on-chain entities in Cardano (no CPS so far, but see CIP-25, CIP-26, CIP-68, etc. for various attempted solutions).\nMany of the above problems could be mitigated with a good metadata solution, and it’s unclear to what degree this just “is” the metadata problem again.\n\nFor example, simply knowing the script itself (i.e. the pre-image of the hash used in the script address) helps with problem 1, because then you can know that it’s a Plutus script.\nBut it still doesn’t tell you what the form of the datum should be (problem 6), but this could be conveyed with additional metadata.\n\n## Copyright\n\nThis CPS is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CPS-0007/README.md",
    "content": "---\nCPS: 7\nTitle: Voltaire era Governance\nCategory: Ledger\nStatus: Open\nAuthors: \n  - Pi Lanningham <pi@sundaeswap.finance>\nProposed Solutions:\n  - CIP-1694: https://github.com/cardano-foundation/CIPs/tree/master/CIP-1694\nDiscussions:\n  - Discussions on CIPs discord: https://discord.gg/hdqHwSgWvG\n  - Original pull request: https://github.com/cardano-foundation/CIPs/pull/481\nCreated: 2023-03-14\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nIt has long been part of Cardano's vision for the \"final\" roadmap era to be one of Governance: allowing the community of ADA token holders to meaningfully own the decision making process by which the chain evolves.\n\nTo frame this discussion, it's important to outline a set of goals and baseline truths. Some of these will be neutral and uncontroversial, while others are in need of community discussion.\n\n### Acknowledgements\n<details>\n<summary> Thank you to the following people who helped review this draft before it was published: </summary>\n\n * Adam K. Dean\n * Jared Corduan\n * Vanessa Harris\n * HeptaSean\n\n</details>\n\n## Problem\n\nAt the core of it, a system of governance boils down to how decisions are made and enforced.  Cardano currently has 3 core decisions that greatly impact the operation of the chain:\n\n - When and how to change the ledger rules (a \"Controlled Hard Fork\")\n   - These changes are often drastic, with fundamental tradeoffs and extremely high risks\n - When and how to update various protocol parameters\n   - These parameter changes, while limited in scope compared to a hard fork, can still have potentially existential risks on the chain\n - When and to whom to disburse funds from the treasury\n   - Over the last several years, this treasury has accumulated nearly 1 billion ADA, currently worth hundreds of millions of dollars\n\nThe impact of these decisions are also often closely intertwined: development of the next hard fork may need funding from the treasury; parameters may need to be tweaked after a hard fork; etc.\n\nToday, these decisions are primarily made by the founding entities (IOG, Cardano Foundation, and Emurgo). While these entities often consult the community when making these decisions, the final power lies in their hands, with very little that can be done beyond an uncontrolled hard fork by the stake pool operators.\n\nFor a variety of reasons, including moral, philosophical, financial, and possibly regulatory, these founding entities want to dilute their own power substantially, and share the burden of governance of the chain with the community that has arisen around it.\n\nIOG in particular has continued to provide skill and resources for years longer than initially intended, and is significantly over-budget and over-extended. IOG has said that they may be unable or unwilling to support development of the chain indefinitely, and so an expedient and iterative approach to governance is likely to have higher positive impact on our ability to maintain velocity as an ecosystem.\n\nHowever, diluting that power to the community comes with substantial risks and challenges, not the least of which is ensuring that the will of the community is captured *accurately*. For example, one barrier to that accuracy is the possibility of \"sybil attacks\", wherein the anonymity of the blockchain allows someone to cast their vote many times.\n\n## Use Cases\n<!-- A concrete set of examples written from a user's perspective, describing what and why they are trying to do. When they exist, this section should give a sense of the current alternatives and highlight why they are not suitable. -->\n\n## Goals\n\nSynthesizing from the above, and with input from the broader Cardano community, the following goals, constraints, considerations, or ground truths for any governance system arise:\n\n1. A system of on-chain rules should allow decisions to be made and enacted regarding (at a minimum) the three types of changes listed above.\n2. Every (or nearly every) ADA holder should be able to meaningfully participate in this decision making process.\n3. This system should not materially undermine the security of the chain.\n4. This system should not undermine its ability to serve its financial function, such as overburdening the chain, damaging the monetary policy, etc.\n5. This system should be implementable within a reasonable time frame and budget.\n6. This system should be recursively updatable; if improvements or changes to the system of governance are needed, they should be voted on and enacted via this system.\n7. This system is highly dependent on the off chain user experience and community tooling, since very few users are reading raw CBOR dumps from the chain.\n8. This system should be cognizant of the fact that different decisions can have different impact and risk thresholds.\n9. This system cannot avoid the fact that stake pool operators of the network, collectively, always maintain control over a \"pocket nuke\": under sufficient discontent and misalignment with the will of governance, they can modify the code and initiate an uncontrolled hard fork to produce a separate chain aligned with their values.\n\nAdditionally, here is a more opinionated (and potentially controversial) list of potential considerations for a CIP, presented purely to foster discussion:\n\n1. There is currently no known decentralized \"proof of personhood\" system that is well specified and easily implementable, and without such a system, \"one lovelace one vote\" systems are the most effective defense against sybil attacks.\n2. Given the current near total control over these decisions that these founding powers have, any dilution of power that doesn't compromise the security of the chain or risk a deadlock is a worthwhile step to take.\n3. The system loses legitimacy if participation is extremely low, or participation is severely uninformed; If a significant portion of the Cardano community has not yet had a reasonable opportunity to participate, or the majority of participation is indinstinguishable from randomness, then any decisions made during this time are illegitimate.\n4. Not every ADA holder is interested in *directly* participating in every decision. Often an ADA holders voice can still be heard through delegation to another ADA holder.\n5. If the system contains such a notion of delegation, the ability to withdraw, redirect, or reclaim that voice at any time is an important tool in fighting corruption.\n6. While it may be useful to draw inspiration from existing real-world systems, it should also be understood that blockchain governance will have an entirely different set of constraints.  For example, the ADA community does not share one culture or geographic locality. Additionally, the decisions being made are not the same kinds of decisions that a world government needs to make.\n7. The uncontrolled hard fork described above is dangerous (from a safety standpoint) and disruptive (from an economic standpoint); it will likely seriously undermine the cohesion of the Cardano community. For this reason, it should be considered a tool of absolute last resort.\n\n## Open Questions\n\nBased on the goals above, an incomplete set of questions arises that any proposed solution likely ought to answer:\n\n1. What are the exact categories of actors considered by the proposed system, and what actions are available to them under what conditions? What are the explicit justifications for the additional complexity added by distinguishing each category as a separate category?\n2. How is the weight of each vote determined in the proposed system, and how does it defend against fraud and manipulation?\n3. How does the proposed system decide that it has \"reached quorum\", and can legitimately enforce the decision that has been reached?\n4. What vectors for denial of service (at both the protocol level and social level), and how does the proposed system mitigate these?\n5. What is the proposed path to adoption of the proposed system?\n6. What \"transitionary\" periods does the solution include, and what are the justifications for them? Or, conversely, what is the justification for *not* having a transitionary period?\n7. What is an estimated timeline and budget for implementation of the proposed system?\n8. Who is going to implement the proposed solution, and how will it be paid for?\n\n### Philosophical Questions\n\nBelow are a set of philosophical questions applicable across a broad range of solutions that are being discussed by the community:\n\n1. Are there any \"fundamental rights\" of ecosystem participants that should be protected by the governance system?\n2. Must any and all voting related to governance matters occur directly on the layer 1 ledger?\n3. What role, if any, do the founding entities play after governance is adopted?\n4. What kinds of community standards are needed outside of the scope of a specific solution at the ledger layer?\n5. What kinds of incentives (or disinsentives) should we use to align behavior with our goals? Should we try to compensate actors for the time and effort they put in, or does that create corrupt and misaligned incentives of their own?\n6. Is the ability to delegate overall more helpful or harmful? Does the risk of \"popularity\" based delegation (as opposed to trust / expertise based delegation) dilute the votes of others more than it increases inclusivity?\n\n## Copyright\n\nThis CPS is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CPS-0008/README.md",
    "content": "---\nCPS: 8\nTitle: Domain Name Resolution\nCategory: Tools\nStatus: Open\nAuthors:\n  - Hinson Wong <hinson@cns.space>\nProposed Solutions: []\nDiscussions: \n  - Cardano Name Service CIPs fork: https://github.com/cns-space/CIPs\n  - Original pull request: https://github.com/cardano-foundation/CIPs/pull/605\nCreated: 2023-10-14\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nAs different domain projects emerge, the same prefix or suffix may be employed by different projects, leading to potential naming conflicts. One of the key features of blockchain domain service is to resolve domain information. Conflicting names would lead to the integration ambiguity in resolving. To address this, a community-aligned mechanism should be in place to enable users to select their preferred project when resolving names. This ensures a seamless user experience.\n\nThe CPS is written up accordingly to open for discussion on potential approaches to the above issue.\n\n## Problem\n\nAs the ecosystem emerges, more and more domain service projects entering Cardano. Currently noticeably there are 3 domain projects:\n\n1. `ADA Handle`\n2. `adadomains`\n3. `Cardano Name Service (CNS)`\n\nBoth `adadomains` and `CNS` has chosen `.ada` as domain suffix. When proceeding with resolving integration, one common issue faced is the ambiguity in resolving approach, which could lead to user confusion at the minimal impact. On some specific information resolving, it might even cause serious loss of fund when sending tokens with monetary value to unexpected recipients.\n\n## Use Cases\n\nLet's illustrate the potential issues with a hypothetical example in wallet address resolving area.\n\n1. Assuming `Yoroi` wallet is going to integrate with `CNS` and `NuFi` wallet is going to integrate `adadomains`. (And both `CNS` and `adadomains` opt for `.ada` as the suffix)\n2. Both protocol has their separate domain NFT called `hinson.ada` and there are separate holder of `hinson.ada` for 2 domain projects.\n3. When the `hinson.ada` `CNS` holder requesting fund from others, there would be potential loss of fund when the user sending fund to `hinson.ada` through `NuFi` since the fund would be sent to `adadomains` domain holder instead.\n\nThis is not a desirable outcome as funds are mistakenly sending to the incorrect recipient without users noticing it.\n\n## Goals\n\nThe goal of this `CPS` is to invite community discussion on how to best approach this potential problem when the ecosystem evolves and having more and more domain projects entering the space.\n\n### Pro-decentralization Solution\n\nThe solution should embrace the decentralization property of a blockchain where it welcomes multiple domain name services exist in the market without user experience competition at the infrastructure level. The solution should not be made customized for any specific domain service providers, ideally shifting domain service projects' focus to enhancing features rather than competing with each other by oligarchic alliance.\n\n### Clear User Experience Flow\n\nIt ensures a user-friendly experience and allows users to make informed decisions in case of naming conflicts. It accommodates multiple projects with the same suffix while avoiding disputes and confusion, fostering the integration process of wallet and domain service.\n\n## Open Questions\n\n### On Domain Service Providers\n\n1. Should there be any standard in domain service provider side to store user information?\n2. Should there be standardization in domain metadata to assist with consistent integration?\n3. Apart from address resolving, should there be any standardized way to resolve domain information?\n4. Is there any threshold or minimum requirement on domain projects in order to be considered as applicable to apply the potential solution?\n5. Following `question 4 on integration partners`, would it be the domain service providers' responsibility to ensure the integration is in compliance with the potential solution?\n\n### On Integration Partners (e.g. Wallets)\n\n1. Should the potential solution just provide a high level guideline on integration user experience flow? Or a detailed guideline would be preferred?\n2. How to inform the community on whether which projects participated in the solution `CIP` so to alleviate users' concern when proceeding with integration partners? For example user could be confirmed that their fund would not be sent to unexpected recipients when using certain wallets participating in the `CIP`.\n3. Should there be any kind of community verification to include integration partners on to the participation list?\n4. If the potential solution `CIP` only serves as a soft guideline, how could we make it useful to community when projects integrating with domain services do bother to spend time and effort into this alignment?\n\n## Copyright\n\nThis CPS is licensed under [CC-BY-4.0].\n\n[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode\n"
  },
  {
    "path": "CPS-0009/README.md",
    "content": "---\nCPS: 9\nTitle: Coin Selection Including Native Tokens\nCategory: Wallets\nStatus: Open\nAuthors:\n  - Hinson Wong <wongkahinhinson@gmail.com>\n  - Tsz Wai Wu <wu.tszwai@outlook.com>\nProposed Solutions: []\nDiscussions:\n  - Motivating issue: https://github.com/cardano-foundation/CIPs/issues/232\n  - Original pull request: https://github.com/cardano-foundation/CIPs/pull/611\nCreated: 2023-10-20\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nThe introduction of native tokens in Cardano has introduced unique challenges related to coin selection and transaction efficiency. This Cardano Problem Statement (CPS) addresses the need for a specialized coin selection approach to optimize transactions involving native tokens while minimizing transaction size and complexity.\n\n## Problem\n\nThe integration of native tokens in Cardano transactions has brought both opportunities and challenges. One of the significant challenges is associated with coin selection when dealing with native tokens.\n\n### 1. Need for Efficient Coin Selection\n\nCardano transactions involving native tokens require attaching a minUTxO value (lovelace) to the transaction. In scenarios where multiple tokens are associated with a single UTxO, selecting such UTxOs as inputs can lead to inefficient transactions. This inefficiency arises from the increased transaction size due to token information, potentially impacting the decentralized applications and network performance.\n\n### 2. Streamlining the Selection Process\n\nStreamlining the selection process is crucial. Enhancements should be made to the selection algorithms to ensure that, even in complex scenarios, the coin selection process remains efficient and doesn't compromise the user experience.\n\n### 3. Compatibility with Serialization Libraries\n\nThe largest off-chain serialization library, `cardano-serialization-lib`, still follows a modified version of the [CIP-2 standard](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0002/README.md), which was established in the pre-native token era. There's a need to ensure that the proposed coin selection approach remains compatible with existing serialization libraries, making it accessible to a wider range of developers and applications.\n\nWhile CIP-2 certainly works well in an environment where native assets such as tokens and NFTs don't exist, it has been expanded upon differently by each serialization library, with their own custom solutions to select for tokens. It would be useful to once again have some standard for coin selection that is trusted by the community.\n\n### 4. Min UTxO Value for change with tokens\n\nCIP-2 doesn't consider `minUTxOValue` in the change output with tokens, if a pure ADA change output cannot be created that reaches the `minUTxOValue`, it is possible to simply increase the fees paid for the transaction by that small amount to balance the transaction. This, however, doesn't work when tokens are involved, any tokens in the transaction inputs MUST be included in the change output.\n\n## Use Cases\n\n### Native Token Transactions\n\nUsers and applications frequently engage in native token transactions, making efficient coin selection essential to minimize transaction costs and network congestion.\n\n### DApps and DeFi\n\nDecentralized applications and DeFi projects require efficient coin selection to maintain the performance and cost-effectiveness of their transactions.\n\n### Example Implementations\n\nSome real world use cases of coin selection algorithms taking Native Tokens into account are listed below:\n1. [UTxO utils of Cardano in WASM](https://www.npmjs.com/package/cardano-utxo-wasm)\n2. [Cardano Wallet](https://github.com/cardano-foundation/cardano-wallet/tree/master/lib/coin-selection)\n3. [cardano-multiplatform-lib](https://github.com/dcSpark/cardano-multiplatform-lib)\n4. [RoundTable](https://github.com/ADAOcommunity/round-table)\n\n### Network Scalability\n\nEfficient coin selection contributes to network scalability by reducing the size and complexity of transactions, ensuring smooth and rapid processing.\n\n## Goals\n\n### Specialized Coin Selection Approach\n\nThe primary goal of this CPS is to establish a specialized coin selection approach for transactions involving native tokens in Cardano. This approach should prioritize necessary tokens, improve transaction efficiency, and minimize the impact of native token inclusion on transaction size.\n\n### Consider change and fees\n\nIn Cardano, there is somewhat of a cyclic dependency between UTxO selection, change output and fees. It would be extremely helpful if some consensus was reached on how to handle this part of transaction building. Since the most naïve approach essentially requires rebuilding the transaction several times, there is potential to significantly reduce latency in DApps with a more efficient approach.\n\n### Useful change outputs\n\nCIP-2 also selects inputs in order to generate \"useful\" change outputs. This will be a significantly more complex problem when native tokens are considered, but will significantly improve the collective efficiency of transaction generation in wallets.\n\n### Streamlined Transactions\n\nBy optimizing coin selection, we aim to streamline Cardano transactions, reducing their size and complexity while preserving the integrity of native token operations.\n\n### Cross-Compatibility\n\nThe proposed approach should remain compatible with existing off-chain serialization libraries and protocols, ensuring accessibility to a wide range of developers and projects.\n\n### Improved Network Performance\n\nEfficient coin selection contributes to overall network performance, making Cardano more scalable and reliable for users, DApps, and DeFi.\n\n## Open Questions\n\n### Implementation\n\n1. How can we effectively implement and promote the specialized coin selection approach?\n2. What changes, enhancements, or protocols need to be adopted within the Cardano ecosystem to achieve this?\n3. Is there any community collective intelligence could gather for this area? Particularly, would engineers from Emurgo (who maintain `cardano-serialization-lib`) and developers of `cardano-multiplatform-lib` have any form of insight to push forth community progress?\n\n### Developer Education\n\n1. Are there any changes on application code itself with improvements on coin selection algorithms?\n2. If so, how can developers be educated and informed about any new coin selection approach to ensure its successful adoption and integration into their projects?\n\n### Community Consensus\n\n1. How can we gather and build consensus within the Cardano community regarding any proposed coin selection approach?\n2. Do we need any support from academia with formal proof to impose the standard?\n3. What methods can be employed to ensure widespread acceptance and adoption? Do we need endorsement from any of IOHK, CF or Emurgo?\n4. If academic formal research is not needed for this consensus, how can we set the bar for an acceptable algorithm? Would there be a core committee making the decision?\n\n## Copyright\n\nThis CPS is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CPS-0010/README.md",
    "content": "---\nCPS: 10\nTitle: Wallet Connectors\nCategory: Wallets\nStatus: Open\nAuthors:\n    - Ryan Williams <ryan.williams@intersectmbo.org>\n    - Vladimir Kalnitsky <vladimir@mlabs.city>\nProposed Solutions: []\nDiscussions:\n    - Original pull request: https://github.com/cardano-foundation/cips/pull/619\nCreated: 2023-07-28\nLicense: CC-BY-4.0\n---\n\n## Abstract\nWallets the foundational element of Web3, being the primary interface between users and blockchains.\nWallet connectors allow users to connect their wallet to client stacks (i.e. dApps), facilitating a wide range of specialized user experiences.\n\nWallet connector standards largely consist of two parts: the connection standard and the API.\nThe connection standard defines how the wallet and dApp initiate communication, for example, using an injected Javascript object.\nThe API defines what communications look like between the dApp and wallet post connection.\n\nThis problem statement is concerned with the issues surrounding Cardano's current and future wallet connectors.\nThese interfaces are difficult to define and historically have been even harder to iterate upon.\nWe wish to provide a comprehensive catalogue of the current offerings and their drawbacks to be able to make suggestions on future standards.\n\nFor the many contributors to this proposal, see [Acknowledgements](#acknowledgements).\n\n## Problem\nThe motivation for this document is to outline the current state of Cardano's wallet connectors, discuss their flaws, and identify key concerns for future connector authors to be aware of.\nWe hope that by discussing the issues, we will inspire the next generation of Cardano wallet connectors so that the ecosystem can grow beyond its first connector iterations.\n\nIneffective connectors can cause a range of issues for wallets, dApp developers, and thus users.\nDue to the nature of these connections, there can often be unforeseen impacts from small design decisions.\n\nFor users, connectors should offer secure and reliable compatibility with a wide range of dApps.\nFor dApps, connectors should be reliable and provide stable and rich APIs.\nFor wallets, connectors should be secure, optionally extendable, and with APIs which do not expect wallets to go beyond standard expectations.\n\n### Core Concerns\nHere we outline what we see as the necessary concerns which connector authors should consider.\n\n#### 1. Security\nSecurity should remain of paramount concern within Web3.\nConnection standards must strive to, above all, not compromise the security of wallets or dApps.\nConnection standards should be aware of the potential impacts of standard security vulnerabilities, such as man-in-the-middle attacks.\n\nThe security of the API should remain eminent.\nAn example of this is that no secret information should ever be allowed to leave the wallet.\n\n#### 2. Range of supported connection\nConnection standards should support a wide range of wallets and client platforms.\nThis means we shouldn't assume a software environment (e.g. JavaScript in the browser) and define the APIs using schema languages widely used in language-agnostic contexts.\nWith the base-level connections only offering an indication of supported APIs bidirectionally.\n\n#### 3. API Expressiveness\nAPIs should allow for an expressive range of information to be exchanged.\nInformation should be able to be passed in both directions.\n\n#### 4. Versioning\nConnection standards and APIs should be explicitly versioned to clearly allow upgrades.\nFurthermore, ideally, APIs should allow for optional extendability to facilitate specialization of connection.\n\n#### 5. Adherence to Expected Roles\nAPIs should be written to have a clear scope, understanding the potential strains placed on wallet providers.\n\n### Context\n\n#### Cardano's Wallet Connector*s*\n[CIP-30](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0030/README.md) is *the* wallet connector for Cardano.\nThis standard has facilitated the emergence of dApp development on Cardano by defining both a connection standard and an API.\nIt is, to date, the only wallet connector to see wide adoption in the ecosystem.\nUsing an injected Javascript object for communication between wallets and web-based dApps.\nSince its' authoring, CIP-30 has seen continued iteration with many tweaks to its API.\n\n##### CIP-30 Alternatives\nPost CIP-30's acceptance there have only been two other competing standards, in CIP-45 | Decentralized WebRTC dApp-Wallet Communication ([#395](https://github.com/cardano-foundation/CIPs/pull/395)) and CIP-90 | Extendable dApp-Wallet Web Bridge ([#462](https://github.com/cardano-foundation/CIPs/pull/462/)).\nWith neither of these standards gaining significant adoption.\n\nWith CIP-45 offering an alternative connection standard based on initiating a WebRTC connection via WebTorrent tracker, taking a similar to [Wallet Connect](https://walletconnect.com/).\nThis was motivated by a want to diversify the connection standards in Cardano.\nUnlike CIP-30 this proposal does not define any standards for the API shared after connection time, instead it just reuses the [CIP-30 Full API](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0030/README.md#full-api).\n\nCIP-90 was created in reaction to the last major changes to CIP-30, within [#446](https://github.com/cardano-foundation/CIPs/pull/446).\nThis proposal aims to reuse the CIP-30 connection standard, whilst making the CIP-30 API optional, allowing for other CIPs to specify further APIs.\nThis contrasted the ideas presented within [#446](https://github.com/cardano-foundation/CIPs/pull/446) which stipulated that all connections should include the CIP-30 Full API. \n\nAlthough not a direct competitor, [CIP-13 | Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/README.md) could be seen as an alternative standard, fitting some wallet-client niches.\nThis URI scheme allows a sort-of one way connection, where information can be passed to a wallet to trigger a function.\n\n#### Historical Issues\nCIP-30 is likely the most iterated upon CIP, post merger into the CIPs repository.\nThese changes have been attempting to remedy issues with the initial proposal.\n\n##### Versioning\nDespite the CIP-30 API including a [versioning mechanism](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0030/README.md#cardanowalletnameapiversion-string) it was not utilized.\nAlterations to the API were accepted without incrementing the version number.\n\nThese changes resulted in diverging implementations and thus broken compatibility.\nAt connection time there would be no way to tell which version of CIP-30 the wallet had implemented.\nOften resulting in errors during dApp-wallet communication, degrading usability.\n\nA result of this has been that dApps whitelist only those wallets which they have tested against.\nThis completely undermines the benefits of having such a standard.\nFurthermore this whitelisting has encouraged those smaller wallets to emulate the whitelisted wallets, by injecting themselves under the name of the whitelisted wallets.\nThis sort of arms race, is completely unnecessary and results in future complexities for both sides.\n\n##### Unclear Responsibilities\nCIP-30 does not provide rationale to what should be the concern of the wallet and clients.\n\nThe knock-on effect of this is uncertainty regarding the direction future CIP-30 development should follow.\n\n##### Limited Scope\nBy it's nature CIP-30 is a base level connector designed to get the first dApps on Cardano moving.\nIt does, of course, have a finite scope which cannot support future upgrades or specialized connections.\n\n##### Language Dependent\nCIP-30's connection standard and API is defined using Typescript.\nWhilst this is convenient for Javascript-based clients this is not convenient for other stacks. \n\nTying the wallet connector to a single language is naturally limiting and will cause friction for potential adopters.\n\n##### Limited to Web-based Stacks\nThe CIP-30 connection standard is based upon injecting code into shared web windows.\nThis is convenient for browser extension wallets and web-based client stacks, but is awkward for all other implementors.\n\nOne consequence of this is that mobile wallets are thus required to reimplement web browsers in their applications, which is wasted effort.\nA similar novel solution would be required for the current full node wallets to be able to utilize CIP-30 compatible dApps.\nThis is not great as non-web-based wallets (and their users) are unable to utilize the benefits of Cardano's web3.\n\n##### Undefined Behavior\nThe overall descriptions of CIP-30 behavior are brief, leading to many potential cases of undefined behavior.\n\nFor example; should the results of `.getUtxos()` include UTxOs the wallet wishes to reserve/not spend? or include UTxOs the wallet knows are in the process of being spent? how should these reserved/pending UTxOs factor into the result of `.getBalance()`?\nSuch behavior is unclear and thus different wallets will implement behavior differently, leading to inconsistent experiences for dApps and users.\n\n##### Combined Standard\nCIP-30 defined both a connection standard and an API which must be used on every connection.\nThis is limiting as it forces all connections using the CIP-30 connect to always use the same endpoints.\nThis adds unneeded complexity, making iterating on connection or API more difficult.\n\n##### No event listener\nThe CIP-30 API and connector is purely based on synchronous and asynchronous calls made by the client dApp.\nThis prevents useful advantages of event-based design, such as dApps subscribing to state update events emitted by wallets.\n\n#### CIP-30 Iteration Improvements\nCIP-30 has seen some efforts to address its flaws.\n\n##### CIP-30 Extensions\nThe CIP-30 extendibility mechanism was introduced as a novel versioning scheme within [#446](https://github.com/cardano-foundation/CIPs/pull/446) and was further refined in [#577](https://github.com/cardano-foundation/CIPs/pull/577).\nThe motivation was to provide a safe way to optionally modify the CIP-30 API without breaking existing implementations.\nFurthermore these changes were introduced to stop any further modifications to the CIP-30 API, negating the need for versioning.\nThis has allowed for the creation of further CIPs defining API extensions, to upgrade, specialize and enhance CIP-30 connections.\nWith extensions also going part way to be able to address undefined behavior.\n\nAt time of writing there are four proposed extensions, with only one being merged into the CIPs repository.\n\n##### CIP-30 Alteration Freeze\nAs part of the extension mechanism be added within [#446](https://github.com/cardano-foundation/CIPs/pull/446), a less formal shift in attitude was adopted by the CIP editors.\nIn that no more alterations to CIP-30 would be allowed, instead all changes must be done through the extension mechanism.\nThis prevents anymore downstream issues caused by lack of versioning.\n\n##### This Problem Statement\nThe hopefully final remediation to CIP-30 is this document.\nWe want to discuss CIP-30's drawbacks, so they can be understood moving one step closer to solving them.\n\n## Use Cases\n\n### NFT Marketplace\nAlice wishes to buy a NFT from an smart contract based NFT marketplace for an agreed price because she wishes to support the artist.\nAlice wants to be able to use a familiar website interface where she can browse rendered NFTs then select and buy on the same site.\n\nWithout the dApp and her wallet communicating it is very difficult to construct the needed transaction to buy the NFT Alice wants.\n\n### Simple Wallet Login\nBob wants to use his wallet to login to a website.\nThe website requires that Bob presents both; his public credentials and also prove his ownership of them.\n\nIt is difficult for Bob to produce and share proof of ownership for public credentials in a secure way without the dApp and wallet communicating.\n\n### dApp Developer\nCarol is a dApp developer, who wants many users to be able interact with her dApp via web interface.\nShe wants to be able to support a wide range of wallets and platforms to maximize potential user base.\nWhilst she wants the API standards to be expressive so that her dApp is able to offer a range of functionality.\n\n### Wallet provider\nDave has created a wallet, he wants to minimize the cost of running his wallet.\n\nWithout clear role of the wallet, and optional API extension scoping Dave's infrastructure may be asked to do many operations incurring cost.\n\n## Goals\nThese goals we outline for future wallet connection and API standards are based upon solving our [Core Concerns](#core-concerns).\n\n**Wallet connectors should:**\n\n### 1. Prioritize Security\nPotential security concerns of wallet connector designs should be well understood and discussed in accompanying CIPs.\nAuthors should seek the collective knowledge of the CIP process to obtain wide range of perspectives.\n\nThe impact of any data leaving the wallet should be discussed, especially for the cases of data that is not observable via the chain, such as root public keys.\n\nAlthough security tolerances are at an implementors discretion, the potential negative impact on the ecosystem should be taken into account by authors.\n\n### 2. Provide Interoperable, Optional and Extensible APIs\nFuture API standards should be connection agnostic as well as stack standard agnostic.\nMeaning API CIP-1234 should work if connection has been initiated via CIP-30 connection or CIP-45, or CIP-4321.\n\nAPI standards should exist within an extensible framework, whereby specific connections can be permissioned and specialized.\nAPIs should be developed via the CIP process, whereby CIPs will each define their own set of endpoints.\n\nImplementing the API support should be fully at the discretion of the wallet providers.\nAlthough at connection time dApps should be free to request as many APIs as they wish, they should not rely on the implementation of optional APIs beyond APIs implemented in [No-data Wallets](#no-data-wallets).\nConnections be based on \"who am I? what do I support?\"\n\n### 3. Support Versioning\nVersioning standards should be utilized by connection standard and API authors.\nAPIs should inherit the novel versioning utilized for CIP-30 extensions.\nConnection standards should be free to employ any versioning scheme they wish.\n\n### 4. Work Within the Role of Wallet\nConnection and API authors should understand that there are different types of wallets, each with their own constraints.\nStandards should be aware of this and discuss which wallets are applicable in their CIPs.\n\nWhilst most software wallets generally offer users a range of features, at their *core* all wallets are concerned with the management of cryptographic operations.\nThe majority of wallets build on this by using a chain indexer, so information related to wallets' cryptographic credentials can be gathered and presented to users.\n\nBy only expecting wallets to support cryptographic operations we define a universal rule for all wallet connectors.\nThis means at a minimum all dApps can expect from wallets during connection is cryptographic operations.\nAlthough, dApps should be able to request additional functionalities on connection if they wish.\n\n**Building on this we define further divisions:**\n\n#### Types of Wallet\nAll possible wallet standards can be divided into three groups based on a single criterion: what data they provide to dApps via the API endpoint.\n\nThis division is important because each of the groups allows for different dApp architectures.\n\n**Note** The groups are nested: every wallet is a no-data wallet and every full-data wallet is also an own-data wallet if we look at the dApp architectures they enable.\n\n##### No-data Wallets\nNo-data wallets do not provide data queries and are only concerned with cryptographic operations (e.g. hardware wallets).\nAll management of UTxOs is placed on dApps side.\nNo-data wallets can use multiple addresses, but they do not allow to query for available UTxOs and do not indicate which of the addresses are actually used on-chain.\n\nThese wallets may even rely on dApps to derive addresses, by sharing the root public key.\n\n![diagram showing wallet and dApp architecture for no-data wallets](./no-data-wallet.drawio.png)\n\nThis design ensures that wallets can function without a query layer and thus without runtime infrastructure needed.\n\n##### Own-data Wallets\nOwn-data wallets provide chain queries related to users' own data and wallet state (users' addresses and UTxOs).\nCIP-30 falls into this category.\n\n![diagram showing possible wallet and dApp architecture for own-data wallets](./own-data-wallet.drawio.png)\n\nThis architecture has two major issues:\n\n- **Unclear separation of concerns** - while wallets provide certain functions for dApp developers, they have no means to enforce their use, and naturally some developers opt to using their own query layers when they see fit, with consequences that are hard to predict. For example, the wallet may not allow signing a transaction that consumes an UTxO it considers \"locked\".\n\n- **Two sources of truth problem** - on Cardano, every running node has its own opinion on the set of currently unspent transaction outputs. Only [eventual consistency](https://en.wikipedia.org/wiki/Eventual_consistency) is guaranteed. Any dApp that interacts with an own-data wallet has to deal with the inconsistency between local `cardano-node`-based query layer and light wallet query layer, especially when dApp workflow involves sending multiple interactions with the wallet in quick succession. For example, a wallet may refuse to sign a transaction containing an UTxO it does not (yet) know about.\n\nEven if we enforce clear separation of concerns in the standards, e.g. by stating that sending a transaction bypassing the wallet is not allowed, the problem of two sources of truth will remain.\n\n##### Full-data Wallets\nFull-data wallets allow to query blockchain data outside of user's scope (i.e. anything not covered by own-data wallets).\n\n![diagram showing possible wallet and dApp architecture for full-data wallets](./full-data-wallet.drawio.png)\n\nDepending on dApp needs, full-data wallets open a way to implement fully-functional dApps that use non-local blockchain data without the need for the developer to maintain dApp backend infrastructure.\nAs a result, more decentralized and censorship-resistant architectures become possible: a dApp can be distributed as a set of files, and deployed to IPFS or static hosting websites.\n\nFull-data wallets enable \"single source of truth\" architecture: no need to work around data inconsistency between two query layers.\n\nThey are more expensive to operate due to higher query layer requirements, but the risks could be lowered by letting query layer providers and wallet developers be separate entities.\nThat would also allow the end users to choose query layer providers they trust more rather than being forced to trust wallet's infrastructure as well as code, and, optionally, use their own query layer deployments, thus alleviating the need to trust any external wallet backend while enjoying the usual interface.\n\n### 5. Minimize Growing Pains\nThe pain caused by uprooting all CIP-30 implementations should not be underestimated.\nThus, future standards should work to minimize the potential pain, be it by support CIP-30 implementations in a legacy mode.\n\n## Open Questions\n\n### Can a universal connector be pursued?\nEvery wallet connector that simply adds functionality on top of another standard can be considered a valid implementation of the base standard.\nIf the set of standards is designed in a way that allows for extensions without conflicts, then a superset of all standards can be considered a universal connector. How to make it possible to clearly define a \"universal connector\" and whether it is useful at all remains to be seen.\n\n### Can a universal API be pursued?\nPlatform differences are a concern: by using specifications that do not rely on assumptions about data transfer methods, software environment or programming language, it is possible to create a standard that is truly reusable across platforms.\n\nThere are many types of dApp architectures enabled by different wallet types, but there is no requirement to use the APIs provided by wallets, so dApps that use simpler standards should still remain functional when used with their extensions.\n\n### How interoperable can standards be with those of other ecosystems?\nCardano is sufficiently different from most of the blockchains that aim to unify their wallet standards.\n\nWhat options do we have for integration with Cardano sidechains, rollups, hardforks, private testnets, etc.?\n\n### How can we effectively police API scope?\nHow can we prevent duplication of functionality and make sure different APIs do not overlap?\n\n## Acknowledgements\n\n<details>\n  <summary><strong>First workshop - 2023-11-27</strong></summary>\n\n  We would like to thank those that contributed to the first workshop hosted by Adam Dean and Ryan Williams ([see shared drive with resources](https://drive.google.com/drive/folders/1gYGeVJBLmDhCGEp1mTkCrsJYspd5hSoM?usp=drive_link)).\n  - Beatrice Anihiri\n  - Denis Kalinin\n  - Evgenii Lisitskii\n  - George APEX Pool\n  - George Flerovsky\n  - George Humphreys\n  - Hernán Rajchert\n  - Jack Rousian\n  - Joshua Marchand\n  - Ken Fritschy\n  - Ken-Erik Ølmheim\n  - Leo H\n  - Marcel Baumberg\n  - Martynas Kazlaukas\n  - Michael Chappell\n  - Mircea Hasegan\n  - Nicolas Ayotte\n  - Rhys Bartels-Waller\n  - Robert Phair\n  - Rodolpho Ribeiro\n  - Steven Johnson\n  - Teodora Sevastru Lunn\n  - Thomas Lindseth\n  - Thomas Upfield\n  - Vladimir Kalnitsky\n\n</details>\n\n<details>\n  <summary><strong>Second workshop - 2023-12-08</strong></summary>\n\n  We would like to thank those that contributed to the second workshop hosted by Adam Dean and Ryan Williams ([see shared drive with resources](https://drive.google.com/drive/folders/1gYGeVJBLmDhCGEp1mTkCrsJYspd5hSoM?usp=drive_link)).\n  - Alex Dochioiu\n  - George APEX Pool\n  - Mark Byers\n  - Leo H\n\n</details>\n\n<details>\n  <summary><strong>Third workshop - 2024-01-06</strong></summary>\n\n  We would like to thank those that contributed to the third workshop hosted by Ryan Williams ([see shared drive with resources](https://drive.google.com/drive/folders/1gYGeVJBLmDhCGEp1mTkCrsJYspd5hSoM?usp=drive_link)).\n  - Brent\n  - Ishita Verma\n  - Jonathan Kelly\n  - Leo H\n  - Nick Ulrich\n  - NOODZ\n  - Vladimir Kalnitsky\n\n</details>\n\n## Copyright\n\nThis CPS is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)."
  },
  {
    "path": "CPS-0011/README.md",
    "content": "---\nCPS: 11\nTitle: Universal JSON Encoding for Domain Types\nCategory: Tools\nStatus: Open\nAuthors:\n    - Vladimir Kalnitsky <vladimir@mlabs.city>\nProposed Solutions: []\nDiscussions:\n    - Original pull request: https://github.com/cardano-foundation/cips/pulls/742\nCreated: 2024-01-10\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\ndApps require the use of communication protocols that facilitate data transfer between:\n\n- query layer providers and dApps\n- wallets and dApps\n- wallets and query layer providers\n- dApp frontends and backends\n- different dApps\n- Cardano blockchain indexers and their API consumers\n\nUsually these protocols include a specification of Cardano domain types, i.e. ledger block and all of its sub-components.\n\n## Problem\n\nCardano domain types have canonical CDDL definitions (for every era), but when it comes to use in web apps, where JSON is the universally accepted format, there is no definite standard.\n\nAs a result, software solutions are incompatible with each other, and dApp developers are forced to write code for conversions that could in principle be unnecessary, because the semantics of different JSON layouts are often the same. In particular, this problem is very real when offchain libraries need to provide support for different query layer providers (examples: [Lucid](https://lucid.spacebudz.io/docs/getting-started/choose-provider/), [Mesh.js](https://meshjs.dev/providers), [cardano-transaction-lib](https://github.com/Plutonomicon/cardano-transaction-lib/blob/develop/doc/runtime.md), [Atlas](https://haddock.atlas-app.io/GeniusYield-Providers.html)).\n\nThe [initiative](https://github.com/cardano-foundation/CIPs/pull/625) to standardize query layers on Cardano is currently blocked due to absence of a standardized JSON data schema. However, such a schema would be useful in contexts other than query layers, which is the reason why this CPS is separate.\n\n## Use Cases\n\n- dApp developers want to have a definite encoding of JSON data, so that they don't need to specify the format themselves\n- dApp developers want to be sure they will be able to reuse data coming from different sources (third parties) without format changes\n- dApp developers want to provide external APIs that must be easily consumable\n- Query layer developers want to make sure their APIs will be easily consumable\n- Multiple service/product owners, who utilize different competing JSON encoding conventions want to converge to a single convention\n\n## Goals\n\nThe main goal of a CIP that corresponds to this CPS is to construct a JSON schema that explicitly defines all domain types for the current era. This CIP should evolve in sync with the Cardano Ledger CDDL specification, so that when a new era spec comes out, a new JSON schema file is provided with the needed modifications.\n\nOptional goals:\n\n- Providing support for eras older than the current one. The goal of the spec is to be used across different software solutions that run on Cardano mainnet. Compatibility with past ledger versions should be provided only as long as there is a real need.\n\nNon-goals:\n\n- Maintain roundtrip property for conversion between JSON and CBOR: this is impossible, because CBOR uses varying binary encodings for arrays and maps.\n- Provide support for different eras in a single schema. Specifications should be kept in separate files.\n- Maintain correctness of signatures for transactions encoded as JSON: this is impossible in the general case, because signature validity depends on binary layout determined by CBOR encoding. Conventions may apply to preserve signatures, but they are out of scope of the standard, because they apply to CBOR encoding, not JSON.\n- Making the encoding as compact as possible (reducing encoded data size)\n\n## Open Questions\n\n- What's the best approach to specifying address formats in json-schema format?\n- Should the schema be concerned with different representations of addresses (bech32 vs. hex)?\n- How can we programmatically or manually test the constructed schema file?\n- How to encode long integer arithmetic? Some JSON encoding implementations simply refuse to handle long integers, e.g. [CSL](https://github.com/Emurgo/cardano-serialization-lib/blob/4a35ef11fd5c4931626c03025fe6f67743a6bdf9/rust/src/plutus.rs#L1370).\n- [RFC8949](https://www.rfc-editor.org/rfc/rfc8949.html#name-converting-data-between-cbo) and [RFC8610](https://datatracker.ietf.org/doc/html/rfc8610#appendix-E) contain recommendations for developers who want to maintain interoperability with JSON. Can we apply these in our context?\n\n## Copyright\n\nThis CPS is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CPS-0012/README.md",
    "content": "---\nCPS: 12\nTitle: Query Layer Standardization\nCategory: Tools\nStatus: Open\nAuthors:\n    - Vladimir Kalnitsky <vladimir@mlabs.city>\n    - Ryan Williams <ryan.williams@intersectmbo.org>\nProposed Solutions: []\nDiscussions:\n    - Original pull request: https://github.com/cardano-foundation/CIPs/pull/625\nCreated: 2023-11-27\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nQuery layer services abstract away the difficulties of indexing blockchains, offering builders API interfaces to access data. \n\nCardano's query layers lack standardization.\nThis leads to suboptimal tooling, dApp and wallet architecture.\n\n## Problem\n\nCardano nodes offer limited options for querying chain data.\nFor builders, running chain indexing infrastructure can alleviate the data availability issues of the Cardano node.\nBut this brings with it large overheads in running the nodes, chain followers, data storage and data access.\n\nQuery layer providers offer builders the opportunity to abstract away the infrastructure complexities of Cardano data availability, usually to some cost.\nThese providers are extremely useful and in turn are used as a foundational element for hundreds of tools.\n\nCardano has a range of query layer providers, each with their own interfaces and business motivations.\nThis can present issues for builders who wish to build with multiple providers.\n\n### Query Layers and Tooling\n\nLack of a standardized query layer results in multiple different implementations of roughly the same set of functionality:\n\n- [Blockfrost](https://blockfrost.io/)\n- [Koios](https://www.koios.rest/)\n- [Maestro](https://www.gomaestro.org)\n\nAs a result, there is a need to support multiple incompatible APIs in downstream tools, examples of which are:\n\n- [Mesh.js](https://meshjs.dev/providers)\n- [Lucid](https://lucid.spacebudz.io/)\n- [cardano-transaction-library](https://github.com/Plutonomicon/cardano-transaction-lib/blob/develop/doc/runtime.md)\n- [cardano-js-sdk](https://github.com/input-output-hk/cardano-js-sdk/tree/master/packages/core/src/Provider)\n\nQuery layer providers are not identical, which means that the *promise* of abstracting away from a particular query layer provider completely, that an offchain library may want to give to its users, will either be left *unfulfilled* (i.e. some features will work with some providers, but not others) or the scope of the downstream API will have to be *reduced* to the very minimum that is covered by every supported query layer.\n\n### Query Layers and Wallets\n\nThis CPS initiative originated in the discussion about [Extensive Wallet Standard CIP](https://github.com/cardano-foundation/CIPs/pull/620) on the CIP Discord server ([invite](https://discord.gg/P59aNVN8zu))\nin the [`#general`](https://discord.com/channels/971785110770831360/992011119872970762/1176567729017327737) channel, continuing in a dedicated [`#query-layer-standard`](https://discord.com/channels/971785110770831360/1178763938389823598) channel.\n\nEvery light wallet has its own backend infrastructure: functioning of the browser extension relies on the availability of the data sources. However, none of the wallets currently provide a way to override their query layer endpoint URLs.\n\nIn the past, users have encountered problems with ability to submit transactions due to limited mempool capacity, which resulted in some wallets providing a way to configure custom [tx-submit-api](https://github.com/blinklabs-io/tx-submit-api) endpoints - but this only covers transaction submission.\n\nTight coupling between wallets and query layers results in unnecessary economic burden imposed on wallets, and forces them to make opinionated choices (of query layer provider) that could otherwise be delegated to the end user, similarly to how it is done in Metamask with RPC provider selection.\n\nThe economic burden, in turn, results in discouraging of innovation in the wallet ecosystem, because there is a very strong pressure to keep wallet standards minimal coming from wallet providers.\n\nAnother downside of tight coupling between wallets and query layers is that, unlike Ethereum wallets, Cardano wallets can't be used to interact with dApps deployed to custom (private) testnets. Only public testnets are supported, and as a result in order to simply test a dApp end-to-end, it must be deployed to a public testnet. This is a privacy concern for dApp developers, because making on-chain contracts available publicly (although in a compiled form) before they are officially open-sourced can be seen as data breach.\n\n### Centralization and Ecosystem Risks\n\nThe inability to interchange query layer providers results in vendor lock-in. Query layer providers are disincentivized to opensource their infrastructure setup or provide a competitive service. Dependency on a fixed set of entities to run the infrastructure makes it easier for adversaries to attack dApps by taking over the infrastructure.\n\nHaving accepted standards drastically reduces the complexity and cost for new providers to develop.\nThis creates a query layer marketplace where providers can be more easily compared by customers.\n\n### Barriers to adoption\n\nSuch a standard could likely face resistance to adoption.\n\nThe potential risk for commercial offerings adopting this standard is the loss of the ability to differentiate themselves from competitors via data shape.\n\nDifferentiating themselves via data shape is useful in two ways for query layer providers.\nFirstly, data providers each use their own unique infrastructure, so the costs of the same query are not uniform between providers.\nBy adjusting query shape, providers can adjust queries to suit their architecture, ensuring speed and reducing cost.\n\nSecondly, is the potential monetary advantages.\nWithout a standard commercial providers are able to shape their data in a way to attract customers.\nA provider's business model may be to charge per request, which incentivises them to keep the data small to increase the number of queries by customers.\nA standardized set of queries would reduce the ability for providers to do this.\n\n#### Mitigation\n\nTo mitigate the impact of varying provider architectures, authors of solutions should seek to involve query layer providers in the development of a standard.\nThis will allow providers to voice concerns over potentially expensive or awkward queries.\n\nTo address loss of avenue for differentiation, via data shape standard authors should seek to ensure there are other ways in which providers can differentiate.\nThese could be built into the standard such as optional batching, allowing providers to offer tiers of batching support for their endpoints.\n\n## Use Cases\n\n### Multi-Provider Wallets\n\nWallets may wish to allow users to bring their own data layer provider (on public or custom networks).\nBy having a standard interface wallets would be able to support this, which would reduce the wallet's operating costs.\nFor the users this gives them flexibility, redundancy and the option to run their wallet on their own infrastructure. \n\n### DApps Avoiding Lock-In\n\nDApp developers don't want to tie their infrastructure to one query layer provider.\nBy being able to switch providers without the need for significant engineering, they can avoid providers which do not offer fair pricing.\n\n### New Infrastructure Providers\n\nNew Cardano infrastructure providers want to be able join pools of interchangeable query layer suppliers.\nWithout standardization new providers must invest significant time to develop their own backends (including APIs).\n\n## Goals\n\n1. Create an extensive query layer API specification that is not tied to any particular implementation\n\n2. Describe how can it be used in different contexts: HTTP API, JavaScript interfaces, browser-based wallets, standalone wallets, dApp backends.\n\n3. A query layer standard which meets the needs of query layer providers, wallet developers and dApp developers.\n\n## Open Questions\n\n### How can we encourage query layer providers to adopt the solution?\n\nSuch standardization could have drawbacks for existing query layer providers.\n\nThe primary argument against such an initiative is the potential loss of business advantage from query layer providers.\nAs standardized providers would loose the ability to differentiate themselves via data shape and language.\n\nFor providers which charge per request this can negatively impact their ability to control their value proposition.\nSuch providers are currently incentivized to make the data returned via queries contain the least possible useful information.\nStandards would mean providers would not be able to control the amount of data that is returned upon a query.\nThis would mean existing providers would have to adjust their business and value proposition to customers.\n\n### How can we encourage wallet developers to adopt the solution?\n\nFor wallet providers, a standardized query layer would offer long term benefits which outweigh any upfront engineering costs.\nWith users being able to bring their own data providers, wallets will incur less costs to the use of their providers.\n\n### How can we encourage dApp developers to adopt the solution?\n\nDApp developers would benefit from a more open and competitive query layer market.\nDevelopers will be able to choose the provider which best fits the needs of their dApp.\n\n### How can we address multiple Cardano ledger eras?\n\nHow a standard distinguishes between data from different Cardano ledger eras is something that needs to be addressed.\nShould providers be expected to support a superset of all Cardano eras?\n\n## Acknowledgements\n\n<details>\n  <summary><strong>Workshop 1 - 2024-01-25</strong></summary>\n\n  We would like to thank those that contributed to the first Query Layer Standardization workshop hosted by The Wallets Working Group ([see shared drive with resources](https://drive.google.com/drive/folders/1baSYHfWJdUh5dwRkHjY7qnaufjuO8sP2?usp=sharing)).\n\n  Hosts:\n\n  - Ryan Williams\n  - Adam Dean\n\n  Participants:\n\n  - Dmang\n  - George APEX Pool\n  - Leo H\n  - Marcin Szamotulski\n  - Markus Gufler\n  - Matt Davis\n  - Matthieu Pizenberg\n  - Michael Chappell\n  - NEXUS Crypto\n  - Nick Cook\n  - Rhys Bartels-Waller\n  - Ruslan Dudin\n  - Torbjørn Løvseth Finnøy\n\n</details>\n\n## Copyright\n\nThis CPS is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)."
  },
  {
    "path": "CPS-0013/README.md",
    "content": "---\nCPS: 13\nTitle: Better builtin data structures in Plutus\nCategory: Plutus\nStatus: Open\nAuthors:\n    - Michael Peyton Jones <michael.peyton-jones@iohk.io>\n    - Philip DiSarro <philip.disarro@iohk.io>\n    - Pi Lanningham <pi@sundaeswap.finance>\nProposed Solutions: []\nDiscussions:\n    - Original pull request: https://github.com/cardano-foundation/CIPs/pull/638\nCreated: 2023-12-14\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nPlutus Core lacks builtin data structures with good asymptotic performance for some use cases.\n\n## Problem\n\nPlutus Core has a few builtin data structures, but these are mostly used to make a minimally adequate representation of the `Data` type. \nIt does not have builtin data structures optimized for performance.\n\nUsers can implement their own data structures (since Plutus Core is an expressive programming language), but in practice this has not happened much. \nIn particular, we will focus on two examples here:\n\n1. Arrays with constant-time lookup\n2. Maps with logarithmic-time lookup (also Sets, but we can treat them as a special case of Maps)\n\nBoth of these are difficult to implement in Plutus Core:\n\n1. Arrays are (we believe) impossible without some kind of primitive with constant-time lookup\n2. Maps are possible but are typically moderately complex data structures which require a lot of code, and this has not been done in practice\n\n## Use Cases\n\n### Arrays\n\n#### Order matching\n\nA common pattern in DEXs is to have a list of inputs/outputs to match up in a datum. \nIn some cases the order is highly significant, e.g. earlier orders should be processed first, and the outcome of processing an earlier order may affect later ones.\n\nFor example, we might have:\n```\ninputIdxs :: BuiltinList Integer\noutputIdxs :: BuiltinList Integer\n```\nWe then want to go through these lists, looking up the corresponding inputs and outputs and check some property (e.g. that the value is directly transferred from one to the other).\n\nThis requires a quadratic amount of work, which puts a low ceiling on how many orders can be processed at once. \nEmpirically, many are capped at about 30, whereas if they were limited only by the amount of space in the transaction for inputs and outputs the limit would be hundreds.\n\nIf we had arrays with constant time indexing, we could make this linear instead. \nNote that unless we also implemented the \"Data fields\" suggestion below we would still need to do a linear amount of work to create arrays for the transaction inputs and outputs from the lists in the script context.\n\n#### Data fields\n\nThe `Data` type has a `Constr` alternative which is used for encoding datatype constructors. \nThis is used for encoding the script context, and is used by languages such as Aiken extensively for representing user-defined datatypes also.\n\nThe fields of the constructor are encoded in a list; hence to access a particular field the compiled code needs to do a linear amount of work. \nIf the arguments to a `Constr` were an array, we could access the fields in constant time.\n\nSimilarly, the `List` and `Map` constructors of `Data` could use arrays.\n\n### Maps\n\n#### Operations on `Value`\n\nThe `Value` type is a nested map: it is a map from bytestrings (representing policy IDs) to maps from bytestrings (representing token names) to integers (representing quantities).\nSince map operations are currently linear, this means that even simple operations like checking whether one value is less than another can have quadratic cost.\n\nThis would be much better if map operations were logarithmic cost.\n\n#### Indexing by party\n\nMany applications have a known set of participants identified by some bytestring, typically a public key. \nIt is therefore natural to store per-party state in a map indexed by the party identifier.\n\nSince map operations currently have much worse complexity than a good map data structure (often linear/quadratic instead of logarithmic/linear), this is needlessly expensive and imposes a limit on the number of parties.\n\n## Goals\n\n1. Reduce the cost of operations on `Value` by a factor of 2-10\n2. Reduce the cost of a matching algorithm such that we can handle hundreds of matches for the same cost it currently takes to do 30.\n\n## Open Questions\n\n- Can we implement a set/map data structure in Plutus Core code that has acceptable performance and doesn’t require too much size overhead?\n- Do we need generic maps or is a map-from-bytestring sufficient? What about map-from-integer?\n    - Generic maps are harder since we typically need to know how to order the key type\n- Is an array type useful even if it is immutable?\n    - We are unlikely to be able to offer mutable arrays\n- Are builtin data structures useful enough even if they can only contain builtin types?\n    - This would mean that complex data structures would have to be stored inside arrays as `Data`, rather than using Scott encoding or sum-of-products representation\n- Can we feasibly change the structure of the builtin `Data` type so that `Constr` arguments are in an array?\n    - We would need to retain both versions for backwards compatibility\n    \n## References\n\n- https://x.com/Quantumplation/status/1733298551571038338?s=20\n\n## Copyright\n\nThis CPS is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CPS-0014/README.md",
    "content": "---\nCPS: 14\nTitle: Register of CBOR Tags for Cardano Data structures\nCategory: Tools\nStatus: Open\nAuthors:\n  - Steven Johnson <steven.johnson@iohk.io>\nProposed Solutions:\n  - CIP-0114 | CBOR Tags Registry: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0114\nDiscussions:\n  - Original pull request: https://github.com/cardano-foundation/CIPs/pull/751\n  - CIP-0114 pull request: https://github.com/cardano-foundation/CIPs/pull/752\nCreated: 2024-01-24\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nCardano uses CBOR for a lot of data structures, both on and off chain.\nCBOR defines a number of tags which identify the types of encoded data, and IANA maintain a registry of these tags.\nCardano data structures could benefit from consistent tagging of CBOR fields.\n\n### **Acknowledgements**\n\nThank you to the following people who helped review this draft before it was published:\n\n* Ryan Williams\n\n## Problem\n\n[CBOR] defines the ledger contents, transactions, and commonly the metadata attached to transactions.\nFor example [CIP-0036] metadata used for registering voters in Project Catalyst.\n[CBOR] defines a set of [CBOR Tags] which are used to define the type of data being encoded.\nWhile [CBOR] defines a basic set of [CBOR Tags] it also defines a [CBOR Tags Registry] to enable further tags to be defined.\n[IANA][IANA - Homepage] maintains a registry of CBOR Tags at [IANA - CBOR Tags Registry][IANA].\n[BCR-2020-006] defines CBOR tags related to some blockchain data structures.\nMost (all?) of these are registered with IANA.\n\nWithout Tags, [CBOR] data types can become ambiguous and rely on comments in a specification to help resolve the contents.\n[CBOR] tags unequivocally disambiguate the encoding of data.\nThey also help with forward compatibility and extensibility of data structures.\n\nHowever, with the exception of [#6.258] there are no Cardano specific registered tags.\nAlso, Tag use in CIPs is currently haphazard and inconsistent.\nFor example, [CIP-0042] uses tag **#6.102**, which [IANA] list as \"Unassigned\".\nThis Tag is able to be assigned by IANA at any time.\nIt's unofficial use could break, if a decoder tries to interpret the data according to it's official [IANA] assignment.\n\nDefining a CBOR tag for a Cardano data structure will also define a canonical representation for the data type so tagged.\nThis will help with interoperability and consistency of specification.\nCIPs can simply refer to the Tag, and the CIP in which it is defined, rather than define how that data will be represented.\n\n## Use Cases\n\nIn Project Catalyst CIP-36 a Voting key is defined as:\n\n```cddl\n$cip36_vote_pub_key /= bytes .size 32\n```\n\nThis is a public [ED25519-BIP32] key.\nIf is used to validate that a Vote has been signed correctly by the registered voter.\n\nHowever, there are a couple of issues:\n\n1. How the Key is encoded is NOT defined.\n   1. It is 32 bytes, but is it Big-endian or Little-endian encoded?\n2. The kind of key is defined only in the words of the specification.\n\nIf there was a canonical specification for tagging and encoding [ED25519-BIP32] keys.\nAnd say that tag was `7777`, then this could be defined simply as:\n\n```cddl\n$cip36_vote_pub_key /= #6.7777(bytes .size 32)\n```\n\nWithout any extra information, it can be now determined the Key type that is valid, and the encoding.\nThis would lead to greater clarity and simpler specifications.\n\nIt would also allow simple and unambiguous extension.\nSay Project Catalyst desired to also the use of Signing Public Keys as defined in [BCR-2023-011].\nAll it needs to do is define that `#6.40022` is a valid public key type.\nThe decoder would be able to unambiguously identify the key type.\nThe basic metadata encoding would not need to change, just the list of valid public key types.\nA decoder based on an older version of the specification would be able to detect that the new key type was not supported.\nThis would provide forward compatibility.\n\n## Goals\n\n1. Definitive sources of truth for CBOR encoding of common Cardano data structures.\n2. Uniform use of CBOR tags to unambiguously identify common Cardano data structures inside CBOR.\n3. An easily accessible reference to all CBOR tags defined by CIPs, to help eliminate their re-definition.\n4. Guidelines on the creation of new CBOR tags as data structures emerge, or existing data structures are formalized.\n5. Clarity on who is responsible to have new Tags registered with IANA.\n\nIt is NOT a goal of this CPS to cause all pre-existing Cardano data structures to be standardized with CBOR tags.\nIndividual projects should evaluate if the existing tags are sufficient or if they require new ones for their purposes.\nit would then be the responsibility of the project to raise a CIP to standardize the CBOR tag for the pre-existing data structure.\n\nIt is also not a goal of this CPS to define how general data structures are tagged.\nThe data structure should be either defined by a CIP or integral to Cardano.\nAn example is `ULID` this has no current CBOR Tag, but it is not defined by a CIP nor integral to Cardano.\nEven though a CIPs metadata may use one, its formalization should be done outside the CIP process.\n\n## Open Questions\n\n* Should we define a canonical list of tags, the CIP they are defined in, and if they are IANA registered or not?\n* Who should register the Tag with IANA?\n  * Would this become a necessary part of the \"path to Active\" of any CIP which defines a CBOR tag?\n* How should duplicate structures be handled (same data encoded differently with a different tag)?\n* Should defining tags be their own CIP, or can they be part of a larger CIP?\n* Should we define recommendations for the use of Tags in Metadata CIPs?\n\n## References\n\n* [CIP-0036 - Catalyst Registration Transaction Metadata Format (Updated)][CIP-0036]\n* [CIP-0042 - New Plutus Builtin serialiseData][CIP-0042]\n* [RFC8949 - Concise Binary Object Representation (CBOR)][CBOR]\n* [BCR-2020-006 - Registry of Uniform Resource (UR) Types][BCR-2020-006]\n* [BCR-2023-011 - UR Type Definitions for Public Key Cryptography][BCR-2023-011]\n* [IANA CBOR Tag Registry][IANA]\n\n## Copyright\n\nThis CPS is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n\n[CIP-0036]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0036\n[CIP-0042]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0042/README.md\n[CBOR]: https://datatracker.ietf.org/doc/html/rfc8949\n[CBOR Tags]: https://datatracker.ietf.org/doc/html/rfc8949#name-tagging-of-items\n[CBOR Tags Registry]: https://datatracker.ietf.org/doc/html/rfc8949#ianatags\n[IANA - Homepage]: https://www.iana.org/\n[IANA]: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml\n[BCR-2020-006]: https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-006-urtypes.md\n[ED25519-BIP32]: https://github.com/input-output-hk/adrestia/raw/bdf00e4e7791d610d273d227be877bc6dd0dbcfb/user-guide/static/Ed25519_BIP.pdf\n[BCR-2023-011]: https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-011-public-key-crypto.md\n"
  },
  {
    "path": "CPS-0016/README.md",
    "content": "---\nCPS: 16\nTitle: Cardano URIs\nCategory: Tools\nStatus: Open\nAuthors:\n  - Adam Dean <adam@crypto2099.io>\n  - Mad Orkestra <mad@madorkestra.com>\nProposed Solutions:\n  - CIP-0013: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013\n  - CIP-0099: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0099\n  - CIP-0107: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0107\n  - CIP-0134: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0134\n  - CIP-0158: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0158\n  - CIP-0162: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0162\nDiscussions:\n  - Issue - CIP-0013 Current state of integration and further advancements: https://github.com/cardano-foundation/CIPs/issues/836\n  - CIP-0013 pull request: https://github.com/cardano-foundation/CIPs/pull/559\n  - CIP-0107 pull request: https://github.com/cardano-foundation/CIPs/pull/635\n  - Original pull request: https://github.com/cardano-foundation/CIPs/pull/841\n  - CIP-0134 pull request: https://github.com/cardano-foundation/CIPs/pull/888\nCreated: 2024-06-15\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nCardano URI schemes ([CIP-0013]) have been defined since early 2021. However, some\nof the proposed standards have languished and struggled for adoption event as\nthe amount of wallet developers in the ecosystem has skyrocketed. This CPS aims\nto create a centralized point of reference for those interested in creating new\nstandards or publishing integration solutions.\n\n## Problem\n\nA keen pain point in the utilization of blockchain is the archaic and convoluted\nprocesses necessary to interact with the blockchain or cite historical ledger\ndata. Well-defined URI schemes can provide a plethora of easy access and\ninteraction methods, particularly to mobile users, since they can leverage\ndeep-linking and QR technologies to pass data between applications.\n\n## Use Cases\n\nThe Cardano URI Scheme(s) that exist already present several fantastic use cases\nfor URI schemes. We welcome additional or expanded definitions to be added to\nthis section for further discussion, development, and adoption by the community.\n\n### Easy On-Chain Interactions\n\n#### Payments\n\n1. The original specification of [CIP-0013][CIP-0013-payment] defined only the\n   base `web+cardano:` **scheme** and an **authority**-less path consisting of a\n   payment address and an optional `amount` query parameter to specify via QR\n   code or deep-link an address and amount of Lovelace to send.\n2. In 2024 [a new CIP was proposed](https://github.com/cardano-foundation/CIPs/pull/843) defining an explicit `//pay`\n   **authority** as well as path and query parameters to support _Native Assets_\n   and transaction _Metadata_.\n\n#### Staking/Delegation\n\n1. The first extension to [CIP-0013][CIP-0013-staking] added the `//stake`\n   **authority** and some query parameter options to specify a Cardano Stake\n   Pool. The goal of these URIs would be to make it easy for a user to switch\n   their wallet's stake delegation to the pool in question. This could be\n   performed via easy deep-link integration on stake pool website(s) and social\n   media, and also through real-world advertising such as banners, flyers, and\n   business cards at marketing and networking events.\n\n#### Onboarding/Airdrops\n\n1. In 2023 [CIP-0099] was introduced, adding a `//claim` **authority** and\n   defining a URI + wallet interaction protocol that would allow a user with\n   only access to a URI to \"claim\" an airdrop of _Lovelace_ and/or _Native\n   Assets_ assuming that both the wallet and the project server were correctly\n   configured to follow the protocol.\n\n#### Open URLs in the in-app browser\n\n1. In 2026 [CIP-0158] introduced a new `//browse` **authority** defining a URI\n   with versioning to allow opening a percent-encoded `https://` or `http://` address\n   including forwarded parameters in the in-app browser of mobile wallets with\n   the intent to gain easier access to the full wallet functionality and improve\n   the overall mobile user experience.\n\n#### DRep links\n\n1. Also in 2026 [CIP-0162] introduced a new `//drep` **authority** defining a new\n   URI and wallet behaviour for frictionless DRep delegation, taking in a [CIP-0129]\n   DRep-Id with the intent to open the wallet-app, validate the DRep-Id against\n   on-chain data and - if a valid Id of a registered DRep has been provided -\n   create a governance delegation transaction for the user to sign and submit.\n\n### Easy Historical Reference\n\n#### Blocks and Transactions\n\n1. In 2023 [CIP-0107] was proposed, this CIP introduced the `//block` and\n   `//transaction` **authorities** along with relevant **path** and **query**\n   parameters. This novel use of URI structures allows for easy reference to\n   specific events and points in time of the blockchain ledger's history. This\n   proposal makes referencing a point in the chain's history relatively trivial\n   which can be an important step in data availability layers for external on-\n   and off-chain solutions.\n\n## Goals\n\nThe goals of this CPS are as follows:\n\n* [X] Provide an easy-to-reference repository for all `web+cardano:` URI\n  solutions to simplify integrations.\n* [X] Define a list of known `web+cardano:` URI authorities to prevent overlap\n  and collision by developers creating new solutions.\n* [X] Provide a platform to centralize new discussions about emerging standards\n  that may arise in the future.\n\n## Open Questions\n\n1. What can we do as a community to encourage more applications and software\n   providers to support `web+cardano:` URIs?\n2. What software or best practices exist to aid developers in deploying support\n   for `web+cardano:` URIs?\n3. What new authorities or protocols could be built to leverage these URIs?\n4. What does the process look like to register a new `web+cardano:` URI\n   authority or protocol?\n\n### Proposal Process\n\nRecent best practices in this repository suggest that the preferred method is\nfor new standards that expand functionality should be defined as new, discrete\nCIPs unless the existing CIP provides for the capability of versioning and\niterative improvement.\n\nBy creating separate, discrete CIPs for new standards this allows for a clean\nhistory of discussion and community consensus building around new standards as\nwell as measurable progress towards adoption.\n\n### Registered URI Authorities\n\nPer [URI Syntax] a URI consists of the following structure:\n\n```abnf\nURI = scheme \":\" [\"//\" authority] path [\"?\" query] [\"#\" fragment]\n```\n\nGiven that the shared scheme of `web+cardano:` is known and accepted and the\noriginal version of [CIP-0013] declared an authority-less, path-only structure:\n**All future `web+cardano:` URI extensions MUST register a new, unique authority\nor SHOULD define a new version of an existing **authority** that has explicitly\nallowed for versioning in its definition.\n\nThe following are the currently registered URI **authorities** mentioned in\nCIPs:\n\n* `null`: (Blank/no Authority) registered in [CIP-0013][CIP-0013-payment]\n* `//stake`: registered in [CIP-0013][CIP-0013-staking]\n* `//claim`: supports versioning, registered in [CIP-0099]\n* `//transaction`: supports versioning (?), registered in [CIP-0107]\n* `//block`: supports versioning (?), registered in [CIP-0107]\n* `//addr`: registered in [CIP-00134]\n* `//browse`: registered in [CIP-0158]\n* `//drep`: registered in [CIP-0162]\n\n## Copyright\n\nThis CPS is licensed under [CC-BY-4.0].\n\n[CIP-0013]:https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013\n\n[CIP-0013-payment]:https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013#for-payment-uris\n\n[CIP-0013-staking]:https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013#for-stake-pool-uris\n\n[CIP-0099]:https://github.com/cardano-foundation/CIPs/tree/master/CIP-0099\n\n[CIP-0107]:https://github.com/cardano-foundation/CIPs/tree/master/CIP-0107\n\n[CIP-0129]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0129\n\n[CIP-00134]:https://github.com/cardano-foundation/CIPs/tree/master/CIP-0134\n\n[CIP-0158]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0158\n\n[CIP-0162]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0162\n\n[CC-BY-4.0]:https://creativecommons.org/licenses/by/4.0/legalcode\n\n[URI Syntax]:https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Syntax\n"
  },
  {
    "path": "CPS-0017/README.md",
    "content": "---\nCPS: 17\nTitle: Settlement Speed\nCategory: Consensus\nStatus: Open\nAuthors:\n  - Arnaud Bailly <arnaud.bailly@iohk.io>\n  - Brian W. Bush <brian.bush@iohk.io>\n  - Hans Lahe <hans.lahe@iohk.io>\nProposed Solutions:\n  - CIP-0140 | Ouroboros Peras - Faster Settlement: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0140\n  - CIP-0161 | Ouroboros Phalanx - Breaking Grinding Incentives: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0161\nDiscussions:\n  - Original pull request: https://github.com/cardano-foundation/CIPs/pull/1065\nCreated: 2024-09-30\nLicense: Apache-2.0\n---\n\n## Abstract\n\nExisting and emerging Cardano use cases would greatly benefit from faster \"settlement\" or \"finality\" of transactions. Moreover, some current and pending use cases are hampered or blocked by not having transaction settlement within minutes of including of a transaction on a block. Examples are partner chains, bridges, exchanges (centralized and decentralized), Dapps, and ordinary high-value transactions. Although rollbacks of transactions on the Cardano `mainnet` are uncommon because of the careful design of the Ouroboros protocol and the robust implementation of the Cardano node's memory pool and block diffusion, extraordinary adversarial conditions can in principle produce forks that cause impactful rollbacks with some probability: stake-based and CPU-based attacks might seek to create long-lived adversarial forks, for example. The Cardano `mainnet` currently has a 5% active slot coefficient and a security parameter of 2160 blocks (approximately 12 hours). Recent research indicates that for faster settlement (precisely defined in terms of stakeholder use cases) the Ouroboros protocol logic could be modified and the active slot coefficient could be optimized.\n\n\n## Problem\n\nFast settlement is a critical part of Cardano scaling, as described in [*Scaling blockchain protocols: a research-based approach*](https://www.youtube.com/watch?v=Czmg9WmSCcI). Under Ouroboros Praos, settlement occurs probabilistically on the Cardano blockchain, where the probability that a block will be rolled back from the preferred chain decreases exponentially as the chain grows beyond the block and where that rate of decrease is slower when adversarial activity is stronger. Some use cases require high assurance that a block (and the transactions within it) will not be rolled back, necessitating a potentially lengthy wait before a transaction is considered \"settled\" or \"finalize\". Some major centralized exchanges, for example, require fifteen confirmations (i.e., blocks) before a transaction is considered settled: this amounts to waiting ten minutes before a consumer has their transacted funds or tokens available for subsequent use. This situation is not unique to Cardano: centralized exchanges generally require at least five minutes wait for most of the common blockchains. Partner chains, Dapps, or bridges may have stringent requirements for fast and highly certain settlement.\n\nThere are several definitions of \"settlement\" or \"finality\", and precision is important when discussing these. Two noteworthy scenarios can be defined precisely. Both scenarios are expressed in terms of the probability a transaction or block that's been observed _locally_ to be part of the chain will be rolled-back in the future. Remember that rollbacks are the natural consequence of the eventually consistent nature of blockchains.\n\n- *Ex ante* settlement probability: \"What is the probability that a transaction that I just submitted will ever be rolled back?\"\n- *Ex post facto* settlement probability: \"Given that I submitted my transaction $x$ seconds ago and it has not yet been rolled back, what is the probability that it will ever be rolled back?\"\n\nEven better would be to have an on-chain indication that transactions up to a particular point have been settled with high probability.\n\nIf one is unwilling or unable to re-submit a rolled-back transaction, then the *ex ante* probability might be of most interest. This matches use cases where there is no opportunities for the parties involved in a transaction to resubmit it: for example, one party might have purchased physical goods and left the vendor's premises, leaving no chance to resubmit a rolled-back transaction.\n\nOther use cases are better suited for *ex post facto* settlement: for example, a partner chain, bridge, or decentralized exchange can monitor the ledger for a fixed time and see that the transaction either is not or is rolled back, knowing that there is only a vanishingly small chance of that status ever changing once they have watched the chain for the fixed amount of time, giving them an opportunity to re-submit the transaction if it was rolled back. Both opportunity and back-end infrastructure distinguish these use cases. Protocol research has historically focused on optimizing *ex post facto* certainty after predefined waiting times.\n\nSettlement failures (i.e., roll backs, \"slot battles\", and \"height battles\") can occur naturally as short forks occur due to multiple slot leaders being elected in the same slot or due to network delays. Under typical uncongested conditions such forks often do not create settlement failures because a user's transaction tends to the diffuse throughout the global memory pool and is included in a block on each of the honest, naturally occurring forks. Careful observation might reveal that the transaction was rolled back from one fork but was adopted on the newly preferred fork. Cardano tooling should routinely deal with such situations even though they are rarely apparent to or affect end users. Most wallets do not display information about such short forks and rollbacks to users. Short forks occur hourly at local Cardano nodes, but globally visible forks are much less common, and anecdotal evidence indicates that rollbacks of more than three blocks never occur on a large scale on Cardano `mainnet`.  (There may be one exception to this, however, where a longer rollback is said to have occurred.) As with settlement, a precise definition of near-global rollbacks is required to measure and discuss this phenomenon in detail.\n\nCasual perusal of information about Cardano on the internet reveals a wide variety of conflicting explanations and assertions regarding settlement and finality. The terms \"settlement\" and \"finality\" are not clearly defined in the context of Cardano and statements about them range from saying that only one block/confirmation is required to consider a transaction settled to 2160 blocks or 12 hours is required for settlement. The Ouroboros security parameter *k* also seems poorly described.\n\nMany centralized exchanges have published the number of confirmations (blocks) required for them to consider a transaction settled. Taking Kraken as an example,[^1] we see in the following table the significant delay required for transactions to be treated as final. Cardano is not among the cluster of fast-settling blockchains. (Note that the following table contains internal contradictions between the \"confirmation\" column and the \"time\" column, a situation which further highlights imprecise understanding of settlement.)\n\n| Blockchain | Confirmations Required | Approximate time (minutes) |\n| ---------- | ---------------------: | -------------------------: |\n| Algorand   |                     10 |                          1 |\n| Aptos      |                     50 |                          5 |\n| Avalance   |                     20 |                          1 |\n| Bitcoin    |                      3 |                         30 |\n| Cardano    |                     15 |                         10 |\n| Dogecoin   |                     40 |                         40 |\n| Ethereum   |                     70 |                         14 |\n| Polkadot   |                    n/a |                          5 |\n| Ripple     |                    n/a |                          0 |\n| Solana     |                    n/a |                          0 |\n| Tezos      |                      6 |                          3 |\n[^1]: Data extracted from [https://support.kraken.com/hc/en-us/articles/203325283-Cryptocurrency-deposit-processing-times](https://support.kraken.com/hc/en-us/articles/203325283-Cryptocurrency-deposit-processing-times) on 7 August 2024.\n\nCardano Dapps and DEXes vary quite a bit regarding how many confirmations they require before they consider a transaction settled. As few as one confirmation is required for some Dapps, but other require twelve hours.\n\nWhen Cardano becomes used by large institutions or nation states, attacks on settlement may become more attractive and lucrative. Hence, it is not safe to assume that stake-based and grinding attacks will not occur in the future.\n\n## Use Cases\n\nFast settlement primarily benefits use cases where a party needs certainty, after a fixed amount of time, about the settlement status of a transaction. The generic use case follows.\n\n1. The party submits a transaction to the local memory pool.\n2. A block producer includes the transaction in a newly forged block.\n3. After a fixed time passes or a specific indication is observed, the party considers their transaction settled.\n4. Contrarily, the party might observe that their transaction was rolled back from the preferred chain, so they may choose to resubmit it to the memory pool.\n\nSpecific use cases involving time-constrained, high-value transactions conform to this generic pattern. When the value at risk is low, a one-in-a-million chance of a rollback might not be as concerning as it would be for a large transaction. Examples follow.\n\n- Centralized exchanges, where fast settlement improves the user convenience and experience\n- Partner chains and bridges, where certainty about synchronization between two chains is essential\n- Dapps where fixed-horizon certainty is needed to orchestrate transactions\n- Ordinary transactions where a brief wait is acceptable but a roll-back is not\n\nFor example, the partner-chain use case might leverage faster settlement as follows. The desired target for cross-chain transfers is on the order of minutes.\n\n1. Funds or tokens need to be transferred from the partner chain to the Cardano chain.\n2. A smart-contract transaction escrows the funds/tokens on the partner chain.\n3. Simultaneously, a mirror of that smart-contract transaction is submitted on Cardano.\n4. After a short amount of time, the Cardano transaction has been incorporated into a newly-formed block.\n5. Wait for settlement or non-settlement, either by waiting for a specific number of blocks to cover the transaction or by observing some other aspect of the chain.\n\t1. If the transaction settled, complete the escrow contract on the partner chain.\n\t2. If the transaction was rolled back, resubmit it.\n\nTwo prominent use cases are the Cardano-Midnight ZK Bridge and the Cardano-Bitcoin BOS Grail Bridge. These bridges and partner chains likely will require fast settlement on Cardano if they intend to keep chains in sync and rapidly move value to/from Cardano.\n\n\n## Goals\n\nThe overall goals are to precisely define settlement metrics and to propose protocol or parameter changes that significantly speed settlement without negatively impacting performance or security.\n\n1. Develop precise settlement/finality metrics relevant for stakeholders.\n\t1. Some metrics should be defined in terms of the whole life cycle of a transaction, from its submission to the memory pool to its becoming settled in a block.\n\t2. Block- versus slot-based metrics have importance for different use cases.\n\t3. Embody these metrics in an open-source library or toolkit for estimating settlement times or measuring finality of Cardano transactions.\n\t4. Create metrics that are practical for wallets to implement and to present clearly to users.\n2. Shorten settlement time, as defined by stakeholder-relevant metrics, in the face of even moderate adversarial activity.\n\t1. Stake-based adversaries.\n\t2. Attacks utilizing adversarial resources (CPU or network).\n\t3. Natural disruption of infrastructure or networks (e.g., data-center or internet outages).\n4. Fall back to Praos-like security in the face of strongly adversarial conditions.\n\nIt addition to the goals above, it is advisable to avoid the following potentially costly changes.\n\n1. Avoid making major changes to the existing Ouroboros protocol parameters or logic.\n2. Do not weaken Ouroboros security or substantially enlarge its attack surface.\n3. Minimize changes that increase the resource usages of Cardano nodes or the cost of operating them.\n\nThree approaches are under active consideration or development to address the settlement and finality problem. The first two mitigate stake-based and grinding attacks, respectively.\n\n- *Voting approaches* strengthen the weight of the preferred chain, making it extremely difficult to roll back blocks on the prefix of the chain that was made weightier by a quorum (consensus) of stake-based votes. [Ouroboros Peras](https://github.com/cardano-foundation/CIPs/pull/872) is an example of this. This approach does not mitigate CPU-resource attacks.\n- *Anti-grinding approaches* make prohibitively expensive any attacks that rely on CPU resources to weaken cryptographic guarantees of the pseudo-randomness of the slot-leadership schedule. This approach does not mitigate stake-based attacks, but grinding requires some stake in order to manipulate the slot-leadership schedule.\n- *The protocol-parameter approach* simply lowers the active slot coefficient (currently set to 5% of the slots on `mainnet`) to a somewhat lower value, so that the block production rate and settlement are faster. This approach can only moderately shorten settlement times and does not mitigate against the aforementioned attacks.\n\n\n## Open Questions\n\n- Is finality on the order of a couple of minutes feasible on Cardano? What is the theoretically fastest finality possible for a Praos-like consensus algorithm?\n- What definitions of settlement and finality are most relevant to Cardano stakeholder use cases? Is a single definition common to all use cases?\n- How best can empirical data on Cardano `mainnet` settlement and finality be collected and communicated?\n- Can a single approach to faster settlement work in the face of both stake-based and resource-based adversaries?\n- Would faster settlement negatively impact or be undercut by other planned Cardano node updates?\n- What are the trade-offs between settlement speed, throughput, performance, and security?\n- To what extent would tiered pricing for transactions improve settlement times for high-value transactions.\n- Is \"rollback insurance\" a viable alternative to shortening settlement times?\n\n\n## Copyright\n\nThis CPS is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CPS-0018/README.md",
    "content": "---\nCPS: 18\nTitle: Greater Transaction Throughput\nCategory: Consensus\nStatus: Open\nAuthors:\n  - Arnaud Bailly <arnaud.bailly@iohk.io>\n  - Brian W. Bush <brian.bush@iohk.io>\n  - Hans Lahe <hans.lahe@iohk.io>\nProposed Solutions: []\nDiscussions: \n  - Original pull request: https://github.com/cardano-foundation/CIPs/pull/925\nCreated: 2024-10-11\nLicense: Apache-2.0\n---\n\n\n\n## Abstract\n\nThe Cardano mainnet occasionally experiences congestion where there are too many transactions in the memory pool to be included in the next block or in the next few blocks. Sometimes the block utilization peaks above 90% for an extended period of time. This not only impacts general user experience but it can also severely impact use cases such as airdrops, oracles, partner chains, DEXes, and Dapps. Emerging use cases and application deployments promise to accelerate the need for high throughput on Cardano. Applied research on several fronts is needed to propose and provide evidence for techniques that increase throughput measured in terms of transactions, transaction size, and script execution units. Such work should be based on a clear understanding of stakeholder requirements.\n\n## Problem\n\nThe Cardano mainnet occasionally encounters periods of congestion, where the number of pending transactions in the memory pool exceeds the network's capacity to include them in the upcoming block or even the next several blocks. During these times, block utilization can consistently peak above 90%, sometimes for an extended duration. This high level of congestion not only degrades the general user experience by causing delays in transaction processing but also poses significant challenges for specific use cases. For instance, activities such as airdrops, which require efficient processing of large numbers of transactions, can be significantly hampered. Similarly, oracles that depend on timely data updates might face disruptions, while partner chains could experience slower cross-chain interactions. The impact is also felt by decentralized exchanges (DEXes) that need fast transaction confirmations to maintain liquidity and decentralized applications (DApps) whose performance and user interactions are affected.\n\nMoreover, the ongoing evolution of the Cardano ecosystem is expected to amplify these demands. New and emerging use cases, along with an increasing number of application deployments, are likely to accelerate the need for higher throughput and improved scalability on the network. As the ecosystem expands to support more diverse and sophisticated use cases, such as real-time financial applications, gaming, or supply chain solutions, the pressure on Cardano's infrastructure to handle larger transaction volumes efficiently will continue to grow. Addressing these scaling challenges will be essential to ensure a seamless experience for users and to maintain Cardano’s competitive position in the rapidly evolving blockchain space.\n\nCardano's current throughput (measured both in data rate and available script execution units) is usually (but not universally) adequate for the current demand. There is also some protocol-parameter opportunity to increase the block sizes and script execution limits to meet emerging future demands for increased network capacity. There are however fundamental limits to how far the block size and the script execution budget can be pushed, while maintaining system security.\n\nIn Ouroboros Praos, maintaining the security of the system requires that blocks be distributed reliably across the network within a specified time frame, known as $\\Delta$, which is set at five seconds on the Cardano mainnet. The process of relaying blocks is inherently sequential: blocks are transmitted from one block producer node to the next through a series of intermediary relay nodes. The time required for this process depends on the number of network hops between consecutive block producers and the network latency associated with each hop, considering that these hops often span the entire globe. Since this entire operation must consistently be completed within a five-second window, it imposes strict limitations on the maximum block size and the amount of time available for validating transactions and scripts.\n\nTo significantly scale beyond these limitations, fundamental changes to the overall blockchain algorithm are necessary. The potential for scaling is substantial, as the network and computational resources of most nodes are largely underutilized, remaining almost idle for much of the time. By adopting a different algorithm, these resources could be leveraged more effectively to increase the total bandwidth of the blockchain. Such improvements could enable the system to handle a higher volume of transactions while maintaining security and efficiency, addressing current limitations and unlocking new levels of scalability for the Cardano network. As the blockchain continues to evolve, optimizing the utilization of network and computational resources will be crucial to supporting future growth and expanding the capabilities of the platform.\n\nAdditionally, certain applications demand predictability or specific quality-of-service guarantees to function optimally. These applications might not necessarily need high levels of sustained throughput, but they are particularly sensitive to fluctuations in how quickly a transaction can be processed and included in a block after entering the memory pool. In such cases, even small delays or variances in the time it takes for a transaction to move from the memory pool into a confirmed block can significantly impact the performance, reliability, and user experience associated with these applications.\n\nFor example, in financial services, delays in processing transactions could disrupt trading activities, arbitrage opportunities, or other time-sensitive financial operations where precise timing is critical. Similarly, gaming applications or real-time auctions require transactions to be confirmed quickly to maintain a seamless user experience or to uphold the integrity of the bidding process. Predictable block times are also important for supply chain applications, where time-sensitive tracking and updates must be performed in real-time to reflect changes in inventory or shipments.\n\nQuality-of-service guarantees can also be crucial for smart contracts that rely on external data feeds (oracles). These contracts might need a high degree of predictability in transaction processing to ensure that data updates happen within specific timeframes, thereby maintaining the accuracy of the contract's execution. The lack of consistency in transaction inclusion times could lead to issues such as missed deadlines, inconsistent states, or degraded performance for automated processes.\n\nThus, while the need for raw throughput is one aspect of blockchain performance, the ability to ensure a predictable and stable processing time for transactions is equally important for many applications. Addressing this challenge involves optimizing the underlying network protocol, enhancing transaction prioritization mechanisms, or implementing features that can deliver the necessary guarantees for latency-sensitive use cases. As more sophisticated applications continue to emerge on blockchain platforms, meeting these requirements will be essential to ensuring that the technology can support a diverse range of real-world use cases effectively.\n\n#### Urgency \n\nWhile recent improvements like reference scripts have provided some relief, throughput limitations persist and will become increasingly critical as on-chain activity grows. This is evidenced by events like the launches of SundaeSwap and Snek.fun, where application-level queue times reached days and order processing was severely limited due to block capacity constraints. This hinders Cardano's ability to compete and attract wider adoption.\n\nWhile theoretical maximum TPS provides an indication of potential capacity, real-time TPS offers a more accurate reflection of current network capabilities. Looking at other ecosystem, [the data](https://chainspect.app/dashboard) reveals that the maximum recorded TPS for Solana was 7229 TPS, for Base 93 TPS and for Arbitrum 944 TPS. These figures are relevant for attracting new projects and investments to an ecosystem. Throughput, finality times and gas fees are among the primary technical attributes that projects look for when choosing which web3 network to pick. \n\n| Blockchain | Max Recorded TPS |\n|---|---|\n| Cardano | 12 |\n| Solana | 7229 |\n| Algorand | 5716 |\n| Hedera | 3302 |\n| BNB | 1731 |\n| Arbitrum | 944 |\n| Base | 293 |\n| Polygon | 429 |\n| NEAR | 342 |\n| Ethereum | 62 |\n\nSource for table data: https://chainspect.app/dashboard\n\nTo achieve a sustainable and thriving ecosystem, Cardano needs to handle significantly higher transaction volumes at current or lower fee levels. This necessitates a proactive approach to scaling that goes beyond addressing sporadic spikes in activity and focuses on supporting the growth required for long-term network profitability without relying on inflation. This aligns with the vision of scaling Cardano to support nation-state level usage by 2030.\n\n### Evidence\n\nHistorical data indicates that an appreciable fraction of the blocks on the Cardano mainnet have been nearly full and that periods of high utilization can last for minutes. In such situations it is likely that additional transactions queue up in the nodes' memory pool, awaiting inclusion in a future block. Needless to say, block congestion correlates directly with transaction throughput. With the current average block-production rate of one per twenty seconds, that queuing can translate into unacceptably long waits for a transaction to be included in a block and receive its first confirmation. Even without the additional demand anticipated when new projects come online in the future, there sometimes are periods where user experience is degraded by limited throughput.\n\nThe plots below illustrate the significant frequency of blocks that are nearly full. (The maximum block size since Epoch 335 has been 90,112 bytes.) The six-minute average block size also indicates the presence of full blocks, but the block-size limit does not appear significant in six-hour average. On the epoch-average level there are periodic peaks in block size. Note that when interpreting these diagrams, it is important to consider that transactions will not exactly fill a block. Also, some blocks hit their limit on Plutus execution cost and memory before well below the maximum-size limit: they are, nevertheless, fully utilized.\n\n|                                                            |                                                            |\n| ---------------------------------------------------------- | ---------------------------------------------------------- |\n| ![Distribution of block sizes](images/block-size-1blk.svg) | ![Distribution of block sizes](images/block-size-6min.svg) |\n| ![Distribution of block sizes](images/block-size-6hr.svg)  | ![Distribution of block sizes](images/block-size.svg)      |\n\nOf particular interest is the following plot that shows the distribution of the length of runs of consecutive blocks that are all larger than 80 kB. Occasionally, there are stretches of more than ten blocks being almost full, and in one case there was a series of 194 almost-full blocks. These long periods of nearly full blocks may be correlated with long waits between the time a user submits a transaction to the memory pool and the time it appears in a block.\n\n![Runs of nearly-full blocks](images/block-run.svg)\n\nThe following plots illustrate the situation for memory and execution units relative to the maximum allowed for a block. This confirms the rule of thumb that Plutus memory is a tighter constraint than Plutus steps. A not-insignificant number of blocks are close to or at the Plutus execution limits.\n\n|                                                               |                                                              |\n| ------------------------------------------------------------- | ------------------------------------------------------------ |\n| ![Distribution of block sizes](images/block-mem.svg)          | ![Distribution of block sizes](images/block-steps.svg)       |\n| ![Distribution of block sizes](images/block-memory-epoch.svg) | ![Distribution of block sizes](images/block-steps-epoch.svg) |\n\nMore concerning are the situations shown below where consecutive blocks are near or at the Plutus execution budget. In one case twenty-five consecutive blocks were near that limit.\n\n![Runs of nearly-full blocks](images/block-ex-run.svg)\n\n## Use Cases\n\nEven with the existing rate of transactions on the Cardano mainnet, there are periods where throughput-limits delay the inclusion of transactions in blocks and hamper settlement. Growing and emerging use cases will exacerbate the situation.\n\n- Time-sensitive applications like DEXes and Dapps require prompt inclusion of their transactions on the blockchain, and any delay also translates to a delay in settlement. See also [CPS-17 Faster Settlement](https://github.com/cardano-foundation/CIPs/pull/922).\n- Newly released high-profile Cardano applications tend to create congestion as many users experiment and transact with the new capabilities shortly after they become available. Greater transaction throughput will improve the initial experience of new users of those applications, and some of those new users may be new to Cardano. *First impressions are important.*\n- Partner chains, bridges, and oracles rely on quality of service guarantees that support a regular and predictable rhythm of their transactions being included in blocks. Delays in such transactions' inclusion in blocks can cascade to Dapps that interact with such services. Delays on oracles result in stale data being provided to Dapps or in Dapps having to wait for the updated oracle state to be posted. Delays on partner chains or bridges result in bottlenecks in the transfer of funds or information between chains.\n- Transaction \"scoopers\" and \"batchifiers\" work most efficiently when high throughput is possible.\n- Air drops are well known to have caused spikes in network load and block utilization.\n- Any of the above use cases that also involve executing Plutus scripts add an additional requirement of execution-unit throughput in addition to transaction-size throughput. Applications that do complex validation encounter this extra dimension of resource usage.\n\nThe advent of the Cardano-Midnight ZK bridge and the prospect of a Cardano-Bitcoin BOS Grail bridge promise to significantly increase the transaction load on the Cardano mainnet.\n\n## Goals\n\n1. Develop precise requirements for transaction and script-execution throughput for Cardano mainnet, categorized by use case and metrics for quality of service.\n2. Propose safe increases in the maximum block size and Plutus execution limits for blocks.\n3. Increase transaction throughput in terms of number, size, and execution units and provide evidence that the proposed techniques meet stakeholder requirements.\n4. Investigate and semi-quantitatively compare throughput techniques such as input endorsers, zero-knowledge technologies, transaction prioritization, offloading work (Mithril, partner chains, etc.), and protocol-parameter changes.\n5. Propose methods for guaranteeing specific levels of throughput, including priority tiers and reservations.\n\nIn addition to the goals above, it is advisable to avoid the following:\n\n1. Avoid approaches with long development timelines or high opportunity costs.\n2. Do not weaken Ouroboros security or substantially enlarge its attack surface.\n3. Minimize changes that increase the resource usages of Cardano nodes or the cost of operating them.\n4. Guard against protocol alterations that adversely impact other scaling metrics such as settlement time.\n\n## Open Questions\n\n- How much larger can existing Ouroboros Praos blocks be made without affecting Cardano mainnet safety or performance?\n- How much can the block-production rate (the active-slot coefficient) be increased without affecting Cardano mainnet safety or performance?\n- What fraction of theoretical global network bandwidth can techniques like input endorsers efficiently utilize?\n- Are zero-knowledge techniques a viable option for increasing transaction throughput?\n- How much will implementing greater transaction throughput impact the hardware requirements for and the cost of operating a Cardano stakepool?\n- Will changes to the memory pool be necessary to support transaction throughput?\n- Will increasing throughput adversely affect other performance metrics such as settlement time?\n- Will higher throughput open Cardano to a broader spectrum of denial-of-service and other attacks?\n- To what extent is the Plutus execution budget for blocks a more limiting constraint than the size budget for blocks? What statistics support this? What types of applications hit this constraint, and how often?\n- Can high-throughput solutions simplify the operation of transactions scoopers and batchifiers?\n- Does [Ouroboros Leios](https://iohk.io/en/research/library/papers/high-throughput-blockchain-consensus-under-realistic-network-assumptions/) satisfy stakeholder requirements for greater throughput? Would simpler solutions be adequate in the short term?\n- How much can pay-for-priority schemes alleviation throughput concerns for high-value applications that are particularly sensitive to it?\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0).\n"
  },
  {
    "path": "CPS-0020/README.md",
    "content": "---\nCPS: 20\nTitle: Governance Stakeholder Incentivization\nCategory: Tools\nStatus: Open\nAuthors:\n- Seomon (Cardano After Dark) <Seomonregister@gmail.com>\n- Martin Marinov <martin.marinov@cardano.marketing>\n- Sebastián Pereira Gutiérrez <sebpereira33@gmail.com>\nProposed Solutions: []\nDiscussions:\n- Original pull request: https://github.com/cardano-foundation/CIPs/pull/997\nCreated: 2025-02-13\nLicense: CC-BY-4.0\n---\n\n## Abstract\nThe Cardano governance framework depends on the active participation of Delegated Representatives (DReps), the Constitutional Committee (CC), and Ada holders, alongside the already incentivized Stake Pool Operators (SPOs), to maintain a highly effective, representative and democratic governance structure. Presently, the system's heavy reliance on the altruistic behavior of governance participants, which poses a significant risk, potentially leading to a concentration of voting power among a small, select group. This situation undermines broader community participation and threatens democratic principles. The primary goal should be to establish a balanced but robust incentivization framework that encourages consistent and informed participation from a diverse range of stakeholders with different levels of governance responsibilities, commitments and impact. However, achieving this objective faces several technical obstacles and game theoretic challenges, including designing fair reward mechanisms, ensuring the sustainability of incentives, and preventing the misuse of incentivization structures. Addressing these challenges is crucial to fostering a more balanced and representative governance model for the Cardano community.\n\n## Problem\nThe Cardano governance framework relies on Delegated Representatives (DReps), Constitutional Committee (CC), Stake Pool Operators (SPOs), and ADA holders to make informed decisions, exercise veto power, and select both SPOs and DReps that reflect the broader community's interests. However, the current system lacks a structured mechanism to incentivize DReps, CC members, and ADA holders delegating to DReps effectively. Without adequate rewards, DReps and CC members are primarily driven by altruism or self-interest, which is neither sustainable nor scalable in the long term. ADA holders also lack any reason to deeply connect with DReps. This reliance on voluntary participation risks a significant imbalance in governance, where only a small, motivated subset of the community holds disproportionate influence.\n\nThe absence of an incentivization framework discourages widespread participation and may lead to voter apathy, reducing the overall quality and representativeness of decisions. This problem is further exacerbated by the potential for centralization, as a few highly active stakeholders can dominate governance processes, marginalizing the voices of the broader community.\n\nThe writing of this CPS document is motivated by the urgent need to address these issues and create a comprehensive incentivization system. Such a system aims to ensure that DReps, CC members, and ADA holders are fairly compensated for their efforts, thereby promoting active, informed participation and maintaining a decentralized governance structure that truly reflects the diverse interests of the Cardano community.\n\nAny incentives program for the above mentioned stakeholders should take into account the current SPO rewards. Rewards and incentives have to be considered along the yearly inflows of ada to the treasury. All governance stakeholders must be considered as part of a whole which is the Cardano governance model. \n\n\n\n## Use Cases\n### **1. Dedicated DReps Struggle to Stay Engaged**\nBob is a long-time Cardano supporter who wants to actively participate in governance. He has been following governance actions and has taken the time to research and write about important proposals. His insights gain traction, and several small ADA holders delegate their stake to him, recognizing his contributions.\n\nHowever, despite his dedication, Bob finds it increasingly difficult to justify the time required to analyze governance actions, engage with the community, and vote responsibly. He works a full-time job and has personal responsibilities, leaving him with little bandwidth to commit to governance. While some Stake Pool Operators (SPOs) and project owners have been able to transition into full-time roles within the ecosystem, Bob has no way of sustaining himself as a DRep. Over time, he is forced to step back and delegate his voting power to another DRep, reducing the diversity of governance representation.\n\nA well-designed incentivization framework would allow individuals like Bob to remain engaged by compensating them for their time and effort. This would lead to a more representative governance model and prevent valuable contributors from exiting the system due to financial constraints.\n\n![DRep registrations and deregistrations over time from epoch 510](https://github.com/Ryun1/metadata/blob/main/drep-reg-and-drep-over-time.png?raw=true)\n\n### **2. Constitutional Committee members (CC members)**\nThe CC is the body with the smallest pool of participants and we expect this to remain the case even after it opens up to more members. As such, CC members will have a bigger workload per individual when compared to other governance bodies. \n\nCC members run the risk of being overwhelmed by the quantity of proposals they’ll need to consider. Compensation for CC members allows them to dedicate more time to the process and also consider it as part of their professional activities. Members of the CC should be incentivesed by their on-chain votes on all governance actions where their role plays a part. This on-chain information can be the basis to check on their activity and performace. \n\n### **3. Ada Holders are incentivized but not for governance involvement**\nAda holders play a crucial role in the Cardano ecosystem. While they are incentivized to stake to a DRep, there is no clear motivation for them to stay actively engaged in their DRep’s voting behavior or governance participation. This creates a disconnect between delegation and governance outcomes, weakening the representativeness of governance decisions.\n\nMany Ada holders delegate their stake precisely because they lack the time or expertise to follow governance actions closely. However, the system still requires their periodic engagement, to assess whether their chosen DRep continues to align with their values. Without an incentive to review or reconsider their delegation, Ada holders risk passively contributing to governance stagnation, where ineffective or misaligned DReps retain power simply due to voter inertia.\n\nFor governance to be truly decentralized and representative, Ada holders must have a reason to stay informed—even at a minimal level—to ensure their delegation remains an active choice rather than a passive default.\n\n\n### **4. Stakepool Operators are already incentivized**\nWhile Stake Pool Operators play a dual role in the Cardano ecosystem now, their governance participation is not directly rewarded. \n\nSPOs who are also DReps face overlapping responsibilities, meaning they have the opportunity to do almost the same amount of work for double the impact in some cases. \n\nSince there is little additional incentive for them, to engage deeply in governance beyond their required votes this could lead to a passive voting behaviour, where SPOs vote without fully engaging in the governance discourse. Another concern is the Concentration of governance power, if large SPOs who act as DReps accumulate excessive influence over governance decisions as some already have.\n\n### **5. Centralization of Governance Due to a Lack of Incentives and Guardrails**\nIn the absence of financial incentives, only a small group of highly motivated individuals participate in governance. Over time, governance power becomes concentrated among a few active representatives who have the time and resources to engage, while many potential DReps remain on the sidelines.\n\nThis concentration of power increases the risk of governance capture, where a small number of stakeholders control the outcome of key decisions and their only financial incentive is voting to serve their own interests. Additionally, inactive DReps or SPOs who continue to hold delegation without participating, or voters who lost their keys but still stake to DReps, contribute to governance stagnation, reducing the legitimacy of voting outcomes.\n\nA structured incentive system would mitigate these risks by encouraging broader participation and preventing governance power from consolidating among a select few. Implementing periodic delegation resets for inactive DReps would further ensure that voting power remains in the hands of engaged representatives.\n\n### **6. Uninformed Voting Reduces Governance Effectiveness**\nDReps & SPOs are expected to vote in the best interest of the Cardano community, but without the right incentives, there is little motivation to conduct thorough research on governance actions. Some DReps/SPOs may vote based on limited information, personal biases, the current SPO incentives or simply follow the decisions of other prominent representatives without critical evaluation.\n\nThis lack of diligence increases the likelihood of errors in leadership and policy, including the approval of poorly structured proposals or the rejection of initiatives that would benefit the ecosystem. Without a mechanism to reward informed voting, governance risks becoming a process of rubber-stamping rather than a meaningful evaluation of proposals.\n\nBy introducing performance-based rewards that factor in voting participation, rationalization, and retrospective scoring of governance actions, the system can encourage DReps to engage more thoughtfully in decision-making. This would improve the overall quality of governance and ensure that voting outcomes align with the long-term interests of the Cardano ecosystem.\n\n### 7. Disincentives \nThe prior use cases have focused thus far on frameworks that use positive incentives to increase participation, support, and broaden the pool of stakeholders. There is a case to be made to also introduce disincentives to the governance process where mechanisms punish and discourage bad actors. For this to have an effect, the positive behavior of each stakeholder needs to be identified and made clear for all participants. Any punitive actions at the level of the protocol have to be designed with a clear set of positive ones. These must be identified via a community-led effort that ensures all participants can have input in the process. \n\nAny introduction of protocol-level disincentives has to be taken with proper data and community consensus. If these mechanisms are not adequately discussed and tested, the network can introduce punitive actions for behaviours that may be within the democratic model of Cardano. For this reason, this document cannot recommend any such mechanism; the aim is only to leave the possibility open for those in the community who want to research this area of governance.  \n\n## Goals\n### **Primary Objective**\nEstablish a structured and sustainable incentivization framework that motivates and rewards governance stakeholders to participate actively and make well-informed governance decisions, therefore upholding democratic, sustainable, ethical as well as decentralized principles of the Cardano ecosystem.\n\n### **Key Goals**\n#### Compensate stakeholders for their meaningful work\nGovernance stakeholders invest significant time and effort into understanding, evaluating, and voting on governance actions. Without financial incentives, this responsibility falls predominantly on individuals who either have the financial freedom to participate voluntarily, are driven purely by altruism, or have self-serving motives. A fair and transparent reward mechanism will enable DReps to commit to governance activities without financial strain, ensuring the role remains accessible to all willing participants and serves the greater ecosystem.\n\n#### Increase stakeholder participation\nThe current system lacks sufficient incentives, leading to a low engagement rate among potential governance participants. This results in a concentration of power among a small number of highly active participants, which increases the risk of centralization and reduces diversity in governance decision-making. By implementing a rewards system, more individuals will be encouraged to participate, leading to a more decentralized and representative governance model. Inclusivity should be considered as a democratic core value to increase stakeholder buy-in and participation.\n\n#### Improve the quality of stakeholder actions\nThe effectiveness of governance decisions depends on the depth of understanding and thoroughness of analysis conducted by governance stakeholders. A well-designed incentivization mechanism will encourage stakeholders to dedicate time to research governance proposals, critically evaluate their impact, and act in a manner that aligns with the broader interests of the Cardano community. Furthermore, implementing performance-based rewards, such as factoring in participation rates and the quality of voting rationales as well as scoring of governance actions in retrospect will discourage uninformed voting and promote responsible decision-making.\n\n#### Ensure fair and transparent reward distribution\nThe incentivization model must be structured to fairly distribute rewards based on clear and measurable parameters. Rewards should not be arbitrary or biased toward wealthier or more influential participants but should instead reflect the quality and impact of a DRep’s contributions. The framework must be transparent, allowing the Cardano Community to understand how rewards are calculated and distributed.\n\n#### Encourage long-term engagement and stability\nGovernance in Cardano is an evolving process that requires consistency and long-term commitment. An effective incentivization structure should not only attract new participants but also encourage existing DReps to remain engaged over extended periods. This will ensure continuity in governance practices, minimize abrupt power shifts, and provide a stable decision-making environment for the ecosystem.\n\n#### Prevent gaming and misuse of incentives\nAny reward system carries the risk of exploitation, where participants attempt to maximize rewards through minimal effort, collusion, or other manipulative tactics. The incentive framework must be robust and include safeguards against such behaviors, such as requiring active participation, considering qualitative assessments of governance contributions, and periodically reviewing and adjusting parameters to close potential loopholes.\n\n#### Promote global and cultural diversification\nCardano is a global ecosystem, and its governance should reflect the diverse perspectives and experiences of its community members. A key goal is to encourage participation from a wide range of geographic regions, cultural backgrounds, and socioeconomic contexts. Achieving this will help governance decisions better align with the needs and values of the global Cardano community, rather than being dominated by any single region or demographic.\n\n#### Maximize governance effectiveness\nTraditional governance mechanisms often suffer from inefficiencies, slow decision-making, and resource-heavy processes that do not scale well. The incentivization framework for DReps must be designed to optimize governance effectiveness while minimizing unnecessary complexity and resource consumption.\n\n\n## Open Questions\n- Is change needed at the Ledger/protocol level or tooling/wallet level?\n- What are the current incentives for stakeholders?\n- Is the current architecture avoiding or aiding centralization?\n- What’s the proper reward amount?\n- How much should the rewards be based on ADA delegation, the DRep’s participation or other factors?\n- What’s the impact of stakeholder rewards on Cardano’s treasury?\n\n## References\n- [Reward Schemes and Committee Sizes in Proof of Stake Governance](https://arxiv.org/abs/2406.10525)\n- [Should DReps receive compensation? Poll]()\n## Copyright\nThis CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "CPS-0021/CPD/README.md",
    "content": "## Ouroboros Randomness Generation Sub-Protocol - The coin-flipping Problem\n\n### Cardano Problem Definition (CPD) \n\nThis document is a **Cardano Problem Definition (CPD)**, from which the [**Cardano Problem Statement (CPS): Ouroboros Randomness Manipulation**](../README.md) is derived.  \n\nWhile the **CPS** is being structured for formal submission with a focus on accessibility, and alignment with the **CIP process**, this **CPD** retains the full depth of technical material that shaped the problem understanding. It preserves detailed modeling, cost definitions, and adversarial analysis that could not be fully included in the **CPS** due to scope and formatting constraints. \n\nThe **CPD** thus complements the **CPS** by serving as its technical foundation and extended reference, providing the complete analytical context behind the identified problem.\n\n### Abstract\n\nA well-designed consensus protocol is inherently **modular**, comprising multiple sub-protocols that collectively ensure **security**, **efficiency**, and **decentralization**. Among these, the **Randomness Generation Sub-Protocol** is pivotal in tackling the *Coin-Flipping Problem*—the challenge of generating **fair**, **unbiased**, and **unpredictable** randomness in a distributed environment.\n\nThis issue is especially critical in **Ouroboros**, where randomness underpins essential sub-protocols like **leader election**. A **robust** and **tamper-resistant** randomness mechanism is vital to maintaining the protocol’s **security**, **fairness**, and **integrity**.\n\nThis **CPD** delineates this challenge within the context of *Ouroboros Praos*, analyzing its approach and its vulnerability to *grinding attacks*, where adversaries attempt to manipulate leader election outcomes. The document offers:\n\n- An **analysis** of attack vectors, their **economic** and **computational** prerequisites, and Cardano’s current **resilience**.\n- A **quantification** of attack feasibility, highlighting escalation beyond a **20% stake threshold**.\n- **Pivotal questions**: *Is manipulation occurring? What is Cardano’s vulnerability? How might threats be mitigated?*\n\nRather than prescribing specific solutions, this CPD urges the **Cardano community** to take **responsibility** for addressing these risks, potentially through advancements in *detection*, *stake distribution*, or *protocol design*. It establishes a **rigorous foundation** for understanding these issues and solicits **collaborative efforts** to bolster *Ouroboros’ resilience* against evolving adversarial strategies.\n\n\n### Summary of Findings\n\nThis **CPD** undertakes a thorough examination of the *Randomness Generation Sub-Protocol* within the *Ouroboros Praos*, focusing on the *Coin-Flipping Problem* and its implications for the **security** of the *Cardano blockchain*. The principal findings are as follows:\n\n- **Randomness Mechanism**: *Ouroboros Praos* utilizes **VRFs** for efficient randomness generation, yet this design exposes vulnerabilities to *grinding attacks*, wherein adversaries manipulate *nonce values* to influence **leader election** processes.\n- **Attack Feasibility**: The likelihood and impact of successful attacks rise significantly when an adversary controls **>20% of total stake** (~**4.36 billion ADA**, March 2025), while lesser stakes render such efforts statistically improbable over extended periods.\n- **Economic Considerations**: Acquiring substantial stake entails a **significant financial commitment**—on the order of **billions of USD** for a 20% share—further complicated by potential **asset devaluation** if an attack undermines network integrity.\n- **Computational Requirements**: Scenario analysis across varying grinding depths ($\\rho$) reveals a spectrum of feasibility:\n  - Minor attacks (e.g. manipulating **$\\rho=20$** blocks costs ~**$56**) are readily achievable.\n  - Significant manipulations (e.g. **$\\rho=50$** costs ~**$3.1 billion**) demand resources ranging from *feasible* to *borderline infeasible*, contingent upon adversary capabilities.\n  - The cost disparity between the most resource-intensive scenario (*Owl Survey*) and the least (*Ant Glance*) is substantial, with a consistent ratio of **$\\Delta \\log_{10}(\\text{Cost (USD)}) \\sim 6.3$**, indicating that the strongest attack here considered, the *Owl Survey* scenario, costs approximately **$10^{6.3}$ times more** than the base and weakest attack, *Ant Glance*, driven by the significant influence of the adversary's strategy evaluation, **$T_{\\text{eval}}$** (simpled called the evaluation complexity), and their target window scope **$w_T$**.\n\n<div align=\"center\">\n<img src=\"./image/grinding_depth_scenarios_cost_with_feasibility_layers_gradient.png\" alt=\"Grinding Depth Scenarios with Feasibility Thresholds\"/>\n</div>\n\n\nThe table below delineates the **$\\rho$ values** at which each scenario transitions across feasibility categories, illustrating the computational and economic thresholds:\n\n| **Feasibility Category**                  | **🔵 Ant Glance**   | **🟠 Ant Patrol**   | **🟢 Owl Stare**   | **🔴 Owl Survey**   |\n|--------------------------------------------|---------------------|---------------------|--------------------|--------------------|\n| **🟢 🌱 Trivial for Any Adversary**        | $0 \\to 53.6$        | $0 \\to 32.9$        | $0 \\to 31.6$       | $0 \\to 31.1$       |\n| **🟡 💰 Feasible with Standard Resources** | $53.6 \\to 60$     | $32.9 \\to 39.5$     | $31.6 \\to 38.3$    | $31.1 \\to 37.8$    |\n| **🟠 🏭 Large-Scale Infrastructure Required** | $60 \\to 69.7$  | $39.5 \\to 49.5$     | $38.2 \\to 48.2$    | $37.8 \\to 47.7$    |\n| **🔴 🚫 Borderline Infeasible**            | $69.7 \\to 79.4$     | $49.5 \\to 59.5$     | $48.2 \\to 58.2$    | $47.7 \\to 57.7$    |\n| **🔴 🚫 Infeasible**                      | $79.4 \\to 256$      | $59.5 \\to 256$      | $58.2 \\to 256$     | $57.7 \\to 256$     |\n\n\n✏️ **Note**: For a detailed explanation of these scenarios and their feasibility thresholds, refer to **[Section 3.5 - Scenarios](https://github.com/cardano-foundation/CIPs/pull/1009#35-scenarios)** within this CPD.\n\nThis document deliberately avoids advocating specific countermeasures, instead presenting these findings to highlight **extant vulnerabilities** and their **associated costs**. It is incumbent upon the **Cardano community** to assess and address these challenges, potentially through:\n- Development of **enhanced detection mechanisms**,\n- Improvement of **stake pool diversity**, or\n- Introduction of **protocol-level innovations**.\n\n**Stakeholders** are invited to engage with this CPD in its entirety to **validate the analysis**, **deepen their comprehension**, and **assume ownership** of subsequent solutions. Contributions are welcomed via the ongoing discourse at [**https://github.com/cardano-foundation/CIPs/pull/1009**](https://github.com/cardano-foundation/CIPs/pull/1009), aimed at collectively **fortifying the Ouroboros protocol**.\n\n\n## Table of Contents\n\n- [**1. Preliminaries**](#1-preliminaries)\n  - [1.1 Fundamental Properties](#11-fundamental-properties)\n    + [1.1.1 Transaction Ledger Properties](#111-transaction-ledger-properties)\n      * [1.1.1.1 Persistence with the security parameter k](#1111-persistence-with-the-security-parameter--textk-in-mathbbn-)\n      * [1.1.1.2 Liveness with the transaction confirmation time parameter u](#1112-liveness-with-the-transaction-confirmation-time-parameter--textu-in-mathbbn-)\n    + [1.1.2 Chain Properties](#112-chain-properties)\n      * [1.1.2.1 Common Prefix (CP)](#1121-common-prefix-cp)\n      * [1.1.2.2 Existential Chain Quality (∃CQ)](#1122-existential-chain-quality-cq)\n      * [1.1.2.3 Chain Growth (CG)](#1123-chain-growth-cg)\n  - [1.2 The Coin-Flipping Problem](#12-the-coin-flipping-problem)\n    + [1.2.1 Defining the Problem](#121-defining-the-problem)\n    + [1.2.2 Strategies for Randomness Generation](#122-strategies-for-randomness-generation)\n    + [1.2.3 The Historical Evolution of Ouroboros Randomness Generation](#123-the-historical-evolution-of-ouroboros-randomness-generation)\n    + [1.2.4 Comparing Ouroboros Randomness Generation with Ethereum](#124-comparing-ouroboros-randomness-generation-with-ethereum)\n    + [1.2.5 Conclusion: The reasons behind Ouroboros Praos](#125-conclusion-the-reasons-behind-ouroboros-praos)\n  - [1.3 Leader Election in Praos](#13-leader-election-in-praos)\n    + [1.3.1 Oblivious Leader Selection](#131-oblivious-leader-selection)\n    + [1.3.2 Application of Verifiable Random Function (VRF)](#132-application-of-verifiable-random-function-vrf)\n    + [1.3.3 Epoch Structure](#133-epoch-structure)\n    + [1.3.4 Epoch & Phases Length](#134-epoch--phases-length)\n    + [1.3.5 The Randomness Generation Sub-Protocol](#135-the-randomness-generation-sub-protocol)\n  - [1.4 Forks, Rollbacks, Finality and Settlement Times](#14-forks-rollbacks-finality-and-settlement-times)\n- [**2. The Grinding Attack Algorithm**](#2-the-grinding-attack-algorithm)\n  - [2.1 Randomness Manipulation Objectives](#21-randomness-manipulation-objectives)\n    + [2.1.1 Exposure](#211-exposure)\n    + [2.1.2 Slot Leader Distribution Selection](#212-slot-leader-distribution-selection)\n    + [2.1.3 Potential Outcomes of Grinding Attacks](#213-potential-outcomes-of-grinding-attacks)\n  - [2.2 Non-Exhaustive Manipulation Strategy List](#22-non-exhaustive-manipulation-strategy-list)\n    + [2.2.1 System Model](#221-system-model)\n    + [2.2.2 Self Mixing Strategy](#222-self-mixing-strategy)\n    + [2.2.3 Forking Strategies](#223-forking-strategies)\n- [**3. The Cost of Grinding: Adversarial Effort and Feasibility**](#3-the-cost-of-grinding-adversarial-effort-and-feasibility)\n  - [3.1 Definitions](#31-definitions)\n    + [3.1.1 α-heavy and Heaviness](#311-α-heavy-and-heaviness)\n    + [3.1.2 Grinding Power g](#312-grinding-power-g)\n    + [3.1.3 Grinding Windows](#314-grinding-windows)\n      * [3.1.3.1 Opportunity Windows](#3141-opportunity-windows-wo)\n      * [3.1.3.2 Target Window](#3142-target-window-wt)\n  - [3.2 Entry Ticket: Acquiring Stake to Play the Lottery](#32-entry-ticket-acquiring-stake-to-play-the-lottery)\n  - [3.3 Cost of a Grinding Attempt](#33-cost-of-a-grinding-attempt)\n    + [3.3.1 Nonce Generation](#331-nonce-generation)\n    + [3.3.2 Slot Leader Distribution Evaluation](#332-slot-leader-distribution-evaluation)\n    + [3.3.3 Strategic Benefit Evaluation](#333-strategic-benefit-evaluation)\n    + [3.3.4 Total Estimated Time per Grinding Attempt](#334-total-estimated-time-per-grinding-attempt)\n  - [3.4 Cost of a Grinding Attack](#34-cost-of-a-grinding-attack)\n    + [3.4.1 Formula](#341-formula)\n    + [3.4.2 Estimated Formula Using Mainnet Cardano Parameters](#342-estimated-formula-using-mainnet-cardano-parameters)\n  - [3.5 Scenarios](#35-scenarios)\n  - [3.6 Grinding Power Computational Feasibility](#36-grinding-power-computational-feasibility)\n\n- [**4. References**](#4-references)  \n- [**5. Copyright**](#5-copyright)  \n\n## 1. Preliminaries\n\nThis section introduces the pertinent parts of the Cardano proof-of-stake consensus protocol. We focus on the randomness generation and leader selection processes and omit irrelevant protocol details.\n\n## 1.1 Fundamental Properties\n\nA consensus protocol implements a robust transaction ledger if it maintains the ledger as a sequence of blocks, where each block is associated with a specific slot. Each slot can contain at most one ledger block, and this strict association ensures a well-defined and immutable ordering of transactions within the ledger. \n\nThe protocol must satisfy the two critical properties of _**Persistence**_ and _**Liveness**_, which ensure that blocks and transactions are securely committed and cannot be easily manipulated by adversaries. These can be derived from fundamental **chain properties** which are *used to explain how and why the leader election mechanism has been designed in this manner*. \n\n| **Chain Property**                      | **Description**                                                                                                                    |\n|-----------------------------------------|------------------------------------------------------------------------------------------------------------------------------|\n| **Common Prefix (CP)**                  | Ensures consistency across honest parties by requiring that chains adopted by different honest nodes share a common prefix.   |\n| **Existential Chain Quality (∃CQ)**     | Guarantees that at least one honestly-generated block appears in a portion of a sufficient length of the chain, ensuring honest contributions. |\n| **Chain Growth (CG)**                   | Ensures that the blockchain extends at a minimum rate over time, preventing indefinite stalling by adversaries while maintaining progress based on the fraction of honest stakeholders producing blocks. |\n\n### 1.1.1 Transaction Ledger Properties \n#### 1.1.1.1 Persistence with the **security parameter $` \\text{k} \\in \\mathbb{N} `$**\n \nOnce a node of the system proclaims a certain transaction *tx* in the stable part of its ledger, all nodes, if queried, will either report *tx* in the same position of that ledger or report a stable ledger which is a prefix of that ledger. Here the notion of stability is a predicate that is parameterized by a **security parameter $` \\text{k} `$**. Specifically, a transaction is declared **stable** if and only if it is in a block that is more than $` \\text{k} `$ blocks deep in the ledger.\n\n#### 1.1.1.2 Liveness with the **transaction confirmation time parameter $` u \\in \\mathbb{N} `$** \n\nIf all honest nodes in the system attempt to include a certain transaction then, after the passing of time corresponding to $`\\text{u}`$ slots (called the **transaction confirmation time**), all nodes, if queried and responding honestly, will report the transaction as stable.\n\n### 1.1.2 Chain properties \n\n**Persistence** and **liveness** can be derived from basic **chain properties**, provided that the protocol structures the ledger as a **blockchain**—a sequential data structure. The following key chain properties ensure that the blockchain behaves securely and efficiently:\n\n#### 1.1.2.1 **Common Prefix (CP)**: With the **security parameter $`k \\in \\mathbb{N}`$**. \n\nConsider 2 chains $C_1$ and $C_2$ adopted by 2 honest parties at the onset of slots $sl_1$ and $sl_2$, respectively, where $sl_1 \\leq sl_2$. The chains must satisfy the condition:\n\n  ```math\n  C_1^{\\lceil k \\rceil} \\preceq C_2\n  ```\n  Where:\n  - $C_1^{\\lceil k \\rceil}$ represents the chain obtained by removing the last $k$ blocks from $C_1$.\n  - $\\preceq$ denotes the **prefix relation**.\n\n  This ensures that the shorter chain is a prefix of the longer one, ensuring consistency across honest parties.\n\n#### 1.1.2.2 **Existential Chain Quality (∃CQ)**: With parameter $s \\in \\mathbb{N}$ (Minimum Honest Block Inclusion Interval). \n\nConsider a chain $C$ adopted by an honest party at the onset of a slot. For any portion of $C$ spanning $s$ prior slots, there must be at least one honestly-generated block within this portion. This ensures that the chain includes contributions from honest participants. In practical terms, $s$ defines the length of a \"safety window\" where honest contributions are guaranteed.\n\n#### 1.1.2.3 **Chain Growth (CG)**: With parameters $\\tau \\in (0, 1]$ (speed coefficient) and $s \\in \\mathbb{N}$ (Minimum Honest Block Inclusion Interval).\n\nThe Chain Growth (CG) property is a more general concept that combines both the **speed of block production** and the **frequency of honest contributions**. It uses two parameters: $\\tau$, the **speed coefficient**, which governs how fast the chain grows, and $s$, the **Minimum Honest Block Inclusion Interval**, which ensures that honest blocks are consistently produced within a given interval of slots.\n\nConsider a chain $C$ held by an honest party at the onset of a slot. For any portion of $C$ spanning $s$ contiguous prior slots . The number of blocks in this portion must be at least $\\tau s$. \nThe parameter $\\tau$ determines the fraction of slots in which blocks are produced. For example, if $\\tau = 0.5$ and $s = 10$, there should be at least 5 blocks produced within that span.\n\n  \nFor example, if $\\tau = 0.5$ and $s = 10$, then at least $\\tau s = 0.5 \\cdot 10 = 5$ honest blocks must be produced over the span of those 10 slots. \n\n## 1.2 The Coin-Flipping Problem  \n\nThe **Coin-Flipping Problem** is a fundamental challenge in distributed systems that require a **fair, unbiased, and unpredictable** source of randomness—without allowing any single participant to manipulate the outcome.  \n\n### **1.2.1 Defining the Problem**  \nConsider a scenario where multiple untrusted parties must **flip a coin** and use the outcome, the concatenation of heads or tails, to reach a decision. The challenge is ensuring that:  \n\n1. 🎲 The outcome remains **random and unpredictable**.  \n2. 🔒 No participant can **bias or influence** the result in their favor.  \n3. ⚖️ The process is **fair and secure**, even in the presence of dishonest or colluding actors.  \n\nIn **blockchain consensus protocols**, randomness is crucial for **leader election, committee selection, and cryptographic lotteries**. If an adversary can bias the randomness, they can **increase their influence over block production**, **delay settlements**, or **disrupt network security**.  \n\n### **1.2.2 Strategies for Randomness Generation**  \nVarious cryptographic techniques exist to address the **coin-flipping problem** in decentralized settings. These methods differ in **security, efficiency, and resistance to adversarial manipulation**.  \n\n| **Approach**              | **Pros** | **Cons** |\n|---------------------------|---------|---------|\n| **PVSS-Based Beacons** <br> _(Ouroboros Classic, RandHound, Scrape, HydRand)_ | ✔ Strong randomness guarantees — output is indistinguishable from uniform.<br> ✔ Resistant to last-mover bias — commitments prevent selective reveals. | ❌ High communication complexity — requires O(n²) messages.<br> ❌ Vulnerable to adaptive adversaries — who may corrupt committee members. |\n| **Threshold Signature-Based Beacons** <br> _(DFINITY)_ | ✔ Fast and non-interactive — requires only one round of communication.<br> ✔ Resistant to last-mover bias — output is deterministic. | ❌ Group setup complexity — requires distributed key generation (DKG).<br> ❌ No random number output in case of threshold signature generation failure. |\n| **Byzantine Agreement-Based Beacons** <br> _(Algorand)_ | ✔ Finality guarantees — randomness is confirmed before the next epoch.<br> ✔ Less entropy loss than Praos. | ❌ Requires multi-round communication — higher latency.<br> ❌ Not designed for eventual consensus — better suited for BA-based protocols. |\n| **\"VRF\"-Based Beacons** <br> _(Ethereum’s RANDAO Post-Merge, Ouroboros Praos, Genesis, Snow White)_ | ✔ Simple and efficient — low computational overhead.<br> ✔ Fully decentralized — any participant can contribute randomness. | ❌ Vulnerable to last-revealer bias — the last participant can manipulate the final output. |\n\n### **1.2.3 The Historical Evolution of Ouroboros Randomness Generation**\n\nThe **Ouroboros family of protocols** has evolved over time to optimize **randomness generation** while balancing **security, efficiency, and decentralization**. Initially, **Ouroboros Classic** used a **secure multi-party computation (MPC) protocol** with **Publicly Verifiable Secret Sharing (PVSS)** to ensure **unbiased randomness**. While providing **strong security guarantees**, PVSS required **quadratic message exchanges** between committee members, introducing **significant communication overhead**. This **scalability bottleneck** limited participation and hindered the decentralization of Cardano's consensus process.\n\nRecognizing these limitations, **Ouroboros Praos** moved to a **VRF-based randomness generation** mechanism where each individual randomness contribution is generated with Verifiable Random Functions (VRFs). Here, each block includes a **VRF value**, that is a veriable random value that gas been _deterministically_ computed from a fixed message. The random nonce for an epoch is then derived from the **concatenation and hashing** of all these values from a **specific section of the previous epoch’s chain**. This significantly **reduces the communication complexity**, which now becomes **linear in the number of block producers**, making randomness generation **scalable and practical** while maintaining **adequate security properties**.\n\nHowever, this efficiency gain comes at a cost: the random nonce is now _biasable_ as this protocol change introduces a **limited avenue for randomness manipulation**. Adversaries can attempt **grinding attacks**, evaluating multiple **potential nonces** and selectively influencing randomness outcomes. While constrained, this trade-off necessitates further countermeasures to **limit adversarial influence** while maintaining protocol scalability.\n\n\n<details>\n<summary>📌📌 <i> More Details on VRFs </i> – <b>  Expand to view the content.</b></summary>\n<br>\n\n**Verifiable Random Functions (VRFs)**  are cryptographic primitives that produce a pseudorandom output along with a proof that the output was correctly generated from a given input and secret key.\n\n**BLS Signatures** (Boneh–Lynn–Shacham) can be used as Verifiable Random Functions (VRFs) because they satisfy the core properties — Determinism, Pseudorandom and efficiently Verifiable - required of a VRF. \n\nA BLS signature is indistinguishable from random without knowledge of the secret key, their signature is efficient and the signature generation is determistic and secure under standard cryptographic assumptions.\n\n</details>\n\n### **1.2.4 Comparing Ouroboros Randomness Generation with Ethereum**  \n\nEthereum RANDAO protocol was first based on a **commit and reveal** approach where each block producer would commit to random values in a first period, i.e. publish the hash of a locally generated random value during block proposal, before revealing them afterwards. As the latter period finished, all revealed values were combined, more specifically XORed, together to finally get the random nonce.\n\nEthereum's **Post-Merge RANDAO** protocol remains mostly the same, but instead of using a **commit-reveal** approach, each contributor generate randomness deterministically by using VRFs, making these values verifiable. These values are finally, as before, sequentially aggregated using **XOR**, forming the final **randomness output** used in **validator shuffling** and **protocol randomness**.\nThis version of the protocol is very similar to Ouroboros Praos' where hashing is used instead of XOR to combine contributors' randomness together, and does not rely on commitees.\n\nWhile **decentralized** and **computationally lightweight**, RANDAO still suffers from **last-revealer bias**, where the **final proposers** in an epoch can **withhold their reveals** to manipulate randomness. As such, Ethereum has spent some time studying Verifiable Delayed Functions (VDFs) to prevent the last revealer attack by relying on its sequentiality property. Subsequently, Ethereum decided **against integrating Verifiable Delay Functions**  due to feasibility concerns, including the difficulty of practical deployment and the risk of centralization stemming from specialized hardware dependencies. They instead opted for a **frequent reseeding mechanism** to strengthen the commitee selection in order to mitigate biases which, unfortunately does not fully eliminate last-revealer manipulation concerns.\n\n<details>\n<summary>📌📌 <i> More Details on VDFs </i> – <b>  Expand to view the content.</b></summary>\n<br>\n\nVDFs are designed to provide **unpredictable, verifiable randomness** by requiring a **sequential computation delay** before revealing the output. \n\nThis makes them **resistant to grinding attacks** since adversaries cannot efficiently evaluate multiple outcomes. However, they introduce **significant computational costs**, require specialized **hardware for efficient verification**, and demand **additional synchronization mechanisms**.\n\n</details>\n\n### **1.2.5 Conclusion: The reasons behind Ouroboros Praos**\n\nDespite some **security trade-offs**, non-interactively combining **VRFs** was selected for Ouroboros Praos due to its **balance between efficiency, scalability, and security**. Unlike **PVSS**, we do not require a **multi-party commit-reveal process** or have **quadratic communication overhead**.\n\nHowever, ongoing research continues to explore potential enhancements to **mitigate grinding risks**, including **hybrid randomness beacons** that combine **VRFs with cryptographic delay mechanisms**.\n\n## 1.3 Leader Election in Praos\n\n### 1.3.1 Oblivious Leader Selection\n\nAs Explained into [DGKR18 -  Ouroboros Praos_ An adaptively-secure, semi-synchronous proof-of-stake blockchain](https://eprint.iacr.org/2017/573.pdf), Praos protocol presents the following basic characteristics : \n- **Slot Leader Privacy**: Only the selected leader knows they have been chosen as slot leader until they reveal themselves, often by publishing a proof. This minimizes the risk of targeted attacks against the leader since other network participants are unaware of the leader's identity during the selection process.\n\n- **Verifiable Randomness**: The selection process uses verifiable randomness functions (VRFs) to ensure that the leader is chosen fairly, unpredictably, and verifiably. The VRF output acts as a cryptographic proof that the selection was both random and valid, meaning others can verify it without needing to know the leader in advance.\n\n- **Low Communication Overhead**: Since the identity of the leader is hidden until the proof is revealed, Oblivious Leader Selection can reduce communication overhead and minimize the chance of network-level attacks, such as Distributed Denial of Service (DDoS) attacks, aimed at preventing the leader from performing their role.\n\nBased on their local view, a party is capable of deciding, in a publicly verifiable way, whether they are permitted to produce the next block, they are called a **slot leader**. Assuming the block is valid, other parties update their local views by adopting the block, and proceed in this way continuously. At any moment, the probability of being permitted to issue a block is proportional to the relative stake a player has in the system, as reported by the blockchain itself :\n1. potentially, multiple slot leaders may be elected for a particular slot (forming a slot leader set); \n2. frequently, slots will have no leaders assigned to them; This is defined by the **Active Slot Coefficient f**\n3. a priori, only a slot leader is aware that it is indeed a leader for a given slot; this assignment is unknown to all the other stakeholders—including other slot leaders of the same slot—until the other stakeholders receive a valid block from this slot leader.\n\n\n### 1.3.2 Application of Verifiable Random Function (VRF)\n\nThe VRF is used to generate randomness locally in the protocol, making the leader election process unpredictable. It ensures that:\n- A participant is privately and verifiably selected to create a block for a given slot.\n- The VRF output is both secret (only known to the selected leader) and verifiable (publicly checkable).\n\nTo determine whether a participant is the slot leader of $`\\text{slot}_t`$ in epoch $`\\text{epoch}_e`$, they first generate a VRF output and proof using their secret VRF key out of the slot number $`\\text{slot}_t`$ and current epoch random nonce $`\\eta_\\text{e}`$. They then compare this value with a threshold $`\\text{Threshold}^\\text{participant}_\\text{e}`$ that is computed from the participant's relative stake at the beginning of the epoch. If the VRF output is smaller than the threshold, they become the slot leader of $`\\text{slot}_t`$. In that case, when publishing a block for this slot, they include in the block header $` \\text{BlockHeader}_\\text{t} `$, the $` \\text{SlotLeaderProof}_\\text{t} `$ comprising the VRF proof.\n\n| **Features** | **Mathematical Formula** | **Description**  | \n|--------------|------------------|-----------------------|\n| **Slot Leader Proof** | $`\\mathsf{VRF}^\\text{Certification}_\\text{(participant,t)} \\equiv (\\mathsf{VRF}^\\text{Proof}_\\text{(participant,t)},\\mathsf{VRF}^\\text{Output}_\\text{(participant,t)}) \\leftarrow VRF_\\text{gen} \\left( Key\\mathsf{VRF}^\\text{participant}_\\text{private}, \\text{slot}_t \\, ⭒ \\, \\eta_\\text{e} \\right) `$ | This function computes the leader eligibility proof using the VRF, based on the slot number and randomness nonce.       | \n| **Slot Leader Threshold** | $` \\text{Threshold}^\\text{participant}_\\text{e} = (1 - ActiveSlotCoefficient )^\\frac{\\text{ActiveStake}^\\text{e}_\\text{participant}}{\\text{ActiveStake}^\\text{e}_\\text{total}}  `$ | This function calculates the threshold for a participant's eligibility to be selected as a slot leader during $` \\text{epoch}_e `$.   | \n| **Eligibility Check** | $` isEligible\\left (t,participant ,\\text{ActivesStake}^\\text{e},\\eta_\\text{e}\\right) = \\frac{ toBoundedNatural  \\circ  \\mathsf{VRF}^\\text{Output}_\\text{(participant,t)}}{\\text{MaxBoundedNatural}} < \\text{Threshold}^\\text{participant}_\\text{e} `$ |The leader proof is compared against a threshold to determine if the participant is eligible to create a block.         |\n| **Verification**       | $` VRF_\\text{verify} \\left(  Key\\mathsf{VRF}^\\text{participant}_\\text{public}, \\mathsf{VRF}^\\text{Certification}_\\text{(participant,t)}, \\text{slot}_t \\, ⭒ \\, \\eta_\\text{e} \\right) = 0 \\land 1  `$ | Other nodes verify the correctness of the leader proof by recomputing it using the public VRF key and slot-specific input.     | \n \n| Where | |\n|-----------------------------------|-----------------------------------------------------------------------------------------------------------------------------------|\n| $` \\text{slot}_t `$                   | The current slot number.                                                                                                          |\n| $` \\eta_\\text{e} `$                   | Eta, The randomness nonce used in $` \\text{epoch}_\\text{e} `$, computed within the previous $` \\text{epoch}_\\text{e-1} `$.            |\n| $` key_\\text{private} `$              | The node's secret (private) key.                                                                                                  |\n| $` key_\\text{public} `$               | The node's public key.                                                                                                            |\n| $` VRF_\\text{gen} \\left( key_\\text{private}, \\text{input} \\right) \\rightarrow (Proof,Output) `$ | Generate a Certification with input |\n| $` VRF_\\text{verify} \\left( key_\\text{private}, (Proof,Output), msg \\right) \\rightarrow \\{0,1\\}  `$ | Verify a Certification with input |\n| $` a ⭒ b `$    | The concatenation of $`a`$ and $`b`$ , followed by a BLAKE2b-256 hash computation.                                                |\n| $` \\text{ActiveStake}^\\text{e}_\\text{participant} `$ | The stake owned by the participant used in $` \\text{epoch}_\\text{e} `$, computed within the previous $` \\text{epoch}_\\text{e-1} `$                                                                                              |\n| $` \\text{ActiveStake}^\\text{e}_\\text{total} `$       | The total stake in the system used in $` \\text{epoch}_\\text{e} `$, computed within the previous $` \\text{epoch}_\\text{e-1} `$                                                                                                  |\n| $` ActiveSlotCoefficient`$                            | The active slot coefficient (referred as $`f`$), representing the fraction of slots that will have a leader and eventually a block produced.                                           |\n\n<details>\n  <summary> 📌📌 <i> Relevant Implementation Code Snippets for This Section </i> – <b>  Expand to view the content.</b>\n </summary>\n  \n```haskell\n-- | The body of the header is the part which gets hashed to form the hash\n-- chain.\ndata HeaderBody crypto = HeaderBody\n  { -- | block number\n    hbBlockNo  :: !BlockNo,\n    -- | block slot\n    hbSlotNo   :: !SlotNo,\n    -- | Hash of the previous block header\n    hbPrev     :: !(PrevHash crypto),\n    -- | verification key of block issuer\n    hbVk       :: !(VKey 'BlockIssuer crypto),\n    -- | VRF verification key for block issuer\n    hbVrfVk    :: !(VerKeyVRF crypto),\n    -- | Certified VRF value\n    hbVrfRes   :: !(CertifiedVRF crypto InputVRF),\n    -- | Size of the block body\n    hbBodySize :: !Word32,\n    -- | Hash of block body\n    hbBodyHash :: !(Hash crypto EraIndependentBlockBody),\n    -- | operational certificate\n    hbOCert    :: !(OCert crypto),\n    -- | protocol version\n    hbProtVer  :: !ProtVer\n  }\n  deriving (Generic)\n\n-- | Input to the verifiable random function. Consists of the hash of the slot\n-- and the epoch nonce.\nnewtype InputVRF = InputVRF {unInputVRF :: Hash Blake2b_256 InputVRF}\n  deriving (Eq, Ord, Show, Generic)\n  deriving newtype (NoThunks, ToCBOR)\n\n-- | Construct a unified VRF value\nmkInputVRF ::\n  SlotNo ->\n  -- | Epoch nonce\n  Nonce ->\n  InputVRF\nmkInputVRF (SlotNo slot) eNonce =\n  InputVRF\n    . Hash.castHash\n    . Hash.hashWith id\n    . runByteBuilder (8 + 32)\n    $ BS.word64BE slot\n      <> ( case eNonce of\n             NeutralNonce -> mempty\n             Nonce h      -> BS.byteStringCopy (Hash.hashToBytes h)\n         )\n\n-- | Assert that a natural is bounded by a certain value. Throws an error when\n-- this is not the case.\nassertBoundedNatural ::\n  -- | Maximum bound\n  Natural ->\n  -- | Value\n  Natural ->\n  BoundedNatural\nassertBoundedNatural maxVal val =\n  if val <= maxVal\n    then UnsafeBoundedNatural maxVal val\n    else error $ show val <> \" is greater than max value \" <> show maxVal\n\n-- | The output bytes of the VRF interpreted as a big endian natural number.\n--\n-- The range of this number is determined by the size of the VRF output bytes.\n-- It is thus in the range @0 ..  2 ^ (8 * sizeOutputVRF proxy) - 1@.\n--\ngetOutputVRFNatural :: OutputVRF v -> Natural\ngetOutputVRFNatural = bytesToNatural . getOutputVRFBytes\n\n-- This is fast enough to use in production.\nbytesToNatural :: ByteString -> Natural\nbytesToNatural = GHC.naturalFromInteger . bytesToInteger\n\nbytesToInteger :: ByteString -> Integer\nbytesToInteger (BS.PS fp (GHC.I# off#) (GHC.I# len#)) =\n  -- This should be safe since we're simply reading from ByteString (which is\n  -- immutable) and GMP allocates a new memory for the Integer, i.e., there is\n  -- no mutation involved.\n  unsafeDupablePerformIO $\n    withForeignPtr fp $ \\(GHC.Ptr addr#) ->\n      let addrOff# = addr# `GHC.plusAddr#` off#\n       in -- The last parmaeter (`1#`) tells the import function to use big\n          -- endian encoding.\n          importIntegerFromAddr addrOff# (GHC.int2Word# len#) 1#\n  where\n    importIntegerFromAddr :: Addr# -> Word# -> Int# -> IO Integer\n#if __GLASGOW_HASKELL__ >= 900\n-- Use the GHC version here because this is compiler dependent, and only indirectly lib dependent.\n    importIntegerFromAddr addr sz = integerFromAddr sz addr\n#else\n    importIntegerFromAddr = GMP.importIntegerFromAddr\n#endif\n\n\n-- | Check that the certified VRF output, when used as a natural, is valid for\n-- being slot leader.\ncheckLeaderValue ::\n  forall v.\n  VRF.VRFAlgorithm v =>\n  VRF.OutputVRF v ->\n  Rational ->\n  ActiveSlotCoeff ->\n  Bool\ncheckLeaderValue certVRF σ f =\n  checkLeaderNatValue (assertBoundedNatural certNatMax (VRF.getOutputVRFNatural certVRF)) σ f\n  where\n    certNatMax :: Natural\n    certNatMax = (2 :: Natural) ^ (8 * VRF.sizeOutputVRF certVRF)\n\n-- | Check that the certified input natural is valid for being slot leader. This\n-- means we check that\n--\n-- p < 1 - (1 - f)^σ\n--\n-- where p = certNat / certNatMax.\n--\n-- The calculation is done using the following optimization:\n--\n-- let q = 1 - p and c = ln(1 - f)\n--\n-- then           p < 1 - (1 - f)^σ\n-- <=>  1 / (1 - p) < exp(-σ * c)\n-- <=>  1 / q       < exp(-σ * c)\n--\n-- This can be efficiently be computed by `taylorExpCmp` which returns `ABOVE`\n-- in case the reference value `1 / (1 - p)` is above the exponential function\n-- at `-σ * c`, `BELOW` if it is below or `MaxReached` if it couldn't\n-- conclusively compute this within the given iteration bounds.\n--\n-- Note that  1       1               1                         certNatMax\n--           --- =  ----- = ---------------------------- = ----------------------\n--            q     1 - p    1 - (certNat / certNatMax)    (certNatMax - certNat)\ncheckLeaderNatValue ::\n  -- | Certified nat value\n  BoundedNatural ->\n  -- | Stake proportion\n  Rational ->\n  ActiveSlotCoeff ->\n  Bool\ncheckLeaderNatValue bn σ f =\n  if activeSlotVal f == maxBound\n    then -- If the active slot coefficient is equal to one,\n    -- then nearly every stake pool can produce a block every slot.\n    -- In this degenerate case, where ln (1-f) is not defined,\n    -- we let the VRF leader check always succeed.\n    -- This is a testing convenience, the active slot coefficient should not\n    -- bet set above one half otherwise.\n      True\n    else case taylorExpCmp 3 recip_q x of\n      ABOVE _ _ -> False\n      BELOW _ _ -> True\n      MaxReached _ -> False\n  where\n    c, recip_q, x :: FixedPoint\n    c = activeSlotLog f\n    recip_q = fromRational (toInteger certNatMax % toInteger (certNatMax - certNat))\n    x = -fromRational σ * c\n    certNatMax = bvMaxValue bn\n    certNat = bvValue bn\n\n  -- | Evolving nonce type.\ndata Nonce\n  = Nonce !(Hash Blake2b_256 Nonce)\n  | -- | Identity element\n    NeutralNonce\n  deriving (Eq, Generic, Ord, Show, NFData)\n\n-- | Evolve the nonce\n(⭒) :: Nonce -> Nonce -> Nonce\nNonce a ⭒ Nonce b =\n  Nonce . castHash $\n    hashWith id (hashToBytes a <> hashToBytes b)\nx ⭒ NeutralNonce = x\nNeutralNonce ⭒ x = x\n\n-- | Hash the given value, using a serialisation function to turn it into bytes.\n--\nhashWith :: forall h a. HashAlgorithm h => (a -> ByteString) -> a -> Hash h a\nhashWith serialise =\n    UnsafeHashRep\n  . packPinnedBytes\n  . digest (Proxy :: Proxy h)\n  . serialise\n\ninstance HashAlgorithm Blake2b_224 where\n  type SizeHash Blake2b_224 = 28\n  hashAlgorithmName _ = \"blake2b_224\"\n  digest _ = blake2b_libsodium 28\n\nblake2b_libsodium :: Int -> B.ByteString -> B.ByteString\nblake2b_libsodium size input =\n  BI.unsafeCreate size $ \\outptr ->\n    B.useAsCStringLen input $ \\(inptr, inputlen) -> do\n      res <- c_crypto_generichash_blake2b (castPtr outptr) (fromIntegral size) (castPtr inptr) (fromIntegral inputlen) nullPtr 0 -- we used unkeyed hash\n      unless (res == 0) $ do\n        errno <- getErrno\n        ioException $ errnoToIOError \"digest @Blake2b: crypto_generichash_blake2b\" errno Nothing Nothing\n\n\n  ```\n</details>\n\n### 1.3.3 Epoch Structure \n\nIn Praos and Genesis, an epoch consists of 3 logical phases to compute these 2 key variables—**active stake distribution** and **randomness beacon**—by going through the following phases:\n\n<div align=\"center\">\n<img src=\"./image/epoch-structure-praos.png\" alt=\"Epoch Structure\" />\n</div>\n\nThe sequential flow of these 3 phases is deliberately structured by designed : \n\n| Id | **Phase**                                                  | **Key Property**                 | **Description**| \n|----|-------------------------------|---------------------------|-------------------------------|\n| **1.**| $`\\text{ActiveStakeDistribution}_e`$ Stabilization | **Chain Growth (CG for CP)**  | This phase must be long enough to satisfy the **Chain Growth (CG)** property, ensuring that each honest party's chain grows by at least $k$ blocks. This guarantees that all honest parties agree on the stake distribution from the previous epoch. | \n| **2.**| Honest Randomness in $\\eta_\\text{e}$     | **Existential Chain Quality (∃CQ)** | After the Active Stake Distribution being stabilized to prevent adversaries from adjusting their stake in their favor, this phase must be sufficiently long to satisfy the Existential Chain Quality (∃CQ) property, which is parameterized by $s \\in \\mathbb{N}$, ensuring that at least one honestly-generated block is included within any span of $s$ slots. The presence of such a block guarantees that honest contributions to the randomness used in the leader election process are incorporated. This phase directly improves the quality of the randomness $\\eta_\\text{e}$ by ensuring that adversarial attempts to manipulate the randomness beacon are mitigated. The honest block serves as a critical input, strengthening the unpredictability and fairness of the leader election mechanism.   | \n| **3.**| $\\eta_\\text{e}$ Stabilization   | **Chain Growth (CG for CP)**          | This phase must again be long enough to satisfy the **Chain Growth (CG)** property, ensuring that each honest party's chain grows by at least $k$ blocks, allowing all honest parties to agree on the randomness contributions from the second phase. | \n\n### 1.3.4 Epoch & Phases Length \n\nWhile there is no theoretical upper bound on the epoch size—since it is defined by social and practical considerations (e.g., $10 \\, \\text{k}/f$ slots, 5 days)—the epoch does have a defined lower bound. Phases 1 and 3 have fixed sizes of $3 \\, \\text{k}/f$ and $4 \\, \\text{k}/f$, respectively. The size of Phase 2, \"Honest Randomness in $\\eta_\\text{e}$,\" is adjustable with a minimum size of $1 \\, \\text{k}/f$. \n\nThe structure of an epoch is often described by the ratio `3:3:4`:\n- **Phase 1** occupies **3** parts of the total epoch.\n- **Phase 2** also occupies **3** parts of the epoch (adjusted slightly to ensure the total reaches **10** parts in total.). \n- **Phase 3** takes up the remaining **4** parts of the epoch.\n\nNote that the third phase is only longer than the first one to complete the epoch duration. Consequently, we can assume that the CG property is already reached at the ninth part of an epoch. \n\n\n### 1.3.5 The Randomness Generation Sub-Protocol \n\nTo select the slots leaders, which stake pool is eligible to produce and propose a slot's block, we need to rely on random numbers. As economic reward and transaction inclusion depends on these numbers, the generation of these number is of critical importance to the protocol and its security. We show in this section how these random numbers, or _random nonces_ are defined.\n\n#### **The $\\eta^\\text{evolving}$ Stream Definition**  \n\nContrary to [Section 1.2.3](#123-the-historical-evolution-of-ouroboros-randomness-generation), where we first defined the random nonce as the hash of all VRF outputs, we adopt an iterative approach for the randomness generation in practice.\nMore particularly, the random nonces $\\eta$ are defined iteratively from a genesis value, as the hash of the previous epoch's nonce and the VRF outputs published between the Phase 2 of consecutive epochs. We thus talk about _evolving nonces_ $\\eta^\\text{evolving}$ as their value can be updated with the VRF output comprised in each block.\n\n```math\n   \\eta^{\\text{evolving}}_{t+1} =\n   \\begin{cases}\n   \\text{ProtocolParameter}_\\text{extraEntropy} & \\text{when } t = 0, \\\\\n   \\eta^{\\text{evolving}}_{t}\\ ⭒\\ \\ \\mathsf{VRF}^\\text{Output}_\\text{t+1} & \\text{when BlockProduced}(t) \\\\\n   \\end{cases}\n   \n```\n\n```math \n\\text{where } \\text{BlockProduced}(t) = \n\\begin{cases} \ntrue & \\text{if a block is produced at slot } t\\\\\nfalse & \\text{otherwise.}\n\\end{cases}\n```\n\n| **where** ||\n|---------------|-----------------|\n| $\\text{ProtocolParameter}_\\text{extraEntropy} $ | The evolving nonce is initialized using the extra Entropy field defined in the protocol parameters.|\n| $\\mathsf{VRF}^\\text{Output}_\\text{i}$ | The **VRF output** generated by the $\\text{slot}_\\text{i}$ Leader and included in the block header |\n| $a\\ ⭒\\ b$    | The concatenation of $a$ and $b$ , followed by a BLAKE2b-256 hash computation.\n\n#### **The $`\\eta^\\text{candidates}`$**  \n\n- As multiple competing forks can exist at any given time, we also encounter multiple **nonce candidates**, denoted as $`\\eta^\\text{candidates}`$. More precisely, the **nonce candidate** of a specific fork for epoch $`e`$ is derived from the **previous epoch’s nonce** $`\\eta_{e-1}`$, the **Verifiable Random Function (VRF) outputs** from the **candidate chain** starting from epoch $`e-2`$, and the **VRF outputs of the fork** itself up to the **end of Phase 2** of epoch $`e-1`$. \n\n- These components together form a **candidate nonce** for epoch $`e`$, corresponding to the **last derived evolving nonce** $`\\eta^{\\text{evolving}}_{\\text{t}}`$ at the **conclusion of Phase 2** of epoch $`e-1`$: \n\n   \n```math\n\\eta_\\text{e}^\\text{candidate} = \\eta^\\text{evolving}_{t}, \\quad \\text{when } t = T_{\\text{phase2}_\\text{end}}^{\\text{epoch}_{e-1}}  \n```\n\n#### **The $`\\eta`$** Generations\n   - This is the final nonce used to determine participant eligibility during epoch $`e`$. \n   - The value of $`\\eta_\\text{e}`$ is derived from the $`\\eta_e^\\text{candidate}`$ contained within the fork that is ultimately selected as the **canonical chain** at the conclusion of $`\\text{epoch}_{e-1}`$.  \n   - It originates from $`\\eta_e^\\text{candidate}`$ concatenated with $`\\eta^\\text{evolving}`$ of the last block of the previous epoch followed by a BLAKE2b-256 hash computation , which becomes stabilized at the conclusion of $`\\text{epoch}_{e-1}`$ and transitions into $`\\text{epoch}_e`$.  \n\n```math\n\\eta_\\text{e} = \\eta^\\text{candidate}_{e}\\ ⭒\\ \\eta^\\text{evolving}_{T_{\\text{end}}^{\\text{epoch}_{e-2}}} , \\quad \\text{when } {\\text{epoch}_e\\text{ starts}} \n```\n\nAs one of these fork will become the canonical main chain, so will the candidate nonce. Hence, the epoch nonce $\\eta_e$ is the candidate nonce of the longest chain at Phase 2, which is determined once the chain stabilises.\n\nFor a detailed formalization of the consensus mechanisms discussed herein, refer to the [Consensus Specifications](https://github.com/IntersectMBO/cardano-formal-specifications?tab=readme-ov-file#consensus-specifications) in the Cardano Formal Specifications repository maintained by IntersectMBO.\n\n<details>\n  <summary>📌📌 <i>Divergence with academic papers</i> – <b>Expand to view the content </b>.\n   </summary> \n<p> \n\nIn the Ouroboros Praos paper, an epoch's random nonce is computed as the hash of the first blocks' **VRF outputs**, combined with some auxiliary information. This design ensures that individual random contributions are **published on-chain**, **publicly verifiable**, and that the final randomness computation $`\\eta_e`$ remains **efficient**. \n\nHowever, in practice, slight modifications were introduced to **distribute the nonce generation cost across the network**. This was achieved by **iterative hashing**, which not only balances the computational load but also ensures **uniform block generation behavior** regardless of a block's position within the epoch. \n\nThe nonce aggregates randomness from the **entire epoch**, rather than a limited subset as described in the academic version of the paper. When generating the nonce for epoch $`e`$, we incorporate:\n\n- **VRF outputs** from **Phase 3** of epoch $`e-2`$  \n- **VRF outputs** from **Phases 1 and 2** of epoch $`e-1`$  \n- The **previous epoch's nonce** $`\\eta_{e-1}`$\n\nThis leads to the following iterative hashing process:\n<div align=\"center\">  \n$`\\eta_e = \\text{Hash}\\left( \\mathsf{VRF}_n \\,\\|\\, \\text{Hash}\\left( \\mathsf{VRF}_{n-1} \\,\\|\\, \\dots \\text{Hash}\\left( \\mathsf{VRF}_1 \\,\\|\\, \\eta^\\text{evolving}_{T_{\\text{end}}^{\\text{epoch}_{e-2}}} \\right) \\dots \\right) \\right)`$\n</div>\n\nThis approach contrasts with the simpler method from the paper, where only the **VRF outputs of Phase 1 and 2 of epoch** $`e-1`$ are hashed together with $`\\eta_{e-1}`$:\n<div align=\"center\">\n$`\\eta_e = \\text{Hash}(\\eta_{e-1} \\,\\|\\, \\mathsf{VRF}_1 \\,\\|\\, \\dots \\,\\|\\, \\mathsf{VRF}_m)`$ \n</div>\n  </p>\n</details>\n\n<details>\n  <summary> 📌📌 <i>Relevant Implementation Code Snippets for This Section</i> – <b>Expand to view the content.</b>\n </summary>\n  \n```haskell\n\n  -- | Evolving nonce type.\ndata Nonce\n  = Nonce !(Hash Blake2b_256 Nonce)\n  | -- | Identity element\n    NeutralNonce\n  deriving (Eq, Generic, Ord, Show, NFData)\n\n-- | Evolve the nonce\n(⭒) :: Nonce -> Nonce -> Nonce\nNonce a ⭒ Nonce b =\n  Nonce . castHash $\n    hashWith id (hashToBytes a <> hashToBytes b)\nx ⭒ NeutralNonce = x\nNeutralNonce ⭒ x = x\n\n-- | Hash the given value, using a serialisation function to turn it into bytes.\n--\nhashWith :: forall h a. HashAlgorithm h => (a -> ByteString) -> a -> Hash h a\nhashWith serialise =\n    UnsafeHashRep\n  . packPinnedBytes\n  . digest (Proxy :: Proxy h)\n  . serialise\n\ninstance HashAlgorithm Blake2b_224 where\n  type SizeHash Blake2b_224 = 28\n  hashAlgorithmName _ = \"blake2b_224\"\n  digest _ = blake2b_libsodium 28\n\nblake2b_libsodium :: Int -> B.ByteString -> B.ByteString\nblake2b_libsodium size input =\n  BI.unsafeCreate size $ \\outptr ->\n    B.useAsCStringLen input $ \\(inptr, inputlen) -> do\n      res <- c_crypto_generichash_blake2b (castPtr outptr) (fromIntegral size) (castPtr inptr) (fromIntegral inputlen) nullPtr 0 -- we used unkeyed hash\n      unless (res == 0) $ do\n        errno <- getErrno\n        ioException $ errnoToIOError \"digest @Blake2b: crypto_generichash_blake2b\" errno Nothing Nothing\n\n\n  ```\n</details>\n\n## **1.4 Forks, Rollbacks, Finality, and Settlement Times**\n\nWith **Ouroboros Praos**, as with [**Nakamoto consensus**](https://coinmarketcap.com/academy/article/what-is-the-nakamoto-consensus) in general, transaction **finality** is **probabilistic** rather than immediate. This means a transaction isn't **guaranteed** to be permanently stored in the **ledger** when it's first included in a **block**. Instead, each additional **block** added on top **strengthens its permanence**, gradually decreasing the likelihood of a **rollback**.\n\n**Ouroboros Praos** guarantees that after $k$ blocks have been produced, the likelihood of a **rollback** diminishes to the point where those blocks can be regarded as **secure** and **permanent** within the **ledger**. However, before these $k$ blocks are finalized, multiple versions of the **blockchain** — commonly referred to as \"**forks**\" — may coexist across the **network**. Each **fork** represents a potential **ledger state** until **finality** is ultimately achieved.\n\nThe **consensus layer** operates with a structure that resembles a branching **\"tree\" of blockchains** before **finality** stabilizes:\n\n<div align=\"center\">\n<img src=\"./image/high-level-ledger-structure.png\" alt=\"\" />\n</div>\n\n#### **Why Do Blockchain Forks Occur?**\n\nBlockchain **forks** can happen for several reasons:\n\n- **Multiple slot leaders** can be elected for a single **slot**, potentially resulting in the production of **multiple blocks** within that **slot**.\n- **Block propagation** across the **network** takes time, causing **nodes** to have differing views of the **current chain**.\n- **Nodes** can dynamically **join** or **leave** the **network**, which is a fundamental challenge in decentralized systems, affecting synchronization and consensus stability.\n- An **adversarial node** is not obligated to agree with the most **recent block** (or **series of blocks**); it can instead choose to append its **block** to an **earlier block** in the **chain**.\n\n#### **Short Forks vs. Long Forks**\n\n**Short forks**, typically just a **few blocks long**, occur **frequently** and are usually **non-problematic**. The **rolled-back blocks** are often nearly identical, containing the **same transactions**, though they might be distributed **differently** among the **blocks** or have **minor differences**.\n\nHowever, **longer forks** can have **harmful consequences**. For example, if an **end-user** (the **recipient** of funds) makes a decision—such as **accepting payment** and **delivering goods** to another user (**the sender of the transaction**)—based on a **transaction** that is later **rolled back** and does not **reappear** because it was **invalid** (e.g., due to **double-spending** a **UTxO**), it creates a **risk of fraud**.\n\n## 2. The Grinding Attack Algorithm  \n\nThis section describes the grinding attack, detailing its objectives, mechanics, and the adversary’s strategy to maximize its effectiveness.\n\n## 2.1 Randomness Manipulation\nWe describe here the grinding attack Cardano's randomness generation protocol suffers from, from passively waiting for its chance or actively maximizing its attack surface, to choosing the best attack vector - stake distribution - to achieve its goal, be it maximizing rewards to controlling target blocks.\n\n### 2.1.1 Exposure \n\nIn its current version, Praos has a vulnerability where an adversary can manipulate the nonce $\\eta_\\text{e}$, the random value used for selecting block producers. This allows the adversary to incrementally and iteratively undermine the uniform distribution of slot leaders, threatening the fairness and unpredictability of the leader selection process.\n\nAt the conclusion of Phase 2, when the $\\eta^\\text{candidate}_{e}$ nonce is determined, the distribution of slot leaders for the next epoch becomes deterministic in a private manner. This means that, at this point, the adversary gains precise knowledge of the slots in which they will be elected but lacks detailed knowledge of the slot distribution for honest participants.\n\nFor example, if the adversary acts as the slot leader immediately before this phase transition, they can choose whether to produce a block or not. This decision grants them the ability to compute and compare two valid nonces - one with one fewer VRF update than the other -, evaluate different slot leader distributions for the upcoming epoch and potentially maximize their future gains at the cost of lesser rewards at this epoch. The more blocks the adversary controls before Phase 2's end, the more nonces they may _grind_ and choose from, and the more critical the attack becomes. In essence, the adversary gains access to up to $2^x$ possible combinations of slot leader distributions, where $x$ denotes the number of controlled leader slots at this particular stage of the protocol.\n\n<div align=\"center\">\n<img src=\"./image/grinding-opportunity-window.png\" alt=\"\" />\n</div>\n\nThis marks the beginning of a grinding attack, where the adversary's initial goal is to maximize the number of adversarial blocks at this critical juncture, either passively by waiting, or actively by reaching a snowball effect. By doing so, they expand the range of potential slot leader distributions they can choose from, significantly enhancing their influence over the protocol. We use the term \"exposure\" here because the adversary is first setting the stage for its attack. \n\n### 2.1.2 Slot Leader Distribution Selection\n\nThis is the pivotal moment where the adversary's prior efforts pay off. They are now in a position with *x* blocks at the critical juncture. At this stage, the adversary can generate up to $2^x$ possible $η$ nonces, compute the next epoch's slot leader distribution for each of them, and strategically select the nonce and distribution that best aligns with their goal. This positioning enables them to deploy the attack effectively in the subsequent epoch.\n\n<div align=\"center\">\n<img src=\"./image/slot-leader-distribution-selection.png\" alt=\"\"/>\n</div>\n\nAs the adversary accumulates blocks, the attack's bottleneck swiftly shifts from waiting for enough blocks at the critical juncture to the computational power needed to compute enough nonces to achieve their goal. \n\nAccumulating a significant number of leader slots at this position necessitates, except when owning a significant portion of the total stake, an underlying intent to exploit or destabilize the protocol. Achieving such a level of control requires significant coordination, making it highly unlikely to occur without deliberate adversarial motives. Once an attacker reaches this threshold, their objectives extend beyond a single exploit and diversify into various strategic threats. \n\n### 2.1.3 Potential Outcomes of Grinding Attacks\n\nBelow is a non-exhaustive list of potential attack vectors, ranging from minor disruptions in system throughput to severe breaches that compromise the protocol’s integrity and structure.\n\n### Economic Exploitation\nManipulating slot leader distributions to prioritize transactions that benefit the adversary or to extract higher fees.\n\n### Censorship Attacks\nSelectively excluding transactions from specific stakeholders to suppress competition or dissent.\n\n### Minority Stake Exploitation\nAmplifying the influence of a small adversarial stake by targeting specific epoch transitions.\n\n### Fork Manipulation\nCreating and maintaining malicious forks to destabilize consensus or execute double-spend attacks.\n\n### Settlement Delays\nStrategically delaying block confirmation to undermine trust in the protocol's settlement guarantees.\n\n### Double-Spend Attacks\nExploiting control over slot leader distributions to reverse confirmed transactions and execute double-spends.\n\n### Chain-Freezing Attacks\nUsing nonce selection to stall block production entirely, halting the protocol and causing network paralysis.\n\n## 2.2. Non-Exhaustive Manipulation Stategy List\n\nThe Ethereum community recently published an insightful paper titled [*Forking the RANDAO: Manipulating Ethereum's Distributed Randomness Beacon*](https://eprint.iacr.org/2025/037). Since the system model used to analyze randomness manipulation in Ethereum is also applicable to Cardano, we will extensively reference their work to explore various manipulation strategies within the Cardano ecosystem. \n\n\n### 2.2.1 System Model\n\nA block can exist in one of four states:  \n\n- **H / Proposed** – The validator successfully proposes a valid block, which is accepted by the supermajority of validators and included in the canonical chain. Honest validators always follow this behavior in our analysis, while adversarial validators may consider alternative strategies, such as withholding blocks.  \n\n- **R / Reorged** – The validator proposes a valid block, but it ends up on a non-canonical branch of the blockchain. This block is no longer considered part of the main chain by the supermajority of the stake.  \n\n- **M / Missed** – The validator fails to publish a block during its designated slot. For an honest validator, this typically results from connectivity issues or other operational failures.  \n\n- **P / Private** – The validator constructs a block but does not immediately publish it during its assigned slot. Instead, an adversarial validator selectively shares the block with validators within its staking pool. Later, the private block may be introduced into the canonical chain by **forking** the next block—a strategy known as an **ex-ante reorg attack**. Alternatively, depending on the evolving chain state, the attacker may decide to withhold the block entirely, a tactic we refer to as **regret**.  \n\n<div align=\"center\">\n<img src=\"./image/grinding-model.png\" alt=\"\" width=\"500\"/>\n</div>\n\nBlock statuses are denoted as $H^e_i, R^e_i, M^e_i, P^e_i$ indicating that the \nblock in the $i$ th slot in epoch $e$ was proposed, reorged, missed, or built privately, respectively. Reorged and missed blocks do not contribute to the generation of $\\eta_e$ since they are not part of the canonical chain. \n\n### 2.2.2 Self Mixing Strategy\n\nThe adversary can selectively propose or miss blocks to manipulate $\\eta_e$. Assume that $\\mathcal{A}$ is assigned with $t$ consecutive tail blocks, formally $\\mathcal{A}^{t}$ of epoch $e$, then $\\mathcal{A}$ can choose arbitrarily between $2^t$ $\\eta_e$ by missing or proposing each tail block. Thus, it is trivial that $\\mathcal{A}^{t} \\in AS_{\\alpha}(m,n)$ for $0 \\leq t \\leq m$, as $\\mathcal{A}$ can compute $\\eta_e$ corresponding to $C^t$.  \n\nThe manipulative power for $t = 2$ is the following decision tree \n\n<div align=\"center\">\n<img src=\"./image/mixing-strategy.png\" alt=\"\" width=\"600\"/>\n</div>\n\ne.g : The adversary chooses option $\\{H^e_{30}, M^e_{31}\\}$ if the calculated $\\eta_e$ eventually leads to the highest number of blocks. In this case, sacrificing Slot 30 and 31 is worthwhile, as it results in a significantly higher number of blocks in epoch $e + 2$.  \n\n### 2.2.3 Forking Strategies\n\n\nTo achieve the goal of maximizing $x$ trailing blocks at this critical juncture, the adversary leverages the forking nature of the consensus protocol by introducing a private chain. By strategically applying the Longest-Chain rule to their advantage, the adversary ensures that the last honest trailing blocks are excluded at this pivotal moment. With this added dimension, gaining access to $2^x$ possible combinations of slot leader distributions becomes equivalent to $x = |A| - |H|$, where $|A|$ and $|H|$ represent the number of adversarial and honest blocks, respectively, within this specific interval of the protocol : \n\n<div align=\"center\">\n  <img src=\"./image/grinding-opportunity.png\" alt=\"Grinding Opportunity\" width=\"600\">\n</div>\n\nThe adversary can choose between **two forking strategies** depending on when they act:\n\n- **Preemptive Forking (Ex-Ante Reorging):** The adversary **forks before** the randomness update, ensuring that only adversarial VRF contributions are included while honest ones are discarded. This allows them to manipulate $\\eta_e$ **before it is finalized**, biasing leader selection for the next epoch.\n\n- **Reactive Forking (Ex-Post Reorging):** Instead of acting in advance, the adversary **waits until all honest VRF contributions are revealed** before deciding whether to fork. If the observed $\\eta_e$ is unfavorable, they **publish an alternative chain**, replacing the honest blocks and modifying the randomness post-facto.\n\nBoth strategies undermine fairness in leader election, with **Preemptive Forking** favoring proactive randomness manipulation and **Reactive Forking** enabling selective, informed chain reorganizations.\n\n## 3. The Cost of Grinding: Adversarial Effort and Feasibility  \n\n### 3.1 Definitions\n\n#### 3.1.1 $\\alpha$-Heavy and Heaviness\nWe define the heaviness of an interval as the percentage of blocks an adversary controls.\nLet $X_A(w)$ be the **number of adversarial blocks** and similarly $X_H(w)$ the **number of honest blocks** in the an interval of $w$ blocks.\nThe **heaviness** of an interval of size $w$ is thus the ratio $\\frac{X_A(w)}{w}$. Heaviness thus vary between 0, where the interval only comprises honest blocks, and 1, where the adversary control them all. \n\nWe say that the interval is $\\mathbf{\\alpha}$**-heavy** if $\\frac{X_A(w)}{w} \\geq \\alpha$. We furthermore say that the adversary _dominates_ the interval if $\\alpha \\geq 0.5$. We shall look from now on to the longest suffix the adversary dominates at the critical juncture, hence the longest interval $w_\\text{max}$ where $\\alpha \\geq 0.5$.\n\n#### 3.1.2 Grinding Power g\n\nAn **$\\alpha$-heavy suffix** must be present at the critical juncture for a grinding attack to be considered. The heavier $w$, for a fixed $w$, the greater the adversary’s grinding power.\n\nThe **grinding power** $g$ of an adversary $A$ is the number of distinct values that $A$ can choose from when determining for the epoch nonce $\\eta$. This quantifies the adversary's ability to manipulate randomness by selectively withholding, recomputing, or biasing values. \n\nLet $g_w(X_A)$ be the number of possible grinding attempts in an interval of size $w$ when controlling $X_A$ blocks. We have,\n\n```math\n\\begin{align*}\ng_w(X_A) &= \\sum_{i= w - X_A(w)}^{X_A(w)} \\binom{X_A(w)}{i}\\\\\n        &= 2^{w} \\text{ when } X_A = w\n\\end{align*}\n```\n\nThe grinding power for a given interval of size $w$ is the sum of $g_w(X_A)$ when the adversary dominates the interval, that is the adverary controls a majority of the blocks. \n\n```math\ng_w = \\sum_{X_A \\geq \\frac{w}{2}}^{w} g_w(X_A)\n```\nSimilarly, we define the **grinding depth**, $\\rho$, as the logarithm of the grinding power: $\\rho = \\log_2 g$, and bound it by $0 \\leq \\rho \\leq 256$. It determines the **entropy reduction** caused by an adversary's nonce manipulation, directly impacting the protocol's resistance to randomness biasing, that is the number of bits of randomness an adversary can manipulate (we upper bound $g_w$ to 256 as the random nonce is 256-bit long).\n\nIn a simplified model where the multi-slot leader feature is not considered, the probability an adversary with $\\text{stake}_A \\in (0,1)$ stake controls $X_A$ out of $w$ blocks is:\n\n```math\nP(\\exists X_A \\in w) = \\binom{w}{X_A}\\ \\text{stake}_A^{X_A}\\ (1 - \\text{stake}_A)^{w-X_A}\n``` \n\nwhere:\n- $\\binom{x}{y}$ represents the number of ways to select $x$ blocks out of $y$.\n- $\\text{stake}_A$ is the percentage of stake controlled by the adversary.\n\n\nWe can now define the expected grinding power $\\mathbb{E}(g)$:\n\n```math\n\\begin{align*}\n\\mathbb{E}(g) &= \\sum_{t=n-s+1}^n g_{n-t} \\cdot P(\\text{\\{slot T is honest and slots T+1..N are A-heavy\\}}) \\\\\n&= (1-\\text{stake}_A) \\sum_{d=1}^s \\sum_{X_A \\geq d/2}^{d} g_d(X_A) \\cdot P(\\exists X_A \\in d)\n\\end{align*}\n``` \n\nIn **Cardano mainnet**, the nonce size used in the randomness beacon is **256 bits**, meaning the theoretical maximum grinding power is $g_{\\max} = 2^{256}$. However, practical grinding power is typically limited by computational constraints and stake distribution dynamics.\n\n#### 3.1.3 Grinding Windows\n\n#### 3.1.3.1 Opportunity Windows $w_O$\n\nThe **grinding opportunity window** $w_O$ is the time interval at the end of Phase 2 during which an adversary, dominating a suffix of size $w$, can compute and reveal one of $g$ possible $\\eta_e^\\text{candidate}$ nonces before the honest chain outpaces their chosen chain.\n\nThe end of Phase 2 happens after $S_2 = \\frac{6k}{f}$ slots, where $\\eta_e^\\text{candidate}$ is sampled from $\\eta^\\text{evolving}$ based on the VRF outputs of blocks up to that point ([see Section 1.3.5](#135-the-randomness-generation-sub-protocol)). Given the protocol parameters $f = \\frac{1}{20}$ and $k = 2,160$, we have  $S_2 = 259,200$.\n\nAssuming the adversary controls the $X_A(w)$ slots (between slot numbered $S_2 - w $ and $S_2$), they can manipulate $X_A(w)$ VRF outputs to generate up to $2^{X_A(w)}$ possible nonces by selectively revealing or withholding each output. After $S_2$, a chain with their chosen nonce — ranging in length from $X_H(w)$ (revealing no blocks, withholding all) to $w$ (revealing all) — is set. As such, the grinding oppotunity window is bounded by :\n\n```math\n\\frac{X_A(w)}{f} \\leq w_O \\leq \\frac{w}{f} \\text{ when w is A-heavy}\n```\n\n**N.B.** Contrary to the grinding power that is upper-bounded by $2^{256}$, the grinding window is bounded by $k$ of Chain Prefix (CP) property.\n\n- **Parameters**:\n  - $f$: Active slot coefficient (e.g., $\\frac{1}{20}$), the fraction of slots with a leader.\n  - Slot duration = 1 second.\n\n<div align=\"center\">\n<img src=\"./image/grinding-depth-vs-opportunity-window.png\" alt=\"\"/>\n</div>\n\n✏️ **Note**: The code to generate this graph is available at ➡️ [this link](./graph/window0_graph.py).\n\nLet's consider the worst case where the adversary controls all trailing slots ($`g = 1 \\Leftrightarrow w = X_A(w)`$):\n\n- **$w = 16$**:\n  - $w_O = \\frac{16}{\\frac{1}{20}} = 16 \\cdot 20 = 320$ seconds (~5.3 minutes).\n  - Starts at $S_2 - w = 259,200 - 16 = 259,184$, ends at $S_2 + \\frac{1}{f} = 259,200 + 20 = 259,220$ (adjusted for reveal timing).\n\n- **$w = 32$**:\n  - $w_O = \\frac{32}{\\frac{1}{20}} = 32 \\cdot 20 = 640$ seconds (~10.7 minutes).\n  - Starts at $S_2 - w = 259,200 - 32 = 259,168$, ends at $259,200 + 20 = 259,220$.\n\n- **$w = 256$**:\n  - $w_O = \\frac{256}{\\frac{1}{20}} = 256 \\cdot 20 = 5,120$ seconds (~85.3 minutes).\n  - Starts at $S_2 - w = 259,200 - 256 = 258,944$, ends at $259,200 + 20 = 259,220$.\n\nThis sizing ensures the adversary has time to act before honest chain growth threatens even a length-1 chain, providing a practical and conservative bound for grinding feasibility.\n\nWe can moreover defined opportunity window with respect to the adversarial stake, $\\text{stake}_A$. The expected opportunity window tends to,\n\n```math\n\\mathbb{E}[w_O] \\approx f^{-1} \\cdot \\left (\\frac{2 \\cdot \\text{stake}_A}{1 - 2 \\cdot \\text{stake}_A} \\right )\n```\n\n- **Parameters**:\n  - $f$: Active slot coefficient (e.g., $\\frac{1}{20}$), the fraction of slots with a leader.\n  - $\\text{stake}_A$ is the percentage of stake controlled by the adversary.\n  - Slot duration = 1 second.\n\n| $\\text{stake}_A$ (%) |    0.5    |     1     |     2     |     5      |     10     |     20     |     25     |     30      |     33       |     40     |     45    |     49    |\n| :----------------------: | :-------:   | :------: | :-------: | :--------: | :--------: | :--------: | :--------: | :---------: | :----------: | :--------: | :-------: | :-------: |\n| $\\mathbb{E}[w_O]$ (s)                      |  2.02E-01\t |4.08E-01\t| 8.33E-01\t| 2.22E00\t | 5.00E00\t  | 13.33E00 \t | 2.00E01 \t|  3.00E01\t  |  3.88E01\t   |  8.00E01  | 1.80E02\t| 9.79E02  |\n\n\n\n<details>\n<summary>📌📌 <i> More Details on the expectation's computation </i> – <b>  Expand to view the content.</b></summary>\n\nTo compute the expectation of the opportunity window, we need to find the earliest slot starting from the end of Phase 2, such that the adversary controls a majority of slots in that interval (and before the chain has been set, that is before $k$ slots).\n\nMore particularly, if we define each slot as a Benoulli random variable $X_1, \\dots, X_{S2}$ such that the slot is takes for value 1 — is owned by the adversary — with probability $p = \\text{stake}_A$, we want to compute the expectation of the earliest position $P \\in \\{1, \\dots, {S2}+1\\}$ such that $\\sum_{i=P}^{S2} X_i \\geq \\frac{{S2} - P + 1}{2}$.\n\nWe can make the problem symmetric by defining $Y_i = 2 \\cdot X_i -1$. In that case, $Y_i = 1$ wth probability $p$ and $Y_i = -1$ with probability $1-p$. We can rewrite the inequality then as,\n\n```math\n\\begin{align*}\n\\sum_{i=P}^{S2} X_i &\\geq \\frac{{S2} - P + 1}{2}\\\\\n\\sum_{i=P}^{S2} \\frac{Y_i - 1}{2} &\\geq \\frac{{S2} - P + 1}{2}\\\\\n\\sum_{i=P}^{S2} Y_i &\\geq 0\n\\end{align*}\n```\n\nBy re-indexing, with $T = {S2} - P + 1$ and $Z_j = Y_{k=j+1}$, we have,\n $\\sum_{j=1}^T Z_j \\geq 0$.\n\nWe can see this sum over $Z_i$ as finding the length of a Gambler's ruin problem with initial stake 0 and sole end condition that the stake becomes negative. As such, we have, $\\mathbb{E}[T] = \\frac{1}{1-2\\cdot p} -1$ (we remove one as ruin is defined as the first time the stake equals $-1$).\n\nThe position $P$ then becomes $\\mathbb{E}[P] = {S2} + 1 - \\mathbb{E}[T] \\approx {S2} + 1 - \\frac{2 \\cdot p}{1 - 2 \\cdot p}$ and the opportunity window is the duration of the interval from position $P$ to the end of the interval of size ${S2}$, hence $\\mathbb{E}[w_O] = f^{-1} \\cdot ({S2} - \\mathbb{E}[p]) = f^{-1} \\cdot \\frac{2 \\cdot p}{1 - 2 \\cdot p}$.\n\n</details>\n\n\n##### 3.1.3.2 Target Window $w_T$\n\nOnce the adversary obtains a potential **candidate nonce** ($\\eta_e^{\\text{candidate}}$) for epoch $e$, they can compute their private **slot leader distribution** for the entire epoch, spanning:  \n\n```math\n\\frac{10k}{f} = \\frac{10 \\cdot 2,160}{0.05} = 432,000 \\text{ slots} = 5 \\text{ days}\n```\n\nWe define the **grinding target window** $w_T$ as the slot interval an adversary targets based on their attack strategy, where $1 \\leq w_T \\leq 4.32 \\cdot 10^5 \\text{ slots}$.\n\n#### 3.1.3 Grinding Attempt\n\nA **grinding attempt** is a single **evaluation of a possible $\\eta$ nonce** by the adversary within the grinding target window $w_O$.  \nEach attempt follows three key steps:  \n\n1. **Computing a candidate $\\eta$ nonce** by selectively revealing or withholding VRF outputs.\n2. **Simulating the resulting slot leader distribution** over the target window $w_T$.  \n3. **Evaluating the strategic benefit** of choosing this $\\eta$ nonce for their attack objectives.  \n\nThe number of grinding attempts an adversary can make is constrained by their **grinding power** $g$, and is upper-bounded by:  \n\n```math\ng \\leq 2^{X_A(w)}\n```\n\nwhere the adversary dominates the suffix of size $w$ at the critical juncture and **$X_A(w)$** represents the number of blocks they control in that interval.  \n\n### 3.2 Entry Ticket: Acquiring Stake to Play the Lottery  \n\nBefore an adversary can execute a grinding attack, they must first **acquire enough stake**, akin to **buying an entry ticket** to participate in a **lottery**.  \nIn this case, the **lottery** is the leader election process, where the probability of winning a slot—and thus influencing the $\\eta$ nonce—is directly proportional to the stake held.  \n\nJust like in a lottery, **the more tickets an adversary buys (stake accumulated), the greater their chances of winning**.  \nBy securing a significant share of stake, they increase the likelihood of being selected as a **slot leader in key trailing positions**, providing the foundation needed to execute a grinding attack.  \n\nThus, the **first cost** of a grinding attack is **not computational but economic** —the price of acquiring enough stake to play the lottery.\n\nTo estimate the cost of these **entry tickets**, we address the following question: \n\n> **How many blocks can an adversary control on average with a given adversarial stake, ensuring a reasonable probability—such as at least one successful grinding opportunity within 10 years** of continuous **epoch-by-epoch execution in Cardano**, where each epoch lasts **5 days**?  \n>  \n> Specifically, for a given adversarial stake, we seek the **maximum $X_A(w)$** for which the probability of obtaining a _dominating_ $\\alpha$-heavy suffix $w_O$ is **at least once over 10 years**, meaning at least one occurrence within **3,650 epochs**.  \n>  \n> **N.B.:** A **10-year period** spans **two full technological innovation cycles**, significantly increasing the likelihood of disruptive advancements in **cryptographic research, computing power, or consensus protocols**. This timeframe provides a long enough horizon for:  \n> - **Assessing long-term adversarial feasibility** and whether stake-based grinding remains viable at scale.  \n> - **Observing historical adversarial behaviors**, particularly in decentralized networks with shifting governance dynamics.  \n> - **Giving the Cardano community sufficient time** to introduce fundamental **protocol-level improvements** to Ouroboros that could **completely mitigate or transform this issue**.  \n\n#### The Data\nWe are computing here the expected number of grinding attempts for both the self-mixing and forking strategies.\n\n##### Self-Mixing\n\nWe present here the average number of years required for an adversary with a stake of $\\text{stake}_A$ to control N blocks. We chose to emphasize frequencies below 10 years, as it is reasonable to assume the protocol will have evolved after such a period.\n\n<div align=\"center\">\n<img src=\"./image/grinding_mixing_years.png\" />\n</div>\n\n(*) We make the simplification to consider the 21,600 blocks directly, that is: there is only 21,600 slots and to each to slot is exactly assigned one slot leader.\n\n<details>\n<summary>📌📌 <i> More Details on Probabilities Here </i> – <b>  Expand to view the content.</b></summary>\n\nWe display here the probabilities of an adversary with a stake of $\\text{stake}_A$ controlling N blocks:\n\n| $N \\text{ vs }\\ \\text{stake}_A$ (%) |    0.5    |     1     |     2     |     5      |     10     |     20     |     25     |     30      |     33       |     40     |     45    |     49    |\n| :----------------------: | :-------:   | :------: | :-------: | :--------: | :--------: | :--------: | :--------: | :---------: | :----------: | :--------: | :-------: | :-------: |\n| $1$                      |  5.00E-03\t |1.00E-02\t| 2.00E-02\t| 5.00E-02\t | 1.00E-01\t  | 2.00E-01 \t | 2.50E-01 \t|  3.00E-01\t  |  3.30E-01\t   |  4.00E-01  | 4.50E-01\t| 4.90E-01  |\n| $2$                      |  2.50E-05\t |1.00E-04\t| 4.00E-04\t| 2.50E-03\t | 1.00E-02\t  | 4.00E-02 \t | 6.25E-02 \t|  9.00E-02\t  |  1.09E-01\t   |  1.60E-01  | 2.03E-01\t| 2.40E-01  |\n| $4$                      |  6.25E-10\t |1.00E-08\t| 1.60E-07\t| 6.25E-06\t | 1.00E-04\t  | 1.60E-03 \t | 3.91E-03 \t|  8.10E-03\t  |  1.19E-02\t   |  2.56E-02  | 4.10E-02\t| 5.76E-02  |\n| $8$                      |  3.91E-19\t |1.00E-16\t| 2.56E-14\t| 3.91E-11\t | 1.00E-08\t  | 2.56E-06 \t | 1.53E-05 \t|  6.56E-05\t  |  1.41E-04\t   |  6.55E-04  | 1.68E-03\t| 3.32E-03  |\n| $16$                     |  1.53E-37\t |1.00E-32\t| 6.55E-28\t| 1.53E-21\t | 1.00E-16\t  | 6.55E-12 \t | 2.33E-10 \t|  4.30E-09\t  |  1.98E-08\t   |  4.29E-07  | 2.83E-06\t| 1.10E-05  |\n| $32$                     |  2.33E-74\t |1.00E-64\t| 4.29E-55\t| 2.33E-42\t | 1.00E-32\t  | 4.29E-23 \t | 5.42E-20 \t|  1.85E-17\t  |  3.91E-16\t   |  1.84E-13  | 7.99E-12\t| 1.22E-10  |\n| $64$                     |  5.42E-148\t |1.00E-128 |\t1.84E-109\t| 5.42E-84\t | 1.00E-64\t  | 1.84E-45 \t | 2.94E-39 \t|  3.43E-34\t  |  1.53E-31\t   |  3.40E-26  | 6.39E-23\t| 1.49E-20  |\n| $128$                    |  2.94E-295\t |1.00E-256 |\t3.40E-218\t| 2.94E-167  | 1.00E-128\t| 3.40E-90 \t | 8.64E-78 \t|  1.18E-67 \t|  2.34E-62\t   |  1.16E-51  | 4.09E-45\t| 2.21E-40  |\n| $256$                    |  0.00E+00\t |0.00E+00\t| 0.00E+00\t| 0.00E+00\t | 1.00E-256\t| 1.16E-179\t | 7.46E-155\t|  1.39E-134\t|  5.49E-124\t |  1.34E-102\t| 1.67E-89\t| 4.90E-80  |\n</details>\n</br>\n\nWe present the expected number (i.e., moment) of grinding attempts during self-mixing, which refers to trailing blocks within an epoch.\n\n| $\\text{stake}_A$ (%) |    0.5    |     1     |     2     |     5     |     10    |     20    |     25    |     30    |     33    |     40    |     45    |     49    |\n| :------------------: | :-------: | :-------: | :-------: | :-------: | :-------: | :-------: | :-------: | :-------: | :-------: | :-------: | :-------: | :-------: |\n| $\\mathbb{E}(X_A)$    |   0.005   |   0.010   |   0.020   |   0.053   |   0.111   |   0.250   |   0.333   |   0.429   |   0.493   |   0.667   |   0.818   |   0.961   |\n\nWe conclude that the self-mixing attack is neither highly probable nor particularly critical.\n\n##### Forking\n\nWe extend here the self-mixing strategy with forking and show how this renders the attack viable. \n\nWe first introduce the formula for the probability for an adversary having $\\text{stake}_A$ stake of having an advantage of $|X_A - X_H| = N$ blocks, that is an adversary controlling a majority of $N$ blocks, in any given interval smaller than $s$ blocks where $s$ is from the $s$-CQ property. \n\n``` math\n\\begin{align*}\n\\Delta_{i,N} &= \\binom{N + 2 \\cdot i}{N + i} - \\sum_{j=0}^{i-1}  \\binom{2 \\cdot (i-j)}{i-j} \\cdot \\Delta_{j,n} \\text{ and } \\Delta_0^N = 1 \\\\\nP(|X_A-X_H|=N) &= \\sum_{i=0}^{\\lfloor s/2 \\rfloor} \\Delta_{i,N} \\cdot \\text{stake}_A^{N+i} \\cdot (1-\\text{stake}_A)^i \n\\end{align*}\n```\n\nAs the formula is not computationally friendly, instead of showing numbers for an interval of size $s$, we look at a smaller interval of size $precision$, to give us a lower-bound on these numbers. We now display a lower bound on the probabilities of having  an advantage of $|X_A - X_H| = N$ blocks, and an upper-bound on the frequency of a corresponding grinding attack per year.\n\n\n<details>\n<summary>📌📌 <i> More Details on Probabilities Here </i> – <b>  Expand to view the content.</b></summary>\n\nWe display here the probabilities of an adversary with a stake of $\\text{stake}_A$ controlling a majority of blocks such that $|X_A - X_H| = N$:\n\n| $N \\text{ vs }\\ \\text{stake}_A$ (%) |    0.5    |     1     |     2     |     5      |     10     |     20     |     25     |     30      |     33       |     40     |     45    |     49    |\n| :----------------------: | :-------:   | :------: | :-------: | :--------: | :--------: | :--------: | :--------: | :---------: | :----------: | :--------: | :-------: | :-------: |\n| $1$                      |  5.00E-03\t |1.00E-02\t| 2.00E-02\t| 5.00E-02\t | 1.00E-01\t  | 2.00E-01 \t | 2.50E-01 \t|  3.00E-01\t  |  3.30E-01\t   |  4.00E-01  | 4.50E-01\t| 4.90E-01  |\n| $2$                      |  2.50E-05\t |1.00E-04\t| 4.00E-04\t| 2.50E-03\t | 1.00E-02\t  | 4.00E-02 \t | 6.25E-02 \t|  9.00E-02\t  |  1.09E-01\t   |  1.60E-01  | 2.03E-01\t| 2.40E-01  |\n| $4$                      |  6.25E-10\t |1.00E-08\t| 1.60E-07\t| 6.25E-06\t | 1.00E-04\t  | 1.60E-03 \t | 3.91E-03 \t|  8.10E-03\t  |  1.19E-02\t   |  2.56E-02  | 4.10E-02\t| 5.76E-02  |\n| $8$                      |  3.91E-19\t |1.00E-16\t| 2.56E-14\t| 3.91E-11\t | 1.00E-08\t  | 2.56E-06 \t | 1.53E-05 \t|  6.56E-05\t  |  1.41E-04\t   |  6.55E-04  | 1.68E-03\t| 3.32E-03  |\n| $16$                     |  1.53E-37\t |1.00E-32\t| 6.55E-28\t| 1.53E-21\t | 1.00E-16\t  | 6.55E-12 \t | 2.33E-10 \t|  4.30E-09\t  |  1.98E-08\t   |  4.29E-07  | 2.83E-06\t| 1.10E-05  |\n| $32$                     |  2.33E-74\t |1.00E-64\t| 4.29E-55\t| 2.33E-42\t | 1.00E-32\t  | 4.29E-23 \t | 5.42E-20 \t|  1.85E-17\t  |  3.91E-16\t   |  1.84E-13  | 7.99E-12\t| 1.22E-10  |\n| $64$                     |  5.42E-148\t |1.00E-128 |\t1.84E-109\t| 5.42E-84\t | 1.00E-64\t  | 1.84E-45 \t | 2.94E-39 \t|  3.43E-34\t  |  1.53E-31\t   |  3.40E-26  | 6.39E-23\t| 1.49E-20  |\n| $128$                    |  2.94E-295\t |1.00E-256 |\t3.40E-218\t| 2.94E-167  | 1.00E-128\t| 3.40E-90 \t | 8.64E-78 \t|  1.18E-67 \t|  2.34E-62\t   |  1.16E-51  | 4.09E-45\t| 2.21E-40  |\n| $256$                    |  0.00E+00\t |0.00E+00\t| 0.00E+00\t| 0.00E+00\t | 1.00E-256\t| 1.16E-179\t | 7.46E-155\t|  1.39E-134\t|  5.49E-124\t |  1.34E-102\t| 1.67E-89\t| 4.90E-80  |\n</details>\n</br>\n\n\n\n<div align=\"center\">\n<!-- <img src=\"./image/grinding_forking_probabilities.png\" alt=\"\" /> -->\n<img src=\"./image/grinding_forking_years.png\" alt=\"\" />\n</div>\n\n\nWe now tabulatethe grinding power's expectation when looking at different precision $s$. While the expectation converges quickly for small stake, smaller than 20\\%, we can note it significicantly rises afterwards.\n $\\text{precision} \\text{ vs stake}_A$ |   0.5% |   1.0% |   2.0% |   5.0% |   10.0% |   20.0% |    25.0% |    30.0% |     33.0% |     40.0% |     45.0% |     49.0% |\n| :----------------------------------: | :----: | :----: | :----: | :----: | :-----: | :-----: | :------: | :------: | :-------: | :-------: | :-------: | :-------: |\n| 16                                   | 0.0203 | 0.0414 | 0.0857 |  0.242 |   0.636 |    3.49 |     8.86 |       22 |      36.8 |       108 |       209 |       334 |\n| 32                                   | 0.0203 | 0.0414 | 0.0857 |  0.242 |   0.637 |    5.71 |     43.4 |      384 |     1,290 |    15,100 |    65,700 |   185,000 |\n| 64                                   | 0.0203 | 0.0414 | 0.0857 |  0.242 |   0.637 |    8.93 |     1010 |  145,000 |  2.01e+06 |  3.56e+08 |  7.36e+09 |  6.06e+10 |\n| 128                                  | 0.0203 | 0.0414 | 0.0857 |  0.242 |   0.637 |    13.6 |  786,000 | 2.92e+10 |  6.59e+12 |  2.44e+17 |  1.05e+20 |  6.87e+21 |\n| 256                                  | 0.0203 | 0.0414 | 0.0857 |  0.242 |   0.637 |    20.2 | 6.98e+11 | 1.64e+21 |   9.6e+25 |  1.45e+35 |  2.48e+40 |  9.29e+43 |\n| 512                                  | 0.0203 | 0.0414 | 0.0857 |  0.242 |   0.637 |    29.6 | 7.87e+23 | 7.19e+42 |   2.8e+52 |  6.59e+70 |  1.64e+81 |  1.79e+88 |\n| 1024                                 | 0.0203 | 0.0414 | 0.0857 |  0.242 |   0.637 |      43 | 1.43e+48 | 1.94e+86 | 3.32e+105 | 1.84e+142 | 8.81e+162 | 7.03e+176 |\n\nWe can approximate the expected grinding power as an exponential function of the precision, i.e. $E(g, n)= \\text{poly}(n) \\cdot \\zeta^n$. Looking at the exponential's based, $\\zeta$ can tell us precisely when the grinding power becomes rises exponentially, that is when $\\zeta = 1$ the exponentiaition starts growing instead of decaying. The following graph indeed confirms that 20\\% is the threshold.\n\n<div align=\"center\">\n<img src=\"./image/grinding_moment.png\" alt=\"\" />\n</div>\n\n<!-- \n<img src=\"./image/proba_controlling_majority_x_blocks.png\" alt=\"\" width=\"500\"/>\n<img src=\"./image/table-legend.png\" alt=\"\" width=\"500\"/>\n-->\n\nThe details of the calculations underlying this table can be found in the following Google Spreadsheet: [Details of Calculations](https://docs.google.com/spreadsheets/d/1DGG4tXTngc2Zu5_IMlWsPoARksgBEMbTCyqBAgKHe7E/edit?gid=0#gid=0).\n\nFor example, with **5% adversarial stake**, it would take about **1800 years** in average for an adversary to obtain an advantage of of exactly 4 blocks at the critical juncture.\n\n####  The Results\n\n<div align=\"center\">\n<img src=\"./image/grinding_depth_comparison.png\" alt=\"\" />\n<img src=\"./image/grinding_power_comparison.png\" alt=\"\" />\n</div>\n\n**N.B** : This analysis does not account for recursion in addition to the forking and self-mixing strategy, so the curve should actually be even steeper than in the graph above. \n\nThis investment is non-trivial and serves as an implicit deterrent to attacks, as the adversary must weigh the risks of financial exposure against potential gains. While stake acquisition might appear as a sunk cost, it can, in some cases, be viewed as an active investment in the blockchain ecosystem. For instance, an adversary with a large stake may not only attempt manipulation but could also seek to benefit from staking rewards, governance influence, or other economic incentives, adding an additional layer of strategic decision-making.\n\nResults suggests that **crossing the 20% stake threshold** dramatically increases an adversary’s probability of influencing leader elections. With such control, their ability to manipulate leader election outcomes becomes **exponentially and primarily constrained by computational feasibility rather than probabilistic limitations**.\n\nAs of **March 1, 2025**, acquiring a 20% stake in Cardano would require an investment exceeding **4.36 billion ADA**, a substantial sum that introduces a fundamental **game-theoretic disincentive**:  \n- A successful attack could undermine the blockchain’s integrity, leading to **loss of trust and stake devaluation**.  \n- If the attack is detected, **reputational damage, delegator withdrawals, or protocol-level countermeasures** could make the adversary's stake significantly less valuable.\n\n> This reinforces **transparency as a natural deterrent**: publicly observable grinding attempts expose adversarial stake pool operators (SPOs) to severe economic and social consequences.\n\n### 3.3 Cost of a Grinding Attempt  \n\nAs previously explained, each attempt consists of three key steps:  \n\n1. **Computing a candidate $\\eta$ nonce** by selectively revealing or withholding VRF outputs.  \n2. **Simulating the resulting slot leader distribution** over the target window $w_T$.  \n3. **Evaluating the strategic benefit** of choosing this $\\eta$ nonce for adversarial objectives.  \n\nLet's analyze each of these steps.  \n\n### 3.3.1 Nonce Generation  \n\nWe will denote this step as $T_{\\text{nonce}}^\\rho$ moving forward. \n\nNonce generation consists of:  \n\n1. **VRF Evaluation**: Computes a candidate $\\eta$ nonce.  \n2. **$\\ast$ Operation**: Concatenation + **BLAKE2b-256** hashing.  \n\nSince the VRF outputs can be precomputed, we can discard them from the computational cost of a grinding attack. As for the computational cost, as the hash functions are protected against extension attacks, we have to consider the average cost of hashing of all nonces when considering a fixed grinding depth $\\rho$.\n\nWe make the assumption that hashing $n$ inputs takes as much time as hashing $n$ times two inputs, that is that the finalization step of a hashing function is not significant. We also look at the worst case scenario, for simplification, and assume that $g = 2^{X_A(w)}$.\n\n```math\nT_{\\text{nonce}}^\\rho =  T_{\\text{BLAKE2b}} \\cdot \\frac{\\sum_i i  \\cdot \\binom{\\rho + i}{\\rho}}{2^\\rho} = \\frac{\\rho}{2} \\cdot T_{\\text{BLAKE2b}}\n```\n**N.B.** We may drop the superscript $\\rho$ for readibility.\n\n**N.B.** This represents the average time to compute a nonce. While each nonce can be computed in parallel, we cannot easily parallelize the generation of one nonce as the computation is sequential. \n\n### 3.3.2 Slot Leader Distribution Evaluation  \n\nWe will denote this step as $T_{\\text{distribution}}$ moving forward. \n\nAfter generating a candidate nonce, the adversary must evaluate its impact on **slot leader election** over an target window $w_T$ :  \n\n1. **Computing VRF outputs** for all slots in $w_T$ of interest.  \n2. **Evaluating the eligibilty of these values** to know when the adversary is the slot leader.  \n\nSince **leader eligibility is unknown in advance**, the adversary must verify **all slots** in $w_T$.\n\nDefine:\n- $w_T$ → **target window size (seconds)**.\n- $T_{\\mathsf{VRF}}$ → **VRF evaluation time**.\n- $T_{\\text{eligibility}}$ → **Slot eligilibity check**.\n\nEach slot requires **one VRF verification**, leading to:\n\n```math\nT_{\\text{distribution}} = w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} )\n```\n\nThis represents the total time of the leader distribution evaluation. Once a nonce is computed, we can generate and check the eligibility of the VRF outputs in parallel.\n\n\n\n### 3.3.3 Strategic Benefit Evaluation  \n\nWe denote this step as $T_{\\text{eval}}$ moving forward.\n\nAfter simulating the leader election distribution, the adversary must determine whether the selected $\\eta$ nonce provides a **strategic advantage** by:  \n\n1. **Assessing block production gains** relative to honest stake.  \n2. **Estimating adversarial control over leader election.**  \n3. **Comparing multiple nonces** to select the most effective one.  \n\n#### **Nature of the Computational Workload**  \n\nUnlike previous steps, this phase does not perform a single deterministic computation but operates as an **evaluation loop over a dataset of adversarial leader election scenarios**. The attacker’s dataset includes:  \n\n- **Nonce-to-leader mappings** → which nonces yield better leadership control.  \n- **Stake distributions** → impact of adversarial stake on slot control.  \n- **Slot timing predictions** → evaluating when it's best to control a block.  \n- **Secondary constraints** → network conditions, latency factors, or additional attack-specific considerations.  \n\nSince this **\"database\" of possible leader elections** depends on **adversarial strategies**, the cost is too diverse to define precisely. While the **exact cost varies**, this step is **compulsory** and must be factored into the total grinding time. \n\n### 3.3.4 Total Estimated Time per Grinding Attempt  \n\nThe total grinding time is the sum of:  \n\n1. **Nonce Generation ($T_{\\text{nonce}}$)** → VRF evaluation + hashing.  \n2. **Slot Leader Simulation ($T_{\\text{distribution}}$)** → Eligibility checks over $w_T$.  \n3. **Strategic Evaluation ($T_{\\text{eval}}$)** → Nonce selection analysis.  \n\n#### **Total Grinding Time Formula**  \n\n```math\nT_{\\text{grinding}} = T_{\\text{nonce}} + T_{\\text{distribution}} + T_{\\text{eval}}\n```\n\nExpanding each term:\n\n- **Nonce Generation:** : $T_{\\text{nonce}} = \\frac{\\rho}{2} \\cdot T_{\\text{BLAKE2b}}$\n- **Slot Leader Verification** : $T_{\\text{verify}} = w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} )$\n- **Strategic Evaluation** : $T_{\\text{eval}}$ (attack-dependent term)\n\nFinal expression:\n\n```math\nT_{\\text{grinding}} = \\frac{\\rho}{2} \\cdot T_{\\text{BLAKE2b}} + w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}}\n```\n\nWhere:\n- $T_{\\mathsf{VRF}}$ is the VRF evaluation time.\n- $T_{\\text{eligibility}}$ is the eligibility checktime.\n- $T_{\\text{BLAKE2b}}$ is the time for the hashing operation.\n- $w_T$ is the target window size (seconds).\n- $\\rho$ is the grinding power.\n- $T_{\\text{eval}}$ is the nonce selection and evaluation time, which is attack-specific.\n\n### 3.4 Cost of a Grinding Attack\n\n### 3.4.1 Formula\n\nA **grinding attack** consists of multiple grinding attempts executed within the **grinding opportunity window** $w_O$. Since each grinding attempt takes time to compute, the feasibility of the attack depends on whether the total computation can be completed within this window.\n\nWe define the **total attack time** as:\n\n```math\nT_{\\text{attack}} = \\frac{2^{\\rho} \\cdot T_{\\text{grinding}}}{N_{\\text{CPU}}}\n```\n\nwhere:\n- $\\rho$ = **grinding depth** (bits of entropy the adversary can manipulate),\n- $T_{\\text{grinding}}$ = **time required for one grinding attempt**,\n- $N_{\\text{CPU}}$ = **number of CPUs available for parallel execution**.\n\nFor the attack to be feasible, this total time must fit within the **grinding opportunity window** $w_O$:\n\n```math\n\\frac{2^{\\rho} \\cdot T_{\\text{grinding}}}{N_{\\text{CPU}}} \\leq w_O\n```\nwhich leads to the lower bound on computational power ($N_CPU$) : \n\n```math\nN_{\\text{CPU}} \\geq \\left \\lceil \\frac{2^{\\rho} \\cdot T_{\\text{grinding}}}{w_O}\\right \\rceil\n```\n\n#### Expanding $T_{\\text{grinding}}$\nFrom **Section 3.3**, the per-attempt grinding time is:\n\n```math\nT_{\\text{grinding}} = \\frac{\\rho}{2} \\cdot T_{\\text{BLAKE2b}} + w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}}\n```\n\nSubstituting this into the inequality:\n\n```math\nN_{\\text{CPU}} \\geq \\left \\lceil \\frac{2^{\\rho} \\cdot \\left( \\frac{\\rho}{2} \\cdot T_{\\text{BLAKE2b}} + w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}} \\right)}{w_O} \\right \\rceil\n```\n\n\n#### Expanding $w_O$ in Terms of $\\rho$ and $f$\nFrom previous sections, the **grinding opportunity window** is:\n\n```math\n\\frac{X_A(w)}{f} \\leq w_O \\leq \\frac{w}{f}\n```\n\nSubstituting this into our equation:\n\n```math\n\\begin{align*}\nN_{\\text{CPU}} &\\geq  \\left \\lceil \\frac{f \\cdot 2^{\\rho}}{w} \\cdot \\left( \\frac{\\rho}{2} \\cdot T_{\\text{BLAKE2b}} + w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}} \\right) \\right \\rceil\\\\\n& \\geq  \\left \\lceil \\frac{f \\cdot 2^{\\rho}}{2 \\rho - 1} \\cdot \\left( \\frac{\\rho}{2} \\cdot T_{\\text{BLAKE2b}} + w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}} \\right) \\right \\rceil \\text{, as the interval is dominated, i.e. } w < 2 \\cdot \\rho - 1\\\\\n& \\geq  \\left \\lceil f \\cdot 2^{\\rho-2} \\cdot \\left ( T_{\\text{BLAKE2b}} + 2 \\rho^{-1} \\cdot \\left [ w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}} \\right ] \\right ) \\right \\rceil\n\n\\end{align*}\n```\n\n### 3.4.2 Estimated Formula Using Mainnet Cardano Parameters\n\nStarting from the final expression at the end of the last section:\n\n```math\nN_{\\text{CPU}}  \\geq  \\left \\lceil f \\cdot 2^{\\rho-2} \\cdot \\left ( T_{\\text{BLAKE2b}} + 2 \\rho^{-1} \\cdot \\left [ w_T \\cdot ( T_{\\mathsf{VRF}} + T_{\\text{eligibility}} ) + T_{\\text{eval}} \\right ] \\right ) \\right \\rceil\n```\n\n#### Applying Cardano Mainnet Parameters\nUsing Cardano’s mainnet values:\n- $T_{\\mathsf{VRF}} = 10^{-6}$ seconds (1 microsecond) – Time to evaluate a Verifiable Random Function.\n- $T_{\\text{BLAKE2b}} = 10^{-8}$ seconds (0.01 microseconds) – Time for a BLAKE2b-256 hash operation.\n- $f = \\frac{1}{20} = 0.05$ – Active slot coefficient.\n- Slot duration = 1 second.\n\nThus, the expression becomes:\n\n```math\nN_{\\text{CPU}}  \\geq  \\left \\lceil 5 \\cdot 10^{-10} \\cdot 2^{\\rho-2} + 5 \\cdot 10^{-8} \\cdot w_T \\cdot \\rho^{-1} \\cdot 2^{\\rho-1}  + 5 \\cdot 10^{-2} \\cdot T_{\\text{eval}} \\cdot \\rho^{-1} \\cdot 2^{\\rho-1} \\right \\rceil\n```\n\nwhere each step contributes as follows,\n- **Nonce Generation:** : $5 \\cdot 10^{-10} \\cdot 2^{\\rho-2}$\n- **Slot Leader Verification** : $5 \\cdot 10^{-8} \\cdot w_T \\cdot \\rho^{-1} \\cdot 2^{\\rho-1} $\n- **Strategic Evaluation** : $5 \\cdot 10^{-2} \\cdot T_{\\text{eval}} \\cdot \\rho^{-1} \\cdot 2^{\\rho-1}$\n\n\n#### Final Expression\nThe estimated number of CPUs required is:\n\n```math\nN_{\\text{CPU}}  \\geq  \\left \\lceil 5 \\cdot 10^{-10} \\cdot 2^{\\rho-2} + 5 \\cdot 10^{-8} \\cdot \\frac{w_T \\cdot 2^{\\rho-1}}{\\rho}  + 5 \\cdot 10^{-2} \\cdot \\frac{T_{\\text{eval}} \\cdot 2^{\\rho-1}}{\\rho} \\right \\rceil\n```\n\n- $\\rho$: The number of blocks controlled by the adversary.\n- $w_T$: The target window (in seconds), ranging from short (e.g., 3600 s) to a full epoch (e.g., 432,000 s), as defined in [Section 3.5 - Scenarios](#35-scenarios).\n- $T_{\\text{eval}}$: The strategic evaluation time (in seconds), varying from 0 to 1, as explored in [Section 3.5 - Scenarios](#35-scenarios).\n\nThis expression transitions the theoretical cost model into a practical estimate, with specific values for $w_T$ and $T_{\\text{eval}}$ evaluated in [Section 3.5 - Scenarios](#35-scenarios) to assess feasibility across different attack strategies.\n\n\n## 3.5 Scenarios\n\nFollowing the computational model from [Section 3.4.2 - Estimated Formula Using Mainnet Cardano Parameters](#342-estimated-formula-using-mainnet-cardano-parameters), we explore four scenarios to observe how randomness manipulation behaves across varying grinding depths $\\rho$. These scenarios are framed with an animal-inspired metaphor reflecting evaluation complexity ($T_{\\text{eval}}$) and observation scope ($w_T $), providing a basis for graphical analysis to be developed later.\n\n| **Scenario**    | **$T_{\\text{eval}}$ (Complexity)** | **$w_T$ (Scope)** | **Description**                                                                 |\n|-----------------|--------------------------------------|---------------------|---------------------------------------------------------------------------------|\n| **Ant Glance**  | 0 (Low)                              | 0s          | An ant quickly glancing at a small spot, representing simple evaluation (low $T_{\\text{eval}}$) with basic effort and a narrow observation scope (minimal $w_T$). |\n| **Ant Patrol**  | 0s (Low)                              | 5d (432,000 s)      | An ant patrolling a wide area over time with simple instincts, representing simple evaluation (low $T_{\\text{eval}} $) with basic effort and a broad observation scope (large $w_T$). |\n| **Owl Stare**   | 1s (High)                             | 0s         | An owl staring intently at a small area with keen focus, representing complex evaluation (high $T_{\\text{eval}} $) with advanced effort and a narrow observation scope (minimal $w_T$). |\n| **Owl Survey**  | 1s (High)                             | 5d (432,000 s)      | An owl surveying a wide range with strategic awareness, representing complex evaluation (high $T_{\\text{eval}} $) with advanced effort and a broad observation scope (large $w_T$). |\n\nThe $N_{\\text{CPU}}$ formulas are derived by substituting the respective $w_T$ and $T_{\\text{eval}}$ values from each scenario into the base expression : \n```math \nN_{\\text{CPU}}  \\geq  \\left \\lceil 5 \\cdot 10^{-10} \\cdot 2^{\\rho-2} + 5 \\cdot 10^{-8} \\cdot \\frac{w_T \\cdot 2^{\\rho-1}}{\\rho}  + 5 \\cdot 10^{-2} \\cdot \\frac{T_{\\text{eval}} \\cdot 2^{\\rho-1}}{\\rho} \\right \\rceil\n```\n\n| **Scenario**    | **$N_{\\text{CPU}}$ Formula**                                                                                     |\n|-----------------|-----------------------------------------------------------------------------------------------------------------|\n| **Ant Glance**  | $5 \\cdot 10^{-10} \\cdot 2^{\\rho-2}$ |\n| **Ant Patrol**  | $5 \\cdot 10^{-10} \\cdot 2^{\\rho-2} + 2.16 \\cdot 10^{-2} \\cdot \\frac{2^{\\rho-1}}{\\rho}$ |\n| **Owl Stare**   | $5 \\cdot 10^{-10} \\cdot 2^{\\rho-2} + 5 \\cdot 10^{-2} \\cdot \\frac{2^{\\rho-1}}{\\rho}$ |\n| **Owl Survey**  | $5 \\cdot 10^{-10} \\cdot 2^{\\rho-2} + 7.16 \\cdot 10^{-2} \\cdot \\frac{2^{\\rho-1}}{\\rho}$ |\n\n\n<div align=\"center\">\n<img src=\"./image/grinding-depth-vs-NCPU.png\" alt=\"\" />\n</div>\n\n✏️ **Note**: The code to generate this graph is available at ➡️ [this link](./graph/scenario_cpu_graph.py).\n\n\nThe maximal delta $\\Delta \\log_{10}(N_{\\text{CPU}})$ (**Owl Survey** minus **Ant Glance**) is now approximately $6.8$, reflecting a dramatic difference in computational requirements between the simplest and most complex scenarios. This illustrates that $T_{\\text{eval}}$ and $w_T$ together form a pre-exponential amplification of up to $10^{6.8}$ CPUs, which is then further scaled by the exponential factor $2^{\\rho}$. The yellow line (**Ant Patrol**) sits between the blue (**Ant Glance**) and red (**Owl Survey**) lines, with a delta of approximately $6.2$ from **Ant Glance**, confirming that its high $w_T = 432{,}000$ s causes a **~120x CPU increase** relative to **Ant Glance**, despite both having $T_{\\text{eval}} = 0$.\n\nThe green line (**Owl Stare**), lies below the red line (Owl Survey), with a delta of approximately 0.16 in $\\log_{10}(N_{\\text{CPU}})$. \n\nAt $\\rho = 50$:\n\n- **Ant Glance** ($T_{\\text{eval}} = 0$, $w_T = 0$): $N_{\\text{CPU}} \\approx 5.36 \\cdot 10^{7}$, $\\log_{10}(N_{\\text{CPU}}) \\approx 5.16$\n- **Ant Patrol** ($T_{\\text{eval}} = 0$, $w_T = 432{,}000$): $N_{\\text{CPU}} \\approx 6.32 \\cdot 10^{9}$, $\\log_{10}(N_{\\text{CPU}}) \\approx 11.40$\n- **Owl Stare** ($T_{\\text{eval}} = 1$, $w_T = 0$): $N_{\\text{CPU}} \\approx 1.65 \\cdot 10^{10}$, $\\log_{10}(N_{\\text{CPU}}) \\approx 11.77$\n- **Owl Survey** ($T_{\\text{eval}} = 1$, $w_T = 432{,}000$): $N_{\\text{CPU}} \\approx 2.37 \\cdot 10^{11}$, $\\log_{10}(N_{\\text{CPU}}) \\approx 11.92$\n\n\n### 3.6 Grinding Power Computational Feasibility\n\nBuilding on the analysis in previous [Section 3.5](##35-scenarios), we assessed the feasibility of grinding attacks by examining the computational resources ($N_{\\text{CPU}}$) required across different grinding depths ($\\rho$). The scenarios (Ant Glance, Ant Patrol, Owl Stare, Owl Survey) show a consistent $\\Delta \\log_{10}(N_{\\text{CPU}}) \\sim 2.6$, meaning the most demanding scenario (Owl Survey) requires $10^{2.6}$ times more CPUs than the least demanding (Ant Glance).\n\nTo help readers understand the practicality of these attacks, we define feasibility thresholds based on economic and computational viability, as shown in the table below:\n\n| **Feasibility Category**          | **Cost Range (USD)**         | **Description**                                                                                                   |\n|------------------------------------|------------------------------|------------------------------------------------------------------------------------------------------------------|\n| **Trivial**                       | < $10,000                       | Representing an amount easily affordable by an individual with basic computing resources, such as a personal computer. |\n| **Feasible**                      | $10,000 to $1,000,000        | Reflects costs that require a substantial financial commitment, typically beyond the reach of individuals but manageable for well-funded entities, such as tech startups, research groups, or organized crime syndicates, assuming access to mid-tier cloud computing resources or a dedicated server farm, necessitating a strategic investment that signals a serious intent to exploit the network. |\n| **Possible**                      | $1,000,000 to $1,000,000,000 | Reflects costs that demand resources on the scale of large corporations, government agencies, or nation-states, implying the use of extensive computational infrastructure (e.g., data centers) and significant capital, suggesting an attack that requires coordinated effort and advanced planning, potentially involving millions of CPU hours or specialized hardware. |\n| **Borderline Infeasible**         | $1,000,000,000 to $1,000,000,000,000 | Indicates costs that approach the upper bounds of what global economies can sustain for a single project, requiring resources comparable to those of major international organizations or coalitions, pushing the limits of current computational and financial capabilities, and suggesting that such an endeavor would strain even well-resourced entities, making it highly improbable without global-scale coordination. |\n| **Infeasible**                    | > $1,000,000,000,000         | Denotes costs exceeding 1 trillion usd, deemed infeasible because they surpass the total economic output or computational capacity available globally (e.g., estimated at $`\\sim 10^{15}`$ CPUs or $`\\sim \\$100`$ trillion GDP as of 2025), implying an attack that is theoretically possible only with resources beyond current technological or economic limits, rendering it practically impossible with present-day infrastructure. |\n\nThe cost model uses the $N_{\\text{CPU}}$ formulas from [Section 3.5 - Scenarios](#35-scenarios), computes the number of CPUs needed for the attack, and multiplies by the CPU rental price ($0.01$ per CPU-hour) and runtime defined by the grinding opportunity window $w_O = \\frac{2\\rho - 1}{f}$ seconds (with $f = 0.05$) to estimate the total cost.\n\nCosts are estimated assuming a CPU rental price of $0.01$ per CPU-hour, based on low-end instance pricing from major cloud providers like AWS as of March 11, 2025, where basic instances such as t2.micro cost approximately $0.0116$ per CPU-hour [AWS EC2 Pricing Page](https://aws.amazon.com/ec2/pricing/). However, for high-performance tasks, actual costs may range from $0.04$ to $0.08$ per CPU-hour, as seen with `AWS c5.large` ($0.048$) or `Azure Standard_F2s_v2` ($0.0372$). \n\nThe table below summarizes the feasibility for `Owl Survey` ($T_{\\text{eval}} = 1$, $w_T = 432,000 \\, \\text{s}$), the most resource-intensive scenario, at different $\\rho$ values, using the $0.01$ estimate for initial assessment:\n\n| $\\rho$ | CPUs Required (Log₁₀ Scale) | Estimated Cost (USD) | Feasibility |\n|----------|-----------------------------|----------------------------------|-------------|\n| **31**   | $10^6$ CPUs     | 8,394.76                        | Trivial for any adversary |\n| **37**   | $10^8$ CPUs     | 539,954                         | Feasible with standard resources |\n| **47**   | $10^{11}$ CPUs  | 553.79 million               | Possible with large-scale infrastructure |\n| **48**   | $10^{11}$ CPUs  | 1.107 billion               | Borderline Infeasible, requires massive resources |\n| **58**   | $10^{14}$ CPUs  | 1.137 trillion              | Infeasible, exceeds global computing capacity |\n\n- **CPUs Required**: Computed for Owl Survey at each $\\rho$, rounded to the nearest order of magnitude for readability (exact values approximated).\n- **Cost**: Assumes $0.01$ per CPU-hour, scaled for the runtime $w_O = 20 (2\\rho - 1)$ seconds.\n- **Feasibility**: Assessed based on computational and economic viability, considering global computing resources (e.g., $\\sim 10^{12}$ CPUs in modern data centers, $\\sim 10^{15}$ CPUs globally as of March 11, 2025).\n\n<br> \n<details>\n<summary>📌 Example Calculation for ρ = 50 (Owl Survey)</summary>\n<br>\n\nLet’s walk through the calculation for the Owl Survey scenario at $\\rho=50$ to demonstrate how the values in the table are derived. The Owl Survey scenario has $T_{\\text{eval}}=1$ (high complexity) and $w_T=432,000\\,\\text{s}$ (5 days), making it the most resource-intensive scenario.\n\n### Step 1: Compute $N_{\\text{CPU}}$\n\nThe formula for $N_{\\text{CPU}}$ in the Owl Survey scenario, as given in [Section 3.5 - Scenarios](#35-scenarios), is:\n\n```math\nN_{\\text{CPU}} \\geq 5 \\cdot 10^{-10} \\cdot 2^{\\rho-2} + 7.16 \\cdot 10^{-2} \\cdot \\frac{2^{\\rho-1}}{\\rho}\n```\n\nFor $\\rho=50$, the expression becomes:\n\n```math\n\\begin{align*}\nN_{\\text{CPU}} &\\geq 5 \\cdot 10^{-10} \\cdot 2^{48} + 7.16 \\cdot 10^{-2} \\cdot \\frac{2^{49}}{50}\\\\\n               &\\geq 8.06 \\cdot 10^{11}\n\\end{align*}\n```\n\nIn $\\log_{10}$ scale:\n\n```math\n\\log_{10}(5 \\cdot 10^{-10} \\cdot 2^{48} + 7.16 \\cdot 10^{-2} \\cdot \\frac{2^{49}}{50}) \\approx 11.906\n```\n\n### Step 2: Compute the Estimated Cost in USD\n\nThe cost is calculated as:\n\n```math\n\\text{Cost (USD)} = N_{\\text{CPU}} \\times \\text{cost per CPU-hour} \\times \\text{runtime in hours}\n```\n\n- **Cost per CPU-hour**: $0.01\\,\\text{USD}$,\n- **Runtime**: $w_O = 20 \\times (2\\rho - 1)$ seconds, with $\\rho=50$:\n\n```math\nw_O = 20 \\times (2 \\cdot 50 - 1) = 1,980 \\, \\text{seconds}, \\quad \\text{runtime} = \\frac{1,980}{3600} \\approx 0.55 \\, \\text{hours}\n```\n\n```math\n\\text{Cost (USD)} = 8.06 \\times 10^{11} \\times 0.01 \\times 0.55 \\approx 4.43 \\times 10^9 \\approx 4.43 \\, \\text{billion}\n```\n\n### Step 3: Determine Feasibility\n\nThe feasibility thresholds are:\n\n- **Trivial**: < $10,000$ ($\\log_{10} < 4$),\n- **Feasible**: $10,000$ to $1,000,000$ ($\\log_{10} 4$ to 6),\n- **Possible**: $1,000,000$ to $1,000,000,000$ ($\\log_{10} 6$ to 9),\n- **Borderline Infeasible**: $1,000,000,000$ to $1,000,000,000,000$ ($\\log_{10} 9$ to 12),\n- **Infeasible**: > $1,000,000,000,000$ ($\\log_{10} > 12$).\n\nThis scenario is thus **Borderline Infeasible**, as the cost of $4.43 \\, \\text{billion}$ falls between $1,000,000,000$ and $1,000,000,000,000$.\n\n</details>\n<br> \n\n<div align=\"center\">\n<img src=\"./image/grinding_depth_scenarios_cost_with_feasibility_layers_gradient.png\" alt=\"Grinding Depth Scenarios with Feasibility Thresholds\"/>\n</div>\n\n✏️ **Note**: The code to generate this graph is available at ➡️ [this link](./graph/scenario_cost-graph.py).\n\nThe cost difference between the most expensive scenario (Owl Survey) and the cheapest (Ant Glance) is significant, with a consistent $\\Delta \\log_{10}(\\text{Cost (USD)}) \\sim 6.8$, meaning Owl Survey costs approximately $10^{6.8}$ times more than Ant Glance, reflecting the substantial impact of $T_{\\text{eval}}$ and $w_T$ on resource demands. \n\nThe table below shows the $\\rho$ values where each scenario transitions across feasibility categories:\n\n\n| **Feasibility Category**                  | **🔵 Ant Glance**   | **🟠 Ant Patrol**   | **🟢 Owl Stare**   | **🔴 Owl Survey**   |\n|--------------------------------------------|---------------------|---------------------|--------------------|--------------------|\n| **🟢 🌱 Trivial for Any Adversary**        | $0 \\to 53.6$        | $0 \\to 32.9$        | $0 \\to 31.6$       | $0 \\to 31.1$       |\n| **🟡 💰 Feasible with Standard Resources** | $53.6 \\to 60$     | $32.9 \\to 39.5$     | $31.6 \\to 38.3$    | $31.1 \\to 37.8$    |\n| **🟠 🏭 Large-Scale Infrastructure Required** | $60 \\to 69.7$  | $39.5 \\to 49.5$     | $38.2 \\to 48.2$    | $37.8 \\to 47.7$    |\n| **🔴 🚫 Borderline Infeasible**            | $69.7 \\to 79.4$     | $49.5 \\to 59.5$     | $48.2 \\to 58.2$    | $47.7 \\to 57.7$    |\n| **🔴 🚫 Infeasible**                      | $79.4 \\to 256$      | $59.5 \\to 256$      | $58.2 \\to 256$     | $57.7 \\to 256$     |\n\n\n## 4. References \n \n- [KRD017 - Ouroboros- A provably secure proof-of-stake blockchain protocol](https://eprint.iacr.org/2016/889.pdf)\n- [DGKR18 -  Ouroboros Praos/ An adaptively-secure, semi-synchronous proof-of-stake blockchain](https://eprint.iacr.org/2017/573.pdf)\n- [Practical Settlement Bounds For Longest Chain Consensus](https://eprint.iacr.org/2022/1571.pdf) \n- [The combinatorics of the longest-chain rule: Linear consistency for proof-of-stake blockchains](https://eprint.iacr.org/2017/241.pdf)\n- [Efficient Random Beacons with Adaptive Securityfor Ungrindable Blockchains](https://eprint.iacr.org/2021/1698.pdf)\n- [Forking the RANDAO: Manipulating Ethereum's Distributed Randomness Beacon](https://eprint.iacr.org/2025/037)\n- [Security of Proof-of-Stake Blockchains](https://search.worldcat.org/title/1336590866)\n\n- [AWS EC2 Pricing Page Detailed Instance Pricing](https://aws.amazon.com/ec2/pricing/)\n- [Azure Virtual Machines Pricing Calculator Detailed VM Costs](https://azure.microsoft.com/en-us/pricing/calculator/)\n- [Google Compute Engine Pricing Detailed Compute Pricing](https://cloud.google.com/compute/pricing)\n- [iRender Pricing Information Competitive Cloud Rates](https://www.irender.com/pricing)\n\n\n## 5. Copyright\n\nThis CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0).\nREAD"
  },
  {
    "path": "CPS-0021/CPD/graph/forking_probabilities.py",
    "content": "#!/usr/bin/python\n\nimport sys\nimport math\nimport scipy\nfrom decimal import Decimal\nfrom joblib import Parallel, delayed\nimport scipy.special\nimport argparse\nfrom tabulate import tabulate\n\n\n# Considered adversaral stakes in percentage\nstakes = [0.005, 0.01, 0.02, 0.05, 0.1, 0.2, 0.25, 0.3, 0.33, 0.4, 0.45, 0.49] \nnb_stakes = len(stakes)\n\n# Probability to have x out of w blocks, with stake s: \n# B_{w, s}(x) = (x out of w) * s^x * (1-s)^{w-x}\n# This function uses decimal to work with small numbers\ndef proba_attempts(w,x,s):\n  return Decimal(scipy.special.binom(w,x)) * Decimal(s)**x * Decimal(1-s)**(w-x)\n\n# Number of grinding attempts for an interval of size w blocks\n# and x blocks controlled by the adversary: \n# S(w, x) = Sum_{i >= w-x}^{x} (i out of x)\ndef number_attempts_adv(w, x):\n acc = Decimal(0)\n for i in range(w-x, x+1):\n  acc += Decimal(scipy.special.binom(x, i))\n return acc\n\n# Total number of grinding attempts for an interval of w blocks:\n# S(w) = Sum_{x = w/2}^w S(w,x)\ndef number_attempts(w):\n  acc = Decimal(0)\n  # For an adversary having between w/2 to w blocks\n  for x in range(math.ceil(w/2), w+1):\n    # Number of combinaisons possible\n    acc += number_attempts_adv(w,x)\n  return acc\n\n# Expected number of grinding attempts for an interval of size w blocks,\n# and x blocks controlled by the adversary with stake s:\ndef expectation(w,x,s):\n    return proba_attempts(w, x, s) * number_attempts_adv(w, x)\n\n# The expected number of grinding attempt for an interval of size d\n# and an adversary with s stake:\n# C(w, s) = Sum_{d=1}^w ( Sum_{x=d/2}^d B_{d,s}(x) * S(d,x) )\n# For Praos, s ~= 21600 * 4 / 10, but this number is too high for scipy\n# This function can still be used to show the convergence with increasingly high s however\ndef eg(s, precision=10, cores=2):\n p = Decimal(0)\n for w in range(1, precision):\n  results = Parallel(n_jobs=cores)(delayed(expectation)(w, x, s) for x in range(math.ceil(w/2),w+1))\n  for res in results:\n    p += res\n return (s, Decimal(1-s) * p)  \n\n# Computes and print the expectation of grinding attempts for all adversaries\ndef all_egs(precision=10, cores=1):\n results = Parallel(n_jobs=cores)(delayed(eg)(s, precision) for s in stakes)\n res = sorted(results, key=lambda x : x[0])\n # Printing tables (use tabulate's option tablefmt=\"plain\" to have no lines)\n headers = [\"stake (%)\"] + [\"{:.1f}%\".format(s*100) for s in stakes]\n table = [[\"E(g)\"] + [\"{0:.2E}\".format(r[1]) for r in res]]\n print(\"\\nTable of grinding attempts\")\n print(tabulate(table, headers, tablefmt='orgtbl'))\n\n\ndef proba_diff(diff, s, precision=10):\n ps = []\n for i in range(precision+1):\n  acc = Decimal(1)\n  for j in range(1,i+1):\n   acc = acc * Decimal((diff+2*i+1-j)/j) * Decimal(s) * Decimal(1-s)\n  for j in range(i+1,diff+i+1):\n   acc = acc * Decimal((diff+2*i+1-j)/j) * Decimal(s)\n  for (j, di) in enumerate(ps):\n   acc_d = di\n   for l in range(1, i-j+1):\n    acc_d = Decimal(acc_d) * Decimal((2*i-2*j+1-l)/l) * Decimal(s) * Decimal(1-s)\n   acc = acc - acc_d\n  ps.append(acc)\n return (s, sum(ps))\n\ndef tables(precision=10, cores=1):\n # Computing the tables of probabilities\n table = []\n pows = [1,2,4,8,16,32,64,128,256]\n for p in pows:\n  results = Parallel(n_jobs=cores)(delayed(proba_diff)(p, s, precision) for s in stakes)\n  row = sorted(results, key=lambda x: x[0])\n  table.append([r[1] for r in row])\n # Printing tables (use tabulate's option tablefmt=\"plain\" to have no lines)\n headers = [\"|Xa - Xh| vs stake\"] + [\"{:.1f}%\".format(s*100) for s in stakes]\n # Printing the tables of probabilities\n table_proba = [[pows[i]] + [\"{:.3E}\".format(el) for el in row] for (i,row) in enumerate(table)]\n print(\"\\nTable of probabilities\")\n print(tabulate(table_proba, headers, tablefmt='orgtbl'))\n # Printing the tables of frequencies (per year)\n table_year = [[pows[i]] + [\"{:.2E}\".format(5./(float(el)*365.0)) if float(el) !=0 else \"-\" for el in row] for (i,row) in enumerate(table)]\n print(\"\\nTable of frequencies (year)\")\n print(tabulate(table_year, headers, tablefmt='orgtbl'))\n\n\ndef parseArguments():\n    # Create argument parser\n    parser = argparse.ArgumentParser()\n\n    # Optional arguments\n    parser.add_argument(\"-c\", \"--cores\", help=\"number of threads\", type=int, default=1)\n    parser.add_argument(\"-p\", \"--precision\", help=\"interval to compute E(g) on\", type=int, default=32)\n\n    # Print version\n    parser.add_argument(\"--version\", action=\"version\", version='%(prog)s - Version 1.0')\n\n    # Parse arguments\n    args = parser.parse_args()\n\n    return args\n\nif __name__ == '__main__':\n  # Parse arguments\n  args = parseArguments()\n  precision = args.precision\n  cores = min(args.cores, nb_stakes)\n  print(\"Printing forking's figures with precision={}\".format(precision))\n  \n  # Run function\n  all_egs(precision, cores)\n  \n  # Run tables\n  tables(precision, cores)\n"
  },
  {
    "path": "CPS-0021/CPD/graph/mixing_probabilities.py",
    "content": "#!/usr/bin/python\n\nimport sys\nimport math\nimport time\nimport scipy\nfrom decimal import Decimal\nfrom joblib import Parallel, delayed\nimport scipy.special\nimport argparse\nfrom tabulate import tabulate\n\n# Considered adversarial stakes in percentage\nstakes = [0.005, 0.01, 0.02, 0.05, 0.1, 0.2, 0.25, 0.3, 0.33, 0.4, 0.45, 0.49] \nnb_stakes = len(stakes)\n\n# Probability to have x trailing blocks, with stake s: \n# This function uses decimal to work with small numbers\ndef proba_attempts(x,s):\n  return s, Decimal(s)**x * Decimal(1-s)\n\ndef eg(w,s):\n acc = Decimal(0)\n for x in range(w+1):\n  acc += Decimal(x) * proba_attempts(x,s)[1]\n return s, acc\n\n# Computes and print the expectation of grinding attempts for all adversaries\ndef all_egs(cores=1):\n results = Parallel(n_jobs=cores)(delayed(eg)(21600, s) for s in stakes)\n res = sorted(results, key=lambda x : x[0])\n # Printing tables (use tabulate's option tablefmt=\"plain\" to have no lines)\n headers = [\"stake (%)\"] + [\"{:.1f}%\".format(s*100) for s in stakes]\n table = [[\"E(g)\"] + [\"{0:.2E}\".format(r[1]) for r in res]]\n print(\"\\nTable of grinding attempts\")\n print(tabulate(table, headers, tablefmt='orgtbl'))\n\n\ndef tables(cores=1):\n table = []\n pows = [1,2,4,8,16,32,64,128,256]\n for p in pows:\n  results = Parallel(n_jobs=cores)(delayed(proba_attempts)(p, s) for s in stakes)\n  row = sorted(results, key=lambda x: x[0])\n  table.append([r[1] for r in row])\n # Printing tables (use tabulate's option tablefmt=\"plain\" to have no lines)\n headers = [\"N vs stake\"] + [\"{:.1f}%\".format(s*100) for s in stakes]\n # Printing the tables of probabilities\n table_proba = [[pows[i]] + [\"{:.3E}\".format(el) for el in row] for (i,row) in enumerate(table)]\n print(\"\\nTable of probabilities\")\n print(tabulate(table_proba, headers, tablefmt='orgtbl'))\n # Printing the tables of frequencies (per year)\n table_year = [[pows[i]] + [\"{:.2E}\".format(5./(float(el)*365.0)) if float(el) !=0 else \"-\" for el in row] for (i,row) in enumerate(table)]\n print(\"\\nTable of frequencies (year)\")\n print(tabulate(table_year, headers, tablefmt='orgtbl'))\n\ndef parseArguments():\n    # Create argument parser\n    parser = argparse.ArgumentParser()\n\n    # Optional arguments\n    parser.add_argument(\"-c\", \"--cores\", help=\"number of threads\", type=int, default=1)\n\n    # Print version\n    parser.add_argument(\"--version\", action=\"version\", version='%(prog)s - Version 1.0')\n\n    # Parse arguments\n    args = parser.parse_args()\n\n    return args\n\nif __name__ == '__main__':\n  # Parse arguments\n  args = parseArguments()\n  \n  # Optimize threads\n  cores = min(args.cores, nb_stakes)\n  print(\"Printing self-mixing's figures\")\n\n  # Run function\n  all_egs(cores)\n\n  # Run tables\n  tables(cores)"
  },
  {
    "path": "CPS-0021/CPD/graph/scenario_cost-graph.py",
    "content": "import numpy as np\nimport matplotlib.pyplot as plt\nfrom matplotlib.patches import Patch\n\n# Define the range for rho (Grinding Depth), starting at 1 to avoid underflow issues\nrho = np.linspace(1, 256, 1000)  # 1000 points for smooth curve, starts at 1, ends at 256\n\n# Define f and cost per CPU-hour\nf = 0.05\ncost_per_cpu_hour = 0.01  # $0.01 per CPU-hour\n\n# Compute w_O in seconds for each rho\nw_O = 20 * (2 * rho - 1)  # w_O = 20 * (2 * rho - 1)\nw_O_hours = w_O / 3600  # Convert to hours for cost calculation\n\n# Define N_CPU functions for Praos scenarios\ndef ant_glance_praos(rho):\n    return 5e-10 * 2**(rho - 2) \n\ndef ant_patrol_praos(rho):\n    return 5e-10 * 2**(rho - 1) + 2.16e-2 * 2**(rho - 1) / rho\n\ndef owl_stare_praos(rho):\n    return 5e-10 * 2**(rho - 2) + 5e-2 * 2**(rho - 1) / rho\n\ndef owl_survey_praos(rho):\n    return 5e-10 * 2**(rho - 2) + 7.16e-2 * 2**(rho - 1) / rho\n\n# Compute N_CPU for all Praos scenarios\nn_cpu_ant_glance_praos = ant_glance_praos(rho)\nn_cpu_ant_patrol_praos = ant_patrol_praos(rho)\nn_cpu_owl_stare_praos = owl_stare_praos(rho)\nn_cpu_owl_survey_praos = owl_survey_praos(rho)\n\n# Compute cost in USD for all Praos scenarios\ncost_ant_glance_praos = n_cpu_ant_glance_praos * cost_per_cpu_hour * w_O_hours\ncost_ant_patrol_praos = n_cpu_ant_patrol_praos * cost_per_cpu_hour * w_O_hours\ncost_owl_stare_praos = n_cpu_owl_stare_praos * cost_per_cpu_hour * w_O_hours\ncost_owl_survey_praos = n_cpu_owl_survey_praos * cost_per_cpu_hour * w_O_hours\n\n# Calculate log10(Cost) for all scenarios, adding a small epsilon to avoid log of zero\nepsilon = 1e-100  # Small positive value to prevent log(0)\nlog_cost_ant_glance_praos = np.log10(np.maximum(cost_ant_glance_praos, epsilon))\nlog_cost_ant_patrol_praos = np.log10(np.maximum(cost_ant_patrol_praos, epsilon))\nlog_cost_owl_stare_praos = np.log10(np.maximum(cost_owl_stare_praos, epsilon))\nlog_cost_owl_survey_praos = np.log10(np.maximum(cost_owl_survey_praos, epsilon))\n\n# Create the plot with improved aesthetics\nplt.figure(figsize=(12, 7))\n# Plot Praos scenarios with solid lines\nplt.plot(rho, log_cost_ant_glance_praos, label='Ant Glance Praos', color='blue', linewidth=2)\nplt.plot(rho, log_cost_ant_patrol_praos, label='Ant Patrol Praos', color='orange', linewidth=2)\nplt.plot(rho, log_cost_owl_stare_praos, label='Owl Stare Praos', color='green', linewidth=2)\nplt.plot(rho, log_cost_owl_survey_praos, label='Owl Survey Praos', color='red', linewidth=2)\n\n# Add feasibility threshold layers as horizontal spans based on log10(Cost USD)\nplt.axhspan(-10, 4, color='green', alpha=0.1, label='Trivial')         # Trivial (< $10,000)\nplt.axhspan(4, 6, color='yellow', alpha=0.1, label='Feasible')          # Feasible ($10,000 to $1M)\nplt.axhspan(6, 9, color='#FFA07A', alpha=0.1, label='Possible')         # Possible ($1M to $1B) - Light salmon\nplt.axhspan(9, 12, color='#FF6347', alpha=0.1, label='Borderline Infeasible')  # Borderline Infeasible ($1B to $1T) - Tomato\nplt.axhspan(12, 90, color='red', alpha=0.1, label='Infeasible')         # Infeasible (> $1T) - Red\n\n# Add labels and title with larger font\nplt.xlabel('$\\\\rho$ (Grinding Depth)', fontsize=14)\nplt.ylabel('$\\\\log_{10}(\\\\text{Cost (USD)})$', fontsize=14)\nplt.title('Cost of Grinding Attacks Across Praos Scenarios with Feasibility Thresholds', fontsize=16)\nplt.grid(True, linestyle='--', alpha=0.7)\n\n# Set axis limits to ensure full range is visible\nplt.xlim(0, 256)  # X-axis from 0 to 256\n# Compute y_max considering all Praos scenarios\nvalid_log_costs = np.concatenate([\n    log_cost_ant_glance_praos[np.isfinite(log_cost_ant_glance_praos)],\n    log_cost_ant_patrol_praos[np.isfinite(log_cost_ant_patrol_praos)],\n    log_cost_owl_stare_praos[np.isfinite(log_cost_owl_stare_praos)],\n    log_cost_owl_survey_praos[np.isfinite(log_cost_owl_survey_praos)]\n])\ny_max = np.max(valid_log_costs) + 5 if valid_log_costs.size > 0 else 90\nplt.ylim(-5, y_max)  # Y-axis starts at -5\n\n# Function to find crossing points and annotate\ndef annotate_crossings(log_costs, color, threshold, position='above'):\n    # Find indices where the curve crosses the threshold\n    indices = np.where((log_costs[:-1] < threshold) & (log_costs[1:] >= threshold))[0]\n    if len(indices) > 0:\n        idx = indices[0]\n        rho_val = rho[idx]\n        plt.scatter(rho_val, threshold, color=color, marker='o', s=50, zorder=5)\n        # Position above or below based on the curve\n        if position == 'below':\n            plt.annotate(f'{rho_val:.1f}',\n                         xy=(rho_val, threshold),\n                         xytext=(rho_val + 1.1, threshold - 0.4),\n                         fontsize=8, color=color)\n        elif position == 'green':\n            plt.annotate(f'{rho_val:.1f}',\n                         xy=(rho_val, threshold),\n                         xytext=(rho_val - 0.6, threshold - 0.9),\n                         fontsize=8, color=color)\n        else:\n            plt.annotate(f'{rho_val:.1f}',\n                         xy=(rho_val, threshold),\n                         xytext=(rho_val - 1, threshold + 0.5),\n                         fontsize=8, color=color)\n\n# Annotate crossings for Praos curves\nthresholds = [\n    (4, \"Trivial to Feasible\"),\n    (6, \"Feasible to Possible\"),\n    (9, \"Possible to Borderline\"),\n    (12, \"Borderline to Infeasible\")\n]\n\ncurves = [\n    (log_cost_ant_glance_praos, 'blue', 'above'),\n    (log_cost_ant_patrol_praos, 'orange', 'below'),\n    (log_cost_owl_stare_praos, 'green', 'green'),\n    (log_cost_owl_survey_praos, 'red', 'above')\n]\n\n# Annotate crossings\nfor threshold, threshold_name in thresholds:\n    for log_costs, color, position in curves:\n        annotate_crossings(log_costs, color, threshold, position)\n\n# Create a custom legend with Praos labels and feasibility thresholds\nlegend_elements = [\n    plt.Line2D([0], [0], color='blue', lw=2, label='Ant Glance Praos'),\n    plt.Line2D([0], [0], color='orange', lw=2, label='Ant Patrol Praos'),\n    plt.Line2D([0], [0], color='green', lw=2, label='Owl Stare Praos'),\n    plt.Line2D([0], [0], color='red', lw=2, label='Owl Survey Praos'),\n    Patch(facecolor='green', alpha=0.1, label='Trivial'),\n    Patch(facecolor='yellow', alpha=0.1, label='Feasible'),\n    Patch(facecolor='#FFA07A', alpha=0.1, label='Possible'),\n    Patch(facecolor='#FF6347', alpha=0.1, label='Borderline Infeasible'),\n    Patch(facecolor='red', alpha=0.1, label='Infeasible')\n]\nplt.legend(handles=legend_elements, fontsize=10, loc='lower right',\n           bbox_to_anchor=(1, 0), ncol=2, handletextpad=0.5, columnspacing=1.5)\n\n# Adjust layout to prevent overlap\nplt.subplots_adjust(left=0.1, right=0.95, top=0.9, bottom=0.2)\n\n# Save the plot\nplt.savefig('grinding_depth_scenarios_cost_praos_annotated.png', dpi=300, bbox_inches='tight')\nplt.show()"
  },
  {
    "path": "CPS-0021/CPD/graph/scenario_cpu_graph.py",
    "content": "import numpy as np\nimport matplotlib.pyplot as plt\n\n# Define the range for rho (Grinding Depth), starting at 0.1 to avoid division by zero\nrho = np.linspace(0.1, 256, 1000)  # 1000 points for smooth curve\n\n# Define N_CPU functions for each scenario based on the updated formulas\ndef ant_glance(rho):\n    return 5e-10 * 2**(rho - 2) \n\ndef ant_patrol(rho):\n    return 5e-10 * 2**(rho - 2) + 2.16e-2 * 2**(rho - 1) / rho\n\ndef owl_stare(rho):\n    return 5e-10 * 2**(rho - 2) + 5e-2 * 2**(rho - 1) / rho\n\ndef owl_survey(rho):\n    return 5e-10 * 2**(rho - 2) + 7.16e-2 * 2**(rho - 1) / rho\n\n# Calculate log10(N_CPU) for each scenario\nlog_ant_glance = np.log10(ant_glance(rho))\nlog_ant_patrol = np.log10(ant_patrol(rho))\nlog_owl_stare = np.log10(owl_stare(rho))\nlog_owl_survey = np.log10(owl_survey(rho))\n\n# Create the plot with improved aesthetics\nplt.figure(figsize=(12, 7))\nplt.plot(rho, log_ant_glance, label='Ant Glance', color='blue', linewidth=2)\nplt.plot(rho, log_ant_patrol, label='Ant Patrol', color='orange', linewidth=2)\nplt.plot(rho, log_owl_stare, label='Owl Stare', color='green', linewidth=2)\nplt.plot(rho, log_owl_survey, label='Owl Survey', color='red', linewidth=2)\n\n# Add labels and title with larger font\nplt.xlabel('$\\\\rho$ (Grinding Depth)', fontsize=14)\nplt.ylabel('$\\\\log_{10}(N_{\\\\text{CPU}})$', fontsize=14)\nplt.title('Behavior of $N_{\\\\text{CPU}}$ Across Scenarios', fontsize=16)\nplt.grid(True, linestyle='--', alpha=0.7)\nplt.legend(fontsize=12)\n\n# Add annotation for the delta at rho = 50 (where curves are more separated)\nrho_idx = np.argmin(np.abs(rho - 50))  # Index closest to rho = 50\ndelta_log_ncpu = log_owl_survey[rho_idx] - log_ant_glance[rho_idx]\nmid_y = log_owl_survey[rho_idx] - (delta_log_ncpu / 2) + 0.5  # Position slightly above mid-point\n\n# Draw a thinner double-headed arrow in purple with smaller arrowheads\nplt.annotate('', xy=(50, log_owl_survey[rho_idx]), xytext=(50, log_ant_glance[rho_idx]),\n             arrowprops=dict(arrowstyle='<->', color='purple', lw=1, shrinkA=0, shrinkB=0))\n\n# Add the delta label in purple, slightly offset to the right\nplt.text(53, mid_y-3.5, f'$\\\\Delta \\\\log_{{10}}(N_{{CPU}}) \\\\approx {delta_log_ncpu:.1f}$',\n         fontsize=12, color='purple', bbox=dict(facecolor='white', alpha=0.8, edgecolor='none'),\n         verticalalignment='center')\n\n# Adjust layout to prevent overlap\nplt.tight_layout()\n\n# Save the plot as an image with higher resolution\nplt.savefig('grinding_depth_scenarios_with_delta_updated.png', dpi=300)\nplt.show()"
  },
  {
    "path": "CPS-0021/CPD/graph/window0_graph.py",
    "content": "import matplotlib.pyplot as plt\nimport numpy as np\n\n# Parameters\nf = 1/20  # Active slot coefficient\n\n# Range of rho values (grinding depth)\nrho_values = np.arange(1, 257, 5)  # From 1 to 256, step size 5\n\n# Calculate w_O for worst-case and best-case scenarios (in seconds)\nw_O_worst = rho_values / f  # Worst case: rho / f\nw_O_best = (2 * rho_values - 1) / f  # Best case: (2 * rho - 1) / f\n\n# Convert to hours\nw_O_worst_hours = w_O_worst / 3600\nw_O_best_hours = w_O_best / 3600\n\n# Special value at rho = 256\nrho_special = 256\nw_O_worst_special = (rho_special / f) / 3600  # Worst case at rho = 256 (~1.42 hours)\nw_O_best_special = ((2 * rho_special - 1) / f) / 3600  # Best case at rho = 256 (~2.84 hours)\n\n# Create the plot\nplt.figure(figsize=(10, 6))\nplt.plot(w_O_worst_hours, rho_values, color='red', linestyle='-', linewidth=2, label=r'Worst Case: $w_O = \\frac{\\rho}{f}$')\nplt.plot(w_O_best_hours, rho_values, color='blue', linestyle='--', linewidth=2, label=r'Best Case: $w_O = \\frac{2\\rho - 1}{f}$')\n\n# Add vertical lines at rho = 256\nplt.axvline(x=w_O_worst_special, color='red', linestyle=':', linewidth=1.5, ymax=256/260)  # Scale to rho = 256\nplt.axvline(x=w_O_best_special, color='blue', linestyle=':', linewidth=1.5, ymax=256/260)\n\n# Add x-axis labels for special values, offset to the right\noffset = 0.01  # Small offset in hours to the right\nplt.text(w_O_worst_special + offset, -15, f'{w_O_worst_special:.2f} h', color='red', ha='left', va='top', fontsize=12)\nplt.text(w_O_best_special + offset, -15, f'{w_O_best_special:.2f} h', color='blue', ha='left', va='top', fontsize=12)\n\n# Customize the plot\nplt.xlabel(r'Grinding Opportunity Window ($w_O$, hours)', fontsize=12)\nplt.ylabel(r'Grinding Depth ($\\rho$)', fontsize=12)\nplt.legend(fontsize=10, loc='upper left')  # Add legend in upper left corner\nplt.grid(True, linestyle='--', alpha=0.7)\n\n# Set reasonable axis limits\nplt.xlim(0, max(w_O_best_hours) * 1.1)  # Add 10% headroom on x-axis\nplt.ylim(-30, 260)  # Extend y-axis bottom to show labels clearly\n\n# Show the plot\nplt.tight_layout()\nplt.show()\n\n# Optional: Save the plot\n# plt.savefig('w_O_graph_hours_lines_legend.png')"
  },
  {
    "path": "CPS-0021/README.md",
    "content": "---\nCPS: 21\nTitle: Ouroboros Randomness Manipulation\nCategory: Consensus\nStatus: Open\nAuthors:\n    - Nicolas Henin <nicolas.henin@iohk.io>\n    - Raphael Toledo <raphael.toledo@iohk.io>\nProposed Solutions: \n    - CIP-0161 | Ouroboros Phalanx - Breaking Grinding Incentives: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0161\nDiscussions:\n    - Original pull request: https://github.com/cardano-foundation/CIPs/pull/1009\nCreated: 2025-10-03\nLicense: Apache-2.0\n---\n\n## Abstract\n\nThe **Ouroboros protocol** ⚙️, underpinning Cardano’s consensus mechanism, relies on a modular design where the **Randomness Generation Sub-Protocol** is pivotal in addressing the *Coin-Flipping Problem*—the generation of **fair**, **unbiased**, and **unpredictable** randomness in a distributed system. \n\nThis CPS formally documents this challenge, aiming to coordinate community-driven efforts through **Cardano Improvement Proposals (CIPs)** 📝 to mitigate or resolve it within Ouroboros. Randomness is foundational to sub-protocols like **leader election**, where vulnerabilities could compromise Cardano’s **security** 🔒, **fairness** ⚖️, and **decentralization** 🌐. \n\nAs the consensus protocol is a core component of any blockchain, and the **Randomness Sub-Protocol** is central to Ouroboros, this problem represents a *core of the core* issue for Cardano, with profound impacts on its integrity.\n\nHowever, this issue is not exclusive to Cardano; it is a pervasive concern across **Proof-of-Stake (PoS)** blockchains, including Ethereum, Solana, Algorand, and Tezos, where randomness underpins validator selection and consensus integrity. \n\nThis CPS examines Ouroboros’ approach, and poses critical questions about **vulnerability**, **detection**, and **deterrence**. Rather than prescribing solutions, it invites the Cardano community to assess and address this shared challenge, fostering research and innovation to enhance Ouroboros’ resilience within the broader PoS landscape 🌍.\n\n## Problem\n\nThis **Cardano Problem Statement (CPS)** 📜 builds upon the foundational work of the [**Cardano Problem Definition (CPD): Ouroboros Randomness Generation Sub-Protocol – The Coin-Flipping Problem**](./CPD/README.md) 📑, which provides an in-depth technical analysis of the issue at hand. While the **CPD** retains the full depth of technical material—including detailed modeling, cost definitions, and adversarial analysis—the **CPS** is structured for formal submission within the **CIP process** ✍️, prioritizing accessibility and alignment with community-driven solution development. As such, the technical details are preserved in the **CPD** as an appendix, while this **CPS** offers a concise, high-level summary of the problem, connecting it to broader concerns within Cardano and the blockchain community.\n\n\n### Summary of Findings\n\nThis **[**CPD**](./CPD/README.md)** examines the *Randomness Generation Sub-Protocol* within the *Ouroboros Praos* ⚙️, highlighting its vulnerabilities and their implications for *Cardano’s* **security** 🔒. Key insights include:\n\n- **Randomness Vulnerability**: *Ouroboros Praos* employs **VRFs** for randomness generation, but this approach is susceptible to *grinding attacks*, where adversaries manipulate outcomes to influence **leader election**, threatening Cardano’s **fairness** ⚖️ and **integrity**.\n- **Attack Likelihood**: Attacks become significantly more feasible when an adversary controls **over 20% of the total stake** (approximately **4.36 billion ADA**, as of March 2025), while smaller stakes (e.g., **5%**) make such attempts highly unlikely over extended periods.\n- **Economic Barrier**: Gaining enough stake to execute an attack requires a **substantial investment** 💰—billions of USD for a **20% share**—posing a financial risk, as a successful attack could devalue the asset and undermine network trust.\n- **Computational Feasibility**: The feasibility of attacks varies widely based on the computational resources an adversary can deploy, becoming progressively more accessible as stake accumulates:\n  - Small-scale attacks, costing as little as ~**$56**, are easily achievable with minimal resources, such as a standard computer, making them a low-barrier threat that even individual actors could attempt.\n  - Large-scale attacks, costing up to ~**$3.1 billion**, require extensive computational infrastructure, such as large data centers with millions of CPUs, placing them in a range from feasible for well-funded entities (e.g., corporations or nation-states) to nearly impractical for most adversaries due to the immense resource demands.\n  - The intensity of these attacks scales with stake: the more stake an adversary holds, the greater their influence over **leader election**, amplifying their ability to manipulate randomness. In a simplistic view, this can be likened to manipulating a $256$-bits nonce—a value $\\rho$ ranging from $0$ to $256$— where higher stake progressively grants more control, potentially allowing full manipulation of the nonce at the upper limit.\n  - The wide cost disparity reflects how the complexity of the attack—such as the scope of the targeted time window and the depth of evaluation—drastically increases resource needs, acting as a natural deterrent for more ambitious manipulations.\n\nTo illustrate the **Computational Feasibility**, the graph below (sourced from the **CPD**, Section [**3. The Cost of Grinding: Adversarial Effort and Feasibility**](./CPD/README.md#3-the-cost-of-grinding-adversarial-effort-and-feasibility)) maps attack feasibility across four scenarios—**Ant Glance**, **Ant Patrol**, **Owl Stare**, and **Owl Survey**—based on the nonce value $\\rho$ (0 to 256 bits). Each scenario reflects different attack complexities, with feasibility shifting as computational and economic demands grow:\n\n<div align=\"center\">\n<img src=\"./CPD/image/grinding_depth_scenarios_cost_with_feasibility_layers_gradient.png\" alt=\"Grinding Depth Scenarios with Feasibility Thresholds\"/>\n</div>\n\nThe table below delineates the **$\\rho$ values** at which each scenario transitions across feasibility categories, illustrating the computational and economic thresholds:\n\n| **Feasibility Category**                  | **🔵 Ant Glance**   | **🟠 Ant Patrol**   | **🟢 Owl Stare**   | **🔴 Owl Survey**   |\n|--------------------------------------------|---------------------|---------------------|--------------------|--------------------|\n| **🟢 🌱 Trivial for Any Adversary**        | $0 \\to 53.6$        | $0 \\to 32.9$        | $0 \\to 31.6$       | $0 \\to 31.1$       |\n| **🟡 💰 Feasible with Standard Resources** | $53.6 \\to 60$     | $32.9 \\to 39.5$     | $31.6 \\to 38.3$    | $31.1 \\to 37.8$    |\n| **🟠 🏭 Large-Scale Infrastructure Required** | $60 \\to 69.7$  | $39.5 \\to 49.5$     | $38.2 \\to 48.2$    | $37.8 \\to 47.7$    |\n| **🔴 🚫 Borderline Infeasible**            | $69.7 \\to 79.4$     | $49.5 \\to 59.5$     | $48.2 \\to 58.2$    | $47.7 \\to 57.7$    |\n| **🔴 🚫 Infeasible**                      | $79.4 \\to 256$      | $59.5 \\to 256$      | $58.2 \\to 256$     | $57.7 \\to 256$     |\n\n\n**Context**: The scenarios represent increasing attack sophistication (e.g., *Ant Glance* is a quick, low-effort attack; *Owl Survey* is a comprehensive, resource-intensive one). As $\\rho$ increases, so does the difficulty, shifting feasibility from trivial (e.g., a lone actor with a laptop) to infeasible (e.g., requiring nation-state-level resources).\n\nThese findings underscore critical risks to Cardano’s consensus mechanism, urging the **Cardano community** 🌐 to address them through potential strategies like improved detection, stake pool diversity, or protocol enhancements. For detailed technical analysis, stakeholders are encouraged to consult the **CPD**.\n\n\n## Use Cases\n\nThe *Coin-Flipping Problem* 🎲 within the **Ouroboros protocol** ⚙️ represents a **core of the core issue** for Cardano. The consensus mechanism is a fundamental component of any blockchain, and the *Randomness Generation Sub-Protocol* is integral to Ouroboros’ operation. Consequently, the consequences of randomness manipulation are **diverse and far-reaching** 🌍, impacting Cardano’s **security** 🔒, **fairness** ⚖️, and **decentralization** 🌐 in numerous ways. Given this breadth, providing an exhaustive list of use cases is challenging. However, a significant impact is evident: randomness manipulation enables an adversary to **group the intervals** during which they are selected as a **slot leader**, concentrating their influence over block production.\n\nThis ability to cluster slot leadership **amplifies classical blockchain attacks** 💥, exacerbating their impact. For example:\n\n- In a **Private Forking Attack** 🍴, an adversary withholds blocks to create a secret fork, later revealing it to outpace the honest chain. Clustering slot leadership enhances their ability to extend this fork, increasing the attack’s success rate.\n- Similarly, this manipulation intensifies other attacks, including:\n  - **Selfish Mining** 💰: Withholding blocks to gain disproportionate rewards.\n  - **Double-Spending Attacks** 💸: Reversing transactions for financial gain.\n  - **Censorship Attacks** 🚫: Excluding specific transactions to suppress competition.\n\nAs detailed in the [**CPD**](./CPD/README.md#213-potential-outcomes-of-grinding-attacks), adversaries could also exploit randomness to enable additional attack vectors, such as:\n\n- **Economic Exploitation** : Prioritizing transactions for higher fees.\n- **Minority Stake Exploitation** 📊: Amplifying a small stake’s influence.\n- **Settlement Delays** ⏳: Undermining trust in confirmation times.\n\nThese scenarios **underscore the critical need** ❗ to address randomness manipulation to safeguard Cardano’s integrity.\n\n## Goals\n \nThe goal is to **mitigate or completely eliminate grinding attacks** on the protocol by introducing **targeted protocol enhancements** to address this issue. Two approaches are actively being explored to address the **Randomness Manipulation Problem**:  \n\n- **Complete Elimination of Grinding Attacks** – Ongoing research aims to make the protocol fully resistant to such attacks. One notable example is *[Efficient Random Beacons with Adaptive Security for Ungrindable Blockchains](https://eprint.iacr.org/2021/1698.pdf).*  \n- **Partial Mitigation by Increasing Attack Complexity** – While full protection may not yet be feasible, making such attacks **computationally and economically prohibitive** can significantly reduce their viability. This approach is the basis of **Ouroboros Phalanx** (Coming soon as a CIP)].   \n\nHowever, while **fully protecting the protocol from Randomness Manipulation attacks** may not yet be feasible, it is crucial to advance in the following areas:  \n\n- **Risk Quantification** : Assessing the **profitability and feasibility of attacks**, along with **refining risk assessment models**, will provide deeper insights into vulnerabilities and their potential impact on the protocol's security and stability.  \n\n- **Transparency on Manipulations** : **Enhancing detection mechanisms**, such as **self-mixing analysis** and **forking manipulation detection**, can help identify potential exploits and assess ongoing threats in real time.  \n\n- **Game Theory & Economic Disincentives** –   \n  **Promoting stake operator diversity** and **strengthening decentralization incentives** will reduce the economic viability of manipulation, fostering a more **resilient and distributed** stake pool ecosystem.  \n\nWe strongly encourage the community to actively engage in addressing this challenge by contributing research, proposing solutions, and participating in discussions. Collaborative efforts will be crucial in refining detection mechanisms, strengthening protocol resilience, and ensuring the long-term security and fairness of Ouroboros.\n\n\n\n## Open Questions\n\nThe *Coin-Flipping Problem* 🎲 within the **Ouroboros protocol** ⚙️ poses critical uncertainties that challenge Cardano’s **security** 🔒, **fairness** ⚖️, and **decentralization** 🌐. These open questions, rooted in the [**CPD**](./CPD/README.md) 📑 analysis, call for exploration by the **Cardano community** 🌍 to strengthen the protocol’s resilience:\n\n- **Is randomness manipulation currently occurring, and how detectable is it?** 🕵️‍♂️  \n  Are grinding attacks already subtly affecting Cardano undetected? What tools, metrics, or on-chain signals could reveal adversarial manipulation in real-time, given the protocol’s design?\n\n- **How will Peras influence grinding attack capabilities?** 🔄  \n  With Peras enhancing Ouroboros’ settlement times, does it increase, decrease, or shift the opportunities for adversaries to exploit randomness through grinding attacks?\n\n- **Are current economic deterrents effectively discouraging randomness manipulation?** 💰  \n  Does the high cost of acquiring significant stake (e.g., ~4.36 billion ADA for 20%) adequately dissuade adversaries, or do potential rewards (e.g., staking profits, governance power) offset this barrier? Can we do better ?\n\n- **How does preparing for the worst-case grinding attack scenario affect the security parameter $k$?** 🛡️  \n  If we adjust Ouroboros to handle extreme grinding attacks, what impact would this have on the **security parameter $k$**, which governs chain stability and finality ? What benefits could we gain by reducing $k$?\n\n- **Who benefits most from executing a grinding attack?** 🎯  \n  Which actors—malicious stakeholders, competing blockchains, or economic opportunists—stand to gain the most from manipulating randomness, and how might their motives shape attack strategies?\n\n- **Can grinding attacks be fully eliminated from Ouroboros?** 🚫  \n  Is it technically feasible to design a randomness mechanism that completely removes the possibility of grinding attacks, or are trade-offs (e.g., scalability, complexity) inevitable?\n\n- **Can we increase the cost of grinding attacks to deter adversaries?** 💸  \n  What protocol modifications—such as higher computational demands or stake penalties—could make grinding attacks prohibitively expensive, and how would they balance with Cardano’s usability?\n\n## Copyright\n\nThis CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0).\n\n\n"
  },
  {
    "path": "CPS-0022/README.md",
    "content": "---\nCPS: 22\nTitle: Lost Stake\nCategory: Ledger\nStatus: Open\nAuthors:\n    - Ryan Wiley <rian222@gmail.com>\nProposed Solutions: []\nDiscussions:\n    - Original pull request: https://github.com/cardano-foundation/CIPs/pull/1060\nCreated: 2025-07-22\nLicense: CC-BY-4.0\n---\n\n## Abstract\n\nIn everyday Cardano discussions the umbrella term “Sticky Stake” is used for any stake that stubbornly remains delegated, regardless of whether its owner is still around. This Cardano Problem Statement (CPS) zooms in on the most critical slice of that phenomenon that we dubbed “Lost Stake”: Ada that (a) remains delegated to a stake pool or dRep, yet (b) can never again be moved because the controlling private keys are irretrievably lost (e.g., seed-phrase loss, death of the sole key holder, catastrophic wallet failure).\n\nThis CPS formalises the Lost Stake problem and quantifies its systemic impact: dilution of the rewards pot available to active participants, distortion of pool-selection incentives, and ossification of governance power. Some amount of ADA may already be draining from the rewards pot into permanently unreachable wallets each epoch. Left unchecked, compounding Lost Stake will siphon a significant amount of ADA in rewards and an ever-growing share of voting weight into wallets that nobody controls, making future remediation far costlier and more contentious. \n\n\n## Problem\n\nLost Stake continues to earn and compound staking rewards and carries voting weight despite being permanently inaccessible.  Even though the funds are gone for good, the ledger continues to treat them as live stake. They keep:\n\n• earning a proportional share of every epoch’s rewards,  \n• compounding themselves through those rewards, and  \n• exerting voting weight whenever their chosen dRep participates.  \n\n“Lost delegation” may be a more technically correct phrase since it is the delegation certificate that survives, but we will use the more familiar term \"Lost Stake\" to stay consistent with community vocabulary around Sticky Stake.\n\n**Figure 1** (below) visualises these relationships with overlapping circles:\n\n<img src=\"fig1.jpg\" alt=\"Figure 1: Circles depict the Total Rewards Pot and its diminishing share with some rewards also flowing to Sticky Stake and Lost Stake addresses every epoch.\" width=\"50%\" />\n\n> **Figure 1:** Circles depict the Total Rewards Pot and its diminishing share with some rewards also flowing to Sticky Stake and Lost Stake addresses every epoch.\n\nCardano already distributes a significant amount of ADA every epoch in staking rewards to addresses that are permanently inaccessible. This occurs when ADA is lost, such as when a holder loses their seed phrase or passes away without sharing their keys, rendering the funds permanently unreachable. In most other cryptocurrencies, lost coins simply exit circulation. For example, it is estimated that around 20% of all Bitcoin supply is lost forever [[investopedia.com](https://www.investopedia.com/news/20-all-btc-lost-unrecoverable-study-shows/)], with more granular analyses by Ledger Academy and Chainalysis both converging on roughly 4% of all Bitcoin being lost each year [[ledger.com](https://www.ledger.com/academy/topics/economics-and-regulation/how-many-bitcoin-are-lost-ledger); [chainalysis.com](https://www.chainalysis.com/blog/money-supply/)].\n\nCardano’s design, however, allows lost ADA to remain economically “active” if it was delegated prior to loss. Once delegated, a stake key remains registered and tied to a stake pool (for block production) and potentially to a dRep (for voting) until it is actively changed or deregistered. A user who loses access cannot undelegate or spend those funds, meaning the ADA continues to stay delegated indefinitely.\n\nThe lost-stake problem is the accumulation of this unreachable-yet-delegated ADA within the Cardano ecosystem. Such lost stake still contributes to stake-pool sizes and earns staking rewards every epoch, even though the rewards accumulate in an address that nobody controls. For as long as the chosen stake pool produces staking rewards, the lost ADA compounds. Rewards paid to these addresses increase their delegated stake, which in turn earns more rewards, and so on. Similarly, if the lost ADA was delegated to a governance representative (dRep) for Voltaire-era on-chain voting, that voting power remains with the dRep permanently (or until the dRep retires or is marked inactive). The original owner is no longer present to adjust their delegation in response to changing conditions. This creates a class of delegation that cannot be reallocated or corrected.\n\n### Detrimental effects\n\nLost stake and lost ADA have several detrimental effects on the Cardano network:\n\n#### Perpetual reward dilution\nEach epoch, a portion of the total ADA rewards is distributed to all staked ADA, whether active or lost. Rewards sent to addresses with lost ADA are effectively removed from circulation forever, resulting in active delegators and stake-pool operators (SPOs) receiving a smaller share than they would if that lost stake did not exist. In effect, active participants are subsidizing the lost stake. Over time, the compounding of these rewards to lost ADA can significantly dilute the reward pool available to real users and operators.\n\n#### Reward increases worsen the problem\nAny attempt to increase staking rewards—such as raising the reward rate, boosting incentives for SPOs or delegators, providing additional yield from Partner Chains, or otherwise enlarging the total rewards pot—will also proportionally increase the amount of rewards paid to lost ADA. As a result, well-intentioned efforts to improve returns for active participants can actually make the lost stake problem worse, since a fixed percentage of all new rewards will continue to be siphoned off to permanently unreachable addresses.\n\n#### Skewed stake-pool incentives\nLost ADA that remains delegated contributes to a stake pool’s apparent stake and saturation level. Pools with large amounts of lost stake may continue to produce blocks and earn rewards from that stake without any risk of it ever being withdrawn. This can distort competitive incentives. For example, a pool might appear reliably saturated or have high loyalty even if some of its delegation is simply abandoned funds. In extreme cases, if a pool amasses substantial lost ADA, it could remain highly ranked or saturated based on stake that no active delegator can respond to (e.g., they cannot move that stake if the pool underperforms). This reduces the effectiveness of normal market dynamics in the staking ecosystem and can harm network security.\n\n#### Governance participation anomalies\nIn Cardano’s governance model (e.g., under [CIP-1694](https://cips.cardano.org/cips/cip1694/)), voting power is tied to stake. Lost ADA that was delegated to a dRep continues to bolster that dRep’s voting power indefinitely. This means decisions may be swayed by stake with no active owner, potentially undermining the representativeness of votes. The governance framework acknowledges this risk—for instance, CIP-1694 introduces an inactivity mechanism so that dReps who stop voting are marked inactive. However, if lost ADA remains delegated to an **ACTIVE** dRep, it will keep influencing outcomes with no way for the original holder (or anyone) to ever retract that delegation.\n\n#### Long-term economic inefficiencies\nAs the proportion of lost stake grows, Cardano’s monetary and incentive system will face sustainability issues. Eventually, block rewards will rely more on transaction fees (as treasury reserves deplete). If a significant fraction of stake is lost ADA, then a matching fraction of all transaction fees (and any remaining rewards) gets continually paid to unreachable addresses. This reduces fee efficiency and causes the network to effectively waste a chunk of fees on lost stakeholders, making less available to reward the operators and holders who actually secure and use the system. In a scenario where, say, 30% of all stake is lost stake decades from now, that 30% of fees and rewards is perpetually locked up, potentially requiring higher fees or other adjustments to adequately incentivize active validators.\n\nIt is important to formally document the lost-stake problem now, even before it becomes visibly acute, because the Cardano community needs a clear understanding of the issue’s scope and implications.\n\n### Why the Protocol Behaves This Way\n\nCardano’s ledger does not distinguish between active and inactive stake. All ADA is treated equally under the consensus rules. This design choice (common to many PoS systems) avoids complexity and respects the principle that tokens are the bearer’s property indefinitely. However, the unintended consequence is that there is no built-in mechanism to recognize or mitigate lost keys. From a protocol perspective, lost ADA is indistinguishable from a perfectly content long-term holder. Any potential solution must therefore carefully balance improving incentives with respecting property rights and avoiding false positives (e.g., not seizing or disabling legitimately held ADA).\n\n### Current Mitigations and Their Limits\n\nAs noted earlier, governance proposals like [CIP-1694](https://cips.cardano.org/cips/cip1694/) include measures to limit the impact of inactive delegated stake on voting outcomes. Additionally because DRep delegation is a new feature, all previously lost stake is unable to engage. These measures (such as marking inactive dReps) help prevent governance paralysis, but do not address the underlying issue of lost ADA still existing and, in some cases, continuing to accumulate rewards. However, when a stake pool with lost stake retires or shuts down, the lost ADA delegated to it is actually much less of a problem. That ADA effectively becomes undelegated and removed from circulation, meaning it no longer receives staking rewards or participates in governance. While the system currently has no direct way to reclaim or reassign lost ADA, the most persistent issues arise when lost stake remains delegated to active pools or dReps. Indirect mitigations only address symptoms (like governance quorum) rather than the root cause.\n\n### Why Ignoring the Problem Is Risky\n\nSome might argue that lost coins simply increase the value of the remaining ones (through scarcity) or that the effect is negligible for now. However the effect is not static. It grows over time and can reach levels that materially impact network operation. Unlike in Bitcoin (where lost coins arguably don’t harm network security or functionality [[investopedia.com](https://www.investopedia.com/tech/how-much-bitcoin-has-been-lost/)]), in Cardano most lost coins still participate in consensus. Therefore, ignoring lost stake and lost ADA means accepting a slow-growing skew in the system that could ultimately undermine user trust and network performance. Early recognition allows for carefully researched, minimally disruptive solutions before the problem becomes too large and contentious to fix.\n\n\n## Use Cases\n\nThe motivation for addressing lost stake and lost ADA is grounded in preserving fairness, efficiency, and the long-term health of Cardano’s proof-of-stake and governance mechanisms. At present, the problem may seem minor or largely theoretical, as lost ADA is not immediately visible on a small scale. But the impact compounds over time, and proactive understanding is crucial.\n\nEven a modest annual loss rate combined with ongoing rewards can, in theory, lead to exponential increases in the amount of ADA effectively trapped as lost stake. Over decades, lost ADA (plus the rewards it continually accrues) could constitute an ever-growing share of the total circulating supply.  As the proportion of rewards and transaction fees paid to lost ADA grows, the situation would become increasingly unacceptable to active users. At some point, most users would likely abandon the ecosystem rather than continue subsidizing unreachable addresses, making such runaway growth of lost stake unsustainable. Without a mechansism to prevent continous compounding of lost stake it is expected that reward dilution will become more severe, stake pools and governance will become heavily influenced by non-recoverable funds, and the active Cardano community would be supporting an increasing “dead weight” in the ecosystem until a breaking point is reached.\n\n\n## Goals\n\n- **Reward Fairness:** Cardano’s reward mechanism is zero-sum—if a portion goes to inaccessible wallets, everyone else simply gets less. Active delegators and SPOs should not have their rewards continuously diminished by wallets that no one can ever use. Over long periods, this will erode the attractiveness of staking for newcomers (who would see lower returns because part of the yield is effectively burned by lost stake and lost ADA).\n\n- **Governance Legitimacy:** For on-chain governance to be legitimate and effective, voting power should reflect real, engaged stakeholders. If a growing percentage of voting power is tied up in lost ADA (delegated to dReps or otherwise), it calls into question how representative the outcomes are. In the worst case, crucial governance actions might face quorum issues or skewed results due to a bloc of inactive stake that cannot be mobilized or removed. The community will become disenfranchised if “votes” are attributed to lost ADA swing decisions.\n\n- **Decentralization and Dynamism:** A healthy PoS ecosystem relies on the ability of stakeholders to move, re-delegate, or withdraw their stake in response to performance and incentives. Lost stake undermines this dynamism. It introduces static pools of stake that remain in place regardless of performance, potentially propping up some pools or dReps indefinitely. This will slow down the natural reallocation of stake that helps decentralization (e.g., shifting away from an underperforming or oversaturated pool) because some portion of stake simply cannot move. In extreme scenarios, network adaptability and resilience will likely suffer.\n\n- **Economic Sustainability:** In the long term, as block-reward inflation tapers off, Cardano’s security will hinge on transaction fees and community participation. If a significant chunk of ADA is effectively out of economic circulation (yet still “consuming” rewards/fees), it means the active economy has to carry that burden. The security budget (total incentives for validators) would be partially drained to non-participants. This inefficiency will necessitate higher fees or protocol changes to compensate, which is undesirable for growth. In short, allowing lost stake and lost ADA to grow unchecked may undermine the sustainability of the network’s incentive model.\n\n\n## Open Questions\n- How can the protocol reliably identify truly lost credentials?\n- Could an inactivity period (epochs/years) be acceptable before stake is considered “lost”?\n- Which economic / social mechanisms can prevent reward dilution without violating property rights?\n- Would the introduction of some solution to lost stake violate some of prior promises from the protocol?\n\n## References\n\n- **Cardano Improvement Proposal 1694 (CIP-1694):** On-Chain Decentralized Governance\n  [cips.cardano.org](https://cips.cardano.org/cips/cip1694/)\n\n- **Ledger Academy – “How Many Bitcoin Are Lost?”** \n  [ledger.com](https://www.ledger.com/academy/topics/economics-and-regulation/how-many-bitcoin-are-lost-ledger)\n\n- **Chainalysis – “Money Supply: What Does It Mean for Crypto?”** \n  [chainalysis.com](https://www.chainalysis.com/blog/money-supply/)\n\n- **Wall Street Journal Analysis of Lost Bitcoin:** \n  [[investopedia.com](https://www.investopedia.com/tech/how-much-bitcoin-has-been-lost/)]\n\n## Acknowledgements\n\n<details>\n  <summary><strong>Community SPO Incentives Working Group</strong></summary>\n\nThis CPS could not have been created without the support, assistance, and input of all participants in the community-led SPO Incentives Working Group.\n\n * Stef M [RABIT]\n * Rich Manderino [ECP] \n * Wayne Cataldo [OTG]\n * Homer [AAA]\n * Chad [BBHMM]\n * Mark H [UPSTR]\n * Carlos Lopez de Lara [Input|Output]\n * Pedro Lucas\n * Seomon\n * OYSTR Pool\n\n</details>\n\n## Copyright\n\nThis CPS is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).\n"
  },
  {
    "path": "LICENSE",
    "content": "Attribution 4.0 International\n\n=======================================================================\n\nCreative Commons Corporation (\"Creative Commons\") is not a law firm and\ndoes not provide legal services or legal advice. Distribution of\nCreative Commons public licenses does not create a lawyer-client or\nother relationship. Creative Commons makes its licenses and related\ninformation available on an \"as-is\" basis. Creative Commons gives no\nwarranties regarding its licenses, any material licensed under their\nterms and conditions, or any related information. Creative Commons\ndisclaims all liability for damages resulting from their use to the\nfullest extent possible.\n\nUsing Creative Commons Public Licenses\n\nCreative Commons public licenses provide a standard set of terms and\nconditions that creators and other rights holders may use to share\noriginal works of authorship and other material subject to copyright\nand certain other rights specified in the public license below. The\nfollowing considerations are for informational purposes only, are not\nexhaustive, and do not form part of our licenses.\n\n     Considerations for licensors: Our public licenses are\n     intended for use by those authorized to give the public\n     permission to use material in ways otherwise restricted by\n     copyright and certain other rights. Our licenses are\n     irrevocable. Licensors should read and understand the terms\n     and conditions of the license they choose before applying it.\n     Licensors should also secure all rights necessary before\n     applying our licenses so that the public can reuse the\n     material as expected. Licensors should clearly mark any\n     material not subject to the license. This includes other CC-\n     licensed material, or material used under an exception or\n     limitation to copyright. More considerations for licensors:\n     wiki.creativecommons.org/Considerations_for_licensors\n\n     Considerations for the public: By using one of our public\n     licenses, a licensor grants the public permission to use the\n     licensed material under specified terms and conditions. If\n     the licensor's permission is not necessary for any reason--for\n     example, because of any applicable exception or limitation to\n     copyright--then that use is not regulated by the license. Our\n     licenses grant only permissions under copyright and certain\n     other rights that a licensor has authority to grant. Use of\n     the licensed material may still be restricted for other\n     reasons, including because others have copyright or other\n     rights in the material. A licensor may make special requests,\n     such as asking that all changes be marked or described.\n     Although not required by our licenses, you are encouraged to\n     respect those requests where reasonable. More considerations\n     for the public:\n     wiki.creativecommons.org/Considerations_for_licensees\n\n=======================================================================\n\nCreative Commons Attribution 4.0 International Public License\n\nBy exercising the Licensed Rights (defined below), You accept and agree\nto be bound by the terms and conditions of this Creative Commons\nAttribution 4.0 International Public License (\"Public License\"). To the\nextent this Public License may be interpreted as a contract, You are\ngranted the Licensed Rights in consideration of Your acceptance of\nthese terms and conditions, and the Licensor grants You such rights in\nconsideration of benefits the Licensor receives from making the\nLicensed Material available under these terms and conditions.\n\n\nSection 1 -- Definitions.\n\n  a. Adapted Material means material subject to Copyright and Similar\n     Rights that is derived from or based upon the Licensed Material\n     and in which the Licensed Material is translated, altered,\n     arranged, transformed, or otherwise modified in a manner requiring\n     permission under the Copyright and Similar Rights held by the\n     Licensor. For purposes of this Public License, where the Licensed\n     Material is a musical work, performance, or sound recording,\n     Adapted Material is always produced where the Licensed Material is\n     synched in timed relation with a moving image.\n\n  b. Adapter's License means the license You apply to Your Copyright\n     and Similar Rights in Your contributions to Adapted Material in\n     accordance with the terms and conditions of this Public License.\n\n  c. Copyright and Similar Rights means copyright and/or similar rights\n     closely related to copyright including, without limitation,\n     performance, broadcast, sound recording, and Sui Generis Database\n     Rights, without regard to how the rights are labeled or\n     categorized. For purposes of this Public License, the rights\n     specified in Section 2(b)(1)-(2) are not Copyright and Similar\n     Rights.\n\n  d. Effective Technological Measures means those measures that, in the\n     absence of proper authority, may not be circumvented under laws\n     fulfilling obligations under Article 11 of the WIPO Copyright\n     Treaty adopted on December 20, 1996, and/or similar international\n     agreements.\n\n  e. Exceptions and Limitations means fair use, fair dealing, and/or\n     any other exception or limitation to Copyright and Similar Rights\n     that applies to Your use of the Licensed Material.\n\n  f. Licensed Material means the artistic or literary work, database,\n     or other material to which the Licensor applied this Public\n     License.\n\n  g. Licensed Rights means the rights granted to You subject to the\n     terms and conditions of this Public License, which are limited to\n     all Copyright and Similar Rights that apply to Your use of the\n     Licensed Material and that the Licensor has authority to license.\n\n  h. Licensor means the individual(s) or entity(ies) granting rights\n     under this Public License.\n\n  i. Share means to provide material to the public by any means or\n     process that requires permission under the Licensed Rights, such\n     as reproduction, public display, public performance, distribution,\n     dissemination, communication, or importation, and to make material\n     available to the public including in ways that members of the\n     public may access the material from a place and at a time\n     individually chosen by them.\n\n  j. Sui Generis Database Rights means rights other than copyright\n     resulting from Directive 96/9/EC of the European Parliament and of\n     the Council of 11 March 1996 on the legal protection of databases,\n     as amended and/or succeeded, as well as other essentially\n     equivalent rights anywhere in the world.\n\n  k. You means the individual or entity exercising the Licensed Rights\n     under this Public License. Your has a corresponding meaning.\n\n\nSection 2 -- Scope.\n\n  a. License grant.\n\n       1. Subject to the terms and conditions of this Public License,\n          the Licensor hereby grants You a worldwide, royalty-free,\n          non-sublicensable, non-exclusive, irrevocable license to\n          exercise the Licensed Rights in the Licensed Material to:\n\n            a. reproduce and Share the Licensed Material, in whole or\n               in part; and\n\n            b. produce, reproduce, and Share Adapted Material.\n\n       2. Exceptions and Limitations. For the avoidance of doubt, where\n          Exceptions and Limitations apply to Your use, this Public\n          License does not apply, and You do not need to comply with\n          its terms and conditions.\n\n       3. Term. The term of this Public License is specified in Section\n          6(a).\n\n       4. Media and formats; technical modifications allowed. The\n          Licensor authorizes You to exercise the Licensed Rights in\n          all media and formats whether now known or hereafter created,\n          and to make technical modifications necessary to do so. The\n          Licensor waives and/or agrees not to assert any right or\n          authority to forbid You from making technical modifications\n          necessary to exercise the Licensed Rights, including\n          technical modifications necessary to circumvent Effective\n          Technological Measures. For purposes of this Public License,\n          simply making modifications authorized by this Section 2(a)\n          (4) never produces Adapted Material.\n\n       5. Downstream recipients.\n\n            a. Offer from the Licensor -- Licensed Material. Every\n               recipient of the Licensed Material automatically\n               receives an offer from the Licensor to exercise the\n               Licensed Rights under the terms and conditions of this\n               Public License.\n\n            b. No downstream restrictions. You may not offer or impose\n               any additional or different terms or conditions on, or\n               apply any Effective Technological Measures to, the\n               Licensed Material if doing so restricts exercise of the\n               Licensed Rights by any recipient of the Licensed\n               Material.\n\n       6. No endorsement. Nothing in this Public License constitutes or\n          may be construed as permission to assert or imply that You\n          are, or that Your use of the Licensed Material is, connected\n          with, or sponsored, endorsed, or granted official status by,\n          the Licensor or others designated to receive attribution as\n          provided in Section 3(a)(1)(A)(i).\n\n  b. Other rights.\n\n       1. Moral rights, such as the right of integrity, are not\n          licensed under this Public License, nor are publicity,\n          privacy, and/or other similar personality rights; however, to\n          the extent possible, the Licensor waives and/or agrees not to\n          assert any such rights held by the Licensor to the limited\n          extent necessary to allow You to exercise the Licensed\n          Rights, but not otherwise.\n\n       2. Patent and trademark rights are not licensed under this\n          Public License.\n\n       3. To the extent possible, the Licensor waives any right to\n          collect royalties from You for the exercise of the Licensed\n          Rights, whether directly or through a collecting society\n          under any voluntary or waivable statutory or compulsory\n          licensing scheme. In all other cases the Licensor expressly\n          reserves any right to collect such royalties.\n\n\nSection 3 -- License Conditions.\n\nYour exercise of the Licensed Rights is expressly made subject to the\nfollowing conditions.\n\n  a. Attribution.\n\n       1. If You Share the Licensed Material (including in modified\n          form), You must:\n\n            a. retain the following if it is supplied by the Licensor\n               with the Licensed Material:\n\n                 i. identification of the creator(s) of the Licensed\n                    Material and any others designated to receive\n                    attribution, in any reasonable manner requested by\n                    the Licensor (including by pseudonym if\n                    designated);\n\n                ii. a copyright notice;\n\n               iii. a notice that refers to this Public License;\n\n                iv. a notice that refers to the disclaimer of\n                    warranties;\n\n                 v. a URI or hyperlink to the Licensed Material to the\n                    extent reasonably practicable;\n\n            b. indicate if You modified the Licensed Material and\n               retain an indication of any previous modifications; and\n\n            c. indicate the Licensed Material is licensed under this\n               Public License, and include the text of, or the URI or\n               hyperlink to, this Public License.\n\n       2. You may satisfy the conditions in Section 3(a)(1) in any\n          reasonable manner based on the medium, means, and context in\n          which You Share the Licensed Material. For example, it may be\n          reasonable to satisfy the conditions by providing a URI or\n          hyperlink to a resource that includes the required\n          information.\n\n       3. If requested by the Licensor, You must remove any of the\n          information required by Section 3(a)(1)(A) to the extent\n          reasonably practicable.\n\n       4. If You Share Adapted Material You produce, the Adapter's\n          License You apply must not prevent recipients of the Adapted\n          Material from complying with this Public License.\n\n\nSection 4 -- Sui Generis Database Rights.\n\nWhere the Licensed Rights include Sui Generis Database Rights that\napply to Your use of the Licensed Material:\n\n  a. for the avoidance of doubt, Section 2(a)(1) grants You the right\n     to extract, reuse, reproduce, and Share all or a substantial\n     portion of the contents of the database;\n\n  b. if You include all or a substantial portion of the database\n     contents in a database in which You have Sui Generis Database\n     Rights, then the database in which You have Sui Generis Database\n     Rights (but not its individual contents) is Adapted Material; and\n\n  c. You must comply with the conditions in Section 3(a) if You Share\n     all or a substantial portion of the contents of the database.\n\nFor the avoidance of doubt, this Section 4 supplements and does not\nreplace Your obligations under this Public License where the Licensed\nRights include other Copyright and Similar Rights.\n\n\nSection 5 -- Disclaimer of Warranties and Limitation of Liability.\n\n  a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE\n     EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS\n     AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF\n     ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,\n     IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,\n     WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR\n     PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,\n     ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT\n     KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT\n     ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.\n\n  b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE\n     TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,\n     NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,\n     INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,\n     COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR\n     USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN\n     ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR\n     DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR\n     IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.\n\n  c. The disclaimer of warranties and limitation of liability provided\n     above shall be interpreted in a manner that, to the extent\n     possible, most closely approximates an absolute disclaimer and\n     waiver of all liability.\n\n\nSection 6 -- Term and Termination.\n\n  a. This Public License applies for the term of the Copyright and\n     Similar Rights licensed here. However, if You fail to comply with\n     this Public License, then Your rights under this Public License\n     terminate automatically.\n\n  b. Where Your right to use the Licensed Material has terminated under\n     Section 6(a), it reinstates:\n\n       1. automatically as of the date the violation is cured, provided\n          it is cured within 30 days of Your discovery of the\n          violation; or\n\n       2. upon express reinstatement by the Licensor.\n\n     For the avoidance of doubt, this Section 6(b) does not affect any\n     right the Licensor may have to seek remedies for Your violations\n     of this Public License.\n\n  c. For the avoidance of doubt, the Licensor may also offer the\n     Licensed Material under separate terms or conditions or stop\n     distributing the Licensed Material at any time; however, doing so\n     will not terminate this Public License.\n\n  d. Sections 1, 5, 6, 7, and 8 survive termination of this Public\n     License.\n\n\nSection 7 -- Other Terms and Conditions.\n\n  a. The Licensor shall not be bound by any additional or different\n     terms or conditions communicated by You unless expressly agreed.\n\n  b. Any arrangements, understandings, or agreements regarding the\n     Licensed Material not stated herein are separate from and\n     independent of the terms and conditions of this Public License.\n\n\nSection 8 -- Interpretation.\n\n  a. For the avoidance of doubt, this Public License does not, and\n     shall not be interpreted to, reduce, limit, restrict, or impose\n     conditions on any use of the Licensed Material that could lawfully\n     be made without permission under this Public License.\n\n  b. To the extent possible, if any provision of this Public License is\n     deemed unenforceable, it shall be automatically reformed to the\n     minimum extent necessary to make it enforceable. If the provision\n     cannot be reformed, it shall be severed from this Public License\n     without affecting the enforceability of the remaining terms and\n     conditions.\n\n  c. No term or condition of this Public License will be waived and no\n     failure to comply consented to unless expressly agreed to by the\n     Licensor.\n\n  d. Nothing in this Public License constitutes or may be interpreted\n     as a limitation upon, or waiver of, any privileges and immunities\n     that apply to the Licensor or You, including from the legal\n     processes of any jurisdiction or authority.\n\n\n=======================================================================\n\nCreative Commons is not a party to its public licenses.\nNotwithstanding, Creative Commons may elect to apply one of its public\nlicenses to material it publishes and in those instances will be\nconsidered the “Licensor.” The text of the Creative Commons public\nlicenses is dedicated to the public domain under the CC0 Public Domain\nDedication. Except for the limited purpose of indicating that material\nis shared under a Creative Commons public license or as otherwise\npermitted by the Creative Commons policies published at\ncreativecommons.org/policies, Creative Commons does not authorize the\nuse of the trademark \"Creative Commons\" or any other trademark or logo\nof Creative Commons without its prior written consent including,\nwithout limitation, in connection with any unauthorized modifications\nto any of its public licenses or any other arrangements,\nunderstandings, or agreements concerning use of licensed material. For\nthe avoidance of doubt, this paragraph does not form part of the public\nlicenses.\n\nCreative Commons may be contacted at creativecommons.org."
  },
  {
    "path": "README.md",
    "content": "## Cardano Improvement Proposals (CIPs)\n\nA [Cardano Improvement Proposal (CIP)](./CIP-0001) is a formalised design document for the Cardano community and the name of the process by which such documents are produced and listed. A CIP provides information or describes a change to the Cardano ecosystem, processes, or environment concisely and in sufficient technical detail. In this CIP, we explain what a CIP is; how the CIP process functions; the role of the CIP Editors; and how users should go about proposing, discussing and structuring a CIP.\n\nThe Cardano Foundation intends CIPs to be the primary mechanisms for proposing new features, collecting community input on an issue, and documenting design decisions that have gone into Cardano. Plus, because CIPs are text files in a versioned repository, their revision history is the historical record of significant changes affecting Cardano.\n\nFor more about the human factors of the CIP process, and to learn how to get involved, click the Wiki tab above (**[CIP Wiki](https://github.com/cardano-foundation/CIPs/wiki)**).\n\n> [!TIP]\n> For new CIPs, a reference template is available in [.github/CIP-TEMPLATE.md](./.github/CIP-TEMPLATE.md)\n\n## Cardano Problem Statements (CPS)\n\nA [Cardano Problem Statement (CPS)](./CIP-9999) is a formalised document for the Cardano ecosystem and the name of the process by which such documents are produced and listed. CPSs are meant to complement CIPs and live side-by-side in the CIP repository as first-class citizens.\n\n> [!TIP]\n> For new CPSs, a reference template is available in [.github/CPS-TEMPLATE.md](./.github/CPS-TEMPLATE.md)\n\n## Communication Channels\n\nExtend or discuss ‘ideas’ in the [Developer Forums](https://forum.cardano.org/c/developers/cips/122), Cardano’s Official [Developer Telegram Group](https://t.me/CardanoDevelopersOfficial) or in `#developers` in Cardano Ambassadors Slack.\n\nCIP editors facilitate discussions and progress submissions on GitHub, reviewing progress in bi-weekly meetings held [on Discord](https://discord.gg/J8sGdCuKhs) which are open to the public. The Discord server also has channels for developer working groups to discuss details and implementations of selected CIPs.\n\n> [!NOTE]\n> To facilitate browsing and information sharing for non-Github users, an auto-generated site is also provided at [cips.cardano.org](https://cips.cardano.org/).\n\n## Cardano Improvement Proposals (CIP)\n\n| #    | Title | Status |\n| ---- | --- | --- |\n| 0001 | [CIP Process](./CIP-0001/) | Active |\n| 0002 | [Coin Selection Algorithms for Cardano](./CIP-0002/) | Active |\n| 0003 | [Wallet key generation](./CIP-0003/) | Active |\n| 0004 | [Wallet Checksums](./CIP-0004/) | Proposed |\n| 0005 | [Common Bech32 Prefixes](./CIP-0005/) | Active |\n| 0006 | [Stake Pool Extended Metadata](./CIP-0006/) | Active |\n| 0007 | [Curve Pledge Benefit](./CIP-0007/) | Proposed |\n| 0008 | [Message Signing](./CIP-0008/) | Active |\n| 0009 | [Protocol Parameters (Shelley Era)](./CIP-0009/) | Active |\n| 0010 | [Transaction Metadata Label Registry](./CIP-0010/) | Active |\n| 0011 | [Staking key chain for HD wallets](./CIP-0011/) | Active |\n| 0012 | [On-chain stake pool operator to delegates communication](./CIP-0012/) | Proposed |\n| 0013 | [Cardano URI Scheme](./CIP-0013/) | Proposed |\n| 0014 | [User-Facing Asset Fingerprint](./CIP-0014/) | Active |\n| 0015 | [Catalyst Registration Transaction Metadata Format](./CIP-0015/) | Active |\n| 0016 | [Cryptographic Key Serialisation Formats](./CIP-0016/) | Active |\n| 0017 | [Cardano Delegation Portfolio](./CIP-0017/) | Inactive |\n| 0018 | [Multi-Stake-Keys Wallets](./CIP-0018/) | Proposed |\n| 0019 | [Cardano Addresses](./CIP-0019/) | Active |\n| 0020 | [Transaction message/comment metadata](./CIP-0020/) | Active |\n| 0021 | [Transaction requirements for interoperability with hardware wallets](./CIP-0021/) | Active |\n| 0022 | [Pool operator verification](./CIP-0022/) | Active |\n| 0023 | [Fair Min Fees](./CIP-0023/) | Proposed |\n| 0024 | [Non-Centralizing Rankings](./CIP-0024/) | Proposed |\n| 0025 | [Media Token Metadata Standard](./CIP-0025/) | Active |\n| 0026 | [Cardano Off-Chain Metadata](./CIP-0026/) | Active |\n| 0027 | [CNFT Community Royalties Standard](./CIP-0027/) | Active |\n| 0028 | [Protocol Parameters (Alonzo Era)](./CIP-0028/) | Active |\n| 0029 | [Phase-1 Monetary Scripts Serialization Formats](./CIP-0029/) | Active |\n| 0030 | [Cardano dApp-Wallet Web Bridge](./CIP-0030/) | Active |\n| 0031 | [Reference Inputs](./CIP-0031/) | Active |\n| 0032 | [Inline Datums](./CIP-0032/) | Active |\n| 0033 | [Reference Scripts](./CIP-0033/) | Active |\n| 0034 | [Chain ID Registry](./CIP-0034/) | Proposed |\n| 0035 | [Plutus Core Evolution](./CIP-0035) | Active |\n| 0036 | [Catalyst Registration Transaction Metadata Format](./CIP-0036) | Proposed |\n| 0037 | [Dynamic Saturation Based on Pledge](./CIP-0037) | Proposed |\n| 0040 | [Collateral Output](./CIP-0040) | Active |\n| 0042 | [New Plutus Builtin: serialiseBuiltinData](./CIP-0042) | Active |\n| 0045 | [Decentralized WebRTC dApp-Wallet Communication](./CIP-0045) | Active |\n| 0049 | [ECDSA and Schnorr signatures in Plutus Core](./CIP-0049) | Active |\n| 0050 | [Pledge Leverage-Based Staking Rewards](./CIP-0050) | Proposed |\n| 0052 | [Cardano Audit Best Practice Guidelines](./CIP-0052) | Proposed |\n| 0054 | [Cardano Smart NFTs](./CIP-0054) | Proposed |\n| 0055 | [Protocol Parameters (Babbage Era)](./CIP-0055) | Active |\n| 0057 | [Plutus Smart-Contract Blueprint](./CIP-0057) | Active |\n| 0058 | [Plutus Bitwise Primitives](./CIP-0058) | Inactive |\n| 0059 | [Terminology Surrounding Core Features](./CIP-0059) | Active |\n| 0060 | [Music Token Metadata](./CIP-0060) | Active |\n| 0067 | [Asset Name Label Registry](./CIP-0067) | Proposed |\n| 0068 | [Datum Metadata Standard](./CIP-0068) | Active |\n| 0069 | [Plutus Script Type Uniformization](./CIP-0069) | Active |\n| 0071 | [Non-Fungible Token (NFT) Proxy Voting Standard](./CIP-0071) | Proposed |\n| 0072 | [DApp Registration](./CIP-0072) | Proposed |\n| 0074 | [Set min-pool-cost to 0](./CIP-0074) | Proposed |\n| 0075 | [Fair Stake Pool Rewards](./CIP-0075) | Proposed |\n| 0080 | [Transaction Serialization Deprecation Cycle](./CIP-0080) | Active |\n| 0082 | [Improved Rewards Scheme Parameters](./CIP-0082) | Proposed |\n| 0083 | [Encrypted Transaction message/comment metadata (Addendum to CIP-0020)](./CIP-0083) | Active |\n| 0084 | [Cardano Ledger Evolution](./CIP-0084) | Active |\n| 0085 | [Sums-of-products in Plutus Core](./CIP-0085) | Active |\n| 0086 | [NFT Metadata Update Oracles](./CIP-0086) | Proposed |\n| 0088 | [Token Policy Registration](./CIP-0088) | Proposed |\n| 0089 | [Distributed DApps & Beacon Tokens](./CIP-0089) | Active |\n| 0091 | [Don't force Built-In functions](./CIP-0091) | Proposed |\n| 0093 | [Authenticated Web3 HTTP requests](./CIP-0093) | Proposed |\n| 0094 | [SPO On-chain Polls](./CIP-0094) | Active |\n| 0095 | [Web-Wallet Bridge - Conway ledger era](./CIP-0095) | Active |\n| 0099 | [Proof of Onboarding](./CIP-0099) | Active |\n| 0100 | [Governance Metadata](./CIP-0100) | Active |\n| 0101 | [Integration of keccak256 into Plutus](./CIP-0101) | Proposed |\n| 0102 | [Royalty Datum Metadata](./CIP-0102) | Proposed |\n| 0103 | [Web-Wallet Bridge - Bulk transaction signing](./CIP-0103) | Active |\n| 0104 | [Web-Wallet Bridge - Account public key](./CIP-0104) | Proposed |\n| 0105 | [Conway Era Key Chains for HD Wallets](./CIP-0105) | Active |\n| 0106 | [Web-Wallet Bridge - Multisig wallets](./CIP-0106) | Proposed |\n| 0107 | [URI Scheme - Block and transaction objects](./CIP-0107) | Proposed |\n| 0108 | [Governance Metadata - Governance Actions](./CIP-0108) | Proposed |\n| 0109 | [Modular Exponentiation Built-in for Plutus Core](./CIP-0109) | Proposed |\n| 0110 | [Plutus v1 compatible script references](./CIP-0110) | Active |\n| 0112 | [Observe script type](./CIP-0112) | Proposed |\n| 0114 | [CBOR Tags Registry](./CIP-0114) | Proposed |\n| 0115 | [CBOR tag definition - ED25519-BIP32 Keys](./CIP-0115) | Proposed |\n| 0116 | [Universal JSON Encoding for Domain Types](./CIP-0116) | Proposed |\n| 0117 | [Explicit script return values](./CIP-0117) | Active |\n| 0118 | [Nested Transactions](./CIP-0118) | Proposed |\n| 0119 | [Governance Metadata - DReps](./CIP-0119) | Proposed |\n| 0120 | [Constitution specification](./CIP-0120) | Proposed |\n| 0121 | [Integer-ByteString conversions](./CIP-0121) | Active\n| 0122 | [Logical operations over BuiltinByteString](./CIP-0122) | Active |\n| 0123 | [Bitwise operations over BuiltinByteString](./CIP-0123) | Active |\n| 0124 | [Extend token metadata for translations](./CIP-0124) | Proposed |\n| 0127 | [Integration of ripemd_160 into Plutus](./CIP-0127) | Active |\n| 0128 | [Preserving Order of Transaction Inputs](./CIP-0128) | Proposed |\n| 0129 | [Governance Identifiers](./CIP-0129) | Proposed |\n| 0132 | [New Plutus Builtin DropList](./CIP-0132) | Proposed |\n| 0133 | [Plutus support for Multi-Scalar Multiplication over BLS12-381](./CIP-0133) | Proposed |\n| 0134 | [Cardano URIs - Address Representation](./CIP-0134) | Proposed |\n| 0135 | [Disaster Recovery Plan for Cardano networks](./CIP-0135) | Active |\n| 0136 | [Governance metadata - Constitutional Committee votes](./CIP-0136) | Proposed |\n| 0137 | [Decentralized Message Queue](./CIP-0137) | Proposed |\n| 0138 | [Plutus Core Builtin Type - Array](./CIP-0138) | Proposed |\n| 0139 | [Universal Query Layer](./CIP-0139) | Proposed |\n| 0140 | [Ouroboros Peras - Faster Settlement](./CIP-0140) | Proposed |\n| 0141 | [Web-Wallet Bridge - Plutus wallets](./CIP-0141) | Proposed |\n| 0142 | [Web-Wallet Bridge - Network Determination](./CIP-0142) | Proposed |\n| 0143 | [Interoperable Programmable Tokens](./CIP-0143) | Inactive |\n| 0146 | [Multi-signature wallet registration and discovery](./CIP-0146) | Proposed |\n| 0149 | [Optional DRep Compensation](./CIP-0149) | Proposed |\n| 0150 | [Block Data Compression](./CIP-0150) | Proposed |\n| 0151 | [On-Chain Registration - Stake Pools](./CIP-0151) | Proposed |\n| 0152 | [Modules in UPLC](./CIP-0152) | Proposed |\n| 0153 | [Plutus Core Builtin Type - MaryEraValue](./CIP-0153) | Proposed |\n| 0155 | [SRV Registry](./CIP-0155) | Proposed |\n| 0156 | [Plutus Core Builtin Function - multiIndexArray](./CIP-0156) | Proposed |\n| 0158 | [Cardano URIs - Browse Application](./CIP-0158) | Proposed |\n| 0159 | [Account Address Enhancement](./CIP-0159) | Proposed |\n| 0160 | [Receiving Script Purpose and Addresses](./CIP-0160) | Proposed |\n| 0161 | [Ouroboros Phalanx - Breaking Grinding Incentives](./CIP-0161) | Proposed |\n| 0162 | [URI Scheme - DRep Links](./CIP-0161) | Proposed |\n| 0163 | [Time-Bound Delegation with Dynamic Rewards](./CIP-0163) | Proposed |\n| 0164 | [Ouroboros Linear Leios - Greater transaction throughput](./CIP-0164) | Proposed |\n| 0165 | [Canonical Ledger State](./CIP-0165) | Proposed |\n| 0167 | [Remove isValid from transactions](./CIP-0167) | Proposed |\n| 0170 | [KERI-backed metadata attestations](./CIP-0170) | Proposed |\n| 0171 | [On-chain Smart Contract Bytecode Verification](./CIP-0171) | Proposed |\n| 0176 | [Non-segregated Block Body Serialization](./CIP-0176) | Proposed |\n| 0381 | [Plutus Support for Pairings Over BLS12-381](./CIP-0381) | Active |\n| 1694 | [A First Step Towards On-Chain Decentralized Governance](./CIP-1694) | Active |\n| 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](./CIP-1852/) | Active |\n| 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](./CIP-1853/) | Proposed |\n| 1854 | [Multi-signatures HD Wallets](./CIP-1854/) | Active |\n| 1855 | [Forging policy keys for HD Wallets](./CIP-1855/) | Proposed |\n| 9999 | [Cardano Problem Statements](./CIP-9999/) | Active |\n\n<p align=\"right\"><i>Last updated on 2026-03-31</i></p>\n\n> [!NOTE]\n> For more details about CIP statuses, see [CIP-0001 > Statuses](./CIP-0001/README.md#statuses).\n\n### Proposals Under Review (CIP)\n\nThe following link lists \"candidate\" CIPs still under discussion with the community; these are assigned numbers to avoid later clashes and to facilitate community discussion (see further below for stalled proposals):\n\n**[CIP pull requests under active review](https://github.com/cardano-foundation/CIPs/pulls?q=is%3Apr+is%3Aopen+%2F%5ECIP-%2F+in%3Atitle+label%3A%22State%3A+Confirmed%22%2C%22State%3A+Last+Check%22+draft%3Afalse+-label%3AUpdate%2CCorrection%2CTranslation%2C%22Bi-Weekly+Notes+%2F+Editorial+Housekeeping%22%2C%22CIP-0010%3A+new+registry+entry%22%2C%22CIP-0067%3A+new+label%22%2C%22CIP-0088%3A+new+extension%22+sort%3Aupdated-desc)** (most recently discussed first)\n\n## Cardano Problem Statements (CPS)\n\n| #    | Title | Status |\n| ---- | --- | --- |\n| 0003 | [Smart tokens](./CPS-0003) | Open |\n| 0005 | [Plutus Script Usability](./CPS-0005) | Open |\n| 0007 | [Voltaire era Governance](./CPS-0007) | Open |\n| 0008 | [Domain Name Resolution](./CPS-0008) | Open |) |\n| 0009 | [Coin Selection Including Native Tokens](./CPS-0009) | Open |\n| 0010 | [Wallet Connectors](./CPS-0010) | Open |\n| 0011 | [Universal JSON Encoding for Domain Types](./CPS-0011) | Open |\n| 0012 | [Query Layer Standardization](./CPS-0012) | Open |\n| 0013 | [Better builtin data structures in Plutus](./CPS-0013) | Open |\n| 0014 | [Register of CBOR Tags](./CPS-0014) | Open |\n| 0016 | [Cardano URIs](./CPS-0016) | Open |\n| 0017 | [Settlement Speed](./CPS-0017) | Open |\n| 0018 | [Greater Transaction Throughput](./CPS-0018) | Open |\n| 0020 | [Governance Stakeholder Incentivization](./CPS-0020) | Open |\n| 0021 | [Ouroboros Randomness Manipulation](./CPS-0021) | Open |\n| 0022 | [Lost Stake](./CPS-0022) | Open |\n\n<p align=\"right\"><i>Last updated on 2025-10-15</i></p>\n\n> [!NOTE]\n> For more details about CPS statuses, see [CIP-9999 > Statuses](./CIP-9999/README.md#statuses).\n\n### Proposals Under Review (CPS)\n\nThe following link lists \"candidate\" CPSs still under discussion with the community; these are assigned numbers to avoid later clashes and to facilitate community discussion (see further below for stalled proposals):\n\n**[CPS pull requests under active review](https://github.com/cardano-foundation/CIPs/pulls?q=is%3Apr+is%3Aopen+%2F%5ECPS-%2F+in%3Atitle+label%3A%22State%3A+Confirmed%22%2C%22State%3A+Last+Check%22+draft%3Afalse+-label%3AUpdate%2CCorrection%2CTranslation%2C%22Bi-Weekly+Notes+%2F+Editorial+Housekeeping%22%2C%22CIP-0010%3A+new+registry+entry%22%2C%22CIP-0067%3A+new+label%22%2C%22CIP-0088%3A+new+extension%22+sort%3Aupdated-desc)** (most recently discussed first)\n\n## Updates Under Consideration\n\nThe following link shows updates to existing CIPs and CPSs that have entered the review process:\n\n**[CIP and CPS updates under consideration](https://github.com/cardano-foundation/CIPs/pulls?q=is%3Apr+is%3Aopen+label%3AUpdate+sort%3Aupdated-desc)** (most recently discussed first)\n\n## Stalled / Waiting For Authors\n\nThe following links list proposals deemed ready for review but requiring further update\nfrom the original author(s) or other confirmation of proposal elgibility (if considered deprecated):\n\n[**Stalled CIPs and CPSs**](https://github.com/cardano-foundation/CIPs/pulls?q=is%3Apr+is%3Aopen+draft%3Afalse+in%3Atitle+label%3A%22State%3A+Waiting+for+Author%22%2C%22State%3A+Likely+Abandoned%22%2C%22State%3A+Likely+Deprecated%22+-label%3AUpdate%2CCorrection%2CTranslation%2C%22Bi-Weekly+Notes+%2F+Editorial+Housekeeping%22%2C%22CIP-0010%3A+new+registry+entry%22%2C%22CIP-0067%3A+new+label%22%2C%22CIP-0088%3A+new+extension%22+sort%3Aupdated-asc) (all lists least recently discussed first) - consisting of:\n* [proposals Waiting for Author](https://github.com/cardano-foundation/CIPs/pulls?q=is%3Apr+is%3Aopen+draft%3Afalse+in%3Atitle+label%3A%22State%3A+Waiting+for+Author%22+-label%3AUpdate%2CCorrection%2CTranslation%2C%22Bi-Weekly+Notes+%2F+Editorial+Housekeeping%22%2C%22CIP-0010%3A+new+registry+entry%22%2C%22CIP-0067%3A+new+label%22%2C%22CIP-0088%3A+new+extension%22+sort%3Aupdated-asc)\n* [proposals Likely Abandoned](https://github.com/cardano-foundation/CIPs/pulls?q=is%3Apr+is%3Aopen+draft%3Afalse+in%3Atitle+label%3A%22State%3A+Likely+Abandoned%22+-label%3AUpdate%2CCorrection%2CTranslation%2C%22Bi-Weekly+Notes+%2F+Editorial+Housekeeping%22%2C%22CIP-0010%3A+new+registry+entry%22%2C%22CIP-0067%3A+new+label%22%2C%22CIP-0088%3A+new+extension%22+sort%3Aupdated-asc)\n* [proposals Likely Deprecated](https://github.com/cardano-foundation/CIPs/pulls?q=is%3Apr+is%3Aopen+draft%3Afalse+in%3Atitle+label%3A%22State%3A+Likely+Deprecated%22+-label%3AUpdate%2CCorrection%2CTranslation%2C%22Bi-Weekly+Notes+%2F+Editorial+Housekeeping%22%2C%22CIP-0010%3A+new+registry+entry%22%2C%22CIP-0067%3A+new+label%22%2C%22CIP-0088%3A+new+extension%22+sort%3Aupdated-asc)\n\nProposals stalled without any updates from their authors will eventually be closed. However, authors are invited to re-open pull requests or open new ones should they want to bring the discussion back to life.\n\n## Editors\n\n| Robert Phair <br/> [@rphair][] | Ryan Williams <br/> [@Ryun1][] | Thomas Vellekoop <br/> [@perturbing][] |\n| ---                            | ---                            | ---                                    |\n\n[@rphair]: https://github.com/rphair\n[@Ryun1]: https://github.com/Ryun1\n[@perturbing]: https://github.com/perturbing\n\n"
  }
]