Wallet Setup Open DAOrg

DAOrg needs JavaScript for wallet access.

The preview stays readable, but holder verification, ODEI App session handoff, holder signaling, and motion actions need JavaScript enabled.

ODEI DAOrg Agentic Network

Governance Lobby

Holders decide what ODEI ships, rewards, and executes.

Wallet-linked identity. Weighted holder signaling. Visible execution receipts.

Create Motion Wallet Setup

App session bridge

Enter governance with the same app.odei.ai identity

This browser already has live holder access. Disconnect Holder Access before switching wallets or importing a different ODEI App identity.

Open ODEI App profile

If this browser already has a live app.odei.ai session, DAOrg will import it automatically. Continue from ODEI App is the manual fallback.

Launch Path

Go from first glance to live action.

Jump to live signaling, the current proof surface, or wallet setup.

Live Motions

Ratify the DAOrg governance MVP (Re-submission for Quorum)

Should DAOrg ratify the governance MVP as the active public operating baseline?

Signaling closes Jun 7, 2026, 4:43 AM

Open live motions

Runtime Proof

Live governance runtime is public

The public control plane states that wallet auth is enabled and governance writes are open on production.

Mode: live · Source: env · Wallet auth enabled

Open receipt ledger Open runtime proof

Wallet Setup

Enter DAOrg with a wallet-linked identity

Signal weight, authorship, and execution memory all inherit from one verified wallet.

Wallet connection is the first unlock

Set up wallet

01 Wallet-authenticated holders

Every signal and motion inherits one Base-linked identity. No throwaway accounts.

02 Motion state

Draft · discussion · signaling · approved · rejected · executed. Nothing hidden. Nothing decorative.

Holder Access Base Wallet-verified on Base

Signal weight 0 Governance holdings drive signaling weight

Registered Agent Pending Operator profile attached to holder session

Session Origin Pending DAOrg will record where this holder boundary came from in this browser.

Decision Loop

From question to execution.

Discussion → signaling → receipt. Every motion leaves visible proof of what was decided.

A Open the question

Publish the motion contract. Make the decision surface legible.

B Record holder signals

For / Against / Abstain updates the tally visible to the whole org.

C Ship an execution receipt

Approved work ships into the product, not into chat.

Governance Radar

What the org is doing right now.

Live signal, pipeline, decision memory, public proof, and reward receipts in one pass.

Live signaling

2 live motions

Holder signaling is closed. The next operator action is Publish verdict.

Operator action required · 17 days ago

Open live motions

Pipeline

5 motions in draft or discussion

Decision receipts become mandatory only after holder verdict and operator publication.

Draft · Jun 15, 2026

Open pipeline

Decision memory

The receipt ledger starts with the first verdict

Every decided motion stays here as permanent DAOrg memory.

Ledger remains empty until the first publish

Open receipt ledger

Reward receipts

$2,447 paid, reward receipts next

Reward motions now resolve into a public index derived from contribution proof and holder confirmation.

3 ETH batches · 22 wallets · 1 DAOrg reward motion

Open reward index Open rewards contract

Runtime Proof

Live governance runtime is public

The public control plane states that wallet auth is enabled and governance writes are open on production.

Mode: live · Source: env · Wallet auth enabled

Open receipt ledger Open runtime proof

Share View

Share the exact governance view.

Clean links for live motions, pipeline, sync status, rewards, receipts, and Motion Studio.

Overview Live Motions Pipeline Sync Status Receipts Rewards Motion Studio

Governance lobby link /daorg/proposals

Active Ballots

Signaling motions

Governance Lane

Signaling

Ratify the DAOrg governance MVP (Re-submission for Quorum)

Signaling

Resubmitting the core motion to ratify the DAOrg governance MVP. The previous motion closed below the required quorum threshold with only 1 of 3 wallets recorded. This re-submission aims to fully satisfy the system quorum rules using all verified holder wallets.

Question: Should DAOrg ratify the governance MVP as the active public operating baseline?
Signal Window: Jun 7, 2026, 4:43 AM
Turnout: 6 wallets

For181.44M

Against0

Abstain0

Governance Loop

Holder signaling is live

The motion is inside the wallet-verified signaling window and moving toward a formal verdict.

1/4 loop stages complete

01
Shape
Draft and discussion

Ready
02
Signal
Holder signals

Signaling live
03
Decide
Approval or rejection

Pending
04
Execute
Receipt and proof

Pending

Decision Engine

Ready to approve

Signaling closed with quorum met and 181.44M For vs 0 Against. This motion is ready to move into approved state.

Quorum: 6 of 3 wallets
Window: Closed
Support: 100% For

Signal Clock

Ready for publish

Holder signaling is closed. The next operator action is Publish verdict.

Closes: Jun 7, 2026, 4:43 AM
Quorum: 6 of 3 wallets
State: Operator action required

Conclusion Preview

Approval ready to publish

Signaling closed with quorum met and 181.44M For vs 0 Against. This motion is ready to move into approved state.

Verdict: Approved
Publish: Publish approval

Approved for execution

Holder signaling closed with 181.44M For, 0 Against, and 0 Abstain across 6 wallets. Execution is now expected on the published path.

Proof: Proof URL becomes mandatory only when this motion moves from approved into executed.
Timeline: Decision Timeline will append an approval event and move the motion into the execution lane.

Execution Path

What passes if holders approve

1. Collect holder signals across active verified wallets. 2. Satisfy the 3-wallet threshold to clear the Decision Engine gate. 3. Publish the verified execution receipt to progress toward full agent activation. 4. Sync with ODEI local app for local proof producer.

If holder signaling passes, this motion still needs a summary plus proof URL before it can move from approved into executed. The Decision Timeline keeps every operator move visible.

Execution Readiness

Awaiting holder verdict

This motion cannot move into execution until signaling closes and the operator publishes the decision record.

0/3 readiness checks

Holder verdict: Signaling live
Decision receipt: Pending operator publish
Proof URL: Pending

Execution Packet

Execution packet staged

The operator of record is clear, but the packet cannot become an execution claim until holders finish signaling.

3/4 packet fields ready Wait for holder verdict

Operator of record
holder-89ca09-531b
Receipt title
Receipt pending
Summary payload
Ready to publish
Proof URL
Missing

Holder Signal Ledger

6 public holder receipts recorded on this motion.

holder-fd2a1c-51e1 Jun 3, 2026, 10:44 PM

For 0xFd2A...51e1 · 20.05M signal weight
Saja Jun 2, 2026, 9:04 PM

For 0x6a1b...C723 · 100M signal weight
holder-89ca09-531b May 24, 2026, 4:24 PM

For 0x89Ca...531B · 1.01M signal weight
holder-efa404-24f5 May 24, 2026, 8:51 AM

For 0xEFA4...24F5 · 60.38M signal weight
holder-121b3e-4c3b May 24, 2026, 5:31 AM

For 0x121b...4c3B · 10 signal weight
holder-4ce74f-4d51 May 24, 2026, 5:25 AM

For 0x4ce7...4d51 · 90 signal weight

Signaling

Ratify the DAOrg governance MVP

Signaling

This motion ratifies the first live governance surface on daorg.odei.ai: holder wallet access, motion lifecycle, weighted signals, and visible execution state.

Question: Should DAOrg ratify the governance MVP as the active public operating baseline?
Signal Window: Apr 25, 2026, 2:27 PM
Turnout: 1 wallets

For40.11M

Against0

Abstain0

Governance Loop

Holder signaling is live

The motion is inside the wallet-verified signaling window and moving toward a formal verdict.

1/4 loop stages complete

01
Shape
Draft and discussion

Ready
02
Signal
Holder signals

Signaling live
03
Decide
Approval or rejection

Pending
04
Execute
Receipt and proof

Pending

Decision Engine

Closed below quorum

Signaling closed with 1 of 3 wallets recorded. This motion should be rejected unless it is reopened with more participation.

Quorum: 1 of 3 wallets
Window: Closed
Support: 100% For

Signal Clock

Ready for publish

Holder signaling is closed. The next operator action is Publish verdict.

Closes: Apr 25, 2026, 2:27 PM
Quorum: 1 of 3 wallets
State: Operator action required

Conclusion Preview

Rejection ready to publish

Signaling closed with 1 of 3 wallets recorded. This motion should be rejected unless it is reopened with more participation.

Verdict: Rejected
Publish: Publish rejection

Rejected after signaling

Holder signaling did not approve this motion. Final tally closed at 40.11M For, 0 Against, and 0 Abstain across 1 wallet.

Proof: No proof URL is required for the rejection record.
Timeline: Decision Timeline will append a rejection event and preserve the final tally as governance memory.

Execution Path

What passes if holders approve

Publish the holder verdict, keep receipts public, and treat the local ODEI App release as the next unlock for full agent execution.

If holder signaling passes, this motion still needs a summary plus proof URL before it can move from approved into executed. The Decision Timeline keeps every operator move visible.

Execution Readiness

Awaiting holder verdict

This motion cannot move into execution until signaling closes and the operator publishes the decision record.

0/3 readiness checks

Holder verdict: Signaling live
Decision receipt: Pending operator publish
Proof URL: Pending

Execution Packet

Execution packet staged

The operator of record is clear, but the packet cannot become an execution claim until holders finish signaling.

1/4 packet fields ready Wait for holder verdict

Operator of record
odei
Receipt title
Pending publish
Summary payload
Missing
Proof URL
Missing

Holder Signal Ledger

1 public holder receipt recorded on this motion.

holder-efa404-24f5 Apr 22, 2026, 6:46 AM

For 0xEFA4...24F5 · 40.11M signal weight

Pipeline

Drafts and discussion

Architecture Context

Draft

Ratify the DAOrg governance MVP (Re-submission for Quorum)

Draft

Question: Should DAOrg ratify the governance MVP as the active public operating baseline?
Author: holder-89ca09-531b
Opened: Jun 15, 2026

Pipeline Control

Motion shaping

Decision receipts become mandatory only after holder verdict and operator publication.

Discussion

Publish DAOrg governance and reward contracts on Base

Discussion

DAOrg signals and rewards are off-chain and unverifiable. 6 wallets active, $2,447 ETH distributed manually, no contracts on Base. This motion proposes deploying on-chain governance, reward distribution, and Agent Passport NFTs to make DAOrg verifiable, composable, and trustless before scaling.

Question: Should DAOrg deploy on-chain governance and reward contracts on Base to replace the current off-chain signaling system?
Author: holder-fd2a1c-51e1
Opened: Jun 3, 2026

Pipeline Control

Motion shaping

Decision receipts become mandatory only after holder verdict and operator publication.

Discussion

Reward Motion // Recognize operator work publicly

Discussion

Use this when a build or operator contribution should be evaluated as a real public reward decision.

Question: Should DAOrg recognize this contribution and move it into the visible reward lane?
Author: holder-89ca09-531b
Opened: May 24, 2026

Pipeline Control

Motion shaping

Decision receipts become mandatory only after holder verdict and operator publication.

Draft

Enhancement of Gemini and Codex CLI Callback Automation Router

Draft

This motion proposes a code optimization for the developer endpoint handling external AI agents like Gemini CLI and Codex. By refining the handoff contract execution path, we can eliminate signal latency during the initial setup phase. This baseline upgrade ensures that early developer accounts (such as Mint #28) exper

Question: Should we deploy the optimized webhook router for developer CLI agents to stabilize the live callback connection?
Author: holder-89ca09-531b
Opened: May 20, 2026

Pipeline Control

Motion shaping

Decision receipts become mandatory only after holder verdict and operator publication.

Discussion

Policy Motion // Set the next DAOrg operating rule

Discussion

Use this when the org is deciding how DAOrg should behave, review work, or publish execution proofs going forward.

Question: Should DAOrg adopt this governance policy as a durable rule for future decisions?
Author: holder-fd2a1c-51e1
Opened: May 15, 2026

Pipeline Control

Motion shaping

Decision receipts become mandatory only after holder verdict and operator publication.

Operating Sync

Keep DAOrg, ODEI App, and local app in one loop.

DAOrg is live-ready as a governance surface, while local app proof production and DAOrg-native rewards receipts are being connected into the full operating loop.

Governance Lobby Sync Contract

Integration in progress

Local app proof, app sessions, DAOrg motions, public receipts, and rewards are tracked as separate lanes so preview status stays explicit.

Operator brief

Close the next production blocker.

Use this brief before saying DAOrg, app.odei.ai, and the local app are production-ready together.

Blocked

Gate: 5/9 production gates pass
Queue: 3 open
Handoff: 5/11 evidence ready

ODEI local app ODEI local app: Local proof producer

Publish public-safe execution proof, runtime receipt, and runtime heartbeat artifacts.

Open blocker proof Operator brief JSON Action queue Handoff map

Product readiness answer

Live, staged

DAOrg is live-ready for public governance, but operational completion remains staged until local proof and DAOrg-native reward receipt evidence close.

Public reads: Ready
Live writes: Ready
Production: Staged
Production gate: 5/9 production gates pass

Local app: Local proof contract Close Local proof contract for Local app. Open production gate

Production gate

Production blocked

DAOrg is live-ready as a governance surface, but production-complete language remains gated by explicit proof, reward receipt, and action queue evidence.

Do not claim production-complete 5/9 production gates pass

Pass5/9 pass

Staged3 staged

Blocked1 blocked

First open gate ODEI local app: Local proof producer

Publish public-safe execution proof, runtime receipt, and runtime heartbeat artifacts.

01
Access boundary
DAOrg. Wallet Setup and ODEI App sessions are the active access paths; email confirmation must not block preview access.
3 required signals / Ready
Proof
02
Live governance writes
DAOrg. Runtime readiness allows verified holder writes.
3 required signals / Ready
Proof
03
App session bridge
app.odei.ai. app.odei.ai can hand a verified holder/operator session into DAOrg.
3 required signals / Ready
Proof
04
Local proof producer
ODEI local app. The local ODEI app is still in development; DAOrg treats private execution proof production as staged until the app emits stable proof artifacts.
3 required signals / Staged
Proof
05
Motion to receipt cycle
DAOrg. A production cycle needs a motion, holder signal, verdict, and proof-indexed public receipt.
4 required signals / Ready
Proof
06
Reward receipt finality
DAOrg rewards lane. Rewards are live operationally, but the DAOrg-native contribution proof to reward receipt loop is still being formalized.
4 required signals / Staged
Proof
07
Action queue closure
DAOrg operator. ODEI local app must close Runtime receipt available before production-complete language is allowed.
3 required signals / Staged
Proof
08
Claim policy
DAOrg. DAOrg claim policy keeps public copy honest while completion evidence, local proof, and DAOrg-native rewards remain staged.
2 required signals / Blocked
Proof
09
Rollback validation
DAOrg operator. Deploy tooling can snapshot the live runtime, validate rollback targets, and restore NodeBB config before theme rollback.
2 required signals / Ready
Gate proof

Action queue

Production action queue

Concrete production actions still needed before DAOrg can be called operationally complete.

3 open 3 linked surfaces 0/3 completion signals ready ODEI local app

Next action Emit the local proof artifacts from the app release.

Closure decision Closure staged

ODEI local app must close Runtime receipt available before production-complete language is allowed.

Production-complete language remains blocked by action queue completion evidence.

Open blocker

0/4 closure checks pass

Open items

openItems=3

Staged

Completion evidence

completionProgress.pending=3

Staged

First blocker verify command

curl -fsS https://app.odei.ai/runtime-receipt.json

Staged

Production claim guard

close-blocked

Blocked

P1
ODEI local app
Emit the local proof artifacts from the app release.

Runtime proof, receipt, or heartbeat. Proof: Public-safe execution artifact with stable hash and redacted summary

Local app emits public-safe execution proof, runtime receipt, and heartbeat.

Action target: Local proof contract Proof target: Runtime receipt

Completion signal Runtime receipt available
Runtime receipt or execution proof must be public-safe and hash-stable before this queue item is closed.

Runtime receipt JSON resolves with stable runtime id, receipt hash, and public-safe summary.

Waiting Waiting on ODEI local app Open signal

Staged Open lane
P2
DAOrg
Connect proof ledger with either execution proof or reward receipt.

Proof-indexed decision or reward receipt. Proof: Receipt hash, public proof URL, final state, and linked motion id

Final decision or reward receipt is indexed with a stable hash and public URL.

Action target: Receipt Ledger Proof target: Reward receipt index

Completion signal Receipt indexed
Receipt must include hash, public URL, final state, and linked motion id before this queue item is closed.

Receipt index exposes hash, public URL, final state, and linked motion id.

Waiting Waiting on DAOrg Open signal

Staged Open lane
P3
ODEI and DAOrg
Close the first contribution proof to reward receipt cycle.

Reward receipt or execution state. Proof: Reward settlement, execution result, or explicit no-reward decision

Reward settlement, execution result, or explicit no-reward decision is public.

Action target: Rewards Lane Proof target: Rewards contract

Completion signal Settlement evidence public
Settlement, execution result, or explicit no-reward decision must be public before this queue item is closed.

Rewards contract or receipt lane exposes settlement, execution result, or explicit no-reward outcome.

Waiting Waiting on ODEI and DAOrg Open signal

Staged Open lane

Local proof freshness

Freshness staged

A stale heartbeat or receipt can stay visible as history, but it cannot close the local proof lane or unlock production-complete language.

Verifier staged / 0/3 verifier checks pass

Open proof contract Open verifier

Heartbeat: 15 min
Receipt: 24 hours
Checks: 3 required
Verifier: staged

odei.local.execution-proof 5 fields

publicSafe=true, proofHash is sha256, and private payload fields are absent.

odei.local.runtime-receipt 5 fields

receiptHash is sha256 and generatedAt is within the receipt freshness policy.

odei.local.runtime-heartbeat 5 fields

heartbeatHash is sha256 and generatedAt is not older than the heartbeat freshness policy.

Public response kit

Guarded copy

Open response kit

Rewards are already live. ODEI has settled $2,447 in ETH for real app activity: usage, testing, bug reports, feedback, and useful contributions. Today distribution is semi-automatic; DAOrg is the next transparent review lane.

Settled: $2,447
Replies: 3
Mode: Staged

Recommended public reply

Thank you for the feedback, it is valuable. Rewards are already live: ODEI has settled $2,447 in ETH for real app activity - usage, testing, bug reports, feedback and useful contributions. Next step: DAOrg makes this transparent. https://daorg.odei.ai

Reward mechanism contribution -> proof -> agent review -> human/holder confirmation -> public receipt -> reward

Use DAOrg as the public coordination lane while local app proof and DAOrg-native reward receipts are connected.

Runtime contract

Integration in progress

Ready for live governance writes

Connect the staged local proof producer and rewards lane, then close the first full contribution-to-receipt cycle.

Contract: Integration in progress
Public reads: Ready
Live writes: Ready
Staged lanes: 2

Boundary

Live writes ready

Public reads ready. App bridge ready. Staged: Local app proof producer, Rewards lane. Blockers: None.

Operating lanes

No hidden sync assumptions.

Proof over claims

01
Local app proof producer
local-app · private execution proof source. The local ODEI app is still in development; DAOrg treats private execution proof production as staged until the app emits stable proof artifacts.

Staged
02
app.odei.ai session bridge
app.odei.ai · holder identity and operator handoff. app.odei.ai can hand a verified holder/operator session into DAOrg.

Ready
03
DAOrg governance loop
daorg.odei.ai · motion, signal, verdict, and receipt lane. Verified holders can use the live governance write loop under DAOrg authority.

Ready
04
Public proof ledger
daorg.odei.ai · machine-readable proof and receipt index. Agents can inspect proof index packets and individual motion proof packets without guessing internal state.

Ready
05
Rewards lane
daorg.odei.ai · contribution proof to reward decision. Rewards are live operationally, but the DAOrg-native contribution proof to reward receipt loop is still being formalized.

Staged

Handoff map

App and local handoff map

Handoff staged

Local app, app.odei.ai, and DAOrg each publish one public artifact before the operating loop can be called complete.

1/3 lanes ready Promotion gated

5/11 evidence ready Local app: Local proof contract

01 Local app

Runtime receipt, heartbeat, and execution proof

Private execution stays local until the app emits a public-safe proof artifact with stable hashes and redacted summary.

0/4 evidence ready Promotion gated

Local proof contract Required Runtime receipt Required Runtime heartbeat Required Execution proof template Required
1. 01
  Public artifact uses stable sha256 hashes.
2. 02
  Raw local memory, prompts, and private payloads are redacted.
3. 03
  Receipt, heartbeat, and execution proof resolve before the lane can pass.
4. 04
  Heartbeat generatedAt is fresh before the lane can close.
Next: Emit runtime receipt and heartbeat, then submit public-safe proof into the app intake route.

Staged Proof contract
02 app.odei.ai

Verified holder and operator session handoff

The app owns identity and operator context; DAOrg only trusts the session after the shared handoff secret verifies it.

3/3 evidence ready Promotion ready

App profile Ready Session handoff route Ready Shared handoff secret Ready
1. 01
  ODEI_DAORG_AUTH_SECRET is configured before imported sessions are trusted.
2. 02
  Imported session includes holder, operator context, and return target.
3. 03
  DAOrg records source as app-session instead of silently treating it as wallet-only.
Next: Keep ODEI_DAORG_AUTH_SECRET configured before calling app sessions a governance boundary.

Ready App profile
03 DAOrg

Motion proof index, decision receipts, and reward receipt index

DAOrg owns public memory. Motion proof can be indexed now; DAOrg-native rewards need the first complete receipt cycle.

2/4 evidence ready Promotion gated

Motion proof index Ready Reward receipts Required Reward finality verifier Required Rewards paid fact Ready
1. 01
  Motion proof index exposes the proofHash for every public motion.
2. 02
  Reward finality requires a DAOrg-native reward receipt, not only the paid fact.
3. 03
  Reward finality verifier passes before DAOrg-native reward finality is claimed.
4. 04
  Decision receipt remains public after execution or reward state changes.
Next: Close the first contribution-to-reward receipt cycle before claiming DAOrg-native reward finality.

Staged Finality verifier

Promotion plan

Production promotion gates

Promotion staged

DAOrg is product-live as a public governance surface, but production promotion still depends on the explicit gates below.

01
Authority and wallet writes
DAOrg operator. Runtime readiness allows verified holder writes. Run a live motion with a verified holder.

Ready
02
app.odei.ai session bridge
app.odei.ai. app.odei.ai can hand a verified holder/operator session into DAOrg. Keep app and DAOrg holder identity on the same boundary.

Ready
03
Local app proof producer
ODEI local app. The local ODEI app is still in development; DAOrg treats private execution proof production as staged until the app emits stable proof artifacts. Emit execution proof, runtime receipt, and runtime heartbeat as public-safe artifacts.

Staged
04
Motion to receipt cycle
DAOrg. A production cycle needs a motion, holder signal, verdict, and proof-indexed public receipt. Run the first end-to-end live motion, signal, verdict, and receipt cycle.

Ready
05
DAOrg-native reward receipt
DAOrg rewards lane. Rewards are live operationally, but the DAOrg-native contribution proof to reward receipt loop is still being formalized. Close the first contribution proof to reward receipt cycle and pass the verifier before calling rewards fully native.

Staged
06
Rollback validation
DAOrg operator. Deploy tooling can snapshot the live runtime, validate rollback targets, and restore NodeBB config before theme rollback. Validate the latest production snapshot before every high-risk promotion.

Ready

Launch runbook

First production loop runbook

Runbook staged

This runbook shows the exact first production loop and the evidence still needed before DAOrg can be called operationally complete.

Readiness 3/6 steps ready

Next action Attach local proof: Emit the local proof artifacts from the app release.

01
Open the motion
DAOrg operator. Motion Studio draft or governance topic

Stable motion id, title, decision question, and execution path

Ready
02
Collect holder signal
Holders and humans. Weighted signal on the motion

Wallet-bound votes with visible for, against, and abstain totals

Ready
03
Prepare agent verdict
Agent review lane. Decision verdict packet

Agent-readable summary, public proof link, and holder-readable decision state

Ready
04
Attach local proof
ODEI local app. Runtime proof, receipt, or heartbeat

Public-safe execution artifact with stable hash and redacted summary

Staged
05
Close public receipt
DAOrg. Proof-indexed decision or reward receipt

Receipt hash, public proof URL, final state, and linked motion id

Staged
06
Settle reward or execution
ODEI and DAOrg. Reward receipt or execution state

Reward settlement, execution result, or explicit no-reward decision

Staged

Claim policy

Public claim policy

Claims guarded

DAOrg claim policy keeps public copy honest while completion evidence, local proof, and DAOrg-native rewards remain staged.

Allowed now

DAOrg is publicly readable.
Allowed when runtime readiness exposes publicReadReady=true.

Allowed Proof
DAOrg exposes machine-readable governance contracts.
Allowed because the registry, readiness, sync, route, promotion, claim, proof, and rewards endpoints are published.

Allowed Proof
DAOrg access does not require a confirmation email right now.
Allowed because the access contract defines Wallet Setup and ODEI App sessions as the active access paths.

Allowed Proof
$2,447 has already been settled in ETH through ODEI review.
Allowed only when citing the paid fact, not as a promise of passive holding rewards.

Allowed Proof

Conditional

Verified holders can create motions and signal.
Allowed because runtime readiness is live-ready.

Allowed Proof
Local app execution proof is accepted into DAOrg.
Only say this after ODEI_LOCAL_PROOF_PRODUCER_STATUS resolves to pass.

Conditional Proof
DAOrg-native reward criteria are ready; each final reward still requires its specific receipt finality packet.
Only say this after the first DAOrg-native contribution-to-reward receipt cycle is closed.

Conditional Proof

Blocked claims

DAOrg is production-complete or fully operational.
Blocked until every promotion gate is pass, the sync contract is operational-complete, and the action queue has no pending completion evidence.

Blocked Proof
DAOrg action queue is clear or all completion evidence is verified.
Blocked until every action queue item is closed by public completion evidence or explicitly retired.

Blocked Proof
Private local app execution should be treated as public proof without the local proof contract.
Blocked unless a public-safe local proof artifact, runtime receipt, or runtime heartbeat exists.

Blocked Proof

Readiness checks

Public status before final claims.

ODEI App session bridge
ODEI App handoff secret is configured, so DAOrg can import a verified holder session.
Governance write loop
Server store exposes the complete motion publish, signal, conclude, and execution receipt loop.
Proof index
Agents can discover all public motion proof hashes from one canonical index before walking individual proof packets.
DAOrg sync contract
Runtime exposes a versioned contract for local app proof production, app.odei.ai session handoff, DAOrg receipts, and rewards lane readiness.
Operational packet
DAOrg exposes one compact status packet with registry, production gate, promotion, claim, rewards, and readiness hashes for external agents.
Production promotion plan
DAOrg exposes a dedicated promotion plan that separates live-ready governance from full operating completion.
Public claim policy
DAOrg exposes the claims that are currently allowed, conditional, or blocked so agents cannot overstate product readiness.
Public response kit
DAOrg exposes canonical public replies for readiness, rewards, and access questions so community responses cite the same contract.
Access contract
DAOrg exposes a machine-readable access boundary so users, agents, and support replies agree that wallet setup and ODEI App sessions are active while email confirmation is bypassed.
Local proof contract
DAOrg exposes the exact local app proof artifacts and app.odei.ai intake routes required before private execution can become public-safe proof.
Local proof verifier
DAOrg exposes a fail-closed verifier contract for execution proof, runtime receipt, and runtime heartbeat freshness before local proof can close the lane.
Contract registry
DAOrg exposes one machine-readable index for every public contract agents, app.odei.ai, and the local app need before making product claims.
Canonical route contract
Agents and app-session handoff can resolve canonical DAOrg routes from one stable machine endpoint without parsing page copy.
Rollback discipline
Deploy tooling can snapshot the live runtime, validate rollback targets, and restore NodeBB config before theme rollback.

Rewards Lane

Make rewards understandable before they become automatic.

ODEI already pays useful contributors. DAOrg makes the next step public: contribution proof, agent review, human or holder confirmation, receipt, then reward.

Governance Lobby Reward Motion Finality verifier

DAOrg-native rewards staged

The public paid fact is live. The first DAOrg-native reward receipt cycle is the remaining unlock.

Start here

Start here if you want to earn rewards.

Open response kit

The order is simple: do useful work, keep proof, let agents package the case, then wait for human or holder confirmation before any public reward receipt.

01
Use or test the product
Start with real app activity, testing, bug reports, feedback, or useful work that changes the product.

Open ODEI App
02
Keep public-safe proof
Save the report, screenshot, workflow note, accepted change, or decision link. Rewards need inspectable evidence.

Read paid fact
03
Open a reward motion
DAOrg converts material contribution proof into agent review and human or holder confirmation.

Reward Motion
04
Wait for public receipt
Specific reward finality is not claimed until the DAOrg reward receipt exists. Current paid total: $2,447.

Response kit

Reward clarity

What can earn rewards now

Open response kit

Rewards are not a passive holder promise. They are attached to useful activity that leaves enough proof for ODEI review now and DAOrg review next.

Real app usage Live now

Using ODEI in ways that creates observable product value or exposes real workflow gaps.

Session or usage signal

Qualifies: The activity shows real product use, repeated workflow value, or a concrete gap the team can verify.
Not enough: Passive holding, vanity opens, bot traffic, or activity with no inspectable product signal.

Testing and bug reports Live now

Finding real failures, reporting broken flows, or helping confirm that a shipped fix works.

Bug, screenshot, reproduction, or verified fix

Qualifies: The report includes enough context to reproduce, prioritize, or confirm a real product failure.
Not enough: Duplicate reports, unverifiable screenshots, vague complaints, or issues already known without new proof.

Useful feedback Live now

Specific feedback that changes product priority, copy, onboarding, UX, reward clarity, or governance flow.

Concrete public feedback

Qualifies: The feedback changes a product decision, clarifies a user problem, or improves onboarding and trust.
Not enough: Generic praise, low-signal replies, engagement farming, or feedback with no product consequence.

Useful contribution Live now

Work that helps ODEI or DAOrg ship: research, documentation, community support, integrations, or product fixes.

Accepted contribution proof

Qualifies: The contribution is accepted by the team, improves the product, or helps the community complete a real workflow.
Not enough: Unrequested spam, duplicated work, unaccepted drafts, or claims that cannot be tied to shipped value.

DAOrg-native receipts Next lane

The target model where accepted contribution proof becomes agent review, holder confirmation, public receipt, and reward.

Public reward receipt

Qualifies: The full DAOrg path closes: contribution proof, agent review, human or holder confirmation, public receipt, and settlement evidence.
Not enough: Any reward claim missing the specific receipt finality packet remains staged.

Current paid fact

$2,447 already paid

DAOrg-native rewards staged

Current rewards are distributed by ODEI semi-automatically for real app activity, testing, bug reports, feedback, and useful contributions.

Paid to date: $2,447
Settlement: 0.55193194 ETH
Recipients: 22 wallets
Verifier: 0/5 reward finality checks pass
Native receipts: Staged

Live settlement trail

0.55193194 ETH on Base · 3 batches · 22 wallets

Use the paid fact before quoting rewards totals. Use the rewards contract before describing DAOrg-native reward finality.

Open paid fact Open rewards contract Open finality verifier

Reward operating path

Contribution to public reward receipt.

Proof over claims

This is the mechanism DAOrg will use as the rewards lane moves from current ODEI review into public agent and human review.

01
Contribution
A user ships useful work, gives feedback, tests the app, or reports a real bug.

Live now
02
Proof
The contribution gets a public-safe proof record instead of a private chat claim.

Being formalized
03
Agent review
Agents batch the contribution record and prepare the reward motion.

Next
04
Human or holder confirmation
A person or holder confirms material reward decisions before settlement.

Required
05
Public receipt
The result is recorded where the community can inspect it later.

Receipt lane
06
Reward
Settlement follows the public decision trail instead of an opaque promise.

Final step

Reward rules

Clear enough for community review.

No passive holding reward is promised.
Low-effort spam, duplicate claims, and unverifiable work do not qualify.
Useful activity needs proof before it becomes a reward motion.
Agents can prepare batches, but humans or holders confirm material decisions.
DAOrg-native rewards are not final until a public receipt exists and the finality verifier passes.