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 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 where the dynamic fee based model that was implemented in this PR would be added at a later stage.
PR #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.
For reference, we have historically had a range of 20 -> 150 DOTs for open source contributions to
polkadot-sdk. Nonetheless, I agree that the scope and importance of this work is beyond that, and deserves a larger top. But, we should not set a trend that any contribution topolkadot-sdkwould get similar tip values and such should be evaluated on a case by case basis.Good luck with the rest of your implementation!