> ## Documentation Index
> Fetch the complete documentation index at: https://paralens.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# ParaLens FAQ: Pricing, Chains, Authentication, and More

> Answers to common questions about ParaLens: free pricing, supported chains, authentication, data freshness, classification accuracy, and batch usage.

Quick answers to common questions about ParaLens.

<AccordionGroup>
  <Accordion title="Is ParaLens free?">
    Yes, completely free. There is no signup, no billing, and no rate limits communicated at this time. You can start making requests to the API immediately without creating an account.
  </Accordion>

  <Accordion title="Do I need an API key?">
    No authentication is required today. You can call any endpoint without providing credentials.

    Future-compatible clients should be prepared to send an `x-api-key` header as authentication may be introduced in future versions:

    ```http theme={null}
    x-api-key: <your-api-key>
    ```

    The server is already prepared to handle this header but does not currently enforce it. Adding it to your client now will make any future migration seamless.
  </Accordion>

  <Accordion title="Which blockchains are supported?">
    Ethereum mainnet only. The `chain` field in the request body accepts the following equivalent values:

    | Value      | Chain                       |
    | ---------- | --------------------------- |
    | `ethereum` | Ethereum mainnet            |
    | `mainnet`  | Ethereum mainnet            |
    | `eth`      | Ethereum mainnet            |
    | `1`        | Ethereum mainnet (chain ID) |

    Support for other EVM-compatible chains is not currently available.
  </Accordion>

  <Accordion title="How fresh is the data?">
    ParaLens fetches live data on every request. There is no caching on the server side — each call to `/analyze` triggers a fresh RPC fetch and full analysis run.

    You can call `/analyze` for any confirmed Ethereum transaction regardless of how old it is, from the genesis block to the most recently confirmed block.
  </Accordion>

  <Accordion title="Can I analyze pending transactions?">
    No. ParaLens requires a confirmed transaction with a complete execution trace. Pending transactions have not yet been executed, so no trace data exists to analyze.

    Once a transaction is confirmed and included in a block, it can be analyzed immediately.
  </Accordion>

  <Accordion title="How accurate is the classification?">
    Classification accuracy depends on the transaction type:

    * **Common patterns** — Swap, Transfer, LiquidityProvision, and similar well-defined operations are classified with high confidence using structural proof derived from execution traces.
    * **Novel or obfuscated patterns** — Transactions that do not match a known structural signature may be classified as `UnknownComplexFlow`.

    For per-transaction certainty, check two fields in the response:

    | Field                       | What it tells you                                                                           |
    | --------------------------- | ------------------------------------------------------------------------------------------- |
    | `classification.confidence` | `High`, `Medium`, or `Low` — reflects how strongly the evidence supports the classification |
    | `classification.status`     | `Proven` (conclusive structural match) or `Suspected` (best-effort estimate)                |

    When `status` is `Suspected` or `confidence` is `Low`, treat the classification as a best-effort signal rather than a definitive label.
  </Accordion>

  <Accordion title="Can I analyze multiple transactions at once?">
    The API processes one transaction per request. For batch use cases, call `/analyze` in parallel for each transaction hash. Because the API is fully stateless, all requests are independent and safe to parallelize.

    Since confirmed transactions are immutable, consider caching responses on your side to avoid redundant API calls for hashes you have already analyzed.
  </Accordion>

  <Accordion title="Does ParaLens store my data?">
    The API is stateless — requests are not cached or stored server-side. Each call is processed independently and no data is persisted between requests.
  </Accordion>

  <Accordion title="Why is net_usd unavailable for some transactions?">
    `net_usd` (and related USD fields) require pricing data for every asset involved in the transaction at the block height where it was confirmed. If any asset cannot be priced, the aggregate USD values will be unavailable.

    This commonly occurs for:

    * Obscure or low-liquidity tokens with no reliable on-chain price feed
    * Newly deployed contracts with no DEX liquidity at the time of the block
    * Very old transactions involving assets that no longer exist or trade

    Check `economics.valuation` for a breakdown of which assets were priced and which were not. The `unpriced_assets` array lists every asset for which a price could not be resolved.

    USD fields use the `DisplayMoney` structure: `{ text, available, reason }`. Always check `available` before rendering `text` — when `available` is `false`, `text` is a non-numeric placeholder and `reason` describes why the value could not be computed.
  </Accordion>

  <Accordion title="What is the difference between inflow_usd and net_usd_before_gas?">
    These two fields measure different things:

    * **`inflow_usd`** — the gross USD value of assets *received* by the economic actor, with no offset for outflows
    * **`net_usd_before_gas`** — the net USD change for the economic actor (inflows minus outflows), before gas costs are subtracted

    **Example:** a swap of $10,000 USDC into $9,998 WETH:

    | Field                | Value                                                        |
    | -------------------- | ------------------------------------------------------------ |
    | `inflow_usd`         | \~\$9,998 (value of WETH received)                           |
    | `net_usd_before_gas` | \~−$2 (net change: received $9,998 WETH, sent \$10,000 USDC) |

    Use `inflow_usd` when you want to show the value of what was received. Use `net_usd_before_gas` when you want to show economic gain or loss.
  </Accordion>

  <Accordion title="What is realized_pnl and when is it available?">
    `realized_pnl` is the profit extracted within a single atomic transaction. It is calculated only for **self-closing flows** — transactions where the full position opens and closes within the same execution, such as atomic arbitrage (e.g., flash-loan-backed arb that starts and ends in the same token).

    `realized_pnl.supported` will be `false` for:

    * Normal swaps (a position opens but does not close in the same transaction)
    * Liquidity deposits and withdrawals
    * Long-lived positions managed across multiple transactions

    For these cases, use `economics.net_usd_before_gas` as a proxy for value captured.
  </Accordion>

  <Accordion title="What does pipeline_stats tell me?">
    `pipeline_stats` exposes the internal metrics from the analysis pipeline run for that transaction. It includes counts such as:

    * **`frames`** — number of execution trace frames processed
    * **Log entries** — number of on-chain events decoded
    * **Graph nodes / edges** — size of the internal call and flow graph
    * **Structural scopes** — number of distinct execution scopes identified

    Higher numbers across these fields indicate a denser, more complex transaction. For most use cases you can ignore `pipeline_stats`, but it is useful for:

    * **Debugging** — understanding why a complex transaction took longer or produced an unexpected result
    * **Advanced analysis** — correlating transaction complexity with classification confidence or latency
  </Accordion>
</AccordionGroup>