fee_calculator::calculate_fee lacks any access control

[martinzhames]

Category: security

Problem

dabdub_contracts/contracts/fee_calculator/src/lib.rs's calculate_fee(env: Env, merchant: Address, amount: i128) -> (i128, i128, u32) has no caller parameter and calls no require_auth() anywhere. It directly mutates persistent per-merchant rolling-30-day volume state via update_and_get_volume (line 151-171), which determines which fee tier (select_fee_bps) the merchant gets on every subsequent call. src/test.rs calls client.calculate_fee(&merchant, &amount) directly with no authorizing party in every test, consistent with there being no auth to bypass.

Impact

Any address can call calculate_fee for any merchant with an arbitrary amount, with no funds actually moving and no relationship to a real payment. Repeated calls artificially inflate a targeted merchant's tracked volume_usdc, permanently pushing them into a lower fee-bps tier ahead of real usage — a direct fee-tier manipulation/gaming vector, and also a griefing vector (an attacker can pollute a competitor's volume window with a flood of amount=1 calls). Since this contract appears intended to be invoked only by trusted settlement flow (e.g. payment_escrow/settlement_ledger), the absence of a caller restriction is a real access-control gap on state that directly affects merchant economics.

Suggested fix

Add a caller: Address parameter with caller.require_auth(), and restrict calculate_fee to a configured, admin-settable caller (e.g. the settlement/escrow contract's address), similar to the admin-gating pattern used in merchant_registry::update_fee_tier.

[shemaiahdelia03-cmd]

@shemaiahdelia03-cmd has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi! I would like to work on this issue for this wave. I have experience with this stack, understand the requirements, and I'm ready to submit a clean, well-tested PR once assigned. Could you please assign it to me?

ℹ️ Repo Maintainers: To accept this application, review their application or assign @shemaiahdelia03-cmd to this issue.

[M2u0i0z]

@M2u0i0z has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I'd be glad to handle this issue. I'll keep the implementation concise, maintainable, and well-documented. .
Please 🙏

ℹ️ Repo Maintainers: To accept this application, review their application or assign @M2u0i0z to this issue.

[ibochivincent-lang]

@ibochivincent-lang has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I’d like to work on Issue #1019 because calculate_fee currently allows any address to modify a merchant’s rolling 30-day volume without proving that the call comes from a legitimate payment or settlement flow. Since that volume directly affects fee tiers, this creates a clear opportunity for fee manipulation and griefing.

I will first review contracts/fee_calculator/src/lib.rs, the existing volume-tracking logic, and the contracts that are expected to call calculate_fee, especially the settlement and escrow paths. I will also review the authorization pattern used by related contracts such as merchant_registry.

I will then add caller authentication to calculate_fee and require the caller to authorize the operation. I will also introduce a configured trusted caller address, controlled through the existing admin pattern, so only the intended settlement or escrow contract can update merchant volume and calculate the associated fee.

The authorization logic will be designed so unauthorized callers cannot artificially increase a merchant's tracked volume. I will also make sure the configured caller cannot be changed by an unauthorized account and that changing it follows the contract's established administrative controls.

I will update the existing tests to provide the required caller and add security-focused cases covering authorized calls, unauthorized callers, and attempts to manipulate a merchant's volume through repeated or arbitrary fee-calculation requests.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @ibochivincent-lang to this issue.

[unrealtim-tech]

@unrealtim-tech has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I would like to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @unrealtim-tech to this issue.

[drips-wave]

Congratulations, @unrealtim-tech! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @unrealtim-tech: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊