D47K field notes: an experiment in gamified crowdsourcing and on-chain reputation.

We set out to see if small, focused apps plus on-chain notarization could bootstrap a neutral reputation layer. The goal: gather high-quality web corrections, reward contributors, and keep proof of work (the human kind) verifiable without handing control to a single company.

In trust-minimized systems you don’t know your counterparty. You still need signals of quality. We explored whether a gamified browser plugin, a reviewer network, and a fee-recycling reward pool could produce those signals and sustain incentives—without minting forever or relying on one operator’s database.

We took a market-first approach. In survey and secondary research we reviewed (industry polls on typo impact and willingness-to-pay), up to 60% of owners were willing to pay up to $8 for typo/bug alerts on their sites. Roughly the same share of users said they’d avoid buying from sites with visible mistakes. That was enough to justify a lightweight “error bounty” loop.

We built an internal test tool—a simple widget to report site errors—to see if this flow was feasible. Install the browser plugin, click the error, type a note. In the background we capture the URL, user ID, optional screenshot, and notarize that bundle on-chain. It’s fully user-initiated—no campaigns or coordinators required. Anyone can install it and report whatever’s wrong on the internet.

Roles: site owners (clients), hunters (error reporters), reviewers (quality control), and affiliates (outreach). We leaned on the crowd for all four, instead of a sales or support team. Reviewers gate spam and low quality; affiliates nudge site owners that an error bundle awaits them.

Flow: hunter reports a mistake → basic checks → reviewers vote on quality → if approved, it appears on the client’s dashboard with on-chain proof of when/who reported it → the client accepts/rejects → reputation updates for everyone involved.

Reputation design: we used a Prisoner’s Dilemma-style scoring. Reviewers don’t know each other. Agree with the majority and your score goes up; disagree or skip and it drops. Over time, reliable reviewers earn higher privileges; bad actors get filtered out.

Example: skips incur small penalties; wrong calls incur bigger ones. Consistent alignment with the crowd lifts your score. Drop below a threshold and you’re out. Climb above thresholds and you earn better rewards and access.

Reward timing: we didn’t want to wait for site owners to sign up before paying contributors. But we also refused to mint endlessly or burn. Constraint: fixed supply, automated distribution, no human overrides.

So we modeled a “reward pool” that recycles fees. Fees go into the pool; each block/interval pays out a percentage; leftover fees stay, so the pool can refill as usage grows.

Here’s the simplified model we used: total supply 1,000 tokens. In the first interval, 900 enter circulation; 100 sit in a reward pool.

Let’s say that for every block or every interval, we give 5% of those tokens that are in the reward pool away as rewards to all the people who participated in the system. Everyone who reported an error, everyone who’s been reviewing, and everyone who’s been an Affiliate. They get 5% of that interval of the tokens that are in the reward pool. Now as you can see here, if you do 5% then by the time we hit the 10th block, more than 40% of our tokens are gone in our reward pool.

Traditional payout (no fee recycling) drains fast:

Even adding a steady 4% fee inflow still trends toward zero with this model:

If you just keep paying 5% out, the pool drains fast—just like block subsidies without a cap. Over time that goes to zero.

In our example here, since we only have a very limited number of coins, and we distribute, like in this example, 5% of every block; in less than 200 blocks we will reach zero or near zero. There’s nothing left to distribute anymore.

The tweak: recycle fees into the pool and pay out a slice of those fees each interval. In simulation the pool declines for six intervals, then stabilizes and starts to refill as usage grows.

If fees go into the pool (instead of straight out), the pool dips early then starts refilling around interval 7:

When you simulate true market conditions here, of course, this will never happen because this is very linear, you will never have a fixed number of tokens coming in and going out. Therefore we also simulated this several times according to real market situations. There are times when there are a lot of fees that are being paid because a lot of people are using the system, and there are times when very few fees are being paid.

Effect: when fewer fees come in, the algorithm releases more coins from the pool to circulation. When more fees arrive, the pool grows and circulation can contract. It’s an automated, rule-based inflation/deflation adjustment.

The other effect is that there are more fees being paid and more fees are coming in, which means it’s going well with a lot of transactions. What happens then is that more fees stick in the reward pool and the reward pool goes up and the circulating supply gets less. We can do the following: we can lock this in a smart contract. There’s no human interference possible anymore then, we cannot say let’s print more coins. That won’t be needed because the supply always stays the same, no extra coins being minted, no need for burning of tokens as is the case with many blockchains at the moment, and our Reward Pool, thanks to this system, actually never runs dry. It creates sort of an automated inflation-deflation indexation.

When there are many transactions, more fees accumulate and circulating supply can contract—healthy for price action. When activity is low, the pool tops up circulation. Lock it in a contract and no one can mint extra or burn: supply stays fixed, rewards breathe with usage.

Simulations with spiky fee patterns show the pool breathing with demand: low activity pushes more rewards out; high activity retains more in the pool, tightening circulating supply.