Dynamic Leverage Pricing for Non-Transferable Time Credits: Solving Skill-Mismatch in Volunteer & Public-Good Labor

Problem

Classic time-banking systems (Ithaca Hours, LETS, Edgar Cahn’s Time Dollars) use a fixed 1:1 exchange rate: one hour of any labor equals one hour of credit, regardless of skill or scarcity. This has a well-documented failure mode: when a scarce or high-skill task (medical consult, plumbing repair) is priced identically to a low-skill, abundant one (dog walking, data entry), skilled contributors disengage, scarce categories go permanently unfilled, and the system either collapses or quietly reverts to informal favor-trading outside the ledger.

The goal here is a mechanism that keeps the core properties of time banking that make it attractive — non-transferable credits, no money, no accumulation into a de facto currency — while fixing the fixed-rate problem, without reintroducing a priced labor market or a central administrator manually setting rates.

Mechanism

1. Cold start

The system launches with a flat 1:1 baseline: one hour of registered task time equals one unit of standard credit, for every task category. Entry requires only a minimal competency check for skill-gated categories (e.g. basic verification for first-aid or plumbing tasks) — no formal certification bureaucracy.

2. Gap detection

A shared ledger tracks, per task category, the ratio of posted task-hours to filled task-hours over a rolling window (e.g. 2–4 weeks). A category is flagged as “in deficit” when unfilled hours exceed a threshold for N consecutive windows.

3. Dynamic rate adjustment

When a category is in sustained deficit, its exchange rate is increased algorithmically (e.g. 1:1 → 1:1.5 → 1:2), making it more attractive relative to other categories, without changing what credits can be redeemed for. As supply catches up and the deficit clears, the rate decays back toward the 1:1 baseline over a fixed half-life, rather than snapping back instantly (to avoid oscillation).

4. Multi-signal feedback (beyond raw supply/demand)

Two additional signals correct for a failure mode that pure supply/demand tracking misses — a category can look “adequately priced” by the numbers while actually being miserable to do:

  • Exit rate: the fraction of people who accept a task and then abandon it before completion. A high exit rate on a category, even at an already-elevated rate, is treated as a signal that the task itself (not just its price) needs redesign — this is a flag for human review, not just a further rate increase.

  • Repeat rate: the fraction of past participants willing to take the same category again. Sustained low repeat rate at a stable rate suggests the price is masking an underlying quality-of-task problem rather than a scarcity problem.

  • Survey/intent signals: periodic lightweight surveys capture anticipated future gaps before they show up in the hard data (e.g. “would you take on X if it were offered next month”), allowing pre-emptive rather than purely reactive adjustment.

5. Non-transferability and decay

Credits cannot be transferred between individuals and decay over time if unused. This is a deliberate design constraint, not an oversight: it prevents credits from being accumulated, traded, or converted into a store of wealth or status, which is the property that distinguishes this from a parallel currency.

Prior art

  • Ithaca Hours / LETS: fixed-rate time/labor exchange systems; largely stalled at small scale, with the skill-mismatch problem described above being one of the most commonly cited reasons.

  • Al Roth et al., matching market design: extensive academic literature on allocating scarce resources without prices (kidney exchange, school choice, residency matching). Highly relevant to the allocation problem but generally solved via one-shot matching algorithms rather than a continuously adjusting rate.

  • Uber/Lyft surge pricing: closest real-world analog for the dynamic-rate mechanic itself, but operates with real currency and no decay/non-transferability constraint — the incentive-shaping logic (raise price when supply is short, let it fall as supply recovers) is structurally similar.

What doesn’t seem to exist, as far as I’ve found: a non-transferable, decaying credit system with a continuously adjusted rate driven by a multi-signal feedback loop (gap + exit rate + repeat rate + survey), rather than price or gap data alone.

Open problems

  • Sybil resistance: nothing here prevents an individual from registering multiple identities to farm high-leverage categories, dodge decay by “resetting” through a fresh identity, or dilute exit-rate/repeat-rate signals with fake activity. This is probably the single largest unsolved issue — without a reliable one-person-one-identity guarantee, none of the anti-accumulation properties actually hold.

  • Decay-gaming: whether small, low-effort recurring transactions could be used purely to reset an individual’s decay clock without meaningful participation, and if so, what the minimum viable anti-gaming rule looks like.

  • Oscillation and reference class size: at what community size does the gap-detection window stop producing noisy, reactive rate swings? This likely needs real deployment data rather than simulation to answer well.

  • Long-horizon, high-specialization tasks: the mechanism assumes tasks are discrete and roughly interchangeable in duration. It has no answer yet for coordinating a small team over a multi-year project where mid-project attrition is catastrophic — that may need a structurally different, contract-like mechanism layered on top rather than a rate adjustment.

What I’m looking for

Pointers to prior systems that tried something like the multi-signal dynamic-rate approach (rather than fixed-rate time banking or priced surge pricing) and where it broke in practice — especially any that got past small-community scale. Also interested in known Sybil-resistance approaches that don’t require a centralized identity authority, if any credible ones exist.

This is a real failure mode and you have the backbone right. Non-transferability plus decay is exactly what keeps the credit from congealing into a parallel currency, and that instinct is worth more than it looks: it is what makes this a standing or franchise token rather than capital. I have been building a non-transferable proof-of-contribution credit with the same two properties and hit walls that are worth flagging before you commit to the dynamic-pricing layer, because I think two of them are load-bearing and one reframe dissolves both.

The first is that your pricing signal and your payout are the same object. Posted-versus-filled hours per category both detects deficit and determines what a filled hour pays. That makes the signal the manipulation target, not just an input to it. The profitable strategy is to manufacture deficit: post tasks in your category that you do not intend to fill, or coordinate to leave hours unfilled for N periods, let the rate climb to 1:2, then fill. The multi-signal feedback (exit rates, repeat rates, survey intent) does not close this, it widens it, because each new signal that moves the rate is one more thing to spoof. This is a general trap worth naming: never let an implicit signal carry two jobs at once. Right now posted-vs-filled is asked to carry both “how scarce is this genuinely” and “how much do I get paid,” and any time those two point in different directions the second one wins. Your Sybil concern is real but it is downstream of this. Sybil resistance is hard precisely because the signal being Sybil-attacked is also the mint.

The second is that hour-denomination hides within-category quality variance, and I suspect that is the actual reason skilled people disengage, more than cross-category mispricing. Once you price the medical-consult category at 1:2, two consult hours still pay identically even if one contributor resolves the case and the other does not. The scarce thing was never the category, it was the contributor. Cross-category leverage narrows the gap between dog-walking and surgery but leaves the sharper gap, between a good hour and a bad hour of the same task, exactly where it was. Skilled people feel that one more.

The reframe that dissolved both for me is to stop minting the scarcity multiplier into the credit. Split the measure from the medium. Let the soulbound credit measure contribution standing only (decays, non-transferable, your design), and let the scarcity multiplier live in the matching or clearing layer as a transient property of a single trade. Then gaming the price signal buys you a better clearing on one match and never accretes durable standing, which is the property you actually want to protect. It also gives you a natural home for quality: standing can be updated by realized outcome (did the task resolve, did it repeat) rather than by hours logged, so the within-category variance shows up where it belongs.

One smaller control-theory note. A fixed half-life decay against an adversarial input is in a bind: slow enough to resist oscillation is also slow enough to leave a fat arbitrage window (hold effort, deploy when your category spikes), and fast enough to close the window reintroduces the oscillation. You probably want the decay rate to be a function of measured signal volatility rather than a constant, so it stiffens exactly when someone is trying to swing it.

Genuine question: did you consider separating the standing measure from the payout medium from the start, or is keeping them fused (one credit that both scores and pays) load-bearing for the incentive you are after? I can see an argument that fusion is the whole point, but if it is not, splitting them buys you most of your open problems back

Thanks — this was the sharpest feedback I’ve gotten on this so far, and it forced a real redesign rather than a patch.

To answer your closing question directly: fusing standing and payout was not load-bearing, it was just an oversight. We’ve split it into three separate tracks now:

  1. Base credit — paid out per task, tied to verified time/effort input, calculated using the dynamic-leverage rate as a one-time transient property of that single trade (as you suggested). Does not accumulate into anything, resets each cycle. This is the only track that’s actually “spendable.”

  2. Lifetime contribution tally — a running total of base credit earned over a person’s life, but explicitly non-redeemable for anything. It exists purely so long-term contribution is visible and acknowledged (that was actually the original motivation for this whole project — the sense that sustained effort tends to go unseen). It cannot be used as a governance weight or priority claim, specifically to avoid it quietly becoming an informal power base.

  3. Reputation/quality score — domain-siloed (a person doing both nursing and electrical repair has two independent scores, not one blended one), updated from outcome-based signals rather than raw hours, non-redeemable, and only ever gates future access (harder tasks, priority matching, audit priority) rather than paying out directly. This is where exit rate, repeat rate, and error rate now live, rather than feeding the leverage calculation.

We also added an upstream layer specifically for your “manufactured deficit” attack: task requests above a routine-frequency baseline for a given requester/category pair get flagged for third-party verification before they ever reach the gap-detection signal, so the leverage layer only ever sees demand that’s already passed a plausibility check. Decay-as-a-function-of-volatility is still on our list but we haven’t worked out the details yet — if you have a specific model in mind for that (rather than just the general principle), I’d genuinely like to see it.

Separately, and this is more of a meta-note than a request for more feedback: the more we’ve worked through this, the more it looks like this design doesn’t actually fit a Web3/DAO context well. The non-transferability, decay, and existence-guarantee pieces all assume a fairly thick layer of real-world verification (who actually did the task, who actually needs the repair) that’s hard to get from on-chain primitives alone, and the things that make it interesting to me (existence guarantees, non-financialized reputation) aren’t really things a token or smart contract can enforce on their own. So this may end up being better suited to a closed pilot community with off-chain verification than an on-chain protocol. Wanted to flag that in case it saves you time deciding whether to keep engaging with this thread — appreciate you taking the first version seriously enough to actually break it.