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 Audits Happen Post-TGE
  • What Gets Audited
  • Who Pays and How It’s Tracked
  • Audit Partners
  • Community Review Before Audit
  1. Security & Audits

Audit Strategy Post-TGE

Axynom’s smart contracts will undergo external audits after the TGE, using part of the funds raised during the public sale.

This is a deliberate decision: the protocol is built and deployed before TGE, but full formal auditing is funded after capital is secured, not before.

This balances early access, product delivery, and financial responsibility without pretending unaudited systems are trustless or guaranteed secure.


Why Audits Happen Post-TGE

  • Pre-TGE capital is limited - Axynom does not raise from private investors or VC funds

  • The MVP is already functional - systems are tested, deployed, and operating with real data

  • Funds from TGE are dedicated - a defined portion of TGE proceeds is reserved for immediate audits of all live systems

Security is treated as a first priority once the community has funded it. No shortcuts. No excuses.


What Gets Audited

The audit scope includes all core systems active at the time of TGE:

  • AxynomToken.sol (ERC20 logic, tax routing)

  • AxynomStaking.sol and connected logic libraries

  • PoG.sol, PoGLogic.sol, and contribution flow libraries

  • ContributionRegistry.sol (tracking and admin controls)

  • RewardsPool.sol and Treasury interaction contracts

  • Proxy upgrade patterns and admin roles

Any pending or planned upgrades are reviewed separately before deployment.

CaaS-specific deployments for partners will be audited independently, once live use begins.


Who Pays and How It’s Tracked

  • Audits are paid directly from the Treasury Pool, using a dedicated budget funded by the TGE

  • Multiple auditors may be contracted for separate systems (staking, token, PoG, etc.)

  • Full audit reports are published publicly and permanently, with detailed responses and follow-ups for any critical findings

  • No audit is considered “complete” unless the final contract matches the reviewed version

Audit funding is a mandatory part of the TGE fund allocation plan. It is not subject to delay or reprioritization.


Audit Partners

Audit partners will be selected based on:

  • Proven experience with upgradeable, modular systems

  • Clear communication and documentation practices

  • Willingness to work transparently with the Axynom core team and contributor reviewers

  • Availability and turnaround time for time-sensitive systems

Auditors will be named publicly before contracts are sent for review. Any prior code review from contributors or external developers will be included in documentation and handoff materials.


Community Review Before Audit

Before formal audits begin, the deployed contracts will also undergo:

  • Public technical review from Axynom contributors with Solidity experience

  • Issue reporting and discussion on GitHub and internal forums

  • Walkthroughs and annotations published in the documentation for review by non-technical stakeholders

This ensures that the audit is not the first time the system is reviewed. It is the final confirmation, not the only check.


Audits do not guarantee perfection. But they do raise the floor of risk and give contributors, partners, and future voters a clear signal that the system they’re using has been independently verified.

Axynom will not scale without audits. And it will not fund audits until the product is real, working, and ready to be trusted.

PreviousModular Contract ArchitectureNextRole of Community Peer Review

Last updated 1 month ago