cardano-foundation · Ryun1 · Jan 5, 2026 · Jan 5, 2026 · Jan 5, 2026 · Jan 5, 2026
diff --git a/.github/CIP-TEMPLATE.md b/.github/CIP-TEMPLATE.md
@@ -29,13 +29,13 @@ License: CC-BY-4.0
 ## Abstract
 <!-- A short (\~200 word) description of the proposed solution and the technical issue being addressed. -->
 
-## Motivation: why is this CIP necessary?
+## Motivation: Why is this CIP necessary?
 <!-- 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`. -->
 
 ## Specification
 <!-- 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.-->
 
-## Rationale: how does this CIP achieve its goals?
+## Rationale: 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.
 
 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.

diff --git a/.github/CPS-TEMPLATE.md b/.github/CPS-TEMPLATE.md
@@ -32,7 +32,7 @@ License: CC-BY-4.0
 ## Problem
 <!-- A more elaborate description of the problem and its context. This section should explain what motivates the writing of the CPS document. -->
 
-## Use cases
+## Use 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 not suitable. -->
 
 ## Goals

diff --git a/CIP-0001/README.md b/CIP-0001/README.md
@@ -26,7 +26,7 @@ A Cardano Improvement Proposal (CIP) is a formalised design document for the Car
 
 The 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.
 
-## Motivation: why is this CIP necessary?
+## Motivation: Why is this CIP necessary?
 
 CIPs aim to address two challenges mainly:
 1. The need for various parties to agree on a common approach to ease the interoperability of tools or interfaces.
@@ -81,9 +81,9 @@ Name                                            | Description
 ---                                             | ---
 Preamble                                        | Headers containing metadata about the CIP ([see below](#header-preamble)).
 Abstract                                        | A short (\~200 word) description of the proposed solution and the technical issue being addressed.
-Motivation: 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`.
+Motivation: 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`.
 Specification                                   | 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.
-Rationale: 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.
+Rationale: 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.
 Path 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.
 _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**
 Copyright                                       | The CIP must be explicitly licensed under acceptable copyright terms ([see below](#licensing)).
@@ -441,7 +441,7 @@ Emeritus editors:
 - Matthias Benkort - [@KtorZ](https://github.com/KtorZ)
 - Duncan Coutts - [@dcoutts](https://github.com/dcoutts)
 
-## Rationale: how does this CIP achieve its goals?
+## Rationale: How does this CIP achieve its goals?
 
 ### Key changes from CIP-0001 (version 1)
 

diff --git a/CIP-0002/README.md b/CIP-0002/README.md
@@ -24,7 +24,7 @@ In the context of this article, **coin selection** refers to the process of
 choosing _unspent coins_ from a wallet (or [UTxO set](#utxo-set)) in order to
 pay money to one or more recipients.
 
-## Motivation: why is this CIP necessary?
+## Motivation: Why is this CIP necessary?
 
 This document was written to help people gain an understanding of the coin
 selection algorithms used in Cardano _without_ having to read through and
@@ -953,7 +953,7 @@ to the caller as the [coin selection](#coin-selection) result.
 The [available UTxO set](#available-utxo-set) is returned to the caller as the
 [remaining UTxO set](#remaining-utxo-set) result.
 
-## Rationale
+## Rationale: How does this CIP achieve its goals?
 
 ### Largest-First
 

diff --git a/CIP-0003/README.md b/CIP-0003/README.md
@@ -24,7 +24,7 @@ Many wallets utilize some way of mapping a sentence of words (easy to read and w
 
 This document outlines the various mapping algorithms used in the Cardano ecosystem.
 
-## Motivation: why is this CIP necessary?
+## Motivation: Why is this CIP necessary?
 
 The 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)
 
@@ -62,7 +62,7 @@ Throughout the years, Cardano has used different styles of master key generation
 | [Icarus-Trezor](./Icarus.md)            | Trezor          | Ae2                     | No             | No              |
 | [Ledger/BitBox02](./Ledger_BitBox02.md) | Ledger/BitBox02 | Ae2                     | No             | No              |
 
-## Rationale: how does this CIP achieve its goals?
+## Rationale: How does this CIP achieve its goals?
 
 This CIP is merely to document the existing standards and not to provide rationales for the various methods used.
 

diff --git a/CIP-0004/README.md b/CIP-0004/README.md
@@ -20,7 +20,7 @@ License: Apache-2.0
 
 We introduce a checksum algorithm to help users verify they are restoring the right wallet before the restoration actually takes place.
 
-## Motivation: why is this CIP necessary?
+## Motivation: Why is this CIP necessary?
 
 Users 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.
 
@@ -47,7 +47,7 @@ To satisfy (2) and (3), the a hash of the public key is used
 
 To 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).
 
-## Rationale: how does this CIP achieve its goals?
+## Rationale: How does this CIP achieve its goals?
 
 We first provide a template for the code, explain the template and then provide the parameterization we use for Cardano
 

diff --git a/CIP-0005/README.md b/CIP-0005/README.md
@@ -21,7 +21,7 @@ License: Apache-2.0
 
 This 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.
 
-## Motivation: why is this CIP necessary?
+## Motivation: Why is this CIP necessary?
 
 Many 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).
 
@@ -151,7 +151,16 @@ The [CIP-0129] definitions are included within the tables above.
 | `cc_hot`           | Constitutional committee hot verification key hash (hot credential)   | blake2b\_224 digest of a constitutional committee hot verification key   |
 | `cc_hot_script`    | Constitutional committee hot script hash (hot credential)             | blake2b\_224 digest of a serialized constitutional committee hot script  |
 
-## Rationale: how does this CIP achieve its goals?
+### Changelog
+
+In order to make it easy to keep up with updates to this specification, 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.
+
+| ID  | Date        | Summary of changes                                              | Pull Request                                                  |
+| --- | ---         | ---                                                             | ---                                                           |
+| 2   | 2025-05-13  | Defined bech32 prefixes for extended pool operator keys         | [#1036](https://github.com/cardano-foundation/CIPs/pull/1036) |
+| 1   | 2025-04-22  | Defined bech32 prefixes for genesis keys and created changelog. | [#1027](https://github.com/cardano-foundation/CIPs/pull/1027) |
+
+## Rationale: How does this CIP achieve its goals?
 
 ### About the `_test` suffix
 
@@ -209,15 +218,6 @@ The only prior work done towards that direction has been [jcli](https://input-ou
 
 - Available JavaScript library: [cip5-js](https://www.npmjs.com/package/@dcspark/cip5-js)
 
-## Changelog
-
-In 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.
-
-| ID  | Date        | Summary of changes                                              | Pull Request                                                  |
-| --- | ---         | ---                                                             | ---                                                           |
-| 2   | 2025-05-13  | Defined bech32 prefixes for extended pool operator keys         | [#1036](https://github.com/cardano-foundation/CIPs/pull/1036) |
-| 1   | 2025-04-22  | Defined bech32 prefixes for genesis keys and created changelog. | [#1027](https://github.com/cardano-foundation/CIPs/pull/1027) |
-
 ## Copyright
 
 This CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0).

diff --git a/CIP-0006/README.md b/CIP-0006/README.md
@@ -19,7 +19,7 @@ License: CC-BY-4.0
 
 This CIP defines the concept of extended metadata for pools that is referenced from the pool registration data stored on chain.
 
-## Motivation: why is this CIP necessary?
+## Motivation: Why is this CIP necessary?
 
 As 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):
 
@@ -87,7 +87,7 @@ The operator now:
 
 This 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`.
 
-## Rationale: how does this CIP achieve its goals?
+## Rationale: How does this CIP achieve its goals?
 
 In the following we describe a first minimal version of the extended JSON file format.
 

diff --git a/CIP-0007/README.md b/CIP-0007/README.md
@@ -19,7 +19,7 @@ License: Apache 2.0
 Modifying 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.
 This also reduces the unfortunate side effect in the current equation that over rewards private pools which provide no additional security benefit.
 
-## Motivation: why is this CIP necessary?
+## Motivation: Why is this CIP necessary?
 
 There are two main reasons for changing the current linear a0 pledge benefit factor in the rewards equation.
 
@@ -108,7 +108,7 @@ Pledge	Rewards	Benefit	Alt Rwd	Alt Bnft
 
 As you can see this gives meaningful pledge benefit rewards to pools pledging less than 1m ADA.
 
-## Rationale: how does this CIP achieve its goals?
+## Rationale: How does this CIP achieve its goals?
 
 Using 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.
 It 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.

diff --git a/CIP-0008/README.md b/CIP-0008/README.md
@@ -22,7 +22,7 @@ License: CC-BY-4.0
 
 Private 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.
 
-## Motivation: why is this CIP necessary?
+## Motivation: Why is this CIP necessary?
 
 Most common use cases:
 
@@ -289,7 +289,7 @@ We recommend usage of unprotected headers vs protected headers when possible. Th
 
 The 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).
 
-## Rationale: how does this CIP achieve its goals?
+## Rationale: How does this CIP achieve its goals?
 
 ### Requirements
 

diff --git a/CIP-0009/README.md b/CIP-0009/README.md
@@ -18,7 +18,7 @@ License: Apache-2.0
 This 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.
 It is intended to serve as a historic record, allowing protocol parameter changes to be tracked back to the original settings.
 
-## Motivation: why is this CIP necessary?
+## Motivation: Why is this CIP necessary?
 
 We 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,
 and that document the chain of changes to the parameters.
@@ -309,7 +309,7 @@ The Mary Hard Fork Event will introduce multi-asset token capability.  It is not
 See [CIP-0028: Protocol Parameters (Alonzo Era)](../CIP-0028).
 
 
-## Rationale: how does this CIP achieve its goals?
+## Rationale: How does this CIP achieve its goals?
 
 The 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,
 in 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.).

diff --git a/CIP-0010/README.md b/CIP-0010/README.md
@@ -17,7 +17,7 @@ License: CC-BY-4.0
 
 Cardano 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.
 
-## Motivation: why is this CIP necessary?
+## Motivation: Why is this CIP necessary?
 
 The 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:
 
@@ -58,7 +58,7 @@ this file.
 
 \* It's best to avoid using `0` or any a similar number like `1` that other people are very likely to use. Prefer instead to generate a random number
 
-## Rationale: how does this CIP achieve its goals?
+## Rationale: How does this CIP achieve its goals?
 
 Creating a registry for `transaction_metadatum_label` values has the following benefit: