An aggregator reports a security incident: what should users check?

After a reported aggregator incident, first establish what was affected: website, signing flow, allowance contract, router implementation, bridge or operational keys. The response should match that scope.

Verify the notice

Use independently verified official channels and corroborate the exact contract addresses, networks and relevant time window. Incident announcements attract impersonators offering fake revocation or refund pages.

Do not sign a migration transaction simply because a social reply uses the protocol’s logo.

Check your actual exposure

• Did you interact during the affected period?
• Did you authorize one of the identified spenders?
• Are relevant allowances still active?
• Did you sign an unused permit or order?
• Is there evidence your signing secret was exposed?

Standard token revocation and signature-related risk require different checks. A website restoration does not automatically clear permissions already granted.

Review before resuming

Read the remediation explanation, current deployment information and any new review. If contracts changed, verify the new spender and determine whether the old allowance should remain.

Upgradeable contract designs can change behavior behind an address, so the familiar address alone does not settle whether the relevant fix was deployed.

Preserve transaction evidence and use official support for account-specific questions. A general notice that “funds are safe” should not replace checking the scope relevant to your own transactions. Avoid granting additional permissions merely to qualify for an unverified compensation promise.