Hi Solana Community! It’s Matt here from the Kin Foundation.
The purpose of this thread is to propose an adjustment to the logic of the Solana Rent Program to be responsive to the price of SOL
The Solana blockchain introduces the concept of “Rent” for new account creations. As the documentation states:
“Since validators on the network need to maintain a working copy of this state in memory, the network charges a time-and-space based fee for this resource consumption, also known as Rent.”
This Rent cost has two features: (1) it compensates validators for the hard cost of storage, and (2) it deters inefficient account creation - either malicious or non-malicious.
There are two ways that rent is administered:
- Pay per Byte: rent is collected in each epoch (~48 hours)
- Rent Exemption: if an account maintains >2 years of rent then that account is exempt from the rent charges
For the purpose of this analysis, we will be assuming most accounts meet the second criteria of being “rent exempt”.
The Solana documentation has indicated an intention to adjust the cost of rent over time: “Currently, the rent cost is fixed at the genesis. However, it’s anticipated to be dynamic, reflecting the underlying hardware storage cost at the time. So the price is generally expected to decrease as the hardware cost declines as the technology advances.” We have seen in the last three months that SOL is susceptible to rapid price increases so we believe it is prudent to be proactive in recommending a system that is sensitive to these dynamics.
The challenge with the current structure is that rent is priced in SOL (19.05 lamports per byte-epoch which is equal to 0.00089 SOL for rent exemption of a minimum account size) and is not responsive to the price movements of SOL. At the current price of SOL the dollar cost of rent is ~$0.04, which can be anticipated to further increase if not changed. While this may not seem prohibitively expensive, it has a detrimental impact on developers building for the mainstream consumer, including large scale consumer apps interested in bringing their existing user bases to Solana.
Solana is built for high scale to support billions of consumers. To onboard these users into the crypto economy, many developers will choose to subsidize the account creation cost to make it simple for a new user to get on board. At $0.04 per user that starts to become a non-trivial expense (ie. 1 million users = $40k, or a medium size app with 10 million users = $400k). Anecdotally, here at the Kin Foundation we are in regular contact with apps of this size and larger interested to offer digital currencies to their users but the cost of rent to onboard large user bases to the Solana network is of material concern. We do understand that many developers choose to push the cost to their users, which for some applications makes sense, but in these instances our view is that the cost to the consumer should always be as close to the breakeven hard cost to remain competitive in an emerging space.
The Solana ecosystem needs to be attune to the friction points for mainstream adoption, and this includes for new users to get on board. So our view is that we should make it feasible for a developer to subsidize this fee if they so choose.
Note: many accounts far exceed the minimum account size. Accounts in the Kin ecosystem, for example, require 0.002SOL for rent exemption which is presently equal to ~$0.09 per account. Earlier this year, Kin migrated to the Solana blockchain 55 million user wallets belonging to 32 applications in the Kin ecosystem. The cost exceeded $1.5 million USD in SOL to create these accounts - noting the market price of SOL at the time was significantly less than it is today. Other consumer applications and services will face a similar barrier to on-board, which entails a significant cost in bringing large amounts of users to Solana.
As stated in the documentation, the primary function of rent is to compensate validators for their hard costs of storing account data (even in a rent exempt scenario that SOL is effectively staked so there is an indirect payoff for validators). The hard costs of validators are conceivably incurred in dollar terms, so we believe that the Rent cost should be responsive to this.
- Beginning on or about June 1, Rent is recalibrated to a target of 1.5x the hard validator cost of storage in USD
- This price is determined using the trailing median price of SOL over the previous 30 epochs
- Every subsequent 30 epochs, the median price over the previous 30 epochs is taken
- If that median price is <0.75x or >2.25x the hard cost of storage then the price is recalibrated to 1.5x target
Note: An important consideration in implementing this fee structure is ensuring consistency for end-users in the event that the cost changes, but their wallet is already rent-exempt. With this proposal, if there is an increase in the cost of rent, rent exempt accounts will continue to be rent exempt, but pay per byte accounts will have to adapt. This is similar to a fixed rate/variable rate mortgage or other analogous financing obligation.
- Tighter or longer time bounds on the measurement periods
- 30 epochs (~60 days) was selected to give a sufficient amount of time for the median to be insulated from short term periods of volatility while not being so long that rent is unresponsive to market shifts (like what we’ve seen in the last three months)
- Real-time price adjustments (ie. rent is denominated in USD)
- While this might bring rent closest to parity of the dollar cost for hardware cost it would create challenging dynamics with a constant moving target of the rent requirement
- Bulk/Volume Rate Discount Program
- Developers who are enabling large numbers of wallets at once (e.g. Foundations/Wallets/Large Apps) would be given a substantial discount on rent, especially justified if they are subsidizing the rent by insulating users from the on-boarding friction. Administration of such program would need to be thought out, e.g. Solana could reserve certain address blocks at a given rate and assign them exclusively to the developer wholesaler who will be given a given timeframe to roll them out or lose their discount.
- Do nothing
- Of course, an option is to leave the program as it is. Our view is that this will stifle the momentum in the Solana ecosystem to reach mass adoption by making it more challenging to onboard large userbases at scale
In addition to the above pricing, we believe it will be a simpler user experience for SPL tokens to be able to pay rent in that SPL token rather than having to manage a two token system ie. when a user has to deposit SOL in a wallet to initialize the account to accept a transfer of OXY. The Solana team recommended a simple system to have SPL tokens deposited as rent into an account and at the end of a block the validators clear that account. We recommend that this is implemented to further simplify the process, but this does not remove the need for a dynamic system on the cost of rent.
While there has been some third party developments in this regard in relation to tx fees, this is generally supportive of the notion that such solutions are necessary and should actually be features of the Solana network in itself.
Thanks for reading and we appreciate if you could show your support.