The ZAO Fractal: Measured State

As of 2026-09-02. What is specifically true about this fractal, measured rather than described.

General fractal theory is already covered and does not need repeating: reference/ has 16 documents on Larimer, Fractally, Eden, Optimism Fractal and Respect mechanics, and research/01-foundations-deep.md goes deeper. This document is only the ZAO part, and only the parts that were read from the chain or the database.

It extends research/onchain-governance-audit-2026-07-21.md, which remains correct where it overlaps. All three things that audit listed as unreachable are resolved here (section 4), and two of its open flags are closed (sections 7 and 8).

1. The system, as it actually is

The six-day floor. 72h voting plus 72h veto means no fractal result can reach chain in under six days. This is visible in the data, not just the config: each week’s execute transaction lands roughly six days after its proposal. Any design in which a session ends and Respect appears that evening is impossible.

OG is transferable and ZOR is not. That asymmetry matters: governance weight (OG) can be moved between wallets, while earned Respect (ZOR) cannot. Not previously recorded anywhere.

2. How the game actually runs, from the award ledger

Read via alchemy_getAssetTransfers over ZOR mints from the zero address. The periodNumber is carried in the non-fungible token id (bytes 4-11; bytes 0-3 are the mint type).

Four things follow, none of them in any existing document.

Periods are minted late, in batches, and out of order. Period 106 minted across two dates two weeks apart. Period 107 the same. The tidy picture of “a fractal happens, its Respect is minted” is not what the ledger shows.

Period 103 has no awards at all. A week where the game either did not run or was never submitted. Which, is open.

Period 111 has exactly one award. The most recent fractal’s Respect is almost entirely unsubmitted as of 2026-09-02. Zaal’s 2026-09-01 decision - propose for whoever has a wallet, supplementary proposal later - is already the de facto practice, just unmanaged and untracked.

Award counts per period range from 1 to 12, so the number of groups and the number of people per group both vary week to week.

3. The concentration risk, named precisely

Every one of the last twelve ZOR mints was sent by 0x7234…e9afoptimism, calling the OREC executor.

voteWeightOf and respectOf both return 3094 for that address, against a minWeight of 1000. One key clears the passing threshold three times over, alone, every week.

research/onchain-governance-audit-2026-07-21.md independently lists Zaal’s OG holding as 3094. The addresses therefore match: that wallet is the founder’s, not a service key.

CORRECTED 2026-09-02. “Sole relayer” was the wrong frame. OREC’s execute is permissionless: the burn transaction in section 12 was sent by 0xaed6…6286optimism, which holds zero OG, and it executed successfully. So relaying is replaceable by anyone and is not the risk. The risk is narrower and sharper than first stated: one wallet holds enough vote weight to pass any proposal alone, and it is the same wallet that in practice does the relaying. Losing the key stops nothing being executed; it stops anything being passed.

That sharpens the risk rather than softening it. If that key is lost, no Respect can be minted by anyone, because ZOR’s owner is OREC and OREC needs a passing proposal. whitepaper/draft/ch10-roadmap.md carries a milestone dated 2026-06-30, “Establish 3+ Signer Committee for OREC”. It is two months overdue and this is what it was for.

Zaal was shown this measurement on 2026-09-01 and chose to accept the risk for now. Recorded so the acceptance is visible rather than looking like nobody noticed.

4. What today resolved from the July audit

That audit’s “Tooling notes” listed three blockers. All three were solvable from this machine, and the credentials were in ~/Documents/ZAO OS V1/.env.local the whole time.

• “Historical event scans: public RPC caps eth_getLogs range… needs an Alchemy key” - ALCHEMY_API_KEY is in that file. Full award-ledger reconstruction now works via alchemy_getAssetTransfers, which is what section 2 is built from.
• “ZAOOS Supabase (respect_members, wallets) … not reachable from this session” - reachable via REST with the service role key in the same file. Project efsxtoxvigqowjhgcbiz.
• “the ORDAO tokens Airtable was not reachable” - reached, section 7. The base id is not in any env file; it is hardcoded in ZAO OS source.

And one correction to that audit’s framing: wallets does not exist. It is named as a table to reach; it is not in the schema. Only respect_members, users and the fractal_* tables are.

5. The offchain half, and why it went dark

Nothing has been recorded since 2026-03-23. The newest bot-written session is “ZAO Fractal 92 - Group 1”. Zero sessions created after 2026-04-15.

The cause is not a code bug. The deployed bot’s .env, downloaded from the bot-hosting panel on 2026-09-01, contains ALCHEMY_API_KEY, DISCORD_TOKEN, FRACTAL_BOT_WEBHOOK_SECRET and WEB_WEBHOOK_URL - and no Supabase credentials at all. Its only write path was ZAO OS’s webhook, whose own header comment reads “fire-and-forget semantics (10s timeout)”.

So the game ran correctly every week for five months and recorded nothing, and nothing depended on the recording strongly enough for anyone to notice.

The chain is the only complete ledger of what was minted - though section 11 shows that is not the same as what was played, since periods 71 and 72 were scored in Airtable and never minted at all. What exists only in Supabase, and is therefore lost for the 2026-03-23 to 2026-09-02 window, is the human layer: names, Discord ids, group names, facilitator, thread links, and anyone who attended and earned nothing.

6. The two registries, reconciled (2026-09-02)

Closes section 6’s first open item. The ORDAO tokens Airtable is reachable: base appTUNG04rjZ9kSF4, via AIRTABLE_TOKEN in ~/Documents/ZAO OS V1/.env.local. Tables: Summary, Respect, Misc, Fractal Hosts, ZAO Festivals, Wallet Data. The base id is hardcoded at ZAO OS V1/src/app/api/admin/respect-import/route.ts:10, not in any env file, which is why it was not found before.

AIRTABLE_PAT returns 403 and AIRTABLE_TOKEN works; neither can list bases (no schema.bases:read scope), only read records.

Reconciled on lowercased wallet address:

Roughly 15% of the membership exists in exactly one of the two systems. The counts being nearly equal (187 vs 188) hides this: it looks like two copies of one list, and it is not.

7.1 The drift has a face

0xf73485a6... is Iman in Airtable and 0xf734...a8ea - an unnamed hex placeholder - in respect_members.

That wallet is a recipient in period 110’s award transaction 0x10d6878532... on 2026-08-25, at rank 4, level 3, 26 Respect.

So a member earns Respect, is named correctly on the public leaderboard, and is anonymous to the bot that runs the game. Any bot feature that resolves people by name - roster capture, /mystats, a welcome message - cannot see him.

The other mismatch is cosmetic: 0$ versus 0$ (OS).

7. The OG/ZOR numbering overlap, closed

Closes the 2026-07-21 audit’s open flag 4, which read: OG “fractals 1-73 through Sep 2025” but froze Dec 2025; ZOR “74+ from Sep 2025”. 3-month overlap unexplained.

Full ZOR mint ledger read from genesis via alchemy_getAssetTransfers (order: asc, paged to exhaustion - the entire ZOR history fits in one page of 1000 transfers).

ZOR awards begin at period 67, on 2025-09-25. Not 74. Periods 1 through 66 carry no ZOR award at all.

Periods present: 67 through 111, except 71, 72 and 103, plus an anomalous period 0.

Three corrections and one new question follow.

• The documented “ZOR from 74” is wrong by seven periods; the chain says 67.
• The gap is not just period 103. Periods 71 and 72 are also empty, and no document mentions them.
• Period 0 has awards dated 2026-08-18, which is not a plausible first fractal. Something minted with an unset period number. Unexplained, and worth chasing because it means the period field is not always populated correctly.

On the overlap itself: the 20 most recent OG mints all went to a single address, 0x7234c36a..., in bulk amounts (2852, 2559, 2000, 1000, 110, 50), the last on 2025-12-09. Those are not per-member fractal awards. So the “overlap” is not two award ledgers running concurrently - it is ZOR taking over per-member awards from period 67 while OG continued to receive bulk mints to one wallet until the December freeze. That is a materially different story from the one the whitepaper tells, and it should be checked against the operators before being written into ch06.

8. Who can actually vote (2026-09-02)

Closes the app-versus-chain weight item, carried over from the 2026-07-21 audit. Read directly: balanceOf on OG and balanceOf(addr, 0) on ZOR, for every one of the 161 respect_members rows that has a wallet.

Members hold 37,512 of OG’s 38,484 supply, and 15,684 ZOR.

Twenty-eight members have earned Respect and cannot vote on anything. That is 20% of the 143 members holding any Respect at all. OREC’s respectContract is OG, OG has been frozen since December 2025, and ZOR is not a governance token - so anyone who arrived after the freeze accumulates Respect weekly and accumulates no say, permanently, by construction.

The dashboard does not show this. computeRespectWeight sums OG + ZOR and labels the result “weight”. For these 28 people that number is not their voting power, it is their lifetime earnings, and the two are presented identically.

The highest-earning members with no vote:

0xf734...a8ea is Iman - the same wallet as section 6.1, named in Airtable and anonymous in respect_members. He is simultaneously the most-earning voteless member of the fractal and a member the bot cannot identify by name. Two independent defects landing on one person is a useful test of whether these findings matter in practice.

For scale: 738 ZOR is more than the OG holding of most voting members, and minWeight to pass a proposal is 1000.

This is not a bug in any component. Every part behaves as written. It is a governance design consequence that nothing currently surfaces to the people it affects.

9. The period 0 anomaly, explained

One award carries period 0: 1 Respect, mint type 10, to 0x70a7…4743optimism, on 2026-08-18, transaction 0x055d04485f74....

One Respect is not on the ladder (110/68/42/26/16/10), and period 0 is not a real meeting. This is a test mint left in the live ledger. It is harmless to governance - ZOR carries no vote - but any tooling that derives the meeting list from token ids will see a phantom period 0, and any leaderboard summing ZOR counts it.

Correcting section 7: the period gaps are 71, 72 and 103; period 0 is not a gap but a stray.

10. Governance drift: two-thirds of earners cannot vote

Extends section 8 from a snapshot to a trend, and answers whether it is getting worse. It is, and the reason is structural rather than behavioural.

The weekly flow is flat. Of every period’s awardees, the share holding zero OG has not moved: 34% across periods 67-89, and 34% across periods 90-111. A third of each week’s awards have gone to people with no vote, steadily, for a year. No trend.

The accumulated stock is not flat. Of everyone who has ever received a ZOR award, up to and including each period:

Two-thirds of everyone who has ever earned Respect in the ZOR era cannot vote, and the figure rises monotonically.

It has to. OG is the governance token, OG froze in December 2025, and ZOR confers no vote. No new voter can ever be created under the current configuration. Every new participant is added to the denominator and never to the numerator, so the share converges to 100% as the community grows. Nothing anyone does at a meeting can change it.

Method: ZOR mints from genesis via alchemy_getAssetTransfers, joined to a batched balanceOf read of OG for all 70 distinct recipients. Caveat: OG balances are today’s. Since OG froze in December 2025 they are static for any period after that, and the late OG mints went in bulk to one address rather than to awardees, so this is a fair proxy for the earlier periods too - but it is a proxy, not a point-in-time read.

11. Two meetings were played and never paid

Closes the periods 71, 72 and 103 question, using the Airtable Respect table, which carries one column per meeting (186 member rows, 192 columns, 80 of them per-fractal, covering fractals 14 to 98).

Ten member-awards from November 2025 were earned and never issued. The meetings were played and scored; the Respect does not exist onchain. Whether to mint them now is an operator decision, not a research one, but the members concerned are owed and nothing currently tracks that.

Period 103 cannot be resolved from either source: the chain has no mints, and Airtable’s per-fractal columns end at 98, so its absence there is not evidence. Answering it needs the Discord history.

11.1 Neither ledger is complete

In the range where both sources overlap, periods 67 to 98, each one contains meetings the other lacks:

• Chain only: period 73 (10 awardees, 2025-11-10). No Airtable column.
• Airtable only: periods 71 and 72. No mints.

Airtable is also missing columns for fractals 26, 57, 58 and 59, all below the chain’s coverage floor of 67, so those cannot be cross-checked at all.

The practical consequence: there is no single complete record of the ZAO fractal. Section 5 said the chain is the only complete ledger. That was wrong, and this section corrects it - the chain is the only complete ledger of what was minted, which is not the same as what was played. Reconstructing the full history needs the chain, the Airtable, and Discord, and even together they have a hole at period 103.

12. Six periods currently carry no Respect

A correction to sections 2 and 11, found on 2026-09-02 by looking for burns rather than mints.

OG has never been burned. Zero transfers to the zero address, ever. The ledger is static as well as frozen.

ZOR has 28 burns, all in one transaction. 0x12c1…c5efoptimism46b8eee357be9d7891eba0f1, on 2025-10-24, executed against the OREC executor with the same selector 0xfd165a73 used for every award.

What it burned:

Every award from the first four ZOR periods, reversed in full. And none of the four has been re-minted since: their only mint dates are 2025-09-25 through 2025-10-17, all before the burn.

Combined with section 11 - periods 71 and 72 were played and never minted - periods 67 to 72, six consecutive meetings, currently carry no live Respect at all. Four were issued and revoked; two were never issued.

Whether the reversal was intended (bad data, wrong amounts, a re-run under different period numbers) or a mistake is not answerable from the chain. Note that period 73 was minted on 2025-11-10, two weeks after the burn, with 10 awardees, and periods 74 and 75 carry 17 each - unusually large. That is consistent with a re-issue under new numbers, and consistent with several other things. Do not treat it as established. It needs an operator who was there.

12.1 What this does to the earlier sections

• Section 2’s per-period table counts mint events, some of which were later reversed. It is a record of what was issued, not of what is currently held.
• The “70 distinct ZOR recipients” in section 10 likewise counts anyone ever minted to, including the 28 reversed awards.
• Neither changes section 8 or 10’s conclusions, which are computed from OG balances and are unaffected by ZOR burns.

12.2 The July audit’s decay flag was already fixed

That audit’s open flag 1 read: ch04 claims Respect decays to ~0 after ~230 weeks of inactivity, but also says OG holders keep full weight forever.

Checked 2026-09-02: no longer true. ch04 was last edited on 2026-07-22, the day after the audit, and now states plainly that “Respect ledgers are static - the current OG and ZOR balances do not decay”, using the conditional throughout for the decay model it describes as “under consideration for the next-generation Respect token”.

The measurement backs it: zero OG burns ever, and ZOR’s only burns are the single 2025-10-24 reversal. Nothing has decayed. Flag closed, and a note added to ch04 recording the evidence so it does not get re-flagged.

13. Still open

• The Airtable tokens base, still unreached. CLOSED, section 7.
• The 2025-10-24 burn, new: why were periods 67-70 reversed in full, and were they re-issued under other numbers? Needs an operator, not the chain.
• Periods 71, 72, 103. Closed for 71 and 72, section 11: both ran and were never minted. Period 103 remains open and needs Discord history; neither the chain nor Airtable can answer it.
• Period 0. CLOSED, section 9: a single 1-Respect test mint.
• App-vs-chain weight. CLOSED, section 8. 28 members have zero governance weight; the dashboard shows them a number that is not their vote.
• The OG/ZOR numbering overlap. CLOSED, section 8, with three corrections to the documented version.
• ch08-the-zao-fractal.md is stale: it says “100 Weeks” and the chain is at period 111.