Quote from: DdmrDdmr on March 03, 2020, 11:12:37 AM

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:

Code:

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:

Quote from: Coin-1 on December 05, 2018, 06:59:24 PM

Code:

AVAILABLE_sMERITS = floor(RECEIVED_MERITS / 2) - SENT_MERITS

To calculate the aggregated nSmeritsAvailable index, you probably need to modify your query like this:

Code:

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.