Live: https://redbelly.smartcodedbot.com/changelog/ The document: CHANGELOG.md
A dated record of every approved Redbelly Community DAO decision that changed governance structure, whether it was actually implemented, and what the rules are right now. Built for TASK-23 on the DAO Task Board.
A decision passing and a decision taking effect are different events, and Snapshot makes the difference checkable.
Every change to a Snapshot space configuration is an EIP-712 signed message, pinned to IPFS and dated. It cannot be edited after the fact. That gives an implementation oracle: a decision requiring a configuration change is in force only if a signed settings message postdates it and contains the change.
rbnt.eth has 18 settings messages. The last is 2026-01-28 00:13:53 UTC.
Therefore any config-requiring decision after that timestamp is provably unimplemented, which covers all 12 proposals from 2026-03-01 onward. One query reproduces it:
curl -s -X POST https://hub.snapshot.org/graphql -H 'Content-Type: application/json' \
-d '{"query":"{ messages(first: 50, where: {space: \"rbnt.eth\", type: \"settings\"}, orderBy: \"mci\", orderDirection: asc) { ipfs address timestamp } }"}'| Decision | Evidence |
|---|---|
| Remove the voting whitelist (Snapshot, closed 2026-07-05) | The whitelist strategy is still attached to the space and to both proposals created after the vote. The last config change predates it by five months. |
| Quadratic voting (Discord poll, reported 2026-03-01) | Zero of 30 proposals use the quadratic ballot type. The six proposals dated on the alleged day all ran weighted. No settings message postdates 2026-01-28. |
| Proposal creation threshold and the whitelist itself | Both are signed configuration changes with no Snapshot proposal authorising them. They went the other way: applied without ever being voted on. |
The vote to remove the whitelist passed, was announced as live by a High Council member, and was never applied. But the whitelist was never a restriction in the first place.
The strategy returns 1 point for a listed address and 0 for everyone else, against RBNT balances in the millions. Measured on the most recent proposal:
- 27 voters, of whom 15 were not on the whitelist
- Those 15 cast 6,612,407 of 24,750,586 voting power, 26.7%
- The whitelist strategy contributed 12 points in total
Voter eligibility is governed by voteValidation, which has been set to any
for the entire life of the space. All 30 proposals carry validation: any. No
voter has ever been gated.
The list also holds 90 raw entries but only 89 unique addresses, because one appears twice in different case. Do not describe it as 90 members.
DAO Guild Structure Consolidation closed on Abstain at 56.7%. Among votes that took a position, For beat Against 1,363,897 to 10,941, which is 99.2%. One reading is that nobody opposed it. The other is that no majority endorsed it.
Resolution: it did not take effect. A plurality of Abstain is an explicit refusal to decide, and the space has no quorum rule that would let a minority For carry a structural change. The observable state agrees: Section 3 was never amended and still names five pods, and later proposals say pod 24 times against guild 6. Caveat: the vocabulary was never cleaned up. The constitution itself switches to "Guild" twice inside Section 4.1 without ever defining it.
High Council Elections replaced an earlier election that was deleted. Its body states the vote "has been reset with a corrected voting method" and that "The new proposal uses Approval voting".
Resolution: the remedy described is not the remedy applied. The replacement
runs ballot type copeland, a pairwise Condorcet method, not the
tick-every-candidate-you-support count the body promises. Snapshot supports
approval as a distinct type, so this was a choice rather than a limitation.
The result stands, but voters were told the ballot worked differently from how
it actually worked.
The live Notion page and the ratified PDF both claim to be v1.2. They differ in Section 4.1:
| Step | Ratified PDF | Live Notion page |
|---|---|---|
| 1 | "Submit proposal via Google form" | "Submit proposal via Notion form" |
| 5 | "Vote via Snapshot" | "Vote via Snapshot (for projects >5k RBNT/USDT) or Discord (for holders <5k RBNT)" |
The live page introduces a second voting venue and a wealth-based routing rule that was never ratified. The string "Notion form" appears zero times in the ratified PDF and no value-routing rule exists in it. Section 9 requires "Version control and public publishing required for each update", so this is a constitutional change made by document edit rather than by vote.
Every clause in this changelog is cited from the ratified PDF, retrieved from the DAO's own API, not from the Notion page. Citing the page would cite text nobody voted on.
Verified by searching the ratified text directly:
quorum,whitelist,allowlist,electionandquadraticeach appear zero times.- The document contains exactly three day-figures: a 3-day Cross-Pod Feedback window in Section 4.1, and a 7-day notice plus a 5-day voting period in Section 9, which governs constitutional amendments only.
- So ordinary proposals have no specified voting duration. It would be wrong to say the constitution sets no voting period at all, because Section 9 does.
The guild widget returns HTTP 403, a member verification gate blocks read access even after joining, and no mirror, archive or Wayback capture of the channels exists. Any Discord-only decision therefore cannot be verified from outside the DAO, and the poll record has to be requested from an admin.
The set of poll-only decisions in this changelog is certainly incomplete and is labelled as such. Redbelly's own Month In Review for March 2026 covers the window of the alleged quadratic voting decision and records no voting-method change.
The space carries 50 proposal messages against 30 live proposals, so 20 have been deleted. One of them matters: the first High Council election, replaced two days later. Its record is gone from the archive, though the signed content remains on IPFS.
Nothing is retyped from a summary. Every fact comes from a primary record.
python3 engine/build-changelog.py -o engine/ # pull every primary record
python3 engine/verify.py # check every claim against it
python3 engine/render-changelog.py # regenerate CHANGELOG.md| Output | Source |
|---|---|
proposals.json |
Snapshot GraphQL, 30 proposals with ballot type, duration, strategies and scores |
settings-ledger.json |
The 18 signed configuration messages, each fetched from IPFS |
space.json |
Live space config, message counts, and the measured whitelist power |
constitution.json |
The 17 sections of the ratified PDF |
resources.json |
The DAO's 5 published documents, with the 2 restricted ones flagged |
engine/entries.json is the only file carrying human judgment: which proposals
are structural, what each changed, which clause it touches, and whether it was
applied. It is separate so a reviewer can disagree with a classification without
doubting the data underneath it.
verify.py runs 79 assertions against the generated data. The point is not
that they pass. It is that a reviewer can run them and see any claim in the
changelog fail if it drifts from the record.
Two parsing traps cost real time and will catch the next person:
PDF ligatures. The constitution PDF stores "Conflict" as Con<fl>ict and
"Ratified" as Rati<fi>ed using single ligature codepoints. A plain text search
for either word finds nothing, and Section 5, which carries the recusal rule and
the one-paid-role limit, silently vanished from the parse. unligature() handles
it.
A failed fetch is not a change. When one IPFS gateway dropped a request, the ledger rendered the gap as a configuration change, "whitelist 10 to None". A network error had invented a governance event. The build now retries across gateways, marks any entry it could not fetch, and refuses to diff against it.
- It cannot see inside Discord. Poll-only decisions can be listed but not verified, and the set is incomplete.
- Unverifiable is not the same as not applied. Four entries are marked unverifiable because no public record settles them either way. They are not counted among the three that demonstrably were not applied.
- The classification is one person's reading. It is published in full, in one file, so it can be argued with.
- Two DAO documents are marked internal only. They are named for completeness and were used to check understanding. Their contents are not reproduced anywhere in this deliverable.
- Snapshot space
rbnt.eth: https://snapshot.box/#/s:rbnt.eth - DAO Resources, unauthenticated:
https://us-central1-redbelly-community-dao.cloudfunctions.net/api/resources - Ratified Constitution v1.2 PDF and Code of Conduct, both from that API
- Redbelly Community DAO Leadership, November 2025
MIT.