From 04ea19939c5a81e9a8c7049e7626b86f19e3ad89 Mon Sep 17 00:00:00 2001 From: colll78 Date: Thu, 24 Jul 2025 20:16:41 -0700 Subject: [PATCH 01/11] Introduce GuardScripts CIP --- CIP-GuardScripts/README.md | 138 +++++++++++++++++++++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 CIP-GuardScripts/README.md diff --git a/CIP-GuardScripts/README.md b/CIP-GuardScripts/README.md new file mode 100644 index 0000000000..44932e86e8 --- /dev/null +++ b/CIP-GuardScripts/README.md @@ -0,0 +1,138 @@ +--- +CIP: ???? +Title: GuardScriptCredential and Guard Script Purpose +Category: Ledger +Status: Proposed +Authors: + - Philip DiSarro +Implementors: [] +Discussions: + - https://github.com/cardano-foundation/CIPs/pull/??? +Created: 2025-07-24 +License: CC-BY-4.0 +--- + +## Abstract + +This CIP proposes the introduction of a new script credential type, `GuardScriptCredential`, and a corresponding `Guard` script purpose. This enhancement allows a smart contract to validate not only UTxO spends from its address, but also UTxO creations to its address. The lack of such a mechanism today forces developers to implement complex workarounds involving authentication tokens, threaded NFTs, and registry UTxOs to guard against unauthorized or malformed deposits. This CIP aims to provide a native mechanism to guard script addresses against incoming UTxOs, thereby improving protocol safety, reducing engineering overhead, and eliminating a wide class of vulnerabilities in the Cardano smart contract ecosystem. + +## Motivation: why is this CIP necessary? + +In Cardano’s current eUTxO model, smart contracts can enforce logic only when their locked UTxOs are being spent. They have no ability to reject or validate UTxOs being sent to them. This leads to a fundamental weakness: anyone can send arbitrary tokens and datum to a script address, potentially polluting its state or spoofing valid contract UTxOs. To mitigate this, developers today must: + +- Mint authentication tokens +- Use threading tokens to track contract state +- Build registry systems with always-fails scripts +- Validate datums defensively with token-datum context coupling + +These workarounds add significant complexity, on-chain cost, and surface area for bugs. A native mechanism to guard UTxO creations at a script address would eliminate the need for most of these patterns. + +## Specification +We propose: + +1. **A new credential type**: + ```haskell + data Credential = + KeyCredential PubKeyHash + | ScriptCredential ScriptHash + | GuardScriptCredential ScriptHash -- new + ``` +2. **A new ScriptPurpose:** + ```haskell + data ScriptPurpose = + Spending TxOutRef + | Minting CurrencySymbol + | Certifying DCert + | Rewarding StakingCredential + | Voting Vote + | Proposing Proposal + | Guarding ScriptHash Integer (Maybe Integer) -- new + ``` + +**Guard validation rule:** +During phase-2 script validation, for each transaction output to a `GuardScriptCredential`, the associated script must be executed using the `Guarding` purpose, where `ScriptHash` is the hash of the guarding script and the first `Integer` is the index of the output sent to the guarding script that is being validated, the `Maybe Integer` an optional type that may contain the index of an input from the same script. There is one important exception to this rule, if the `Maybe Integer` argument is `Just idx` and the credential of the input at index `idx` in the transaction inputs set corresponds to the `GuardScriptCredential` associated with the Guarding script then the script succeeds by default and does not need to be executed. This rule is very important to avoid redundant scirpt executions, as if the script is already invoked with a `Spending` purpose then it can already reject unauthorized `UTxOs. Without this rule, the same script would need to be evaluated twice for all state transitions with continuing outputs (extremely common) and this would simply be too inefficient for production use. + +If any `Guarding` script **fails** during evaluation, the **entire transaction is invalid** and is rejected during phase-2 validation. + +### CDDL Extension + +```cddl +; Extend Credential with GuardScriptCredential +credential = + [ 0, addr_keyhash ; KeyCredential + // 1, script_hash ; ScriptCredential + // 2, script_hash ; GuardScriptCredential (NEW) + ] + +; Extend ScriptPurpose with Guarding +redeemer_tag = + 0 ; spend + / 1 ; mint + / 2 ; cert + / 3 ; reward + / 4 ; voting + / 5 ; proposing + / 6 ; guarding ; NEW: script validates output creation to GuardScriptCredential +``` + +## Rationale: how does this CIP achieve its goals? + +The proposed `GuardScriptCredential` and `Guard` script purpose solve the long-standing problem of uncontrolled UTxO injection at script addresses. By giving smart contracts the ability to validate outputs being sent to them during phase-2 validation, developers can: + +- Ensure only valid state transitions or authenticated deposits are accepted +- Enforce access control and structural correctness of datums before a UTxO is created +- Remove the need for workaround patterns such as: + - Authentication tokens + - Threading/state tokens + - The issues from cyclic depenencies that are inherent in both of the above. + +This CIP is also forward-compatible and additive. Existing contracts using `ScriptCredential` remain unaffected. Contracts that require guarded output validation may opt-in by using `GuardScriptCredential`. + +### Alternatives considered + +- **Status quo**: Relying on auth tokens, thread tokens, and registry patterns introduces complexity, performance bottlenecks, and cyclic dependencies that are fragile and hard to audit. It has also led to serious exploits in real-world protocols due to misused or mishandled tokens. + +- **Off-chain filtering**: While indexers and DApp backends can attempt to filter out junk UTxOs, they provide no on-chain security and cannot be relied on in adversarial environments or in composable settings. + +- **Multivalidator pattern**: While technically feasible, this couples minting and spending logic into a single script, constrained by the 16KB script size limit. Furthermore, this introduces a huge layer of complexity and an associated attack surface. Managing the lifecycle of minted state tokens to prevent smuggling is extremely difficult, and becomes more impractical as the complexity of the dApp increases (ie. The attack surface for state token smuggling in a protocol that has 12 different validator scripts is nearly impossible to secure). In practice, this constraints the realm of what types of dApps are feasible on Cardano, you cannot build a cutting-edge financial instrument like AAVE, Balancer, or MakerDAO on Cardano because managing the lifecycle of dozens of state tokens across dozens of scripts while preventing smuggling is infeasible. + +### Backward Compatibility + +This proposal can be **fully backward-compatible** with previous Plutus versions. There are no obvious issues with this. However, for extra-safety and to avoid any +unintended consequences, it is also possible to strictly disallow Guarding scripts to be present in transactions that also execute scripts from Plutus versions before they +are introduced. + +Wallets, nodes, and off-chain tooling must be updated to: +- Recognize and encode/decode `GuardScriptCredential` addresses +- Include `Guarding` redeemers in transactions with guarded outputs +- Extend phase-2 validation to evaluate `Guarding` scripts +- Address decoding/encoding that correctly identifies the new credential + +Node software, CLI, Plutus libraries, and serialization tooling (e.g., `cardano-api`, `cardano-ledger`, `plutus-ledger-api`) would require coordinated upgrades. + + +### Acceptance Criteria + +- Agreement from Cardano Ledger and Plutus teams +- Implementation of: + - `GuardScriptCredential` in address serialization + - `Guarding` in ledger script validation rules and Plutus interpreter + - Phase-2 validation for guarded outputs +- Inclusion in a future era upgrade (e.g., Voltaire or beyond) + +### Implementation Plan + +1. Extend ledger types to include `GuardScriptCredential` and `Guarding ScriptPurpose`. +2. Modify transaction validation logic to detect guarded outputs and invoke appropriate scripts. +3. Add redeemer indexing logic for `Guarding` purposes tied to `txOutputs`. +4. Introduce CDDL changes for redeemer tags and address credential variants. +5. Update transaction witnesses, CLI tooling, and Plutus interpreter to support `Guarding`. +6. Provide test cases for: + - Correct execution of `Guarding` scripts + - Optimized bypass logic when corresponding inputs exist + - Rejection of invalid guarded outputs +7. Provide examples and documentation for contract authors. + +## Copyright + +This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). From bad470f58586571db90e232a1326e0b25d1a1963 Mon Sep 17 00:00:00 2001 From: colll78 Date: Fri, 25 Jul 2025 20:47:00 -0700 Subject: [PATCH 02/11] Update CIP-GuardScripts/README.md Co-authored-by: Robert Phair --- CIP-GuardScripts/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-GuardScripts/README.md b/CIP-GuardScripts/README.md index 44932e86e8..83e3ffdbb6 100644 --- a/CIP-GuardScripts/README.md +++ b/CIP-GuardScripts/README.md @@ -1,6 +1,6 @@ --- CIP: ???? -Title: GuardScriptCredential and Guard Script Purpose +Title: Guard Script Purpose and Credential Category: Ledger Status: Proposed Authors: From 14b9ae63557569feec4ee4cb1e5202158226415b Mon Sep 17 00:00:00 2001 From: colll78 Date: Fri, 25 Jul 2025 21:04:00 -0700 Subject: [PATCH 03/11] Update README.md --- CIP-GuardScripts/README.md | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/CIP-GuardScripts/README.md b/CIP-GuardScripts/README.md index 83e3ffdbb6..aaf8cb809a 100644 --- a/CIP-GuardScripts/README.md +++ b/CIP-GuardScripts/README.md @@ -37,7 +37,7 @@ We propose: | ScriptCredential ScriptHash | GuardScriptCredential ScriptHash -- new ``` -2. **A new ScriptPurpose:** +2. **Two new `ScriptPurpose`s:** ```haskell data ScriptPurpose = Spending TxOutRef @@ -46,13 +46,21 @@ We propose: | Rewarding StakingCredential | Voting Vote | Proposing Proposal - | Guarding ScriptHash Integer (Maybe Integer) -- new + | Guarding ScriptHash -- NEW: only output(s) to script + | GuardingContinuing ScriptHash -- NEW: both input(s) and output(s) ``` **Guard validation rule:** -During phase-2 script validation, for each transaction output to a `GuardScriptCredential`, the associated script must be executed using the `Guarding` purpose, where `ScriptHash` is the hash of the guarding script and the first `Integer` is the index of the output sent to the guarding script that is being validated, the `Maybe Integer` an optional type that may contain the index of an input from the same script. There is one important exception to this rule, if the `Maybe Integer` argument is `Just idx` and the credential of the input at index `idx` in the transaction inputs set corresponds to the `GuardScriptCredential` associated with the Guarding script then the script succeeds by default and does not need to be executed. This rule is very important to avoid redundant scirpt executions, as if the script is already invoked with a `Spending` purpose then it can already reject unauthorized `UTxOs. Without this rule, the same script would need to be evaluated twice for all state transitions with continuing outputs (extremely common) and this would simply be too inefficient for production use. +During phase-2 script validation, for each transaction output to a `GuardScriptCredential`, the associated script must be executed using one of two new script purposes: -If any `Guarding` script **fails** during evaluation, the **entire transaction is invalid** and is rejected during phase-2 validation. +- `Guarding` is used when the transaction includes one or more outputs to the script, but no inputs from it. +- `GuardingContinuing` is used when the transaction includes both inputs and outputs involving the same `GuardScriptCredential`. + +This separation ensures that input-side and output-side logic can remain cleanly isolated. Output validation logic can be entirely handled within `Guarding` and `GuardingContinuing`, while spending logic can be isolated to the `Spending` script purpose. + +Critically, this design avoids redundant script execution. Without it, spending scripts would need to inspect transaction outputs in every case — even when no guarding logic is necessary — leading to wasted validation effort and bloated execution budgets. + +If any `Guarding` or `GuardingContinuing` script **fails** during evaluation, the **entire transaction is invalid** and is rejected during phase-2 validation. ### CDDL Extension @@ -116,20 +124,20 @@ Node software, CLI, Plutus libraries, and serialization tooling (e.g., `cardano- - Agreement from Cardano Ledger and Plutus teams - Implementation of: - `GuardScriptCredential` in address serialization - - `Guarding` in ledger script validation rules and Plutus interpreter + - `Guarding` in ledger script validation rules + - `Guarding` and `GuardingContinuing` in Plutus - Phase-2 validation for guarded outputs - Inclusion in a future era upgrade (e.g., Voltaire or beyond) ### Implementation Plan -1. Extend ledger types to include `GuardScriptCredential` and `Guarding ScriptPurpose`. +1. Extend ledger types to introduce the `GuardingScriptCredential` type. 2. Modify transaction validation logic to detect guarded outputs and invoke appropriate scripts. 3. Add redeemer indexing logic for `Guarding` purposes tied to `txOutputs`. 4. Introduce CDDL changes for redeemer tags and address credential variants. 5. Update transaction witnesses, CLI tooling, and Plutus interpreter to support `Guarding`. 6. Provide test cases for: - Correct execution of `Guarding` scripts - - Optimized bypass logic when corresponding inputs exist - Rejection of invalid guarded outputs 7. Provide examples and documentation for contract authors. From e760d5b57f8d638593315c681e5928d293920ac7 Mon Sep 17 00:00:00 2001 From: colll78 Date: Tue, 19 Aug 2025 12:47:58 -0700 Subject: [PATCH 04/11] Update CIP-GuardScripts/README.md Co-authored-by: Ryan --- CIP-GuardScripts/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-GuardScripts/README.md b/CIP-GuardScripts/README.md index aaf8cb809a..dc44451e5f 100644 --- a/CIP-GuardScripts/README.md +++ b/CIP-GuardScripts/README.md @@ -7,7 +7,7 @@ Authors: - Philip DiSarro Implementors: [] Discussions: - - https://github.com/cardano-foundation/CIPs/pull/??? + - https://github.com/cardano-foundation/CIPs/pull/1063 Created: 2025-07-24 License: CC-BY-4.0 --- From 2de3429d88c34b5fe683d181ee93a58e7b1280fe Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Wed, 20 Aug 2025 16:42:05 +0545 Subject: [PATCH 05/11] assign CIP number 160 --- CIP-GuardScripts/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-GuardScripts/README.md b/CIP-GuardScripts/README.md index dc44451e5f..5f024b45ad 100644 --- a/CIP-GuardScripts/README.md +++ b/CIP-GuardScripts/README.md @@ -1,5 +1,5 @@ --- -CIP: ???? +CIP: 160 Title: Guard Script Purpose and Credential Category: Ledger Status: Proposed From 9e46834e65846d95317f1bf2f045f29624bb6408 Mon Sep 17 00:00:00 2001 From: colll78 Date: Fri, 3 Oct 2025 18:31:48 -0700 Subject: [PATCH 06/11] Update with respect to ledger team feedback Update to replace `GuardingCredential` (a new credential type) with `ProtectedAddress` (a new address type), and replace `Guarding` script purpose with `Receiving` script purpose. --- CIP-GuardScripts/README.md | 92 +++++++++++++++++++------------------- 1 file changed, 45 insertions(+), 47 deletions(-) diff --git a/CIP-GuardScripts/README.md b/CIP-GuardScripts/README.md index 5f024b45ad..516a61fe97 100644 --- a/CIP-GuardScripts/README.md +++ b/CIP-GuardScripts/README.md @@ -1,6 +1,6 @@ --- CIP: 160 -Title: Guard Script Purpose and Credential +Title: Receiving Script Purpose and Addresses Category: Ledger Status: Proposed Authors: @@ -14,7 +14,7 @@ License: CC-BY-4.0 ## Abstract -This CIP proposes the introduction of a new script credential type, `GuardScriptCredential`, and a corresponding `Guard` script purpose. This enhancement allows a smart contract to validate not only UTxO spends from its address, but also UTxO creations to its address. The lack of such a mechanism today forces developers to implement complex workarounds involving authentication tokens, threaded NFTs, and registry UTxOs to guard against unauthorized or malformed deposits. This CIP aims to provide a native mechanism to guard script addresses against incoming UTxOs, thereby improving protocol safety, reducing engineering overhead, and eliminating a wide class of vulnerabilities in the Cardano smart contract ecosystem. +This CIP proposes the introduction of a new Address type, `ProtectedAddress`, and a corresponding `Receiving` script purpose. This enhancement allows a smart contract to validate not only UTxO spends from its address, but also UTxO creations to its address. The lack of such a mechanism today forces developers to implement complex workarounds involving authentication tokens, threaded NFTs, and registry UTxOs to guard against unauthorized or malformed deposits. This CIP aims to provide a native mechanism to guard script addresses against incoming UTxOs, thereby improving protocol safety, reducing engineering overhead, and eliminating a wide class of vulnerabilities in the Cardano smart contract ecosystem. ## Motivation: why is this CIP necessary? @@ -30,14 +30,22 @@ These workarounds add significant complexity, on-chain cost, and surface area fo ## Specification We propose: -1. **A new credential type**: +1. **A new address type**: ```haskell - data Credential = - KeyCredential PubKeyHash - | ScriptCredential ScriptHash - | GuardScriptCredential ScriptHash -- new +data Address = + Address + { addressCredential :: Credential + -- ^ the payment credential + , addressStakingCredential :: Maybe StakingCredential + -- ^ the staking credential + } + ProtectedAddress -- new + { address :: Credential + , addressStakingCredential :: Maybe StakingCredential + } + ``` -2. **Two new `ScriptPurpose`s:** +2. **A new `ScriptPurpose`:** ```haskell data ScriptPurpose = Spending TxOutRef @@ -46,33 +54,26 @@ We propose: | Rewarding StakingCredential | Voting Vote | Proposing Proposal - | Guarding ScriptHash -- NEW: only output(s) to script - | GuardingContinuing ScriptHash -- NEW: both input(s) and output(s) + | Receiving ScriptHash -- NEW: only output(s) to script ``` -**Guard validation rule:** -During phase-2 script validation, for each transaction output to a `GuardScriptCredential`, the associated script must be executed using one of two new script purposes: +Normal addresses and protected addresses are differentiated by the introduction of an `isProtected` bit in the address header bytes, if the bit is set then the address is a protected address, otherwise it is unprotected. + +**Receiving validation rule:** -- `Guarding` is used when the transaction includes one or more outputs to the script, but no inputs from it. -- `GuardingContinuing` is used when the transaction includes both inputs and outputs involving the same `GuardScriptCredential`. +Any output to a protected address requires the witness for the payment credential of that address to be provided in the transaction. For outputs to protected addresses with public key payment credentials this means the transaction must be signed +by the owner of that public key. For outputs to protected addresses with plutus script payment credentials this means the associated plutus script must be executed in phase-2 validation. -This separation ensures that input-side and output-side logic can remain cleanly isolated. Output validation logic can be entirely handled within `Guarding` and `GuardingContinuing`, while spending logic can be isolated to the `Spending` script purpose. +During phase-2 script validation, for each transaction output to a `ProtectedAddress`, with a script payment credential the associated script must be executed using the script purpose: -Critically, this design avoids redundant script execution. Without it, spending scripts would need to inspect transaction outputs in every case — even when no guarding logic is necessary — leading to wasted validation effort and bloated execution budgets. +- `Receiving` is used when the transaction includes an output to a `ProtectedAddress` where the payment credential is a script. -If any `Guarding` or `GuardingContinuing` script **fails** during evaluation, the **entire transaction is invalid** and is rejected during phase-2 validation. +If any `Receiving` script **fails** during evaluation, the **entire transaction is invalid** and is rejected during phase-2 validation. ### CDDL Extension ```cddl -; Extend Credential with GuardScriptCredential -credential = - [ 0, addr_keyhash ; KeyCredential - // 1, script_hash ; ScriptCredential - // 2, script_hash ; GuardScriptCredential (NEW) - ] - -; Extend ScriptPurpose with Guarding +; Extend ScriptPurpose with Receiving redeemer_tag = 0 ; spend / 1 ; mint @@ -80,12 +81,12 @@ redeemer_tag = / 3 ; reward / 4 ; voting / 5 ; proposing - / 6 ; guarding ; NEW: script validates output creation to GuardScriptCredential + / 6 ; receiving ; NEW: script validates output creation to a ProtectedAddress ``` ## Rationale: how does this CIP achieve its goals? -The proposed `GuardScriptCredential` and `Guard` script purpose solve the long-standing problem of uncontrolled UTxO injection at script addresses. By giving smart contracts the ability to validate outputs being sent to them during phase-2 validation, developers can: +The proposed `ProtectedAddress` and `Receiving` script purpose solve the long-standing problem of uncontrolled UTxO injection at script addresses. By giving smart contracts the ability to validate outputs being sent to them during phase-2 validation, developers can: - Ensure only valid state transitions or authenticated deposits are accepted - Enforce access control and structural correctness of datums before a UTxO is created @@ -94,7 +95,7 @@ The proposed `GuardScriptCredential` and `Guard` script purpose solve the long-s - Threading/state tokens - The issues from cyclic depenencies that are inherent in both of the above. -This CIP is also forward-compatible and additive. Existing contracts using `ScriptCredential` remain unaffected. Contracts that require guarded output validation may opt-in by using `GuardScriptCredential`. +This CIP is also forward-compatible and additive. Existing contracts using unprotected `Address` remain unaffected. Contracts that require guarded output validation may opt-in by using `GuardScriptCredential`. ### Alternatives considered @@ -107,39 +108,36 @@ This CIP is also forward-compatible and additive. Existing contracts using `Scri ### Backward Compatibility This proposal can be **fully backward-compatible** with previous Plutus versions. There are no obvious issues with this. However, for extra-safety and to avoid any -unintended consequences, it is also possible to strictly disallow Guarding scripts to be present in transactions that also execute scripts from Plutus versions before they +unintended consequences, it is also possible to strictly disallow Receiving scripts to be present in transactions that also execute scripts from Plutus versions before they are introduced. Wallets, nodes, and off-chain tooling must be updated to: -- Recognize and encode/decode `GuardScriptCredential` addresses -- Include `Guarding` redeemers in transactions with guarded outputs -- Extend phase-2 validation to evaluate `Guarding` scripts -- Address decoding/encoding that correctly identifies the new credential +- Recognize and encode/decode `ProtectedAddress` addresses +- Include `Receiving` redeemers in transactions with outputs to `ProtectedAddress`s +- Extend phase-2 validation to evaluate `Receiving` scripts Node software, CLI, Plutus libraries, and serialization tooling (e.g., `cardano-api`, `cardano-ledger`, `plutus-ledger-api`) would require coordinated upgrades. - ### Acceptance Criteria - Agreement from Cardano Ledger and Plutus teams - Implementation of: - - `GuardScriptCredential` in address serialization - - `Guarding` in ledger script validation rules - - `Guarding` and `GuardingContinuing` in Plutus - - Phase-2 validation for guarded outputs + - `ProtectedAddress` in address serialization + - `Receiving` in ledger script validation rules + - `Receiving` in Plutus + - Phase-2 validation for transactions with outputs to protected addresses - Inclusion in a future era upgrade (e.g., Voltaire or beyond) ### Implementation Plan -1. Extend ledger types to introduce the `GuardingScriptCredential` type. -2. Modify transaction validation logic to detect guarded outputs and invoke appropriate scripts. -3. Add redeemer indexing logic for `Guarding` purposes tied to `txOutputs`. -4. Introduce CDDL changes for redeemer tags and address credential variants. -5. Update transaction witnesses, CLI tooling, and Plutus interpreter to support `Guarding`. -6. Provide test cases for: - - Correct execution of `Guarding` scripts - - Rejection of invalid guarded outputs -7. Provide examples and documentation for contract authors. +1. Extend ledger types to introduce the `ProtectedAddress` type. +2. Modify transaction validation logic to detect outputs to protected addresses and invoke appropriate scripts. +3. Introduce CDDL changes for redeemer tags and the new address variant. +4. Update transaction witnesses, CLI tooling, and Plutus interpreter to support `Receiving`. +5. Provide test cases for: + - Correct execution of `Receiving` scripts + - Rejection of transactions that include outputs to protected addresses and do not have the required witnesses or where the associated `Receiving` script execution fails. +6. Provide examples and documentation for contract authors. ## Copyright From e365b003c017740620b0b175e150a38848eb6bee Mon Sep 17 00:00:00 2001 From: colll78 Date: Wed, 5 Nov 2025 12:02:48 -0800 Subject: [PATCH 07/11] Update CIP-GuardScripts/README.md Co-authored-by: Robert Phair --- CIP-GuardScripts/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-GuardScripts/README.md b/CIP-GuardScripts/README.md index 516a61fe97..ea38a6b2ba 100644 --- a/CIP-GuardScripts/README.md +++ b/CIP-GuardScripts/README.md @@ -59,7 +59,7 @@ data Address = Normal addresses and protected addresses are differentiated by the introduction of an `isProtected` bit in the address header bytes, if the bit is set then the address is a protected address, otherwise it is unprotected. -**Receiving validation rule:** +### Receiving validation rule Any output to a protected address requires the witness for the payment credential of that address to be provided in the transaction. For outputs to protected addresses with public key payment credentials this means the transaction must be signed by the owner of that public key. For outputs to protected addresses with plutus script payment credentials this means the associated plutus script must be executed in phase-2 validation. From 55830fa0518729c3135598d4ac58e751e6cb4006 Mon Sep 17 00:00:00 2001 From: colll78 Date: Wed, 5 Nov 2025 12:03:02 -0800 Subject: [PATCH 08/11] Update CIP-GuardScripts/README.md Co-authored-by: Robert Phair --- CIP-GuardScripts/README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CIP-GuardScripts/README.md b/CIP-GuardScripts/README.md index ea38a6b2ba..89bcd0361f 100644 --- a/CIP-GuardScripts/README.md +++ b/CIP-GuardScripts/README.md @@ -118,6 +118,8 @@ Wallets, nodes, and off-chain tooling must be updated to: Node software, CLI, Plutus libraries, and serialization tooling (e.g., `cardano-api`, `cardano-ledger`, `plutus-ledger-api`) would require coordinated upgrades. +## Path to Active + ### Acceptance Criteria - Agreement from Cardano Ledger and Plutus teams From d41ac8c6b436bb8397558f549825592ee76be17b Mon Sep 17 00:00:00 2001 From: colll78 Date: Tue, 25 Nov 2025 15:11:08 -0800 Subject: [PATCH 09/11] Rename directory to CIP-0160 --- {CIP-GuardScripts => CIP-0160}/README.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename {CIP-GuardScripts => CIP-0160}/README.md (100%) diff --git a/CIP-GuardScripts/README.md b/CIP-0160/README.md similarity index 100% rename from CIP-GuardScripts/README.md rename to CIP-0160/README.md From 683d6808c0c8588111b2690f472f7fff6847f7d4 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Sun, 7 Dec 2025 17:20:07 -0500 Subject: [PATCH 10/11] attempting to fix list-code collision while fixing indented code block (1 of 2) --- CIP-0160/README.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/CIP-0160/README.md b/CIP-0160/README.md index 89bcd0361f..5aedb6763f 100644 --- a/CIP-0160/README.md +++ b/CIP-0160/README.md @@ -31,20 +31,20 @@ These workarounds add significant complexity, on-chain cost, and surface area fo We propose: 1. **A new address type**: - ```haskell -data Address = - Address - { addressCredential :: Credential - -- ^ the payment credential - , addressStakingCredential :: Maybe StakingCredential - -- ^ the staking credential - } - ProtectedAddress -- new - { address :: Credential - , addressStakingCredential :: Maybe StakingCredential - } - ``` + ```haskell + data Address = + Address + { addressCredential :: Credential + -- ^ the payment credential + , addressStakingCredential :: Maybe StakingCredential + -- ^ the staking credential + } + ProtectedAddress -- new + { address :: Credential + , addressStakingCredential :: Maybe StakingCredential + } + ``` 2. **A new `ScriptPurpose`:** ```haskell data ScriptPurpose = From a8e415e85e443f22ce92c53053b553121c2a20a7 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Sun, 7 Dec 2025 17:20:33 -0500 Subject: [PATCH 11/11] attempting to fix list-code collision while preserving indented code block (2 of 2) --- CIP-0160/README.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/CIP-0160/README.md b/CIP-0160/README.md index 5aedb6763f..58df12528a 100644 --- a/CIP-0160/README.md +++ b/CIP-0160/README.md @@ -45,8 +45,10 @@ We propose: , addressStakingCredential :: Maybe StakingCredential } ``` + 2. **A new `ScriptPurpose`:** - ```haskell + + ```haskell data ScriptPurpose = Spending TxOutRef | Minting CurrencySymbol @@ -55,7 +57,7 @@ We propose: | Voting Vote | Proposing Proposal | Receiving ScriptHash -- NEW: only output(s) to script - ``` + ``` Normal addresses and protected addresses are differentiated by the introduction of an `isProtected` bit in the address header bytes, if the bit is set then the address is a protected address, otherwise it is unprotected.