Block.One New EOSIO Resource Allocation Proposal

Block.One recently published their new proposal for resource allocation in EOSIO chains. The proposal was prompted by the problems that attacked the EOS mainnet, when due to an extreme increase in demand for resources, the Resource Exchange was unable to stabilize its liquidity. This made the blockchain unusable for most users who did not have enough resources.

The changes have already been proposed in the EOSIO Github Repository and the pull request was included with the recent release of eosio.contracts v.1.8.4-rc1. So they would be ready to be implemented.

In the proposal, the Block.One team points out that the network, although unusable due to the low liquidity on REX, was not using most of the available resources, which still amounted to 70%. Making the whole system inefficient.

For this reason they propose a new change in the Resource Exchange system, which will allocate 100% of the existing resources, creating a more effective system.

---

Proposed changes:

• Users will pay a resource rental fee to be granted 30 days worth of CPU/NET from the total supply
• Every 30 days the rental must be renewed
• Pricing is automatically adjusted using a market based mechanism
• Staking tokens will enable users to receive certain fees from name auctions, RAM fees, and proceeds from CPU/NET rentals.
• Staking tokens will no longer guarantee an allocation of resources

---

"The objective of proposing a transition from a resource entitlement model to a leasing or rental model is to remove the influence of speculative markets over resource pricing. Introducing a rental market with pricing based on overall resource utilization will make resource allocation more predictable and reliable for the community."

---

How is the rental price determined?

The price for renting resources will be based on supply and demand. When the convergence of these leads to a price increase, the increase will be instantaneous, but this will not be the case for price decreases. In latter case, the price decreases will be diluted over time, to prevent large renters from leveraging an undesirable renting advantage.

The price is determined by the difference in the network utilization prior to the rental purchase versus the new utilization of resources based on the size of the rental. For example, a user looking to acquire 5% of the CPU/NET supply for 30 days would pay a price equal to:

MAX(P(InstantUtilization+5%),P(AdjustedUtilization+5%))) – MAX(P(InstantUtilization),P(AdjustedUtilization)))

The formula shows how the difference between the current utilization and the level of utilization as a result of the rental order is used to calculate price

---

How can we move from the current model to this new approach?

As previously explained in a post by Dan Larimer and in an EOS Go news, the easiest way to move from the correct system to this new model is by "virtually" increase the supply of the CPU and move the newly generated one within the contract system.

In this way the CPU "real" time within the chain remains stable while the ownership of the "virtual" one is transferred to the new rental market. Once the total virtual supply is increased 100 times, the contract system would hold 99% of the entire real CPU and we could then proceed with the new model.

After that, the contract system would distribute the total CPU within the REX pool and the revenues would be distributed among the staked EOS holders within REX. In this way we would be able to gradually shift into the new system.

---

Sources:

• EOSIO Resource Allocation Proposal
• New CPU and REX approach proposed by Dan Larimer
• rentbw EOSIO GitHub
• EOSIO.Contracts v1.8.4-rc1 Release Notes

Suggested News