I think that you've identified an important problem, but I disagree with your approach to solving it. I think you're right that scarcity is a good way to make

I think that you've identified an important problem, but I disagree with your approach to solving it. I think you're right that scarcity is a good way to make voting (especially approval-style voting) into something more meaningful. One of the problems with Digg is not just the unlimited amount of voting that one can do, but also the unlimited amount of submitting one can do. As a result, you have people running scripts to submit tons and tons of articles scraped from RSS feeds. Literally one article every few seconds. What your system would do (making people earn mod points through submissions) is simply encourage users to submit as much as possible in order to gain more points. Crapflooding the queue then destroys the signal to noise ration irretrievably. I think the better way to implement scarcity, apart from your method and Slashdot's method, is to weight users' votes according to the number of votes they've distributed in a given period (say 24 hours). So a person who votes for under 10 things might have each vote count as a full 1 point. But a person who votes for 20 things might have their vote count as only 1/2 a point. You might put a lower bound on it, so that a vote will never be worth less than 1/10th of a point, but you get the idea. It's not scarcity by number, so much as scarcity by dilution. The best part of this is that it's invisible to the user. When you have a system that's visible ("You've got 5 Modpoints, Use 'em or Lose 'em!"), you encourage gaming the system. When you have a system that's invisible, users can behave normally or badly and the system can compensate without giving them clues as to how to game it.