AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 27 Monero

feat: migrate Trade data to SQLite with TradeLegacy for backward compatibility (#3106)

Public commit record

What the developer wrote

Authored by David Adegoke

93/100 · Strong
feat: migrate Trade data to SQLite with TradeLegacy for backward compatibility (#3106)

* feat: migrate Trade data to SQLite with TradeLegacy for backward compatibility

* feat: persist full currency snapshots in sql storage, not raw-only [WIP]

* feat: persist full trade currency snapshots in sql storage

* refactor trade and currency handling for migration

* Minor fixes

---------

Co-authored-by: Omar Hatem <omarh.ismail1@gmail.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit replaces the app's old storage system for swap/exchange records (called 'Trades') with a new SQLite database. It also adds a one-time migration that reads old records out of the encrypted Hive file and copies them into the new SQLite table. The change is a routine data-layer refactor with backward-compatibility logic. There is no direct evidence in the commit that this introduces theft of funds or private-key leaks, but any storage migration can carry risks of data loss, downgrade/replay issues, or subtle bugs if currency information is not preserved correctly.

Recommended action

Treat this as a high-touch migration change requiring QA, not as an active vulnerability. Verify that: (1) the legacy Hive migration runs exactly once and does not duplicate or overwrite trades; (2) the SQLite table is created with the same encryption/protection expectations as the legacy Hive box; (3) currency reconstruction from title/tag fallback does not misidentify assets; (4) the ConflictAlgorithm.replace behavior on 'id' cannot be abused to corrupt another user's trade record; (5) backup/restore logic correctly handles both legacy and new trade formats. No immediate patch for a security flaw is evident from the diff alone.

Security signals we found

01

Storage migration from encrypted Hive to SQLite for sensitive trade metadata

02

New SQLite table stores trade details including input/output addresses, refund addresses, payout addresses, memos, txIds, amounts, and provider identifiers

03

Migration code catches and logs per-record errors but continues migration, which could leave some records unconverted

04

SQLite save() uses ConflictAlgorithm.replace on the 'id' column, so duplicate trade IDs will overwrite existing rows

05

Legacy encrypted Hive box is opened with the same encryption key during migration

06

Currency reconstruction now relies on stored title/tag fallback when raw id deserialization fails

07

No parameterized query issues visible; queries use sqflite's whereArgs binding

Risk score

Why this scored 27/100

Our methodology →
Potential impact 5/30
Exploitability 4/25
Stealth signal 3/15
Affected reach 6/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.