workers

Every holder is a pool worker. This is the full roll for the current rental, what each worker was assigned, what it has put in, and what it is owed.

current set

rentalsnapshot slotrootworkershashing
workerholderbalanceshareassigned H/slive H/svalidinvalidattributedpendingpaidrail
No worker set yet. Workers are created at the first rental snapshot.

how the split is made

At the slot the rental transaction confirms, the engine reads every token account of the mint and records each holder's balance. Balances below the dust floor of one thousand base units are dropped. The remaining balances are summed, and each worker's share in basis points is its balance over that sum, rounded down, with the remainder of the rounding given to the largest holder so the shares sum to exactly ten thousand.

The rented hashrate is assigned to workers by those shares. The rig itself hashes under one pool login per worker, which means the provider is handed a worker list, not a single login. Providers that support only one login are not used.

The merkle root of the sorted list of (holder, balance) pairs, hashed with sha256 over the 32 byte pubkey followed by the 8 byte little endian balance, is written into the rental receipt PDA. Anyone can recompute it from a snapshot of the holders at that slot and check that their worker was in the set with the share they were owed.

share distribution

share by worker, descending

modelling

workershareXMR per 1 XMR harvestedXMR per 1 XMR after breakthrough split
No worker set yet. Workers are created at the first rental snapshot.

Computed from the current shares. It changes only when a new rental snapshots a new set.