Anoma Q3 2025-Token & Token Distributor Audit Report Final v3

Security Audit Report

ANOMA Q3 2025: TOKEN & TOKEN DISTRIBUTOR

Authors: Last Revised Aleksandar Stojanovic, Carlos Ro- 2025/09/18 driguez Anoma Q3 2025 Token & Token Distributor

Contents Audit overview 2 The project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Scope of this report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Audit plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Audit Dashboard 3 Target Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Engagement Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Severity Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

System Overview 4 Architecture diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Token repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Token distributor repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Threat Model 9 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Protocol properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Integration properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Implementation properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Findings 19 Minimum locked supply requirement may be impossible to satisfy if more than 75% of total supply is burned 20 Upgrading to a previous version re-activates per-implementation locking, voting. . . states causing potential underflows and balances/governance inconsistencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Claim window can be as short as 1 second . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Miscellaneous code improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Appendix A: Review of change to restrict caller of transferAndLock 24

Appendix B: Vulnerability classification 25

Disclaimer 28

Audit overview The project In August 2025, Anoma engaged with Informal Systems to conduct a security audit of the XAN token system. It features an ERC-20 token supporting dual governance (voting through token locking and council) to decide on future underlying implementations of the contract. Tokens are deployed and distributed with a time-limited, Merkle-proof-based claim system for both unlocked and locked tokens.

Scope of this report The audit focused on evaluating the correctness and security properties of the smart contracts in the anoma/token ↗ and anoma/token-distributor ↗ repositories, focusing specially on guaranteeing that no undesired behaviour manifests in the ERC-20 (XAN token contract), foreign reserve (fee recipient from allocation claiming) and token distributor (token allocation claim system) contracts.

Audit plan The audit was conducted between August 18th, 2025 and August 27th, 2025 by the following personnel:

● Aleksandar Stojanovic ● Carlos Rodriguez

Conclusions We performed a manual review supported by property-based tests. Most safety and liveness properties hold. Notable exceptions are that upgrading to a prior implementation can re-activate per-implementation governance state, causing unlocked balance underflow and governance misalignment with current ERC-20 balances. ERC- 7201 storage isolation is sound with the caveat above. Configuration choices (fixed MIN_LOCKED_SUPPLY) can render minimum locked supply requirement unattainable if too much supply is burned after initial distribution period. In the kickoff, the team acknowledged that if a large fraction of voter’s body (especially 100%) votes for the current implementation, gathering enough votes for a new upgrade can be very hard or impossible, impacting upgradeability. The team acknowledges the governance risk their design introduces. The voter body is sovereign, and if it reaches quorum and minimum locked supply for a malicious implementation, it will be chosen as a next implementation (the council cannot override it).

Review of

Audit Dashboard Target Summary ● Type: Protocol and implementation ● Platform: Solidity smart contracts ● Artifacts:

– For token (at commit hash e4b0034 ↗): src/libs/Voting.sol src/libs/Parameters.sol src/libs/Locking.sol src/libs/Council.sol src/interfaces/IForeignReserveV1.sol src/interfaces/IXanV1.sol src/ForeignReserveV1.sol src/XanV1.sol – For token-distributor (at commit hash 2b4e2bf ↗): src/libs/Allocation.sol src/TokenDistributor.sol src/interfaces/ITokenDistributor.sol

Engagement Summary ● Dates: August 18th, 2025 → August 27th, 2025 ● Method: Manual code review, property-based testing

Severity Summary

Finding Severity Number

Critical 0 High 0 Medium 1 Low 0 Informational 3 Total 4

System Overview The XAN Token System consists of two interconnected contract repositories that together provide a comprehensive token distribution and governance platform:

● Token repository contains the core governance infrastructure with XanV1.sol serving as an advanced ERC-20 token featuring dual governance mechanisms, token locking for voting participation, and upgrade authorization. Alongside it, ForeignReserveV1.sol provides an arbitrary execution framework that can perform any contract operations as directed by the token’s governance system. ● Token distributor repository implements a factory pattern through TokenDistributor.sol, which deploys both

the XAN token and ForeignReserveV1 contracts during its construction. It then orchestrates a time-bounded, Merkle-tree based distribution system that allows users to claim token allocations using cryptographic proofs, with support for both immediately available and governance-locked tokens.

The system’s architecture enables initial token distribution followed by community-driven governance, with the flexibility to execute arbitrary operations through the ForeignReserveV1 contract as the protocol evolves.

Architecture diagram

Figure 1: Architecture diagram

Token repository The token repository serves as the governance backbone of the XAN system, housing two critical contracts that work in tandem to provide token management and execution capabilities. XanV1.sol represents a governance token that extends standard ERC-20 functionality. At its core, it implements a dual governance model where both token holders (the “voter body”) and a designated governance council can propose and execute contract upgrades. The token features a locking mechanism that is implementation- specific, meaning tokens locked for governance participation in one version of the contract remain locked until that implementation is upgraded. This design ensures that governance participants have long-term alignment with the protocol’s success. The voting system allows locked token holders to cast votes for proposed implementations, with vote weight corresponding to their locked token balance. The contract maintains a quorum requirement of a minimum percentage of locked tokens and minimum locked supply threshold. When these requirements are met, the voter body can schedule upgrades with built-in time delays that provide opportunity for review and potentially cancelling the upgrade. The governance council operates as a counterbalance to the voter body, with the ability to propose upgrades when the voter body hasn’t reached quorum. This creates a system of checks and balances that prevents either governance mechanism from acting unilaterally. The upgrade authorization logic ensures that only legitimately proposed and scheduled upgrades can be executed, with different authorization paths for voter body versus council-initiated upgrades. ForeignReserveV1.sol complements the governance token by providing an arbitrary execution framework. The ForeignReserveV1 contract serves multiple purposes within the system: it receives fees from the token distribution process, and provides a mechanism to distribute accrued fees to other contracts/EoAs.

Execution flow Governance participation

Token holders lock tokens for current implementation.
Locked token holders can vote on proposed implementations.
When quorum is reached, upgrades can be scheduled with time delays.
Council upgrade can be vetoed if a voter body implementation meets requirements.
After delay periods, authorized upgrades can be executed.

Token distributor repository The token-distributor repository implements a token distribution system centered around the TokenDistributor.sol contract, which deploys both the XanV1 and ForeignReserveV1 contracts during its own construction. During deployment, it initializes the XAN token with an initial supply minted to itself, and establishes the ForeignReserveV1 with the XAN token as its owner. This creates a clean ownership hierarchy where the governance council can schedule upgrades of the XAN token, which in turn controls the ForeignReserveV1. The distribution mechanism is built around Merkle tree verification. The system supports different allocation structures through the Allocation data structure, which includes not only the recipient address and token amounts but also fee requirements and the distinction between locked and unlocked tokens. This allows for distribution strategies where some recipients receive immediately available tokens while others receive tokens that are permanently locked for governance participation. Each allocation can specify a fee that must be paid during claiming, and these fees are automatically forwarded to the ForeignReserveV1 contract. The contract enforces configurable start and end times for the claiming period, ensuring that distribution occurs within a specific window. The system tracks claimed allocations using a bitmap approach, preventing double- claiming while minimizing storage costs.

Figure 2: Execution flow

The cleanup mechanism ensures that unclaimed tokens don’t remain indefinitely in the distribution contract. After the distribution period ends, anyone can trigger the burning of remaining tokens, ensuring that the total supply reflects only the tokens that were actually claimed. This prevents the accumulation of unclaimed tokens that could potentially be exploited or create uncertainty about the true circulating supply (which would distort the requirement of minimum locked supply for voter body upgrades). When allocations specify locked tokens, the distributor uses the XAN token’s transferAndLock function to both transfer and immediately lock the tokens in a single operation. This ensures that recipients of locked allocations are immediately eligible to participate in governance, creating a seamless transition from distribution to governance participation.

Execution flow System deployment:

Deploy TokenDistributor with Merkle root, time bounds, and governance council address.
TokenDistributor automatically deploys XanV1 proxy (mints initial supply to itself).
Governance council address becomes council of XanV1.
TokenDistributor automatically deploys ForeignReserveV1 proxy (owned by XAN token).
System is ready for time-bounded claiming period. Token claiming process:
Claimer generates Merkle proof for their allocation off-chain.
Claimer calls claim() with allocation data, proof, and required fee.
TokenDistributor verifies time bounds, claim status, and Merkle proof.
Fee is forwarded to ForeignReserveV1 if applicable.
Locked tokens are transferred and permanently locked via XanV1.transferAndLock().
Unlocked tokens are transferred directly to claimer.
Allocation is marked as claimed in bitmap. Post-distribution operations
After end time, anyone can call burnUnclaimedTokens().
All remaining tokens in TokenDistributor are burned.
System transitions to normal governance-controlled ERC20 operations.
ForeignReserveV1 continues to provide arbitrary execution capabilities.

Implementation overview The XAN token system utilizes OpenZeppelin contracts library as its foundation for security and standardization. The architecture embraces upgradeability throughout, with XanV1 and ForeignReserveV1 contracts implemented as a UUPS (Universal Upgradeable Proxy Standard) proxy to enable evolution over time. The token contract extends OpenZeppelin’s comprehensive ERC20 suite, incorporating permit functionality for gasless approvals and burnable capabilities for supply management, while the ForeignReserveV1 contract combines ownership controls with reentrancy protection to safely execute arbitrary operations. The distribution mechanism leverages cryptographic merkle proofs for verification and OpenZeppelin’s SafeERC20 patterns for secure token handling. Custom governance libraries manage the complex dual-governance model, token locking mechanisms, and voting systems, while the ERC-7201 storage pattern ensures upgrade safety by preventing storage collisions.

Figure 3: Execution flow

Threat Model Assumptions ● All inherited OpenZeppelin contracts are properly audited, maintain standard compliance, and have no critical security vulnerabilities.

Protocol properties Safety properties for token Property PS-1 (locked balance constraints): Locked balances never exceed total balances for any address

● Threat a: Manipulation of lock operations to exceed total balance Conclusion: The threat doesn’t hold. Lock operations can’t push a user’s locked balance above their total balance. Locking requires value <= unlockedBalanceOf(account), where unlocked = balance - locked. Any attempt to lock more reverts before incrementing locked amounts (code ref ↗). Transfers and burns only move unlocked tokens. Any attempt to move more than the unlocked portion reverts. (code ref ↗)

Property PS-2 (locked token transfer immutability): Locked tokens cannot be transferred, sold, or moved between addresses while they remain locked

● Threat a: Exploiting vulnerabilities in the _update() function or unlocked balance calculation to transfer locked tokens Conclusion: The threat doesn’t hold. _update() is overridden to require unlockedBalanceOf(from) >= value for any non-mint move (code ref ↗). Locked amounts are excluded from spendable balance. All transfer- /burn paths route through _update().

● Threat b: Manipulation of implementationSpecificData mapping to affect locked balance calculations Conclusion: The threat doesn’t hold. Locks are intentionally scoped per implementation and reset on up- grade by design (different slots under different namespace are used for implementation specific data). Exter- nal manipulation of the mapping is not possible and upgrades must pass authorization.

● Threat c: Exploiting edge cases in ERC-20 transfer logic to move locked tokens Conclusion: The threat doesn’t hold. All balance changes (transfer(), transferFrom(), _burn()) go through _- update() and thus the unlocked-balance guard. _mint() bypasses the guard but does not spend locked tokens. Custom transferAndLock() transfers then locks at the receiver.

Property PS-3 (quorum enforcement): A voter body upgrade may only be scheduled when quorum (50% + 1 of locked supply) is reached and minimum locked supply (25% of total) is met

● Threat a: Manipulation of vote counting to bypass quorum requirements (e.g., counting same votes multiple times) Conclusion: The threat doesn’t hold. A voter’s contribution to a given proposal’s tally is capped at their cur- rent locked balance. Repeated calls without increased locks revert, preventing double-count within the same proposal (code ref ↗).

● Threat b: Exploiting locked supply calculation errors to underreport total locked supply (and thus lowering requirements threshold) Conclusion: The threat doesn’t hold. Locked supply is tracked centrally per implementation and only increases via _lock(); the quorum threshold derives directly from this value ↗ and scheduling enforces both threshold and minimum locked supply.

Property PS-4 (vote monotonicity): Individual vote counts can only increase (never decrease) for any voter- implementation pair

● Threat a: Vote update logic is exploited to decrease votes Conclusion: The threat doesn’t hold. castVote() forces strictly increasing per-voter votes for a given imple- mentation by requiring newVotes > oldVotes and setting votes to lockedBalance, then only adding the positive delta to the total locked supply (code ref ↗). There is no path to reduce either the per-voter votes or total votes. lockedBalance never decreases (no unlock; transfers/burns can only move unlocked), so new votes cannot be less than prior votes. Attempts to recast without increased locked amount revert.

Property PS-5 (upgrade mutual exclusion): At most one upgrade can be scheduled at any time (either voter body or council, never both)

● Threat a: Race condition in upgrade scheduling logic causes concurrent upgrade Conclusion: The threat doesn’t hold. Voter’s body scheduling cancels any existing council schedule (code ref ↗). Council scheduling is forbidden when voter quorum is (or remains) reachable (code ref ↗) and upgrade authorization asserts that both cannot be scheduled simultaneously (code ref ↗).

● Threat b: State inconsistency between voter body and council upgrade tracking Conclusion: The threat doesn’t hold. Both subsystems use the same scheduling predicate (impl != 0 and endTime != 0), voter’s body scheduling clears any existing council schedule and upgrade authoriza- tion clears the corresponding schedule after success.

Property PS-6 (voter body upgrade cancellation authority): A voter body upgrade may only be cancelled when (a) the delay period has elapsed and (b) the scheduled upgrade no longer meets quorum requirements or is no longer the most voted

● Threat a: Cancelling legitimate voter body upgrades before delay period elapsed or while still meeting require- ments Conclusion: The threat doesn’t hold. Cancellation requires the delay to have ended, and it reverts if the scheduled implementation still meets quorum and remains the most-voted (code ref ↗).

● Threat b: Preventing cancellation of voter body upgrades that no longer meet requirements Conclusion: The threat doesn’t hold. Once the delay has elapsed, if the scheduled implementation ei- ther

Excerpt (19994 of 62958 characters). Read the whole page on informalsystems/audits ↗

← Back to Documentation