Staking Functionality

Upon successful artwork sales and weekly inflation runs on AOVR tokens, the ovr-program requires a mechanism for distributing the appropriate SPL tokens to the corresponding recipients. As it is not feasible to keep large lists of addresses on chain$^{18}$, nor possible to present large numbers of accounts to the ovr-program function call, it is not possible for the ovr-program to transfer tokens directly to a large number of recipients.

A proposed solution is to extend the ovr-program (or a separate program), henceforth the staking program, which in essence would allow a large number of balances to be updated in an atomic fashion without the need to pass in a large number of accounts into the function call. Instead of transferring tokens directly, a balance on a ledger that represents the balance owed to a specific account would be increased. This allows the staking program to update a large number of balances, limited only by computation limits. The stakes would be stored in one of N staking slots, grouped into a number M of staking pools. Each pool would provide rebalancing and withdrawal functions, such that at any time the rightful owner of the stake could withdraw their tokens or read their balance. The solution would not allow for an infinite number of stakeholders, but a reasonable number, e.g. 100 staking pools with 100 slots within could provide 10,000 individual staking slots. The full details of the proposal are found in Appendix 1 to this document.

______________________________________________________________________________

$^{18}$Storing large data sets on Solana accounts is limited due to high rent costs. Solana program request size limits mean not all accounts that would need to be written to could be passed into the function call.