skip to content
Skill Issue Dev | Dax the Dev
search
Part of series: Zera Origin Stories

TW-TVV: Why Token-Quantity Voting Is Broken, and the Math I Tried to Fix It With

Print view

Sections

Disclosure: TW-TVV was a proposal I drafted for the m0n3y docs site in March 2025. I never built it. The protocol it was meant to govern eventually shipped under different names (Zera, Vanta) without any DAO governance at all. This post is a retrospective on the math, not a status report on the system.

The thing nobody admits about token-based DAO governance is that token-weighted voting is mostly broken before it begins. The mechanism is “one token, one vote.” The reality is “one early investor, ten thousand votes; one retail holder, one vote.” This is the founding problem of every governance system that ships in 2024–2026, and it’s the thing I tried to write a fix for in 427042a — :sparkles: Added voting prop on 2025-03-18.

The proposal is called TW-TVV: Time-Weighted Tiered Value Voting. It lives at src/pages/en/voting.md in the m0n3y-web docs and it’s 85 lines of markdown with three formulas and a table.

This post is about what’s actually load-bearing in those 85 lines.

The four problems token-weighted voting can’t solve

If you’ve been reading governance proposals since 2021 you can skip this section. If not: token-weighted voting fails because the same number of tokens is weighted the same way regardless of:

  1. When you got them. A founder’s 10M tokens at TGE vote the same as a retail holder’s 10M bought at peak.
  2. What you paid for them. Vesting cliffs, OTC discounts, airdrops — all get the same vote weight as a market buy.
  3. How long you’ve held them. A whale who bought to vote on a single proposal and dumped the next day votes the same as someone who’s held for two years.
  4. What you do with them off-chain. Token holders staking in a CEX often don’t vote at all, leaving the vote to be decided by a low-turnout subset that may or may not represent the holder base.

If you tried to write a token-vote system in 2014 you might call this “fine, the market sets the price, the price sets the influence, that’s democracy in motion.” It’s not. It’s plutocracy with a Discord channel.

TW-TVV’s three knobs

The proposal addresses three of the four (the fourth is unsolvable on-chain — you can’t make people vote). It introduces three new variables to the voting power formula:

Knob 1: USD value, not token quantity

By tying voting power to the USD value of tokens rather than token quantity, the mechanism mitigates the impact of token price volatility and early acquisition advantages.

This is the single most important change. Voting power is denominated in dollars at vote time. If you bought 1,000worthoftokensattheTGEandthetoken100xd,yourvoteweighttracksthecurrent1,000 worth of tokens at the TGE and the token 100x'd, your vote weight tracks the *current* 100,000, not the historical 1,000.Ifyour1,000. If your 1,000 went to zero, your vote weight is $1,000 / current_price ≈ a lot of tokens but a vanishingly small dollar value, so your voting weight is correspondingly small.

The five-tier structure:

TierUSD Value RangeBase Voting Power
11010–1001
2101101–1,0003
31,0011,001–10,0007
410,00110,001–100,00012
5$100,001+18

A whale with 10MoftokensisinTier5withbasepower18.Aretailholderwith10M of tokens is in Tier 5 with base power 18. A retail holder with 50 is in Tier 1 with base power 1. The whale’s base power is 18× the retail holder’s, not 200,000× as it would be under linear token-weight. The compression is intentional and aggressive.

The downside of tiers is that they introduce cliff effects. If you have $99 of tokens and someone buys you a beer, you suddenly drop a tier on the way home. The next iteration of this proposal would smooth the tiers into a continuous function. The reason I shipped tiers is that they’re explainable in a paragraph; a continuous logistic function is not.

Knob 2: time multiplier (with a cap)

Time Multiplier = Base Factor + (Holding Duration in Days / Time Division Factor)
Holding PeriodTime Multiplier
0–30 days1.0x
31–90 days1.5x
91–180 days2.0x
181–365 days2.5x
366+ days3.0x

The thing the buckets gloss over is the cap at 3.0x. The cap is doing more work than the curve. Without a cap, a multi-year holder accumulates voting power monotonically forever, which means the founder’s wallet (held since day -1) eventually has compounded more vote-time than every other holder combined, regardless of stake size. The cap forces a horizon: after a year, you’ve earned all the time-weight you’re going to earn, and any further vote concentration has to come from buying more.

Why a cap of 3? Because 3× compresses a one-year holder’s weight relative to a one-day holder by 3:1, which is enough to reward loyalty without being so steep that a one-month holder’s voice is worthless. I picked it from playing with the numbers; there’s no first-principles derivation.

Knob 3: logarithmic volume scaling

Volume Factor = log(USD Value) / Scaling Constant

This is the knob that compresses the whale-vs-minnow asymmetry on top of the tier. Inside Tier 5 (everyone with 100k+),a100k+), a 100M holder has log(100,000,000) ≈ 18.4 and a $100k holder has log(100,000) ≈ 11.5. The ratio is 1.6×, not 1000×.

Combine the tiers (which compress the across-tier asymmetry) with the log volume factor (which compresses the within-tier asymmetry) and you get a system where a 100Mwhaleanda100M whale and a 100 retail holder have voting power in roughly a 50:1 ratio, not the 1,000,000:1 they’d have under linear weight.

50:1 still isn’t equal. It’s not supposed to be. The point isn’t “everyone’s vote weighs the same.” The point is “the vote distribution roughly tracks economic interest in the protocol without being decided by a single capital-rich faction.”

The final formula

Voting Power = min(max(Tier Base Power × Time Multiplier × Volume Factor, 1), MaxVotingPower)

min and max with floor 1 and ceiling MaxVotingPower are the safety valves. Floor 1 prevents accidentally zero-ing out a small holder due to a calculation glitch. The ceiling prevents the founder’s anniversary-and-largest-holder slot from accumulating an absolute monopoly.

MaxVotingPower is left intentionally undefined in the proposal because it depends on protocol stage. Pre-launch, you might want a low cap (say, 0.5% of total possible voting power) so that no single wallet can hard-pass a proposal. Post-mature, you might raise it because the holder base is wide enough that the cap is mostly hit by exchange wallets you’d want to suppress anyway.

What the proposal doesn’t solve

I want to be honest about the holes:

Sybil attacks via wallet splitting. Nothing in TW-TVV prevents a 1Mwhalefromsplittinginto100walletsof1M whale from splitting into 100 wallets of 10k each, putting each in Tier 4, and aggregating power that way. Tier 4 base 12 × time 1× × log(10000)/k = ~28 weight per wallet × 100 wallets = 2800 weight, vs. one wallet at Tier 5 with base 18 × time 1× × log(1000000)/k = ~37. Splitting gains the attacker an order of magnitude of weight. The proposal as written is anti-Sybil-naive.

The fix — proof-of-personhood, KYC tier, social graph attestations — is a project an order of magnitude bigger than the voting math. I knew it when I wrote the proposal. I shipped the proposal anyway because the math was the easier half.

Vote buying. If voting power is dollar-denominated, the going rate to bribe a Tier-3 voter is bounded by the cost of buying enough tokens to reach Tier 4. That’s a dramatic improvement over token-weight (where bribery has no floor), but it’s not eliminated. The standard mitigation — secret-ballot voting via ZK proofs — is something the rest of the m0n3y stack would naturally support. I just didn’t write it down in the same proposal.

Exchange custody. If you hold your tokens on Binance, Binance votes for you. TW-TVV doesn’t help with this. The fix is forcing exchanges to either pass through votes (some do; most don’t) or excluding centrally-custodied tokens from the eligible voter pool, which is a much harder on-chain detection problem than the math here.

Dollar-pegged stake under volatile native assets. If $M0N3Y the token tanks 90%, suddenly everyone drops several tiers at once. That’s correct in spirit (your economic interest in the protocol is smaller now) but causes a governance discontinuity at exactly the moment you might need stability. The right answer is to compute the USD value at time of stake commitment for vote, not at vote time, with a window — i.e. you “lock in” the dollar valuation when you announce intent to vote.

What this told me about mechanism design

I wrote this proposal in a single afternoon, six weeks after the m0n3y docs site went up. It is the first governance design I’d written down in any rigor. Looking back I notice three things:

  1. The hard part wasn’t the math; it was committing to a specific tier table. I rewrote the table four times. Each rewrite rebalanced who got what weight. Every choice felt like rigging the system in someone’s favor — because every choice does. There’s no neutral table.

  2. The formula is short. The defense of the formula is long. The voting math is 4 lines. The justification for each variable is a paragraph each. If a community can’t read those four paragraphs and consent to the choices, the formula is a fiction.

  3. The proposal hasn’t shipped. It probably never will, in this exact form. The instinct it embodies — “value × time, with caps, against linearization” — has already shown up in how I think about other systems. The shielded-pool zera-wallet’s NFC bearer cards implicitly use a “value-tier” idea (cards with $10k+ get a different visual treatment because they need different operational caution). The m0n3y burn-to-earn doc was written to address the same hoarding problem from a fee-side angle.

What I’d do differently

If I were going to ship this for real today:

  • Continuous tier function (logistic curve, e.g., power = 18 / (1 + exp(-(log10(usd) - 3.5) / 0.4))) instead of step function. Smooths the cliff.
  • Vote commitment, not vote-time pricing. Lock in the dollar valuation when you commit to vote, not at vote-resolution time. Removes a manipulation surface.
  • Sybil-resistant proof-of-personhood layer, even if optional. World ID, BrightID, Privado ID all viable in 2026; pick one and require it for Tier 5+ to amplify weight beyond cap.
  • Public auditable vote receipts via ZK so that voters can prove they voted without revealing how. Cuts vote-buying.
  • Quadratic on top of TW-TVV, possibly. Gitcoin’s quadratic funding work shows that compressing whale influence further (by paying the square root of weight, not weight) provides additional protection without erasing all weight differentials.

Further reading

Hire me — book a 30-min call $ book →