⚖️

Governance

A living constitution for the Headstone protocol, data union, and ecosystem.

Preamble

*"Competition may have gotten us here. But cooperation will lead us forward."*

— Johnny Bettencourt, Founder

Headstone exists to invert the extraction economy. Every design decision — technical, economic, and governance — serves that purpose. This document defines how the platform governs itself, how $Tone holders exercise power, how the data union operates, and how the protocol evolves.

Governing Principles: Freedom · Individual Rights · Equality · Compassion · Trust · Justice · Progress

Article I — The Data Union

1.1 Purpose

The Headstone Data Union is the collective body of all users who choose to share their data for mutual benefit. It exists to give users collective bargaining power over their data — the power that individual users lack and that centralized platforms have historically exploited.

1.2 Membership

Every Headstone user is automatically a member of the Data Union. Membership carries no cost and cannot be revoked except for violation of core principles (Article VI). Members may opt out of specific data-sharing programs without losing membership.

1.3 Rights of Members

Each member holds the right to:

1.4 Data Commons

Data shared to the Union forms the Data Commons — a collectively governed resource pool. The Commons is not owned by Headstone the company. It is owned by the Union members. Usage of Commons data by third parties requires Union approval and compensating the Union treasury.

Article II — $Tone Governance Rights

2.1 Token as Governance Instrument

$Tone serves two functions: governance weight and economic medium of exchange. Holding $Tone confers voting power proportional to holdings, with mechanisms to prevent plutocratic capture.

2.2 One Person, One Vote Foundation

For personal governance decisions (privacy policy changes, data-sharing rules), $Tone weight is secondary to human identity. One verified human = one vote on matters of personal data rights. $Tone weight applies to economic and protocol decisions (treasury allocation, fee structures, protocol upgrades).

2.3 Quadratic Voting

To prevent large holders from dominating decisions, quadratic voting applies: the cost of additional votes increases quadratically. A holder with 100 $Tone gets 10 votes. A holder with 10,000 $Tone gets 100 votes, not 10,000. This balances influence with broad participation.

2.4 Delegation

Members may delegate their voting power to another member or to a trusted third party (an advocacy organization, a research institution, a family member). Delegation is revocable at any time. Delegated votes follow the same quadratic weighting.

2.5 Minimum Participation Threshold

For a vote to be binding, minimum participation of 5% of eligible voters is required. If threshold is not met, the vote extends and the proposal is decided by a supermajority (60%) of those who did participate.

Article III — Protocol Governance

3.1 The Protocol

The Headstone protocol is the open specification for how Stones, LifeLines, data certification, and inter-Stone communication work. It is distinct from the software that implements it. The protocol is the foundation; implementations can vary.

3.2 Protocol Amendments

Amending the protocol requires:

1. A written proposal published for public comment (minimum 30 days)

2. Technical review by designated stewards (Article V)

3. Community vote with supermajority (60%) approval

4. A 90-day implementation window

Emergency amendments (security vulnerabilities, legal requirements) may proceed on an accelerated timeline with 72-hour notice and a 75% supermajority of stewards.

3.3 Backward Compatibility

Protocol amendments should maintain backward compatibility unless a supermajority (75%) determines that breaking changes are necessary for the health of the ecosystem.

3.4 Forking

The protocol is open. Any group may fork it at any point. A fork that garners more than 10% of active Stones within 6 months triggers a governance review. The federation architecture (Native In Each Domain) anticipates and accommodates forks.

Article IV — Federation Governance

4.1 Native In Each Domain

Headstone protocol implementations may be operated by independent entities in different jurisdictions. Each implementing entity is a "Domain." Domains must follow the core protocol but may adapt to local law, culture, and language.

4.2 Domain Requirements

To be recognized as an official Domain, an entity must:

4.3 User Choice

Users may choose their Domain at onboarding and may migrate their Stone between Domains at any time. Migration is a core protocol right and cannot be blocked by any Domain.

4.4 Inter-Domain Council

Each Domain appoints one representative to the Inter-Domain Council. The Council:

4.5 Domain Autonomy

Domains operate independently. A Domain's governance failures do not affect Stones in other Domains. User data never crosses Domain boundaries without explicit user consent.

Article V — Stewards

5.1 Role of Stewards

Stewards are individuals or organizations responsible for the health of the protocol, the integrity of the certification system, and the facilitation of governance. Stewards are not rulers — they are custodians.

5.2 Steward Responsibilities

5.3 Steward Appointment

Initial stewards are appointed by the founding team. After the first 10,000 active Stones, stewards are elected by $Tone holders using quadratic voting. Steward terms are 2 years, renewable once, with a maximum of 3 consecutive terms.

5.4 Steward Removal

A steward may be removed by:

This page summarizes the full specification. See the full document for complete details.

Dive Deeper

Back to Home Read the Vision