The Deception Delta (arXiv 2609.14098): deceptive bytecode versus LLM analysis

What happened on this date

On 2026-09-12 (UTC), Timo Schefold submitted v1 of The Deception Delta to arXiv (v2 followed on 2026-10-06). The paper asks whether LLMs used in blockchain forensics can be misled by contracts built to deceive. It tested 22 frontier models with six prompt strategies on 13 purpose-built contracts, 9 deceptive and 4 controls, producing 8,528 usable runs. Compared with functionally matched controls, deception lowered drain detection by about 20 percentage points. Multi-hop call chains, XOR-masked selectors and storage-loaded drain parameters evaded detection in almost all models; some models described the hidden mechanism correctly yet accepted the contract's benign framing. Simple guard instructions did not help overall, and only five models from two providers exceeded 50% detection. The author states that the conclusion holds only for a single-shot, raw-bytecode-only protocol and does not cover multi-turn, tool-augmented or decompiler-assisted workflows.

Why it matters for protecting app logic

The subject is smart contracts, not apps, but the paper offers a data point: techniques like indirect calls, masking and data-driven dispatch do affect LLM understanding in a single-shot reading. That cannot be generalized into obfuscation stops AI. Real analysts are more likely to use multi-turn agent workflows with tools and decompilers, which is exactly outside the paper's scope. A more direct lesson concerns defenders themselves: if you use LLMs to review your own code or third-party SDKs, the finding that models described the mechanism correctly but still reached the wrong verdict shows that single-shot LLM review can create false reassurance.

Checks you can run

First, do not make single-shot LLM review the only gate for adopting a third-party SDK or binary dependency; keep human review and dynamic observation. Second, when evaluating how your protection affects AI-assisted analysis, use multi-turn, tool-enabled scenarios rather than only pasting code into a chat. Third, any external statement that AI struggles to understand your code should state the test protocol and scope. Fourth, in review reports, separate a model's description of a mechanism from its risk verdict and verify each independently. Revisit any such conclusion as models and tools change.

Your checklist

• Do not make single-shot LLM review the only gate for third-party dependencies
• Evaluate protection with multi-turn, tool-enabled scenarios
• State test protocol and scope in any external claims