We also need an option for the leaderboard to be calculated for points currently held, rather than lifetime points.

In terms of computational requirements, this should not be much of an issue. As points are already calculated via the leader-board and stored in the database, there is a simple arithmetic API that takes the number of points as a parameter and turns it into a voting power. The bulk of the load will come from querying for those points for every member.

For consistency, since points are stored, we should probably also calculate voting power and control upon generation of the leader-board and store alongside points in the database. That way, these values reflect voting power as they were at the time of leader-board generation and do not fluctuate when the voting power calculation settings are changed. Furthermore, while this will slightly increase load for leader-board generation, it will offset by not requiring any additional load when viewing leader-boards (since these values were already computed).

I will further enhance the efficiency by only calculating voting power once we have determined who will be on that leader-board, and only for the members who made it to the leader-board. (EDIT: can't do that; we need to know the voting power of every member to calculate voting control)

agreed