The proposal system introduced in the HF21 is a big improvement and step forward in the blockchain. Thanks to this Steem is now a bit more auto sustainable in terms of developments and contributions.

In this sense, I also want to give my contribution. The objective of the current proposal is to improve the steem code, concretely, the proposal system itself. Although the work done by @blocktrades and his team is very good and appreciated, there are still some things to fix and it also needs new features relevant to both creators and stakeholders.

Improvements

The improvements I propose to develop are:

• Vote weight
• Add maximum payment
• Calculate the total paid
• Fix scalability issues

Vote weight

Currently, when a user votes for a proposal he is voting with all of his steem power, there is no way to define a weight.

For big stakeholders this is a problem. Suppose this situation: A big stakeholder votes for a return proposal and votes for a proposal for a new development. He really wants the new development but it is not reaching the threshold. If he removes the vote from the return proposal then the development will start getting the funds, however, the return proposal lose a lot of votes and then other proposals can cross the barrier and get funds too.

This problem can be solved by giving the possibility to vote with different vests. In this case, the stakeholder could reduce the vote for return proposal a little bit in order to reduce the threshold for the development but not too much and the barrier continues for the rest.

Maximum payment

Suppose this scenario: A proposal is created to work during 15 days and asks a daily payment of 100 sbd. Then the expectation is to to receive 1500 sbd. What happens if at the end of the period the total payout is only 1000 sbd? There are some ends in the current implementation:

1. The contributor finishes the work despite the final payout. We rely in the good will of the contributor but sometimes a reduction of the budget is not enough to finish the work.
2. The contributor creates a new proposal asking for the remaining amount. This is a good solution, but the problem is to get the again the attention from the stakeholders, which have to vote again the new proposal.
3. The work is not finished or it is partially finished (if applies).

One solution to these problems is the possibility to define a maximum payment. Following the example above, the contributor could create a proposal to work during 25 days, ask a daily payment of 100 sbd, but put 1500 sbd as the maximum payment. In this sense there are 10 additional days to complete the payment, but it can not increase beyond 1500 sbd.

Calculate the total paid

In the current implementation the unique way to calculate the total paid to an active proposal is by consulting all single payments using the history api.

If we implement the maximum payment described above, then the total paid must be added too, and it can be easily obtained by calling the proposal details.

Scalability issues - Total votes

Currently, each hour, all votes from all active proposals are computed in order to sort them and distribute the payments.
If a single proposal is voted by 12000 users then, each hour the blockchain will add the steem power of all of them, which is not scalable to hundred of proposals and thousands of users.

The best way to handle this issue is by calculating only the increments. If a new vote comes in, then the total is incremented. If it is removed then the total decreases. If there is a power down then the proposals voted decrease. If there is a power up the new vests are added to the proposals voted.

In this sense, after the end of the period there is no need to calculate the votes, just sort them and distribute the payments.

This part will also solve the current problem with the inactive proposals, which the total votes are not calculated because the inactive proposals are not in the schedule of payments.

Timeline and qualifications

The total payment for this work is 4800 sbd, distributed in 30 days with daily payment of 160 sbd.

The new code will be submitted as a pull request to the principal repository of steem.

Qualifications

I've been working as principal blockchain developer in a pilot project for the European Commission during almost one year. This time has helped me to get a lot of experience with respect to the core of the steem blockchain and I would like to continue doing more improvements.

I've made some minor contributions to the steem repository:

• Fix account_update2 in condenser_api
• Fix sbd print rate
• Fix update median feed price
• Fix FC ASSERT downvotes

I've been contributing to the dsteem javascript library:

• Support operations for SPS and account update2

How to vote

To vote for this proposal follow this link.

To consult this proposal:

• https://joticajulian.github.io/steemexplorer/#/proposals/23
• https://steemproposals.com/proposals/jga
• https://steempeak.com/proposals

Acknowledgment

These ideas are the result of discussions with some users and witnesses, especially @smooth, about improvements that they would like to see implemented in a later hardfork.