CIP-0069 | single argument Scripts #774
Conversation
|
|
||
| - Use Case 3: Allow dApp protocols to have a claim or withdraw mechanism (similar to Ethereum for tokens sent to a contract without call) for claiming tokens sent without a datum. | ||
|
|
||
| I'd be remiss if I didn't mention CIP-0112 which has been expanded to improve native script capabilities to provide an alternative solution for use case 1 and 2. But for use case 3, CIP-0112 does not enable a "claim or withdraw mechanism" for contracts. |
| @@ -30,10 +32,24 @@ As it stands the scripts being made on cardano often suffer this problem, and th | |||
|
|
|||
| - Use Case 3 (taken from Minswap's Dex V1): NFT is minted for the same reason as above. It allows a minting policy to later mint LP tokens with that unique id token name. | |||
|
|
|||
| We see a similar pattern repeating over and over again as witnessed by dapp developers and auditors alike. By allowing the multi-purpose policies (spending and any other) we increase the security of Cardano by giving us more confidence and allowing to design protocols that have their architecture driven by Cardano's features, not limited by Cardano's language. | |||
| We see a similar pattern repeating over and over again as witnessed by dapp developers and auditors alike. By allowing the multi-purpose scripts (spending and any other) we increase the security of Cardano by giving us more confidence and allowing to design protocols that have their architecture driven by Cardano's features, not limited by Cardano's language. | |||
There was a problem hiding this comment.
Soley this reason is enough justification for this CIP. As in the case of the withdraw-zero trick and CIP 112, it is simply not healthy for the most critical and widely used design patterns throughout the ecosystem to rely on what is essentially an obscure implementation detail / black magic trick. Given the importance of this design pattern, and its demonstrable utility (on mainnet across a huge number of protocols in the ecosystem in production) it is of great importance that this is granted more official support and formalization.
There was a problem hiding this comment.
I would, however, remove the part about the "recent Nami bug" since AFAIK CIP are supposed to be timeless and this might lose context in the future. Maybe replace with a brief line about how a bug in nami caused UTxOs without datums to be sent to a script and thus mistakenly locked forever.
rphair
changed the title
|
@MicroProofs I've added this to today's CIP editors' meeting agenda (https://hackmd.io/@cip-editors/83) with a note to also introduce #769. As always it would be great if you can come & explain what these are & how the issue & solution are related. |
rphair
added
the
Update
MicroProofs
changed the title
Not sure if we should discuss here or in #769
The goal is to add additional clarity to this CIP or determine if another CIP is better suited to 2 major use cases