CIP-0159? | Account Address Enhancement

[fallen-icarus]

This CIP adds support for depositing assets into account addresses (a.k.a. reward/staking addresses) which helps alleviate some of the pain-points from the minUTxOValue requirement. The CIP also provides a mechanism for plutus smart contracts to get a sense of the account's current balance using account balance intervals similarly to how time is specified.

---

Rendered Proposal

[fallen-icarus]

This is a first draft, but @GeorgeFlerovsky and I would like to start getting community feedback on it.

Tagging some people who might be interested: @Quantumplation @lehins @colll78 @michele-nuzzi

[colll78]

Great CIP!

Can you add a script purpose that allows you to do partial withdrawals?

[fallen-icarus]

Can you add a script purpose that allows you to do partial withdrawals?

Why not just use the already present Withdrawal purpose? This purpose would be used for both full withdrawals and partial withdrawals. AFAIU only the ledger rules need to be changed to support partial withdrawal.

[rphair]

@fallen-icarus we'll tag it for Triage to be discussed at the next CIP meeting after it comes out of Draft: but if you would like to tag it for the meeting earlier (for more of that "community" feedback) please just say so (p.s.: and tag the editors in case we miss that message in the long conversation).

[michele-nuzzi]

@fallen-icarus maybe I'm missing something, but not supporting native assets means that minUtxo is solved only for ada-only utxos?

I think the big pain point is sending assets without minUtxo

[fallen-icarus]

... minUtxo is solved only for ada-only utxos?

Yes, that is correct. This section discusses the concern for dusting attacks with native asset support.

I think the big pain point is sending assets without minUtxo.

That might be true for you, but that is not true for everyone. I have spoken to several projects and they would like to charge fees (in ADA) for their services, but currently the smallest fee they can charge is 1 ADA because of the minUTxO. Also, for DAOs whose treasuries are mostly ADA, using an account address makes more sense.

I would like to one day see support for native assets as well; but as the CIP says, why should we wait since we can safely add support for ADA now? It could be years before someone figures out a simple solution to native asset dusting attacks.

[Quantumplation]

I think this does help with minUTxO though, because you can always withdraw from an account to cover minUTxO; so if someone has a very congested wallet, but wallets keep the reward account topped up, then the "solve" for utxo selection is less of a fixed point: select the UTxOs needed to cover whatever you're trying to do, and then furnish the minUTxO from the account. You don't have to go back to UTxO selection and potentially loop multiple times.

[michele-nuzzi]

but wallets keep the reward account topped up

Collateral taught us that making assumptions about the user wallet is not good, both for DevExp and UX.

Having support for tokens in the account helps everyone, solving both the singular case for ADA and the broader case for tokens

[michele-nuzzi]

I believe we could come up with a minAda for the account

minAda in the account would be significantly less problematic than minUtxo because you only have to have 1 shared minAda for all the assets, whereas the minUtxo implies an overhead for each utxo (the simplest utxo has at least the overhead of the address).

[fallen-icarus]

I think a minUTxO for account addresses would open up an attack vector. 🤔

Imagine if I have only 5 ADA in my account. You could mint a bunch of worthless tokens and deposit them into my account. Doing so effectively forces my ADA to be used as the minUTxO deposit in the account. I didn't consent to this. Now, in order to claim my 5 ADA, I need to do something with these worthless tokens.

This attack isn't possible with UTxOs since you can't use my ADA from other UTxOs to be your minUTxO deposit. You need to cover the minUTxO deposit yourself when you send me the worthless tokens and my ADA is still segregated from these tokens.

[michele-nuzzi]

you can always withdraw from an account to cover minUTxO

how does this not have the same problem you describe?

[michele-nuzzi]

one naive-ish way to solve for this attack would be to require authorisation to deposit in the account (either by pub key signature or by contract)

[fallen-icarus]

how does this not have the same problem you describe?

You're right. It does.

one naive-ish way to solve for this attack would be to require authorisation to deposit in the account (either by pub key signature or by contract)

I don't think this would work for pubkeys since it requires the business to sign every transaction that wants to send them money. For it to work at scale, the business would need to automate the signing and have their keys online 24/7. This is a major security sacrifice just to allow filtering native asset deposits.

Also, I'd personally like to avoid requiring deposit script executions due to execution costs. Some services could possibly charge 0.01 ADA per tx, but a deposit script execution would add way more than that in tx execution fees.

[fallen-icarus]

Perhaps it is possible to whitelist native assets in an account address' registration certificate? But I don't know if this would add too much overhead to still rely on Phase 1 validation. @lehins

[michele-nuzzi]

I'm not sure why everyone is so scared about executing scripts lately, but these are the relevant parameters

{
"price_mem":0.0577,
"price_step":0.0000721,
"max_tx_ex_mem":"14000000",
"max_tx_ex_steps":"10000000000"
}

that means that a tx that spends 100% of the max tx budget pays 14000000 * 0,0577 = 807800 lovelaces for memory and 10000000000 * 0,0000721 = 721000 lovelace for cpu

that is 1,5288 ADA of the MAX possible fee paid for a script execution.

I would find hard to believe a script that verifies the whitelist of contract (a single utxo ref in a linked list) to go over 2% of max tx budget

2% implies a ~0,03 ADA of additional fee

[fallen-icarus]

IMHO a fee-based script is a workaround, not a solution. Since all we are trying to do is filter native asset deposits, a phase 1 check that also works for pubkey addresses would be preferable.

[michele-nuzzi]

a phase 1 check that also works for pubkey addresses would be preferable

agree, but, as you said, we don't want to put too much load on phase 1, so it would have to be benchmarked.

if it is doable it would be preferred.

regardless, in order to truly solve for minUtxo we need to consider CNTs

[lehins]

I am pretty sure we will also need to provide the ability to operate on multi-assets in accounts, because:

1. it would be an awesome and desired feature in the community
2. one of the important reasons why we also want to have this account enhancement is to potentially be able to do treasury withdrawals that will have multi-assets in them (that feature will need its own CIP). In the nutshell, it would allow annual budget be defined in stable coins, instead of volatile native asset.

Problems that I am aware of with respect to putting multi-assets into accounts are:

1. the dust attack, where one could split junk multi-assets and deposit them into millions of accounts.
2. attacking individuals with many junk multi assets, since it would cost them money to get rid of that junk from the account

Solution that comes to mind is to also require addition of ADA to the deposit associated with the account, where the amount of ADA would be proportional to the size of binary representation in memory of the multi-asset (which is similar to how minUTxO works). This has a few benefits:

• it places an actual cost on the attacker that would try to send junk to accounts that are not controlled by the attacker
• requires more skin in the game if an attacker wants to register millions of addresses and put junk in there, which is a similar deterrent that we get from the 2 ADA deposit that we already have today upon registration of accounts
• if a user A sends some junk multi asset to another user B, it will cost that user B some ADA to get rid of such multi-aseset, if such multi-asset was undesired by user B, requiring to transfer some ADA with multi-assets would give user B enough money in order to get rid of it.

Naturally, this is still just an idea that I have not given good enough thought, but I have a feeling that it could work.

Slight complication I can see with this is with getting the deposit back. After all, we do not want to encourage users to drain accounts and unregister in order to get what could be a pretty big deposit. This could potentially be solved with a special "rebalance" certificate that allows users getting back surplus from the deposit by looking at current multi-asset balance in the account. I am just not confident that it is safe to do something like this automatically on a withdrawal, since there would be a dependency on some protocol parameter and that has implications for plutus scripts, but maybe that would be fine too.

[fallen-icarus]

@lehins Whitelisting CNTs in the address' registration cert seems much cleaner. The registration deposit could be exponentially proportional to the number of CNTs whitelisted. Then any tx that deposits a non-whitelisted CNT just fails (phase 1?) validation. This approach safely allows the account address owner to cover the minUTxO for all deposits.

---

EDIT: Actually, I think the whitelist could be checked during phase 2 validation. Phase 1 would only check that the receiving account is registered. This means depositing CNTs would require posting collateral. This seems fine since it is your fault if you try depositing a non-whitelisted CNT. ADA can always be deposited without specifying collateral.

[lehins]

Whitelisting CNTs in the address' registration cert seems much cleaner.

Whitelisting is a limiting solution, IMHO, since you need to know all multi-assets you want to accept a priori. In other words, if you'd like to accept a new token, you'd have to unregister and register back again, which would also require undelegation from DReps and Stake Pools.

Also, from what I understand about this suggestion, this is not an acceptable protection from ledger perspective, because it would rely on logic that is not directly enforced by the ledger. In other words, ledger has no knowledge or control of what is being validated in phase2. If we are to allow multi-assets in accounts, all of the enforcement must be done at the ledger rules level.

Most importantly, however, whitelisting does not protect against an attack where an attacker creates couple of hundred accounts with millions of multi-assets white listed. That would allow such an attacker to do a DDoS, and it would be fairly inexpensive.

Perhaps it is possible to whitelist native assets in an account address' registration certificate?

So, I am sorry to say, but this is not a viable solution.

[lehins]

AFAIU only the ledger rules need to be changed to support partial withdrawal.

@fallen-icarus You do need to mention that partial withdrawals will not be available in presence of Plutus versions that are already active on mainnet (PlutusV1-V3 today), otherwise this would be a backwards incompatible and unsafe change, which we must avoid.

[Quantumplation]

Why would a partial withdraw look any different from just a withdrawal certificate with less ada in the wallet, from the perspective of plutus v1-v3?

The "account balance interval" stuff, or deposits, certainly wouldn't be visible, but any existing script can't possibly care whether it's a partial or "complete" withdrawal

[fallen-icarus]

Whitelisting is a limiting solution, IMHO, since you need to know all multi-assets you want to accept a priori.

I don't see how this is a problem. If I'm running a service and people need to pay me, they need to use a pre-approved currency. I won't accept payment in just any asset. If they need to send me a one-off asset, sending it into a UTxO is still possible. In what scenarios do you need to frequently accept random assets? 🤔

... if you'd like to accept a new token, you'd have to unregister and register back again ...

I personally don't consider this to be an issue since adding pre-approved assets to the whitelist for payments would be a rare occurrence. But if it is an issue, we can decouple the whitelist into its own certificate.

Most importantly, however, whitelisting does not protect against an attack where an attacker creates couple of hundred accounts with millions of multi-assets white listed. That would allow such an attacker to do a DDoS, and it would be fairly inexpensive.

I don't see how this attack is actually possible. The whitelist itself must fit inside a certificate which must fit inside a transaction. I doubt you can fit "millions of multi-assets" into a whitelist. My guess is that it is only a few hundred per address before the certificate size exceeds the tx limits. Plus, if we have the exponential deposit calculation like I suggested, it could be prohibitively expensive after only 20 assets whitelisted. The attack you're describing would require locking up millions of ADA.

---

AFAIK the number one use case for this feature is accepting payments or specific markers (e.g. vote counting). This implies a very finite list of assets that each account address needs to accept. I don't see why we need to enable support for depositing a lot of unique random assets into each account address.

[lehins]

Why would a partial withdraw look any different from just a withdrawal certificate with less ada in the wallet, from the perspective of plutus v1-v3?

Because there is an implicit assumption that some scripts might rely on the account balance to be fully drained. It might not affect anyone, but it might affect someone significantly. We just never know.

The "account balance interval" stuff, or deposits, certainly wouldn't be visible, but any existing script can't possibly care whether it's a partial or "complete" withdrawal

Presence of an interval or deposit would immediately disqualify any presence of PlutusV1-V3 scripts in a transaction. The only exception we have ever done intentionally to this rule was enabling reference inputs for PlutusV1, which was weighted very carefully.

[lehins]

I don't see how this is a problem. If I'm running a service and people need to pay me, they need to use a pre-approved currency. I won't accept payment in just any asset.

This fact of whitelisting has to be stored in the ledger state, which itself has the exact same overhead as just storing that multiasset for the account state in the ledger state. So, you are not solving anything with this.

I don't see how this attack is actually possible. The whitelist itself must fit inside a certificate which must fit inside a transaction.

It is not the transaction that is the problem, but the space whitelist would occupy in the ledger state.

I don't see how this attack is actually possible.

Imagine that I am an attacker and I submit a certificate that contains as many multi assets that you'd like to whitelist as transaction size limit allows. Now you have 16KiB of data that has to be stored in the ledger state. Rinse and repeat for more accounts until node is killed with out of memory. The reason why we have reward account deposit and minUTxO, is to prevent precisely this attack.

Side note. I think we should consider renaming withdrawal and deposit to something like credit and debit. It is really confusing discussing deposits, since accounts already have 2ADA deposit, which means something totally different.

[lehins]

I don't see why we need to enable support for depositing a lot of unique random assets into each account address.

It is not a problem of allowing depositing anything random into the account, it is a problem with storing the whitelisting in the state, cause it occupies the same amount of memory as the multi-asset itself. We could potentially make the deposit proportional to the size of the whitelisting. That could work too. However, it would be very similar to my suggestion, except the user that is creating an account would have to leave the deposit, instead of the one that is putting the actual multi-asset into the account. 🤷‍♂️
In this sense the difference is only in:

• whether users are ok accepting any multi-asset from anyone, knowing that they will also get enough ADA to get rid of it
• or giving the choice to the owner of the account which multi-asstes they are willing to accept.

FTR. We'd also have to cap the amount of any multi-asset that can be stored in the account to 2^64-1, but I don't think that would be a deal breaker 😄

[lehins]

I've made this CIP a topic for the next Ledger Working Group Meeting #20. Anyone interested in it is encouraged to join.

[GeorgeFlerovsky]

It might be worth motivating the interval with some examples in the CIP; initially I was wondering why we don't just attest to account balance by a withdrawal followed by a deposit; If I want to prove to a script I have 10 ADA in the account, I can withdraw 10 ADA and then deposit 10 ADA.

It was only after some thought that I realized the above is essentially just a lower bound, and the intervals allow you to assert an upper bound on the balance, but I couldn't immediately think of why that would be useful. (the other value here is that it doesn't require a witness from the account owner, but that's already pretty clear from reading that section).

@Quantumplation Agreed, we should elaborate on rationale for balance intervals.

The bottom line is that (phase-1 validated) balance intervals are the only way to expose the volatile account balance to phase-2 scripts without breaking phase-2 determinism (which the ledger team has indicated would be a deal-breaker). We already do the same thing with time-validity intervals for the same reason.

The balance interval can be quite useful. Two different usecases that I recently described on twitter:

• You can use its upper bound to enforce fixed-supply token minting.
• You can use its lower bound to check that a dApp's onchain gov action has passed the threshold to be enacted.

[fallen-icarus]

@fallen-icarus as I understand the differentiation between Value and AccountValue is just for phase 1 validation

What is the reason to have 2 diffenerent definitions onchain, can't we just use Value in plutus contracts?

As others pointed out, they have different invariants. That was enough for me to consider a separate high-level type. But TBH I don't have a strong opinion on this. If other smart contract devs believe it would be better to work with Value, I'm open to changing it.

This of-course doesn't mean that it will have a different onchain data representation (both MintedValue and Value currently have different invariants but still share the same underlying representation).

👍

---

The main use case I see would be building up the proper AccountValue at run-time to compare with the actual amounts direct deposited. But you could build up a Value (so that you can actually add new assets to the map) and then use a high-level function to convert the Value to an AccountValue right before you compare.

[fallen-icarus]

It might be worth motivating the interval with some examples in the CIP; initially I was wondering why we don't just attest to account balance by a withdrawal followed by a deposit; If I want to prove to a script I have 10 ADA in the account, I can withdraw 10 ADA and then deposit 10 ADA.

It was only after some thought that I realized the above is essentially just a lower bound, and the intervals allow you to assert an upper bound on the balance, but I couldn't immediately think of why that would be useful. (the other value here is that it doesn't require a witness from the account owner, but that's already pretty clear from reading that section).
-- emphasis mine

IMHO not requiring a witness is the biggest use case for the intervals. The "withdraw 10 ADA + deposit 10 ADA" approach requires a witness from the account owner which means it can't be used for decentralized use cases. The decentralized fixed-supply minting is an example use case that wouldn't be practical without the witness-less intervals. Basically, if you want something to happen when a threshold is reached, how can you enable that in a decentralized way without the witness-less intervals?

[Ryun1]

may consider references to different node implementations/teams

[rphair]

@fallen-icarus for CIPs affecting core systems we're planningconsidering to recommend language like added here:

• CIP-0001 | Small suggestions for multi node world #1070

[rphair]

@fallen-icarus FYI to document what you observed on this topic in the last CIP meeting: the CIP-0001 modification above may be less significant than planned — due to difficulties with the original recommendation as summarised in #1070 (review) — so in my opinion this can be resolved unless perhaps @Ryun1 can recommend something in the spirit of that meeting's consensus.

[GeorgeFlerovsky]

@lehins
For the CIP Editors' benefit, can you reiterate your comments here from the Ledger WG regarding this CIP?
Specifically, I recall you saying that the ledger team has a clear idea of how to implement it and is generally positive towards the proposed design.

(If not, or if there are lingering reservations from your team, please comment and we'll continue the discussion)

[GeorgeFlerovsky]

As Midgard protocol architect, I can confirm that we are very excited about the features of this CIP.
They will allow us to simplify our management of the L2 treasury and potentially enable secure onchain governance.

@colll78 please add your 👍 if you agree

[rphair]

@fallen-icarus thanks for the well rounded presentation at the CIP meeting yesterday: as expected this is confirmed as a candidate. @GeorgeFlerovsky your bringing in the feedback from Ledger and the significance to L2 development were also very helpful: and promising both for this CIP and for Cardano.

Editors would look forward to confirming that the remaining disputable details, especially based on Ledger input, are worked out before merging this: so please @lehins @WhatisRT confirm when you think that has been accomplished and we'll put this up for Last Check (no rush).

Please rename this directory to CIP-0159 and update the new pathname to the rendered proposal in your OP 🎉

[AlexDochioiu]

Bringing my comment from X here for visibility. Also, bringing here @Crypto2099 , @disassembler , @HinsonSIDAN since they also showed interest in lowering min utxo ada.

Other people/companies that we spoke with and showed interest in this approach are: Sheldon Hunt + Michael Yagi (Sundial) , Matteo + Raul (FluidTokens)

I think this approach reverses the right order of operations.

If the real pain point is the minUTxO constraint, the first step should be to lower it (since that’s soon possible with UtxoHD), not to redesign how accounts work at the ledger level.

Reducing minUTxO to a negligible value would immediately remove most of the friction that users and dApps face today, with zero ledger or ecosystem changes. It’s a simple parameter adjustment. Every wallet, dApp, and piece of infrastructure would support it automatically.

CIP-159 adds significant complexity for relatively little practical gain. The requirement for users to register each asset type before it can even be received introduces major UX and support headaches:

• Users will run into confusing cases where they “can’t receive” a token because it isn’t registered.
• Wallets and dApps will need to handle and explain new error states that make Cardano feel inconsistent.
• Different dApps will end up showing different balances depending on whether they added support for those assets.

Beyond UX, it also introduces massive work and coordination overhead: new ledger rules, serialization updates, indexer changes, wallet changes, connector updates (CIP-35), and transaction-building changes across the ecosystem. All this work is for functionality that provides no value to existing dApps (since they wouldn't really be able to benefit at all).

By contrast, lowering minUTxO:

• Benefits every existing dApp instantly
• Requires no code or protocol changes
• Preserves current tooling and UX patterns

Doing CIP-159 before even testing a reduced minUTxO is like buying a new car because the seat’s uncomfortable, before trying to slide it back a notch.

---

P.s. It’s been years since collateral return was introduced, and many dApps still don’t use it or use it only partially. Setting collateral shouldn’t exist anymore, yet a large portion of dApps still rely on it. That was a far smaller change compared to what CIP-159 proposes, and adoption is still limited. It’s a realistic preview of how slowly major changes propagate through the ecosystem.

Also bringing this:

[AlexDochioiu]

One more thing I forgot to mention on the UX side: users would effectively have two possible receive addresses: their normal base address and their stake address.

From a user’s perspective, the stake address will seem preferable since it doesn’t lock ADA, but it would only work in some cases depending on which assets are approved. That inconsistency will make it feel unreliable. Wallets would then have to show both addresses and explain when and why each one works, which is going to be a UX nightmare.

[Quantumplation]

Reducing minUTxO to a negligible value would immediately remove most of the friction that users and dApps face today,

While also removing most of the security it provides in the form of bounds on UTxO state size.

CIP-159 adds significant complexity for relatively little practical gain

Just registering my interest here for this proposal regardles of the minUTxO considerations; this unlocks really powerful new design patterns in the dApp design space, and as I look at our internal 2 year roadmap, this would solve quite a few of the awkward things we'll have to work around in the products we want to build. Lots of those have been enumerated by the likes of @GeorgeFlerovsky above, but there are others as well.

[AlexDochioiu]

While also removing most of the security it provides in the form of bounds on UTxO state size.

Could you please elaborate @Quantumplation ? My current understanding is that this was never about security, but rather about keeping the max network state within some bounds for the sake of node operators (keep a small minimum memory requirement). This is no longer much of a problem with UtxoHD being introduced, which allows UTxOs to be offloaded to hdd/ssd.

[Quantumplation]

Keeping the utxo state within some bounds is a security concern, as growing that state without bound could take the network offline.

Even with UTxOHD, there should still be a reasonable bound, for the sake of state growth, access times, and other indexing services. We can certainly likely lower it, but I'm not sure we could lower it to zero; and having it present at all is what causes the UX issues; lowering it to 0.01 ada still means we need to include the ada, meaning tx building is more complicated, etc.

An alternative that would simplify things greatly is simplify the equation. If we calculated what the minUTxO should be for the maximum sized utxo after UTxOHD, and that came in below what it is currently (let's say, 0.5 ada), and we just made it constant, accepting the inefficiency, we could simplify a lot of code, clarify a lot of error messages, etc; it becomes much easier to explain to users, and to resolve programatically.

I would still argue in favor of this CIP in addition, fwiw.

[AlexDochioiu]

@Quantumplation Appreciate the extra context.

I believe lowering it to 0 would not be allowed anyways, and is not what was suggested. I believe that lowering it to ~0.01 ada (or even ~0.1 ada) would still improve a lot of things. The dev complexity doesn't change compared to how it is currently, but the user experience would be massively improved. And it's very easy to deliver.

fixed 0.5 ada min utxo

A fixed utxo ada would absolutely improve both dev and user experience. Only downside that I see is complexity. It requires again real code updates for many components and dev tools, so it'd be much harder/slower to deliver. I'd still like to see this maybe more like 0.1 ada per utxo, but I am generally liking this solution too. (except for the complexity to deliver it)

would still argue in favor of this CIP in addition

My comments here are primarily meant to be about improving the users UX when it comes to the min utxo pains.

If this proposal still makes sense (for other reasons than min utxo cost), I'd like to see a version where it's not viable for P2P transfers, but rather only for SCs. Because if people expect to do transfers to users via stake account, the whole sending experience on Cardano will get insanely messy and confusing.

[GeorgeFlerovsky]

@AlexDochioiu
As @Quantumplation pointed out, the minUtxo constraint exists for a reason: it prevents malicious users from spamming the ledger with tiny utxos.

Recall that currently, Cardano nodes must keep track of each utxo for its entire lifecycle until it is spent, which could be never. So, fundamentally we need something in place to constrain the total number of utxos that each person can create.

In that sense, while this CIP is not about security per se, the solution you're suggesting as an alternative would degrade security IMO.

However, even if minUtxo were eliminated or greatly reduced, this CIP would still be useful. Unlike with a utxo:

• You can always add funds to an account without contention with any other users. This can be used to, for example, easily count up governance votes onchain in an account and perform an action when a threshold is reached, all in parallel without contention.

• If the account has enough liquidity, multiple people can withdraw funds from it in parallel without contention.

As Pi mentioned, I provided more details on usecases above. See here:
#1061 (comment)

[GeorgeFlerovsky]

@AlexDochioiu

If this proposal still makes sense (for other reasons than min utxo cost), I'd like to see a version where it's not viable for P2P transfers, but rather only for SCs. Because if people expect to do transfers to users via stake account, the whole sending experience on Cardano will get insanely messy and confusing.

i strongly disagree. First of all, if we enhance accounts the way the CIP describes, then they will become general-purpose accounts, not just "staking accounts".

Second, I think users would find it more intuitive to send to an account because that's how they've already done for hundreds of years in the traditional finance world.

On the contrary, if accounts become available, I think that utxos will be used primarily to store datums for smart contracts, because updating datums is an inherently contentious action. A utxo will also be used in situations where its whole contents must be spent atomically. However, in the great majority of other cases, keeping funds in an account (as described in this CIP) is the superior option.

Lastly, I think it would be very messy/complicated for the ledger to allow full-accounts at plutus smart contract addresses while disallowing them for pubkeys and native script addresses. Also, Cardano can't distinguish between a native script and a plutus script until a script witness is provided in a transaction.

If you disallow full accounts only for single pubkey addresses, then I expect that users will just start using native script addresses with singleton key sets, as there is only negligible extra cost for invoking a native script. They would do this to benefit from the features of full accounts.

[lehins]

As others pointed out minUtxo is needed for security, as such, it is not going away anywhere. Once UTxOHD becomes a recommended method of storing UTxO then we would probably be able to lower this minimum amount a bit, but definitelty not enough to solve that problem.

In general I would suggest to anyone avoiding speculating about potential values for any of the protocol parameters, especially whithout knowledge of their purpose. Such confidence can give wrong impression to members of the community that such changes are fine, when they are absolutely not fine.

Regardless of minUtxo, I am sure there are plenty of other use cases that will come out of this CIP, that we haven't even thought of yet. Proper chymeric ledger has some superpowers, even Charles Hoskinson agreed when I discussed this feature with him.
One important use case that hasn't been mentioned yet, is that it will provide us with capability to request budget from the treasury in something other than ADA. I am sure you can see how it would make sense to define a yearly budget in stable coins, instead of volatile Ada.

[AlexDochioiu]

First, to clarify the minUTxO discussion: nobody is suggesting removal. The proposal was always a 10-100x reduction (post UTxOHD introduction). Security arguments against complete removal are irrelevant to what was actually suggested. If there are actual arguments against the reduction, I'd appreciate if you could point out the exact concern so that we can be productive and see if they can be addressed, or if they are complete blockers.

@GeorgeFlerovsky - I disagree with several points:

1. The traditional finance comparison doesn't work here.
The core issue is fragmentation. Users would have two addresses per wallet with different capabilities depending on asset whitelists. When Alice tries to send Bob tokens, which address does she use? How does she know if Bob's stake address accepts that token? This creates decision paralysis and support burden.

2. Additional deposits per registered token.
This introduces another deposit mechanism (on top of stake registration deposits). More deposits mean more locked ADA that users need to understand and manage. This compounds the fragmentation problem.

3. Receiver education burden.
Every payment now requires coordination. Bob can't just give Alice "his address" - he needs to specify which address accepts which tokens. With UTxOs, one address works for everything. This creates constant friction in the most common user action: receiving payments.

4. Extra failure causes.
When a transaction fails, the reason for it now increases to a lot more options. Not whitelisted? Insufficient deposit? Wrong address type? Insufficient balance? Min utxo ada not met? This will create more support tickets and user frustration across every wallet, dApps and exchanges.

5. Ecosystem support burden.
Wallet teams, dApps, exchanges, and support staff now troubleshoot: "Is this token whitelisted? Did you send to the right address type? Do you have enough deposit?" This significantly increases support complexity across the entire ecosystem.

My core concern isn't whether this has dev value for SC use cases since clearly it does. It's that nobody has mapped the actual user journey. How do wallets and dApps surface this? How do users choose between addresses? What happens when they pick wrong? How do they understand which tokens require deposits?

It would be good to see some actual:

• Wallet interaction patterns documented
• Error state definitions (wrong address type, unsupported asset, etc)
• Clear guidance on when users should use accounts vs UTxOs
• Deposit management UX considerations
• Fallback behavior for unsupported assets

Without this, we're shipping technical capabilities that will confuse users and fragment the ecosystem. The comparison to traditional banking doesn't address the actual complexity this introduces.

[fallen-icarus]

My core concern isn't whether this has dev value for SC use cases since clearly it does. It's that nobody has mapped the actual user journey.

@AlexDochioiu I'm not just a smart contract dev. I've also created my own prototype wallet and am working with Lace to create a market-ready version. I've already thought about how to integrate this CIP into the wallet.

I think the issue here is that you are misunderstanding two things:

1. how this CIP works which I think is causing you to over-estimate the UI/UX complexity of this CIP.
2. how financial transactions work.

To start, the sender is not the one who pays the deposit. The recipient pays the one-time deposit when they register the whitelist. The recipient preemptively pays the deposit so that the senders don't need to. This is the reverse of the minUTxO flow where the sender is the one that covers the deposit for the assets they send.

Every payment now requires coordination. Bob can't just give Alice "his address" - he needs to specify which address accepts which tokens.

First of all, this is already the case due to it being a financial transaction. If an entity wants to get paid, it must specify which assets it accepts for payment and where to send the payment. You seem to think the senders will have a choice of addresses which is simply not true in the real world. Whether you are paying a friend, buying something at a store, or sending to a dApp, the sender will be told what address and asset(s) to use.

Second of all, the certificate Bob used to register the whitelist was recorded on-chain. To know what assets are supported by this account address, you just need to lookup the latest whitelist certificate for that account address. (If there is none, then only ADA is supported.) It is exactly the same process as checking where a stake address is delegated. So determining the address' supported assets actually does not require any more coordination than right now.

Recipient UI/UX Flow: Wallets already show reward address balances. It would be pretty straightforward to update these components to:

• Add a button to enable creating/editing an asset whitelist. Selecting the assets would be as simple as searching the tickers and adding them to a list. When the user clicks confirm, the wallet generates the requires whitelist certificate, calculates the required whitelist deposit, and attaches both of them to a tx for the user to sign & submit.
• Show any native asset balances present in the address. Many wallets already show native asset balances in UTxOs which can hold arbitrary assets. Why would it be any different for the reward address' balance?
• Enable withdrawing multiple assets from the account address. It would be as simple as showing the current balances for each asset and asking the user how much of each asset to withdraw.

Sender UI/UX Flow: The sender will already know what asset to send and what address to use. The user will first enter the address. If it is an account address, lookup the latest whitelist certificate for it. Then ask the user to enter asset quantities but only allow quantities for the assets in the whitelist. There is never a reason for a user to send any other asset to the recipient: if a store only accepts ADA and you send them SNEK, the store will not recognize it as a valid payment. So if there is ever a mismatch between the whitelist and what the user is trying to send, either the recipient misconfigured their whitelist or the sender is doing something wrong and is rightly blocked. If the wallet submits the tx anyway, it will fail phase 1 validation and tell you exactly what happened: the sender tried sending an unsupported asset.

Also your approach of only decreasing minUTxO is actually significantly worse than this CIP. Consider airdrops. Airdrops send assets to people without their consent. It is effectively spam. I actually like the high minUTxO because it disincentivizes exactly this spam. If a user actually wants the airdropped token, they can add the token to their account address whitelist. Now the project doing the airdrop can send the user the token without having to pay any deposit. Right now, airdrops are so expensive because of all the minUTxO deposits required. This CIP entirely eliminates that pain-point! Cardano goes from being one of the most expensive chains for airdrops to being one of the cheapest! This is because the receiver pays all deposits for account addresses. And it does so while still deterring spammy airdrops. Just lowering minUTxO would not do this and your suggestion of lowering it by a factor of 10-100 would dramatically increase the number of spammy airdrops. 👎

• Clear guidance on when users should use accounts vs UTxOs

@GeorgeFlerovsky is actually correct about the ideal user flow. If the recipient is willing to accept the asset the sender wants to send, the ideal UX is for the recipient to register the whitelist (also preemptively paying the deposit) and the sender sends the asset to the specified account address. If the recipient does not want to accept the asset, they can optionally provide a normal UTxO address as a backup option. The sender can choose to use this address if they really want to but the minUTxO deposit they must pay properly discourages going against the recipient's wishes.

How do they understand which tokens require deposits?

The sender doesn't pay the deposit for account addresses so from their perspective, none of the tokens require deposits. And again, it is actually quite trivial to know which assets are whitelisted because you can always just lookup the account address' latest whitelist certificate.

When a transaction fails, the reason for it now increases to a lot more options. Not whitelisted? Insufficient deposit? Wrong address type? Insufficient balance? Min utxo ada not met?

This is not true. The only new errors are the first two: not whitelisted and insufficient deposit. The former only applies to senders and the latter only applies to receivers.

I hope this helps clear things up. It really is an easy UI/UX. Beginner-friendly wallets should prioritize using account addresses while normal UTxO addresses will be for more advanced users and smart contracts.