---
title: 'FlashGuard: Dual Systems for PSE & DeFi'
url: https://www.emergentmind.com/topics/flashguard
type: topic
---

# FlashGuard: Dual Systems for PSE & DeFi

FlashGuard is the name used by two distinct 2025 research systems: one targets seizure-inducing flashes in digital media for viewers with photosensitive epilepsy (PSE), and the other targets non-price flash loan attacks against Decentralized Finance (DeFi) smart contracts. In both cases, the name denotes a tightly integrated detect-and-mitigate pipeline operating under stringent latency constraints, but the technical substrates differ completely: the former is built around perceptually uniform color-space analysis in CIELAB for real-time media sanitization, whereas the latter is built around mempool monitoring, function-signature matching, and stealth dusting counterattacks in EVM-compatible blockchains [2507.19692] [2503.01944].

## 1. Scope and nomenclature

In the 2025 arXiv literature, “FlashGuard” designates separate systems rather than a single unified framework. One paper, “FlashGuard: Novel Method in Evaluating Differential Characteristics of Visual Stimuli for Deterring Seizure Triggers in Photosensitive Epilepsy,” was published on 2025-07-25 and addresses accessibility and media safety. The other, “Protecting DeFi Platforms against Non-Price Flash Loan Attacks,” was published on 2025-03-03 and addresses blockchain runtime security [2507.19692] [2503.01944].

| FlashGuard variant | Domain | Core mechanism |
|---|---|---|
| FlashGuard for PSE | Digital media accessibility | CIELAB-based detection plus localized luminance reduction and color smoothing |
| FlashGuard for DeFi | Smart contract security | Mempool signature matching plus stealth dusting counterattack |

The shared nomenclature reflects a common systems pattern: each FlashGuard is designed for real-time intervention rather than purely offline analysis. This suggests a broader engineering motif in which detection is coupled directly to mitigation, with latency budgets treated as a first-class design constraint.

## 2. FlashGuard for photosensitive epilepsy: problem setting and architecture

The PSE-oriented FlashGuard is a software system designed to detect and mitigate seizure-inducing flashes in digital media in real time, using a perceptually uniform color-space analysis in CIELAB. It was motivated by the observation that individuals with photosensitive epilepsy can suffer seizures when exposed to rapid flashes of brightness or high-contrast color changes in videos, social media feeds, games, and other digital displays. Existing tools such as the Photosensitive Epilepsy Analysis Tool (PEAT) and the WCAG 2.0 Success Criterion 2.3.1, “Three Flashes or Below Threshold,” work only in an offline, asynchronous fashion and target primarily global luminance or saturated-red flashes; they do not scale to user-generated, streaming content and tend to deny or obscure entire video streams rather than surgically remove only the dangerous elements [2507.19692].

Its architecture comprises two tightly integrated subsystems. The detection subsystem samples screens at video frame rate, uses a grid of sampler points such as a 50×50 “trigger array,” reads pixel colors, converts them from RGB into CIELAB $(L^*, a^*, b^*)$ values, and computes temporal differentials. Each sampler stream feeds a logistic-regression classifier that outputs a binary risk signal, and the active nodes are interpolated into a continuous “risk mask” that locates just those regions requiring mitigation. The mitigation subsystem then applies two localized filters only where the mask indicates unsafe flashing: a luminance suppression filter overlays a semi-opaque black tint whose opacity, or “k-level,” is adaptively chosen, and a color-smoothing filter blends the current frame’s Lab* values with a running average over the past $n$ frames, with $n = 15$.

The stated objectives were a real-time, low-latency detection method that runs on the user device, a computationally lightweight pipeline that preserves most of the original content, and a broader set of metrics that capture not only brightness but also perceptual color contrast.

## 3. Perceptual metrics, detection logic, and mitigation in the visual system

Flash detection in the PSE-oriented FlashGuard is based on measuring the rate of change of color in Lab space. Given successive frames at times $t_1$ and $t_2$, the per-pixel color difference is

$$
\Delta E_{ab} = \sqrt{(L_2^* - L_1^*)^2 + (a_2^* - a_1^*)^2 + (b_2^* - b_1^*)^2}.
$$

Because CIELAB is designed to be perceptually uniform, $\Delta E_{ab}$ is used as a proxy for human-perceived color change. For a small region or pixel stream, FlashGuard aggregates these per-pixel $\Delta E$ values over time, forming an estimate of “flashing” $F$, decomposed into luminance and chromatic components as

$$
F = |dL^*/dt| + \sqrt{(da^*/dt)^2 + (db^*/dt)^2}.
$$

This quantity is compared against a learned threshold $T$ [2507.19692].

Operationally, the system maintains a sliding window of Lab* values at each sampler point; the instantaneous rate of change is approximated by frame-to-frame differences, and $F$ is averaged over the last few frames to reduce noise. Spatial sampling with a 50×50 grid reduces pixel-level monitoring from approximately 800 K pixels to 2,500 sampler streams, described as a 99.7% reduction in computational load. Using a synthetic training set of 800 ten-second videos labeled by PEAT as risky or non-risky, a logistic model learns the threshold $T$ that best separates safe from dangerous flashing, and this single-parameter model attains an AUC-ROC of 0.90. Because the Lab* axes are perceptually aligned, no further weighting is required, although the system can adapt $T$ in low-light versus high-light conditions if desired.

Mitigation is explicitly localized. Once a region’s aggregate $F$ exceeds $T$, a luminance reduction filter uses an adaptive black overlay with opacity $k$ to suppress brightness spikes; empirically, $k$ is modeled as a decreasing function of the local $L^*$ value. The color-smoothing stage computes, for current frame color $C_t$ in the masked region and running mean $\bar C_{t-n \dots t-1}$ over the previous $n = 15$ frames,

$$
C'_t = \alpha \cdot \bar C + (1-\alpha)\cdot C_t,
$$

with $\alpha$ chosen to remove abrupt chromatic jumps while preserving detail. By relying on color-space conversion, vector differences, logistic scoring, and alpha-blending rather than deep networks, the system processes each frame in under 10 ms on a modern CPU, and GPU acceleration can reduce this to sub-2 ms per frame.

## 4. Evaluation, standards implications, and limitations of the visual system

Evaluation of the PSE-oriented FlashGuard was reported on several controlled datasets. On 200 held-out synthetic videos, with 100 risky and 100 safe by PEAT, the logistic detector achieved 80% overall accuracy, 86% true-positive rate, 74% true-negative rate, and $\mathrm{AUC} = 0.9038$ with $p < 0.001$ versus random. In luminance mitigation experiments using 200 single-color videos with controlled white-flash overlays, the minimum k-level required to neutralize PEAT-detected flashes showed a Pearson correlation of $-0.43$ with the base color’s $L^*$, with darker colors needing more darkening. A Shapley analysis confirmed the Helmholtz–Kohlrausch effect’s role in perceived brightness. When both mitigation filters were applied to 200 high-risk videos, FlashGuard reduced PEAT-detected flash frames by 92%, while preserving scene content, and was reported to significantly outperform GAN-based sanitization in speed and content fidelity [2507.19692].

The study argues that seizure risk depends not only on flash rate and pure brightness but also on perceptual color contrast and intrinsic luminance of the media. On that basis, it calls for revision of WCAG 2.0 Success Criterion 2.3.1 to include thresholds on $\Delta E_{ab}$ for color-contrast flashes in addition to luminance flashes, to adopt spatially localized criteria such as flashing regions greater than 25% of the viewport rather than global rules, and to encourage real-time mitigation tools on consumer platforms such as TikTok and Instagram rather than sole reliance on user-driven filtering.

Its limitations are stated directly. Initial validation used synthetic videos and PEAT as ground truth, which may not fully capture the diversity of real-world content or individual patient thresholds. Proposed future directions include gathering user-labeled PSE trigger datasets from real media, personalizing threshold $T$ and k-level based on patient EEG feedback, extending spatial resolution to dynamically adjust sampler density for high-motion areas, integrating machine learning to predict k-level directly from Lab* histograms, and conducting formal user-experience studies on content acceptability and seizure-prevention efficacy.

## 5. FlashGuard for non-price flash loan attacks: threat model and detection architecture

The DeFi-oriented FlashGuard is a runtime detection and mitigation method for non-price flash loan attacks. It addresses attacks that exploit logical vulnerabilities in smart contracts, often zero-day flaws, in an atomic transaction that borrows liquidity from a flash loan provider, corrupts victim contract state, siphons assets, and repays the loan within a single block. The paper distinguishes these attacks from classical price-manipulation flash loans that exploit oracles or Automated Market Makers. Because the attack succeeds or reverts atomically and unfolds during the brief interval in which pending transactions are visible in the mempool but not yet confirmed, the problem is framed as one of real-time detection plus immediate disruption [2503.01944].

The architecture comprises three tightly integrated components: a Mempool Monitor, a Signature Matcher, and a Counterattack Dispatcher. The sequence flow is explicit: the attacker’s exploit transaction enters the mempool; the monitor captures the new transaction and forwards `input_data` to the matcher; the matcher decodes function signatures and applies detection logic; on a positive match it emits `txHash` to the dispatcher; the dispatcher crafts a minimal dusting transaction targeting the victim contract’s state; this dusting transaction is submitted via private relay to a miner; the miner includes the dusting transaction, altering contract state; and the miner then includes the attacker transaction, whose corrupted preconditions cause it to revert.

Detection is based on a characteristic combination of function signatures within a single pending transaction. Let $F(tx)$ denote decoded input data for transaction $tx$, and define signature sets for flash loan providers, token transfer, withdrawal, and approval. The transaction is flagged if

$$
\mathrm{hasFlashLoan}(tx) \wedge \big(\mathrm{hasTransfer}(tx) \vee \mathrm{hasWithdrawal}(tx)\big) \wedge \mathrm{hasApproval}(tx).
$$

Known benign addresses, such as MEV bots, are excluded to reduce false positives. The report states that filtering out excluded addresses yields approximately 45% speedup.

## 6. Dusting counterattack, implementation, and empirical results in the DeFi system

Once a transaction is flagged, the DeFi-oriented FlashGuard dispatches a “dusting” counterattack intended to disrupt the attacker’s assumed atomic state. Two variants are supported. In Allowance-Based State Dusting (ABSD), the victim DeFi protocol subscribes to FlashGuard and grants a small token allowance, for example 2 USDC. The dispatcher computes $\mathit{dustAmt} = \min(\text{allowance}, \texttt{fixed\_dust})$, verifies the allowance with `IERC20(token).allowance(victim, this)`, executes `transferFrom(victim, 0x…dead, dustAmt)`, and uses `Revert("Disruption successful")` to abort only the dusting transaction’s net effect while leaving the state change that invalidates the attacker’s preconditions intact. In Self-Funded State Dusting (SFSD), FlashGuard uses its own funds, dispatches `transfer(token, 0x…dead, \texttt{fixed\_dust})` from FlashGuard’s balance, and then reverts in the same manner. To guarantee ordering against high-gas attacker transactions, the system submits via private relays such as Flashbots, bypassing the public mempool and minimizing latency. The timing constraint is expressed as requiring $t_{\mathrm{det}} + t_{\mathrm{disp}} \ll t_{\mathrm{block}}$, with average block inclusion on Ethereum given as approximately 12 s [2503.01944].

Implementation details are concrete. Core modules are written in Node.js with Web3.js for mempool monitoring via WebSocket; the disruptor smart contract is written in Solidity and compiled and tested with Foundry; and the system integrates with Infura and Alchemy nodes for multi-chain access. Additional low-latency optimizations include an address exclusion table $\mathbb{E}$, signature-only parsing of `input_data` rather than full ABI decoding, in-memory hash maps to correlate internal call events, and private relay submission for near-instant dispatch.

The evaluation uses 20 real-world non-price flash loan attacks from 2020 to 2024 across Ethereum, Base, Arbitrum, Polygon, and Avalanche, together with 6 “unseen” vulnerability scenarios. Metrics include detection latency $t_{\mathrm{det}}$, detection accuracy, precision, recall, false positive rate, disruption time $t_{\mathrm{disp}}$, resource usage, and counterattack gas cost.

| Blockchain | FPR | Accuracy |
|---|---:|---:|
| Ethereum | 0.03% | 99.97% |
| Base | 0.05% | 99.95% |
| Arbitrum | 0.09% | 99.91% |
| Polygon | 0.16% | 99.84% |
| Avalanche | 0.04% | 99.96% |

Across these experiments, FlashGuard achieved an average real-time detection latency of 150.31 ms, detection accuracy of over 99.93%, average disruption time of 410.92 ms, and combined detection plus disruption latency of approximately 561.23 ms. Resource overhead was reported as approximately 8.24% CPU and approximately 0.40 MiB memory. The paper states that FlashGuard could have potentially rescued over \$405.71 million in losses if deployed prior to the evaluated attack instances. On “unseen” cases, ABSD disrupted all listed vulnerability types, whereas SFSD failed for unchecked return value and uninitialized storage pointer scenarios, illustrating a trade-off between gas cost and security coverage. In the Hedgey Finance replay, with loss approximately \$2 M, the attacker transaction sequence was `flashLoan → createLockedCampaign → cancelCampaign → siphon funds → repay`; FlashGuard reported $t_{\mathrm{det}} = 129.93$ ms, immediately dispatched ABSD dusting of 1 USDC via private relay, altered the victim contract’s allowance, caused `cancelCampaign` to fail the `REVERT` check, and prevented any fund loss.

The paper also states several limitations. SFSD may fail against vulnerabilities that do not depend on token allowances if gas spent on dusting is too low to alter attacker preconditions. The system assumes predictable function signatures, so heavily obfuscated or proxy-based attacks may evade signature matching. It also relies on private relay availability and miner support, so extremely congested networks or relay downtime could degrade performance. Proposed future work includes on-chain deployment with long-term monitoring, obfuscation resilience through lightweight machine learning or pattern recognition, automatic updating of exclusion lists and signature sets from false positives and false negatives, and cross-chain coordination for bridge-mediated and multi-chain flash loan strategies.

Source: https://www.emergentmind.com/topics/flashguard