CIP-0040? | Collateral output

CollateralOutput/README.md

@@ -0,0 +1,60 @@
+---
+CIP: ?
+Title: Explicit Collateral Output
+Authors: Sebastien Guillemot <seba@dcspark.io>
+Status: Draft
+Type: Standards
+Created: 2022-02-10
+License: CC-BY-4.0
+---
+
+# Abstract
+
+This document describes adding a new output type to transactions called Collateral Outputs
+
+# Motivation
+
+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:
+
+1. Cannot contain any tokens (only ADA)
+2. Cannot be a script address
+3. Must be a UTXO input
+4. Must be at least some percentage of the fee in the tx (concrete percentage decided by a protocol parameter)
+5. Can be the same UTXO entry as used in non-collateral tx input
+6. Is consumed entirely (no change) if the contract execution fails during phase 2 validation
+7. Is not consumed if phase phase 2 validation succeeds
+
+Additionally, there cannot be more than *maxColInputs* (protocol parameter) inputs and the inputs have to cover a percentage of the fee defined by *collateralPercent* (protocol parameter)
+
+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 #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
+
+If phrase-2 verification fails, we can send outputs to a special output marked as the collateral output.
+
+There are two ways to create collateral outputs
+
+1. Add collateral outputs as a new field inside the transaction. This change is similar to how collateral inputs were created a new field
+2. Change the definition of outputs as `TxOut = Addr × Value × DataHash? × Source?` where source (optional for backwards compatibility) is an enum `0 = regular output, 1 = collateral output`.
+
+Option #1 provides the best backwards compatibility because we don't expect phase-2 validation to be a common occurrence and so wallets that (due to not being updated) never check collateral outputs will still in the overwhelming majority of cases return the correct result.
+
+Additionally, this requires updating the collateral requirement.
+
+If no collateral output is specified (and therefore no tokens are in the collateral input), then we keep the old definition
+
+```
+ubalance (collateral txb ◁ utxo) ≥ quot (txfee txb * (collateralPercent pp)) 100
+```
+
+However, if collateral output is specified, then
+1. Each collateral output needs to satisfy the same minimum ADA requirement as regular outputs
+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.
+
+## Copyright
+
+This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)