
SmartMemory: Detecting On-chain-off-chain Communication Inconsistency for Smart Contract via Memory-based Agent
SmartMemory is an academic framework that detects "OFC inconsistency" (OFCI) — a newly identified root-cause vulnerability class where business-logic flaws break the equivalence between a smart contract's on-chain state and its off-chain counterpart, affecting cross-chain bridges, real-world-asset tokenization, and fiat-backed stablecoins. It normalizes heterogeneous on-chain/off-chain implementations into a canonical business-semantic representation, uses a memory-based agent to distill and reuse vulnerability patterns across cases, and verifies candidates with taint analysis. Evaluated on a new dataset of 48 DApps with 81 known OFCIs (80.68% precision, 87.65% recall), it also found 36 previously unknown, since-fixed OFCIs in an analysis of 325 real-world OFC applications.
What it is
SmartMemory targets OFC inconsistency (OFCI), which it splits into two structural subtypes tied to specific broken invariants: Type-1 asset-exchange inconsistency (violates equivalence invariants B1/B3 — the minted/withdrawn token quantity doesn't match the input-side asset value) and Type-2 proof-semantic inconsistency (violates B2 — an on-chain event/proof structure is ambiguous enough that an off-chain verifier parses a meaning inconsistent with actual asset flow).
How it works
The paper gives concrete worked examples the summary omits. For Type-1: a Pledge contract's mint function has two paths (mint from on-chain assets, or mint from off-chain collateral) that both erroneously key off the same chainAmount variable — letting an attacker submit a minting request backed by minimal off-chain collateral, then inflate the on-chain asset amount, and mint excessive tokens before withdrawing the original on-chain deposit.
For Type-2: a Token.deposit() function emits a Deposit event as proof-of-assets, but a separate Vault.returnAssets() function (meant to batch-return funds to users) emits a Transfer event with the same structure and fully attacker-controlled parameters. Off-chain relayers can't distinguish the two events, so an attacker calls returnAssets to forge a valid-looking deposit proof and withdraws assets without ever depositing.
A real-world diversity example is also given: Wormhole verifies off-chain proofs via guardian multisig, flags status with a boolean, and emits redeem; Nomad instead uses Merkle-proof verification, stores a Merkle root as status, and emits Process/Receive. This divergence in implementation is why pattern-based tools miss cross-implementation instances of the same root cause.
Preconditions / Affected
Applies to contracts implementing any of the three equivalence invariants: B1 (outflow≡proof), B2 (proof≡off-chain-parsed value), B3 (accepted off-chain proof≡minted tokens) — i.e., cross-chain bridges, RWA tokenization, and fiat-backed stablecoin contracts where an off-chain relayer/verifier consumes on-chain events or proofs.
flowchart TD
A[On-chain deposit/burn] -->|emits proof event| B{Event structure ambiguous?}
B -->|Yes - Type-2| C[Off-chain verifier conflates unrelated event as proof]
B -->|No| D{Mint path uses correct input variable?}
D -->|No - Type-1| E[Mint amount decoupled from actual off-chain collateral]
D -->|Yes| F[Equivalence invariant holds]
C --> G[Attacker withdraws without real deposit]
E --> GCaveats
The paper states its static analysis explicitly excludes OFCIs caused by non-contract issues (e.g., runtime or off-chain infrastructure failures) — only contract-side business-logic flaws are in scope.
Technologies named here
- OFC smart contract applications
- SmartMemory
Techniques named here
- OFC inconsistency
- Taint Analysis
Related in Blockchain

THORChain Exploit Report #2 — GG20 root-cause disclosure

Black Thursday revisited: MakerDAO keeper exploited for $500K
.jpg)