Description

In transferErcTokens, the contract calls:

However, there is no guarantee that msg.sender has executed approve(address(this), amount) on the ERC20ToGenerateNftFraccion token. If not approved, transferFrom will revert. Although some of the code in TokenDivider updates an internal balances mapping, it does not ensure an ERC20 approve or handle reverts explicitly.

Impact

1. Transaction Reverts: Users may repeatedly run into reverts if they do not first call approve(TokenDivider, amount).

2. User Confusion: The internal balances might no longer reflect the actual token contract’s allowance or real balance after a revert.

Attack Route

1. A user calls transferErcTokens without having given the contract an allowance.

2. The transaction reverts on the external call transferFrom(msg.sender, to, amount).

(While not a “theft” vulnerability, it is a usability/design risk that could break your system if the logic does not match standard ERC20 patterns.)

Recommendation

• Either require the user to set approve before calling transferErcTokens, or redesign to a “pull” model where the user transfers the tokens into the contract first, and then the contract updates internal balances.

• Document carefully (in comments or a UI) that users must approve the contract before transferring fractions.