When a parachain is registered, the parachain manager is responsible for the cost of storing the validation code on-chain. After successful registration in the current system, parachains are allowed to perform code upgrades without being required to pay for the differences in validation code size.
This means that someone could theoretically register a parachain with minimal code and then, at a later point, freely register validation code that is significantly larger than the original code.
This is obviously a problem that needs to be fixed, as being imprecise about the deposit requirements for storing data on-chain can lead to issues in the system.
This is something that needs to be fixed before the release of the new Coretime model.
In <a href="https://github.com/paritytech/polkadot-sdk/pull/2372">PR #2372</a> I have proposed a solution that would solve this problem and I implemented it. However, after having a lot of meaningful discussions on this PR a different approach was <a href="https://github.com/paritytech/polkadot-sdk/pull/2372#discussion_r1461873933">proposed</a> where the dynamic fee based model that was implemented in this PR would be added at a later stage.
<a href="https://github.com/paritytech/polkadot-sdk/pull/3020">PR #3020</a> Is the implementation of phase #1 described in the proposed approach.
This is something I have dedicated a lot of my time to and I would love to continue working on this.
<span style="font-family: S&ouml;hne, ui-sans-serif, system-ui, -apple-system, 'Segoe UI', Roboto, Ubuntu, Cantarell, 'Noto Sans', sans-serif, 'Helvetica Neue', Arial, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji'; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre-wrap; background- text-decoration-thickness: initial; text-decoration-style: initial; text-decoration- display: inline !important; float: none;">This is a tip request for the efforts I've invested so far.

When a parachain is registered, the parachain manager is responsible for the cost of storing the validation code on-chain. After successful registration in the current system, parachains are allowed to perform code upgrades without being required to pay for the differences in validation code size.

This means that someone could theoretically register a parachain with minimal code and then, at a later point, freely register validation code that is significantly larger than the original code.

This is obviously a problem that needs to be fixed, as being imprecise about the deposit requirements for storing data on-chain can lead to issues in the system.

This is something that needs to be fixed before the release of the new Coretime model.

In [PR #2372](https://github.com/paritytech/polkadot-sdk/pull/2372) I have proposed a solution that would solve this problem and I implemented it. However, after having a lot of meaningful discussions on this PR a different approach was [proposed](https://github.com/paritytech/polkadot-sdk/pull/2372#discussion_r1461873933) where the dynamic fee based model that was implemented in this PR would be added at a later stage.

[PR #3020](https://github.com/paritytech/polkadot-sdk/pull/3020) Is the implementation of phase #1 described in the proposed approach.

This is something I have dedicated a lot of my time to and I would love to continue working on this.

This is a tip request for the efforts I've invested so far.

Problem Statement:
- The current system allows parachains to register with minimal code and later freely register validation code that is significantly larger, leading to imprecise deposit requirements for storing data on-chain.

Significance:
- Being imprecise about deposit requirements can lead to issues in the system.
- This problem needs to be fixed before the release of the new Coretime model.

Proposed Solution:
- Implement a dynamic fee-based model to accurately account for the cost of storing validation code on-chain.

Expected Outcomes:
- Improved accuracy and fairness in deposit requirements for storing data on-chain.
- Mitigation of potential issues in the system.
- Continued development and improvement of the proposed solution.

#601 Retroactive reimburesement for para upgrade fees contributions

No Active Proposals