Skip to main content
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

ConditionWhat happens
Same origin is already connected in the current iframe sessionThe wallet can return the cached connection result immediately.
The dApp supplies app metadata and the app is already known for the selected accountThe wallet can auto-approve if it is already unlocked.
The wallet is lockedThe wallet shows connect UI and may require passkey unlock before approval completes.
No metadata is suppliedThe 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

PhaseWhat the wallet is doingWhat the dApp should show
Before connect() resolvesWaiting for connect approval or unlockA persistent “waiting for wallet approval” state
Before signTransaction() resolvesWaiting for transaction approval and possibly passkey unlockA persistent “confirm in wallet” state
After signTransaction() resolvesThe wallet has returned canonical raw bytes, but has not submitted themA “submitting transaction” state until the dApp sends and tracks the transaction
On rejectionReturning a user-rejected errorA 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.