# Asymmetric address validation across checks

Two paths compare sender, receiver, or token addresses differently, so one check can be bypassed

_Area: Smart contract access control and control flow. Seen in 2 disclosed reports; latest 2024-02-13. Updated 2026-10-24._

## How it works
A privileged decision is gated on an address comparison, but the same address is represented or derived differently at two points. One path compares against a stored canonical value; another path compares against a caller-supplied alias, a different field, or a registry membership that can change. When the two representations diverge, a caller satisfies the weaker check while the stronger one is never reached, or a legitimate payload is rejected by the second check. The broken assumption is that "same address" means the same thing everywhere.

## Where it shows up
- Equality checks like `token == collateral` or `msg.sender == expected` guarding debt, balance, or permission logic.
- Tokens with legacy or double entrypoints (proxies, upgradeable tokens) where an alias resolves to the same underlying balance.
- Registries with both add and remove operations, where downstream `isRegistered` checks assume removed entities stop operating.
- The same payload validated in two places, each deriving the expected sender/receiver from a different field.
- Cross-chain flows where keeper-supplied data is checked against source sender in one contract and receiver in another.

## How to review
Identify every site that compares an address and confirm they all resolve to the same canonical identity. The invariant: any address accepted by a weaker check must also pass the strongest check on the same underlying entity, and vice versa. For tokens, verify alias/double-entrypoint addresses cannot move the real balance while skipping the debt or permission gate. For registries, confirm removed-but-live entities are handled consistently at every membership check. For multi-site validation, confirm both sites derive the expected party from the same field.

## Variants seen
- Alias collateral token bypasses debt check in withdraw [E1](https://bugbountylibrary.com/r/c4%3A2023-04-frankencoin%3AH-02.md).
- Removed market fails registration check, blocking sanctions enforcement while market still operates [E2](https://bugbountylibrary.com/r/c4%3A2023-10-wildcat%3AM-07.md).
- Two validation sites use different address fields, reverting valid cross-chain withdrawals [E3](https://bugbountylibrary.com/r/cantina%3Asuperform_erc1155a_dec2023%3A3.2.4.md).

## Impact and severity
Led to draining collateral without repaying debt [E1](https://bugbountylibrary.com/r/c4%3A2023-04-frankencoin%3AH-02.md), sanctions evasion [E2](https://bugbountylibrary.com/r/c4%3A2023-10-wildcat%3AM-07.md), and denial of service on withdrawals [E3](https://bugbountylibrary.com/r/cantina%3Asuperform_erc1155a_dec2023%3A3.2.4.md). Severity rises when the bypassed check protects funds or compliance, and when the divergence is silent.

## Evidence
- E1: https://bugbountylibrary.com/r/c4%3A2023-04-frankencoin%3AH-02.md
- E2: https://bugbountylibrary.com/r/c4%3A2023-10-wildcat%3AM-07.md
- E3: https://bugbountylibrary.com/r/cantina%3Asuperform_erc1155a_dec2023%3A3.2.4.md