I'm curious whether this could be Implemented into the marketplace, it would be time effective, easy to Implement and stop a lot of scamming.
Let's take this example:
Bob is a HF user, bob just upgraded to Ub3r to exchange BTC in the marketplace, Bob is a high quality user but ends up scamming members. Bob would face a potential (permanent) ban from staff.
Currently no such functionality exists for HF staff to restrict members from selling marketplace - the only functionality that exists currently is the ability to ban users completely, in my view this restricts the potential revenue vector for any single user for that period of time. Milk the cow till she's dry'
1. We could introduce 1, 3, 6 and 12 month marketplace selling bans - increasing profitability for Omniscient as member retention is kept longer while decreasing community risk.
Risk #1 - Members may decide to proxy sell, in such event this would result in even more revenue for HF, this risk is associated regardless of Implementation as banned user may seek to proxy sell regardless.
Risk #2 - Banned user creates new account, this risk is again, associated regardless of the marketplace ban.
Risk #3 - Banned user spams, goes on rampage or becomes clinically insane. This would be expected in a large portion of users, in such event this can be averted by issuing regular bans after marketplace bans.
2. HF introduces the "marketplace wildcard" - this idea would be when Omniscient approves members for ub3r but restricts marketplace selling for X months until reputability is built for the user and community risk decreased. This allows HF to gain increased revenue through the means of increased "reputability time" when the member seeks to build up reputation with the potential of donating to HF and purchasing additional awards, while protecting the community.
3. Prestige restriction for marketplace areas. The prestige system is dubbed an unknown mathematical equation summing a members quality -- perhaps utilize this existing infrastructure to restrict members from posting in high risk categories (such as the exchange section) regardless of user group.
Let's take this example:
Bob is a HF user, bob just upgraded to Ub3r to exchange BTC in the marketplace, Bob is a high quality user but ends up scamming members. Bob would face a potential (permanent) ban from staff.
Currently no such functionality exists for HF staff to restrict members from selling marketplace - the only functionality that exists currently is the ability to ban users completely, in my view this restricts the potential revenue vector for any single user for that period of time. Milk the cow till she's dry'
1. We could introduce 1, 3, 6 and 12 month marketplace selling bans - increasing profitability for Omniscient as member retention is kept longer while decreasing community risk.
Risk #1 - Members may decide to proxy sell, in such event this would result in even more revenue for HF, this risk is associated regardless of Implementation as banned user may seek to proxy sell regardless.
Risk #2 - Banned user creates new account, this risk is again, associated regardless of the marketplace ban.
Risk #3 - Banned user spams, goes on rampage or becomes clinically insane. This would be expected in a large portion of users, in such event this can be averted by issuing regular bans after marketplace bans.
2. HF introduces the "marketplace wildcard" - this idea would be when Omniscient approves members for ub3r but restricts marketplace selling for X months until reputability is built for the user and community risk decreased. This allows HF to gain increased revenue through the means of increased "reputability time" when the member seeks to build up reputation with the potential of donating to HF and purchasing additional awards, while protecting the community.
3. Prestige restriction for marketplace areas. The prestige system is dubbed an unknown mathematical equation summing a members quality -- perhaps utilize this existing infrastructure to restrict members from posting in high risk categories (such as the exchange section) regardless of user group.
