SDK

Two different things can go wrong, and they surface differently.

Failures before submission throw. Bad configuration, an unsupported signer, a chain with no relay. These are JavaScript Errors with a message string. Catch them with try/catch.

Failures at or after submission do not throw. execute and revokeSession return an ExecuteResult with status: "FAILED". Nothing is raised. If you only wrap calls in try/catch, you will not notice these.

const result = await client.execute({ wallet, signer, calls });
if (result.status !== "CONFIRMED") {
  // Handle it here. No exception was thrown.
}

grantSession is the exception: it throws Session grant did not confirm: status=<status> (with the relay code appended when one was observed, e.g. status=FAILED (relay code 300)) rather than returning a failed result, because there is no useful Session object to hand back.

Reading ExecuteResult

type ExecuteResult = {
  callsId: Hex;
  status: "CONFIRMED" | "FAILED" | "PENDING";
  transactionHash?: Hex;
  statusCode?: number;   // the relay's raw numeric status, when observed
};

Relay status codes

The relay answers status polls with a numeric code. The codes follow the EIP-5792 convention (the relay does not publish its own list, so the SDK classifies by band, the same way viem does):

What FAILED carries

FAILED comes with statusCode when the relay reported one, which splits the diagnosis in two: 3xx/4xx means nothing reached the chain (fee, cap, or relay policy — fix the session or funding and resubmit), while 5xx/6xx means it reverted on-chain. There is still no revert string or receipt on the result; for the on-chain reason, use the table below and the explorer.

If you need the onchain reason, look up the userOp yourself. You have callsId; the wallet address and chain are yours. Search the wallet address on the chain's explorer (BscScan for BNB, Etherscan for Ethereum) and inspect the most recent transaction to the account. The revert reason is in the trace.

Telling the failure classes apart

Errors the SDK throws

There is no error class and no error code: every one of these is a plain Error, so match on the message if you must branch on them.

Configuration

Chain and relay

Signers

Passing a signer the SDK cannot use produces a multi-line message naming every supported constructor. SignerType is "privateKey" | "passkey"; a hand-rolled signer object with any other type — including "injected", which browser wallets can never satisfy — is rejected with guidance, e.g. "Injected wallet signers (e.g. MetaMask) need to sign a transaction but the current build of @altananetwork/sdk doesn't accept them as a signer type." Use signerFromPrivateKey, createPrivateKeySigner, createPasskey, or createHeadlessPasskey. For the browser-wallet story — why extension wallets cannot sign for a 7702 account, and the onboarding flow that works instead — see Onboard users from browser wallets.

Cross-chain sync

Recovery

recoverFromPasskey needs at least one active key in Keystore, which means the wallet must have executed at least once. A wallet that was created but never used has nothing to recover from.

Related

• execute for the call itself
• Sessions for what makes a session valid
• createWallet for counterfactual wallets and funding