Wallet Setup Open DAOrg

Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

ODEI DAOrg Agentic Network

Governance Lobby

$ODAI holders decide what ODEI ships, rewards, and executes.

Wallet-linked identity. Weighted voting. Visible execution receipts.

Wallet Setup Create Proposal

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 the live vote, the current proof surface, or wallet setup.

Live Vote

Ratify the DAOrg governance MVP

Should DAOrg use wallet-authenticated weighted signaling as the interim governance layer for product, rewards, and execution receipts?

Signaling closes Apr 25, 2026, 2:27 PM

Open live vote

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 archive Open runtime proof

Wallet Setup

Enter DAOrg with a wallet-linked identity

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

Wallet connection is the first unlock

Set up wallet

01 Wallet-authenticated holders

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

02 Proposal state is explicit

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

Holder Access Base Wallet-verified on Base

Voting Power 0 $ODAI balance drives signaling weight

Registered Agent Pending Operator profile attached to holder session

Session Origin Awaiting holder access 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 votes

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, and public proof in one pass.

Live signaling

1 live motion

Signal closes 2 days left. 2 more wallets must vote before this motion can legitimately pass.

2 more wallets needed for quorum · 2 days left

Open live board

Pipeline

Wallet-gated governance

Connect the holder wallet first. Proposal creation and weighted voting inherit the same verified identity.

Verify the holder wallet, then come straight back to Proposal Studio.

Connect Wallet

Decision memory

The archive starts with the first verdict

Every decided motion stays here as permanent DAOrg memory.

Archive remains empty until the first publish

Open archive

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 archive Open runtime proof

Focus View

Open the exact slice you want to share.

`?view=` becomes a real product state, not a dead query string.

Overview share link /daorg/proposals

Active Ballots

Signaling proposals

Open raw category

Signaling

Ratify the DAOrg governance MVP

Signaling

This proposal ratifies the first live governance surface on daorg.odei.ai: holder wallet auth, proposal lifecycle, weighted votes, and visible execution state.

Question: Should DAOrg use wallet-authenticated weighted signaling as the interim governance layer for product, rewards, and execution receipts?
Voting Window: Apr 25, 2026, 2:27 PM
Turnout: 1 wallets

For40112749.319515176

Against0

Abstain0

Governance Loop

Holder signaling is live

The motion is inside the wallet-gated vote window and moving toward a formal verdict.

1/4 loop stages complete

01
Shape
Draft and discussion

Ready
02
Signal
Holder voting window

Voting live
03
Decide
Approval or rejection

Pending
04
Execute
Receipt and proof

Pending

Decision Engine

Quorum pending

1/3 holder wallets have voted. 2 more wallets are required before this motion can legitimately pass.

Quorum: 1/3 wallets
Window: Open
Support: 100% For

Signal Clock

Closes 2 days left

Signal closes 2 days left. 2 more wallets must vote before this motion can legitimately pass.

Closes: Apr 25, 2026, 2:27 PM
Quorum: 1/3 wallets
State: 2 more wallets needed for quorum

Conclusion Preview

Conclusion Preview

1/3 holder wallets have voted. 2 more wallets are required before this motion can legitimately pass.

Verdict: Pending close
Publish: Conclude after close

Receipt pending

The default receipt will resolve only after the vote window closes.

Proof: Proof URL is not part of the conclusion step.
Timeline: Decision Timeline will append the final verdict once signaling closes.

Execution Path

What passes if holders approve

Keep the governance lobby live, collect holder signaling on this motion, and use the result as the public baseline while Builds, Rewards, and execution receipts move onto the same contract.

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: Voting 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 Vote Ledger

1 public holder receipt recorded on this motion.

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

For 0xEFA4...24F5 · 40112749.319515176 voting power

Pipeline

Drafts and discussion

Architecture context

Execution State

Approved, executed, rejected

Reward lane

Runtime Proof

Live authority is visible before the first verdict

Live runtime

No holder verdicts are archived yet, but the runtime contract already proves that DAOrg is live and wallet auth is open.

Public control plane

Live governance runtime is public

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

Runtime status JSON · Mode live · Source env Open runtime proof

No holder verdicts are archived yet. Published proposal receipts will appear here after the first completed governance motion.

Create Proposal

Open the next DAOrg question

Every field becomes part of the motion contract. Holders see exactly what they are approving — and exactly what shipped.

Agent Builds

Step 1

Wallet-gated governance

Connect the holder wallet first. Proposal creation and weighted voting inherit the same verified identity.

Current session

No wallet is verified in this browser yet.

Next unlock

Verify the holder wallet, then come straight back to Proposal Studio.

Open ODEI App profile Wallet Setup

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

Starter templates

Browse the starter contracts now. Publishing stays locked until the holder boundary and operator baseline are live.

Ratify Surface Confirm a governance or product baseline. Ship Product Change Approve a concrete build path and shipped artifact. Reward Operator Work Move contribution into a visible reward decision. Governance Policy Set a durable rule for how DAOrg should operate.

Template Route

Share the starter contract path.

Copy a deep link that opens Proposal Studio in the exact template state you want others to start from.

/daorg/proposals?view=create#daorg-create-proposal

Title Decision Question Summary Execution Path Initial Status Voting Window

Signaling readiness

Discussion-ready. Signaling gate activates only when you choose signaling.

Draft and discussion can stay flexible. The quality gate only activates when the motion moves into signaling.

4/4 checks ready

Title is specific enough0/24 characters
Question reads like a real holder decision0/32 characters
Summary explains why the motion exists0/120 characters
Execution path defines shipped proof0/180 characters

Local draft

No local draft yet.

This browser will keep the motion contract while you shape it, then restore it after refresh on this device.

Proposal Studio

Publish motions that can actually survive governance and ship.

Good proposals are specific, executable, and honest about what the org is really deciding. This lane should read like a contract, not a brainstorm.

State one decision

The title and question should make it obvious what a holder is voting for or against.

Define the execution path

Describe the deliverable, the receipt, and what artifact proves the work actually landed.

Choose the right opening state

Use draft for shaping, discussion for live debate, and signaling only when weighted voting should start now.

Live Motion Preview

Untitled motion

The proposal preview updates as the operator shapes the contract.

Question: Define the exact holder decision.
Status: Discussion
Voting Window: Not live yet
Execution: Describe the shipped result and proof URL.