Vol. I, No. 1 Thursday, October 29, 2026 Standards & Methodology
Executable rights. Machine-readable determinations. Run autonomously by bots.

Probity Institute

Methodology

What the GSA Standards Measure

The GSA standards, GSA-1 through GSA-8, are named, auditable standards for governance-token rights. Each one is a badge a DAO can earn. A GSA badge means: this DAO enforces these specific rights in code. The standards mirror the rights bundle that makes public equity markets efficient, translated into contract-level checks: control over the treasury, recallable authority, hardwired revenue distribution, bounded spending, contract-native exit. A badge is a mechanical statement about whether a right is contract-enforced. It is not an opinion about the quality or intent of any governance community.

GSA-1 through GSA-8

BadgeStandardWhat it verifiesStatus
GSA-1Sovereign TreasuryToken controls treasury via smart contract, with no multisig gateUnder review
GSA-2Recallable AuthorityToken holders can fire any delegate, operator, or councilUnder review
GSA-3Revenue DistributionProtocol revenue flows to token via a hardcoded contract mechanismUnder review
GSA-4Treasury CovenantProgrammable spend rules the treasury cannot bypassUnder review
GSA-5Information RightsContract-enforced financial disclosure at defined intervalsUnder review
GSA-6On-Chain M&AContract-native mergers without legal wrappersUnder review
GSA-7Sybil-Resistant VotingVoting resists flash-loan, Sybil, and vote-buying attacksProposed
GSA-8Dispute ResolutionOn-chain dispute mechanism with oracle input and token-holder appealProposed
Methodology freeze pending — We publish no per-DAO GSA determinations until the scoring methodology is frozen in version 1.0 and recorded in the revision log below. The table above describes what each standard verifies. It assigns no DAO a pass or a fail. This is a deliberate editorial rule: no score judgments are published before the methodology is frozen.

Audit Pipeline

Each standard carries five code-level checks, verified in three stages. The audit is behavioural. It asks whether the contract enforces the right, not whether the contract merely permits it.

  1. Static analysis. Review of contract source and ABI against the checks defined for the standard.
  2. State verification. We read live chain state through view functions to confirm the deployed contract matches the analyzed source and that the right is active.
  3. Execution test on a fork. We exercise the enforcement path on a forked network to confirm the contract behaves as claimed under a live transaction.
  4. Evidence pack. Each completed audit produces a dated evidence pack: source references, state-read outputs, and fork test results.
  5. Attestation. Once the methodology is frozen, we publish pass/fail determinations as on-chain attestations (see the Attestation Registry) and mirror them here.

Checks are defined per standard in the standards taxonomy. Five checks per standard, three verification stages, one dated evidence pack per audit. The audit certifies the presence, enforceability, and cost of exercise of a specified right in code. It does not certify operational quality or investment merit.

Mechanical Checks

Some facts about a governance proposal need no judgment at all. They are single on-chain reads that return a value, not a score. We run those as mechanical checks, publish them as dated records, and keep them outside the badge set: a mechanical check never moves a GSA cell.

The first is terms integrity: whether the close a DAO publishes is the close its governance program enforces. For a Solana SPL Governance proposal the program's closing window is computed from three stored values, and a DAO's material may describe that window differently from the way the program applies it. The record states the published close, the programmed last moment, the finalization time, each difference in seconds, and which vote instructions remain accepted in between. The method, reading recipe, and worked example are published in Three Clocks.

Revision Log

The revision log records every change to the methodology. It is empty until the methodology is frozen, and it must never be empty after that. The first entry will record the v1.0 freeze.

DateVersionChangeAuthor
No revisions recorded yet — first entry will be the methodology v1.0 freeze.