Who's who on the platform — who can do what, and how
This page lists, for every role in the system, what it can do and through which concrete means (a page on the site, an API call, or a human action outside the software). It complements the scoring model page and the Transparency page.
There are 4 roles: member, administrator, public visitor, and wallet organiser. There is no automated server process for collecting mining data — the administrator triggers it themselves from their own machine (see §2 and §5 below).
1. Member
A member of the association, signed up on the site. The mining module runs in the background on their machine — through the app with an icon in the system tray, which drives the mining engine without the member ever needing a terminal.
| They can... | How |
|---|---|
| Sign up (email + password + nickname) | The /register page. Automatically generates their unique identification key. |
| Log in | The /login page (returns a token stored in the browser) |
| See their profile (seniority, KYC status) | /dashboard |
| Download their ready-to-use mining app | A button (Windows/Linux/macOS) on /dashboard: a single zip file containing the already-built binary (with the association's address baked in) plus their personal token and instructions. Nothing to assemble by hand. |
| Adjust the mining power used, with no terminal and no file to edit | An icon near the clock (system tray) opens a small settings page with a slider: more power means a hotter machine but a better-ranked help request (mining time and power count toward the score, see scoring model); less power means less heat but a less favourable ranking |
| Let the icon start itself again after a restart (or turn that off) | Enabled automatically the first time it runs; a checkbox in the icon's menu turns it off |
| Post a help request (amount + message), one per round | A form on /dashboard (rejected if a request already exists for the current round) |
| See the current round's requests, to vote with full context | /dashboard (members only — personal messages are not public) |
| Vote for a request (optional, one vote per round, never for their own request) | A "Vote" button on /dashboard (rejected if they already voted this round) |
| See the history of their own requests | /dashboard |
| Check public transparency (like anyone, see §3) | /transparency |
What a member cannot do: see another help request's message without being logged in, vote more than once, trigger the score, treasury, or distribution calculation themselves, or close a round (reserved to the administrator).
2. Administrator (the association's organiser)
An account cannot grant itself administrator rights from the site (a deliberate security choice) — it is set up directly on the server when the first administrator account is created.
| They can... | How |
|---|---|
| Log in to the admin interface | The /admin/login page (same mechanism as the member login — it is the administrator status, checked server-side, that grants real access) → /admin |
| Fetch the mining metrics collected from the pool | From their own machine, never from the site: the admin-tools/collect_mining.py script. Can be re-run as often as they like during an open round. |
| Compute the round's scores for every requester | A button on /admin |
| Compute the round's treasury (gross/rate/net fees) | A form on /admin |
| Run the cascading distribution engine | A checkbox + button on /admin — dry-run is checked by default, it must be explicitly unchecked for the plan to be saved and logged in the audit log. A real run closes the round and opens a new one automatically. |
| View the payout sheet (beneficiaries' addresses) | A button on /admin |
| Confirm that a payment was actually sent (after doing it manually from their own wallet, see §4) | A form on /admin |
| View the audit log and check the chain's integrity | A button on /admin (same data as what is published publicly) |
/admin/login is currently not linked from the main navigation (accessed by direct URL only).
What the administrator can never do from the site: actually send funds, or query the mining pool themselves from the web server (which no longer has any mechanism to do so — see §5). The web server calculates and publishes who should receive what, but never has access to the wallet's private key (calculation and execution are kept separate) — see the next role.
3. Public visitor (logged in or not, even a non-member)
Anyone can check the association's transparency data, with no account needed.
| They can see... | How |
|---|---|
| The list of past and current rounds | /transparency |
| The round's pot (gross, fee rate applied, net, carried-over amount) | /transparency |
| The full score detail for every member (every component, not just the total) | /transparency |
| The list of beneficiaries for the round and their payment status | /transparency |
| The entire audit log (signups, mining, requests, votes, scores, payouts) | The public audit log endpoint |
| A cryptographic check that the audit log has not been tampered with | The public verification endpoint |
| The public documentation of the scoring formula | Scoring model page |
This full transparency is a non-negotiable requirement: the scoring formula and the distribution engine are public, and fees are never hidden.
4. Monero wallet organiser (a human role, outside the web software)
This is not an account on the site: it is the person who holds the seed of the association's single wallet, on their own machine, outside the web server (no multisig, but stronger protection of this machine since it is now a single point of failure).
| They can... | How |
|---|---|
| Fetch the round's payout sheet in one command (personal addresses + amounts to send, admin-only — not the same view as the public one in §3) | Consumed automatically by organizer-tools/pay_month.py |
| Actually send the funds to each beneficiary, to their personal Monero address | The organizer-tools/pay_month.py script, run on their own machine, driving their local monero-wallet-rpc (one individual transfer per beneficiary) |
| Confirm each payment to the server | Done automatically by the script, no separate manual step needed |
| Test on a small subset before a large batch | pay_month.py --no-dry-run --limit 3 |
| Safely resume after a crash or a network outage mid-send | The script logs every send locally before confirming with the server — no payment is ever sent twice |
In current practice, this is often the same physical person as the administrator (§2), but they are two distinct roles: one acts inside the web software, the other acts in a completely separate tool that never talks to the server beyond those two calls.
5. Collecting mining metrics — a local script, not an automated role
There is no server process continuously querying the pool. Collection is an explicit action taken by the administrator, from their own machine:
| Step | How |
|---|---|
| List active members and their key | admin-tools/collect_mining.py calls an admin-only endpoint |
| Query the pool for each member's exact key | Direct calls to supportxmr.com (or equivalent) — cumulative work and recent mining time |
| Push the result to the server | The server simply records it — it never calculates or queries anything itself |
This script can be re-run as often as the administrator wants during an open round — each pass only measures the delta since the previous pass, with no double-counting. Recommended: run it one last time right before computing the score (§2), to capture the freshest data.
Visual summary
Member ──────► posts a request, votes, mines
Administrator ──► pushes mining metrics (from their own machine)
│
▼
computes treasury → scores → distribution (dry-run, then real)
│
▼
publishes the list of beneficiaries; a real distribution
closes the round and opens a new one
│
▼
Wallet organiser ──► sends the funds via their local wallet → confirms
automatically
Public visitor ──► checks everything, anytime (transparency)