The following text is pulled from the EOSIO github repo maintained by Block.One. We are very happy to read such detailed and observant notes as it is evidence of how closely Block.One is listening to the concerns of the community. For details surrounding the implementation of “additional fees” mentioned toward the end of this post, please see our post here.

Initial Market State and Bootstrapping

Prior to the proper functioning of a Bancor market, initial values for the pools at either side of a connector must be initialized. Generally, this can be accomplished in a few ways but after review the most promising are:

Setting initial “virtual” balances which can never be removed from the pools.

Conduct an initial bidding process to establish seed balances.

While the bidding process is potentially more accurate, it also requires a far more complex launch ceremony. As such, initial development will not support this option. This leaves initial “virtual” balances as the preferred method of bootstrapping a new instantiation of the REX.

In order to provide better documentation to future REX operators, some analysis will occur such that general guidelines for determining initial “virtual” balances is available.

Resilience To Market Resets

In concert with bootstrapping concerns, there are still outstanding features which will attempt to prevent a complete reset of the market except in the rare event of all owners deciding to sell their REX shares. This will likely take the form of a “minimum”ratio of balances in the Bancor pools under which various measures, like delaying withdrawals, will exist to maintain a stable market maker and prevent the market from returning abruptly to its initial state.

Buying REX with staked tokens

The current implementation in GitHub requires liquid tokens in an internal REX balance prior to processing a buyrex action. This presents a strong incentive for active voters to unstake tokens, wait for the refund to process, and then buy into the REX. During this period, the voting influence of these tokens is removed from the elections and this runs counter to the one of the goals of the REX to increase voter participation.

As a result, prior to release, a path for participation in the REX will be added which maintains voter influence during the transition. The exact form of this interaction is in development and will be announced as soon as it satisfies the requirements stated above as well as the requirements of staked token management necessary to prevent resource exploits.

REX Maturity and Testing

In order to prevent possible price manipulation, the concept of maturity is being added to REX purchases. This does not affect the rewards for buying REX but will act as a vesting period over which newly purchased REX cannot be sold. Once outside this time period the given REX tokens can be sold at will. The REX maturity period is now implemented and currently set to 4 days. This value was chosen such that it is longer than the normal resource unstaking period and provides the market adequate time to react. Feedback on the time period is welcome.

Updates on Existing Features

“Toggle” for Additional Fees

In earlier discussions, the deposit of fees generated from other system level functions was contentious and it was stated that there would be a toggle for those fees prior to release. After analysis, it was determined that the best practice was not to provide a soft-switch which would impose RAM and CPU overhead during chain operations. Instead, operators who wish to deploy the REX without those inputs will have clear instructions on how to remove the code, prior to compilation of the contract, so that the deployed contracts are as lean as possible. The code currently in GitHub has been modified to support this removal, if desired, as cleanly as possible.

Voting Rules

One of the goals of the REX is to increase voter participation on a public EOSIO-based blockchain. To achieve this goal, an invariant was established such that participants in the REX needed to EITHER vote for at least 21 block producer candidates OR delegate their voting influence to a registered proxy.

Discussions in the interim have questioned whether this invariant was sufficient to affect a number of different nuanced states in the general voting game-theory. After analysis, the development team has concluded that the current rules are sufficient to at least affect voter apathy. By requiring participants to overcome the initial barriers of entry, the expectation is that the REX will increase voter participation.

Qualitative expectations, such as increasing informed-voter participation OR decreasing active voters with malicious intent, is beyond the scope of a software process such as the REX as the ability to judge these qualities in a voter’s participation is outside of the scope and mandate of the reference system contracts for public EOSIO-based blockchains.

The development team respectfully requests that further discussion on this very contentious topic focus on a more measurable goal of decreasing voter apathy.