diff --git a/.github/CIP-TEMPLATE.md b/.github/CIP-TEMPLATE.md index d048eb2eac..cc8729ff9f 100644 --- a/.github/CIP-TEMPLATE.md +++ b/.github/CIP-TEMPLATE.md @@ -29,13 +29,13 @@ License: CC-BY-4.0 ## Abstract -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? ## Specification -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? -## Use cases +## Use Cases ## Goals diff --git a/CIP-0001/README.md b/CIP-0001/README.md index 733efeacb2..4bfea4be86 100644 --- 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.

This section must address the [Versioning](#versioning) requirement unless this is addressed in an optional Versioning section.

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.

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.

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):
Acceptance Criteria
Describes what are the acceptance criteria whereby a proposal becomes _'Active'_.
Implementation Plan
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:
**Versioning**: if [Versioning](#versioning) is not addressed in Specification
**References**
**Appendices**
**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 index b129925cfd..e7ba21c5b4 100644 --- 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 index 3c6b3eeeac..2bbd7d2584 100644 --- 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 index 87499e432c..b6b807f048 100644 --- 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 index cfb21689fa..a6b4f9b95c 100644 --- 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 index 03781c4c3b..31572b37fa 100644 --- 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 index 5dfe27e442..bd53e4dbea 100644 --- a/CIP-0007/README.md +++ b/CIP-0007/README.md @@ -11,7 +11,7 @@ Discussions: - https://forum.cardano.org/t/protocol-parameters-pledge-and-sybil-resistance/35100 - https://github.com/input-output-hk/cardano-node/issues/1518 Implementors: [] -License: Apache 2.0 +License: Apache-2.0 --- ## Abstract @@ -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 index e94e932bf4..520abba08f 100644 --- 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 index 5b80324b49..032741b649 100644 --- 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 index 88cf4c98fe..73314942f6 100644 --- 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: diff --git a/CIP-0011/README.md b/CIP-0011/README.md index f67fbac852..3836a9e008 100644 --- a/CIP-0011/README.md +++ b/CIP-0011/README.md @@ -19,7 +19,7 @@ License: CC-BY-4.0 Starting 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]. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Generally 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. @@ -60,7 +60,7 @@ reward address (with `network_id=1`) stake1uy8ykk8dzmeqxm05znz65nhr80m0k3gxnjvdngf8azh6sjc6hyh36 ``` -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? ### Meaning of *account* diff --git a/CIP-0012/README.md b/CIP-0012/README.md index 6c81252b41..8e0a5693a3 100644 --- a/CIP-0012/README.md +++ b/CIP-0012/README.md @@ -7,6 +7,7 @@ Authors: - Marek Mahut - Sebastien Guillemot - Ján Hrnko +Implementors: [] Discussions: - https://forum.cardano.org/t/on-chain-stake-pool-operator-to-delegates-communication/42229 - https://github.com/cardano-foundation/CIPs/pull/44 @@ -18,7 +19,7 @@ License: CC-BY-4.0 Standard format for metadata used in an on-chain communication of stake pool owner towards their delegates. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Stake pool owners and their delegates lack an on-chain communication standard between them. @@ -98,7 +99,7 @@ The [schema.json](./schema.json) file defines the metadata. } ``` -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? The 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. diff --git a/CIP-0013/README.md b/CIP-0013/README.md index 3335365352..a0a482a5c3 100644 --- a/CIP-0013/README.md +++ b/CIP-0013/README.md @@ -26,7 +26,7 @@ License: CC-BY-4.0 This describes a general standard URI scheme with two specific protocols to handle Ada transfers and links to weighted lists of stake pools. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? ### In general: @@ -149,7 +149,7 @@ An ABNF grammar should be specified and explained similarly for each CIP that de 2. 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. 3. 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`). -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? ### Rationale for general URI scheme diff --git a/CIP-0014/README.md b/CIP-0014/README.md index 9a69de2f52..a50dea6bb7 100644 --- a/CIP-0014/README.md +++ b/CIP-0014/README.md @@ -17,7 +17,7 @@ License: CC-BY-4.0 This 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. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? The 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. @@ -149,7 +149,7 @@ mkAssetFingerprint (PolicyId policyId) (AssetName assetName) asset_fingerprint: asset1pkpwyknlvul7az0xx8czhl60pyel45rpje4z8w ``` -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? ### Design choices diff --git a/CIP-0015/README.md b/CIP-0015/README.md index 32971f4d89..c85d3f8e8d 100644 --- a/CIP-0015/README.md +++ b/CIP-0015/README.md @@ -4,8 +4,8 @@ Title: Registration Transaction Metadata Format Category: Metadata Status: Active Authors: - - Sebastien Guillemot , - - Rinor Hoxha , + - Sebastien Guillemot + - Rinor Hoxha - Mikhail Zabaluev Implementors: - Daedalus , @@ -26,7 +26,7 @@ License: CC-BY-4.0 This CIP details a transaction metadata format, used by Cardano's [Project Catalyst](https://projectcatalyst.io) for voter registrations. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Project Catalyst uses a sidechain for it's voting system. One 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. @@ -106,7 +106,7 @@ Catalyst Fund 4: It was planned that since Fund 4, `registration_signature` and the `staking_pub_key` entry inside the `key_registration` field will be deprecated. This has been deferred to a future revision of the protocol. -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? The described metadata format allows for the association of a voting key with a stake credential on a Cardano network. diff --git a/CIP-0016/README.md b/CIP-0016/README.md index 6d2001fa03..806f8f0a66 100644 --- a/CIP-0016/README.md +++ b/CIP-0016/README.md @@ -11,7 +11,6 @@ Implementors: - cardano-serialization-lib Discussions: - https://github.com/cardano-foundation/CIPs/pull/57 -Type: Standards Created: 2020-12-21 License: Apache-2.0 --- @@ -26,7 +25,7 @@ cryptographic keys across the Cardano eco-system: - [BIP32-Ed25519](https://ieeexplore.ieee.org/document/7966967) extended keys (Ed25519 extended keys with BIP32-style derivation) -## Motivation +## Motivation: Why is this CIP necessary? Throughout the Cardano eco-system, different projects have used different serialisation formats for cryptographic keys. @@ -108,7 +107,7 @@ code. This structure should be Bech32 encoded, using one of the appropriate `*_xsk` prefixes defined in CIP-0005. -## Rationale +## Rationale: How does this CIP achieve its goals? ### Extended Signing Key Format diff --git a/CIP-0017/README.md b/CIP-0017/README.md index 1c33cf731f..854995da3a 100644 --- a/CIP-0017/README.md +++ b/CIP-0017/README.md @@ -16,7 +16,7 @@ License: CC-BY-4.0 This document details a common format for sharing Cardano delegation portfolio across various tools and wallets. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Stakeholders 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. @@ -61,7 +61,7 @@ Portfolios which treat all stake pools equally should use the same weight (e.g. } ``` -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? 1. JSON is widely used, widely supported and quite lightweight. Makes for a reasonable choice of data format. @@ -93,6 +93,6 @@ The only point of incompatibility regards the `pool_id` field (in Adafolio) vs t - [ ] Provide a reference implementation and/or parsing library to read and/or write files in this schema. -# Copyright +## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). diff --git a/CIP-0018/README.md b/CIP-0018/README.md index 218209e478..79dd798b10 100644 --- a/CIP-0018/README.md +++ b/CIP-0018/README.md @@ -16,7 +16,7 @@ License: CC-BY-4.0 This 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]. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Cardano 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. @@ -68,7 +68,7 @@ As a result, this extension would not incapacitate existing wallets since the pa We deem this to be an acceptable and fairly minor consequence but encourage existing software to raise awareness about this behaviour. -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? - 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. @@ -91,7 +91,7 @@ We deem this to be an acceptable and fairly minor consequence but encourage exis - [ ] Develop the proposed Reference Implementation as suggested when this CIP was originally published (see Discussion link in header for history). - [ ] Contact wallet and dApp representatives in the community to develop and maintain interest in their support for this specification. -# Copyright +## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). diff --git a/CIP-0019/README.md b/CIP-0019/README.md index 850c6474ba..665418c21e 100644 --- a/CIP-0019/README.md +++ b/CIP-0019/README.md @@ -16,7 +16,7 @@ License: CC-BY-4.0 This specification describes the structure of addresses in Cardano, covering both addresses introduced in the Shelley era and the legacy format from the Byron era. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Document 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. @@ -217,7 +217,7 @@ testnet: type-14: stake_test1uqehkck0lajq8gr28t9uxnuvgcqrc6070x3k9r8048z8y5gssrtvn type-15: stake_test17rphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtcljw6kf ``` -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? As 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). diff --git a/CIP-0020/README.md b/CIP-0020/README.md index 62fa209bcd..31ae1a68fb 100644 --- a/CIP-0020/README.md +++ b/CIP-0020/README.md @@ -36,7 +36,7 @@ License: CC-BY-4.0 This describes a basic JSON schema to add messages/comments/memos as transaction metadata by using the metadatum label **674**: allowing informational, commerical, or any other text to be included in a transaction on the Cardano blockchain. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? We 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. So 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. @@ -132,7 +132,7 @@ The number of theses **message-strings** must be at least one for a single messa **CNTools**:
![image](https://user-images.githubusercontent.com/47434720/130353491-fc0f3a69-1937-4e72-b680-c04cc069b5c4.png) -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? This 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 an 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. diff --git a/CIP-0021/README.md b/CIP-0021/README.md index b250493225..d5ece97b46 100644 --- a/CIP-0021/README.md +++ b/CIP-0021/README.md @@ -18,7 +18,7 @@ License: CC-BY-4.0 This CIP describes all the restrictions applicable to Cardano transactions which need to be signed by hardware wallets. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Due 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. @@ -146,7 +146,7 @@ In this exceptional case, auxiliary data must be encoded in their "tuple" format The `auxiliary_scripts` must be an array of length 0. -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? ### Canonical CBOR serialization format @@ -203,7 +203,7 @@ We think that votes and DRep certificates are rare and substantially distinguish - [x] [`cardano-hw-interop-library`](https://github.com/vacuumlabs/cardano-hw-interop-lib) - [x] [`cardano-hw-cli`](https://github.com/vacuumlabs/cardano-hw-cli) (which uses the interop library) -## Restrictions for specific hardware devices +### Restrictions for specific hardware devices The 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). diff --git a/CIP-0022/README.md b/CIP-0022/README.md index 68e648fe02..1aca2328d9 100644 --- a/CIP-0022/README.md +++ b/CIP-0022/README.md @@ -22,7 +22,7 @@ License: CC-BY-4.0 This proposal describes a method allowing a stakepool operator to provide credentials to verify that they are the rightful manager for their stakepool. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Many 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. @@ -126,7 +126,7 @@ verification: 9ca4c7e63ba976dfbe06c7a0e6ec4aec5a5ef04b721ffc505222606dfc3d01572d Verification SUCCESS! ``` -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? Implementing 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. diff --git a/CIP-0023/README.md b/CIP-0023/README.md index eb60f929f3..647d369718 100644 --- a/CIP-0023/README.md +++ b/CIP-0023/README.md @@ -18,7 +18,7 @@ License: CC-BY-4.0 This 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`). -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? The current minimum fixed pool fee places a large and unfair burden on delegators to pools with smaller amounts of stake. This incentivizes people to delegate to pools with higher stake causing centralization and creating an unequal playing field for stake pool operators. @@ -52,7 +52,7 @@ It is also recommended to introducce the hard-fork with `minPoolMargin` initiall Should 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. -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? The 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. Running minfees without any arguments gives the usage message as below. diff --git a/CIP-0024/README.md b/CIP-0024/README.md index 039a982e83..2e2627ab7c 100644 --- a/CIP-0024/README.md +++ b/CIP-0024/README.md @@ -17,7 +17,7 @@ License: CC-BY-4.0 Modify 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. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? There are two main reasons for changing the current ranking methodology: @@ -81,7 +81,7 @@ As an example, setting h to 0.1 would mean that the initial number of epochs for This gives a more reasonable ranking for newer pools that do not have enough historical data to provide fair rankings. -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? Using 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. It will also bring the rankings more in line with the general Cardano principle of increasing decentralization. diff --git a/CIP-0025/README.md b/CIP-0025/README.md index 80d0d423a6..d7c95224aa 100644 --- a/CIP-0025/README.md +++ b/CIP-0025/README.md @@ -23,7 +23,7 @@ License: CC-BY-4.0 This proposal defines an Media Token Metadata Standard for Native Tokens. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Tokens 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. So the link to the metadata needs to be established differently. @@ -150,7 +150,7 @@ Optional fields allow to save space in the blockchain. Consequently the minimal - [EIP-721](https://eips.ethereum.org/EIPS/eip-721) - URI/URL standards: [RFC3986](https://tools.ietf.org/html/rfc3986), [RFC2397](https://tools.ietf.org/html/rfc2397) -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? ### Retrieve valid metadata for a specific token diff --git a/CIP-0026/README.md b/CIP-0026/README.md index 45660aa05e..0769ed515f 100644 --- a/CIP-0026/README.md +++ b/CIP-0026/README.md @@ -19,7 +19,7 @@ License: CC-BY-4.0 We 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. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? On the blockchain, we tend to refer to things by hashes or other opaque identifiers. But these are not very human friendly: * In the case of hashes, we often want to know the preimage of the hash, such as @@ -403,7 +403,7 @@ Similar to the recommendations for metadata servers, this section gives some rec - The metadata client MAY be configurable to limit the amount downloaded. - The metadata client MAY accept user updates for metadata entries. -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? ### Interfaces and progressive enhancement diff --git a/CIP-0027/README.md b/CIP-0027/README.md index 34b9cd4143..bafd7f651a 100644 --- a/CIP-0027/README.md +++ b/CIP-0027/README.md @@ -18,7 +18,7 @@ License: Apache-2.0 This 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. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? There 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. @@ -63,7 +63,7 @@ A new tag of 777 is proposed for this implementation. The community guidelines 3) Burn no name token to free up UTxO (recommended, but not required). 4) Mint planned assets using this same policy. -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? By 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. diff --git a/CIP-0028/README.md b/CIP-0028/README.md index 3b21d57c87..8db7976d29 100644 --- a/CIP-0028/README.md +++ b/CIP-0028/README.md @@ -17,7 +17,7 @@ License: Apache-2.0 This 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. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? We 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. @@ -254,7 +254,7 @@ For simplicity, the details of the parameter settings is omitted here. There are no changes to the non-updatable protocol parameters. -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? The majority of the parameters are needed to enable the use of Plutus scripts on-chain. They relate to the fees calculations for transactions that include Plutus scripts. diff --git a/CIP-0029/README.md b/CIP-0029/README.md index 5f108785b4..d563698d0a 100644 --- a/CIP-0029/README.md +++ b/CIP-0029/README.md @@ -17,7 +17,7 @@ License: CC-BY-4.0 This 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. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? While 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. @@ -88,7 +88,7 @@ The JSON format is given as a [JSON schema in annexe](./phase-1-monetary-scripts "00830302838200581c000000000000000000000000000000000000000000000000000000008200581c000000000000000000000000000000000000000000000000000000018200581c00000000000000000000000000000000000000000000000000000002" ``` -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? - 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. diff --git a/CIP-0030/README.md b/CIP-0030/README.md index da47665a8a..78bcf30204 100644 --- a/CIP-0030/README.md +++ b/CIP-0030/README.md @@ -38,7 +38,7 @@ License: CC-BY-4.0 This 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. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? In 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. @@ -384,7 +384,7 @@ The benefits of this are: 1. New features can be added to CIP30 as experimental features and only moved to non-experimental once multiple wallets implement it 1. It provides a clear path to updating the CIP version number (when functions move from experimental -> stable) -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? See justification and explanations provided with each API endpoint. diff --git a/CIP-0031/README.md b/CIP-0031/README.md index 95de21b5bb..cf1fffc9f3 100644 --- a/CIP-0031/README.md +++ b/CIP-0031/README.md @@ -19,7 +19,7 @@ License: CC-BY-4.0 We introduce a new kind of input, a _reference_ input, which allows looking at an output without spending it. This will facilitate access to information stored on the blockchain without the churn associated with spending and recreating UTXOs. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Datums in transaction outputs provide a way to store and access information on the blockchain. However, they are quite constrained in a number of ways. @@ -100,7 +100,7 @@ transaction_body = } ``` -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? The key idea of this proposal is to use UTXOs to carry information. But UTXOs are currently a bad fit for distributing information. diff --git a/CIP-0032/README.md b/CIP-0032/README.md index 60c4e4b1e6..40c2a94c8b 100644 --- a/CIP-0032/README.md +++ b/CIP-0032/README.md @@ -19,7 +19,7 @@ License: CC-BY-4.0 We propose to allow datums themselves to be attached to outputs instead of datum hashes. This will allow much simpler communication of datum values between users. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Conceptually, datums are pieces of data that are attached to outputs. However, in practice datums are implemented by attaching _hashes_ of datums to outputs, and requiring that the spending transaction provides the actual datum. @@ -69,7 +69,7 @@ transaction_output = ``` TODO: should there be a dedicated production for datum-hash-or-datum? Does it need to be tagged? -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? The key idea of this proposal is simply to restore the conceptually straightforward situation where datums are attached to outputs. Historically, 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). diff --git a/CIP-0033/README.md b/CIP-0033/README.md index d5fb3a7219..1134527f45 100644 --- a/CIP-0033/README.md +++ b/CIP-0033/README.md @@ -20,7 +20,7 @@ License: CC-BY-4.0 We 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. This will allow transactions using common scripts to be much smaller. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Script sizes pose a significant problem. This manifests itself in two ways: 1. 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. @@ -64,7 +64,7 @@ transaction_output = ``` TODO: can we use a more generic type that allows _any_ script in a forwards-compatible way? -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? The 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. diff --git a/CIP-0034/README.md b/CIP-0034/README.md index d50c4d1ef4..9abdf9ceab 100644 --- a/CIP-0034/README.md +++ b/CIP-0034/README.md @@ -18,7 +18,7 @@ License: CC-BY-4.0 Currently 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. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Cardano currently has three ways to refer to a network: - The "network ID" included in every address and also optionally present in the transaction body. This only stores 16 possibilities (4 bits) @@ -55,7 +55,7 @@ When representing these networks in a human-readable string, the following forma cip34:NetworkId-NetworkMagic ``` -# Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? We pick this format for the following reason: - 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 diff --git a/CIP-0035/README.md b/CIP-0035/README.md index 9422e6ff12..4e8f0f6e17 100644 --- a/CIP-0035/README.md +++ b/CIP-0035/README.md @@ -15,15 +15,13 @@ Created: 2022-02-09 License: CC-BY-4.0 --- -# Changes to Plutus Core - ## Abstract This CIP specifies a process for proposing changes to Plutus Core, its builtins, and its interface to the Cardano ledger. It gives a taxonomy of typical changes, and explains how these changes may be made, which in some cases requires a CIP. It introduces the 'Plutus' CIP category for tracking these. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? The 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: - We may be able to increase performance, improve safety, or reduce script sizes by changing the language. @@ -35,10 +33,7 @@ The Plutus Core language, its builtins, and its interface to the ledger are all - … and more This CIP gives a taxonomy of changes, explains how such changes might be implemented in Cardano, and prescribes processes for proposing such changes. - -## Background - -This CIP assumes general familiarity with Plutus Core and the Cardano ledger, but we give some brief background here. +It assumes general familiarity with Plutus Core and the Cardano ledger, though we begin with some brief background: ### Plutus Core @@ -263,7 +258,7 @@ For example, if a bug fix changes behaviour, it will have to wait for a new Plut Proposals for other additions, removals, or changes to behaviour of any part of Plutus Core or its builtins SHOULD be proposed in a CIP. -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? ### Do removals and changes really need a new ledger language? diff --git a/CIP-0036/README.md b/CIP-0036/README.md index 292bc16b58..735149eb06 100644 --- a/CIP-0036/README.md +++ b/CIP-0036/README.md @@ -23,7 +23,7 @@ License: CC-BY-4.0 Cardano 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. This is a revised version of the original [CIP-15 | Registration Transaction Metadata Format](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015). -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Cardano 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". @@ -217,7 +217,7 @@ See the [schema file](./schema.cddl). See [test vector file](./test-vector.md). -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? ### Associating voting power with a voting key diff --git a/CIP-0037/README.md b/CIP-0037/README.md index 0c3af0bca4..0da3cfc6db 100644 --- a/CIP-0037/README.md +++ b/CIP-0037/README.md @@ -16,7 +16,7 @@ License: CC-BY-4.0 The pledge should be used to calculate the saturation point of a pool: setting a maximum delegation proportional to pledge. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Currently 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). @@ -137,7 +137,7 @@ Results: [Log] pledge: 2000000, sat: 67438565.126 ``` -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? Since 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. @@ -148,7 +148,7 @@ One of the questions raised by the community was, will the lower limit stop the 1. The value is a percentage of k, such as 10%. This percentage could increase as needed, such as to 15% of k. 2. 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 -## Path To Active +## Path to Active ### Acceptance Criteria diff --git a/CIP-0040/README.md b/CIP-0040/README.md index 7e694a0a4a..7d8cd148ca 100644 --- a/CIP-0040/README.md +++ b/CIP-0040/README.md @@ -18,7 +18,7 @@ License: CC-BY-4.0 This document describes adding a new output type to transactions called Collateral Outputs. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? As 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: @@ -61,7 +61,7 @@ However, if collateral output is specified, then 2. Collateral output needs to be balanced according to `sum(collateral_input) = sum(collateral_output) + collateral_consumed` Where `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. -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? ### Self-contained balancing diff --git a/CIP-0042/README.md b/CIP-0042/README.md index 9022f51229..307751c305 100644 --- a/CIP-0042/README.md +++ b/CIP-0042/README.md @@ -19,7 +19,7 @@ License: Apache-2.0 This document describes the addition of a new Plutus builtin for serialising `BuiltinData` to `BuiltinByteString`. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? As 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. @@ -97,7 +97,7 @@ We propose to re-use this instance to define a cost model linear in the size of Benchmarking 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. -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? * Easy to implement as it reuses existing code of the Plutus codebase; * Such built-in is generic enough to also cover a wider set of use-cases, while nicely fitting ours; @@ -120,7 +120,7 @@ Benchmarking and costing `serialiseData` was done in [this PR](https://github.co * 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. -## Path To Active +## Path to Active ### Acceptance Criteria diff --git a/CIP-0045/README.md b/CIP-0045/README.md index fdd0544c0a..e419dbaa7d 100644 --- a/CIP-0045/README.md +++ b/CIP-0045/README.md @@ -19,7 +19,7 @@ License: CC-BY-4.0 We 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). -## Motivation +## Motivation: Why is this CIP necessary? In 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. @@ -225,7 +225,7 @@ We decided to spawn the server within the dApp to force the user to manually sca - The wallet app needs to verifiy the origin (address) of the RPC call - 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) -## Rationale +## Rationale: How does this CIP achieve its goals? The 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. diff --git a/CIP-0049/README.md b/CIP-0049/README.md index c74042d492..0258b5eb4e 100644 --- a/CIP-0049/README.md +++ b/CIP-0049/README.md @@ -21,7 +21,7 @@ Support ECDSA and Schnorr signatures over the SECP256k1 curve in Plutus Core; specifically, allow validation of such signatures as builtins. These builtins work over ``BuiltinByteString``s. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Signature schemes based on the SECP256k1 curve are common in the blockchain industry; a notable user of these is Bitcoin. Supporting signature schemes which @@ -146,7 +146,7 @@ The builtin operations will error with a descriptive message if given inputs that don't correspond to the constraints above, return `False` if the signature fails to verify the input given the key, and `True` otherwise. -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? We consider the implementation trustworthy: `secp256k1` is the reference implementation for both signature schemes, and is already being used in diff --git a/CIP-0050/README.md b/CIP-0050/README.md index e0fa18ae06..12ae668834 100644 --- a/CIP-0050/README.md +++ b/CIP-0050/README.md @@ -17,7 +17,7 @@ Discussions: - https://forum.cardano.org/t/cip-shelley-s-basho-voltaire-decentralization-update/97685 - https://forum.cardano.org/t/minimum-pool-fees-with-a-brief-mention-of-k-changes/97002/82 - https://github.com/cardano-foundation/CIPs/pull/1042 -Created: 4 April 2022 (original), 20 May 2025 (updated) +Created: 2022-04-04 License: CC-BY-4.0 --- @@ -25,6 +25,8 @@ License: CC-BY-4.0 Improving 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. +> [Note!] This CIP was originally authored on 2022-04-04, but was subsequently updated on 2025-05-20 + ## Motivation: Why is this CIP necessary? ### Stagnating Decentralization and Sybil Concerns @@ -111,7 +113,7 @@ We propose adding a new protocol parameter L (maximum pledge leverage) to the st * 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. -## Rationale: How Does This CIP Achieve Its Goals? +## Rationale: How does this CIP achieve its goals? ### Penalizing Under-Pledged Pools (Sybil Deterrence) diff --git a/CIP-0052/README.md b/CIP-0052/README.md index ab52b7433d..d65475640e 100644 --- a/CIP-0052/README.md +++ b/CIP-0052/README.md @@ -19,7 +19,7 @@ License: CC-BY-4.0 These 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. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? This 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. @@ -217,11 +217,11 @@ Auditors shall provide credentials for the following competencies: Disclosure It 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. -## Rationale: how does this CIP achieve its goals? +## Rationale: How does this CIP achieve its goals? These 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. -## Path to active +## Path to Active ### Acceptance Criteria diff --git a/CIP-0054/README.md b/CIP-0054/README.md index 144da4770b..b5e1df4ce5 100644 --- a/CIP-0054/README.md +++ b/CIP-0054/README.md @@ -18,7 +18,7 @@ License: CC-BY-4.0 This 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. -## Motivation: why is this CIP necessary? +## Motivation: Why is this CIP necessary? Currently 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. @@ -226,7 +226,7 @@ The second argument allows you to specify which token's files to search - it sho The URL returned by this function should be in a format that is accessible from within the `