One case should not
start from zero.
When the same group of wallets turns up again, CaseRecall brings back what you found last time: the facts, where they came from, what you ruled out, and who signed off. Nothing digs further until a person approves it, and the system never reaches a conclusion of its own.
Where it sits. Alongside your tracing and case-management tools, not in place of them. It holds the record between cases so the next analyst can pick it up.
Context gets rebuilt from scattered tools.
When the same wallets come back, someone has to rebuild the earlier work from explorers, spreadsheets, screenshots, tickets, and whatever one analyst still remembers. It is slow, and the most useful parts go missing first: what you already searched, what you already ruled out, and who approved it.
What gets lost
- Dead ends and negative findings
- How far the earlier search actually reached
- Who approved which step, and why
- Whether a number was really zero or just missing
What CaseRecall keeps
- One thread, every time the group comes back
- What each finding covers and where it came from
- A permanent record of who approved what
- Missing data marked as missing, never as zero
Recall the record.
Bound the next question.
Start from one public event
Bring in a single approved onchain event, keeping a record of where every detail came from.
Recognize the group
If the same set of wallets has appeared before, the event joins their existing thread.
Look at what is actually there
Raw numbers, what they were measured against, what is missing, and the ordinary explanations worth ruling out.
Approve the next question
You decide exactly what gets investigated: which wallets, which time window, how far out, and how much.
Keep what you found
Findings, dead ends, open questions, why the search stopped, and your decision all stay on the thread.
Coming back is deliberately quiet. If the group reappears and something about it has changed, the old thread returns to your review queue. It does not start searching, spend anything, or score the case. It just tells you there is something new to look at.
Every claim carries its own limits.
A finding is more than a line in a report. Each one records what was seen, how it was worked out, how far the search went, what was missing, and which conclusions it cannot support. Open any of them below.
Why this resurfaced
The same three wallets showed up again, and something about them had changed. The old thread came back for review. Nothing was investigated automatically.
- Seen
- The same three wallets, matched under the recurrence rule published with this thread.
- Scope
- 3 wallets · one time window · no hops out
- How
- A result of the matching method, not something the chain itself states.
- Prohibited
- Says nothing about who they are, whether one person runs them, or whether they acted together.
- Seen
- Two transactions inside the time window shown.
- Provenance
- signature · slot · source pointer · receipt hash
- Count
- Two matching transfers, using a transfer definition fixed at the time of the search.
- Prohibited
- Two transfers are not a relationship, and nothing here implies intent.
- Seen
- All three received funds from the same place, within the range that was approved.
- How far
- one hop back · approved sources only
- Other reads
- A shared exchange, a common service, or ordinary infrastructure explains this just as well.
- Prohibited
- Not evidence of ownership, control, coordination, or intent.
- Searched
- Every pair of the three wallets, direct transfers only, inside one time window.
- How far
- 3 wallets · one hop · approved sources
- Result
- A real zero inside that window. The data was there, and there was nothing to find.
- Prohibited
- Says nothing about anything outside what was searched.
- Question
- Check direct transfers and recent history for the three wallets.
- Limits
- one time window · one hop
- Receipt
- who approved · thread version · exact request · single-use token
- Left as
- Open. Keep watching in case the group appears again.
Tap a claim to open its record
If there was nothing to measure against, you get a blank rather than a zero. When data is missing or a question is out of scope, the search stops and says so. It never widens the net or fills the gap with a guess.
Evidence stays separate from interpretation.
What the chain proves, what a data provider reports, what public sources add, and what an analyst concludes are stored as four separate things. A narrow piece of evidence cannot quietly become a broad claim, and outside research can never be used to strengthen an onchain finding.
The system will not
- Put a name to a wallet
- Decide who owns or controls anything
- Produce a risk score or call anyone suspicious
- Escalate, widen a search, or share anything on its own
- Make a compliance, sanctions, or fraud decision
It does not replace
- Tracing and transaction-monitoring platforms
- AML screening and sanctions review
- Case management, identity, or access control systems
- Human judgment, or anyone accountable for the call
A working prototype, honestly scoped.
The memory and evidence side does not care what kind of event it is reading. It works on events once they have been put into a common format. The one live connector so far reads Solana token launches, and funding, creator, and transaction-structure work has been run against saved data rather than live feeds. Building the next connector is the immediate work, and a pilot is how we decide which one.
In one test run on data nobody had looked at first, forty wallet observations produced a single three-wallet thread and a full profile. After a separate approval, the search made six requests, saved six pieces of evidence, and stopped when it reached the limit it had been given. That shows the workflow runs end to end. It says nothing yet about whether the results are useful, and one case is far too small to draw conclusions from.
Demonstrated
- The same group always lands on the same thread
- Missing data kept separate from a real zero
- A person approves every deeper search
- Evidence, receipts, and decisions are tamper-evident
- History stays put, and changes bring a thread back
Not yet established
- That it saves time or improves findings
- Handling private exchange data
- Production hosting, sign-on, permissions, retention
- Other chains, or Solana beyond token launches
Teams that meet the same actors more than once.
It earns its place where the same names come back and the record has to survive being handed to someone else.
Exchange investigations
Get the earlier onchain work back when a group returns, and hand the same history to whoever reviews it next.
Compliance operations
See who approved each step, which sources backed it up, and what could not be checked.
Risk and threat intelligence
Watch how a group changes over time without a black-box score or an automatic escalation.
Forensics and security
Keep findings you can reproduce, sourced properly, alongside the tracing tools you already use.
One case sequence.
Two review points.
Bring one public Solana case with two events that happened at different times. Settle what you are measuring before anyone looks at anything, then compare the second review against what your current process would have had to rebuild. No private data needed.
Pick the case
One public case you can review at two different points in time.
Settle the terms first
Decide up front what counts as success and what you are comparing against.
Work the first event
Record what you found, what you could not check, what you ruled out, and what you decided.
Come back at the second
See how much of the earlier work comes back, and confirm nothing ran without your approval.
Compare with your process
How long the rebuild took, how easily the evidence checked out, and how well it handed over.
One case is enough to decide whether this fits how your team works, and to work out what a second case would need to test. It will not prove the tool works in general, and it is not meant to.
Try it on one real case.
If the same wallets come across your desk more than once, one case is enough to tell whether keeping the record actually changes anything.
samuel@caserecall.xyz