SmartRewards to be improved further


SmartCash is intended to become a widely used cryptocurrency, thus low volatility is critical here.

It is clearly seen that SmartRewards payouts are affecting the price. Sometimes little, sometimes a lot.

We recently saw an announcement that new rewards cycle will be extended to 90 days.
That means thrice more rewards will be paid in certain date risking the price stability even more.

The best solution to volatility problem would be an individual period count for each address (similar as implemented in bank deposits). I know that it would be more tricky to implement an improved algorithm, but it is possible. This way we won’t see price dump on certain date as each address will have own payment cycle.

Any address with > 1000 SMARTs is added into the waiting list with the date of last outcoming transaction or the date of the last SmartRewards payout. This way there won’t be single payout date for all the addresses.

P.S. Voting requirement is a great improvement, appreciated.


Obviously this solution is much more complicated technically, though if implemented it would serve for much better price stability. And let’s be sincere - the project, seriously intended to become a currency can’t allow planned price swings neither monthly nor quarterly.


Thanks for posting. Interesting approach of spreading the pay out day. I do like to concept! Nevertheless I see a few things that should be considered first. In what day range should the payout take place? Having a 30 day range would be considered unacceptable by most I assume. As it is not plannable, consider having your pay date sometimes on the 5th, sometimes on the 28th. Having a too short day range would not address the issue that you describe of people dumping their smart rewards on the payout day.

The main question I have is wheather the smart rewards are actually the main source for the “dumping”? I dont think, and considering it will change to 90 days soon, it will hurt not to get paid.

It would be interesting if someone has time and skill to go through the smartcash addresses and analyses the percentage of addresses that receive smartrewards which after pay day have an outgoing transaction. Also the percentage of addresses used for smartnodes so far had outgoing transactions. So basically check the root cause first and then revisit the proposal.


I don’t think smart rewards are not the main source for dumping

Thanks for the feedback. I think you didn’t get what I mean. Or I wasn’t clear enough.

I suggested to count payment cycle for each address individually.

Here is an example. You topped up the address with 1000 SMARTs. The system constantly checks all SMART addresses. It noticed new address with more or equal to 1000 SMARTs and adds it to SmartRewards addresses list. So if you topped up your address, let’s say on 8th, you will get the reward on 8th in 90 days.

When SMARTs are spent from the address, but the amount is still eligible for SmartRewards, the system resets the day counter for relevant address, so you’ll get the rewards in 90 days starting from the day when the last outgoing transaction occurred.

This way each address will receive SmartRewards on its own date but with the same 90 days period.


Thanks for the example.Now I get what you mean. First I understood it more as a payment zone like feature (similiar to how smartnodes are payed). Now it is clear and a better approach, though complex and I guess the voting requirement (each address shall at least vote once in 90 days) should relate to the same 90 day window as used in your example (= starting after last transaction out or first time address >= 1000 Smart).