DataGram Governance

The DataGram governance platform enables decentralized decision-making within the DataGram ecosystem, specifically for grant assignment through the participation of Full Core operators and other $DGRAM token holders. It fosters community involvement and shared ownership of decisions, promoting transparency while reducing centralized control. This document outlines the platform’s structure, voting mechanisms, requirements, and technical features.

The governance model described for the DataGram Full Cores primarily applies to the DataGram Grant Pool. As the ecosystem grows, a Grant Pool will be established from a percentage of the Ecosystem fund, aimed at fostering innovation and supporting projects that contribute to the growth of the DataGram ecosystem. The final size and composition of this pool is still to be determined. Key Features:

  • Decentralized governance through Full Cores and $DGRAM token holders.

  • Proposal submission and voting framework.

  • Transparent participation requirements.

Note: DataGram, as an organization, and its members or executives, do not have unilateral access to the Grant Pool nor the ability to circumvent the governance platform. While the DataGram team may propose votes for funding from the Grant Pool, it must meet the same burn requirements and abide by the same voting rules as all participants.

  1. Full Core Structure Full Core operators are granted voting rights proportional to their participation in the network. Each Full Core has one vote in governance decisions, ensuring a fair and egalitarian system for proposal submissions and decisions.

  2. Operational Requirement: Eligibility to Vote Full Cores must be operational and actively contributing to the DCS to participate in governance voting. This ensures that only functional Full Cores influencing network operations have voting power.

  3. Voting Requirements In order for a vote to be called, several things can be done:

    • Total Full Cores Required to Call a Vote: 250 Full Cores must support a proposal to initiate the voting process across the network. Each supporting Full Core must burn $50 worth of $DGRAM tokens to demonstrate genuine interest in advancing the proposal.

    • Total Full Cores Required to Pass a Vote: A majority is required to pass a vote, balancing practicality with community representation.

    • Absolute Majority: At least 51% of voting Full Cores must vote in favor, with at least 25% of all active Full Cores participating in the vote. This equates to a minimum quorum of 2,500 Full Cores (assuming 10,000 active Full Cores). The number of active Full Cores is calculated based on the 30-day moving average of those that have been operational within the network. Quorum requirements can be adjusted over time as the network grows, ensuring governance remains practical and responsive.

  4. Proposal Lifecycle

    Proposal Submission by Full Core Operators:

    • Eligibility: Any Full Core operator can submit a proposal.

    • Burn Requirement: To submit a proposal, a Full Core operator must burn $5,000 worth of $DGRAM tokens. This burn mechanism helps deter spam, ensures proposers are committed, and reduces token supply, benefiting the overall ecosystem.

    • Support Requirement: The proposal must gain backing from 250 Full Cores to move to the voting stage. Each supporting Full Core must burn $50 worth of $DGRAM to demonstrate interest.

    Proposal Submission by Token Holders Without Full Cores:

    • Eligibility: Any $DGRAM token holder can submit a proposal, even if they do not operate a Full Core.

    • Burn Requirement: To submit a proposal, the token holder must burn $20,000 worth of $DGRAM tokens. This ensures non-Core participants are equally committed and discourages low-quality proposals.

    • Support Requirement: Proposals submitted by non-Core token holders must also gain support from 250 Full Cores, each burning $50 worth of $DGRAM, to advance to a vote.

  5. Voting Process

    • Operational Verification: Full Cores must be verified as operational and contributing to the DataGram workload to cast a vote.

    • Voting Period: Proposals will remain open for voting over a set period (e.g., 7 days).

    • Vote Tracking: Full Cores cast votes via a governance dApp. Votes are publicly tracked for transparency.

    • Majority and Quorum: A proposal passes if the required percentage of Full Cores vote in favor, meeting both quorum and majority rules.

  6. Historical Uptime Requirement A Full Core must have been online for at least 80% of the voting period to cast a vote. This prevents actors from purchasing votes solely to influence outcomes.

  7. Technical Features: Voting Interface

    • Governance Dashboard: A web-based application where Full Core operators can view proposals, cast votes, and track voting results.

    • Full Core Authentication and Verification: Secure authentication is required to verify Full Core operators, with real-time checks to ensure Full Cores are operational before allowing voting or proposal submissions.

    • Token Holder Proposal Submission: Token holders can submit proposals by burning $20,000 worth of $DGRAM, with the burn transaction automatically tracked. Proposals still need support from 250 Full Cores to move to a vote.

    • Support Burn Mechanism: Full Cores must burn $50 worth of $DGRAM to support a proposal, ensuring it’s certified for voting.

    • Transparency: All votes are recorded on-chain, ensuring transparency and immutability.

  8. Proposal Types

    • Funding Proposals: Cover routine decisions such as network policy changes and minor feature additions. Initially, funding is capped at $100k per proposal, subject to change based on network demand and future governance decisions.

    • Critical Proposals: Concern major network changes, such as protocol upgrades or governance structure amendments, and require higher thresholds to pass.

  9. Voting Mechanisms

    • One Full Core, One Vote: Each Full Core has equal voting power, provided it is operational.

    • Delegated Voting: Full Core operators may delegate their vote to another address if they are unavailable, ensuring representation. However, burn and uptime requirements for the Full Core still apply.

  10. Security Considerations

    • Sybil Attack Mitigation: Governance includes mechanisms to verify Full Core ownership as NFTs and check operational status to prevent manipulation.

    • On-Chain Voting: The voting process and proposal records are stored on-chain, providing immutability and preventing tampering.

    • Burn Mechanism: Requiring $5,000 (for Full Core operators) or $20,000 (for non-Core token holders) worth of $DGRAM to submit proposals, and $50 burn per supporting Full Core, helps ensure that proposals are serious and prevents spam.

  11. Governance Evolution

    • Initial Setup Period: Governance rules and structures may evolve as the ecosystem grows.

    • Amendments to Governance Rules: The governance model itself can be changed through proposals. Voting thresholds, quorum requirements, burn amounts, and submission limits can all be modified by community vote, ensuring the system adapts over time.

The DataGram governance platform is designed to be decentralized and robust, encouraging active participation by Full Core operators while ensuring decisions are made by those contributing to the network. The burn requirements—including $5,000 for proposal submission by Full Core operators, $20,000 for non-Core token holders, and $50 per supporting Full Core—filter out uncommitted actors and enhance the quality of proposals. Voting requirements ensure that decisions reflect broad community support, protecting the network as it grows and matures.

Last updated