m0n3y: Naming a Dream

The docs site that came before the code. Looking back at the m0n3y-web init commit and the voting proposal that was supposed to fix DAO whales.

Every project I’ve ever shipped started with a docs site. Not a prototype, not a proof-of-concept, not a hello-world Anchor program — a docs site. Because if I can’t write down what the thing is supposed to do, I’m not going to be able to build it. So when I sat down on a Sunday in February to start what would eventually become the Zera ecosystem, the very first commit landed in m0n3y-web, nicknamed init, dropped at a567855 on 2025-02-23.

The site itself was a fork of an Astro docs starter — nothing exotic. The interesting part was the README, which still introduces the project as DAXSO Documentation Site, and the first content page that explained what m0n3y was supposed to be:

Monopoly Money represents a groundbreaking implementation of privacy-preserving digital cash on the Solana blockchain, offering users a unique combination of privacy, offline functionality, and the familiar experience of physical cash.

This is the same idea I’d already been ranting about in Building A Better Cryptocurrency — that the cypherpunks were right and we collectively forgot. The difference is that this was the first time I committed to an actual implementation target instead of a manifesto: a dual-token ecosystem ($M0N3Y for governance, $pUSD as a 1:1 USDC-backed privacy stablecoin), running on Solana, with NFC-based offline tap-to-pay.

Why a docs site first?

Because the design constraints write themselves once you have to put them in plain English. As soon as I tried to describe $pUSD I had to answer questions I’d been hand-waving for months:

Where does the privacy come from? (Answer: zk circuits + shielded notes — eventually circomlib + snarkjs Groth16.)
How does an offline payment reconcile? (Answer: encrypted note commitments anchored to an on-chain Merkle tree, with notes scanned via ECDH.)
Who runs the relayer? (Answer: optional, pluggable, but not required for self-custody.)

A docs site forces you to commit a story to a permanent, dated artifact. That artifact becomes the design doc you can be honest with later when you change your mind.

Plausible: when the docs are also a thesis

The next interesting commit on m0n3y-web is 8b984d5 — :chart_with_upwards_trend: Add plausible (2025-02-28). This is where I put privacy-respecting analytics on the privacy-respecting docs site. The diff is three files. It’s deliberately the only telemetry I’m willing to ship for a project whose entire pitch is “we got privacy wrong, let’s fix it”:

// astro.config.mjs
plausible({
  domain: "m0n3y.cash",
  src: "https://plausible.skill-issue.dev/js/script.js",
});

If you put Google Analytics on a privacy crypto project, the universe is allowed to laugh at you.

The voting proposal

The most under-rated commit in m0n3y-web is 427042a — :sparkles: Added voting prop (2025-03-18). It introduces a single new page: /voting. The whole post is a stab at fixing DAO governance, which by 2025 had already calcified into a system where a16z votes 25 times for every retail holder votes once.

The proposal was titled Time-Weighted Tiered Value Voting (TW-TVV). Three knobs:

USD value tiers, not token quantity. Voting power is denominated in dollars at vote time, not in $TOKEN at acquisition time.

Time multiplier, with a cap:

Time Multiplier = Base Factor + (Holding Duration in Days / Time Division Factor)

Logarithmic volume scaling, so whales still vote more than minnows but not 10,000× more:
```
Volume Factor = log(USD Value) / Scaling Constant
```

The actual mechanism design is more involved — there’s a tier table, a per-vote-cost-in-energy thing, the works — but the headline is: the protocol explicitly devalues a token that hasn’t been used. That’s the same anti-hoarding instinct I’d argued for in a better crypto under the names “demurrage” and “velocity requirements.” The voting proposal is what happens when you try to encode that instinct into a governance system instead of a fee structure.

Trade-offs: writing docs before code

I’m not going to pretend this is universally correct. Writing docs first has costs:

You lock in vocabulary you’ll regret. “Monopoly Money” is funny but doesn’t pass an investor smell test. By the time the SDK landed it had been rebranded to ZERA. By April 2026 the Bitcoin-fork side had been re-rebranded again to Vanta. Every rebrand forces a docs rewrite.
You design for problems you don’t have yet. The TW-TVV proposal assumes a DAO; I have not yet built a DAO. There is a real possibility I never will.
Readers think it’s done. A polished docs site reads as “this is shipping next week.” It is not.

But the trade-offs cut the other way too. Every time I sat down to write a Solana program, I could open the docs site and check what the user-facing semantics were supposed to be. When zeraswap shipped the first compressed-token AMM nine months later, the docs site is what told me that “internal balances must reconcile to compressed tokens before AMM exit” was a contract I’d already promised. That ended up costing me a post-graduation conversion path I would have otherwise skipped, and saved me from shipping a footgun.

What this taught me

If you’re going to spend a year on a project, give yourself a permanent dated record of what you thought it was on day one. Not a Notion doc — those rot. A git repo with a deploy URL, an analytics provider you trust, and Markdown files committed by date. You’ll come back to that record more than you think.

Why a docs site first?

Plausible: when the docs are also a thesis

The voting proposal

Trade-offs: writing docs before code

What this taught me

Further reading