What a 200-quest gamification engine taught us about retention on a renovation forum

--

When we sat down to design the quest system on home.renovation.reviews, the idea was that members should be able to earn a real Solana token, $RENO, for the kinds of posts that make a forum useful: a careful answer to someone’s sump-pump question, a finished basement walkthrough with photos, a quote breakdown someone else can learn from. The token was the easy part. The hard part was deciding what should count, what should pay, and how much.

We ended up shipping somewhere north of two hundred individual quests. Some are tiny: link your Solana wallet, post your first reply, complete your profile. Some are heavy: walk through a full project end to end, photograph each milestone, post a final cost summary. After running the engine for a few months I want to share what we got right, what we got wrong, and what I think generalizes if you are thinking about a similar system on Discourse, Circle, Outseta, or any forum stack with hooks deep enough to support server-side validation.

Why the count matters less than the spread

Two hundred quests sounds like a lot. The number is mostly cosmetic. What matters is the spread.

If your quest list is flat, the same effort produces the same reward whether the post took two minutes or two weeks. People notice that quickly and either stop bothering with the heavy contributions or convert everything into the lowest-effort form. We saw both behaviors in our first week, when the rewards table was tighter than it should have been.

When we widened the spread so the smallest quests paid roughly one unit of $RENO and the largest paid one to two hundred units, the ratio between effort and reward got much closer to fair. Heavy quests still felt heavy, but the leaderboard started filling with people who were doing the kinds of long-form posts the forum actually needed. The lesson is unglamorous: design the long tail of your quest list before you publish it, not after.

Server-side validation is non-negotiable

The first version of the quest engine had a few quests that fired off client-side signals. Click a button, mark a quest as complete, get the points. We pulled those out within a week.

The reason is obvious in retrospect. If a forum is paying out a transferable token, anyone with a browser console can find the function that says “grant reward,” call it directly, and walk away with a wallet full of free coin. We rebuilt every reward path so the credit happens server-side, gated by Discourse’s own data: badge grants, post counts, category memberships, custom field values. The badge SQL we use is the source of truth, and the engine’s job is to read state, not to be told what to believe.

There is a side benefit to this. When the rules live entirely on the server, you can change them without touching client code. A quest that turned out to over-reward can have its payout halved by editing one configuration row. We have done this exactly four times so far, and each time the change took effect on the next page load with no rebuild and no member confusion.

The badge is the carrot, not the coin

Early on I assumed the token itself would do most of the motivating work. People would log in, see how much $RENO they had earned, and post for the joy of watching it climb. That happens, but it is not actually the dominant signal.

The dominant signal turned out to be the title above your name. Tier titles unlock at score thresholds and are awarded by Discourse badges. A new member starts as a Cornerstone, climbs to Carpenter, then Foreman, then up the trade ladder. The title is the part people show off. The token is the part that cashes out, but the title is what they read every time they look at their own posts.

There is a lesson buried in that. If you are tying a token to a community, the visible status signal needs to live somewhere everyone sees on every page. A wallet balance does not. A username badge does. Discourse already has the primitive built in, and it composes cleanly with the rest of the trust system, which is why we leaned on badges rather than rolling our own visual element.

The leaderboard does most of the discovery work

Members find new quests less by reading the documentation than by looking at what is happening on the leaderboard and reverse engineering what someone above them is doing right.

This was unexpected. We had written what I thought was thorough quest documentation. People looked at it once on signup and rarely came back. What they did come back to was the leaderboard, where they could see who had jumped twenty places overnight and click into that user’s profile to see which posts had paid out the highest. The leaderboard ends up acting as the implicit changelog for the entire engine. If you are designing one, treat it as a teaching surface rather than a vanity surface. Show enough context that a new member can learn the system by scrolling.

What the on-chain piece changes

One thing I was unsure about going in: would members actually link a Solana wallet, or would the token-earning mechanic feel ornamental? The answer, with a few months of data, is that the wallet field on signup gets filled in well above what I expected, and that the people who fill it in are noticeably more active afterwards.

The plausible explanation is that the act of linking a wallet is also the act of opting into a long-running relationship. You are saying yes, I expect to be here long enough that the balance will matter. That self-selection seems to do part of the retention work all by itself. The token does not have to be valuable in dollars for this to work. It has to be transferable and visible to other members.

What we would do differently

If I were building this again from scratch on a different community, three things would change.

First, I would launch with the leaderboard before launching with the token. Most of the social signal that retains members is in the public ranking, not the wallet balance. You can run that for a month while you finalize the on-chain side, and your members will already understand the loop when the token ships.

Second, I would write the quest spread on paper before writing any code. Treat it as a pricing problem, not an engineering problem. The engineering takes a week. The pricing decisions, if you get them wrong, take three weeks of back-and-forth to unwind without making the early adopters feel cheated.

Third, I would gate every reward through a single helper. Ours is a method called credit_score, and every quest, every badge unlock, every airdrop drops through it. When you put the chokepoint in early, debugging is a single grep. When you sprinkle reward calls across thirty controllers, you spend an afternoon every few weeks chasing a payout that did not happen.

If you want to look at it running

The forum is at home.renovation.reviews. The leaderboard is the fastest way to see the engine in motion, the badge list shows the title ladder, and the welcome thread walks through how new members link a wallet and start earning. None of this is theoretical. The token is live on Solana, the payouts are recorded on a public ledger, and the same gamification primitives are bolted onto a community that started as a place for homeowners to compare renovation quotes. If you are designing your own version, those are the parts that matter more than the token contract itself.