Description

Two conflicting authorization-revocation flows exist in the system with different access-control requirements:

The first flow is a two-step process with operator approval.

// Owner initiates revocation
requestRevokeServiceAuthorization(service) 
    → creates pending revocation with cooldown
    → operator must approve via approveAuthorizationRevocation()

The second flow is direct revocation without operator approval.

// Owner directly revokes
revokeOperatorBorrowing(service)
    → immediately revokes authorization
    → bypasses operator approval entirely

The existence of revokeOperatorBorrowing allows owners to bypass the intended two-step revocation process that requires operator oversight. This creates an inconsistency in the authorization model where one path enforces operator approval (suggesting it is a critical security control) while another path allows owners to act unilaterally.

Impact

The impact is indeterminate as it depends on the intended design:

• If operator approval is required for revocation (to ensure settlements are complete before removing authorization), then revokeOperatorBorrowing undermines this control.

• If owners should have unilateral revocation rights, then the two-step process in requestRevokeServiceAuthorization adds unnecessary complexity.

The inconsistency creates confusion about the actual authorization model and may lead to incorrect assumptions about access controls.

Recommendations

Clarify the intended authorization revocation model:

1. If operator approval is required, remove revokeOperatorBorrowing to enforce the two-step process consistently.

2. If owners should have direct revocation rights, remove requestRevokeServiceAuthorization and approveAuthorizationRevocation, keeping only revokeOperatorBorrowing.

Remediation

This issue has been acknowledged by Hyperbeat, and a fix was implemented in commit 582d51b5↗. Direct revocation of the operator’s credit service authorization in CREDIT mode is now not allowed.