Developers’ Corner: Solving Cardano’s Collateral Problem

The Cardano blockchain launched its smart contract capabilities on Sept 13th, 2021. However, this release also came with a caveat that most people were not aware of: collateral.

Why does Cardano’s smart contract implementation require collateral?

Just like Ethereum, it’s possible to submit a transaction in Cardano that fails. However, Cardano provides additional protection to users by having two types of failure

1. Phase-1 failure: these are meant to cover any common failure that could both reasonably occur and that are computationally easy to check for. For example, maybe the user tried to send more ADA than they have. Since these are computationally easy to check, phase-1 validation failure means your transaction will never be included in a block
2. Phase-2 failure: your transactions is entirely valid, but a smart contract inside the transaction failed. Since smart contracts, in general, can be computationally complex, transactions that fail during phase-2 validation WILL appear on-chain and users WILL lose ADA if this happens to them (similar to how posting a failed transaction to Ethereum costs you as well)

Phase-2 validations in Cardano, however, are rare. This is because if phase-1 validation passes, it means the result of smart contract execution is deterministic. More concretely, if your transaction would succeed when submitted now, it will either succeed in the future OR it will fail in the future with a phase-1 failure (ex: because the TTL in the transaction expired or because your wallet balance changed)

This means that users in Cardano, as long as they trust either their wallet or the dApp they are using, should never see any phase-2 validation

However, as phase-2 validation is still a possibility, transactions in Cardano need to provide collateral (which isn’t spent if they transaction succeeds).

What is collateral exactly?

Collateral works similar to regular transaction inputs but with extra restrictions.

Notably, they can be any UTXO entry that satisfies the following restrictions:

1. Cannot contain any tokens (only ADA)

2. Cannot be a script address

3. Must be a UTXO input (not a reward address)

Also be aware that:

1. They can be the same UTXO entry as used in non-collateral tx input
2. If consumed, they are consumed entirely (no change) if the contract execution fails during phase 2 validation
3. They are 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)

How is collateral handled now

The problem with Cardano light wallets right now is that they cannot verify smart contract execution (since no library exists for smart contract execution validation that can run in the browser) and so they cannot protect users. Similarly, hardware wallets also cannot run smart contracts as they (by design) have very limited memory and computation capacity.

This means that it’s up to users to understand the risks involved with using Cardano smart contracts and wallets (like Flint Wallet) have to explain to users what is collateral (which is not easy for a non-technical audience)

What’s even worse is that there is no standard for how collateral is handled between different wallets. This means that if users are using multiple Cardano wallets, they have to manually make sure all their wallets are configured to handle collateral in the same way.

How do we solve this issue?

At dcSpark, we’ve proposed three different solutions to this problem:

1. Collateral key derivation: this proposal creates a standardized way for wallets to handle collateral to make using multiple Cardano wallets at the same time easy. The benefit of this proposal is that it doesn’t require changing the Cardano protocol at all. The downside is that is still requires explaining collateral to users (which is the core problem we’re trying to solve)
2. Collateral output: this proposal modifies Cardano to create a new kind of transaction output called Collateral Outputs. This would require a protocol upgrade (hard fork combinator event), but would allow users to include tokens into their collateral and, if the transaction fails, they would get the tokens (and any remaining ADA) back. Given this makes phrase-2 collateral low risk, it would also allow wallets to mostly hide the concept of collateral from users entirely.
3. Collateral reward: this proposal is similar to collateral output, except that the change gets sent to the user’s reward address instead of to an explicit output. This would not only require a hard fork combinator event, but would also most likely require reviving the idea of turning Cardano into a chimeric ledger (or at least as simplified version of it). It’s a discussion at least worth having now that ISPOs and and applications like DripDropz are popular enough to show there is demand for allowing tokens to be held by reward addresses.

Enjoy technical content like this? Follow dcSpark on Twitter and also support Flint Wallet which enables us to spend time tackling tough wallet-level problems like this one