# Distribution channels: is the GSA-3 mechanism running?

GSA-3 (Revenue Distribution) passes when a hardcoded contract routes protocol revenue
toward the token. Eight of the 53 scored DAOs pass it. The determination states that the
mechanism exists. It does not state that the mechanism has paid anything, and until this
surface existed a channel dormant for two years read the same as one paying hourly.

`/data/distributions/distributions.json` closes that gap. One row per passing DAO.

## What a row contains

- `contracts[]` — the address that constitutes the channel, the role it plays, and the
  bytecode size read at the probe block. Addresses are not published unless the read found
  code; an address that returns zero bytes is refused, and the reason is in `refused[]`.
- `reads[]` — the state read against that contract at two pinned blocks, with the raw value
  and its human form. Balance of the payout asset, a payout checkpoint, a stream period, a
  vault's assets, a burn address balance, a module balance, a fill history: whichever of
  those the channel actually exposes.
- `finding_state` — one of `flow_observed`, `no_flow_in_window`, `no_contract`,
  `unreadable`.
- `last_observed_flow` — the newest dated flow the reads support, or a typed null saying no
  dated flow was found rather than an estimate.
- `supply` — the token's total supply at the same two blocks, so a burn or emission is
  visible beside the channel.

## What it does not say

`no_flow_in_window` is not a breach. No standard here commits to a payment floor, and a
period of low revenue produces no payment without anything being violated. The row states
what moved; it does not score the channel.

A balance delta is a state read, not a log scan. A distributor that receives and pays out
inside the same window can show a flat balance while moving real money — which is why a
payout checkpoint, a stream period or a fill history is read where one exists. Where an event
count is published, `truncated` says whether the read stopped at a page limit; a truncated
count is a floor, not a window total.

A token supply change is published beside a channel, never attributed to it without a
matching inflow.

Hyperliquid's channel is an L1 account with no bytecode. It is reported as an account, and
never as an enforcement contract.

## How the channel is identified

From contract reads, not from documentation. A channel is named only when a function of one
contract returns the other (`feeTo()`, `distributor()`, `pair()`, `receiver()`), or when the
address is a module or account named by the chain itself. The registry that lists the
channels is curated; every address in it is re-read for bytecode at each probe, and a
zero-byte address fails generation.

## Freshness

`as_of`, `observation_age_days` and `stale` state how old the newest read is. After seven
days the artifact says so rather than presenting an old read as current.

## Licence

CC-BY-4.0. No authentication, no key.