KINEGRANT
View on GitHubRead the Spec

KINEGRANT COMMUNITY / 01

中文

A protocol worth trusting is a protocol the community owns.

KineGrant runs on no-token DAO-style governance: transparent RFC decisions, contribution-based roles, public records, and no financial mechanism.

Join on GitHub ↗Read the governance →
0tokens · treasury · fees
3RFCs tracked
2languages
Apache-2.0all contributions

WHAT WE MEAN BY DAO

Decentralized by design.
Financial by never.

We adopt the DAO ideals that make open infrastructure trustworthy: community ownership, transparent decision records, and open participation. We remove the parts that create risk: tokens, treasuries, fundraising, and speculation.

COMMUNITY-OWNED

The protocol, schemas, and reference implementation are Apache-2.0. Domain names and registries are community assets governed by the charter.

TRANSPARENT

Every decision, vote, and committee record is public and reproducible. Nothing is decided in a closed room.

CONTRIBUTION-WEIGHTED

Influence comes from demonstrated work: reviews, implementations, reproductions, adapters, and RFC contributions. It cannot be bought.

NEVER FINANCIAL

There is no token, no coin, no NFT, no treasury, and no fundraising. DAO principles apply to governance, not to money.

WHO RUNS IT

Roles are earned.
Authority is recorded.

Contributor

Anyone whose work is merged under Apache-2.0: code, tests, documentation, translations, reproductions, and adapters.

PUBLIC RECORD
Maintainer

A contributor with merge rights, responsible for review quality, CI health, and security triage.

PUBLIC RECORD
Editor

A maintainer appointed per RFC who owns a document through the RFC lifecycle.

PUBLIC RECORD
Working Groups

Focused groups for implementation, security, standards outreach, and documentation that report publicly.

PUBLIC RECORD
Steering Committee

A small group of maintainers that resolves escalations and runs RFC final votes. Membership is documented, rotates, and is never sold.

PUBLIC RECORD
Release Manager

The maintainer who cuts a release and verifies checksummed artifacts before publication.

PUBLIC RECORD

HOW DECISIONS GET MADE

Propose.
Debate.
Record.
Decide.

  1. 01

    Propose

    File a KGP-RFC as a pull request marked RFC. Every normative change to the protocol, wire format, security properties, or governance goes through this path.

  2. 02

    Comment

    The proposal stays open for at least 14 days. Questions, objections, and alternatives are recorded in the pull request.

  3. 03

    Community vote

    Discussion is summarized and a recorded community vote is taken. Voting is advisory and weighted by contribution record, never by money.

  4. 04

    Committee review

    The steering committee reviews conflicts of interest, then votes. A supermajority accepts, rejects, or supersedes.

  5. 05

    Accepted

    Accepted RFCs are merged and tracked in the roadmap. A later RFC may supersede them.

Conflicts of interest must be disclosed; interested parties do not cast the deciding vote on their own proposal. Security-critical changes require at least two maintainer reviews, and emergency fixes are reviewed within 72 hours.

RFC STATUS BOARD

The public ledger of protocol decisions.

KGP-RFC-0001

Stable Wire Format

Accepted (final) · v1.0.0
KGP-RFC-0002

Versioned ODRL Profile (kgp-v0.2)

Draft for community review
KGP-RFC-0003

Policy Bundle Schema Stability

Draft (2026-08-15)

New proposals follow the KGP-RFC template in the repository. Every accepted RFC ships with a test plan and a compatibility statement.

CONTRIBUTION CREDENTIALS

Reputation, not reward.

Contributor

Awarded for merged work under Apache-2.0.

Maintainer

Awarded by the steering committee for sustained review and CI responsibility.

Editor

Awarded per RFC to the document owner.

Founding Implementer

A record of early external implementation or accepted contribution. Numbers cannot be bought, reserved, or transferred.

Credentials are non-transferable records with no economic value. They cannot be bought, sold, traded, staked, or used as investment instruments.

COMPLIANCE & BOUNDARIES

Open collaboration,
zero financial exposure.

HOW TO JOIN

The first contribution
is the hardest one.

  1. 01

    Read the docs

    Start with CONTRIBUTING.md and the governance charter so contributions land inside the intended scope.

  2. 02

    Find a real gap

    Pick a good-first issue, reproduce the Machine Permission Test, review an open RFC, or propose an adapter.

  3. 03

    Open a PR

    Small, precise, testable changes. Required CI must pass; security-sensitive changes need two maintainer reviews.

  4. 04

    Earn your record

    Merged work is recorded publicly. Reputation grows through demonstrated work, not payment.

No customer, adoption, certification, investment, or standards-recognition claim is made.