Skip to main content
All updates
Governance3 min read

Governance Framework: Architecture and Rollout

Adina Labs is publishing the foundational architecture of its on-chain governance framework. The model is designed to progressively transfer decision-making authority to ADINA token holders, beginning with advisory forums and culminating in fully autonomous, on-chain governance of treasury and protocol parameters.

Decentralisation is not a fixed state. It is a process. Governance frameworks that attempt to transfer full on-chain autonomy before a community has developed the knowledge, tooling, and coordination mechanisms to exercise it responsibly tend to produce either apathy or capture. Adina Labs is taking a phased approach that begins with structured deliberation and progressively expands the scope of binding community authority as the ecosystem matures.

This document outlines the architecture of that framework.

Design Principles

Our governance model is built on four principles that are held in deliberate tension with one another:

  • Legitimacy: Decisions must be traceable to a process that token holders recognise as fair and transparent. Every binding vote is recorded on-chain and is permanently auditable.
  • Competence: Not all decisions are equally accessible to general participation. Technical parameter changes require specialist knowledge. Our framework creates differentiated tracks for decisions of different complexity and consequence.
  • Protection: Minority token holders must have meaningful protection against proposals that would benefit a majority at their expense. Quorum requirements, time-lock delays, and veto mechanisms are built into the architecture for this purpose.
  • Adaptability: A governance framework that cannot evolve cannot serve a living ecosystem. The parameters of the governance system itself are subject to governance, within bounds designed to prevent destabilisation.

The ADINA Governance Token

Governance rights accrue to holders of ADINA, the native utility token of the Adina Labs ecosystem. ADINA holders may exercise governance rights directly or delegate them to representatives whose technical expertise or community standing they trust. Delegation is fully reversible at any time and does not affect the holder's economic rights over their tokens.

Token-weighted voting is the base mechanism, with quadratic voting mechanisms under consideration for proposal categories where plutocratic outcomes would be particularly harmful. The appropriate voting mechanism for each proposal type will itself be subject to community deliberation during the forum phase.

Phased Rollout

The framework will be introduced in three phases, each contingent on demonstrated community readiness:

  • Phase I: Deliberation: Structured forum-based discussion, informal polling, and community education. No binding outcomes. This phase is designed to build the knowledge and coordination norms that make subsequent phases functional.
  • Phase II: Advisory Governance: On-chain votes for a defined category of non-critical proposals, including ecosystem grant allocations, partnership ratifications, and community programme approvals. Results are advisory pending team implementation, with a clearly defined escalation mechanism for disputes.
  • Phase III: Autonomous Governance: Full on-chain governance including protocol parameter changes and treasury management, executed automatically upon successful vote. This phase will be preceded by a formal governance audit and a security review of the smart contract infrastructure.

Safeguards

All binding votes in Phase II and III are subject to a mandatory time-lock between passage and execution. This window exists to allow token holders to exit positions or escalate concerns before a change takes effect. Certain categories of change, including modifications to the time-lock itself, changes to quorum thresholds, and emergency protocol pauses, require supermajority approval and extended deliberation periods.

A guardian multisig, initially controlled by the Adina Labs founding team and progressively decentralised, retains the ability to veto proposals that would introduce critical security vulnerabilities. This veto power is subject to automatic sunset as the community's security review capacity matures.