Skip to content

Back to the catalog

SmartMemory: Detecting On-chain-off-chain Communication Inconsistency for Smart Contract via Memory-based Agent
arxiv.orgpaper

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.

TL;DR A memory-based agent framework that detects a newly identified class of on-chain/off-chain business-logic inconsistencies in smart contracts, finding 36 confirmed, fixed real-world bugs.
Document

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 --> G

Caveats

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