FamilyToken Manual Review Findings

FTN-01M: Overly Centralized Single Point of Failure

Description:

The FAM token implementation is a mintable token whose minter can be arbitrarily set by the token's owner. This acts as a centralized Single-Point-of-Failure (SPoF) whereby a compromised owner can set an arbitrary minter and mint an unlimited amount of tokens.

Example:

Copy
575/**
576     * @dev Transfers mintership of the contract to a new account (`newMinter`).
577     * Can only be called by the current owner.
578     */
579    function transferMintership(address newMinter) public virtual onlyOwner {
580        require(newMinter != address(0), "Mintable: new minter is the zero address");
581        _transferMintership(newMinter);
582    }
583
584    /**
585     * @dev Transfers mintership of the contract to a new account (`newMinter`).
586     * Internal function without access restriction.
587     */
588    function _transferMintership(address newMinter) internal virtual {
589        address oldMinter = _minter;
590        _minter = newMinter;
591        emit MintershipTransferred(oldMinter, newMinter);
592    }
593}
594
595contract FamilyToken is ERC20("Family", "FAM"), Ownable, Mintable {
596    function mint(address _to, uint256 _amount) external onlyMinter {
597        _mint(_to, _amount);
598    }
599    
600    function burn(address _from, uint256 _amount) external onlyMinter {
601        _burn(_from, _amount);
602    }
603}

Recommendation:

Given the design of the overall contract system, we advise the transferMintership to only be executable once towards the FamilyContract token and to not permit further mintership transmissions, ensuring that the token's minting function cannot be compromised.

Alleviation:

The WagmiDAO team opted to retain the current behaviour in place as they should retain the privilege to change the minter in case there is some problem with the current one as otherwise a whole token migration would be necessary. The WagmiDAO has additionally clarified that the owner of the token will be a 24 hour Timelock contract acting as a second layer of security. In light of this information, we consider this exhibit adequately responded to.

FTN-02M: Arbitrary Burn Mechanism

Description:

The burn implementation of the FAM token does not take into account any allowance by the user the assets are burned from, thus allowing the minter to burn tokens arbitrarily.

Example:

Copy
600function burn(address _from, uint256 _amount) external onlyMinter {
601    _burn(_from, _amount);
602}

Recommendation:

Given the design of the codebase, we advise the burn function to omit its first argument and to instead simply burn tokens from the dead address as specified within the FamilyContract.

Alleviation:

The burn function now properly burns units solely from the dead address, preventing arbitrary burns in case of minter misbehaviour.