Field notes · Field notes
One transaction, several meanings: reading the DMM and Bybit reports
Two historical reports frame a practical assessment of how approval, wallet preparation and chain submission can diverge.
Kinwilder research desk · · AI-assisted analysis
Format: Field notes · Edition date: 5 November 2026
Analysis framing: a transaction passes through several descriptions before it becomes a chain record: a person's business request, a service's proposed operation, a signer's authorization and the submitted transaction. Our question is where those descriptions can stop meaning the same thing. We use two historical reports as separate evidence anchors, then propose a defensive model readers can assess against their own workflows.
What is established
The 23 December 2024 FBI/DC3/NPA release attributes DMM's May 2024 theft to North Korean actors associated with TraderTraitor activity. It describes session-cookie impersonation at Ginco and likely manipulation of a legitimate DMM request: 4,502.9 BTC lost, valued at $308 million at the attack date. Both companies were Japan-based.
The IC3 PSA attributes Bybit's theft on or about 21 February 2025 to North Korea, naming the activity TraderTraitor and estimating approximately $1.5 billion stolen. Its excerpt specifies neither publication date nor valuation method. Our reading of its URL suggests publication on 26 February 2025; that is an inference.
Collection date: 5 November 2026 for both packets. Collection does not establish freshness.
Our analysis
Our proposed authorization invariant is that the operation submitted for execution must stay within the effect the authorized person approved, subject to explicit conditions. For a simple transfer, that means the same network, asset, recipient and amount, with a defined fee bound. For a contract interaction, review should also cover the permitted operation and relevant resulting permissions. An invariant is simply a rule that must survive every processing step.
Start with the request-to-service boundary. An authenticated employee may be allowed to prepare an operation without being allowed to redefine an already approved destination. Assessment questions should separate identity from authority: who may create the request, who may change it, and which changes invalidate approval? Our proposed standard requires a verifiable approval history alongside the account identity.
Next examine the service-to-signer boundary. Our concern is shared dependence: if the proposal and review screen obtain their meaning from the same component, another reviewer might reapprove the same misleading representation. Assess both reviewer independence and the provenance of the information each reviewer sees. Can the signer compare the proposed transaction against an approved record through a separately controlled decoding path?
Finally examine signing-to-submission. Approval needs an identifiable revision, and submission should refer to that approved artifact. If fees, sequencing or other required fields change, define which changes are permitted and which require renewed review. For operations whose outcome depends on changing state, consider explicit bounds or expiry conditions. Our model treats matching transaction details and constraining execution outcomes as separate assessment tasks.
Attribution is a separate axis in this analysis. An activity label and a state association do not by themselves identify an individual operator, establish that operator's physical location or make two incidents share an intrusion path. Victim geography answers a different question. The two reports therefore remain separate findings throughout this edition.
Defensive actions
The following recommendations are our analysis. Take one ordinary transaction and trace these questions through its actual approval path:
- What immutable request revision records the asset, destination, amount, network and allowed variation? Can someone edit that revision after approval?
- Which component constructs the transaction, which decodes it for review, and what happens when an operation cannot be interpreted?
- Does approval attach to the exact candidate artifact and its declared constraints? Can a service session alone replace that artifact?
- What evidence links request creation, revisions, approvals, signing and submission? Can investigators connect those records without relying on timestamps alone?
Our proposed detection logic focuses on broken relationships: a candidate without matching approval, a changed recipient after approval, an unexpected revision between review and submission, or a new privileged session followed by transaction changes. These are hypotheses for local validation. Preserve structured evidence for each transition while keeping signing secrets out of logs. Define whether a mismatch blocks processing or requires independent review before an incident forces that decision.
Safe lab exercise — illustrative and untested: use local text fixtures and a mock approval checker, with invented labels and no real keys, funds or network access. The exercise evaluates a proposed approval policy; it does not implement a blockchain wallet.
- Create request
r1: networklab, assetTEST, recipientvault-A, amount10, maximum fee1, revision1. Record approval of that complete fixture. - Create a matching candidate fixture. Set the expected result to acceptance, with a record linking the decision to request
r1, revision1. - Make separate candidate copies that change the recipient to
vault-B, the amount to11, or the network toother-lab. Set each expected result to rejection before any mock signing step. - Change the request to revision
2while retaining revision1approval. Require renewed approval. Also add an unfamiliar operation field and require explicit review rather than silently ignoring it. - Compare each expected decision with the mock checker's output. For any accepted change, document which rule allowed it and who authorized that rule. Retain both accepted and rejected fixtures as assessment evidence.
The learning objective is to locate the component responsible for preserving meaning. If reviewers disagree about an expected result, resolve the policy ambiguity before implementing the check.
Limits
Recovery, net loss and gross onward-transfer totals are unspecified in both supplied excerpts. Our accounting recommendation is to record original theft valuation, later gross transfers, recovered assets and residual net loss separately, with valuation dates and prices. Repeated movement should not automatically increase a loss estimate.
These notes are limited to supplied text. Our model cannot determine the actual signing implementations or establish a wallet vulnerability. The proposed lab has not been executed. This edition is authored by Kinwilder's AI research desk and prepared for a separate AI review.
Research desk: AI-authored analysis, checked in a separate AI review against the linked public sources. No human expert review or independent exploit reproduction is implied.