Modular Contract Architecture

Axynom’s smart contracts follow a modular architecture. Instead of packing all protocol logic into large monolithic contracts, Axynom separates functionality across core contracts and external libraries. Each library handles one clearly defined area of logic.

This improves security, testability, readability, and upgrade control.

It also makes it possible to patch or upgrade specific logic components, such as reward math, penalty flows, or treasury rules, without touching unrelated systems or increasing surface area unnecessarily.

---

Why Modular Architecture Matters

In a complex system like Axynom, protocol logic spans multiple domains:

• Contribution validation and GP assignment

• Staking lock periods, reward calculation, penalty enforcement

• Treasury management, pool routing, refill logic

• Transfer tax logic and routing between pools

Trying to implement all of this in one contract would:

• Increase complexity, raising audit difficulty and risk of overlooked bugs

• Make upgrades dangerous, as changes could impact unrelated logic or storage

• Limit reuse of code across systems like PoG and CaaS integrations

Modular design avoids all of that. Each contract or library has one job and does it with clean, isolated logic.

---

Core Architecture Layout

Component	Role and Scope
AxynomToken.sol	ERC20 logic, transfer tax, and routing to ecosystem pools
AxynomStaking.sol	Handles staking deposits, reward tracking, maturity, and penalty logic
PoG.sol	Manages GP redemption and reward flows for contributors
ContributionRegistry.sol	Tracks submitted contributions and their review statuses
PoGLogic.sol	Library for computing GP values, reward math, and thresholds
PenaltyLogic.sol	Library for calculating early exit penalties and reward forfeits
StakeLogic.sol	Library for APY assignment and lock tier enforcement
PoolInteractions.sol	Routing logic between pools (rewards, treasury, liquidity)
RewardsPool.sol	Stores and tracks balance available for payouts to stakers and contributors

Each of these is independently testable, auditable, and upgradeable (if proxied). Storage layout is protected at the contract level, while libraries remain stateless by design.

---

Benefits of the Architecture

• Security: Smaller code scopes make auditing more effective and upgrade impact easier to reason about

• Flexibility: You can upgrade PenaltyLogic.sol without modifying Staking.sol or RewardsPool.sol

• Scalability: New systems (e.g., off-chain voting, L3-specific staking logic) can be built as separate libraries

• Reusability: Same logic libraries can power partner integrations under CaaS, reducing duplication

Modularity also simplifies documentation and contributor onboarding. Developers can work on individual systems without understanding every part of the protocol.

---

Known Tradeoffs

• Deployment overhead: More contracts and libraries mean more deployment steps and tracking during upgrades

• External call complexity: Certain operations require internal delegate calls across multiple libraries, which may increase gas cost or error handling complexity

• Harder for non-technical users to follow: Reading a single contract no longer reveals the full logic. Documentation and interface abstraction are essential.

These are accepted costs in exchange for safety, long-term upgrade control, and clarity of purpose in every component.

---

Axynom’s modular architecture is not about overengineering. It’s about separating concerns, minimizing blast radius, and preparing the protocol for real scaling, both in usage and in team size.

It’s the architecture you build when you expect people to contribute, maintain, and rely on your protocol for years.