> For the complete documentation index, see [llms.txt](https://dopameme.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dopameme.gitbook.io/docs/protocol/learning-packets.md).

# Learning Packets

Learning packets are how Dopameme turns repeated scans into compounding intelligence.

A normal alert system sees activity, prints a signal, and moves on. Dopameme is designed to remember what it said. When a token is scanned again, the new packet can be compared against the earlier one so the protocol can understand whether the read was useful, early, late, incomplete, or wrong.

## The Learning Loop

The learning loop is simple, but powerful:

1. A token is scanned or observed.
2. Dopameme creates a packet with the current evidence.
3. The operator read explains what matters and what should happen next.
4. A later scan creates a new packet.
5. The protocol compares the new evidence against the old packet.
6. Audits judge whether the original read held up.
7. Future packets use that history to become sharper.

This is why packets are more important than a single beautiful output. The value comes from the chain of observations.

## What The Protocol Learns

Dopameme should learn from both good and bad reads.

If a token respected a key level, that level should matter in the next read. If tracked-wallet attention faded quickly, the system should remember that. If holder concentration was a warning and the token later failed, that connection should become part of the evidence history. If an operator read missed the real issue, the audit trail should expose it.

The protocol can learn from:

* Whether technical levels held or failed
* Whether wallet attention continued or disappeared
* Whether holder concentration improved or became riskier
* Whether market-cap and liquidity filters protected users from noise
* Whether a suppressed token later proved the filter too strict
* Whether the operator read focused on the right evidence
* Whether repeated audits show the same weakness across different tokens

## Why This Should Matter To Users

The user should not need to read every raw packet to benefit from the learning layer.

The visible product should become clearer because the backend remembers more. Operator reads should improve. Consequence maps should become more precise. Confluence should become more selective. Wallet trust should become more evidence-based. Tokens with repeated useful behavior should be easier to understand, while noisy activity should be easier to suppress.

The end state is a terminal that does not just display the market. It studies the market and carries that context forward.

## What Learning Is Not

Learning does not mean the protocol can predict outcomes with certainty.

Meme markets are reflexive, thin, emotional, and fast. A strong read can fail. A weak token can run. A clean setup can break because liquidity leaves the market.

Dopameme's goal is not certainty. The goal is better context, stronger evidence discipline, and fewer repeated mistakes.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://dopameme.gitbook.io/docs/protocol/learning-packets.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.