Skip to content

Make ParityToken Fully ERC20-Compatible and Safer for Integration #11

Description

@virajbhartiya

Description:

The current implementation of ParityToken is functionally valid but deviates from the ERC20 standard in several important ways that can hinder integration with wallets, block explorers, and other contracts expecting full ERC20 conformance.

Identified Issues:

  1. Missing ERC20 Interface Compliance

    • name, symbol, decimals, and totalSupply are constants or variables, not public view functions as per ERC20 interface expectations.
  2. No IERC20 Interface Declaration

    • The contract does not explicitly implement IERC20 or IERC20Metadata, reducing toolchain compatibility.
  3. Reentrancy Risk in transferWithDataAndCallback

    • Although balances are updated before the external call, using ReentrancyGuard would ensure safety against callback edge cases.
  4. Manual allowance bookkeeping

    • transferFrom directly modifies allowance without an internal _approve helper. Adding one would improve consistency and readability.

Suggested Fixes:

  • Refactor name, symbol, decimals, and totalSupply as public view functions.
  • Explicitly implement IERC20 and IERC20Metadata interfaces.
  • Add OpenZeppelin’s ReentrancyGuardUpgradeable and apply nonReentrant modifier to transferWithDataAndCallback.
  • Introduce internal _approve() and _mint() functions for maintainability.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions