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

# Para

> An embedded wallet provider. Users get a self-custodial wallet at sign-up, and one adapter hook connects it to every Passage flow.

Para maintains its own [Passage integration walkthrough](https://docs.getpara.com/v3/walkthroughs/passage), with the adapter written out in full. Treat it as the source of truth for the Para side of the integration, and this page as the Passage side of it.

## What it is

Para is an embedded wallet and authentication provider, launched as Capsule and renamed to Para in 2025. Its npm packages still carry the old name in places.

Users sign up with email, phone, social login, or a passkey, and get a wallet in the process. There are no seed phrases and no browser extension, so the wallet is part of signing up for your app rather than a separate step your users have to understand first.

## Key model

MPC. Private keys are split between the user's device and Para's infrastructure, and neither Para nor your application ever holds a complete key.

That keeps the wallet self-custodial, which is what Passage flows assume: the user signs their own transactions and pays their own gas, and nothing in Passage can move funds on their behalf.

## What the integration looks like

The Para-specific work is one hook. Para exposes a viem account through `useParaViemAccount()`, and you write an adapter, called `useParaEvmWallet` in Para's walkthrough, that presents it as Passage's [`EvmWallet`](/sdk/wallets): `address`, `signMessage`, `writeContract`, `broadcastRawTx`, and `awaitTx`.

Everything after that is the same code any Passage partner writes. Offers, eligibility and requirements, KYC, wallet screening, disclosures, document signing, and the checkout flows for Ondo and Superstate all run unchanged, because none of them know which wallet stack is underneath.

The adapter is also asset-agnostic. It is written against the wallet interface rather than against any particular provider's flow, so assets added to Passage later become available to your users without further Para-side work.

<Note>
  Because Para signs locally, there is no chain for the user to switch. The adapter takes the target chain as a parameter on each call, which is the same contract any `EvmWallet` implementation satisfies.
</Note>

## Supported networks

EVM only for now: Ethereum and Base, on both mainnet and Sepolia. Para supports more chains than this, but the Passage integration is limited to the four the SDK's `EthereumChain` type covers.

Which of those a given order can actually settle on comes off the offer rather than from this list. `OfferDetail.swapContracts` names the chains an offer supports, and [`swapSpender`](/sdk/ondo-swap#which-contract-the-trader-approves) returns `null` for a chain it does not. See [Wallets and chains](/wallets-chains) for what is live today.

## What you still need from Passage

Para handles the wallet. Passage credentials are separate, and you register for your own: a `client_id`, a registered `redirect_uri`, and a `client_secret`. OAuth runs through your backend so the secret never reaches the browser.

See [Set up OAuth authentication](/sdk/oauth-authentication) for the flow, and [contact us](mailto:support@coinlist.co) if you need credentials.

## FAQ

<AccordionGroup>
  <Accordion title="Does Para hold my users' keys?">
    No, and neither does your app. Keys are split with MPC between the user's device and Para's infrastructure, so a complete key exists in neither place. Passage never has access to a key at all.
  </Accordion>

  <Accordion title="Do my users need a seed phrase or a browser extension?">
    No. A Para wallet is created from the sign-up method your user already chose, whether that is email, phone, social login, or a passkey.
  </Accordion>

  <Accordion title="How much Para-specific code is there?">
    One adapter hook, which Para's walkthrough gives in full. It maps Para's viem account onto the five members of `EvmWallet`. Nothing else in a Passage integration is provider-specific.
  </Accordion>

  <Accordion title="Do my users still have to pass KYC and eligibility?">
    Yes. The wallet provider does not change what an offer requires. Passage reads the requirements for the offer your user is interested in and walks them through exactly those steps. See [Requirements](/sdk/requirements).
  </Accordion>

  <Accordion title="Does wallet ownership still have to be proved?">
    Yes, and the SDK runs it. The user signs a message to prove they control the address, and for Superstate the issuer also allowlists that address on-chain before it can settle. A Para wallet satisfies both through the same `signMessage` the adapter already supplies.
  </Accordion>

  <Accordion title="Who pays gas?">
    The user, from their own wallet, as on any Passage integration. A Para wallet needs the native token of whichever chain the order settles on. See [Wallets and chains](/wallets-chains).
  </Accordion>

  <Accordion title="Can I support Para alongside external wallets?">
    Yes. `CheckoutWalletSelection` takes an embedded wallet and external ones together, so Para can be the default while a user who prefers their own wallet connects it instead. See [Wallets](/sdk/wallets).
  </Accordion>
</AccordionGroup>

## Build it

<CardGroup cols={2}>
  <Card title="Para's Passage walkthrough" icon="arrow-up-right-from-square" href="https://docs.getpara.com/v3/walkthroughs/passage">
    The adapter in full, step by step, from Para's own docs.
  </Card>

  <Card title="Wallets" icon="wallet" href="/sdk/wallets">
    The `EvmWallet` seam the adapter satisfies, and how wallet errors are classified.
  </Card>

  <Card title="Set up OAuth authentication" icon="key" href="/sdk/oauth-authentication">
    Register your credentials and run the flow through your backend.
  </Card>

  <Card title="Building the Checkout flow" icon="cart-shopping" href="/sdk/checkout">
    Hand the adapted wallet to a container that renders any offer type.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.