Conversation
|
|
Review or Edit in CodeSandboxOpen the branch in Web Editor • VS Code • Insiders |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
Reviewer's GuideImplements EIP-5792-style multi-call support and preconditions across provider, relayer, wallet, account, and API layers, refactors transaction sending to accept richer options, and wires new RPC and client surfaces for batched calls and capability discovery. Sequence diagram for wallet_sendCalls multi-call with preconditions (EIP-5792)sequenceDiagram
actor User
participant SequenceSigner
participant SequenceClient
participant SequenceProvider as Provider
participant WalletRequestHandler as RequestHandler
participant Account
participant Relayer
User->>SequenceSigner: sendTransaction(transaction[], { chainId, preconditions })
SequenceSigner->>SequenceClient: sendTransaction(transaction[], { chainId, preconditions })
SequenceClient->>SequenceClient: encodePrecondition(preconditions)
SequenceClient->>SequenceProvider: request(wallet_sendCalls, params, chainId)
SequenceProvider->>RequestHandler: handle(wallet_sendCalls, request)
RequestHandler->>RequestHandler: validateTransactionRequest(account.address, call)
alt prompter exists
RequestHandler->>RequestHandler: prompter.promptSendTransaction([{ chainId, transactions }], { preconditions })
RequestHandler-->>SequenceProvider: JSON.stringify(hashes)
else no prompter
RequestHandler->>Account: sendTransaction(transactionish, chainId, { preconditions })
Account->>Relayer: relay(intendedBundle, { quote, preconditions, waitForReceipt })
Relayer-->>Account: TransactionResponse
Account-->>RequestHandler: metaTxn hash
RequestHandler-->>SequenceProvider: JSON.stringify(hashes)
end
SequenceProvider-->>SequenceClient: JSON result
SequenceClient->>SequenceClient: decode JSON
SequenceClient-->>SequenceSigner: txnHash for chainId
SequenceSigner-->>User: commons.transaction.TransactionResponse
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 7 issues, and left some high level feedback:
- The new
SequenceClient.sendTransactionexpectswallet_sendCallsto return a JSON object keyed by chainId, butwallet_sendCallscurrently returns a JSON stringified array of hashes, so indexing with[ethers.toQuantity(chainId)]will yieldundefined; align the response shape or the client parsing. - In
SequenceClient.sendTransaction,ethers.resolveAddress(to)is used withoutawait, but it is asynchronous in ethers v6, so this will pass a Promise instead of a string into the call payload; resolve the address before constructing thecallsarray.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The new `SequenceClient.sendTransaction` expects `wallet_sendCalls` to return a JSON object keyed by chainId, but `wallet_sendCalls` currently returns a JSON stringified array of hashes, so indexing with `[ethers.toQuantity(chainId)]` will yield `undefined`; align the response shape or the client parsing.
- In `SequenceClient.sendTransaction`, `ethers.resolveAddress(to)` is used without `await`, but it is asynchronous in ethers v6, so this will pass a Promise instead of a string into the call payload; resolve the address before constructing the `calls` array.
## Individual Comments
### Comment 1
<location path="packages/provider/src/transports/wallet-request-handler.ts" line_range="610-611" />
<code_context>
+ throw new Error(`wallet_sendCalls capabilities '${JSON.stringify(capabilities)}' is invalid`)
+ }
+
+ let preconditions: Precondition[] | undefined
+ if (capabilities.preconditions !== undefined) {
+ if (!(capabilities.preconditions instanceof Array) || !capabilities.preconditions.every(isPrecondition)) {
+ throw new Error(`wallet_sendCalls preconditions '${JSON.stringify(capabilities.preconditions)}' is invalid`)
</code_context>
<issue_to_address>
**issue (bug_risk):** Accessing capabilities.preconditions without guarding for undefined will throw a runtime error.
If `capabilities` can be `undefined`, this condition will throw a `TypeError` before the intended validation runs. Please guard `capabilities` first, e.g.:
```ts
if (capabilities && capabilities.preconditions !== undefined) {
...
}
```
</issue_to_address>
### Comment 2
<location path="packages/provider/src/transports/wallet-request-handler.ts" line_range="618-620" />
<code_context>
+ preconditions = capabilities.preconditions
+ }
+
+ if (this.prompter) {
+ return JSON.stringify(
+ await this.prompter.promptSendTransaction(
+ calls.map((call: any) => ({ ...call, chainId: call.chainId !== undefined ? Number(call.chainId) : undefined })),
+ { ...request, preconditions }
</code_context>
<issue_to_address>
**issue (bug_risk):** The promptSendTransaction call does not match the updated prompter interface and the response shape used by the client.
`WalletUserPrompter.promptSendTransaction` now takes an array of `{ chainId?: number; transactions: commons.transaction.Transactionish }` plus an `options` object, and returns `string[]`. This code passes each `call` directly and uses `{ ...request, preconditions }` as options, which includes extra fields beyond `{ origin, projectAccessKey, preconditions }`. Also, `SequenceClient.sendTransaction` expects `wallet_sendCalls` to return a JSON object keyed by `chainId`, but both the prompter and non-prompter paths currently return an array. Please (1) wrap each call as `{ chainId: Number(call.chainId), transactions: call }`, (2) pass only the required options fields, and (3) update the return shape to the keyed-by-chainId object the client expects.
</issue_to_address>
### Comment 3
<location path="packages/provider/src/client.ts" line_range="509-510" />
<code_context>
+ {
+ version: '1.0',
+ from: this.getAddress(),
+ calls: transactions.map(({ to, value, data }) => ({
+ to: to ? ethers.resolveAddress(to) : undefined,
+ value: value !== undefined && value !== null ? ethers.toQuantity(value) : undefined,
+ data: data || undefined,
</code_context>
<issue_to_address>
**issue (bug_risk):** ethers.resolveAddress is async and should not be used directly in a synchronous mapping.
`ethers.resolveAddress` returns a Promise, so using it directly in the `map` makes `to` a Promise in the `calls` payload instead of a resolved address, causing the JSON-RPC request to fail. You should either resolve all `to` values before building `calls` (e.g. `await Promise.all(...)` and then map over the resolved addresses) or require `to` to already be a checksummed address and skip `resolveAddress` here.
</issue_to_address>
### Comment 4
<location path="packages/relayer/src/rpc-relayer/index.ts" line_range="216-219" />
<code_context>
- const data = commons.transaction.encodeBundleExecData(signedTxs)
+ const data = commons.transaction.encodeBundleExecData(transactions)
const metaTxn = await this.service.sendMetaTxn(
{
- call: {
- walletAddress: signedTxs.intent.wallet,
- contract: signedTxs.entrypoint,
- input: data
- },
+ call: { walletAddress: transactions.intent.wallet, contract: transactions.entrypoint, input: data },
quote: typecheckedQuote
},
- { ...(projectAccessKey ? { 'X-Access-Key': projectAccessKey } : undefined) }
</code_context>
<issue_to_address>
**issue (bug_risk):** Relay options include preconditions, but they are not forwarded to the relayer RPC despite schema support.
The relayer schema (`SendMetaTxnArgs` in `relayer.gen.ts`) exposes `preconditions?: Array<Precondition>`, and `Relayer.relay` accepts `options?.preconditions`, but `RpcRelayer.relay` ignores them and never passes them to `sendMetaTxn`. If preconditions are meant to be enforced server-side, they should be serialized and included in the call (e.g. `preconditions: options?.preconditions?.map(encodePrecondition)`), otherwise clients will assume preconditions are applied when they are actually dropped.
</issue_to_address>
### Comment 5
<location path="packages/api/src/index.ts" line_range="53-55" />
<code_context>
+ )
+}
+
+export function encodePrecondition(precondition: Precondition): proto.Precondition {
+ const { type, precondition: args } = encodeChainPrecondition(precondition)
+ delete args.chainId
+ return { type, chainID: encodeBigNumberish(precondition.chainId), precondition: args }
+}
</code_context>
<issue_to_address>
**suggestion:** encodePrecondition mutates the object returned by encodeChainPrecondition and relies on deleting chainId in-place.
`encodePrecondition` deletes `chainId` from the object returned by `encodeChainPrecondition`, which may be shared elsewhere and lead to subtle side effects. Instead, clone and omit the field explicitly, e.g. `const { chainId, ...rest } = args`, then return `{ type, chainID: encodeBigNumberish(precondition.chainId), precondition: rest }` so the original object remains unchanged and the omission of `chainId` is explicit.
Suggested implementation:
```typescript
export function encodePrecondition(precondition: Precondition): proto.Precondition {
const { type, precondition: args } = encodeChainPrecondition(precondition)
const { chainId, ...rest } = args
return { type, chainID: encodeBigNumberish(precondition.chainId), precondition: rest }
}
```
If `encodePrecondition` appears multiple times due to a bad merge (the snippet you shared shows some duplication), apply the same replacement to each occurrence so that none of them uses `delete args.chainId`. This ensures all callers benefit from the non-mutating behavior.
</issue_to_address>
### Comment 6
<location path="packages/provider/src/client.ts" line_range="493" />
<code_context>
}
async sendTransaction(
- txs: commons.transaction.Transactionish,
+ transactions: commons.transaction.Transactionish,
</code_context>
<issue_to_address>
**issue (complexity):** Consider extracting the wallet_sendCalls request construction and response parsing into dedicated helper functions so sendTransaction remains a clear, high-level flow.
You can keep the new behavior while reducing complexity by extracting the protocol-specific request/response handling into small helpers. This keeps `sendTransaction` as a high-level helper and makes the response shape explicit.
For example:
```ts
type SendTransactionOptions = OptionalChainId & { preconditions?: Precondition[] }
function buildWalletSendCallsRequest(
from: string,
transactions: ethers.TransactionRequest[],
chainId: number,
options?: SendTransactionOptions
) {
return {
version: '1.0',
from,
calls: transactions.map(({ to, value, data }) => ({
to: to ? ethers.resolveAddress(to) : undefined,
value: value != null ? ethers.toQuantity(value) : undefined,
data: data || undefined,
chainId: ethers.toQuantity(chainId)
})),
capabilities: options?.preconditions
? { preconditions: options.preconditions.map(encodePrecondition) }
: undefined
}
}
function extractSendCallsHashForChain(rawResult: unknown, chainId: number): string {
const parsed = typeof rawResult === 'string' ? JSON.parse(rawResult) : rawResult
const key = ethers.toQuantity(chainId)
return (parsed as Record<string, string>)[key]
}
```
Then `sendTransaction` becomes:
```ts
async sendTransaction(
tx: ethers.TransactionRequest[] | ethers.TransactionRequest,
options?: SendTransactionOptions
): Promise<string> {
const transactions = Array.isArray(tx) ? tx : [tx]
const chainId = options?.chainId ?? this.getChainId()
this.analytics?.track({
event: 'SEND_TRANSACTION_REQUEST',
props: { chainId: chainId.toString() }
})
const rawResult = await this.request({
method: 'wallet_sendCalls',
params: [buildWalletSendCallsRequest(this.getAddress(), transactions, chainId, options)],
chainId
})
return extractSendCallsHashForChain(rawResult, chainId)
}
```
This keeps all functionality (including `wallet_sendCalls` and preconditions), but makes `sendTransaction` read as: normalize inputs → track → build request → send → extract hash, and isolates the protocol-specific details in dedicated helpers.
</issue_to_address>
### Comment 7
<location path="packages/relayer/src/precondition.ts" line_range="26" />
<code_context>
+ )
+}
+
+export function encodePrecondition(precondition: Precondition): proto.Precondition {
+ const { type, precondition: args } = encodeChainPrecondition(precondition)
+ delete args.chainId
</code_context>
<issue_to_address>
**issue (complexity):** Consider extracting shared balance-like encoding logic into a dispatcher-based `encodePrecondition` to remove repetition and make future extensions simpler.
A small refactor can reduce repetition and make future additions easier without changing behavior.
You can factor out the repeated “copy + numeric encoding” logic and use a dispatcher map keyed by `type`. For example:
```ts
type AnyBalancePrecondition = {
address: `0x${string}`
token?: `0x${string}`
tokenId?: ethers.BigNumberish
min?: ethers.BigNumberish
max?: ethers.BigNumberish
}
function encodeBalanceLikePrecondition<T extends AnyBalancePrecondition>(
type: Precondition['type'],
precondition: T
): proto.Precondition {
return {
type,
precondition: {
...precondition,
type: undefined,
tokenId: encodeBigNumberish(precondition.tokenId),
min: encodeBigNumberish(precondition.min),
max: encodeBigNumberish(precondition.max),
},
}
}
```
Then the type‑specific encoders become very small:
```ts
const PRECONDITION_ENCODERS: Record<Precondition['type'], (p: any) => proto.Precondition> = {
'native-balance': p => encodeBalanceLikePrecondition('native-balance', p),
'erc20-balance': p => encodeBalanceLikePrecondition('erc20-balance', p),
'erc20-approval': p => ({
type: p.type,
precondition: { ...p, type: undefined, min: encodeBigNumberish(p.min) },
}),
'erc721-ownership': p => ({
type: p.type,
precondition: {
...p,
type: undefined,
tokenId: encodeBigNumberish(p.tokenId),
owned: p.owned !== false,
},
}),
'erc721-approval': p => ({
type: p.type,
precondition: { ...p, type: undefined, tokenId: encodeBigNumberish(p.tokenId) },
}),
'erc1155-balance': p => encodeBalanceLikePrecondition('erc1155-balance', p),
'erc1155-approval': p => ({
type: p.type,
precondition: {
...p,
type: undefined,
tokenId: encodeBigNumberish(p.tokenId),
min: encodeBigNumberish(p.min),
},
}),
}
export function encodePrecondition(precondition: Precondition): proto.Precondition {
const encoder = PRECONDITION_ENCODERS[precondition.type]
if (!encoder) throw new Error('unreachable')
return encoder(precondition)
}
```
This keeps the special cases (`owned !== false`, required `min`, etc.) but removes the long `if/else` chain and repeated spread/encoding patterns.
Separately, if `isBigNumberish` / `encodeBigNumberish` already exist in `packages/api/src/index.ts`, consider re-exporting them from a shared module and importing here:
```ts
// common.ts
export { isBigNumberish, encodeBigNumberish } from 'packages/api/src/index'
// in this file
import { isBigNumberish, encodeBigNumberish } from '../common'
```
That centralizes BigNumberish handling and avoids future divergence between copies.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by Sourcery
Add support for EIP-5792-style batched wallet calls with optional on/off-chain preconditions and propagate precondition-aware relay options throughout the account, wallet, relayer, and provider stack.
New Features:
Enhancements:
Build: