In Cardano, the on-chain part of (pretty much) any smart contract is a validation script that has its own address (the script’s hash). So, currently, to use any smart contract on Cardano, a user has to deposit tokens to the script address, thereby giving up custody of these tokens.
Problems
- The user loses control of the funds they send out to a smart-contract,
- unless the smart contract is specifically designed to allow for such control (e.g. giving a “Cancel trade” button in the UI).
- Users depositing their funds into smart contracts may subject the smart contract authors/maintainers to regulations similar to those for credit organizations.
- Funds sent out from a user’s wallet are no longer delegated to the stake pool of the user’s choice.
- unless the smart contract is specifically designed to provide this functionality (I haven’t seen any such apps yet).
- Any UTxO accidentally sent to a script address without a datum is effectively lost now (because of how transaction validation scripts currently work).
Proposal
A solution is to introduce Non-Custodial Smart Contracts: instead of depositing into a script address, a user could commit a UTxO to a script. This would be done by adding a new field to UTxO (the current spec is here: cardano-ledger/babbage.cddl at master · input-output-hk/cardano-ledger · GitHub):
post_alonzo_transaction_output =
{ 0 : address
, 1 : value
, ? 2 : datum_option
, ? 3 : script_ref
, ? 4 : { * scripthash => datum_option } ; New; non-custodial validation scripts
}
The new field is a mapping from script hash to datum. Non-custodial validation scripts are the same Plutus scripts as before (v1 or v2, working just as they currently do). The “non-custodial” part simply means that the UTxO is not located at the script address.
Such UTxO can be spent by a transaction that is validated by:
-
either using the validation mechanism for its address (e.g. signed by the wallet address’ private key)
-
or successful execution of a non-custodial validation script (using the corresponding datum). The spending transaction will include the script it intends to use, either in its witness set or in a reference input.
Benefits
- The user can keep custody of their assets, even if, at the same time, these assets are committed to an order on a DEX.
- If the user decides, there is a better use for these funds elsewhere, they can simply sign a transaction to do just that.
- A single UTxO can be overcommitted: committed to multiple smart-contracts. The first one to spend it wins.
- The funds, still being in the user’s wallet, still generate staking rewards for the user!
- Funds simply cannot be locked forever in non-custodial smart-contracts, by definition.
11 Likes
I figure (with, perhaps, a wee bit of wishful thinking) people are liking this so far, so here’s a draft for the CIP (basically the same as this original post now): CIP: Non-Custodial Smart-Contracts - HackMD
I’ll be working on it there. Any feedback (especially if it seems obvious to you) is WELCOME!
1 Like
thanks @imikushin - I do agree it has potential & think it’s helpful that you’ve made it open for commenting on HackMD. If & when you have the idea developed enough to post it as a CIP on GitHub please notify us here 
5 Likes
@COSDpool I think the CIP draft is ready to be sent as a PR to GitHub.
I’d like to name it CIP-1775: Delegated Spending Authorizations if folks don’t object (open to other suggestions, but prefer this name now).
1 Like
I really like where you are aiming with this but I don’t understand the design space technicalities enough to roll up my sleeves and help.
I am trying to understand how your idea will affect the concept of settlement finality when considering tokens as bearer assets.
Q: Would it be possible for someone to attach what amounts to a clawback (as a delegated spending authorisation) to a UTxO that the recipient then has in their wallet? And what problems could this unearth?
In the example of a swap between two users where each user attaches a clawback authorisation, both have to sign the transaction and therefore need to agree each others clawback authorisation. Say they did this and signed the transaction but one user then quickly moved their tokens to another UTxO to remove the clawback then this would leave the other user unilaterally exposed to their clawback. This seems to set up a potential race condition. Consider that in this scenario one user could be a smart contract.
I guess the answer is to not sign transactions that have an attached delegated spending authorisation on the output intended for yourself. This would necessitate users checking what they are signing in detail to be certain about the conditions that an attached delegated spending authorisation can operate under.
Would this make checking smart contract transactions prior to signing more difficult for users?
1 Like
Thank you for looking at the CIP draft @Terminada! I really appreciate the feedback.
Q: Would it be possible for someone to attach what amounts to a clawback (as a delegated spending authorisation) to a UTxO that the recipient then has in their wallet? And what problems could this unearth?
Yes, with this design it is definitely possible. This is why I note in the CIP draft, that it is important for wallets to highlight this in their UI. Users should be warned when:
- they are about to sign a transaction resulting in UTXOs with delegated spending authorizations in their wallets,
- have UTXOs with delegated spending authorizations attached (perhaps, having received them from a dapp or a sidechain).
In the example of a swap between two users where each user attaches a clawback authorisation, both have to sign the transaction and therefore need to agree each others clawback authorisation.
Probably best not to participate in such transactions, unless for entertainment purposes only and fully prepared to lose the tokens.
Say they did this and signed the transaction but one user then quickly moved their tokens to another UTxO to remove the clawback then this would leave the other user unilaterally exposed to their clawback. This seems to set up a potential race condition. Consider that in this scenario one user could be a smart contract.
Can totally happen.
I guess the answer is to not sign transactions that have an attached delegated spending authorisation on the output intended for yourself. This would necessitate users checking what they are signing in detail to be certain about the conditions that an attached delegated spending authorisation can operate under.
Would this make checking smart contract transactions prior to signing more difficult for users?
I would say: generally, don’t sign such transactions, unless you know what you’re doing or have absolute trust in the entity you are authorizing to manage your tokens. The same applies now when you’re sending tokens out of your wallet, e.g. you’re sending an order to a DEX.
1 Like