Governance and neutrality

Governance and neutrality

The meed is the protocol's defining feature, so who controls it matters. The schedule is capped by the protocol, and the surrounding rules are designed to remove the governing body's incentive to profit from its own decisions.

PayTP is today a draft authored independently by Martin Walfisz, and its governance is a designed model, not yet a running institution: the neutral PayTP Foundation described here is the planned end-state — required before any deployment, its charter not yet decided (see status), not a body that exists today. The properties below are what that model is built to guarantee.

A flat 1%, and no participant can raise it alone. The meed is exactly 1% (100 basis points), split across the enabling roles on the meed and identical on every payment. A merchant may separately add opt-in in-protocol services — escrow, dispute resolution — that cost up to a further 0.5%; these are the merchant's choice and never touch the base. Changing the schedule takes broad consensus (below), so no participant can enlarge its own share.

An absent role gains no one. When no approved operating system applies — a headless server, say, or a denied registry entry — the 0.10% operating-system share goes to an independent open-source fund outside the Foundation's control. Whoever decides operating-system eligibility therefore gains nothing by denying one, and the registry cannot be gatekept for revenue.

Deciding is separate from spending. Registry decisions are kept separate from administering the funds, and the charter restricts the Development Fund to specification work, audits, conformance, and grants. Changing the split is meant to be hard and rare, under a process the charter will settle before deployment; the 100 bp base and 150 bp cap bind every version regardless, so no group can enlarge or redirect the split toward itself. Registry denials and revocations can be appealed to a body the Foundation does not appoint.

Governance can be replaced. Any wire-compatible implementation may state PayTP compatibility, and may fork the governance while keeping that right. A Foundation that misused its position could be forked away from without disrupting existing payments — technically straightforward, though the fork must still win the adoption the incumbent already holds.

Collection by selection, not capture. No cryptography forces anyone to use PayTP: plain x402, cards, and direct transfers remain open beside it, meed-free — so avoiding the meed just means transacting off PayTP, not defeating it. It is collected where PayTP-aware software carries the payment, because that is where it earns: the interaction layer and wallet earn their share only on PayTP payments, so they select it. On the one-shot baseline the split is enforced by construction; within a channel the accounting is tamper-evident (provable), not tamper-proof. The specification states these edges rather than hiding them.