Axynom
  • Introduction
    • What is Axynom?
    • Vision & Mission
  • Why Now
  • Founder's Note
  • The Problem
    • Centralized growth traps
  • Token reward inflation and failure
  • Lack of contributor alignment
  • Gatekeeping in Web3
  • Axynom Solution Overview
    • Proof of Growth (PoG)
    • Contributor as a Stakeholder
    • Transparent Rewards and Governance
  • Modular Ecosystem Architecture
  • PoG: Proof of Growth System
    • What is PoG
    • How Contributions Work
    • Voting and Governance Flow
  • GP: Growth Points
  • Role of Admins, Moderators, and Community
  • Examples of Valid Contributions
  • Axynom Token (AXY)
    • Token Utility
    • Tokenomics
  • Transfer Tax Logic
  • Governance Eligibility
  • Vesting and Distribution
  • Staking Mechanics
    • Lock Periods and APY
    • Early Exit Penalties
    • Sustainability Model
  • Treasury and Ecosystem Pools
    • Overview of Pools
    • Role of the Treasury
    • POL Strategy (Protocol-Owned Liquidity)
  • CaaS (Contributions-as-a-Service)
    • What is CaaS
    • Exporting the PoG System
    • Integration Possibilities
    • Revenue Model for Axynom
  • Governance & Voting
    • Governance Phases
    • Voting Power (AXY + GP)
    • Quorum & Approval Logic
    • No ‘Adjust GP’ Rule
  • Gas Economics
    • Why Arbitrum One
    • Axynom L3 Chain with AXY as Gas
  • Product Roadmap
    • Phase 1: MVP Launch (Staking, PoG, Treasury)
    • Phase 2: CaaS, L3 Chain, Scaled Contributor Base
    • Key Milestones
    • TGE Timeline (After Product-Market Fit)
  • Security & Audits
    • Upgradability Practices
    • Modular Contract Architecture
    • Audit Strategy Post-TGE
    • Role of Community Peer Review
  • KPI Forecast & Growth Goals
    • Contributors, GP Points, Stakers, TVL
    • Expected PoG Submissions
    • Treasury Size & Rewards Flow
    • Marketing & KOL Activation Plans
  • Conclusion
    • Axynom Is Not a Product. It’s a Protocol.
    • Call to Builders, Shillers, Designers, Thinkers
    • How to Get Involved
Powered by GitBook
On this page
  1. Governance & Voting

No ‘Adjust GP’ Rule

In Axynom’s governance model, contributors submit work along with a requested GP value. Voters can then approve or reject the submission, but they cannot modify the requested reward amount.

There is no “adjust GP” option in any voting phase.

This rule simplifies the governance process, protects contributor expectations, and prevents manipulation or negotiation during voting.


Why Adjustment is Not Allowed

Allowing voters to alter reward amounts would introduce complexity, inconsistency, and abuse risks:

  • Subjectivity: Voters may disagree not on the quality of work, but on what it’s “worth,” creating unpredictable outcomes.

  • Vote Fracturing: Contributions might receive partial support at multiple reward levels but fail to pass due to vote fragmentation.

  • Favoritism Risk: Adjusted GP values could reflect personal bias or influence rather than protocol impact.

  • Negotiation Loops: Contributors might be forced into resubmission cycles or lobbying just to secure fair rewards.

Axynom avoids all of this by enforcing a binary vote:

  • Approve - The contribution is valid, and the requested GP is fair.

  • Not Approved - The contribution is invalid, incomplete, low quality, or the reward request is excessive.

This gives contributors a clear incentive to be reasonable, and gives voters a clear decision to make.

PreviousQuorum & Approval LogicNextWhy Arbitrum One

Last updated 1 month ago