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

# Embedded wallets

> Wire any embedded or MPC wallet provider into the sign and submit loop, without a vendor-specific API.

An embedded or MPC wallet provider (Turnkey, Privy, Dynamic, Portal, Crossmint, or another) fits the same pattern regardless of vendor: get the user's address from the provider, build the action, hand each transaction to the provider's own sign and send method in order, then submit and track. This page covers that pattern generically. Vendor pages below are not yet live.

## Prerequisites

* An embedded wallet provider already integrated in your app, capable of returning a wallet address and signing a raw transaction or payload for your target chain.
* A yield.xyz API key. See [Enter and exit flows](/guides/earn/enter-exit-flows) for the request and poll loop this pattern plugs into.

## The pattern

<Steps>
  <Step title="Get the user's address from the wallet provider">
    Every embedded wallet provider exposes a method to create or resolve a user's wallet and return its address for a given chain. Use that address, not one you derive or cache separately, as the `address` on the action request: it must match the wallet that will actually sign.
  </Step>

  <Step title="Build the action">
    Call `POST /v1/actions/enter` (or `/exit`, `/manage`) with the yield's `yieldId`, the wallet's `address`, and arguments built from `mechanics.arguments.enter.fields`. See [Discover yields](/guides/earn/discover-yields) and [Enter and exit flows](/guides/earn/enter-exit-flows).
  </Step>

  <Step title="Hand each transaction to the provider's sign method, in order">
    Sort `action.transactions` by `stepIndex`, skip any already at a terminal status, and for each one, decode `unsignedTransaction` for the chain family (see [Transaction signing](/guides/transaction-signing/index)) and pass it to the provider's own signing method: most embedded wallet SDKs expose something shaped like `wallet.signTransaction(tx)` or `wallet.signAndSendTransaction(tx)`, keyed to the chain rather than to yield.xyz. Consult your provider's SDK for the exact call; this guide does not repeat vendor API surfaces.
    Wait for each transaction to confirm before moving to the next `stepIndex`, unless `action.executionPattern` is `batch`.
  </Step>

  <Step title="Submit and track">
    If the provider's SDK broadcasts for you, report the resulting hash with `PUT /v1/transactions/{transactionId}/submit-hash`. If it only returns a signed payload, hand that to yield.xyz instead with `POST /v1/transactions/{transactionId}/submit`. Use one path per transaction, never both. Then poll `GET /v1/transactions/{transactionId}` (or the whole action) to a terminal status.
  </Step>
</Steps>

<Note>
  The pattern above is the same one a browser extension wallet or a raw key follows; an embedded wallet provider is another signer. Never modify `unsignedTransaction` before handing it to the provider, whichever provider it is.
</Note>

## Widget integration

If you'd rather not call the Yield API directly, `@stakekit/widget` accepts an `externalProviders` option that lets an embedded wallet drive signing inside the widget's own flow. See [Yield widget](/guides/widgets-dashboard/yield-widget) for that integration path.

## Providers

<Columns cols={2}>
  <Card title="Turnkey (Coming soon)" icon="key" href="/guides/integrations/turnkey">
    Programmable key infrastructure for embedded wallets.
  </Card>

  <Card title="Privy (Coming soon)" icon="key" href="/guides/integrations/privy">
    Embedded wallets with email, social login, and passkey auth.
  </Card>

  <Card title="Dynamic (Coming soon)" icon="key" href="/guides/integrations/dynamic">
    Multi-chain embedded wallets with configurable authentication.
  </Card>

  <Card title="Portal (Coming soon)" icon="key" href="/guides/integrations/portal">
    MPC-based embedded wallets.
  </Card>

  <Card title="Crossmint (Coming soon)" icon="key" href="/guides/integrations/crossmint">
    Wallets-as-a-service with NFT and payments infrastructure.
  </Card>
</Columns>

## Next steps

<Columns cols={2}>
  <Card title="Transaction signing" icon="pen-nib" href="/guides/transaction-signing/index">
    Decode unsignedTransaction by chain family before handing it to a provider.
  </Card>

  <Card title="Custody and signing flows" icon="building-columns" href="/guides/enterprise/custody-signing-flows">
    The equivalent pattern for a backend custody or HSM signer instead of a client-side wallet.
  </Card>
</Columns>


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