Hytham Farah

Smart Contract Security Auditor

Audit portfolio from my time at Quantstamp, where I led 26 and contributed to 98 audits securing over $1B in TVL across Ethereum, Solana, Cosmos, and Flow. Background in pure mathematics (MSc, University of Toronto) and web2 security training at the Fields Institute. Cross-ecosystem fluency in Solidity, Rust, Cadence, CosmWasm, and Go.

98 Total Audits
26 Audits Led
30 Published Reports
4 Languages
The Impact of Chain Forks and Reorgs on Cross-chain Bridges

Quantstamp research developed with Kacper Bąk and Alex Murashkin, presented at ETHAustin 2023. Analyzes the security and performance impact of chain forks and reorgs across the full cross-chain bridge design space, varying by decentralization level, settlement speed, and whether the bridge connects two L1s or an L1 to an L2. Introduces a novel deposit-hash mitigation for L1-L2 bridges.

  • Chain forks (e.g. PoW to PoS) have no meaningful security impact on bridges; it is reorgs, specifically changes to the chain tip during active bridge operations, that create real risk
  • A 51% attacker can deposit assets on the source chain, bridge them to the target, withdraw on the target, then reorg the source chain to erase the original deposit, effectively double-spending. This attack vector is independent of how decentralized the bridge is
  • Fast L1-L1 bridges are structurally undefendable: because both chains are live L1s, a reorg on either side can invalidate already-settled withdrawals with no recourse
  • Standard L1-L2 bridges can reduce risk by requiring enough block confirmations to outlast a plausible reorg depth, but this trades off settlement speed
  • The proposed mitigation for L1-L2 bridges uses a deposit hash committing to the cumulative bridged amount, the current L1 chain tip, and the ChainID. A withdrawal on the L2 is only valid if it references a deposit hash present in the canonical L1 history at the time of withdrawal. If a reorg erases the original deposit, the hash no longer exists on-chain and the withdrawal is rejected, closing the double-spend window for both fast and standard L1-L2 (ZK-)bridges

Six findings selected for range rather than volume: account abstraction, oracle manipulation, cross-protocol composability, DeFi math, accounting invariants, and MEV.

Account Abstraction
ALC-1 High
Deferred Actions Bypass All Validation Hooks
In Alchemy’s ERC-6900 modular account, deferred actions embedded in signed UserOps skipped pre-validation and execution hooks, so a tightly scoped session key could drain the full account.
Oracle Manipulation
ERD-7 High
Oracle Fallback Chain Exploited for Mass Liquidation
A fallback chain from Chainlink to Tellor let an attacker force a false low price, trigger recovery mode, and flash-loan liquidate healthy troves. The exploit only appears when multiple external systems fail in sequence.
Cross-Protocol Composability
ARC-36 High
GLP Redemption Mismatch Opens Three Exploit Paths
Closing a leveraged position assumed GLP burn outputs matched debt exactly; when they did not, liquidation, repayment, and accounting each failed differently. One mismatch opened three exploit paths across GMX and the lending layer.
DeFi Math
PRI-2 High
Volatility Domain Error Breaks Health Function
The health formula assumed realized volatility stayed in [0, 1); the actual feed domain was [0, ∞). At 100% volatility every position hit health zero, and above 100% the liquidation logic broke in the opposite direction.
Accounting Invariants
FAB-1 High
Inverted Formula Enables Double-Claiming Yield
A transfer-accounting bug used the wrong balance term when updating _withdraws, letting an attacker transfer zero, reset withdrawal history, and repeatedly reclaim yield until the contract was drained.
MEV
SYN-1 High
Order Filling Can Be Preempted by New Order Placement
Taken but unfilled orders could be preempted by a newly placed order at the same tick. A sophisticated trader could place, fill, and unwind in one transaction, extracting risk-free arbitrage while displacing existing users’ orders.
Audit clients may choose to publish their report or keep it confidential. The reports below represent the subset that clients have elected to make public. They are hosted on Quantstamp's official certificate platform.