Reduce Min UTxO

I have been wanting to propose a CIP on this for awhile but haven’t had time to get more detailed analysis.
Anthony Sadler is assisting me with that.
I think it’s worth starting a discussion here to see what people think in the meantime.
I would like to reduce utxoCostPerWord from 34482 to 3000.
This would put the amount of ADA required to send an NFT or other native token at about the same amount as a transaction fee.
I believe it is enough to prevent network and ledger spamming and keep ledger size within a resonable amount.
See the main bits of the CIP below.
What do you all think?
Shawn

Simple Summary

Enable more applicatinos for native tokens and NFTs by reducing the minimum amount of ADA required per UTxO.

Abstract

The current minimum amount of ADA required per UTxO makes many applications of native tokens and NFTs infeasible or overly complicated.
Reducing the minimum amount of ADA required per UTxO would enable more innovation in native token and NFT applications while maintaining sufficient security and reasonable memory requirements for the ledger.

Motivation

Specification

| Name of the Parameter | New Parameter (Y/N) | Deleted Parameter (Y/N) | Proposed Value | Summary Rationale for Change |
| --------------------- | ------------------- | ----------------------- |--------------- | ---------------------------- |
| utxoCostPerWord       | N                   | N                       | 3000           | See Rationale section.       |
| --------------------- | ------------------- | ----------------------- |--------------- | ---------------------------- |

Rationale

The previous value was 34482.
Currently, this means that approximately 1.5 ADA must be sent with every transaction containing native tokens or NFTs. This is on top of the normal transaction fee.
Sending $10 USD worth of a native token or an NFT requires nearly $2 USD at current prices and has been over $5 USD in the last few months.
This high “fee” is a limiting factor on the types of applications that can be built on Cardano and forces some applications to build complicated vending machines or reuires multiple transactions where only one is necessary.
With the new value the amount of ADA that must be sent is reduced to about 0.13 which puts it in the same range as the minimum transaction fee.
The minimum ADA per UTxO is necessary to prevent someone “spamming” the ledger with millions of UTxOs containing worthless tokens.
The proposed amount would still be sufficient to prevent such attacks while opening up Cardano for innovative new applications using native tokens and NFTs.
This proposal could cause an over all increase in the size of the ledger but given that the cardano-node can now store the ledger on disk rather than keeping it all in memory this is less of a concern for node operators.

3 Likes

While I agree about adjustments to be somehow dynamically formulated, I do not think I get the idea about numbers derived based on rationale mentioned in proposal, or the correlation with outcome based on assumptions used .

It does not mean node will be able to query utxo well, you’d end up relying more on query layers which are increasing substantially (to sync as well as maintain indexes for - if keeping entire chain history just for transaction details itself in an easy to consume manner).

Not sure if I understand this logic, sending 10B worth native token doesnt cost much more either. The value of secondary token (x times easier to manipulate) shouldn’t determine minimum value of base token imo.

Besides it’s not easy to define things like load being “enough”/size being “small” - it depends on the viewpoint of consumer. For token creator, they’d will almost always want fees to be as low as possible, and the assumptions involved would accordingly biased (vice versa). This might need slightly more calculated approach

2 Likes

This will not reduce the cost of transactions below 1 ADA.

The reason transactions of NFT and other digital assets are around 1.5 ADA per unit is because Cardano network implements a minimum transaction UTxO.
This is a protocol parameter that sets this is minUTxOValue and it set to 1,000,000 Lovelace.

So even if you propose to charge 0 instead of 34482 it would still cost 1 ADA.

This value is not there due to digital assets nor to prevent spam. This is done to limit the amount of all UTxO entries on the ledger.

If a ledger has no bottom limit for UTxO size then the number of UTxO can become so large that it will not be manageable by anyone any more. This minimum ADA per Tx exist to protects the ledger and with it protects the whole network, nodes and pools.

So this CIP may at best reduce cost from 1.5 ADA to 1 ADA, which makes pool operators carry the load of larger transactions.

Edit: removed/ corrected mention about fees as suggested below. Thanks :+1:

1 Like

You seem to mix up minimum UTxO values and transaction fees, here.

Minimum UTxO values do not go as rewards to the pool operators, but are always transferred to the new owner (which also makes them less of a problem than mostly thought).

I don’t think this was unclear. I said:

I implied that fee reduction to nothing and just leaving the 1 ADA (as best case scenario for the goal of this CIP) would make operators carry the load for free. I didn’t imply that that 1 ADA minimum fee would be used for fees.

This whole proposal is about changing utxoCostPerWord. As far as I can see that parameter is part of https://docs.cardano.org/native-tokens/minimum-ada-value-requirement (although these parameters have a tendency to be named differently at different places). It makes the 1 ADA for pure ADA UTxOs a little bit bigger depending on the UTxO size (number of other tokens and length of their names and amounts). This never goes as rewards to pools.

That parameter has nothing to do with https://docs.cardano.org/explore-cardano/fee-structure, which goes as rewards to pools. There, the b parameter (which is called txFeePerByte if I query the current protocol parameters) also makes the fee vary with size, but with size of the whole transaction in bytes. This is not proposed to be changed here.

1 Like

And, by the way, this will, as far as I can see, reduce this 1 ADA minimum also.

There seems to have been a change in the calculation at some point in time. If you query the current protocol parameters, you will see that minUTxOValue is null. It seems that the current choice of utxoCostPerWord just happens to lead to a minimum UTxO of roughly 1 ADA for pure ADA UTxOs. (In fact, it’s only roughly, I have just done a transaction with an output of less than 1 ADA: https://cardanoscan.io/transaction/13824b1abd3e66ea3b858a022644e0de73ff4465e7b8b16238916736cea54d9b)

So, the proposed change will also allow pure ADA transactions with much less than 1 ADA.

You are correct about that. I should not have implied that with my reference to pot. I’ll edit my comment for clarity. Thank you :+1:

I’m aware of some of these changes, however there is a min-ada-value constrain in the protocol. It still is functional (maybe it shouldn’t be). There is a github issue about it that is still open:incorrect epoch_params on alonzo · Issue #782 · input-output-hk/cardano-db-sync · GitHub

So, basically, with out making things complicated I’ll give my premises and conclusion. This way we don’t need to talk about new names vs. Alonzo names of variables.

Premises:

(i) There is a Minimum ADA Value X enforced by the network on every transaction.
(ii) Any Tx with Minimum ADA below X will be forced up to X by (i)
(iii) utxoCostPerWord is a parameter used to calculate amount of ADA to be sent with asset

Argument:

If (iii) sets a parameter that calculates amount of ADA to be below X, then (ii).

Conclusion:

Changing utxoCostPerWord parameter in order to reduce minimum ADA required will not work due to (ii)

So, regardless of new/old names terms this is the argument that I’m making.
Let me know if I misunderstood any of it. :smiley:

Yes, there was an error in protocol before. What you are seeing in that transaction is network enforced minimum (ii). They said after fixing it that min ADA value will actually be slightly lower then 1 ADA. Quote:
" The min-ada calculation for any UTXO approximates the above formula. This uses the constants

coinSize = 0 (note: this is an implementation error, and will be changed to the correct value, 2, in the next fork. This will decrease the minimum ada value by a small percentage)"
Source:
https://docs.cardano.org/native-tokens/minimum-ada-value-requirement.

That is a bug against cardano-db-sync. It is just about how the current protocol parameters are presented in the db-sync.

Okay, I tried to find it in the code itself:

Disclaimer: I am not speaking enough Haskell to analyse this in-depth.

That documentation page was created on 2021-06-07 and never changed: https://github.com/input-output-hk/cardano-documentation/blob/master/content/07-native-tokens/02-minimum-ada-value-requirement.mdx

That comment is about the calculation in Mary and does not apply to Alonzo ff., anymore, as far as I can see. And I also do not find any indication that the coinSize = 0 bug was ever fixed, before it became irrelevant due to a complete overhaul.

Insert my usual rant about outdated documentation, here. I am sure that I have also sent people to that page only to now find out, it has very little to do with the current state of things.

For what it’s worth, the 0.999978 ADA that I was able to send in the last message exactly correspond to 29 words × 34482 Lovelave per word, which is the current value of utxoCostPerWord.

Just to be sure we are on the same page:

The minimum UTxO value is not a fee. It is not lost. It is just transferred together with the tokens. So, it can easily be priced into payment transactions in the other direction, so that the net effect will be 0.

If the price of ADA would go much higher, I would agree that it has to be changed, because, e.g., paying a value corresponding to 5 USD by sending 110 USD and getting 105 USD back, because the minimum UTxO value already corresponds to 100 USD, would be impractical. But at the moment, we are not at that point (yet).

So, the primary target for your proposal are airdrop-like situations, where you want to spare the transaction in the other direction, because projects could afford to “lose” the minimum UTxO value without being compensated by the recipients for it?

1 Like

29 seems to be default setting when they were testing switch from just ADA value to coinsPerUTxO
even thou it mentions 27 in official paper, but it may be outdated.
29testMin

29testMin2
Source:cardano-ledger/Golden.hs at b2cb326bd1fd4e613fe8b20f6b7389d7c875b481 · input-output-hk/cardano-ledger · GitHub

However, if you are able to get any number lower then 27 that is divisible by 34482 I would think that would be 100% proof that there is no overriding min value. Also, 857889 seem to be ‘true’ min value as per Babbage latest:
TrueMin
as per the Babbage link you posted.

Yet when I look at those code clips it seem that minUTxO was kept just split into nested default with no value (thus becomes 29) or higher value then 29 determined by coinsPerUTxOWord.

If they coded like they modeled then this function will start to evaluate only at 29 (or 27 depending on which doc I look at) or higher. Also, I’m just a Haskell noob so I have hard time following all the nested functions around the github :sweat: However they seem to imply that coinsPerUTxOWordLocal assumes no change to minUTxOValue.

If you look at the formulas quote:
" For a UTxO containing a token bundle B the min-ada-value calculation is as follows :

** Case 1 : Token bundle B in the UTxO u contains only ada (no other tokens) minAda (u) = minUTxOValue*
** Case 2 : Token bundle B in the UTxO u contains ada as well as other tokens minAda (u) = max (minUTxOValue, (quot (minUTxOValue, adaOnlyUTxOSize)) * (utxoEntrySizeWithoutVal + (size B)))* "

Command max seems to imply that it will calculate both options and choose higher. I have no reason to think they would change this thinking with other upgrades.

@HeptaSean Thanks for looking into this :+1:. It is unbelievable how much more one can learn from discussion then just reading.

@shawnim Sorry OP didn’t mean to hijack this thread with just one point. Just to be clear, beside this issue I still had reservations about allowing exponential growth of UTxO if this proposal does work. Especially since it may mean higher hardware requirements for running all full nodes, plus potential for ledger to become huge and unmanageable.

As I understand it, they chose utxoCostPerWord = 34482, so that the new calculation will yield an almost identical value for pure ADA transactions as the old minUTxOValue = 1000000, because 29 just happens to be the minimal word size of a transaction output.

If we later change utxoCostPerWord – as this proposal wants – this will, of course, not hold anymore. According to this proposal a pure ADA output would have to have at least 29 × 3000 = 87000 Lovelace = 0.087 ADA.

I don’t think that’s possible, since

uses an utxoEntrySizeWithoutVal of 27 and seems to add at least two words for the value/amount and the data hash to it (which may be the 27 vs. 29 confusion).

This does not seem to be exact, since transaction outputs to Byron or undelegated (“enterprise”) addresses should be shorter in words than transaction outputs to the usual delegated Shelley addresses, but this code just ignores these differences and hardcodes 27 as the “length without values” (and data hash).

Well, it seems we are not in the Babbage era, up to now. cardano-cli query tip still shows Alonzo. I don’t know if they just abandoned Babbage, if it will be incorporated into Vasil, if it is the internal name and identical to Vasil, …

Another documentation rant: Up to now, I have not found a detailed overview of the eras and “sub-eras”, what exactly was changed, when exactly (time and epoch) they started if they already started, …

As said, I think that document is totally outdated. Exactly that case distinction with exactly that max function is at

but not found in the code for Alonzo, anymore.

I second that apology. Our diversion is hopefully not totally off-topic, since it is about the effect of such a change.

As far as I understand it, it will not allow exponential growth of the number of UTxOs, but “just” roughly 11.5 times the previous theoretical maximum.

Moreover, the ledger will become larger with adoption also without allowing smaller UTxOs. Pools will have to deal with it, anyway.

At some point, we will have to reduce minimal UTxOs and probably also fess if ADA becomes much more valuable. I’m just not sure it’s urgent.

I also appreciate the detailed discussion (even if a diversion from OP) & would hope when this is presented as a CIP that such a refinement of the terminology & summary of these calculations can be included, and that these arguments against the proposal would be addressed pre-emptively.

Our tech users & investors group (mostly non developers; I’m mainly a systems integrator) has been watching the NFT market flourish on Solana. I would generally prefer the security & atomic nature of Cardano tokens but in my simple understanding many NFT oriented businesses have preferred Solana for its transaction economy when working with tokens.

The initial rebuttal about a potentially vast increase in ledger size sounds serious (potentially 11.5 as per @HeptaSean) as well as the burden it would place on query layers (as per @rdlrt). I wouldn’t be able to address whether taking on these burdens, to make token economies more attractive on Cardano, would be economically justifiable for the ecosystem & value of Cardano itself… I only want to be sure the question isn’t ruled out based only on existing use cases:

One application our group originally ruled out for Cardano was a publishing DAO which would have associated native token(s) with ownership of low-value items (like books & music albums or even individual songs) whose fiat value last year was quickly exceeded by the value of 1 ADA. The parallelism of smart contracts would have made a Cardano-based fully distributed token economy ideal… if not for the cost of carrying around ADA with even the smallest native token transfer.

So I submit that this CIP is worthy of presentation because it would enable additional use cases for Cardano… to support token economies whose transfers are fine grained & massively distributed. The argument that supporting such applications would kill the ledger size, chain size, sync times, etc. would then establish whether & how the CIP might be implemented, and with what parameters. :face_with_monocle:

1 Like

I’d like to stress that 11.5× is a purely theoretical calculation: With the current value (and disregarding native tokens for a moment), the 45 billion ADA maximal supply could lead to roughly 45 billion UTxOs. But, of course, we have much less, because most UTxOs have much more than the minimal UTxO value.

With the new value, the 45 billion maximal supply could lead to roughly 517.24 billion UTxOs (even a little less than 11.5×). How much of that additional possibility for more and smaller UTxOs would be realised is hard to predict. Could very well be that it does not change the number of UTxOs much at all. Before the change, a user has one UTxO with 100 ADA and 100 UTxOs with an NFT and 1.5 ADA each. After the change, the same user has one UTxO with 200 ADA and 100 UTxOs with an NFT and 0.5 ADA each.

Also, the point of @rdlrt is mainly the same: A full node has to save all UTxOs in a way that it can be queried (as far as I know, these are the 3.2 GiB in mainnet/chain/ledger, not the 59 GiB in mainnet/chain/immutable). To verify new transactions, it has to be able to find if the input UTxOs to the transaction exist and if they are still unspent.

(I am a huge advocate of implementing a method to prune the 59 GiB of complete history of the blockchain on most full nodes. There is no reason that every block producer, every relay, even every Daedalus installation carries that around. Mithril will have an (over-complicated) way of not saving the whole history, but it seems that will not be available for block producers and relays, but is marketed just as something for light clients.)

Anyway, the ledger will also grow if the minimal UTxO value stays the same, but we get many new users who do transactions, buy NFTs, organise their wallets. Wanting new users, but the ledger not growing is simply not possible. So, this has to be solved for pools with or without this proposed change.

After arguing, why this proposed change might not be that dramatic, I also have to point out why it might not be that necessary (at the moment):

There is not that much difference if (with, say, 0.5 ADA minimal UTxO) a user purchases a low-value item by sending 1 ADA and getting the item together with 0.5 ADA minimal UTxO back or if (with, say, 1.5 ADA minimal UTxO) they purchase it by sending 2 ADA and getting the item together with 1.5 ADA minimal UTxO back. In both cases, they paid 0.5 ADA net. It’s not that big of a problem that the accompanying ADA are worth more than the token/item.

That’s why I brought up airdrops as the only real use case. If you do not have and do not want to organise transactions in the opposite direction, only then you have a problem with the minimal UTxO, because you cannot simply include it in the payment.

1 Like

That’s why I believe fine grained token based economies are a broad use case of such mostly “one-way” transactions. Publishing or other commodity item purchases with native tokens, for which the buyers will generally not be conditioned to buying NFTs, are a good example of this… e.g. nobody buying a $3 Kindle book would find it acceptable to pay $15 for the book even knowing they’d get $12 of it back along with the book token.

If I go any further into how we proposed to build our highly unconventional publishing DAO there would be a hailstorm of off-topic criticism trying to invalidate our particular use case. I’m only going on record with an example of a broad class of applications that would benefit from substantially reducing the ADA carrying fee for token transfers. :face_with_monocle:

1 Like

Yep, there is a point, where it gets impractical even if it, theoretically, can be offset to have an effect of net zero. As said earlier:

I don’t know, where exactly that point is. Might also differ from use case to use case.

But I would be open to doing a first change in that direction, now. Might very well need another one after the next all-time high.

1 Like

This ties in with another CIP modification draft that came in 2 days ago… the 1 ada barrier for UTxOs is a technical obstacle to breaking up NFT royalties into multiple recipients. It would be interesting to tie these two discussions together somehow: CIP-0027? | Update Proposal: Multiple Royalty Addresses by NicholasMaselli · Pull Request #271 · cardano-foundation/CIPs · GitHub

@rdirt @HeptaSean @Neo_Spank @COSDpool Thanks for the discussion!

It seems like we need clarification from IOG regarding both current intent and actual implementation of the min utxo value.
With the minUTxOValue set to null in the current protocol parameters, it seems wrong to have a “hidden” min utxo value.
The min utxo value should be purely utxoCostPerWord * words.

My use of “fee” in the description was perhaps confusing.
From the perspective of an application that sends native tokens without requiring a prior reverse transaction such as micro payment applications like tipping or payment for non-blockchain based content the min utxo value is a transaction cost similar to a fee.
I understand that it is not a true fee in the sense that the value goes to the receiver and not the SPOs.
The current high min utxo value makes these types of applications difficult or impossible.

The increase in ledger size and the necessary hardware requirements for full nodes needs more analysis to better understand how low we can make the min utxo value.
We need to be cognizant of ledger size / hardware requirements / anti-spam but if we do not reduce the min utxo value (utxoCostPerWord) enough then we will fail to enable a whole class of new applications.

2 Likes

I created some infographic abt a year ago for explaining these values including the 29. Check the min UTxO ADA calculation picture here

1 Like

I do not think it needs clarification. It’s very clear how they designed and implemented these things.

1 Like