ZimX Finance

We express our gratitude to the ZimX Finance team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

ZimX Finance is digital payments infrastructure for the UK-Zimbabwe remittance corridor.

The system users should acknowledge all the risks summed up in the risks section of the report

{Finding_Table?columns=title,severity,status&setting.filter.type=Vulnerability}

Documentation quality

• Functional requirements are detailed.

• • Project overview is detailed.

  • All roles in the system are described.

  • Use cases are described.

• Technical description is robust.

• • Run instructions are provided.

  • The NatSpec documentation is sufficient.

Code quality

• The code leverages OpenZeppelin contracts and follows established patterns.

• The development environment is configured.

Test coverage

Code coverage of the project is 92.59% (branch coverage).

• Deployment and basic user interactions are covered.

• Interactions by several users are not covered thoroughly.

• Negative test cases are covered.

The ZIMXToken is an ERC-20 utility token deployed with a fixed total supply. The contract inherits from OpenZeppelin's ERC20, ERC20Burnable, Pausable, and ERC20Permit, providing standard token functionality alongside gasless approval via EIP-2612 signatures and the ability for any token holder to burn their own tokens.

The ZIMXToken token contract  has the following attributes:

• Name: ZIMX Token

• Symbol: ZIMX

• Decimals: 6

• Total supply: 1 000 000 000 tokens.

The contract implements a multi-role governance model with three privileged addresses — governance, timelock, and guardian — each with a distinct scope of authority. At deployment, the entire supply is minted to a designated treasury wallet, and subsequent distributions are performed through a purpose-built distributeFromTreasury() function that emits telemetry events for on-chain allocation tracking. The treasury address can be updated until it is permanently sealed via sealTreasury(), after which it becomes immutable.

A unique feature is the On-Chain Promises system: the timelock can record human-readable commitments on-chain with Pending, Kept, or Broken statuses, intended as a transparency mechanism for the community. The contract also includes a pause mechanism that halts all token transfers (including minting and burning) and a recoverERC20() function to rescue tokens accidentally sent to the contract address.

Per the project documentation the timelock address is intended to be an OpenZeppelin TimelockController with a meaningful minimum delay, and governance is intended to be a Gnosis Safe multisig. Under this architecture, governance proposes operations to the TimelockController, which schedules them and enforces the delay before execution.

Governance transfer follows a two-step pattern: a transfer is initiated (setting a pendingGovernance), and the new address must call acceptGovernance() to complete the handover. This mitigates the risk of transferring control to an incorrect address.

Privileged roles

• governance: Controls pause/unpause of all token transfers. Intended to be a multisig. Receives rescued ERC-20 tokens.

• timelock: Controls governance transfers, treasury updates, treasury sealing, treasury distributions, ERC-20 recovery, on-chain promise management, and direct setter functions for all three privileged addresses

• guardian: A narrowly scoped emergency role that can only call guardianUnpause() to resume token transfers. Intended as a safety valve if governance is unavailable during a pause. Unset at deployment, zero address by default.

• pendingGovernance: A transient role representing the address nominated to become the new governance. Must call acceptGovernance() to finalize the transfer.

The scope of the project includes the following smart contracts from the provided repository:

Assets in Scope