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
  • Why Axynom Uses Upgradable Contracts
  • Upgrade Controls
  • What Is and Isn’t Upgradeable
  • Known Risks and Limitations
  1. Security & Audits

Upgradability Practices

Axynom uses upgradeable smart contracts. This provides flexibility and resilience as the protocol evolves.

Upgradability is essential in early stages of any system that intends to adapt to real usage, integrate external services, or improve reward mechanics based on live contributor behavior.

What matters is not whether the contracts are upgradeable, but how upgradeability is controlled, tracked, and eventually transitioned into community oversight.


Why Axynom Uses Upgradable Contracts

  • Staking reward logic may require adjustments based on APY caps, penalty distribution, or pool refill mechanics

  • PoG systems evolve as new contribution types and campaign models are introduced

  • Treasury strategies change as CaaS revenue grows or L3 deployment matures

  • Security patches and emerging best practices must be implementable without migration delays or user loss

Axynom does not view its contracts as immutable infrastructure from day one. They are modular, secured, and built to evolve, with controls in place.


Upgrade Controls

Upgrades are only possible through structured control mechanisms:

  • Transparent ownership: Every upgradeable contract is owned by a controlled admin or multisig address

  • Limited scope: Most logic upgrades are isolated to libraries or internal modules, not full redeployments

  • Public audit logs: Every upgrade is tracked on-chain with published changelogs and updated documentation

  • DAO transition plan: Upgrade permissions will be transferred to DAO-controlled multisig once participation metrics reach required thresholds

Until then, all upgrades are published in advance, signed off by multiple operators, and reviewed with detailed reasoning.

There are no hidden upgrade paths or proxy redirections outside the core upgrade framework.


What Is and Isn’t Upgradeable

Component
Upgradeable
Notes

AxynomToken

Yes

Upgradeable via proxy; core logic secured; tax routing is modular

Staking Contract

Yes

Proxy-controlled; rewards, penalties, and APYs can evolve

PoG & Contribution Logic

Yes

Modular via libraries; registry, logic, and reward system are split

Treasury Pools

Yes

Configurable distributions, refill rules, investment tracking

Rewards Pool

Yes

Refill and payout logic upgradeable; balance and accounting secured

User Data / Wallets

No

Stake balances, GP points, contribution logs are preserved across upgrades

User assets and contribution records are never destroyed or migrated unsafely. Storage layout compatibility is rigorously maintained across all contract changes.


Known Risks and Limitations

  • Upgrade authority is a centralization risk - Even with multisig, the protocol is not trustless during early stages.

  • Errors in upgrade logic can introduce new vulnerabilities despite best intentions.

  • DAO transition depends on participation, not just time. Delays may occur if quorum is not met.

  • External dependencies (e.g., Orbit, Arbitrum sequencer) create indirect attack surfaces beyond Axynom’s control

These risks are acknowledged and mitigated.

The goal is to transition toward decentralized control without sacrificing responsiveness during early protocol growth.


Axynom is not immutable from day one. It is upgradeable by design, with visible permissions, structured governance, and honest reporting.

Security is earned through audits, transparency, and public accountability at every upgrade step.

PreviousTGE Timeline (After Product-Market Fit)NextModular Contract Architecture

Last updated 1 month ago