> For the complete documentation index, see [llms.txt](https://docs.bextree.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bextree.com/developers/discovery-architecture.md).

# Discovery Architecture

Discovery answers: *given a connected wallet, what can this user list?*

## How it works

Each supported protocol has a **discoverer** implementing a common interface: it takes a wallet address and returns the eligible assets it found, normalized into a common shape (asset type, provider, face-value estimate, transferability, and the protocol-specific references settlement will later need).

When a wallet connects, the client fans out to all discoverers in parallel — Streamflow, Orca, Raydium, Meteora DAMM v2, plus baseline scanners for SPL tokens and NFTs. Results stream in per protocol, so one slow RPC call doesn't block the rest.

## Trust boundary

Discovery output is **user-reported until verified**. Face-value estimates (`faceValueUsd`) are derived client-side from on-chain data and are treated as untrusted by the server — discount calculations and badges are never taken at face value server-side. Before a listing can be published, ownership and transferability are re-verified independently.

## Eligibility filtering

Discoverers filter out what can't be sold, so users never see a listable-looking asset that would fail at settlement:

* Streamflow contracts whose recipient can't be changed
* Meteora DLMM positions (non-transferable)
* Closed or empty positions