Are you certain about those numbers? I make it nearly double to them, after halving the available sMerits per individual account. As of last Friday I make the minimum amount of sMerits in accounts being that of:
All Accounts (including Banned Accounts) that have received sMerits at some point:
nSmeritsAvailable nReg
139 589 33 065
Banned Accounts (that have received sMerits at some point):
nSmeritsAvailable nReg
10 461 5 161
That would make the minimum available sMerit toll around 129 128 sMerits.
The nSmeritsAvailable is derived from aggregating the individual calculus:
SUM(case when (meritReceived - meritsent)<0 then 0 else floor(meritReceived - meritsent)/2 end) nSmeritsAvailable
Note: The available sMerits are a bare minimum, not considering non-retrievable data from available airdropped sMerits nor precise data from Merit Sources.
Since a user who receives
1 merit only earns
0.5 sMerit, I use the following formula:
AVAILABLE_sMERITS = floor(RECEIVED_MERITS / 2) - SENT_MERITS
To calculate the aggregated
nSmeritsAvailable index, you probably need to
modify your query like this:
SUM(case when (floor(meritReceived/2)-meritsent)<0 then 0 else floor(meritReceived/2)-meritsent end) nSmeritsAvailable
By the way, I do not know how to
correctly deal with transactions which have
negative merit value. In this case my analyzer does
not reduce the sMerit amount of a user. For example, the user received 2 merits, so he/she earned 1 sMerit. If 2 merits were removed later, my analyzer subtracts the merit amount by 2, but does
not subtract the sMerit amount by 1, because users can send earned sMerits
immediately. As a result, such a user will have 0 merit and 1 sMerit.