The factory does not enforce a single voting model like strict 1-token-1-vote. Voting logic is modular and configurable per DAO.
Out of the box, DAOs can use token-weighted voting, but the governance module is designed to support pluggable voting strategies, including time-weighted or lock-based voting. A DAO can require tokens to be time-locked to gain voting power, apply multipliers based on lock duration, or combine balance and lock parameters when calculating vote weight. These rules live in the voting contract or plugin and can be adopted at creation or added later via governance.
For treasury control, the factory supports multi-sig–style authorization and granular permissions through its permission system. Different roles can be defined for proposing, voting, executing, or managing specific treasury sub-accounts, enabling institutional-grade separation of duties without collapsing everything into a single voting flow.
So the system is not limited to 1-token-1-vote. Tiered voting power and role-based treasury control are supported by design, with the exact model chosen and enforced at the DAO level.
This proposal is focused on the on-chain smart contract infrastructure and does not mandate a built-in UI as part of the core protocol.
That said, the architecture is explicitly designed to be UI-friendly. The DAO Registry, standardized factory interfaces, and predictable governance modules are intended to make it straightforward for wallets, explorers, or third-party dashboards to build a unified frontend for DAO creation and management.
A reference UI or dashboard can be developed separately as an ecosystem tool, but it is not a protocol requirement. This separation ensures the DAO Factory remains a neutral, composable infrastructure layer while allowing multiple UIs to coexist and evolve independently.
Yes. While the DAO Factory itself does not hard-enforce treasury guardrails, it ships with recommended safe defaults intended to reduce the risk of malicious or accidental fund movements, especially for first-time deployers.
New DAOs can be initialized with conservative presets such as execution timelocks on treasury actions, minimum quorum and approval thresholds, and separation between proposal approval and execution. These settings are configurable, but they are applied by default unless the creator explicitly opts out.
The key point is that safety mechanisms are opt-out rather than opt-in. Experienced teams can relax or remove them through governance, but new DAOs start with protective constraints that make sudden or unilateral treasury drains difficult without broad and visible consensus.
The DID and KYC layer is optional and non-intrusive by default. Small or purely community-driven DAOs are not required to enable any identity or KYC checks, and in that configuration there is no additional friction compared to a standard token-based DAO.
Compliance checks are only enforced if a DAO explicitly opts into them, for example to meet regulatory or institutional requirements. Even then, the checks are performed as simple eligibility validations before participation, not as ongoing on-chain overhead. If a DAO does not enable compliance gating, the DID layer is effectively bypassed and has no impact on UX or performance.
So lightweight community DAOs can remain fully permissionless, while more regulated DAOs can selectively enable identity constraints when needed, without imposing that cost on the rest of the ecosystem.
The hybrid DAO option is designed to be configuration-driven rather than custom-built, so non-technical teams are not expected to wire EVM and CosmWasm components manually.
From the user perspective, setting up a hybrid DAO is handled at the factory level by selecting a predefined DAO type and parameters through a UI or deployment flow. The DAOFactory is responsible for instantiating the correct combination of governance and treasury modules across VMs and registering their relationships on-chain. No cross-VM contract development is required from the DAO creator.
The added complexity exists at the infrastructure layer, not the user layer. Non-technical teams can use hybrid DAOs through templates and defaults, while more advanced teams retain the ability to customize or extend the setup if needed.
Plugin upgrades are explicit and governance-controlled, not automatic.
Each plugin is an independent contract with its own lifecycle. If a DAO depends on third-party modules, upgrading a plugin requires an on-chain governance action that either replaces the plugin’s address, updates its permissions, or installs a new version alongside the old one. Nothing is implicitly upgraded in the background.
This design avoids hidden risk from upstream changes. DAOs can pin a specific plugin version, review upgrades when they are ready, and migrate gradually if needed. If a plugin becomes unmaintained or compromised, governance can revoke its permissions without affecting the core DAO contracts.
So long-term dependency management is handled through explicit proposals and permission changes, giving DAOs full control over when and how third-party modules evolve.