FightCred V2: Where the Complexity Comes From. An explanation for 3PunchConvo leadership of which parts of the FightCred V2 specification fit the current system and which require structural change.
The V2 document reads like a change to point values. In practice it is a change to the shape of the system.
Today the application awards FightCred to the member who receives engagement. Someone likes your post, replies to your post, or gives it post of the day, and you earn cred. The application awards nothing at all for the act of creating a thread or writing a reply.
That means the entire "Contribution" category in the V2 specification is brand new functionality, not a re-weighting of something that already exists. Several other parts of V2 look like number changes on the page but quietly require the system to keep a kind of record it has never kept.
This document explains which parts of V2 fit comfortably inside how the system works today, which parts require rebuilding part of the foundation, and why.
| V2 element | Classification |
|---|---|
| Changing the values for likes, replies, post of the day | Straightforward |
| Member rankings leaderboard | Straightforward, already built |
| Retuning inactivity decay to the V2 rule | Straightforward, with a member-experience decision attached |
| Activity awards, daily login and fight pick submitted | Straightforward, once awards can be recorded individually |
| Expertise odds bands, ten fixed bands replacing the current formula | Moderate |
| Showing category subtotals on a member profile | Moderate, with one category blocked |
| Thread and reply value ladders that grow with engagement | Structural |
| Per content caps on cred from likes and replies | Structural |
| Itemised transaction history, the bank statement view | Structural |
| Multiple formulas applied to different time ranges | Structural, and we recommend against it |
| Weekly bonus awards | Structural, new recurring cycle |
| A single platform wide Post of the Day | Structural if that is what is meant |
| What happens to members' existing balances | Decision required before work starts |
These fit the way the system already works. They are real work, but they are contained, low risk, and visible to members quickly.
The point values themselves. The values for likes, replies, and post of the day already live in a settings table that can be edited without shipping new software. Changing those numbers is genuinely easy.
Rankings. A member rankings leaderboard is already live in production. It handles paging through long lists, handles members who are tied on the same score, and shows a member their own position. Rankings are effectively already done.
Inactivity decay. The machinery that reduces a member's score when they stop participating already exists in the system. It is currently switched off. Moving it to the V2 rule, a 14 day grace period followed by a 0.25 percent reduction for each idle day after that, is a change to how an existing mechanism calculates, not the building of new machinery.
One caveat worth stating plainly: switching decay on would cause member scores to go down for the first time in the product's history. That is a member-experience decision for the business, not just an engineering task.
Activity awards. Awarding cred for a daily login and for submitting a fight pick is simple new work, provided there is somewhere to record an individual award. That last condition matters, and it connects to the structural section below.
Expertise odds bands. Today, when a member gets a pick right, the value of that pick is calculated from a continuous formula based on the odds, multiplied by a win-streak factor. Replacing that with ten fixed bands is a contained, well understood change.
The bands are applied to the odds a member locked in at the moment they made their pick, which is how settlement already works and which is confirmed as the basis going forward. A member's award reflects the price they actually took.
Category subtotals on a member profile. Showing a member how much of their score came from each of the four categories is achievable for three of them: Recognition, Expertise, and Activity. The fourth, Contribution, cannot be shown at all until Contribution awards exist in the first place.
This is where the real cost sits. Each of the items below is blocked by the same underlying fact about how the system stores scores today, so it is worth stating that fact once.
The system does not record individual awards. It records daily totals. When you earn cred today, the system does not write down "this specific thread earned this member this much cred at this moment". It updates a single running figure: how much this member earned in total on this day. There is no per-item record. That design is fine for a leaderboard. It is not sufficient for anything that needs to look back at one particular award and change it, cap it, or list it.
V2 says an original thread is worth a small amount when it has 0 to 1 replies, more when it has 2 to 4 replies, and considerably more once it reaches 5 or more. It also says a reply is upgraded in value once it reaches 5 likes or 3 replies.
Read that carefully and the implication is significant: an award granted on Monday has to change value on Friday, when the thread keeps growing. The system has to be able to find that one award again and revise it.
It cannot do that today, because the award was never written down as a separate thing. Supporting these ladders requires introducing a per-award record, a line item for every individual award granted. This is the single biggest structural change in the whole specification.
V2 caps the cred a piece of content can generate from likes at 20, and from replies at 20.
To enforce a cap you must know how much a given post has already earned from likes, and separately how much it has earned from replies. Nothing tracks that today, for exactly the reason above: totals are kept per member per day, not per post.
The specification recommends a bank statement style view showing each event with its date, category, and amount. That sounds like a display feature, and it is not.
The data available today can support a daily summary: "on August 3 you earned 18." It cannot support an itemised statement: "2:22pm, post of the day on this thread, plus 15." The itemised version needs the same per-award record as the ladders do.
4. Multiple formulas over different time ranges, the most expensive item, and its premise does not currently hold
The ask here is that cred earned during one period stays valued under the rules that were in force at that time, while new cred uses the new rules.
The obstacle is not the bookkeeping of running several formulas. The obstacle is that the system never took a snapshot of the facts those formulas depend on. Whether a member had a paid membership, what role they held, and whether a post had been moderated are all read as they are today, not as they were at the time.
The consequence is important: recalculating an old period does not reproduce what that period actually paid out. It produces what that period would have paid out given today's facts. Those are different numbers, and the difference is not something we can correct after the fact.
Making history genuinely reproducible means first building a record of what was true at each moment in the past. That is a substantial project in its own right, and one that members would never see.
The weekly top ten percent, the weekly top three percent, the weekly winner, and the perfect card award all require a recurring weekly process. That process has to rank members by units up, decide the winners, and grant the awards exactly once, without double paying if it runs twice or missing a week if something goes wrong.
The ranking part can reuse machinery that already exists. The weekly cycle itself is new.
Today, post of the day is something individual members can give out to content they like. If V2 intends a single editorial post of the day, chosen once per day for the whole platform, that selection mechanism does not exist and would need to be built. This is worth clarifying early, because the two interpretations lead to very different amounts of work.
Whatever else is decided, there is an unavoidable decision about members' current scores. There are two options:
- Recalculate everyone under the new rules. This reshuffles the leaderboard and will upset established members who have built their standing over time.
- Freeze existing totals at a cutover date and apply the new rules only going forward.
This is a community decision more than a technical one, but it has to be made before the work starts, because it shapes the work.
Turning on decay, changing the values, or recalculating scores will move members between status tiers. Tier changes are already wired into member notifications and email marketing, so those messages will fire.
Any change of this kind needs a communications plan alongside it. That is not an engineering dependency, but it is a real one.
First, do the changes that fit the current model. The point values, the odds bands, the Activity awards, the decay retune, and the category subtotals that are achievable today. These are the changes that deliver visible, member-facing improvement quickly, and they carry the least risk.
Second, treat the per-award record as one single foundational piece of work. The value ladders, the per content caps, the itemised transaction history, and any form of formula versioning all depend on the same foundation: a record of each individual award. If these features are built separately over time, that same foundation ends up being built more than once. Building it deliberately, once, is the better path.
Third, we recommend against historically exact formula versioning. The reason is in point 4 above. You would be paying to reconstruct a historical record that was never captured in the first place, and the result would still be an approximation rather than the truth. The simpler approach, freezing existing totals at a cutover date and applying the new rules from that point forward, achieves the practical goal that this feature is really trying to serve: that the new rules are applied fairly and that members are not retroactively penalised.
Nothing in V2 is impossible, and a meaningful portion of it is genuinely quick. The parts that are expensive are expensive for one shared reason: the system currently remembers how much each member earned each day, but not what for. Most of the ambitious ideas in V2, the growing value of a good thread, the caps, the statement view, the historical fairness, all require the system to remember what for.
That is one decision, not five. Making it once, up front, is what keeps the rest of this straightforward.