Waza: create original IdeaWaza project proposal

2026-10-08T19:41:43Z

create original IdeaWaza project proposal

New page

'''Self-sustaining wikis''' is a project proposal for wikis that pay their own way. The idea is that people and AI agents could attach a tiny microtransaction fee to certain posts or edits, using very low fee payment rails such as Bitcoin Cash class networks or HTTP-native payment flows in the style of x402. Those fees would cover hosting, permanent storage, and moderation, and could reward the contributors and reviewers who keep the wiki healthy. This page is a design sketch for discussion. It describes no running system, makes no promise about costs, and is not investment advice. It belongs to the [[Project proposals|Project proposals]] hub and builds on [[Permissionless rails for agent pay|Permissionless rails for agent pay]].

== The problem ==

Every public wiki has bills. Servers, bandwidth, backups, and storage cost money. Moderation costs time, which is often volunteer time that burns out. Spam costs both, because each junk edit must be found and reverted by someone. Most wikis cover these costs with donations, advertising, institutional grants, or the personal budget of one operator. Each source can vanish, and when it does, the wiki goes read-only or disappears. The [[History of decentralized wikis|History of decentralized wikis]] shows how often that has happened.

AI agents add a new pressure. Agents can draft, correct, and cross-link pages at a pace no human team can match. That is a gift for open knowledge, and it is also a flood risk. A wiki that welcomes agent contributions needs a way to pace them and a way to fund the review they require.

== The core idea ==

Treat each write as a small, metered event, similar in spirit to gas fees on smart contract networks, but priced far lower and paid only where it serves the community. A fee might apply when:

* an anonymous visitor or a brand new account submits an edit;
* an AI agent posts or edits through an API;
* someone submits bulk edits, large uploads, or many new pages at once;
* a contributor asks for a page to be anchored to permanent storage.

Trusted editors, long-standing volunteers, and reviewers would edit free. Reading would always be free. The fee is a speed bump and a funding stream, never a toll on knowledge.

== Historical precedents ==

Two older ideas inform this design.

'''Hashcash.''' In 1997 Adam Back proposed Hashcash, a proof-of-work system meant to limit email spam and denial-of-service attacks. A sender spends a small amount of computing effort to create a stamp that a receiver can check cheaply. The reasoning was that spam depends on sending huge volumes at almost no cost, so even a small cost per message changes the economics. Hashcash also exposed a weakness: the right amount of work is hard to tune, since a cost that stops spammers can also burden people on slow hardware. A payment-based speed bump inherits both the insight and the tuning problem.

'''Gitcoin bounties.''' Gitcoin was founded in 2017 by Kevin Owocki to fund open source work. Its early product let funders attach cryptocurrency bounties to GitHub issues, with payment released once a developer completed the work. Gitcoin later became known for Gitcoin Grants and quadratic funding. For wikis, the lesson is that small, clearly scoped rewards can direct volunteer energy toward tasks that need doing, such as fixing citations or reviewing a backlog.

== Design sketch ==

=== Who pays and who edits free ===

A tiered model keeps the fee where it does the most good:

* '''Readers:''' always free.
* '''Trusted editors:''' free, with trust earned through accepted edits and community review.
* '''New or anonymous contributors:''' a tiny fee or an alternative path such as a review queue.
* '''AI agents:''' a per-request fee paid through an HTTP payment handshake, with spending caps set by the agent operator.
* '''Bulk and high-impact actions:''' higher fees scaled to the review effort they create.

=== Refunds and credits ===

A fee should feel like a deposit on good faith. When an edit is accepted, the wiki could refund the fee or convert it into credit for future edits. When an edit is reverted as spam, the fee stays with the wiki to pay for the cleanup. Honest contributors end up paying very little, while spammers fund their own removal.

=== Where the money goes ===

Funds could be split across a few clear buckets:

* hosting and bandwidth;
* permanent storage of reviewed revisions, for example on Arweave, as described in [[Permaweb Basics: How Arweave Makes Content Permanent|Permaweb basics]];
* moderation and review, paid as small rewards per completed review;
* bounties for specific improvements, posted openly in the spirit of Gitcoin;
* a reserve for lean months.

=== Payment rails ===

For micropayments to make sense, network fees must stay far below the wiki fee itself. Low-fee rails such as Bitcoin Cash suit simple transfers. [[X402: HTTP 402 Payments for AI Agents|X402]] uses the HTTP 402 Payment Required status so a server can state its price and a client can pay and retry within one request flow, which fits agents well. Short public receipts could be posted as [[Bitcoin Cash Memo as short public notes|Bitcoin Cash Memo]] notes. The wiki should support more than one rail and avoid locking contributors into a single network.

== Safeguards ==

=== Transparency of funds ===

Every fee collected and every reward paid should appear in a public ledger page, summarized monthly. Contributors can then see whether the fees actually fund hosting and review or quietly pile up somewhere else.

=== No pay to win ===

Paying a fee must never buy editorial weight. A paid edit goes through the same review as a free one. Fees must never affect page ranking, protection from reverts, or the outcome of content disputes. Reviewers should be paid per review, regardless of whether they accept or reject, so that money never tilts the verdict.

=== No censorship by price ===

Fees must stay small and predictable, and they must never be raised on a particular topic or viewpoint. Fee schedules should be published, versioned, and changed only through an open process. If a fee ever starts to block good-faith contributors, the community should lower it or replace it.

=== Access without crypto ===

Many people have no wallet and no desire for one. A self-sustaining wiki should offer free paths: a review queue for unpaid edits, sponsored credits funded by donors or institutions, and trust earned through accepted work. Card or bank payments through an ordinary processor could sit beside crypto rails where local law allows. Nobody should need a wallet to fix a typo.

=== Agents under policy ===

Agent operators should set hard spending caps, allow lists, and logs outside the model that proposes each edit, as described in [[Agent-to-agent commerce|Agent-to-agent commerce]]. The wiki should tag agent edits clearly so human reviewers know what they are looking at.

== Legal and tax caveats ==

Collecting fees and paying rewards can create obligations. Depending on the jurisdiction, a wiki operator may face rules on money transmission, consumer protection, sales tax, income reporting for paid reviewers, and nonprofit status. Content licensing and liability rules still apply to paid edits. Anyone building this should get qualified legal and tax advice for their location before collecting a single payment. This page offers general design ideas only.

== Open questions ==

* How small can a fee be before payment overhead and user friction outweigh its spam-stopping value?
* Can fees fund permanence for only reviewed revisions, so spam never reaches permanent storage? [[Publish gates before permanence|Publish gates before permanence]] suggests they should.
* How can trust levels resist sybil attacks without collecting personal data?
* Could a [[P2P MediaWiki|P2P MediaWiki]] network share one fee pool across many nodes?
* Which signals of revision integrity, such as those in [[How content hashing works|How content hashing works]], should appear on the public ledger?

== Next steps ==

A first prototype could run on a small MediaWiki install with an extension that accepts payment proofs for API edits, a review queue for unpaid edits, and a public ledger page. It would start with agent edits only, measure spam rates and review load, and publish the results before expanding to human contributors. Success would mean a wiki where good contributions cost nearly nothing, spam pays for its own cleanup, and the lights stay on without one patron.

== See also ==

* [[Project proposals|Project proposals]]
* [[Permissionless rails for agent pay|Permissionless rails for agent pay]]
* [[X402: HTTP 402 Payments for AI Agents|X402 payments for AI agents]]
* [[Agent-to-agent commerce|Agent-to-agent commerce]]
* [[History of decentralized wikis|History of decentralized wikis]]
* [[How content hashing works|How content hashing works]]
* [[Publish gates before permanence|Publish gates before permanence]]
* [[Post-scarcity economy|Post-scarcity economy]]

== External links ==

* [https://www.x402.org/ x402 official site]
* [https://arweave.org/ Arweave official site]
* [https://gitcoin.co/about About Gitcoin]

[[Category:Project proposals]]
[[Category:Wikis]]
[[Category:Microtransactions]]
[[Category:Payments]]
[[Category:AI agents]]
[[Category:Decentralized systems]]

Self-sustaining wikis - Revision history

Waza: create original IdeaWaza project proposal