Description:
In buy_fraction, the balance is fetched before checkpoint_yield, then fetched again from storage after it. The first read is used for the checkpoint (correct), but the second read is a fresh storage fetch and will equal the first since nothing changed yet. This is redundant and fragile — if the checkpoint somehow modifies storage in a future refactor, the logic silently breaks.
More critically: the balance variable used for the IsHolder guard (if balance == 0) is the second fetch, which will always equal the first fetch. This is only accidentally correct and will cause confusion.
Expected behaviour:
Use a single balance read. Pass that value to checkpoint_yield and reuse it for all subsequent logic in the same call.
Labels: bug, contracts, fraction-vault
Description:
In
buy_fraction, the balance is fetched beforecheckpoint_yield, then fetched again from storage after it. The first read is used for the checkpoint (correct), but the second read is a fresh storage fetch and will equal the first since nothing changed yet. This is redundant and fragile — if the checkpoint somehow modifies storage in a future refactor, the logic silently breaks.More critically: the
balancevariable used for theIsHolderguard (if balance == 0) is the second fetch, which will always equal the first fetch. This is only accidentally correct and will cause confusion.Expected behaviour:
Use a single balance read. Pass that value to
checkpoint_yieldand reuse it for all subsequent logic in the same call.Labels:
bug,contracts,fraction-vault