Root + Impact

Description

Normal behavior:
LikeRegistry charges a protocol fee when a mutual match occurs. The fee is intended to represent a fixed percentage of the pooled rewards (e.g. 10%), which is then accumulated in totalFees.

Issue:
The variable FIXEDFEE is ambiguously named and does not clearly indicate its unit. Although the fee is applied as a percentage (/ 100), the name suggests a fixed absolute fee rather than a percentage-based rate.

This naming mismatch can lead to:

• Misinterpretation by auditors or integrators

• Incorrect future modifications

• Incorrect frontend assumptions about fee behavior

The logic itself is correct, but the intent is unclear from the variable name.

Risk

Likelihood:

• Reason 1: The ambiguity exists immediately in the deployed code.

• Reason 2: Any developer, integrator, or auditor interacting with the code may misinterpret the fee model.

Impact:

• Impact 1: No direct financial loss or security impact.

• Impact 2: Increased maintenance risk and higher chance of future bugs due to misunderstanding.

• Impact 3: Reduced code clarity in a financially sensitive calculation.

This is a documentation / clarity issue, not a logic flaw.

Proof of Concept

Explanation

The issue is not a runtime failure, but a semantic ambiguity in the fee definition.

The variable name FIXEDFEE suggests an absolute or flat fee, while the implementation applies it as a percentage of the matched rewards by dividing by 100. This mismatch is only visible by carefully reading the calculation logic.

A developer or integrator reading the code may reasonably assume that FIXEDFEE = 10 represents a fixed amount, not a percentage, and could incorrectly build logic or UI around that assumption.

Observed behavior

• The fee is calculated as 10% of totalRewards

• The variable name does not communicate that it represents a percentage

Why this matters

While the current calculation is correct, unclear semantics increase the likelihood of:

• Incorrect future changes to fee logic

• Incorrect frontend displays (e.g. showing a “fixed fee”)

• Incorrect assumptions during audits or protocol extensions

This PoC demonstrates that the issue is clarity and maintainability, not an exploitable bug.

Recommended Mitigation

Rename the variable to explicitly reflect its unit and purpose.

And update the calculation accordingly:

Alternatively, if keeping percentage semantics: