The graph to the right is an example of a Lorenz curve (although at the time it was generated the author was unaware that it had a name). This particular example was generated in 2001 from the complete set of LlaniLETS transaction data for the period November 1994 to February 2001. It indicates that over this period about 20% of members were responsible for 80% of transactions (by both number and value). (Interestingly, a nearby LETS that had been set up in the same year and month was found to have an almost identical set of trading curves although its total volume of trades was about ten times as great. The latter LETS was based in a much more densely populated area with a greater capacity for social interactions.)
The curve is probably typical of all "one-size-fits-all" LETS in which the currency is assigned a value as arbitrary as that of legal tender.
A system of more equal value to its members would have a set of curves much closer to the straight line ideal.
If the deviation of the tradinging curves from the ideal can be considered an indication of system usefulness, it can be assigned a numerical value by integrating the area under the curve (a natural by-product of the process involved in plotting the graph) and subtracting the area of the triangle below the "ideal line".
The particulart example shown was generated using a simple Perl script and a module named GIFgraph. Alternatives now exist capable of generating cleaner-looking graphs.
Another indicator of "eqality of usefulness" is the "connectivity matrix". Unfortunately it has not yet been possible to prepare an example, but the principle is very simple.
An M x M matrix (where M is the number of accounts) can be represented by an M-pixel x M-pixel PNG.
M may represent either the total number of members or the number of members in a particular subset selected according to (as yet undefined) criteria such as
only members who have ever traded
only members who have traded in the past [n] months
only members in a particular geographical area
Each row and each column represents an account: payment from (row) to (column) intersecting at a point (a pixel at the default scale). The colour of that pixel (or expansion thereof) represents a value such as:
number of payments
total value of payments
The colour may range across the visible spectrum (red to violet) or along a scale of hues and shades (e.g. from black  through dark brown, lighter browns, yellow ochre, yellows, oranges, reds, ...). Although a linear progression could be used, it would probably make more sense to use a logarithmic scale. The auto-scaling functiuons involved in this would also be able to generate a colour-key alongside (or above or below) the matrix.
Arbitrary regions could be selected for expansion (so points of intersection would be expanded from 1 x 1 pixel to s x s pixels of the same color.
The order in which accounts are listed along each axis could be selected according to a variety of rules such as:
number of trades
time since last transaction
total value of trades since joining
total value of trades during the last N months
Matrices ordered as 1, 3 or 5 above (for example) can be expected to display clustering symmetrical about the leading diagonal.
An auto-scaling bar graph can be built easily using stretched 1x1-pixel PNGs. These can be stacked vertically alongside member details to give an immediate visual indication of account balances within any particular system/registry.
Three examples are shown here (for a very small imaginary LETS):
Sorted by order of account number
Sorted by order of absolute value of account balance
Sorted by order of value of account balance
Switching between these three views would involve no more than a click on a "sort by" button, or selection from a drop-down list, at the top of the page.
(The 2nd and 3rd examples omit the member number only because there was no time while preparing this page to code in a sorting function. Instead the member numbers were reassigned for convenience of sequencing.)