Selected operator type suppresses personal ICS applications from other role holders

[exromany]

Locations

• csm-widget/features/ics/shared/ics-state-provider.tsx:64-69
• csm-widget/features/ics/ics-apply.tsx:32-37

Summary

The widget classifies a connected wallet as having claimed ICS whenever its selected operator is already ICS, even if the wallet is only that operator's non-owner role holder. This prevents the wallet from opening or reapplying to its own JWT-scoped ICS application.

Root cause

IcsStateProvider derives CLAIMED from the selected operator's operatorType without requiring the connected address to be that operator's owner or to have consumed its own proof.

• IcsApplyContent gives this mixed-identity CLAIMED state precedence over SIWE authentication and the connected wallet's Survey status.
• The backend would select the connected wallet's own application from its JWT, but this route never renders it.

Impact

A legitimate manager or rewards role holder on an existing ICS operator can be denied their personal application or reapplication route. Consequently, the widget can prevent them from obtaining the proof needed to create or convert an operator they own.

• No unauthorized transaction occurs.
• Direct Survey API use or changing the operator-role topology can restore access, making this a low-severity availability failure.

Scenario

• Owner O operates an ICS operator and assigns V the non-owner manager or rewards role.
• V connects with no personal proof and either no application or a rejected application.
• The selected operator reports CSM_ICS, so the provider labels the state CLAIMED despite V not owning it.
• The apply page returns ProofStatus before its SIWE and Survey-status branches and tells V that the operator type was successfully claimed.
• V cannot open or retry the application belonging to their own address while that ICS operator remains selected.

---

Drafted from LidoLens finding ICS-STATE-02