diff --git a/CIP-0031/README.md b/CIP-0031/README.md index 129069920..c252d5eb5 100644 --- a/CIP-0031/README.md +++ b/CIP-0031/README.md @@ -3,8 +3,8 @@ CIP: 31 Title: Reference inputs Authors: Michael Peyton Jones Comments-Summary: No comments -Comments-URI: -Status: Draft +Comments-URI: +Status: Active Type: Standards Track Created: 2021-11-29 License: CC-BY-4.0 @@ -53,17 +53,17 @@ A reference input is a transaction input, which is linked to a particular transa - A referenced output must exist in the UTXO set. - Any value on a referenced output is _not_ considered when balancing the transaction. -- The spending conditions on referenced outputs are _not_ checked, nor are the witnesses required to be present. +- The spending conditions on referenced outputs are _not_ checked, nor are the witnesses required to be present. - i.e. validators are not required to pass (nor are the scripts themselves or redeemers required to be present at all), and signatures are not required for pubkey outputs. - Referenced outputs are _not_ removed from the UTXO set if the transaction validates. - Reference inputs _are_ visible to scripts. For clarity, the following two behaviours which are present today are unchanged by this proposal: -1. Transactions must _spend_ at least one output.[^1] +1. Transactions must _spend_ at least one output.[^1] 2. Spending an output _does_ require the spending conditions to be checked.[^2] -[^1]: This restriction already exists, and is important. It seems unnecessary, since transactions must always pay fees and fees must come from somewhere, but fees could in principle be paid via reward withdrawals, so the requirement to spend a UTXO is relevant. +[^1]: This restriction already exists, and is important. It seems unnecessary, since transactions must always pay fees and fees must come from somewhere, but fees could in principle be paid via reward withdrawals, so the requirement to spend a UTXO is relevant. [^2]: That is, this proposal does not change outputs or the spending of outputs, it instead adds a new way of _referring_ to outputs. ### Script context @@ -74,7 +74,7 @@ The script context therefore needs to be augmented to contain information about Changing the script context will require a new Plutus language version in the ledger to support the new interface. The change in the new interface is: a _new_ field is added to the structure which contains the list of reference inputs. -The interface for old versions of the language will not be changed. +The interface for old versions of the language will not be changed. Scripts with old versions cannot be spent in transactions that include reference inputs, attempting to do so will be a phase 1 transaction validation failure. ### Extra datums @@ -93,35 +93,35 @@ The CDDL for transaction bodies will change to the following to reflect the new ``` transaction_body = { 0 : set ; inputs - ... + ... , ? 16 : set ; reference inputs } ``` ## Rationale -The key idea of this proposal is to use UTXOs to carry information. -But UTXOs are currently a bad fit for distributing information. -Because of locality, we have to include outputs that we use in the transaction, and the only way we have of doing that is to _spend_ them - and a spent output cannot then be referenced by anything else. +The key idea of this proposal is to use UTXOs to carry information. +But UTXOs are currently a bad fit for distributing information. +Because of locality, we have to include outputs that we use in the transaction, and the only way we have of doing that is to _spend_ them - and a spent output cannot then be referenced by anything else. To put it another way: outputs are resource-like, but information is not resource-like. -The solution is to add a way to _inspect_ ("reference") outputs without spending them. -This allows outputs to play double duty as resource containers (for the value they carry) and information containers (for the data they carry). +The solution is to add a way to _inspect_ ("reference") outputs without spending them. +This allows outputs to play double duty as resource containers (for the value they carry) and information containers (for the data they carry). ### Requirements We have a number of requirements that we need to fulfil. - Determinism - It must be possible to predict the execution of scripts precisely, given the transaction. -- Locality +- Locality - All data involved in transaction validation should be included in the transaction or the outputs which it spends (or references). - Non-interference - As far as possible, transactions should not interfere with others. The key exception is when transactions consume resources that other transactions want (usually by consuming UTXO entries). - Replay protection - The system should not be attackable (e.g. allow unexpected data reads) by replaying old traffic. -- Storage control and garbage-collection incentives +- Storage control and garbage-collection incentives - The amount of storage required by the system should have controls that prevent it from overloading nodes, and ideally should have incentives to shrink the amount of storage that is used over time. -- Optimized storage +- Optimized storage - The system should be amenable to optimized storage solutions. - Data transfer into scripts - Scripts must have a way to observe the data. @@ -193,7 +193,7 @@ This is actually a very important feature. Since anyone can lock an output with any address, addresses are not that useful for identifying _particular_ outputs on chain, and instead we usually rely on looking for particular tokens in the value locked by the output. Hence, if a script is interested in referring to the data attached to a _particular_ output, it will likely want to look at the value that is locked in the output. -For example, an oracle provider would need to distinguish the outputs that they create (with good data) from outputs created by adversaries (with bad data). +For example, an oracle provider would need to distinguish the outputs that they create (with good data) from outputs created by adversaries (with bad data). They can do this with a token, so long as scripts can then see the token! ### Hydra diff --git a/CIP-0032/README.md b/CIP-0032/README.md index 3751d7bc4..873d80d4f 100644 --- a/CIP-0032/README.md +++ b/CIP-0032/README.md @@ -3,8 +3,8 @@ CIP: 32 Title: Inline datums Authors: Michael Peyton Jones Comments-Summary: No comments -Comments-URI: -Status: Draft +Comments-URI: +Status: Active Type: Standards Track Created: 2021-11-29 License: CC-BY-4.0 @@ -19,10 +19,10 @@ This will allow much simpler communication of datum values between users. ## Motivation -Conceptually, datums are pieces of data that are attached to outputs. +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. -This is quite inconvenient for users. +This is quite inconvenient for users. Datums tend to represent the result of computation done by the party who creates the output, and as such there is almost no chance that the spending party will know the datum without communicating with the creating party. That means that either the datum must be communicated between parties off-chain, or communicated on-chain by including it in the witness map of the transaction that creates the output ("extra datums"). This is also inconvenient for the spending party, who must watch the whole chain to spot it. @@ -39,7 +39,7 @@ Transaction outputs are changed so that the datum field can contain either a has The min UTXO value for an output with an inline datum depends on the size of the datum, following the `coinsPerUTxOWord` protocol parameter. -When an output with an inline datum is spent, the spending transaction does not need to provide the datum itself. +When an output with an inline datum is spent, the spending transaction does not need to provide the datum itself. ### Script context @@ -52,7 +52,7 @@ There are two changes in the new version of the interface: - The datum field on transaction outputs can either be a hash or the actual datum. - The datum field on transaction inputs can either be a hash or the actual datum. -The interface for old versions of the language will not be changed. +The interface for old versions of the language will not be changed. Scripts with old versions cannot be spent in transactions that include inline datums, attempting to do so will be a phase 1 transaction validation failure. ### CDDL @@ -78,10 +78,10 @@ Since inline datums change very little about the model apart from where data is ### UTXO set size -This proposal gives users a way to put much larger amounts of data into the UTXO set. +This proposal gives users a way to put much larger amounts of data into the UTXO set. Won’t this lead to much worse UTXO set bloat? -The answer is that we already have a mechanism to discourage this, namely the minimum UTXO value. +The answer is that we already have a mechanism to discourage this, namely the minimum UTXO value. If inline datums turns out to drive significantly increased space usage, then we may need to increase `coinsPerUTxOWord` in order to keep the UTXO size down. That will be costly and inconvenient for users, but will still allow them to use inline datums where they are most useful and the cost is bearable. Furthermore, we hope that we will in fact be able to _reduce_ `coinsPerUTxOWord` when the upcoming work on moving the UTXO mostly to on-disk storage is complete. @@ -165,4 +165,4 @@ Hence we choose both option 1s and do _not_ provide backwards compatibility for ## References -[1]: Chakravarty, Manuel MT, et al. "The extended UTXO model." +[1]: Chakravarty, Manuel MT, et al. "The extended UTXO model." diff --git a/CIP-0033/README.md b/CIP-0033/README.md index d4381c3c4..f1792200b 100644 --- a/CIP-0033/README.md +++ b/CIP-0033/README.md @@ -3,8 +3,8 @@ CIP: 33 Title: Reference scripts Authors: Michael Peyton Jones Comments-Summary: No comments -Comments-URI: -Status: Draft +Comments-URI: +Status: Active Type: Standards Created: 2021-11-29 License: CC-BY-4.0 @@ -26,7 +26,7 @@ Script sizes pose a significant problem. This manifests itself in two ways: We would like to alleviate these problems. -The key idea is to use reference inputs and modified outputs which carry actual scripts ("reference scripts"), and allow such reference scripts to satisfy the script witnessing requirement for a transaction. +The key idea is to use reference inputs and modified outputs which carry actual scripts ("reference scripts"), and allow such reference scripts to satisfy the script witnessing requirement for a transaction. This means that the transaction which _uses_ the script will not need to provide it at all, so long as it referenced an output which contained the script. ## Specification @@ -46,10 +46,10 @@ Changing the script context will require a new Plutus language version in the le The change is: a new optional field is added to outputs and inputs to represent reference scripts. Reference scripts are represented by their hash in the script context. -The interface for old versions of the language will not be changed. +The interface for old versions of the language will not be changed. Scripts with old versions cannot be spent in transactions that include reference scripts, attempting to do so will be a phase 1 transaction validation failure. -### CDDL +### CDDL The CDDL for transaction outputs will change as follows to reflect the new field. ``` @@ -60,7 +60,7 @@ transaction_output = , ? ref_script : plutus_script ] ``` -TODO: can we use a more generic type that allows _any_ script in a forwards-compatible way? +TODO: can we use a more generic type that allows _any_ script in a forwards-compatible way? ## Rationale @@ -89,11 +89,11 @@ This is clearly not what you want: the reference script could be anything, perha With inline datums, we could put reference scripts in the datum field of outputs. -This approach has two problems. +This approach has two problems. First, there is a representation confusion: we would need some way to know that a particular datum contained a reference script. We could do this implicitly, but it would be better to have an explicit marker. -Secondly, this prevents having an output which is locked by a script that needs a datum _and_ has a reference script in it. +Secondly, this prevents having an output which is locked by a script that needs a datum _and_ has a reference script in it. While this is a more unusual situation, it's not out of the question. For example, a group of users might want to use a Plutus-based multisig script to control the UTXO with a reference script in it. diff --git a/CIP-0040/README.md b/CIP-0040/README.md index 0ecc7865f..69fd28dbd 100644 --- a/CIP-0040/README.md +++ b/CIP-0040/README.md @@ -2,7 +2,7 @@ CIP: 40 Title: Explicit Collateral Output Authors: Sebastien Guillemot , Jared Corduan , Andre Knispel -Status: Proposed +Status: Active Type: Standards Created: 2022-02-10 License: CC-BY-4.0 @@ -28,7 +28,7 @@ Additionally, there cannot be more than *maxColInputs* (protocol parameter) inpu However, -- Restriction #1 is problematic because hardcore dApp users rarely have UTXO entries that do not contain any tokens. To combat this, wallets have created a special wallet-dependent "collateral" UTXO to reserve for usage of collateral for dApps which is not a great UX. +- Restriction #1 is problematic because hardcore dApp users rarely have UTXO entries that do not contain any tokens. To combat this, wallets have created a special wallet-dependent "collateral" UTXO to reserve for usage of collateral for dApps which is not a great UX. - Restriction #6 is problematic because wallets want to protect users from signing transactions with large collateral as they cannot verify whether or not the transaction will fail when submitted (especially true for hardware wallets) # Specification diff --git a/CIP-0042/README.md b/CIP-0042/README.md index 1a787f8af..05a71b700 100644 --- a/CIP-0042/README.md +++ b/CIP-0042/README.md @@ -1,10 +1,10 @@ --- CIP: 42 Title: New Plutus built-in serialiseData -Authors: Matthias Benkort , Sebastian Nagel +Authors: Matthias Benkort , Sebastian Nagel Discussions-To: https://github.com/cardano-foundation/CIPs/pull/218 Comments-URI: https://github.com/cardano-foundation/CIPs/pull/218 -Status: Proposed +Status: Active Type: Standards Track Created: 2022-02-09 License: Apache-2.0 @@ -20,17 +20,17 @@ This document describes the addition of a new Plutus builtin for serialising `Bu ## Motivation -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. +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. In this particular context, those elements are transaction outputs (a.k.a. `TxOut`). While Plutus already provides built-in for hashing data-structure (e.g. `sha2_256 :: BuiltinByteString -> BuiltinByteString`), it does not provide generic ways of serialising some data type to `BuiltinByteString`. -In an attempt to pursue our work, we have implemented [an on-chain library (plutus-cbor)][plutus-cbor] for encoding data-types as structured [CBOR / RFC 8949][CBOR] in a _relatively efficient_ way (although still quadratic, it is as efficient as it can be with Plutus' available built-ins) and measured the memory and CPU cost of encoding `TxOut` **in a script validator on-chain**. +In an attempt to pursue our work, we have implemented [an on-chain library (plutus-cbor)][plutus-cbor] for encoding data-types as structured [CBOR / RFC 8949][CBOR] in a _relatively efficient_ way (although still quadratic, it is as efficient as it can be with Plutus' available built-ins) and measured the memory and CPU cost of encoding `TxOut` **in a script validator on-chain**. ![](https://i.imgur.com/AtHE0p4.png) The above graph shows the memory and CPU costs **relative against a baseline**, of encoding a `TxOut` using `plutus-cbor` in function of the number of assets present in that `TxOut`. The costs on the y-axis are relative to the maximum execution budgets (as per mainnet's parameters, December 2021) allowed for a single script execution. As can be seen, this is of linear complexity, i.e. O(n) in terms of the number of assets. These results can be reproduced using the [encoding-cost][] executable in our repository. -> Note that we have also calculated similar costs for ada-only `TxOut`, in function of the number of `TxOut` which is about twice as worse but of similar linear shape. +> Note that we have also calculated similar costs for ada-only `TxOut`, in function of the number of `TxOut` which is about twice as worse but of similar linear shape. We we can see on the graph, the cost is manageable for a small number of assets (or equivalently, a small number of outputs) but rapidly becomes limiting. Ideally, we would prefer the transaction size to be the limiting factor when it comes to the number of outputs we can handle in a single validation. @@ -65,7 +65,7 @@ plutus_data = / [ * plutus_data ] / big_int / bounded_bytes - + constr = #6.121([]) / #6.122([a]) @@ -76,7 +76,7 @@ constr = / #6.127([a, a, a, a, a, a]) ; similarly for tag range: #6.1280 .. #6.1400 inclusive / #6.102([uint, [* a]]) - + big_int = int / big_uint / big_nint big_uint = #6.2(bounded_bytes) big_nint = #6.3(bounded_bytes) @@ -95,7 +95,7 @@ The `Data` type is a recursive data-type, so costing it properly is a little tri We propose to re-use this instance to define a cost model linear in the size of data defined by this instance. What remains is to find a proper coefficient and offset for that linear model. To do so, we can benchmark the execution costs of encoding arbitrarily generated `Data` of various sizes, and retro-fit the cost into a linear model (provided that the results are still attesting for that type of model). 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 * Easy to implement as it reuses existing code of the Plutus codebase; @@ -103,10 +103,10 @@ Benchmarking and costing `serialiseData` was done in [this PR](https://github.co * Favoring manipulation of structured `Data` is an appealing alternative to many `ByteString` manipulation use-cases; * CBOR as encoding is a well-known and widely used standard in Cardano, existing tools can be used; * The hypothesis on the cost model here is that serialisation cost would be proportional to the `ExMemoryUsage` for `Data`; which means, given the current implementation, proportional to the number and total memory usage of nodes in the `Data` tree-like structure. -* Benchmarking the costs of serialising `TxOut` values between [plutus-cbor][] and [cborg][] confirms [cborg][] and the existing [encodeData][]'s implementation in Plutus as a great candidate for implementing the built-in: +* Benchmarking the costs of serialising `TxOut` values between [plutus-cbor][] and [cborg][] confirms [cborg][] and the existing [encodeData][]'s implementation in Plutus as a great candidate for implementing the built-in: ![](https://i.imgur.com/6GWrIHb.png) - + Results can be reproduced with the [plutus-cbor benchmark][]. ## Path To Active @@ -124,7 +124,7 @@ Benchmarking and costing `serialiseData` was done in [this PR](https://github.co ## Backward Compatibility -* 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. +* 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. ## Copyright diff --git a/README.md b/README.md index fc6b66b5a..95e9e85dc 100644 --- a/README.md +++ b/README.md @@ -11,13 +11,13 @@ Cardano Improvement Proposals (CIPs) describe standards, processes; or provide g | Obsolete | The CIP was either retired or made obsolete by a newer CIP. | | Rejected | There is some issue with the CIP that makes it not acceptable at this point. | -It is therefore quite common for proposals and implementations to be worked on concomitantly. Even more so that a working implementation (when relevant) is a mandatory condition for reaching an `Active` status. +It is therefore quite common for proposals and implementations to be worked on concomitantly. Even more so that a working implementation (when relevant) is a mandatory condition for reaching an `Active` status. The entire process is described in greater detail in [CIP1 - "CIP Process"](./CIP-0001). -### Reviewed Proposals +### Reviewed Proposals -| # | Title | Status | +| # | Title | Status | | --- | --- | --- | | 1 | [CIP process](./CIP-0001/) | Active | | 2 | [Coin Selection Algorithms for Cardano](./CIP-0002/) | Active | @@ -49,14 +49,15 @@ The entire process is described in greater detail in [CIP1 - "CIP Process"](./CI | 28 | [Protocol Parameters (Alonzo)](./CIP-0028/) | Active | | 29 | [Phase-1 Monetary Scripts Serialization Formats](./CIP-0029/) | Active | | 30 | [Cardano dApp-Wallet Web Bridge](./CIP-0030/) | Draft | -| 31 | [Reference Inputs](./CIP-0031/) | Draft | -| 32 | [Inline Datums](./CIP-0032/) | Draft | -| 33 | [Reference Scripts](./CIP-0033/) | Draft | +| 31 | [Reference Inputs](./CIP-0031/) | Active | +| 32 | [Inline Datums](./CIP-0032/) | Active | +| 33 | [Reference Scripts](./CIP-0033/) | Active | | 34 | [Chain ID Registry](./CIP-0034/) | Draft | | 35 | [Plutus Core Evolution](./CIP-0035) | Active | -| 36 | [Catalyst/Voltaire Registration Transaction Metadata Format](./CIP-0036) | Proposed | -| 40 | [Collateral Output](./CIP-0040) | Proposed | -| 42 | [New Plutus Builtin: serialiseBuiltinData](./CIP-0042) | Proposed | +| 36 | [Catalyst/Voltaire Registration Transaction Metadata Format](./CIP-0036) | Proposed | +| 37 | [Dynamic Saturation Based on Pledge](./CIP-0037) | Proposed | +| 40 | [Collateral Output](./CIP-0040) | Active | +| 42 | [New Plutus Builtin: serialiseBuiltinData](./CIP-0042) | Active | | 52 | [Cardano Audit Best Practice Guidelines](./CIP-0052) | Proposed | | 54 | [Cardano Smart NFTs](./CIP-0054) | Draft | | 55 | [Babbage Era's coinsPerUTxOByte](./CIP-0055) | Proposed | @@ -68,7 +69,7 @@ The entire process is described in greater detail in [CIP1 - "CIP Process"](./CI | 1854 | [Multi-signatures HD Wallets](./CIP-1854/) | Draft | | 1855 | [Forging policy keys for HD Wallets](./CIP-1855/) | Active | -

Last updated on 2022-08-17

+

Last updated on 2022-09-27

> 💡 For more details about Statuses, refer to [CIP1](./CIP-0001). @@ -76,44 +77,46 @@ The entire process is described in greater detail in [CIP1 - "CIP Process"](./CI Below are listed tentative CIPs still under discussion with the community. Discussions and progress will be reviewed by CIP editors in bi-weekly meetings held [on Discord](https://discord.com/channels/971785110770831360/973185848759701504) ([invite](https://discord.gg/qd6jE9Xj)), then transcribed and summarized [here](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings). Note that they are listed below for easing navigation and also tentatively allocating numbers to avoid clashes later on. -| **#** | **Title** | +| **#** | **Title** | | --- | --- | -| 37? | [Dynamic Saturation Based on Pledge](https://github.com/cardano-foundation/CIPs/pull/163) | | 38? | [Arbitrary Script as Native Script Spending Conditions](https://github.com/cardano-foundation/CIPs/pull/309) -| 39? | [Language Annotated Address](https://github.com/cardano-foundation/CIPs/pull/310) | -| 41? | [UPLC Serialization Optimizations](https://github.com/cardano-foundation/CIPs/pull/314/files) | +| 39? | [Language Annotated Address](https://github.com/cardano-foundation/CIPs/pull/310) | +| 41? | [UPLC Serialization Optimizations](https://github.com/cardano-foundation/CIPs/pull/314) | +| 43? | [Address Resolution Through DNS](https://github.com/cardano-foundation/CIPs/pull/319) | | 44? | [Additional Factors For NFT Market Verification](https://github.com/cardano-foundation/CIPs/pull/226) | | 45? | [Decentralization: Using Pledge as a Bidding Param](https://github.com/cardano-foundation/CIPs/pull/229) | | 46? | [Prepay Min Fixed Fee](https://github.com/cardano-foundation/CIPs/pull/190) | +| 47? | [Hardfork Safety Mechanism](https://github.com/cardano-foundation/CIPs/pull/318) | | 48? | [Extended NFT metadata](https://github.com/cardano-foundation/CIPs/pull/249) | | 49? | [ECDSA and Schnorr signatures in Plutus Core](https://github.com/cardano-foundation/CIPs/pull/250) | | 50? | [Shelley's Voltaire Decentralization Update](https://github.com/cardano-foundation/CIPs/pull/242) | | 51? | [Preserve Submitter's Ordering of Transaction Inputs](https://github.com/cardano-foundation/CIPs/pull/231) | -| 53? | [Light Wallet Backend Connection](https://github.com/cardano-foundation/CIPs/pull/254) | | 56? | [Treasury Donation](https://github.com/cardano-foundation/CIPs/pull/269) | | 57? | [On-Chain Script Blueprint](https://github.com/cardano-foundation/CIPs/pull/258) | | 58? | [Plutus Bitwise Primitives](https://github.com/cardano-foundation/CIPs/pull/268) | -| 61? | [Stake-based Protocol Governance Restrictions](https://github.com/cardano-foundation/CIPs/pull/284) | 62? | [Governance API for dApp Connectors](https://github.com/cardano-foundation/CIPs/pull/296) | -| 63? | [Transferring Stake Pool Ownership](https://github.com/cardano-foundation/CIPs/pull/276) | -| 66? | [NFT Identity / W3C DID on Cardano](https://github.com/cardano-foundation/CIPs/pull/294) | +| 63? | [Transferring Stake Pool Ownership](https://github.com/cardano-foundation/CIPs/pull/276) | +| 66? | [NFT Identity / W3C DID on Cardano](https://github.com/cardano-foundation/CIPs/pull/294) | | 67? | [Asset Name Label Registry](https://github.com/cardano-foundation/CIPs/pull/298) | | 68? | [Datum Metadata Standard](https://github.com/cardano-foundation/CIPs/pull/299) | +| 69? | [Plutus Script Type Uniformization](https://github.com/cardano-foundation/CIPs/pull/321/) | +| 70? | [Rejected Ideas w.r.t Spending Policies](https://github.com/cardano-foundation/CIPs/pull/336) | | 989? | [ISPO KYC_CDD](https://github.com/cardano-foundation/CIPs/pull/241) | | 2551? | [Ed25519 Elliptic Curve Group Primitives in Plutus Core](https://github.com/cardano-foundation/CIPs/pull/308) | -

Last updated on 2022-08-17

+

Last updated on 2022-09-27

### Stalled / Waiting For Authors -The following list contains proposals that have been under review and for which actions are now awaiting updates of their original authors. Proposals that have been stalled for several months without any updates from their authors will be eventually closed. Authors are invited to re-open pull requests or open new ones should they want to bring back the discussion to life. +The following list contains proposals that have been under review and for which actions are now awaiting updates of their original authors. Proposals that have been stalled for several months without any updates from their authors will be eventually closed. Authors are invited to re-open pull requests or open new ones should they want to bring back the discussion to life. - [On-Chain Token Metadata Standard](https://github.com/cardano-foundation/CIPs/pull/137) - [Smart Contract Software Licenses](https://github.com/cardano-foundation/CIPs/pull/185) - [collateral rewards](https://github.com/cardano-foundation/cips/pull/217) - [Deep-Link to Desktop Wallet App](https://github.com/cardano-foundation/CIPs/pull/234) +- [Light Wallet Backend Connection](https://github.com/cardano-foundation/CIPs/pull/254) -

Last updated on 2022-08-17

+

Last updated on 2022-09-27

### CIP creation process as a Sequence Diagram