Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Total supply not updated after custom, cashback, transaction #4015

Korben3 opened this issue Jul 27, 2019 · 3 comments


Copy link

commented Jul 27, 2019


After performing the custom cashback transaction from the provided SDK tutorials. It seems that the total supply has not been updated.

call after tx with 10% bonus was broadcasted:
result: { .<snip>.. "supply" : "10000000000000000", "milestone" : "0" }, "links" : {} }

The transaction was broadcasted successfully. Balances of both accounts are updated. Since there are now more tokens on the network, just as when tokens are forged, the total supply should be updated as well.

@sridharmeganathan sridharmeganathan added this to the Sprint 4 milestone Aug 7, 2019

@shuse2 shuse2 added this to To Do in Version 3.0 via automation Aug 7, 2019


This comment has been minimized.

Copy link

commented Aug 13, 2019

Its actually not possible or at least not possible in current structure. Total supply is calculated statically from some basic values. Which are genesis block value and rewards. Its not possible to change that value in case of cash back transaction. Even if we change it runtime, in case the application restart we will loose that.

And its not possible to look into storage layer and find out which transactions generated extra supply. The only possibility left is to persist this value, even then finding that which transaction generated how much extra supply is not possible in current structure or not efficient.

@shuse2 We may be able to calculate runtime value from storage, but with recent change in DPOS will restructure the rewards values. So I suggest to not address this issue at the moment and after we are done with BFT and new DPOS restructuring.


This comment has been minimized.

Copy link

commented Aug 13, 2019

@nazarhussain Thank you for looking into it, and agree with your points.
Let's schedule it later and think about the solution more carefully.

@shuse2 shuse2 removed this from To Do in Version 3.0 Aug 13, 2019

@shuse2 shuse2 removed this from the Sprint 4 milestone Aug 13, 2019


This comment has been minimized.

Copy link

commented Aug 14, 2019

It could be solved quite simply by keeping track of added and deduced amount in total, in very simple field in db ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
5 participants
You can’t perform that action at this time.