Lowering Deposit Requirements on Polkadot and Kusama Asset Hub #45
Conversation
text/000x-assethub.md
Outdated
| ## Unresolved Questions | ||
| - Determining the optimal new deposit amount that reduces the barrier to entry while preventing state bloat remains a subject for debate. What is the balance that allows for inclusivity without compromising the network's efficiency and security? | ||
|
|
||
| ## Future Directions and Related Material |
There was a problem hiding this comment.
I think a good future direction would be to establish some kind of process on how to agree on these values.
Otherwise we will have the same discussion every 3-6 months i guess.
There was a problem hiding this comment.
The proposed prices have been adjusted so that they are not too low, but still have a reasonable maximum at a historical maximum of prices of DOT and KSM.
This of course maybe be an oversimplification and needs to reach an consensus from the community.
text/000x-assethub.md
Outdated
| | collectionDeposit | 10 DOT | 50 $ | 500 $ | 0.1 DOT | 0.5 $ | 5$ | | ||
| | itemDeposit | 0.01 DOT | 0.05 $ | 0.5 $ | 0.001 DOT | 0.005 $ | 0.05$ | | ||
| | metadataDepositBase | 0.20129 DOT | 1.00645 $ | 10.0645 $ | 0.0020129 DOT | 0.0100645 $ | 0.100645$ | | ||
| | attributeDepositBase | 0.2 DOT | 1 $ | 10 $ | 0.002 DOT | 0.01 $ | 0.1$ | |
There was a problem hiding this comment.
It would be nice to see these values in relation to what is actually being stored on-chain.
Then we can compare these values to proven spam-resistant storage prices (like in the preimage pallet).
It should be possible to calculate the DOT/Byte to make it comparable.
Otherwise they are just as random as at genesis, now just 1/10 😉
text/000x-assethub.md
Outdated
|
|
||
| - **Artists**: Primary beneficiaries of the proposed change, particularly those who found the current deposit requirements prohibitive. | ||
| - **KodaDot**: As the facilitator of artists' relations, KodaDot has a vested interest in making the platform more accessible. | ||
| - **Polkadot Community**: Stands to benefit from an influx of artists, creators and diverse NFT collections, enhancing the overall ecosystem. |
There was a problem hiding this comment.
I think the community is also interested in the security of the network.
There was a problem hiding this comment.
Hmm, since this is talking more about the benefits for Stakeholders, would it be okay if I better highlight this point in the drawbacks?
There was a problem hiding this comment.
But the Polkadot Community also benefits from a secure network. Otherwise if the state gets bloated like on Moonbeam then it is not good.
Co-authored-by: Oliver Tale-Yazdi <[email protected]>
|
In theory, all prices should adjust downwards somewhat as more cores become available, due to ongoing optimizations. We'll need Kusama to waste have it's core on gluttons of course. We'll spend some cores on system parachain on Polkadot. Other factors like async backing change the price structure the opposite direction. etc. All this has some floor defined by the number & specs of collator, which again depends upon how system parachains wind up being structured. And elastic scaling releaves that slightly. And all values increase like All this says: It's tricky to automate this too much, but it's still nice not to have the conversation too often. It'd also be nice if there was a for-profit parachain which did specific things like NFTs cheaper than AssetHub. cc @jonasW3F |
|
Hello @ggwpez,
select count(metadata) from collection_entity;
-- 40
select count(metadata) from nft_entity;
-- 2313
select avg(length(metadata)), max(length(metadata)) from nft_entity where metadata is not null;
-- 54.2
SELECT PERCENTILE_DISC(0.5) WITHIN GROUP(ORDER BY length(metadata)) FROM nft_entity;
-- 46
select length(metadata), count(*) from nft_entity where metadata is not null group by length(metadata) order by length(metadata) desc;
-- 74,1
-- 73,3
-- 71,651
-- 66,86
-- 59,33
-- 58,1
-- 53,66
-- 46,1472Regarding attributes on-chain the current utilisation is 0.
Let's do checkup on utilization:
SELECT PERCENTILE_DISC(0.5) WITHIN GROUP(ORDER BY supply)FROM collection_entity where supply > 0 and metadata is not null;`
-- 4
select avg(supply), max(supply) from collection_entity where metadata is not null;
-- 58.65, 1468
What we can do to prevent spam on the AssetHub?There are few ways to make offer better utilization for the assethub NFTs. Second most important is to decrease effective amount of items from Because Third point collection could be potentially TL;DR: There are at least 3 effective ways to prevent 'waste-of-storage', prevent spam, and do effective utilization of the NFTs on AssetHub. |
|
Thanks for the data @vikiival, i normally have no introspection into how it is used. This was very helpful! I checked how many bytes it can take at most to create a collection, and it comes in at around 130 byte. So the 10 DOT seems definitely excessive. When i plug in the 130 byte into the The other constants like What do you think about the values @joepetrowski, @jsidorenko and @rphmeier?
Yea we should do this. @jsidorenko do you have this planned? |
|
Re migration, I'm waiting on the new runtime release to stabilise and then will release the web NFTs migratory. As for the deposits, those enormous deposits don't make any sense and prevent us from having users. |
There was a problem hiding this comment.
The good: I find the updated deposit suggestions quite reasonable and would accept a change toward those.
The bad: This RFC doesn't really provide structured discussion or generalize the issue. It seems like a dump of a bunch of quotes from the forum thread with a very specific goal of making KodaDot's life easier. While that is a nice goal, the RFC should be more general and discuss the economic, technical, and application tradeoffs of storage deposits.
text/000x-assethub.md
Outdated
| ## Explanation | ||
| This RFC suggests modifying the smart contract governing collection creation on the Polkadot Asset Hub to require a lower deposit. The exact amount of the reduced deposit is yet to be determined and should be discussed and agreed upon by the stakeholders. The implementation of this change requires careful consideration of the network's integrity and the prevention of spam, possibly through alternative means such as rate limiting or account verification. | ||
|
|
||
| **Prices and Proposed Prices on Polkadot Asset Hub:** |
There was a problem hiding this comment.
The explanation lacks discussion that I was hoping for about the tradeoffs and how you arrived at these suggested deposits.
text/000x-assethub.md
Outdated
| Additionally, a supplementary proposal aims to augment the network's adaptability: | ||
|
|
||
| > Just from a technical perspective; I think the best we can do is to use a weak governance origin that is controlled by some consortium (ie. System Collective). | ||
| > This origin could then update the NFT deposits any time the market conditions warrant it - obviously while honoring the storage deposit requirements. | ||
| > To implement this, we need RFC#12 and the Parameters pallet from @xlc. | ||
| > -> OliverTY | ||
|
|
||
| This dynamic governance approach would facilitate a responsive and agile economic model for deposit management, ensuring that the network remains both accessible and robust in the face of market volatility. |
There was a problem hiding this comment.
I don't really agree with this approach for a few reasons. One, in attempting to provide stability it actually removes it because the DOT-based deposit can change so often that NFT issuers don't even know how much DOT they should acquire in order to plan a few weeks in advance.
Two, it does not scale. There are deposits all over the system. This group could then find themselves perpetually changing tons of deposits.
I don't see any need to update deposits more than every six months, which is well within the realm of runtime upgrades. If deposits should be tied to some fiat value, then on Asset Hub they should just directly declare the deposit in a chosen stablecoin. If the deposits are in DOT, and users want to hold stablecoins, then wallets can easily batch an Asset Conversion swap in front of a creation call.
This seems like an arbitrary imposition. The economics should provide reasonable bounds on usage, not data overflows.
It looks like those values are just manually set. I'm in favor of generally using the |
Co-authored-by: joe petrowski <[email protected]>
Co-authored-by: joe petrowski <[email protected]>
|
@joepetrowski as per commit 3ad68dd can we keep the deposit as 0.01 DOT per item deposit? |
It was 0.005 before, you want it back to 0.01? |
Ah, I must have misread the |
|
Thank you so much @joepetrowski for your changes! What are the next steps for this RFC? |
| Based on the storage footprint of these items, this RFC proposes changing them to: | ||
|
|
||
| ```rust | ||
| pub const NftsCollectionDeposit: Balance = system_para_deposit(1, 130); |
There was a problem hiding this comment.
I think there is more than one storage item, so to be really precise it should be something in the form of system_para_deposit(1, x) + system_para_deposit(1, y) (Collection and CollectionRoleOf) but i dont want to block this RFC much longer.
Guess this approximates it well enough for now.
There was a problem hiding this comment.
If there are two items then we should probably be consistent. It should still be a large reduction (from 10 to 0.4 instead of 0.2).
Broadly speaking though, and w/r/t the idea of finding an "optimal" deposit, it can never be perfect. As long as you can't start adding more storage items for free (i.e. deposit is directly proportional to storage items added) then it's well-designed. Factors of 2x are just not significant (and it's a bit arrogant to think we can get it so precise). I think probably 10x is the best we can hope for with these parameters.
| ### Performance | ||
|
|
||
| The primary performance consideration stems from the potential for state bloat due to increased | ||
| activity from lower deposit requirements. It's vital to monitor and manage this to avoid any |
There was a problem hiding this comment.
Maybe @KarimJedda or someone from KodaDot is tracking NFT activity?
There was a problem hiding this comment.
I think @vikiival is in a good position to answer this question, since he created indexer for AssetHub.
There was a problem hiding this comment.
Someone from KodaDot is tracking NFT activity?
-- current nfts 9792
select count(*) from nft_entity where burned = false;
-- current collection 98
select count(*) from collection_entity where burned = false;
-- all nfts 9883 (~ 100 burned)
select count(*) from nft_entity;
-- all collections 138 (40 destroyed)
select count(*) from collection_entity;
-- all interactions that is not mint (list, buy, burn) 16_019
select count(*) from event where interaction <> 'MINT';Top 3 creators on AHP
[{
"count": 41,
"issuer": "15CoYMEnJhhWHvdEPXDuTBnZKXwrJzMQdcMwcHGsVx5kXYvW"
},
{
"count": 24,
"issuer": "1ULZhwpUPLLg5VRYiq6rBHY8XaShAmBW7kqGBfvHBqrgBcN"
},
{
"count": 6,
"issuer": "1nYXo6fd1fjVm1ixUwycELfjTyaxxzVHAVgZ8S8H6cZMfY7"
}]Data are public via our @subsquid indexer or Typescript API (kodadot/uniquery)
text/0045-nft-deposits-asset-hub.md
Outdated
| pallet, the system could take the lower value required. A sigmoid curve would make sense for this | ||
| application to avoid sudden rate changes, as in: | ||
|
|
||
| $$ \frac{\mathrm{min(DOT deposit, stable deposit)} }{\mathrm{1 + e^{a - b * x}} }$$ |
There was a problem hiding this comment.
| $$ \frac{\mathrm{min(DOT deposit, stable deposit)} }{\mathrm{1 + e^{a - b * x}} }$$ | |
| $$ startdeposit + \frac{\mathrm{min(DOTdeposit, stabledeposit) - startdeposit} }{\mathrm{1 + e^{b * a - b * x}} }$$ |
There was a problem hiding this comment.
Ah, I see what you are doing. But you don't need b * a because its evaluation is implicit in the value of a.
There was a problem hiding this comment.
Okay but then the code implementor has to know that a = x0 * b, where x0 is the threshold level of collections or items.
Co-authored-by: Aurora Poppyseed <[email protected]>
|
Proposal looks amazing 🚀 big kudos to @joepetrowski, @poppyseedDev and others ❤️ ^-^ |
Co-authored-by: Oliver Tale-Yazdi <[email protected]>
|
Hey @ggwpez could you tell us what are the next steps with this PR? |
We will soon propose this for on-chain voting 🙏 |
|
/rfc propose |
|
Hey @joepetrowski, here is a link you can use to create the referendum aiming to approve this RFC number 0045. Instructions
It is based on commit hash c7edfc33ccb57e881557a5cbbeed478e0d4efc1a. The proposed remark text is: |
|
Voting for this referenda is ongoing. Vote for it here |
|
/rfc process |
|
Please provider a block hash where the referendum confirmation event is to be found. Instructions to find the block hashHere is one way to find the corresponding block hash.
|
|
/rfc process 0x3ac549f24ecf451eb4d45f16f4fff694b0a103f8006ff9ab7f16c484bcfb535c |
|
The on-chain referendum has approved the RFC. |
|
@poppyseedDev, do you have an update on the status of this RFC? |
|
@anaelleltd it's done and deployed |
anaelleltd
added
Implemented
RFC-00xx-assethub, proposes lowering deposit requirements for NFT collection creation on Polkadot and Kusama Asset Hub to make it more accessible for artists. It draws upon the discussion in the Polkadot Forum. While there are concerns about state bloat, the RFC also considers future governance models to dynamically adjust deposit requirements.