3.0.0

[Dargon789]

No description provided.

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[sourcery-ai]

Sorry @Dargon789, your pull request is larger than the review limit of 150000 diff characters

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
🔚	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[codesandbox]

Review or Edit in CodeSandbox

Open the branch in Web Editor • VS Code • Insiders

Open Preview

[mergify]

⚠️ The sha of the head commit of this PR conflicts with #653. Mergify cannot evaluate rules on this PR. Once #653 is merged or closed, Mergify will resume processing this PR. ⚠️

[gemini-code-assist]

Code Review

This pull request introduces OIDC ID token login support, account federation, and Arweave state reader integration, alongside explicit transaction sponsorship checks (isSponsored) and safe-mode self-transfer fixes. The code review highlights several critical issues: a missing Signers import in wallets.ts, missing data parameter forwarding in EIP6963Relayer and PkRelayer's feeOptions methods, an async promise executor anti-pattern in IdTokenHandler, and potential runtime crashes in wallets.ts due to unsafe casting of handlers without instanceof AuthCodeHandler checks.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The Signers namespace/class is used in the newly added addLoginSignerFromPrepared method (e.g., Signers.isSapientSigner), but it is not imported in this file. This will cause a TypeScript compilation error. Please import Signers from @0xsequence/wallet-core.

Suggested change

	import { IdTokenHandler } from './handlers/idtoken.js'
	import { IdTokenHandler } from './handlers/idtoken.js'
	import { Signers } from '@0xsequence/wallet-core'

[gemini-code-assist]

The feeOptions method in EIP6963Relayer does not accept or forward the optional data parameter to the underlying relayer. This prevents accurate simulation of transactions for undeployed wallets when using an EIP-6963 relayer. Please add the data parameter and forward it.

    data?: Hex.Hex,
  ): Promise<{ options: FeeOption[]; quote?: FeeQuote; sponsored: boolean; failed?: boolean }> {
    return this.relayer.feeOptions(wallet, chainId, to, calls, data)

[gemini-code-assist]

The feeOptions method in PkRelayer does not accept or forward the optional data parameter to the underlying relayer. This prevents accurate simulation of transactions for undeployed wallets when using a private key relayer. Please add the data parameter and forward it.

    data?: Hex.Hex,
  ): Promise<{ options: FeeOption[]; quote?: FeeQuote; sponsored: boolean; failed?: boolean }> {
    return this.relayer.feeOptions(wallet, chainId, to, calls, data)

[gemini-code-assist]

Using an async executor in new Promise is an anti-pattern and violates the no-async-promise-executor ESLint rule. Any asynchronous rejection or error thrown inside the executor might not be caught properly. It is cleaner and safer to use a standard synchronous executor and handle promise rejection via .catch(reject).

    return new Promise((resolve, reject) => {
      const respond: RespondFn = async (idToken) => {
        try {
          const [signer, metadata] = await this.completeAuth(idToken)
          resolve({ signer, email: metadata.email || '' })
        } catch (error) {
          reject(error)
        }
      }

      onPromptIdToken(this.signupKind, respond).catch(reject)
    })

[gemini-code-assist]

When Google is configured for ID token authentication, the handler returned by getSignupHandlerKey will be an IdTokenHandler instead of an AuthCodeHandler. Casting it as AuthCodeHandler without checking will cause a runtime crash when calling completeAuth because IdTokenHandler.completeAuth has a different signature. Please add an instanceof AuthCodeHandler check.

Suggested change

	const handler = this.shared.handlers.get(getSignupHandlerKey(args.kind)) as AuthCodeHandler
	if (!handler) {
	throw new Error('handler-not-registered')
	const handler = this.shared.handlers.get(getSignupHandlerKey(args.kind))
	if (!handler) {
	throw new Error('handler-not-registered')
	}
	if (!(handler instanceof AuthCodeHandler)) {
	throw new Error('handler-does-not-support-redirect')
	}

[gemini-code-assist]

If a custom provider is configured as an ID token provider but the caller passes authcode arguments, the handler will not be an AuthCodeHandler. Casting it without checking will cause a runtime crash. Please add an instanceof AuthCodeHandler check.

      const handler = this.shared.handlers.get(args.kind)
      if (!handler) {
        throw new Error('handler-not-registered')
      }
      if (!(handler instanceof AuthCodeHandler)) {
        throw new Error('handler-does-not-support-redirect')
      }