> For the complete documentation index, see [llms.txt](https://riskguard-1.gitbook.io/riskguard-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://riskguard-1.gitbook.io/riskguard-docs/whitepaper/03-position-detection.md).

# 3. Position Detection Engine

> The hardest technical problem in portfolio risk is not scoring a position — it is finding it in the first place.

Most portfolio trackers detect positions using a simple heuristic: they look for known "receipt tokens" in the wallet. When a user deposits into a protocol, that protocol typically issues a token representing the deposit. If the tracker has that token's address hardcoded, the position appears. If it does not, the position is invisible. This approach fails silently and systematically for any protocol architecture that does not issue a simple, wallet-held receipt token.

RiskGuard takes a fundamentally different approach: it queries on-chain state directly, using detection methods tailored to each protocol's actual architecture. This is more engineering-intensive but produces reliable, comprehensive results.

## Detection coverage

### Base — 13 protocols

| Protocol                | Detection method                                         |
| ----------------------- | -------------------------------------------------------- |
| Aave V3                 | `balanceOf` on aTokens directly                          |
| Compound V3             | `balanceOf` on Comet contracts                           |
| Uniswap V3              | NonfungiblePositionManager (NFT)                         |
| PancakeSwap V3          | NonfungiblePositionManager (NFT)                         |
| Aerodrome Slipstream    | Direct NFTs + staked-gauge recovery via transfer history |
| Morpho Blue             | ERC-4626 vault scan + transfer-history fallback          |
| Moonwell                | Strategy registry → proxy → balance                      |
| Steakhouse / Gauntlet   | Curator-labeled Morpho vaults                            |
| Spark                   | ERC-4626 on sUSDC + sUSDS                                |
| Fluid                   | Dynamic factory enumeration + ERC-4626                   |
| Extra Finance (Lending) | LendingPool + dynamic eToken set                         |
| Extra Finance (Farming) | Leveraged vaults via event-log scan + struct decode      |

### Solana — 15 protocols

| Protocol                 | Detection method                               |
| ------------------------ | ---------------------------------------------- |
| Jupiter Lend             | jlTokens in wallet                             |
| Jupiter (Native Staking) | jupSOL mint + native stake accounts            |
| Kamino Farms             | PDA detection at known data offsets            |
| Raydium CLMM             | NFT positions via Helius DAS                   |
| Orca Whirlpool           | Token + Token-2022 scan + batch metadata       |
| Meteora DLMM             | On-chain PositionV2 decode                     |
| MarginFi / Sentora       | Program-account decode (fixed-point shares)    |
| Save Finance (Solend)    | Obligation accounts via program-account scan   |
| Loopscale                | Orderbook lender PDAs via program-account scan |
| Huma Finance             | PST / mPST receipt tokens (USDC-backed)        |
| Marinade Finance         | mSOL mint + native stake accounts              |
| Sanctum                  | INF mint address match                         |
| Jito                     | jitoSOL mint + staking detection               |
| Hastra (RWA)             | wYLDS + PRIME receipt mints                    |

{% hint style="info" %}
Coverage as of the document date and expanding. Native staking via Marinade and Jupiter is detected through Solana stake accounts, which issue no receipt token and are invisible to conventional trackers.
{% endhint %}

## Architectures that hide positions

Through building this engine, RiskGuard has catalogued the specific architectural patterns that cause positions to be missed by conventional detection. Each represents a class of protocol that simple receipt-token scanning cannot handle:

* **Program-derived addresses (PDAs)** — protocols like Kamino Farms store positions in deterministic program accounts rather than wallet-held tokens, requiring direct account parsing at known data offsets.
* **NFT-based positions** — concentrated-liquidity protocols such as Raydium CLMM, Orca, and Uniswap V3 represent positions as non-fungible tokens, requiring digital-asset-standard queries and metadata resolution.
* **Token-2022 program** — newer Solana positions use the extended token program, which a scan limited to the original token program will miss.
* **Native stake accounts** — liquid-staking and native-staking products such as Marinade Native and Jupiter native staking issue no receipt token at all; the staked SOL lives in Solana stake accounts owned by the user, requiring direct stake-program queries to detect.
* **Proxy and smart-wallet intermediaries** — aggregators route deposits through proxy contracts, so the underlying protocol position is held by a contract the user does not directly control.
* **RPC enumeration limits** — some detection paths are blocked by RPC providers' limits on account enumeration, requiring transaction-history fallbacks.
* **Commercial name versus base protocol** — a position branded under one name in a third-party tracker may in fact be a wrapper around a different base protocol.

{% hint style="warning" %}
**Operating principle.** When a user reports a position that the detector returns as empty, RiskGuard treats this as a code problem, never a user problem. A mandatory diagnostic checklist is run before any position is concluded not to exist. This principle drives the engine's reliability and is the foundation of user trust.
{% endhint %}


---

# 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://riskguard-1.gitbook.io/riskguard-docs/whitepaper/03-position-detection.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.