Cardano Improvement Proposals (CIPs)

Introduction Cardano Improvement Proposals (CIPs) are the formalized design documents and standards by which new features and enhancements are discussed, specified, and adopted in the Cardano ecosystem ([cips.cardano.org]1). While CIPs span a wide range of topics (ledger upgrades, wallet features, tooling, metadata, etc.), this tutorial focuses only on those CIPs directly aimed at smart‑contract development—i.e., features that enable richer on‑chain logic, data management for Plutus scripts, and seamless dApp‑to‑wallet integrations.

---

1. Transaction & On‑Chain Script Infrastructure

CIP‑31: Reference Inputs

What it does: Allows transactions to include UTXOs as reference inputs—the script context is augmented so that scripts can read data from these UTXOs without consuming them. Problem solved: Enables data‑sharing and oracle patterns on‑chain without burning collateral or redeploying UTXOs, reducing wastage and complexity. Where used: Introduced in the Vasil hard fork (June 2022), underpinning many Plutus V2 scripts that rely on shared configuration or oracle UTXOs ([cips.cardano.org]2, [docs.cardano.org]3).

CIP‑32: Inline Datums

What it does: Permits complete datum values to be stored inline within transaction outputs, rather than only their hashes. Problem solved: Simplifies off‑chain datum management, ensuring scripts always have direct access to necessary data without requiring external datum retrieval. Where used: Also part of Vasil, widely adopted in Plutus example contracts and emulator tests to streamline datum handling ([cips.cardano.org]4, [docs.cardano.org]3).

CIP‑33: Reference Scripts

What it does: Introduces reference scripts so that the script code itself can be stored in a UTXO and referenced, instead of embedding the script in every transaction. Problem solved: Reduces transaction size and on‑chain storage costs by reusing a single script UTXO across multiple transactions. Where used: Employed in advanced dApps to save on fees and simplify multi‑script deployments following Vasil ([cips.cardano.org]5, [docs.cardano.org]3).

CIP‑40: Collateral Outputs

What it does: Adds an explicit collateralOutputs field to transaction bodies, specifying how much collateral will be consumed if script validation fails. Problem solved: Enables hardware wallets and other tools to verify collateral balances upfront, ensuring security in Plutus script transactions. Where used: Deployed in Vasil and supported by most cardano‑wallet implementations to improve UX when dealing with collateral ([cips.cardano.org]6, [docs.cardano.org]3).

---

2. On‑Chain Data & Metadata Standards

CIP‑25: NFT Metadata Standard

What it does: Defines a unified JSON schema under the "721" label in transaction metadata for minting and describing NFTs. Problem solved: Ensures interoperability across wallets, marketplaces, and explorers when displaying NFTs. Where used: The de facto standard for virtually all Cardano NFT projects and marketplaces since its adoption; leveraged in on‑chain minting policies and metadata parsers ([cips.cardano.org]7).

CIP‑68: Datum Metadata Standard

What it does: Extends metadata standards to on‑chain output datums, allowing arbitrary JSON metadata to reside in UTXO datums beyond NFTs. Problem solved: Bridges the gap between metadata and Plutus scripts, enabling scripts to inspect rich metadata programmatically. Where used: Utilized in token issuance contracts where evolving metadata or programmatic updates are required ([cips.cardano.org]8).

CIP‑54: Cardano Smart NFTs

What it does: Specifies additional metadata fields for NFTs that signal they wish to query current blockchain state (e.g., slot number, asset prices). Problem solved: Enables “smart” NFTs that carry logic to fetch and react to on‑chain information without custom script code. Where used: Early experiments in dynamic NFTs that update appearance or properties based on blockchain events ([cips.cardano.org]9).

CIP‑86: NFT Metadata Update Oracles

What it does: Introduces schemas for simple and regex‑based metadata updates via signed “oracle” transactions. Problem solved: Facilitates efficient batch updates to multiple NFTs’ metadata under a single policy, reducing on‑chain overhead. Where used: Adopted by marketplaces needing to push collection‑wide metadata changes post‑mint ([cips.cardano.org]10).

CIP‑0102: Royalty Datum Metadata

What it does: Defines a datum schema for specifying royalty splits among multiple addresses, encoded on‑chain. Problem solved: Automates on‑chain royalty distributions, enhancing trust and transparency for creators and marketplaces. Where used: Emerging in NFT contracts supporting programmable royalty enforcement ([cips.cardano.org]11).

---

3. dApp–Wallet Integration Interfaces

CIP‑30: dApp–Wallet Web Bridge

What it does: Establishes a JS interface (window.cardano) that dApps use to discover, connect, and interact with user wallets (e.g., submit transactions, get UTXOs). Problem solved: Standardizes wallet‑connector APIs, enabling cross‑wallet dApp compatibility. Where used: Implemented by Nami, Eternl, Flint, and nearly every Cardano browser wallet ([cips.cardano.org]12).

CIP‑141: Web‑Wallet Bridge for Plutus Wallets

What it does: Extends CIP‑30 to support script‑controlled (Plutus) wallets, specifying how dApps request script descriptors, collateral info, and validation contexts. Problem solved: Enables dApps to build transactions for script addresses, broadening wallet support. Where used: In development of Plutus-native wallets (e.g., wallet‑connect‑plutus libraries) ([cips.cardano.org]13).

CIP‑0104: Account Public Key Endpoint

What it does: Adds a CIP‑30 extension for dApps to retrieve an account’s extended public key, allowing granular UTXO selection. Problem solved: Gives dApps more control over fund management for advanced UX scenarios. Where used: Adopted by wallets seeking to optimize on‑chain lookups and custom UTXO strategies ([cips.cardano.org]14).

CIP‑0103: Bulk Transaction Signing

What it does: Enhances the CIP‑30 submitTx endpoint to allow signing and submitting an array of transactions in one call. Problem solved: Improves developer experience by reducing round‑trips when chaining multiple transactions. Where used: Useful in batch‑minting scripts and multi‑step dApp flows ([cips.cardano.org]15).

CIP‑0106: Multisig Wallet Extension

What it does: Defines CIP‑30 extension methods for dApps to interface with native-script multisig wallets, exposing script requirements and descriptors. Problem solved: Enables dApps to construct valid transactions for multisig addresses, unlocking complex custodial workflows. Where used: Integrated by wallet UIs supporting on‑chain multisig schemes ([cips.cardano.org]16).

---

4. Plutus Script API Enhancements

CIP‑69: Script Signature Unification

What it does: Standardizes the arguments to all Plutus script types by removing the separate datum argument, passing only the redeemer and script context. Problem solved: Eliminates mutual-dependency issues when two validators reference each other’s hashes, simplifying validator development. Where used: Rolled into Plutus V2 language updates, adopted by complex dApp protocols to reduce boilerplate ([cips.cardano.org]17).

---

5. Domain‑Specific Smart Contract Standards

CIP‑0071: NFT Proxy Voting Standard

What it does: Defines a minting‑policy‑based “ballot” NFT and associated datum to enable verifiable on‑chain voting in NFT projects lacking a native governance token. Problem solved: Provides a lightweight governance mechanism for NFT communities without building full DAOs. Where used: Employed by NFT collectives seeking on‑chain voting for community decisions ([cips.cardano.org]18).

---

Conclusion These CIPs form the backbone of Cardano’s smart‑contract ecosystem, addressing critical needs from low‑level UTXO management to high‑level dApp interactions and metadata standards. By understanding and leveraging these proposals, developers can build more efficient, interoperable, and user‑friendly Plutus applications.

Summary for New People

What is a CIP?

A Cardano Improvement Proposal (CIP) is a structured design document and the formal process by which community members propose, discuss, and record changes or additions to the Cardano ecosystem.

Why CIPs Matter

• They provide a single, version‑controlled record of design decisions.
• They ensure transparent community feedback and consensus building.
• They drive standardization and interoperability across wallets, tools, tokens, metadata, and more.

CIP Statuses

• Proposed – Meets basic requirements and is open for feedback.
• Active – Accepted; criteria from its Path to Active have been fulfilled.
• Inactive – Superseded, abandoned, or otherwise withdrawn (reason specified).

High‑Level Process

1. Draft & Submit Authors fork the cardano-foundation/CIPs repo, add a Markdown file named README.md in a folder like CIP-my-feature, include the header preamble and required sections, and open a PR.
2. Feedback & Triage In bi‑weekly editor meetings, draft CIPs are triaged, numbered, and assigned for review. Authors solicit community feedback via GitHub PR comments.
3. Review & Merge Editors ensure content quality, technical soundness, and completeness before merging as Proposed. Once its acceptance criteria are met (e.g., implementation released, protocol upgrade live, community adoption), it can be updated to Active.
4. Implementation Implementors follow the CIP’s Implementation Plan to drive the proposal to production.

Document Structure

1. Header Preamble YAML front matter with metadata (number, title, category, status, authors, implementors, discussion links, creation date, license).

2. Abstract ~200‑word summary of the proposal.

3. Motivation Why the CIP is needed; use cases; problem statement.

4. Specification Detailed technical design (enough to implement without further clarification). Include CDDL schemas for on‑chain data.

5. Rationale Design choices, alternatives considered, backward‑compatibility impacts, evidence of community consensus.

6. Path to Active

   • Acceptance Criteria – Observable deliverables or metrics.
   • Implementation Plan – Steps and responsible implementors.

7. Optional Sections Versioning, References, Appendices, Acknowledgements, etc.

8. Copyright Must use an approved license (e.g., Apache‑2.0 for code, CC‑BY‑4.0 for docs).

---

CIP: ? # Number (omit leading zeros until assigned) Title: <Short, descriptive title> Category: <Meta | Wallets | Tokens | Metadata | Tools | …> Status: Proposed | Active | Inactive () Authors:

• Name
• Name Implementors:
• Name # or N/A / [] if none Discussions:

Created: YYYY-MM-DD License: <Apache-2.0 | CC-BY-4.0>

Abstract

Motivation

Specification

Rationale

Path to Active

Acceptance Criteria

Implementation Plan

Optional Sections

Versioning

References

Appendices

Acknowledgements

Copyright

This CIP is licensed under .

Additional Resource:

Cardano Improvement Proposals Explained | TCE 94