The primary limitation is not browser performance.
It is that mixer and peel-chain analysis cannot be treated as ordinary path tracing.
A transaction graph can show where value moved. It does not, by itself, establish which entity controlled each node, whether two transfers belong to the same economic flow, or whether an observed route is the only plausible route. Once a mixer, bridge, exchange, router, pooled contract, or batching system enters the path, the problem changes from graph traversal into constrained state reconstruction under incomplete observation.
That distinction should define the architecture of ChainTrace before scaling is considered.
- Separate observable facts from inferred routes
The system should maintain four different layers:
Observed ledger facts
block and transaction identity;
sender, recipient, value, token, call and event data;
trace position;
success or failure;
chain and finality state;
contract code and role where known.
Candidate flow hypotheses
possible continuations of value;
possible entry/exit relationships;
possible peel-chain continuations;
possible cross-chain continuations;
alternative explanations that remain consistent with the same observations.
Control attribution
evidence that multiple addresses are operated by one entity;
evidence that an address is infrastructure rather than an operator;
confidence and counter-evidence;
whether the conclusion is incident-specific or persistent.
Operational response
warn;
request enhanced review;
monitor;
freeze a case for investigation;
take no action.
These layers must not be collapsed into one risk score.
A transaction is a fact. A route is an inference. Common control is a stronger inference. An enforcement decision is a policy choice. If those objects are merged, the UI will look decisive while concealing where the uncertainty actually entered.
- A mixer does not create a single traceable path
A mixer hop is not an ordinary edge between one deposit and one withdrawal.
It is a many-to-many transformation that may include:
multiple deposits;
multiple withdrawals;
fixed or variable denominations;
relayers;
fees;
delayed withdrawal;
partial withdrawal;
repeated re-entry;
change flows;
cross-chain continuation;
unrelated users sharing the same anonymity set.
The correct output is therefore not:
Deposit A -> Mixer -> Withdrawal B
unless the evidence actually proves that relationship.
The correct output is a bounded hypothesis set:
Deposit A
-> candidate exit set {B, C, D, ...}
-> each candidate supported by explicit constraints
-> each candidate weakened by explicit contradictions
Every proposed entry/exit relationship should identify which constraints support it:
amount compatibility;
denomination compatibility;
fee compatibility;
temporal interval;
anonymity-set membership;
relayer behavior;
pre-entry funding;
post-exit continuation;
common beneficiary;
repeated pattern across independent incidents;
cross-chain message continuity.
The system should also show what remains unresolved.
A mixer does not erase the route, but it changes the plane on which the route must be reconstructed. The reconstruction is only defensible when the system preserves all compatible alternatives until additional evidence removes them.
3. “Peel chain” requires chain-specific semantics
The term originates naturally in UTXO systems, where each transaction can spend an input, forward a remainder, and peel a smaller amount to another output.
An account-based chain behaves differently.
On Ethereum and Arbitrum:
balances are account state, not discrete UTXOs;
one account can receive and spend through many unrelated flows;
gas changes the value relationship;
internal calls can move value without a top-level transfer;
ERC-20 transfers are event/state transitions, not native outputs;
routers, proxies and contracts can aggregate many users;
transaction ordering and nonce are informative but not sufficient;
a contract can emit an apparent chain while acting for unrelated callers.
A valid detector therefore cannot apply one generic “decreasing amount” rule across Bitcoin, Ethereum, Arbitrum, Solana and Tron.
It needs a chain-specific transition model.
For an account-based peel hypothesis, the system should prove a repeated structural relationship such as:
a persistent controller or tightly bounded controller set;
repeated forwarding after receipt;
value conservation within explicit gas/fee bounds;
repeated retention and onward-transfer proportions;
compatible timing;
compatible transaction role;
no shared-infrastructure explanation;
continuity across contract calls and internal traces.
Without these conditions, a descending sequence of transfers is only a visual pattern.
4. Replace a dynamic score with an explainable evidence vector
A single score such as 82/100 is not sufficient for an auditor.
Two cases can receive the same score for completely different reasons:
direct reward consolidation;
weak mixer timing similarity;
repeated common funding;
contact with a flagged exchange;
one shared router;
a high transaction velocity.
Those cases do not carry the same evidential meaning and should not trigger the same response.
The analytical output should expose independent dimensions, for example:
path continuity;
value conservation;
temporal continuity;
common-control evidence;
infrastructure ambiguity;
mixer-set ambiguity;
cross-chain continuity;
beneficiary convergence;
label provenance;
source completeness;
counter-evidence;
unresolved alternatives.
A compact operational class can still be produced, but it must be derived from a versioned evidence policy and accompanied by reason codes.
The user should be able to answer:
Which observations caused this conclusion?
Which inference connected those observations?
What alternative explanation remains possible?
Which missing data could reverse the conclusion?
Which policy version converted the evidence into this risk state?
If those questions cannot be answered, the score is not auditable.
5. Browser-only scaling fails first on evidence completeness, not computation
A browser can render a graph and run a local simulation well.
It should not be treated as the authoritative acquisition and forensic layer for full on-chain monitoring.
The principal problems are:
incomplete pagination;
provider-specific trace coverage;
missing historical state;
rate limits;
inconsistent decoded events;
mutable third-party labels;
chain reorganization;
L2 finality differences;
missing failed calls;
disagreement between transaction, trace and event views;
unavailable archive data;
browser memory limits;
non-reproducible API responses;
hidden changes in upstream provider schemas.
A browser result can therefore be internally consistent while being based on an incomplete evidence plane.
The production architecture should separate:
Acquisition plane
Collects exact blocks, transactions, traces, logs, token transfers, bridge messages and source receipts.
Canonicalization plane
Normalizes chain-specific records into typed, versioned facts without discarding original identities.
Reconstruction plane
Builds candidate value routes, control hypotheses and cross-chain continuations.
Validation plane
Tests hypotheses against independent evidence and negative controls.
Presentation plane
Displays the result in the browser.
The browser should be the presentation and investigation interface, not the source of truth.
6. Every case needs a frozen evidence envelope
A professional auditor must be able to reproduce the same result later.
Each analysis should therefore bind:
chain IDs;
exact block boundaries;
finality state;
source providers;
query or export versions;
original object hashes;
normalization version;
label version and timestamp;
analytical-policy version;
input manifest;
output manifest.
The case should be immutable after creation. New evidence should create a new version, not silently rewrite the old result.
This is especially important for a War Room. During an incident, data providers update, labels change and a chain may still be reorganizing. The operator needs to know whether the screen represents:
provisional live evidence;
a finalized block range;
a partial trace set;
a complete archived case;
a later revised assessment.
Without that distinction, “real time” becomes visually impressive but forensically unstable.
7. Cross-chain continuation must be modeled as a state transition
A bridge is not an ordinary graph edge.
The system must distinguish:
deposit transaction;
canonical message or message hash;
source-chain finality;
relay or proof;
destination-chain execution;
destination recipient;
failure, retry or refund;
third-party liquidity provider;
canonical bridge versus external bridge.
A source-chain address and a destination-chain address should not be linked merely because amounts and times look similar.
The link should be anchored in the bridge’s actual message semantics where available. Where no canonical message relationship exists, the system should expose a candidate continuation with explicit uncertainty.
This same principle applies to mixers: the link must be carried through the mechanism’s true state transition, not inferred from visual proximity alone.
8. Infrastructure must act as a typed boundary
Public infrastructure is the main source of false attribution.
The graph must type and bound:
exchanges;
pooled deposit addresses;
routers;
bridges;
mixers;
relayers;
batch processors;
multisigs;
liquidity pools;
token contracts;
public faucets;
protocol treasury contracts.
A risk state should not propagate through those nodes as if every edge represented ownership.
For example:
two users sending to the same exchange do not become one entity;
two users calling the same router do not become one cluster;
two withdrawals using the same relayer do not prove common control;
a bridge contract receiving illicit funds is not itself the beneficiary;
a mixer contract is not the operator of every depositor and withdrawer.
Propagation should follow evidence of control or constrained economic continuity, not mere adjacency.
9. The War Room UI should show uncertainty, not hide it
The current visual direction is useful for orientation, but a professional incident interface needs more than a highlighted “risk path”.
For every selected route, the auditor should see:
observed facts in one visual language;
inferred edges in another;
alternative compatible routes;
evidence supporting each inference;
contradictions;
source and freshness;
exact block boundary;
missing coverage;
infrastructure boundaries;
confidence decomposition;
first and last supporting observation;
whether the route is provisional, supported, contested or closed.
The UI should also support:
time-plane switching;
value-plane switching;
chain-plane switching;
role-based filtering;
hiding shared infrastructure;
comparison of two competing hypotheses;
exporting the exact evidence package behind one conclusion;
replaying the case from the frozen manifest.
The objective is not to make the graph look certain. The objective is to make every certainty and uncertainty inspectable.
10. The first serious benchmark should be adversarial
Before scaling to live monitoring, ChainTrace should be evaluated against a frozen corpus containing:
confirmed peel chains;
ordinary treasury distributions that resemble peel chains;
exchange withdrawals;
router-mediated transfers;
mixer entry/exit cases with known control evidence;
mixer cases with multiple equally plausible exits;
bridge continuations;
failed bridge messages;
relayer-funded transactions;
contract wallets;
dust poisoning;
deliberate false-link construction;
independent users sharing infrastructure;
repeated common-beneficiary consolidation;
incomplete trace coverage;
reorganization and finality edge cases.
The benchmark should measure:
unsupported attribution rate;
route-completeness rate;
false propagation through infrastructure;
candidate-set calibration;
stability under missing evidence;
cross-provider reproducibility;
deterministic replay;
reviewer agreement;
time to first provisional result;
time to evidence-supported conclusion.
A detector that finds many suspicious paths but cannot preserve alternatives or bound false propagation is not yet suitable for professional AML use.
11. The strongest ecosystem role is evidence infrastructure, not a blacklist
For Arbitrum, the most useful role would be an incident-evidence layer capable of serving:
protocol security teams;
bridge operators;
DAO treasury operations;
wallet providers;
exchanges;
compliance teams;
forensic investigators;
incident-response rooms.
Its output should not be “this wallet is bad”.
Its output should be:
this incident;
this frozen evidence;
these typed roles;
these candidate continuations;
these supported control relationships;
these unresolved alternatives;
this versioned operational assessment.
That allows every downstream consumer to apply its own policy without losing the evidence structure.
Recommended next architecture
Before expanding the number of chains or API providers, define five objects precisely:
Ledger Fact
Typed Mechanism Transition
Candidate Route
Control Attribution
Operational Decision
Then define:
the allowed transitions between them;
the evidence required for each transition;
the confidence-loss rule across every inferred edge;
the infrastructure boundaries that stop propagation;
the versioning and replay model;
the adversarial acceptance corpus.
Once those foundations are fixed, browser scaling becomes an engineering problem.
Without them, scaling only produces a larger graph whose strongest-looking path may still be the wrong one.
The key design principle is:
A mixer or peel chain should not be “followed” as if the route remained visible. It should be reconstructed as a set of constrained state transitions, with every surviving alternative and every attribution boundary preserved until the evidence resolves them.
