DAO Motions

Each autonomous agent within the agentOS protocol is chartered as a Decentralized Autonomous Organization (DAO). This architectural paradigm dictates that all operational directives and strategic actions are subject to the explicit consensus of the agent's stakeholders.

The DAO does not merely influence the agent. It constitutes its core decision-making apparatus, transforming it from a static entity into a collective governed by verifiable, on-chain voting. This is similar to, but not the same as forming a community.

Proposals and Motions

The governance process follows a structured, transparent lifecycle, beginning with a formal proposal and culminating in a token-weighted vote.

An agent's autonomy is an expression of its stakeholders' collective will. All non-deterministic actions must be ratified through the DAO framework before execution.

The governance process is initiated when a holder proposes a motion. A motion is a formal, on-chain proposal for the agent to undertake a discrete, executable action from its predefined capabilities, subject to the actions criterias. To ensure authenticity, the proposing stakeholder must sign the proposal payload with their Solana wallet.

A stakeholder's influence within the DAO is quantified by their pro-rata share of the agent's native token supply.

This token-weighted model aligns governance rights with economic interest which creates investment dynamics that directly tie into a social, community-favouring system. A few examples below.

• If you want to have more power, you should buy more AGENT tokens. You can receive AGENT tokens and swap from one agent to another.

• A few really active community leads that don't have the time to wait for further voting support? The rest of the DAO can appoint them as temporary dictators for a specified term, making them super-voters.

• Someone whos votes and motions you don't appreciate? Have a chat with him and see if you can come to an agreement.

• If the agent is without any direction, you can attempt a CTO (Community Take Over) in a clean manner by having you and your friends purchase a portion of the supply that can pass votes.

An individual's voting power ($Pv​$) is calculated as:

where

• $Su​$ is the quantity of the agent's tokens held by the user.

• $St​$ is the total supply of the agent's tokens.

Once a proposal becomes a motion, other holders participate by casting a vote, which commits the entirety of their token-weighted voting power to either an affirmative (FOR) or negative (AGAINST) stance. The protocol aggregates these commitments in real-time, maintaining a transparent ledger of support for each active motion.

Ineligible voters are shown with a stikethrough red color. These include the aOS token mint and other powerful wallets that are within the ecosystem itself. These addresses cannot vote and their vote is not counted to ensure fairness and transparency across all team operations.

Achieving Consensus

A motion's progression from a proposal to an executed action is governed by deterministic rules of consensus and finality encoded within the agentOS protocol.

A motion is algorithmically ratified once it satisfies the majority pass condition. The condition is met when the affirmative vote weight exceeds the defined pass threshold ($P$) relative to the total vote weight.

Let

• $Vf​$ be the total token weight of votes "FOR" a motion.

• $Va​$ be the total token weight of votes "AGAINST" a motion.

• $P$ be the pass threshold, where $P=0.5$.

The motion is considered passed if the following inequality holds true

Motion State Machine

Each motion transitions through a deterministic state machine, ensuring predictable behavior and transparency throughout its lifecycle. Upon satisfying the pass condition, the protocol enters a brief finalization period before programmatically executing the approved directive.

The primary states are:

• ACTIVE: The motion is open for voting by stakeholders.

• PASSED: The pass condition has been met; the motion is queued for execution.

• REJECTED: The motion failed to achieve the required consensus.

• EXECUTED: The on-chain action was successfully completed.

• FAILED: The on-chain execution was unsuccessful due to a runtime error.

Motion Log

All motions are executed real-time with graphical representations occuring in the simulation, and you can't always be there to vote or keep a record of the votes yourself. Navigating to JOURNAL, you'll find two types of historical data records your agents, of which MOTION LOG is the one that stores all past and present proposal data.

Visit here often to understand what kind of motions the DAO has proposed, pushed through or rejected.

Forecasting and Simulations

To facilitate informed and strategic decision-making, the governance interface is augmented with real-time economic modeling tools. This transforms the DAO from a simple polling mechanism into a sophisticated, data-driven strategic body.

These forecast models and simulations are only as good as the agent's ability to execute the action. In other words, if the agent has a very low chance of success due to lack of relevant skills, there is almost no chance he will predict the consequences correctly.

The ways forecasting is currently being implemented are as follows:

• Action Previews: The protocol provides stakeholders with deterministic previews of potential actions. These previews include data on probabilistic success rates and temporal costs, which are calculated as functions of the agent's dynamic attributes and skill levels.

• Ex-Ante Impact Simulation: For directives with quantifiable economic externalities (e.g., an action requiring an expenditure of aOS), the protocol offers an ex-ante impact simulation. This tool makes available the necessary data to deliberate on the second-order economic effects of its decisions, aligning governance with value preservation and creation.