New users of Cardano sometime want to get started quickly and often face the daunting task of understanding what collateral is. Then faced with the fact that they need to send some collateral to their wallet ... the quickness aspect of it gets lost very quickly

This is particularly true for Mobile Apps running on Cardano. Where users download the mobile app and get a wallet generated for them in the background. The wallet cannot interact with smart contracts until some ada is sent to it from the outside. This is cumbersome and degrades the user experience.

Question: Is it possible for the Dapp provider to add collateral for the user from a centralized wallet?

Potential workflow:

  • User builds a transaction using the cardano-serialization-lib
  • User sends the transaction to a back-end service of the Dapp provider
  • The backend service adds the collateral field, partially signs the transaction and sends back to the user
  • The user signs the full transaction and submits it through their wallet

This would enhance the user experience in mobile apps and increase the adoption of Cardano by letting users download an app and strat using straight away

Is something like this currently possible, and what are the risks?

All the best, DSIO

2 Answers 2


This does not answers your question directly, but might you give you an idea how to solve it in a different and potencialy better way.

In this twitter thread KtorZ explains the recent changes on how to handle collateral.

In case you wondered, here are some quick clarifications about the infamous 'collaterals' in #Cardano.

There was an interesting conversation I was brought into and thought it could be interesting to turn it into a proper thread.

All you ever wanted to know about collaterals 👇 With the Alonzo era and the introduction of Plutus scripts was also added a new feature to transactions: collaterals.

In essence, a collateral is an input which is consumed when a script fails to execute in a transaction.

But, aren't scripts supposed to be deterministic? Precisely.

So in principle, any user in their right mind would not submit a transaction with a failing script, because they would know the outcome in advance.

Yet, an attacker of the system might find that interesting... In fact, a failed transaction consumes resources but does not reward block producers for it. No fees are collected. For basic transactions only involving public key signatures, that's okay since the resources involved are negligible.

Yet for Plutus scripts, that's another story. Hence why a 'collateral' was introduced to transactions.

It is an input (or, UTxO) that is consumed when a well-formed transaction with a failing script is submitted through the system. It acts as a mechanism to prevent bad actors to waste resources of the network at no cost. Any transaction that executes a script is required to have a collateral, but it's only consumed if the result of the script execution turns out wrong.

The amount of collateral depends on the cost of the script and some protocol parameters. Plus, some extra rules. In particular, the collateral cannot itself be an input locked by a script.

Moreso, it must NOT contain any native asset, but be a pure Ada UTxO.

Of course, it must also be an existing input that can be rightfully spent by the transaction. In practice, it means that wallets must manage this collateral. Wallets must make sure to keep a large enough Ada-only UTxO available for collateral. This can be a little tricky, and also, a bit odd from a user perspective. Most Ada holders that have interacted with DApps have probably went through the steps of 'setting a collateral' in their wallet prior to making any transaction to a smart-contract.

This is a, relatively transparent, way for wallet providers to inform users about collaterals. Overall, this is an unsatisfactory user and developer experience, for both > Ada holders and wallet providers alike. While the management of collaterals doesn't require users to explicitly set one, it's cumbersome and confusing to manage over time behind the scene. So, with the Babbage era, a new feature was introduced called the 'collateral return'. This allows wallets to not only define a collateral input to consume on failure, but also an output to send some change to in case it happens.

And this makes everyone's life a lot easier. Remember the constraints about the collateral? In particular, that it needs to be Ada-only?

Well now, what matters is that the remainder between the collateral input > and return is an Ada value, of a minimum quantity depending on the script cost and protocol parameters. Said differently, it makes management of collaterals easier for wallets that decide to make use of it. They no longer need to keep a particular Ada-only UTxO around but can simply use any sufficiently large input as collateral and dump whatever is left in a change output. It's interesting to note that collaterals were never meant to be a user-facing feature in the first place. This was supposed to happen behind the scene only, because in principle, users (or by extension wallets) do not normally submit failing transactions. Yet, this somehow made its way through UIs in such a way that as Cardano users, we've grown accustomed to it. Up to the point where, new wallets would even have to adopt the same strategy to not confuse people.

UX is a funny thing 😶 Moving forward, and with collateral return available in the protocol, we can hope that wallet providers will gradually update to adopt this new approach and, put collaterals back in the shadow and not bother us users about them anymore 😊

  • Thanks Marek, I posted a similar question on their Twitter thread before coming here :) I don't think the points answer the specific question, though, KtorZ recognizes that UX "is a funny thing", and my question is to address the UX.
    – D S
    Dec 2, 2022 at 20:35

Yes this is possible but requires suitable UTxO(s) being already present in wallet. Due to virtues of CIP-40 any UTxO can be taken as collateral because we can set for return output and only this balance between input collateral(s) and return collateral output is required to satisfy the earlier collateral needs (such as being percentage of transaction fee and ada-only). Note that as of now, we can take up to three UTxO(s) as collateral inputs (this is a protocol parameter). Atlas by Genius Yield handles for collateral and the example project in their documentation utilises this approach where if wallet has already set collateral then that is used otherwise framework chooses suitable UTxO as collateral for building the transaction.

Find more details in ledger specifications here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.