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.

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.

Decision Lane

Motions awaiting verdict

Governance Lane

Signaling closed

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

Signaling closed

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: 2026-06-07 · 04:43 UTC
Turnout: 6 wallets

For181.44M

Against0

Abstain0

Governance Loop

Signaling closed, verdict pending

The signaling window has closed. The verdict is waiting for operator publication.

2/4 loop stages complete

01
Shape
Draft and discussion

Ready
02
Signal
Holder signals

Closed
03
Decide
Approval or rejection

Verdict 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 wallets (quorum of 3 met)
Window: Closed
Support: 100% For
Closed: 2026-06-07 · 04:43 UTC
Clock: 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 (not published yet)
Publish: Publish approval

Draft receipt: Approved for execution

Holder signaling closed with 181.44M For, 0 Against, and 0 Abstain across 6 wallets. Execution follows only after the operator publishes this verdict.

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 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 2026-06-03 · 22:44 UTC

For 0xFd2A...51e1 · 20.05M signal weight
Saja 2026-06-02 · 21:04 UTC

For 0x6a1b...C723 · 100M signal weight
holder-89ca09-531b 2026-05-24 · 16:24 UTC

For 0x89Ca...531B · 1.01M signal weight
holder-efa404-24f5 2026-05-24 · 08:51 UTC

For 0xEFA4...24F5 · 60.38M signal weight
holder-121b3e-4c3b 2026-05-24 · 05:31 UTC

For 0x121b...4c3B · 10 signal weight
holder-4ce74f-4d51 2026-05-24 · 05:25 UTC

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

Signaling closed

Ratify the DAOrg governance MVP

Signaling closed

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: 2026-04-25 · 14:27 UTC
Turnout: 1 wallet

For40.11M

Against0

Abstain0

Governance Loop

Signaling closed, verdict pending

The signaling window has closed. The verdict is waiting for operator publication.

2/4 loop stages complete

01
Shape
Draft and discussion

Ready
02
Signal
Holder signals

Closed
03
Decide
Approval or rejection

Verdict 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
Closed: 2026-04-25 · 14:27 UTC
Clock: 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 (not published yet)
Publish: Publish rejection

Draft receipt: Rejected after signaling

If published, this motion closes as rejected: 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 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 2026-04-22 · 06:46 UTC

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

Pipeline

Drafts and discussion

Architecture Context

Motion

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: 2026-06-15

Motion

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: 2026-06-03

Motion

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: 2026-05-24

Motion

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)…

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

Motion

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: 2026-05-15

Launch Path

Go from first glance to live action.

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

Decision Lane

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

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

Signaling closed 2026-06-07 · 04:43 UTC · verdict pending

Open decision lane

Runtime Proof

Live governance runtime is public

Wallet sign-in and governance writes are on for this site. You can verify it yourself from the public status file.

Status: live · Wallet sign-in on

Open receipt ledger Open status JSON

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

Governance Radar

What the org is doing right now.

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

Awaiting verdict

2 motions awaiting verdict

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

Operator action required · 35 days ago

Open live motions

Pipeline

5 motions in draft or discussion

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

Draft · 2026-06-15

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 will resolve into a public index derived from contribution proof and holder confirmation once the first receipt cycle closes.

3 batches · 0.55193194 ETH · 22 wallets · 1 DAOrg reward motion

Open rewards lane Open reward index JSON

Runtime Proof

Live governance runtime is public

Wallet sign-in and governance writes are on for this site. You can verify it yourself from the public status file.

Status: live · Wallet sign-in on

Open receipt ledger Open status JSON

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

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.

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

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 once public reads are on. The runtime readiness endpoint carries the machine flag.

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

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 once the local app proof lane reports pass.

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

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.

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

Earn your first reward receipt.

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

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 create observable product value or expose 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.

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 of 5 in use
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

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.