Appearance

Plugin Requests ​

Canonical

Purpose ​

Custom governance plugins are a major DAO service request type. A DAO may need a specific voting model, eligibility rule, execution module, reporting extension, federation registry feature, or local governance workflow.

Business receives the request, ACS analyzes it, Governance validates it, technical teams scope it, Security reviews it where needed, and only then can implementation or activation proceed.

Scope ​

This page covers plugin requests that originate through Business. Governance-level plugin policy is documented separately in Governance Plugin Requests.

Plugin Types ​

  • Voting plugins: quadratic voting, reputation voting, token-weighted variants, delegated voting extensions, or DAO-specific voting rules.
  • Eligibility plugins: token thresholds, membership status, credentials, certificates, or DAO roles.
  • Execution plugins: treasury execution, contract call execution, timelock execution, or multisig bridges.
  • Reporting plugins: execution receipts, governance metrics, or treasury snapshots.
  • Federation plugins: DAO status registry, product access checks, or constitutional alignment records.
  • Local workflow plugins: DAO-specific proposal flows, board reviews, or community workflows.

Required Intake Fields ​

Plugin requests should capture requesting DAO, requester authority, plugin description, plugin type, governance problem, local/shared/global scope, affected DAO or DAOs, voting or execution logic, eligibility rules, product access impact, treasury impact, security impact, chain or network, governance framework, integration requirements, desired timeline, review expectations, rollback or disable requirements, and documentation needs.

Flow ​

  1. DAO or internal team submits plugin need through Business.
  2. Business validates DAO context, authority, and basic requirements.
  3. ACS classifies type, scope, risk, and missing information.
  4. Business checks whether the plugin affects official Axodus flows.
  5. Constitutional alignment review verifies that the plugin does not bypass guardrails.
  6. Governance routes the request to the appropriate approval path.
  7. Technical scoping defines contract, frontend, backend, indexer, registry, or documentation requirements.
  8. Security review plan defines threat model, tests, and audit needs where applicable.
  9. Implementation authorization approves build scope or rejects the request.
  10. Development, testing, validation, activation, registry update, documentation update, and execution receipt occur under approved scope.

Scope Types ​

  • Local: valid only for the requesting DAO.
  • Shared: may be reused by multiple DAOs.
  • Global: affects Axodus core governance.
  • Experimental: limited pilot or test.
  • Deprecated: no longer recommended.

A local need must not become a global plugin without governance review.

Review Criteria ​

Review should consider functional clarity, constitutional alignment, security model, governance authority, operational maintainability, monitoring, rollback path, and registry status.

Risk Flags ​

Risk flags include voting power manipulation, treasury execution risk, permission overreach, unclear scope, governance capture, audit gaps, registry gaps, and missing execution receipts.

Business Boundaries ​

Business can receive plugin requests, structure scope, coordinate review, prepare Coder tasks, and communicate status. Business cannot approve high-risk plugins alone, bypass governance, bypass security review, declare a plugin official without authority, or deploy a plugin without approved scope.

Released as living documentation for the Axodus ecosystem.

© Axodus. Documentation under active reconstruction.