How ranking of help requests works

This page publicly explains how the score that ranks help requests is calculated at the end of each round (a period of mutual aid of free length — an hour, a day, a month, a year, decided by the administrator), for the case where funds are not enough for everyone. There is no black box: the code that implements this formula is public, tested, and directly readable — the scoring engine lives in backend-php/src/scoring_engine.php and the distribution engine in backend-php/src/distribution_engine.php.

Why a score at all?

The association runs on gifts, funded by members' voluntary mining. When a round's pot is enough to cover every request, everyone gets the full amount they asked for — the score does nothing in that case. It only steps in to decide in what order to pay when the pot is not enough for everyone.

There is no minimum time as a member or minimum mining time required to be allowed to ask for help: a brand new member can ask for help right after signing up, and will be paid normally if funds allow it. The score only puts them at a disadvantage when funds are insufficient — and even then, only partially (see below).

The formula

final_score = 0.30 * amount_bonus_malus
            + 0.15 * recurrence_malus
            + 0.20 * normalized_votes
            + 0.15 * normalized_mining_time
            + 0.10 * normalized_hashpower
            + 0.10 * normalized_seniority

Component	Weight	What it rewards
Gap to the round's average requested amount	30%	Asking for a reasonable amount compared to other requests in the round
Recurrence penalty	15%	Not having asked for help several rounds in a row (never a full 100% block)
Votes received	20%	Community support (optional vote, one per member per round)
Mining time this round	15%	Having contributed by mining during this round
Average hash power	10%	Power contribution (deliberately low weight so big miners don't dominate)
Seniority	10%	Loyalty to the association (capped at 24 months so it doesn't freeze the ranking)

The full detail of the calculation (each component, its value, and its contribution to the score) is stored for every member and every round, and can be checked on the Transparency page — never just the total.

Where the data comes from

Mining time and hash power come exclusively from the mining pool's public API (a source that is hard to fake), never from a member self-report — collected by the administrator on their own machine and pushed to the server; the web server never talks to the pool itself.
Votes are weighted by the voter's seniority, to limit the impact of coordinated newly-created accounts.
The requested amount and its comparison to the average are based only on requests made during the current round.

How the money is shared out

Platform running costs (10% by default, adjustable based on real costs — hosting, Monero network fees...) are taken out of the round's gross pot. The gross amount, the rate applied, and the resulting net amount are always published publicly — never silently.
Requesters are sorted by final score, highest first. If there is a tie, whoever asked for the smallest amount goes first.
The net pot is paid out in that order: each requester gets the full amount they asked for, until the pot can no longer cover one in full.
As soon as that happens, the payout stops right there: no partial payment at the last rank. What is left in the pot is carried over to the next round (and added to its net pot, without being taxed a second time) — this same real payout also closes the round and opens a new one. Unpaid requesters can post a new request in the next round.

What this system does not do

It does not actively check whether mining numbers are honest (no technical cheat-detection): a manual report to the association remains the answer to confirmed abuse. Unusually low mining time simply results in a lower ranking when funds are insufficient.
It never actually converts Monero into euros: the euro amounts shown on the site are only a comparison reference (a price oracle) — every actual movement of funds happens in native XMR.