Referendum #234: Data availability, retroactive funding and on-chain invoices

I wonder if the solution here isn’t something like the following:

  1. Blockchain has configured storage details
  2. Calculate the storage cost of extrinsic X (using data from A)
    1. Discount rate, size of X, term/horizon can be finite/infinite
    2. Value as a growing annuity, annuity due, or perpetuity as required
  3. Blockchain treasury account invests amount from 2.2 at the discount rate obtained in 2.1
  4. Storage costs paid from the cash flow stream generated by 3.

This raises questions that have some implications and requirements.

  • What is the appropriate discount rate?
    • I’d suggest whatever Black’s Zero-Beta CAPM indicates, is a reasonable starting point. However, we are some way from knowing how to get that for even the simple token considered there - which DOT is not.
  • The only way the treasury can assure there exists an investment that pays a return at least the discount rate is to make the return to system staking be that discount rate.
    • The staking yield vs staked % calculation would need to change to ensure the at least condition above.
  • The treasury then would need to be able to nominate validators by staking the amounts obtained from 3 above.
  • Changes to the staking yields now have another ‘thing’ to take into account.
    • What happens when/if the required rate of return decreases?
    • The DOT required rate of return will fluctuate. Like all securities…

@rich this has the property of removing/avoiding the secondary dependency. At the cost of having to create a new category of node. Specifically, storage nodes.

Will the economics of storage nodes work out such that the data fees are not a disincentive?

1 Like