Following the announcement of CIP-107, we received feedback from our team and the community. Two general cases were raised:
- When minting NFTs based on the ERC721- standard, these NFT smart contracts will permanently occupy storage and cannot be burned with CIP107 implemented.
- When minting NFTs based on the ERC1155-standard, the storage space occupied by these NFT smart contracts may fluctuate continuously. During this fluctuation, the storage collateral of the smart contract will be constantly burned, increasing the cost of contract storage without a theoretical upper bound.
With the above-mentioned cases, the Foundation decided to improve CIP-107 with the following principles:
- The “pay once, use forever” expectation for storage collateral should not change.
- If the storage usage upper bound of a contract does not increase, CIP-107 should not increase its cost even if the total storage fluctuates.
- CIP-107 should bring significant token burning.
To achieve these goals, we made the following changes to the original CIP-107 (the following is a draft version for discussion):
- We changed the time point for burning tokens from “refunding storage collateral” to “sponsoring storage collateral.” Sponsoring storage collateral corresponds to the payment phase in “pay once, use forever.” External owned accounts (EOA) are not involved in the sponsorship mechanism and will not burn tokens due to CIP-107.
- To prevent an increase in the storage cost of ecosystem applications, the burned tokens are converted into “storage points” according to a proportion §. When paying for storage collateral, storage points are equivalent to the corresponding amount of burned tokens. When releasing storage space, storage points will be refunded just like tokens and can be reused. The differences between storage points and tokens are that storage points cannot be redeemed for tokens, do not generate collateral interest, and cannot circulate.
- The proportion p is set at 50% in the initial state and can be adjusted by the DAO. The DAO controls a
STORAGE_POINT_PROP
parameter by voting, which is initialized to 1 with 18 decimals. p is defined asSTORAGE_POINT_PROP/(1+STORAFE_POINT_PROP)
. For example, in the first voting cycle, if all votes agree to increase the proportion p,STORAGE_POINT_PROP
will increase to 2, and p will correspondingly increase to 2/3 = 67%.
F.A.Q. from early discussions:
- Are “storage points” transferable?
No, storage points belong to the sponsored contract only. - Can “storage points” be refunded?
CFX or storage points may be refunded when releasing storage space, but storage points can only be used for subsequent storage collateral. - Will there be CFX burning when a new sponsor replaces an old sponsor?
Only the incremental part will burn CFX. For example, if the old sponsor grants 100 CFX, of which 50 were converted into storage points, then if the new sponsor only provides 50 CFX, there will be no CFX burning. If the new sponsor provides 70 CFX, half of the incremental part 20 CFX will be burned and converted into storage points.
Possible impacts of CIP-107:
- For contract developers and users, they do not need to care about the implementation details of CIP-107 and the difference between storage points and storage collateral.
- For contract sponsors, when a new sponsor replaces an old sponsor, the CFX that the new sponsor needs to send to the old sponsor will decrease.
- For miners, the block reward will decrease by 0.001 CFX.