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

# Components

> The moving parts that make PIXA work across install modes, wallet flows, and the treasury hub.

# Components

## MCP Package

The npm-published package is what developers install with `npx pixa-wallet-mcp`.

It provides the tool surface for:

* checking balances
* signing x402 payments
* fetching x402-gated resources
* transferring USDC and ALGO
* running swaps
* launching on-ramp flows
* requesting Pera rekey approval

## Browser Flows

Some actions should not stay inside the Claude iframe.

PIXA uses browser flows for:

* on-ramp checkout
* rekey approval
* hosted or future AC2-style authorization

This keeps the user-facing approval surface explicit and easier to debug.

## PIXA Hub

PIXA Hub is the treasury and routing service.

Its job is to:

* reserve balances
* create payment signatures
* track attempts and ledger state
* bridge the gap between the Algorand home wallet and services on other rails

## External Services

PIXA integrates with outside services rather than pretending everything lives in one chain.

Examples include:

* on-ramp providers
* DEXs such as Tinyman
* x402-gated APIs
* partner services that need a payment receipt or signed authorization

## Data and Policy

PIXA keeps a clear separation between:

* what the user explicitly approved
* what the agent asked for
* what the backend is allowed to do
* what must still be verified on-chain or in a hosted flow

That separation is what makes the system understandable.

## What to show in the docs

For people reading the docs, the most useful explanation is not the library tree.
It is the operational view:

1. user funds the wallet
2. agent chooses a service
3. PIXA decides whether the flow is local, hosted, or routed through the hub
4. the user gets a clear confirmation surface
5. the service returns a usable result