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.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 for that integration path.
Providers
Turnkey (Coming soon)
Programmable key infrastructure for embedded wallets.
Privy (Coming soon)
Embedded wallets with email, social login, and passkey auth.
Dynamic (Coming soon)
Multi-chain embedded wallets with configurable authentication.
Portal (Coming soon)
MPC-based embedded wallets.
Crossmint (Coming soon)
Wallets-as-a-service with NFT and payments infrastructure.
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.