Skip to main content
An embedded or MPC wallet provider 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, and the provider guides below walk through it end to end for Turnkey, Dynamic, Portal, Crossmint and Sequence.

​
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 for the request and poll loop this pattern plugs into.

​
The pattern

1

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.
2

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 and Enter and exit flows.
3

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) 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.
4

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.
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.

​
Providers

Turnkey

Policy-controlled keys that can only call the contracts your yields use.

Dynamic

Embedded MPC wallets with configurable authentication.

Portal

MPC wallets with CAIP-2 chain addressing.

Crossmint

Smart contract wallets with email and social login.

Sequence and Trails

Smart wallets that batch each step, plus cross-chain deposits with Trails Earn.

Privy with AgentKit

Privy server wallets signing for an AI agent under spending policies.

​
Next steps

Transaction signing

Decode unsignedTransaction by chain family before handing it to a provider.

Custody and signing flows

The equivalent pattern for a backend custody or HSM signer instead of a client-side wallet.