---
title: Approval and Signing
description: Understand the embedded wallet request lifecycle for `connect()`,
  `getSigningContext()`, and `signTransaction()`, plus the user-facing approval
  states a dApp should expect.
source_url:
  html: https://thru.org/docs/wallet/approval-and-signing/
  md: https://thru.org/docs/wallet/approval-and-signing.md
---

# Approval and Signing

Use this page when you need the exact high-level lifecycle behind `connect()`, `getSigningContext()`, and `signTransaction()`.

## Connect Lifecycle

From a dApp perspective, `connect()` is a request for wallet approval plus account discovery.

1. The dApp calls `connect()`.
2. `BrowserSDK` auto-initializes the iframe if needed and forwards the request to the embedded provider.
3. The provider posts a `connect` request to the wallet iframe with the dApp origin and optional app metadata.
4. The wallet decides whether it can reuse a cached connection for the same origin, auto-approve a previously connected app, or show the connect UI.
5. If approval succeeds, the wallet returns the connected accounts and resolved app metadata.
6. The provider caches the connected accounts locally and emits `connect`.

## What Changes Connect Behavior

| Condition | What happens |
| - | - |
| Same origin is already connected in the current iframe session | The wallet can return the cached connection result immediately. |
| The dApp supplies app metadata and the app is already known for the selected account | The wallet can auto-approve if it is already unlocked. |
| The wallet is locked | The wallet shows connect UI and may require passkey unlock before approval completes. |
| No metadata is supplied | The wallet still works, but the connection flow goes through the visible approval UI. |

## Signing Lifecycle

`signTransaction()` is a separate approval flow. A connected wallet does not imply automatic transaction approval.

1. The dApp builds an unsigned transaction and base64-encodes the bytes.
2. The dApp calls `wallet.signTransaction(base64Payload)`.
3. The embedded provider shows the wallet iframe and posts a `signTransaction` request.
4. The wallet stores the pending request and opens the transaction approval modal.
5. If the wallet is locked, passkey authentication runs before signing continues.
6. The wallet signs the serialized transaction payload and returns canonical raw transaction bytes encoded as base64.
7. The dApp submits those returned bytes separately.

## Managed Account Vs Network Signer

The selected account and the network signer can differ.

- the selected account is the managed wallet account the user is acting as
- the fee payer and signer can be the embedded manager profile instead
- `getSigningContext()` is the source of truth for that split

This matters before the dApp builds the transaction, not just before it submits it.

## `getSigningContext()` Lifecycle

Use `getSigningContext()` before building a transaction whenever the fee payer or signer identity matters.

The request returns:

- `selectedAccountPublicKey`
- `feePayerPublicKey`
- `signerPublicKey`
- accepted input encodings for `signTransaction()`
- the output encoding that the wallet will return

## dApp UX Expectations

| Phase | What the wallet is doing | What the dApp should show |
| - | - | - |
| Before `connect()` resolves | Waiting for connect approval or unlock | A persistent “waiting for wallet approval” state |
| Before `signTransaction()` resolves | Waiting for transaction approval and possibly passkey unlock | A persistent “confirm in wallet” state |
| After `signTransaction()` resolves | The wallet has returned canonical raw bytes, but has not submitted them | A “submitting transaction” state until the dApp sends and tracks the transaction |
| On rejection | Returning a user-rejected error | A recoverable error state with retry |

## Important Distinction

The wallet signs. The dApp submits.

If `signTransaction()` succeeds but the transaction never appears in explorer, the first thing to check is whether the dApp actually sent the returned raw bytes to the network.

## Account Selection

The sign flow uses the currently selected wallet account. If the dApp wants to sign with a different account, it should change selection before signing.

That selection affects the managed account context shown to the user, but it does not necessarily mean the same public key is the network fee payer.

## Related References

- [Embedded Wallet Integration](https://thru.org/docs/wallet/embedded-wallet-integration.md)
- [`@thru/wallet`](https://thru.org/docs/sdks/web-packages/wallet.md)
- [`@thru/sdk`](https://thru.org/docs/sdks/web-packages/sdk.md)