Main

[Dargon789]

Summary by Sourcery

Add Safe-compatible batch transaction capabilities for Gnosis accounts, tighten NFT media URL handling, and upgrade core dependencies and tooling versions.

New Features:

• Expose walletGetCapabilities and walletSendCalls provider methods to support Safe-compatible batch calls for Gnosis keyring accounts.
• Add Gnosis keyring support for building multi-send batch Safe transactions.

Bug Fixes:

• Sanitize NFT media URLs to avoid using invalid, empty, or obviously local/private HTTP URLs and ensure previews fall back safely.
• Preserve and propagate the Safe operation field through the SignTx approval flow for Gnosis transactions.

Enhancements:

• Introduce a CircleCI config to run a basic workflow on repository checkout.
• Add a SECURITY policy document describing supported versions and vulnerability reporting.
• Upgrade multiple runtime and dev dependencies, including ethers, eslint, jest, webpack, and related tooling.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[sourcery-ai]

Reviewer's Guide

Implements Safe (Gnosis) wallet batch transaction support and capability discovery in the provider, extends the Gnosis keyring with batch-building logic, hardens NFT media URL handling, wires Safe operation handling into the signing UI, adds CircleCI scaffolding and security policy docs, and bumps several core dependencies including ethers to v6 and various tooling libraries.

Sequence diagram for Safe walletSendCalls batch transaction flow

sequenceDiagram
  actor Dapp
  participant ProviderController
  participant KeyringService
  participant GnosisKeyring
  participant PermissionService
  participant RPCService
  participant EthersProvider
  participant SafeSDK
  participant NotificationService
  actor User

  Dapp->>ProviderController: walletSendCalls(req)
  ProviderController->>ProviderController: validate account is GnosisKeyring and from matches
  ProviderController->>KeyringService: getKeyringByType(GnosisKeyring)
  KeyringService-->>ProviderController: GnosisKeyring

  ProviderController->>PermissionService: getWithoutUpdate(origin)
  PermissionService-->>ProviderController: chain
  ProviderController->>RPCService: getRPCByChain(chain)
  RPCService-->>ProviderController: customRpc or null
  ProviderController->>RPCService: getDefaultRPC(serverId)
  RPCService-->>ProviderController: defaultRpc
  ProviderController->>EthersProvider: new JsonRpcProvider(rpcUrl)
  EthersProvider-->>ProviderController: provider

  ProviderController->>SafeSDK: getSafeVersion(address, provider)
  SafeSDK-->>ProviderController: version

  ProviderController->>GnosisKeyring: buildBatchTransaction(from, calls, provider, version, network)
  GnosisKeyring->>SafeSDK: new Safe(address, version, provider, networkId)
  GnosisKeyring->>SafeSDK: encodeMultiSendData(calls)
  GnosisKeyring->>SafeSDK: getMultiSendContract(safeProvider, version)
  GnosisKeyring->>SafeSDK: buildTransaction(multiSendTx)
  SafeSDK-->>GnosisKeyring: safeTransaction
  GnosisKeyring->>SafeSDK: getTransactionHash(safeTransaction)
  SafeSDK-->>GnosisKeyring: transactionHash
  GnosisKeyring-->>ProviderController: safeTransaction

  ProviderController->>NotificationService: requestApproval(SignTx, gnosis_tx_params)
  NotificationService->>User: show SignTx with operation and batch info
  User-->>NotificationService: approve or reject
  loop optional uiRequestComponent loop
    NotificationService-->>ProviderController: uiRequestComponent or final result
    ProviderController->>NotificationService: requestApproval(next_ui)
    NotificationService->>User: show next step
    User-->>NotificationService: approve
  end
  NotificationService-->>ProviderController: approvalResult

  ProviderController-->>Dapp: [currentTransactionHash]

Loading

Updated class diagram for ProviderController and GnosisKeyring Safe batch support

classDiagram
  class ProviderController {
    +walletGetCapabilities(req ProviderRequest) Promise~Record~string,object~~
    +walletSendCalls(req ProviderRequest) Promise~string[]~
  }

  class GnosisKeyring {
    -accounts string[]
    -networkIdsMap Record~string, string[]~
    -safeInstance Safe
    -currentTransaction object
    -currentTransactionHash string
    +buildBatchTransaction(address string, transactions SafeTransactionDataPartial[], provider any, version SafeVersion, networkId string) Promise~object~
    +validateTransaction(params object) Promise~object~
    +buildGnosisTransaction(params object) Promise~object~
  }

  class Safe {
    +Safe(address string, version SafeVersion, provider any, networkId string)
    +buildTransaction(tx object) Promise~object~
    +getTransactionHash(tx object) Promise~string~
  }

  class SafeProvider {
    +SafeProvider(options object)
  }

  class NotificationService {
    +requestApproval(options object) Promise~object~
  }

  class RPCService {
    +getRPCByChain(chain CHAINS_ENUM) object
    +getDefaultRPC(serverId string) object
  }

  class PermissionService {
    +getWithoutUpdate(origin string) object
  }

  ProviderController --> GnosisKeyring : uses
  ProviderController --> NotificationService : uses
  ProviderController --> RPCService : uses
  ProviderController --> PermissionService : uses
  GnosisKeyring --> Safe : composes
  GnosisKeyring --> SafeProvider : uses

Loading

Architecture diagram for new CircleCI workflow

flowchart LR
  GitHubRepo[Rabby GitHub repository]
  CircleCIWorkflow[CircleCI my-custom-workflow]
  CircleCIJob[CircleCI job my-job-name]
  Executor[CircleCI executor my-custom-executor]
  DockerImage[cimg/base:stable]

  GitHubRepo --> CircleCIWorkflow
  CircleCIWorkflow --> CircleCIJob
  CircleCIJob --> Executor
  Executor --> DockerImage
  CircleCIJob --> CheckoutStep[Checkout source]
  CircleCIJob --> RunStep[Run custom commands]

Loading

File-Level Changes

Change	Details	Files
Add Safe-specific provider methods for capability discovery and batched transaction sending for Gnosis (Safe) accounts.	Introduce walletGetCapabilities method with SAFE metadata to return atomicBatch support per network for Gnosis accounts, including authorization checks and keyring-based network resolution. Introduce walletSendCalls method with SAFE metadata to construct and submit batched Safe transactions via the Gnosis keyring, performing account-type validation, chain/RPC resolution, Safe version lookup, and integrating with the approval notification flow. Leverage ethers JsonRpcProvider and Safe SDK to determine Safe version and delegate batch transaction building to the Gnosis keyring, then return the resulting transaction hash to the caller.	src/background/controller/provider/controller.ts
Extend Gnosis keyring with Safe batch transaction construction using MultiSend and Safe SDK.	Add buildBatchTransaction to validate the Safe address, instantiate a Safe instance, encode multi-send data for a list of partial transactions, and wrap it into a delegate-call transaction to the MultiSend contract. Use SafeProvider and getMultiSendContract helpers to resolve the MultiSend contract and encode the multiSend call data, then build the Safe transaction, cache it on the keyring, and compute its transaction hash for later retrieval.	src/background/service/keyring/eth-gnosis-keyring.ts
Sanitize NFT media URLs to avoid obviously local/private URLs and ensure safe rendering in both thumbnail and preview components.	Enhance isValidHttpUrl to trim input, enforce http/https and non-empty hostname, and block localhost and common private IP ranges (10.x, 192.168.x, 172.16–31.x). Ensure Thumbnail and Preview components use a sanitizedUrl derived from isValidHttpUrl when deciding whether to show remote images/videos, falling back to placeholders when invalid.	src/ui/views/Dashboard/components/NFT/NFTAvatar.tsx
Propagate Safe transaction operation field through the SignTx approval UI and into Gnosis transaction building.	Include operation in normalized transaction params derived from SignTx input. Pass operation through the data used for on-chain transaction preview and signing, including when calling wallet.buildGnosisTransaction so the Safe transaction reflects the correct operation type.	src/ui/views/Approval/components/SignTx.tsx
Upgrade multiple runtime and build-time dependencies, including ethers to v6 and various SDK, linting, bundling, and tooling packages.	Bump @coinbase/wallet-sdk, @eth-optimism/contracts, several Keystone packages, lodash, nanoid, patch-package, web3-eth-abi and others to newer versions. Upgrade dev tooling such as @svgr/webpack, eslint, gulp, jest, postcss-custom-properties, shelljs, tailwindcss, webpack, webpack-bundle-analyzer, and webpack-dev-server to more recent major/minor versions. These upgrades may introduce API changes (notably ethers v6) that require compatibility verification across the codebase.	package.json yarn.lock
Introduce basic CI configuration and a security policy document.	Add minimal CircleCI configuration defining a docker-based executor and a placeholder job/workflow, with Docker Hub auth environment variables referenced. Add SECURITY.md describing supported versions and general guidance for reporting vulnerabilities (currently mostly template content).	.circleci/config.yml SECURITY.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[snyk-io]

⚠️ Snyk checks are incomplete.

Status	Scanner	Critical	High	Medium	Low	Total (0)
⚠️	Open Source Security	0	0	0	0	See details

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

[sourcery-ai]

Hey - I've found 2 issues, and left some high level feedback:

• After bumping ethers to 6.0.0, walletSendCalls still uses v5-style APIs (ethers.providers.JsonRpcProvider, casting to ethers.providers.Web3Provider, and provider.send), which are either removed or changed in v6; it would be safer to centralize provider construction and update these usages to the v6-compatible pattern rather than relying on casts that may hide runtime incompatibilities.
• walletSendCalls destructures capabilities from the request data but never uses it; if capabilities are not required for Gnosis batch sends, consider removing this parameter or adding validation/behavior based on it to avoid confusion about the feature surface.
• buildBatchTransaction in eth-gnosis-keyring.ts accepts provider and networkId as untyped/loosely-typed values and then wraps provider in a custom SafeProvider; tightening these types (e.g., to the concrete ethers provider type you expect) would make the Safe integration easier to reason about and reduce the risk of subtle provider mismatches at runtime.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- After bumping `ethers` to `6.0.0`, `walletSendCalls` still uses v5-style APIs (`ethers.providers.JsonRpcProvider`, casting to `ethers.providers.Web3Provider`, and `provider.send`), which are either removed or changed in v6; it would be safer to centralize provider construction and update these usages to the v6-compatible pattern rather than relying on casts that may hide runtime incompatibilities.
- `walletSendCalls` destructures `capabilities` from the request data but never uses it; if capabilities are not required for Gnosis batch sends, consider removing this parameter or adding validation/behavior based on it to avoid confusion about the feature surface.
- `buildBatchTransaction` in `eth-gnosis-keyring.ts` accepts `provider` and `networkId` as untyped/loosely-typed values and then wraps `provider` in a custom `SafeProvider`; tightening these types (e.g., to the concrete ethers provider type you expect) would make the Safe integration easier to reason about and reduce the risk of subtle provider mismatches at runtime.

## Individual Comments

### Comment 1
<location> `src/background/controller/provider/controller.ts:1619-1623` </location>
<code_context>
+      });
+    }
+
+    const provider = new ethers.providers.JsonRpcProvider(rpcUrl);
+
+    const version = await Safe.getSafeVersion({
+      address: from,
+      provider: (provider as unknown) as ethers.providers.Web3Provider,
+    });
+
</code_context>

<issue_to_address>
**issue (bug_risk):** Ethers v6 upgrade is likely incompatible with `ethers.providers.JsonRpcProvider` and `Web3Provider` usage here.

With `ethers@6`, `ethers.providers.*` and `Web3Provider` are no longer exposed as in v5: `JsonRpcProvider` is now `ethers.JsonRpcProvider`, and `Web3Provider` is effectively replaced by `BrowserProvider`. This cast from `JsonRpcProvider` to `Web3Provider` is therefore very likely to fail at runtime after the upgrade. Please update the provider construction to the v6 API and adapt what you pass into `Safe.getSafeVersion` (e.g. via an EIP‑1193 wrapper or v6‑compatible provider type) instead of relying on this cast.
</issue_to_address>

### Comment 2
<location> `src/background/controller/provider/controller.ts:1574` </location>
<code_context>
+      data: { params },
+    } = req;
+    const [data] = params || [];
+    const { from, calls, capabilities } = data;
+    const account =
+      req.account || preferenceService.getCurrentAccount() || undefined;
</code_context>

<issue_to_address>
**suggestion:** `capabilities` argument is parsed but never used in `walletSendCalls`.

`capabilities` is destructured from `data` but never used. If this field is not needed, it should be removed; if it is part of the `wallet_sendCalls` contract (e.g., for capability gating like `atomicBatch`), it should be incorporated into validation or behavior so the handler matches the spec.

Suggested implementation:

```typescript
    const [data] = params || [];
    const { from, calls } = data;

```

If the request type for `wallet_sendCalls` (e.g., a TypeScript interface or type for `data`) currently includes a `capabilities` field, you should remove it or mark it as optional/unused to keep the types in sync with this change.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}