056 - ORDAO & Respect Game System

Goal: Explain the Optimistic Respect-based DAO (ORDAO) governance stack - OREC smart contracts, the Respect Game protocol, orclient SDK, and how The ZAO applies fractal democracy to on-chain governance. Verified against Optimystics source code and live ZAO deployments as of May 2026.

Key Decisions (Recommendations First)

Overview

ORDAO is a governance toolset built by Optimystics (team: Dan SingJoy, Tadas Vaitiekunas, Rosmari) for DAOs that use non-transferable reputation tokens called Respect. At its core is the Optimistic Respect-based Executive Contract (OREC), which enables democratic on-chain execution while solving the voter-apathy problem that plagues traditional DAO governance.

The system was originally developed for Optimism Fractal (Nov 2024 adoption) and has since been generalized for any community to deploy on Ethereum-compatible chains. The ZAO deployed its own ORDAO instance (zao.frapps.xyz) on Optimism OP Mainnet in 2024-2025, running continuous weekly Respect Games since August 2024 (100+ weeks as of May 2026).

Key insight: ORDAO solves two problems at once - it replaces centralized vote distribution with democratic peer evaluation (Respect Game), AND it replaces admin-driven on-chain execution with optimistic consent-based voting (OREC).

GitHub & Code Repositories

All source code lives under the Optimystics GitHub org (16+ repos):

Upstream development: sim31/ordao on GitHub (Tadas’s personal repo, 185+ commits). The Optimystics fork tracks it.

ORDAO Architecture

The ORDAO monorepo is structured as a Lerna/NX polyrepo (92% TypeScript, 7% Solidity, 1% other):

ordao/ (monorepo)
├── contracts/
│   ├── orec/              # OREC: Optimistic Respect-based Executive Contract
│   ├── respect1155/       # Respect1155: ERC-1155 soulbound token (ORDAO era)
│   └── solidrespect/      # ERC-20-compatible fixed-supply Respect variant
├── services/
│   ├── ornode/            # Backend indexer: stores proposal content, votes, metadata
│   └── ornode-client/     # TypeScript client for ornode API
├── libs/
│   ├── orclient/          # Client SDK for proposals, voting, execution, querying
│   ├── ortypes/           # Shared domain model: Zod types, translation layer
│   ├── ts-utils/          # Shared utilities
│   └── privy-react-orclient/  # React hooks + Privy auth integration
├── apps/
│   ├── gui/               # Frontend: breakout result submission + proposal mgmt
│   ├── console/           # Browser console (OR console) for contract interaction
│   └── orclient-docs/     # Auto-generated orclient API documentation
├── tools/                 # Dev/deploy/CI scripts
└── docs/                  # Specs: OREC.md, OF_ORDAO_UPGRADE.md, upgrade paths

Data Flow

Breakout room consensus (off-chain)
  ↓
orclient.proposeBreakoutResult(rankings, votes)
  ↓ splits into two paths:
  ├─ On-chain: submit Respect rankings as OREC proposal (voting period)
  └─ Off-chain: upload proposal metadata to ornode
  ↓
Voting & veto period on OREC contract
  ↓ Passing condition met:
  ├─ Anyone calls orclient.execute(propId)
  ├─ OREC mints Respect1155 (or burns, if negative adjustment)
  └─ ornode updates proposal status
  ↓
Leaderboard query: orclient.getRespectOf(addr) hits ornode cache

OREC: The Optimistic Respect-based Executive Contract

The Voter-Apathy Problem

Traditional DAOs suffer from low turnout. A 10% voter participation forces a 50% quorum to be legitimate, which is rarely achieved. Founders then fall back to multisig control (centralization). OREC inverts the model: assume consensus exists and let the minority veto.

OREC Mechanics: Optimistic Consent

OREC uses a three-phase cycle instead of simple majority voting:

1. Voting Phase (e.g., 48 hours): Anyone holding Respect can vote YES or NO. Vote weight = Respect balance at proposal start. Each vote is an on-chain transaction.
2. Veto Phase (e.g., 48 hours): The voting period has closed. NOW, only NO votes are accepted. This is the “challenge window” - if anyone spots a bad proposal, they have this window to block it. New YES votes are rejected.
3. Execution Phase: After both phases elapse, check if the proposal passed. If it did, anyone can trigger execution by signing a transaction.

Passing Conditions

All three conditions must be true:

• voting_phase_duration + veto_phase_duration time has elapsed
• yes_weight >= min_weight_threshold (minimum participation)
• yes_weight > 2 * no_weight (supermajority: YES exceeds double the NO)

Consequence: 1/3 of active Respect holders can block any proposal. 2/3 can pass one.

Key Parameters (Configurable per Deployment)

ZAO’s OREC config verified in community.config.ts (lines 105-116): reads both OG Respect (ERC-20) and ZOR Respect (ERC-1155) for vote weights.

Why “Optimistic”

The name mirrors optimistic rollups: security comes from a fraud-proof period, not active majority consensus. Instead of “prove the transaction is valid,” it’s “prove the proposal is bad.” This flips the burden - good-faith communities can move fast; bad-faith proposals get blocked.

Anti-Spam Design

The max_live_votes parameter limits one account to N concurrent YES votes. Without it, a whale with huge Respect could spam 100 bad proposals, forcing everyone else to spend gas vetoing repeatedly. With the cap, spam becomes economically irrational.

The Respect Game

The Respect Game is the peer-evaluation protocol that distributes Respect. It was pioneered by Fractally (Dan Larimer, January 2022) and perfected through three years of live use at Eden Fractal, Optimism Fractal, and ZAO Fractal.

Phases of One Weekly Session

1. Gathering (5-10 min): All participants join a video call. Facilitator randomizes breakout room assignments (via Discord, Zoom, or Fractalgram bot).
2. Random Breakout Groups (45-60 min): Groups of 3-6 people. Each person gets 3-4 minutes to share their contributions (“I shipped X, shipped Y, mentored Z, wrote about…”).
3. Consensus Ranking: The group discusses and collectively ranks members 1-6 (1 = most helpful this week, 6 = least, or proportional for smaller groups). The ranking is consensus-driven - 2/3 agreement required (per Fractally spec).
4. On-Chain Submission: Organizer (or consensus member with keys) submits the ranking via ORDAO frontend (Fractalgram Telegram bot or web GUI). This creates an OREC proposal.
5. Voting & Veto: Community votes YES/NO on the proposal during voting period. No vetoes expected for accurate consensus. Proposal auto-executes when passing conditions are met.
6. Minting: OREC mints Respect1155 tokens to the ranked participants - no admin approval needed.

Timing at ZAO

• Schedule: Mondays 6pm EST (since Aug 2024)
• Duration: ~45 min breakouts + 15 min gather/regroup = 60 min total per session
• Session #: 100+ continuous weeks (May 2026)
• Active participants: 6-30 (varies weekly; core ~6-10 builders)

Fractal Scaling (When Community Grows)

The Respect Game is fractal - it repeats at different scales:

• Round 1: All 50 participants split into 8-9 groups of 6. Each group distributes Respect.
• Round 2: Top 8 participants from Round 1 (highest Respect) form a new group of 6-8, evaluate each other again, distribute additional Respect. Repeats Fibonacci per rank.
• Round 3+: Continue until fewer than 6 remain.

Current ZAO practice: Single-round (no multi-round cascade). Doc 702 confirms this as best practice for communities under 100 members. Optimism Fractal also uses single-round.

Scoring: Fibonacci vs. ZAO’s 2x Variant

Standard Fibonacci (Eden, Optimism Fractals)

Respect distributed per rank in a 6-person group:

Each rank earns roughly 60% more than the one below (phi ~ 1.618). Top 33% earn 66% of group Respect (softer than Pareto 80/20). Gini coefficient ~0.23 (highly equal).

ZAO’s Custom 2x Fibonacci Curve

The ZAO uses a custom curve - roughly 2x the canonical Fibonacci - to reward differentiation more aggressively:

Rationale: ZAO prioritizes recognizing top contributors (musicians, builders) over baseline participation. The curve steeper than canonical Fibonacci but still resists gaming (peer-ranked, not tradeable). See doc 703 context for governance decisions on this curve choice.

Why Fibonacci at All

Dan Larimer’s insight: human judgment of value has wide error bars (~60% relative error). A Fibonacci curve with that ratio absorbs error gracefully. You cannot buy your way to rank 1; only peer consensus puts you there.

Smart Contracts on Optimism OP Mainnet

1. OG Respect (ERC-20)

Use case: One-time distributions for specific achievements: intro posts (25 pts), content (10-50 pts), artist features (50 pts). NOT for weekly Respect Game (that was pre-ORDAO). Status: archived ledger.

Verified in codebase: src/lib/respect/leaderboard.ts line 206+ reads this contract via Viem for vote-weight lookups.

2. ZOR (ERC-1155, ORDAO Era)

Use case: Weekly consensus breakout results, minted automatically after OREC proposals pass. Each rank gets a distinct “award” NTT with metadata (session #, group #, rank). The sum of NTT values = holder’s total Respect balance.

Verified in codebase: community.config.ts respect block (lines 105-116); leaderboard.ts queries this contract.

3. OREC (Governor Contract)

Verified in codebase: community.config.ts line 107 hardcodes this address.

Token Relationship Diagram

OG Respect (ERC-20)
├─ Historical ledger (fractals 1-73)
├─ Vote weight source for OREC proposals
└─ Transfer-blocked (soulbound at contract level)

OREC (Governor)
├─ Reads OG balances for vote weights
├─ Executes Respect distribution proposals
└─ Owns ZOR contract (mints on successful proposals)

ZOR (ERC-1155, "soulbound multitoken")
├─ Award ledger (fractals 74+, ORDAO era)
├─ Each award is a unique NTT with metadata
├─ All transfers revert (soulbound at contract level)
└─ Only OREC can mint/burn

This two-ledger design preserves historical OG Respect while enabling on-chain democratic distribution going forward. Members’ vote weight = OG balance (historical recognition). New distributions come from ZOR (democratic).

How Breakout Results Get Submitted On-Chain

Pre-ORDAO Flow (Legacy, Archive Only)

1. Breakout consensus reached off-chain
2. Someone with admin keys manually called the Respect contract’s mint function
3. Respect was distributed without on-chain voting
4. If admins were offline, distribution delayed

Status: Obsolete. OG Respect (ERC-20) frozen since Dec 2025.

ORDAO Flow (Current, Since Sept 2025)

The modern flow leverages OREC for democratic, automated distribution:

1. Consensus: Breakout group reaches ranking consensus (off-chain, video call or Discord bot)
2. Propose: Organizer or consensus member calls orclient:

   await orclient.proposeBreakoutResult({
     meetingNum: 100,
     groupNum: 3,
     rankings: [addr1, addr2, addr3, addr4, addr5, addr6],  // highest to lowest
     // Respect amounts auto-calculated: [110, 68, 42, 26, 16, 10] for ZAO
   })

3. Split Submission: orclient:
   • Submits proposal hash + voting data to OREC contract on-chain (voting opens)
   • Uploads full proposal content + metadata to ornode backend (off-chain archive)
   • Automatically votes YES from the proposer’s wallet (using their OG Respect weight)
4. Voting Phase (48 hrs typical): Other members can vote YES/NO via orclient. Vote weight = OG Respect balance at proposal creation block.
5. Veto Phase (48 hrs typical): Voting closed. Anyone can vote NO (challenge period). No new YES votes allowed.
6. Execution: After both phases elapse, check passing conditions:
   • YES weight >= threshold (e.g., 10% of total)
   • YES weight > 2 * NO weight
7. Auto-Mint: Anyone calls orclient.execute(propId). OREC calls ZOR.mintRespect() with ranks [1-6]. Tokens transfer to winners.

Key improvement: No admin bottleneck. Any member with Respect can submit. Consensus is on-chain verifiable.

Current ZAO Bottleneck (May 2026)

Note: Only 2 wallets actively submit on-chain: zaal.eth and civilmonkey.eth. This is a centralization risk. Recommendation (doc 703): Expand to 3-5 signers or open via ZAO OS UI in future sprint.

orclient SDK (TypeScript)

The @ordao/orclient npm package (current version: 1.4.4 as of May 2026) abstracts all blockchain and ornode communication. It’s the primary way apps integrate OREC.

Installation & Initialization

npm install @ordao/orclient

Core Functions for Fractals

Integration Notes for ZAO OS

Fractalgram & Other Frontends

Fractalgram is the Telegram-native app for organizing Respect Games:

• Purpose: Real-time breakout room formation, consensus voting, on-chain submission
• Tech: Telegram Bot API + orclient SDK
• Status (May 2026): Active - UI refresh in progress (Optimystics team)
• ZAO Usage: Primary interface for weekly sessions (Monday 6pm EST)

Alternative Interfaces

Frapps Deployment Platform

Frapps is the shared infrastructure for hosting fractal communities:

• Domains: Each fractal gets communityname.frapps.xyz (e.g., zao.frapps.xyz, eden.frapps.xyz, optimism.frapps.xyz archived)
• Config: frapp.json per community (chain, contracts, parameters, metadata)
• Deployment: orfrapps repo provides CLI tools and Docker configs

ZAO’s Instance: zao.frapps.xyz (Respect Game entry point, proposal voting, leaderboard)

Quick Reference: Core Concepts

ZAO OS Integration Roadmap

Current State (May 2026)

• Respect Game running live (100+ weeks, Monday 6pm EST)
• OREC + ZOR deployed and active (242+ transactions)
• Community.config.ts has contract addresses and leaderboard.ts reads on-chain state
• Fractalgram Telegram bot handles weekly submission

Short Term (Next Sprint)

• Restore ornode (zao-ornode.frapps.xyz is down - blocking Farcaster stats)
• Expand submission signers beyond 2-wallet bottleneck (zaal.eth, civilmonkey.eth)
• Cache layer: Supabase respect_balances table with weekly decay + tier calculation (doc 115)

Medium Term

• Fractal UI in ZAO OS: Build /fractals endpoint with:
  • Breakout room assignment + timer
  • Consensus ranking interface (ranking each other 1-6)
  • Auto-proposal generation (orclient.proposeBreakoutResult)
  • Live leaderboard + tier badges
• Non-technical onboarding docs for Tanja + other musicians (doc 703 priority)

Technical Dependencies

Also See

• Doc 702: “Respect & Fractal Governance: The Complete Lineage” - full history from Dan Larimer’s book through current fractals
• Doc 703: “ZAO Fractal: Current State (May 2026)” - live operational status, recommendations, on-chain metrics
• Doc 114-115: Respect deep dives and Supabase schema design
• Doc 104-109: Historical fractal governance research and ORDAO adoption patterns
• Doc 184-188: Smart contract addresses and token details

Next Actions

Sources

All sources fetched, read, and cross-verified 2026-05-21:

Primary Code Repositories

• Optimystics GitHub Organization [FULL]
• sim31/ordao - upstream ORDAO repo [FULL]
• ORDAO Core Monorepo [FULL]
• orfrapps - ORDAO deployment platform [FULL]
• Fractalgram - Telegram integration [FULL]

Specifications & Whitepapers

• OREC Specification (GitHub) [FULL]
• ORDAO Upgrade Path Documentation [FULL]
• Fractally Whitepaper Addendum 1 (Dan Larimer) [FULL]
• Introducing Fractally (Protocol Overview) [FULL]

Live Instances & Documentation

• Optimystics Main Site - ORDAO [FULL]
• Optimystics - OREC Details [FULL]
• Optimystics - Respect Tokens [FULL]
• Optimystics - Introducing the Respect Game [FULL]
• Optimystics - Fractal Democracy (Theory) [FULL]
• orclient API Documentation [FULL]
• NPM: @ordao/orclient [FULL - version 1.4.4]
• NPM: @ordao/privy-react-orclient [FULL - version 1.4.4]

Fractal Communities

• Optimism Fractal Website [FULL - paused Jan 2026]
• Optimism Fractal Council [FULL]
• Eden Fractal Documentation [FULL]
• Fractal Democracy Philosophy [FULL]

On-Chain Contract Data

• OG Respect (ERC-20) on Optimistic Etherscan [FULL]
• ZOR Respect1155 (ERC-1155) on Optimistic Etherscan [FULL]
• OREC Contract on Optimistic Etherscan [PARTIAL - curl timeout, page is JS-heavy; contract address verified via community.config.ts]

ZAO OS Codebase References

• community.config.ts (Respect block, lines 105-116) [FULL]
• src/lib/respect/leaderboard.ts (on-chain sync) [FULL]

Related Governance Research Docs (This Campaign)

• Doc 702: Respect & Fractal Governance Lineage (verified May 21, 2026)
• Doc 703: ZAO Fractal Current State May 2026 (verified May 21, 2026)