Codesandbox

[Dargon789]

No description provided.

[codesandbox]

Review or Edit in CodeSandbox

Open the branch in Web Editor • VS Code • Insiders

Open Preview

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[sourcery-ai]

Sorry, we are unable to review this pull request

The GitHub API does not allow us to fetch diffs exceeding 300 files, and this pull request has 2161

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
sequence-js-docs	Ready	Preview, Comment	Jan 31, 2026 0:57am
sequence-js-web	Ready	Preview, Comment	Jan 31, 2026 0:57am
sequence.js	Ready	Preview, Comment	Jan 31, 2026 0:57am
wagmi-project	Error		Jan 31, 2026 0:57am

[snyk-io]

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

Status	Scanner	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.

[gemini-code-assist]

Summary of Changes

Hello @Dargon789, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a foundational transaction relayer service, significantly enhancing the project's ability to handle on-chain interactions with advanced precondition checks and support for various relaying mechanisms. It also establishes a robust CI/CD pipeline and integrates a new submodule for smart contract-based implicit session management, alongside general project maintenance and service updates.

Highlights

• New Relayer Service Package: A new package packages/services/relayer has been introduced, providing a robust Relayer interface and multiple implementations for transaction relaying, fee management, and status checks, including RPC, local, private key, Sequence-specific, and EIP-6963 compatible relayers.
• Comprehensive Precondition Handling: The new relayer service includes dedicated modules for defining, encoding, decoding, and selecting various transaction preconditions. These enable checks for native token balances, ERC20 balances and approvals, ERC721 ownership and approvals, and ERC1155 balances and approvals before transactions are processed.
• Viem Integration for RPC Relayer: The RpcRelayer implementation now leverages the viem library for enhanced interaction with Ethereum RPCs, facilitating efficient fetching of chain information and execution of contract calls necessary for precondition validation.
• EIP-6963 Provider Support: The relayer service now integrates support for EIP-6963 providers, allowing for seamless discovery and interaction with local Ethereum wallet extensions for transaction relaying.
• Foundry Submodule for Implicit Sessions: A new git submodule lib/signals-implicit-mode has been added, incorporating Foundry contracts designed for managing implicit sessions and a project registry, enhancing smart contract interactions within the ecosystem.
• CI/CD and Project Structure Enhancements: Initial CircleCI configuration has been added, alongside various GitHub workflows and issue templates, and updated documentation/web assets, laying the groundwork for improved continuous integration and project maintenance.
• Userdata Service Updates: The packages/services/userdata package received minor version updates, including a new SequenceUserdataClient class that automatically handles JWT and access key authentication headers for API requests.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/on_pr_pnpm-format-label.yml

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a significant amount of new functionality related to relayers and preconditions. However, it also contains several critical issues that must be addressed before merging. Notably, there are unresolved merge conflicts in two generated files, which will break the build. Additionally, some tests are not correctly validating the implemented code due to interface mismatches. I've also identified several correctness issues, such as hardcoded values in the precondition decoding logic and incorrect type validation, which could lead to bugs. There are also potential runtime errors, a memory leak, and areas for improvement in efficiency and maintainability. Please review the detailed comments for each issue.

I am having trouble creating individual review comments. Click here to see my feedback.

packages/services/relayer/src/relayer/rpc-relayer/relayer.gen.ts (2-10)

This file contains unresolved merge conflicts. Please resolve these conflicts before merging.

packages/services/relayer/test/preconditions/selectors.test.ts (25-32)

The structure of the precondition object used in this test does not match the TransactionPrecondition interface being imported from codec.ts. The test uses a data property containing a JSON string with chainID, while the interface defines chainId at the top level. This test is not correctly validating the extractChainID function. Please update the test to use the correct interface structure.

      const precondition: TransactionPrecondition = {
        type: 'native-balance',
        chainId: Network.ChainId.MAINNET,
        ownerAddress: TEST_ADDRESS,
        tokenAddress: '0x0000000000000000000000000000000000000000',
        minAmount: 1000000000000000000n
      }

packages/wallet/core/src/relayer/standard/rpc/relayer.gen.ts (2-10)

This file contains unresolved merge conflicts. Please resolve these conflicts before merging.

packages/wallet/core/src/state/sequence/sessions.gen.ts (2-10)

This file contains unresolved merge conflicts. Please resolve these conflicts before merging.

packages/services/relayer/src/preconditions/codec.ts (65-101)

The decodePrecondition function hardcodes tokenId to BigInt(0) for erc721-ownership, erc721-approval, erc1155-balance, and erc1155-approval preconditions. This will cause these preconditions to only work for token ID 0. The TransactionPrecondition interface should be extended to include an optional tokenId field to support different token IDs. Similarly, erc20-approval hardcodes the operator to be the owner, which might not always be the case.

packages/services/relayer/src/preconditions/types.ts (78-80)

The validation this.min === undefined will always evaluate to false because min is a required bigint parameter in the Erc20ApprovalPrecondition constructor, not an optional one. This validation check is incorrect and should be removed. This same issue exists for tokenId and min properties in other precondition classes within this file (Erc721OwnershipPrecondition, Erc721ApprovalPrecondition, Erc1155BalancePrecondition, Erc1155ApprovalPrecondition).

packages/services/relayer/src/relayer/standard/local.ts (118-157)

The relay method uses setTimeout for polling, but the cleanup function returned by the Promise constructor will likely never be called, as standard Promises are not cancellable. This can lead to a memory leak where polling continues indefinitely even if the consumer of the promise has moved on. Consider using a different pattern for handling asynchronous operations with cancellation, or ensure that the polling has a defined end condition (e.g., a timeout or a maximum number of retries).

packages/services/userdata/src/index.ts (15-35)

The _fetch method uses a non-null assertion on init (init!.headers). However, the fetch API's init parameter is optional. If this method is called without an init object, it will throw a runtime error. You should handle the case where init is undefined to prevent this.

  _fetch = (input: RequestInfo, init?: RequestInit): Promise<Response> => {
    // automatically include jwt and access key auth header to requests
    // if its been set on the api client
    const headers: { [key: string]: any } = {}

    const jwtAuth = this.jwtAuth
    const projectAccessKey = this.projectAccessKey

    if (jwtAuth && jwtAuth.length > 0) {
      headers['Authorization'] = `BEARER ${jwtAuth}`
    }

    if (projectAccessKey && projectAccessKey.length > 0) {
      headers['X-Access-Key'] = projectAccessKey
    }

    // before the request is made
    const newInit = { ...init }
    newInit.headers = { ...(newInit.headers || {}), ...headers }

    return fetch(input, newInit)
  }

packages/services/relayer/src/preconditions/selectors.ts (20-38)

The functions extractNativeBalancePreconditions and extractERC20BalancePreconditions both call decodePreconditions internally. If a consumer calls both of these functions with the same preconditions array, the decoding process will be performed twice unnecessarily. Consider refactoring to decode the preconditions once and then filter the result based on the desired type to improve efficiency.

packages/services/relayer/src/relayer/rpc-relayer/index.ts (128-131)

The catch block in feeTokens swallows the error, logs it to the console, and returns a default value. This can make debugging difficult as the caller won't be aware that an error occurred. It would be better to re-throw the error or return a result object that indicates failure. This same issue is present in feeOptions and checkPrecondition within this file.

    } catch (e) {
      console.warn('RpcRelayer.feeTokens failed:', e)
      throw e
    }

packages/services/relayer/src/relayer/rpc-relayer/index.ts (230)

Constructing the opHash by manually prepending 0x is inconsistent with the sendMetaTxn method, which uses Hex.fromString. For consistency and type safety, please use Hex.fromString here as well.

    return { opHash: Hex.fromString(result.txnHash) }

packages/services/relayer/src/relayer/rpc-relayer/index.ts (364-365)

Slicing a hex string to extract an address (e.g., resultHex.slice(-40)) is brittle and can lead to bugs if the format of the hex string changes. It's more robust to properly decode the return data from the contract call. Using a library like viem or ethers for this would be safer. Also, comparing addresses after converting them to lowercase strings is not ideal. It's better to work with address objects or checksummed strings to ensure correctness.