I have always believed that helping people means more than handing them access. It means giving them understanding. In crypto, I kept seeing the same pattern, over and over: people had the data, but not the clarity. Their accounts were drained. Their tokens were manipulated. Their trades were pushed into markets that looked alive on the surface but were hollow underneath. And when it happened, they had almost nowhere to turn — the evidence of what happened to them was sitting in public, on the ledger, the entire time. Nobody had translated it for them.
That is the wound NaluLF was built to close. Not by hiding the complexity, but by doing the hard part — the math, the pattern recognition, the cross-checking against alternative explanations — so a person who has never heard of Benford's Law or a Herfindahl-Hirschman Index can still ask an honest question about an XRPL address and get an honest, well-reasoned answer back.
What started as a wallet became something larger, on purpose. Today NaluLF carries a full forensic engine underneath it: a five-engine analytics suite that studies an account's numbers, its randomness, its counterparty structure, and its timing from five independent mathematical angles at once; a wash-trading model that no longer collapses everything into one blurry score but separately scores execution, spoofing, and automation, because those are three different questions with three different answers; a rebuilt drain-risk accounting layer that finally tells the difference between money that passed through an account and money that was actually taken from it — a distinction that matters enormously to the person reading the report. Every one of those findings now carries its own evidence trail: what was directly observed on the ledger, what was calculated from that observation, what was inferred by comparing it to the account's own history, and — only when it's genuinely warranted, and always labeled as such — what remains an unproven hypothesis. I did not want to build a system that hands someone a scary number with no way to see how it was reached. I wanted to build one that shows its work.
None of this replaces judgment. NaluLF does not accuse anyone of anything — it surfaces convergent evidence and lets the person holding it decide what to do next. That distinction matters to me. A tool that overclaims certainty is just a different kind of misinformation. A tool that hides its uncertainty is worse. I would rather ship something that says "this is 62% confidence, here is exactly why" than something that says "DANGER" and offers nothing behind it.
Sovereignty is not just holding your own keys. It is holding your own understanding. NaluLF exists so that security intelligence — the kind that used to live behind institutional terminals and paid forensic desks — lives instead in a browser, under the user's own control, running the same analysis for a first-time holder that it runs for anyone else. No account required. No data leaves the device except the public ledger queries the ledger was already designed to answer. That was true on day one, and it is still true now that there is a great deal more happening underneath the surface.
This is still early. There is more I want this platform to do — private infrastructure, deeper historical replay, bounded automation that never touches a key without explicit, narrow permission. But the foundation is the part I care about getting right first: honest evidence, explainable reasoning, and a wallet that never separates the person from the truth about what they're holding.
The Problem — Manipulation, Drain Attacks & Invisible Risk
The XRP Ledger is radically transparent. That is one of its greatest strengths. It is also why the harm that occurs on it is so often misunderstood: the evidence is public, but the meaning is not obvious. Public data is not the same thing as public understanding.
On-chain harm tends to emerge through recognizable categories. Some are direct account compromises: signing authority is altered, a victim does not realize it, and the wallet is drained later — or, just as often, money simply passes through the account and nothing was actually lost, which looks identical to a drain unless the accounting distinguishes the two. Others are market-structure attacks: fake volume, self-trading, and coordinated activity create the appearance of demand where little or none actually exists. Recent SEC actions described schemes intended to induce investors by creating the false appearance of an active trading market, while DOJ actions in 2025 described crypto wash-trading and market-manipulation services sold to token issuers.
The Four Categories of Harm
The Mission — Sovereignty Through Understanding
NaluLF is built around a simple premise: the ledger already contains the truth, but truth without interpretation is inaccessible to most people. The platform exists to close that gap — turning account state, transaction history, market structure, and behavioral patterns into security intelligence that ordinary participants can actually use, with every conclusion traceable back to the ledger facts that produced it.
The wallet is therefore not the end goal. It is the delivery vehicle. NaluLF is not merely a place to hold assets; it is an interface for understanding the security reality of those assets, the counterparties around them, and the markets they move through.
The Evidence Model — Observed → Calculated → Inferred → Hypothesis
Every finding NaluLF produces — across all 23 inspector modules — is built on the same underlying discipline: separate what the ledger directly shows from what has to be derived, inferred, or merely hypothesized about it. A single blended "risk score" with no visible reasoning behind it is not evidence. It is an opinion wearing a number. NaluLF instead structures every finding into four explicit epistemic tiers, so a reader can see exactly how far the system's reasoning traveled from raw ledger fact to conclusion.
Findings also carry alternative explanations and evidence against the flagged interpretation wherever one exists, plus a classification caveat that separates the described behavior from any claim about intent. Severity and confidence are tracked as two independent numbers, not one — a finding can be severe if true but low-confidence given incomplete history, or high-confidence but low-severity because the underlying behavior is minor. The screenshot below is a live rendering from the Evidence Inspector (Section 10), opened on a real drain-risk finding — not a mockup:
Benford's Law Fraud Detection
P(d) = log₁₀(1 + 1/d) for d = 1..9 Expected leading-digit distribution: 1 → 30.1% 4 → 9.7% 7 → 5.8% 2 → 17.6% 5 → 7.9% 8 → 5.1% 3 → 12.5% 6 → 6.7% 9 → 4.6%
Naturally occurring financial datasets — transaction amounts pulled from a genuine economic process — tend to follow Benford's Law: smaller leading digits appear far more often than larger ones. Fabricated, rounded, or mechanically generated numbers routinely violate this distribution, which is why the technique has a long history in forensic accounting and fraud examination.
NaluLF applies this to an account's transaction-amount history, but only after an applicability gate: before any deviation is scored, the module checks whether the sample is large enough and varied enough for a Benford comparison to be meaningful in the first place. A thin or narrow-range sample never gets scored as if it were a confident Benford violation — it is labeled as inapplicable instead of silently producing a misleading number.
Real-World Use
| Result | Interpretation |
|---|---|
| Sample too small / applicability gate not met | Not scored — shown as inapplicable, not as a clean bill of health |
| Mild deviation | Weak signal on its own; considered alongside the other four suite engines |
| Moderate deviation | Elevated signal; contributes to the Market Integrity category |
| Strong deviation | High-confidence anomaly; a leading contributor to a suite-wide convergence verdict |
The Five-Engine Forensic Analytics Suite
The NaluLF forensic suite is built around convergence. One signal can be noise. Two can be suggestive. Three or more independent signals pointing in the same direction become materially harder to dismiss as coincidence.
Each engine in the suite uses a different mathematical lens. That is the point. NaluLF does not want five versions of the same detector. It wants five different ways of interrogating whether an account's behavior looks organic, constrained, scripted, or structurally manipulated.
Why This Matters
Wash Trading Intelligence
Earlier versions of this analysis blended everything into one composite wash-trading score. That flattened three genuinely different questions into one number: is this account round-tripping value back to itself, is it placing and pulling orders without intending to fill them, and is it trading with mechanical, script-like regularity. NaluLF now scores these as three independent dimensions, each with its own evidence:
Round-Trip Quality Model (Wash Execution)
Rather than flagging a round-trip the moment a payment recipient is also found among senders, NaluLF pairs each outbound payment to a counterparty with the next unmatched inbound payment from that same counterparty (first-in, first-out), then scores every such relationship on three independent signals combined into a single quality score:
Round-Trip Quality Model
For each outbound payment to a counterparty:
match → next unmatched inbound FROM that counterparty (FIFO)
Score three independent signals per relationship:
Occurrence → how many round-trips were found
Similarity → 1 − |sent − returned| / sent
Turnaround → how quickly the funds came back
qualityScore = weighted combination of the three signals
Reported: the single strongest relationship found
e.g. "6 round-trip(s), 91% amount match, 14 min median turnaround"
Weak signal : 1 round-trip, 80 days apart → qualityScore ≈ 0.10
Strong signal : 47 round-trips, 99.7% amount similarity,
near-instant turnaround → qualityScore ≈ 0.99
The underlying behavioral signals that feed all three dimensions remain the ones an experienced market observer would look for:
Spoofing: A Multi-Signal Corroboration Model
Spoofing detection is built around the same corroboration principle as the five-engine suite: never let a single weak signal alone produce a high-confidence conclusion. Four independent evidence families are checked — layering- like behavior (several of an account's own offers resting simultaneously at different price levels), opposite-side execution during a displayed order's own window, AMM activity occurring while a CLOB order sits on display, and whether the account currently holds or is authorized for a discounted-fee auction slot in the same currency (context only — never scored on its own, since a discounted fee makes cycling more economically viable without being evidence of intent by itself). Confidence and severity scale with how many of these independently-derived families actually fire together, and the finding names exactly which ones did.
Why This Matters
Drain Risk Classification
tecNO_ALTERNATIVE_KEY governs the safety rail around this). NaluLF's drain-risk logic treats
this as context, not as a standalone finding.
Earlier accounting for this module computed a single number — outflow within a sliding window, divided by the balance at the start of that window — with no floor or ceiling. A wallet with a small opening balance that simply received and forwarded a large sum within a window could mathematically show outflow figures exceeding 100% of its balance, reading as an impossible, alarming "drain" when no real wealth was ever lost. The accounting has since been rebuilt around two deliberately different, clearly labeled metrics:
| Metric | Bounded? | What It Describes |
|---|---|---|
| Gross Turnover % | Unbounded by design | Total outflow relative to opening balance — describes volume moved, can legitimately exceed 100% for a high-turnover account |
| Actual Depletion % | Bounded to [0, 100%] | Opening balance vs. closing balance — describes real, measured loss, and by construction can never overstate it |
Every drain episode also tracks gross outflow, gross inflow, and net outflow as three distinct numbers (rather than inflow being silently ignored), and is run through a classification step:
| Classification | Signature | Interpretation |
|---|---|---|
| Sweep | Net outflow ≈ gross outflow; inflow negligible | Funds are genuinely leaving the account |
| Potential Drain | High actual depletion between opening and closing balance | The balance measurably dropped by the end of the window |
| Partial Outflow | Moderate, ambiguous signal | Some funds left; the picture isn't clear-cut either way |
| Pass-Through | Gross inflow ≈ gross outflow; net outflow and actual depletion both small | Funds moved through the account, not out of it — high turnover is not the same as loss |
Pass-through episodes are capped at informational severity regardless of how large the gross turnover figure looks, and never contribute to the module's aggregate severity score. Confidence is also reduced whenever an episode's underlying transaction history is known to be incomplete, with that reduction shown explicitly rather than silently folded into the number. In production verification against a real high-volume exchange hot wallet, two genuine pass-through episodes rendered as "Gross turnover: 195% / 322% of opening balance" alongside "Actual balance depletion: 0.0%" — correctly classified pass-through, informational severity, confidence reduced to 30% with an explicit note explaining why.
Balance Reconstruction Chart
Drain Risk findings are no longer text-only. The module reconstructs the account's balance over time from ledger history and renders it as a chart, with each detected episode's time window shaded behind the line and colored by its classification — so a sweep, a pass-through, and a potential drain are visually distinct at a glance, not just described in a paragraph underneath.
Merged With Fund Flow: "Is My Account Draining?" and "Where Did It Go?" in One Place
Drain Risk and the Fund Flow Tracer used to be two separate sections, which meant answering "did money leave abnormally?" and "if so, where did it actually go?" required reading two different parts of the page and manually connecting them. They are now one combined section. Concretely, this added three things that were previously either missing entirely or buried in text:
The section also carries one shared, beginner-facing "In plain terms" summary covering both halves — replacing what used to be two separate summaries that, once the sections were visually combined, read as redundant. A Simple / Advanced toggle (present throughout the inspector) keeps the full per-episode evidence and the raw payment-by-payment timeline available one click away, without requiring a first-time reader to parse them before reaching a plain-English answer.
Volume Concentration & Market Structure
A token can show impressive trading volume that is, in reality, produced by a small handful of actors trading with each other. NaluLF measures this directly using two standard concentration statistics — the Herfindahl-Hirschman Index (HHI) and the Gini coefficient — applied to trading-volume share per actor cluster on a given currency pair.
| HHI Range | Interpretation |
|---|---|
| < 1,500 | Competitive — volume spread across many independent actors |
| 1,500 – 2,500 | Moderately concentrated |
| > 2,500 | Highly concentrated — a small number of actors dominate volume |
Concentration alone can be misleading on a small sample — nine trades between two accounts will always show extreme HHI, regardless of what's really happening. NaluLF gates severity on trade count: below roughly fifty trades on a pair, severity is capped one level down (critical→warning, warning→info) no matter how extreme the HHI reads, with an explicit note stating the cap and why. A well-sampled market showing the same extreme concentration is allowed to reach full severity. The module also distinguishes raw distinct-address counts from estimated actor clusters, since a single actor operating multiple addresses can otherwise look like healthy diversity.
Results render as a horizontal, per-cluster share bar rather than a raw table, with currency codes properly decoded from their ledger hex representation to their human-readable symbol before display — a market's volume breakdown is shown by name, not as an unreadable 40-character hex string.
The Account Inspector — 23 Modules
The inspector is NaluLF's main investigative surface. Any XRPL address can be examined — not only the user's own wallets. Each module contributes a distinct slice of intelligence: configuration posture, economic structure, behavioral anomalies, trustline context, issuer dynamics, flow tracing, and synthesized reporting.
Inspector Output Philosophy
Flow Intelligence — Narrative Layers Above the Module Data
Every module above answers a technical question correctly, but a technical answer is not automatically a readable one. Flow Intelligence is a set of narrative layers that sit above the same underlying data — synthesizing it into plain English for a first-time reader — without duplicating or re-scoring anything the modules have already computed. None of the following introduce new findings, new severity levels, or new confidence numbers; they are composition, not analysis.
Evidence Matrix & Evidence Inspector
With 23 modules each capable of producing multiple findings, a single account can generate a substantial amount of evidence. The Evidence Matrix is the aggregate view across all of it: every finding from every module in one sortable, filterable table — Finding, Category, Severity, Confidence, and Evidence Strength as five independent columns, not one blended score.
Filters narrow the table by severity or by category, each showing a live count (e.g. "Critical 5", "Warning 15"). Clicking any row opens the Evidence Inspector — a focused, single-finding view showing the full Observed / Calculated / Inferred / Hypothesis breakdown from Section 03, along with alternative explanations, evidence against the flagged interpretation, and the classification caveat, all for that one finding.
Evidence Pyramid
Sitting above the table, the Evidence Pyramid answers a narrower, more immediately useful question than the full matrix: out of everything this inspection found, how much of it is actually reliable? It buckets every finding into the same Strong / Moderate / Weak tiers the matrix already computes per row — no new scoring logic — and stacks them into three bands. The bands are deliberately drawn at a fixed visual width rather than scaled to the real count, because a literal count-proportional pyramid can render upside down: a genuinely well-evidenced account often has more strong findings than weak ones, and a shape that inverts itself case by case would undermine the "less-but- more-decisive at the top" metaphor it exists to convey. The real counts are always shown as numbers regardless of band width.
Risk Scoring — The Category Evidence Model
Every inspection produces a category-scored verdict rather than one opaque composite number. Findings are grouped into seven independent risk categories, each scored by weighting a finding's severity against its confidence — a severe-but-low-confidence finding does not dominate the same way a severe-and-well-evidenced one does.
| Category | Fed Primarily By | What It Measures |
|---|---|---|
| Security Risk | Security, Drain Risk, NFT | Configuration and compromise-oriented risk |
| Market Integrity Risk | Wash Trading, Benford's, Offer/Flow Coupling, Volume Concentration | Manipulated or fabricated market behavior |
| Counterparty Risk | Fund Flow, Inbound Flow | Who this account interacts with, and how |
| Issuer Risk | Token Issuer, Issuer Connections | Structural control an issuer holds over a token |
| Liquidity Risk | AMM / Liquidity | Pool concentration and real exit-liquidity risk |
| Automation Probability | Wash Trading (automation dimension), Time-Series | Likelihood behavior is scripted — a probability, not an accusation |
| External Exposure | Inbound Memo Analysis | Targeting directed at this account (e.g. phishing memos) — kept separate so being targeted can never inflate the account's own behavioral score |
Project Intelligence & the Intelligence Graph
The Account Inspector answers "is this address behaving safely?" Project Intelligence asks a different question, at a different level: given a token's symbol and issuer, is this project structurally sound? It computes AMM liquidity state (reserves, fee rate, LP supply, auction slot, fee votes), issuer risk flags (freeze, clawback, require-auth, blackhole state), and holder concentration (top-1 / top-5 / top-10 share of supply) — then combines them into a composite Project Strength score where every sub-score carries its own raw inputs, so the reasoning is never hidden behind the final number.
Privacy Architecture — Zero Server, Zero Identity Surface
The security intelligence in NaluLF only matters if the platform itself does not become a new source of user exposure. For that reason, the architecture is local-first and intentionally minimal in what it sends anywhere at all.
| Data Type | Stored Where | Encrypted | Transmitted To |
|---|---|---|---|
| Seeds / private keys | Local device only | AES-256-GCM | Never |
| Profile / identity metadata | Local device only | Yes | Never |
| Inspection history | Local device only | Optional / local-only | Never |
| Public XRPL addresses | Local + public ledger | N/A | XRPL endpoints |
| Market / NFT content fetches | Transient or local cache | N/A | Public APIs / gateways |
Cryptographic Vault Design
NaluLF uses browser-native cryptography to keep sensitive wallet material encrypted locally. The design goal is straightforward: ciphertext at rest, keys derived in-browser, and no server-side custody path.
Key Derivation Pipeline User Password ↓ PBKDF2-HMAC-SHA256 + unique random salt + high iteration count ↓ AES-GCM 256-bit key ↓ Encrypt vault payload with fresh IV ↓ Persist ciphertext locally
XRPL Integration
NaluLF connects directly to XRPL infrastructure over WebSocket and rotates across public endpoints for resilience. The architecture is designed so the application can inspect and reason about ledger state without requiring a proprietary relay layer.
Endpoint Priority Chain wss://s1.ripple.com wss://s2.ripple.com wss://xrplcluster.com wss://xrpl.ws Reconnect: exponential backoff Modes: Mainnet · Testnet · Xahau
Wallet — The Delivery Vehicle for Security Intelligence
The wallet layer exists so that intelligence and action remain connected. There is little value in discovering a risky configuration if the user must then leave the environment that detected it to perform remediation somewhere else.
Reserve Mechanics
XRPL reserve mechanics are a fundamental part of user experience and account interpretation. They affect what is spendable, what remains locked, and how owned objects constrain available XRP.
Reserve = Base Reserve + (Owner Count × Owner Reserve) Current Mainnet Reference: Base Reserve = 1 XRP Owner Reserve = 0.2 XRP per owned ledger object Spendable XRP = Balance − Reserve
Important Precision
Reserve is consumed by owned ledger objects — not by labels alone.
Trustlines, offers, and other objects each contribute to owner count.
For NFTs, the effect is mediated through NFT-related ledger objects such as NFTokenPage structures,
not simply "one NFT equals one full reserve increment."
Roadmap — Infrastructure, Bounded Automation & Scaling
Everything in this section is forward-looking. It is included for transparency about direction, not as a claim about what NaluLF does today — the rest of this paper describes the shipped, verified platform; this section does not.
Node Infrastructure
Public XRPL endpoints are sufficient for the current platform, but long-horizon scaling benefits from private infrastructure: lower latency, deeper historical access, and stronger support for high-volume inspection.
NaluLF Node Layer (planned) ├── rippled full-history node ├── private WebSocket endpoint ├── analytics bridge ├── subscription manager ├── webhook / alert delivery └── historical replay services
Bounded Automation
The same analytical substrate that powers today's forensic tooling could eventually support guided automation — alerts, portfolio intelligence, and narrowly scoped, permissioned actions. Any such capability would be built on three non-negotiable constraints:
Scaling Tiers
Threat Model & Mitigations
| Threat | Likelihood | Mitigation |
|---|---|---|
| Browser extension reads local storage | Medium | Ciphertext only; secret material remains encrypted at rest |
| Physical access while vault is locked | Low | No decrypted key material available |
| Physical access while vault is unlocked | Medium | Auto-lock posture + OS-level device lock discipline |
| Malicious XRPL endpoint response | Low | Can degrade availability or perspective, but not forge user-held signing authority |
| Offline brute force against ciphertext | Very Low | KDF + salt + local-only encrypted storage design |
| Keylogger / compromised host OS | High | Outside browser-only mitigation scope; requires host-level security |
| Single-signal false positive | Medium | Evidence model (Section 03) separates observed fact from inference/hypothesis; suite convergence (Section 05) requires multiple independent engines to agree before treating a signal as strong |
| Small-sample statistical overreach | Medium | Applicability gates (Benford) and sample-size severity caps (Volume Concentration) prevent thin data from reading as confident evidence |