1.10.15

[Dargon789]

Summary by Sourcery

Add helper utilities for constructing explicit session configurations for the dapp client and record patch releases for multiple packages related to EOA login support.

New Features:

• Introduce typed session duration, native token spending, and explicit session parameter types for dapp client utilities.
• Expose a factory function to build ExplicitSessionConfig objects from high-level parameters, including permissions and native token spending constraints.
• Re-export VALUE_FORWARDER_ADDRESS from the dapp client utils module for external use.

Chores:

• Add a changeset to publish patch releases across multiple @0xsequence packages for dapp client EOA login updates.

[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]

Reviewer's Guide

Adds explicit session configuration utilities to the dapp client to support EOA login, including typed session parameter helpers and re‑exports, and bumps packages via a changeset.

Sequence diagram for creating explicit session config during EOA login

sequenceDiagram
  actor User
  participant Dapp as DappClient
  participant Utils as DappClientUtils
  participant WalletCore

  User->>Dapp: Initiate_EOA_login
  Dapp->>Dapp: Collect_ExplicitSessionParams
  Dapp->>Utils: createExplicitSessionConfig(params)
  Utils->>Utils: Compute_deadline_and_valueLimit
  Utils-->>Dapp: ExplicitSessionConfig
  Dapp->>WalletCore: Start_session_with(ExplicitSessionConfig)
  WalletCore-->>Dapp: Session_established
  Dapp-->>User: Login_successful

Loading

Class diagram for explicit session configuration utilities

classDiagram

class SessionDuration {
  +number days
  +number hours
  +number minutes
}

class NativeTokenSpending {
  +bigint valueLimit
  +Address_Address[] allowedRecipients
}

class ExplicitSessionParams {
  +number chainId
  +SessionDuration expiresIn
  +Permission_Permission[] permissions
  +NativeTokenSpending nativeTokenSpending
}

class ExplicitSessionConfig {
}

class Permission_Permission {
}

class Address_Address {
}

class DappClientUtils {
  +createExplicitSessionConfig(params: ExplicitSessionParams): ExplicitSessionConfig
}

ExplicitSessionParams --> SessionDuration : has
ExplicitSessionParams --> NativeTokenSpending : optional
ExplicitSessionParams --> Permission_Permission : uses
NativeTokenSpending --> Address_Address : allowedRecipients
DappClientUtils --> ExplicitSessionParams : input
DappClientUtils --> ExplicitSessionConfig : output

Loading

File-Level Changes

Change	Details	Files
Introduce helpers and types to build ExplicitSessionConfig for explicit sessions, including support for native token spending constraints.	Import ExplicitSessionConfig type from wallet-core, Permission from wallet-primitives, and Address type plus re-export VALUE_FORWARDER_ADDRESS from local constants Define SessionDuration, NativeTokenSpending, and ExplicitSessionParams types to describe session lifetime, permissions, and optional native token spending limits Implement createExplicitSessionConfig utility that computes a deadline from a human-readable duration, validates presence of at least one permission, folds in optional native token spending settings into valueLimit and additional permissions, and returns an ExplicitSessionConfig object	packages/wallet/dapp-client/src/utils/index.ts
Register a changeset to release patch updates across multiple packages for the dapp client EOA login changes.	Add a new changeset file declaring patch version bumps for various @0xsequence packages Document that the changes are related to dapp client updates for EOA login	.changeset/tiny-files-chew.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 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.

[sourcery-ai]

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

• Consider validating SessionDuration (e.g., disallow negative or non-integer values and guard against the all-zero case) so sessionLifetimeSeconds and deadline don’t end up as unexpected values like immediate expiry or huge numbers.
• In createExplicitSessionConfig, it might be worth explicitly handling the case where nativeTokenSpending.valueLimit is set but allowedRecipients is omitted/empty, to clarify whether a global value limit without per-recipient rules is intentional or should be constrained.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Consider validating `SessionDuration` (e.g., disallow negative or non-integer values and guard against the all-zero case) so `sessionLifetimeSeconds` and `deadline` don’t end up as unexpected values like immediate expiry or huge numbers.
- In `createExplicitSessionConfig`, it might be worth explicitly handling the case where `nativeTokenSpending.valueLimit` is set but `allowedRecipients` is omitted/empty, to clarify whether a global value limit without per-recipient rules is intentional or should be constrained.

## Individual Comments

### Comment 1
<location> `packages/wallet/dapp-client/src/utils/index.ts:149-150` </location>
<code_context>
+
+export const createExplicitSessionConfig = (params: ExplicitSessionParams): ExplicitSessionConfig => {
+  const nowInSeconds = BigInt(Math.floor(Date.now() / 1000))
+  const { days = 0, hours = 0, minutes = 0 } = params.expiresIn
+  const sessionLifetimeSeconds = days * 24 * 60 * 60 + hours * 60 * 60 + minutes * 60
+  const deadline = nowInSeconds + BigInt(sessionLifetimeSeconds)
+
</code_context>

<issue_to_address>
**issue (bug_risk):** Handle non-integer and large duration values more defensively before converting to BigInt.

`sessionLifetimeSeconds` is computed as a `number` and only converted at the end. If `expiresIn` contains non-integer values (e.g. `0.5` hours), `BigInt(sessionLifetimeSeconds)` will throw. Large durations might also exceed `Number.MAX_SAFE_INTEGER`, causing precision loss before conversion. Consider normalizing input (e.g. `Math.floor`) and/or doing the arithmetic in `BigInt` from the start, or validating that the seconds value is a safe integer before converting.
</issue_to_address>

### Comment 2
<location> `packages/wallet/dapp-client/src/utils/index.ts:148-151` </location>
<code_context>
+  const nowInSeconds = BigInt(Math.floor(Date.now() / 1000))
+  const { days = 0, hours = 0, minutes = 0 } = params.expiresIn
+  const sessionLifetimeSeconds = days * 24 * 60 * 60 + hours * 60 * 60 + minutes * 60
+  const deadline = nowInSeconds + BigInt(sessionLifetimeSeconds)
+
+  if (params.permissions.length === 0) {
</code_context>

<issue_to_address>
**suggestion:** Consider validating that the computed session lifetime is positive and non-zero.

If `days`, `hours`, and `minutes` all use their defaults, `sessionLifetimeSeconds` is `0`, so `deadline` == `nowInSeconds` and the session expires immediately. If that’s not desired, consider validating that the lifetime is > 0 and either throwing or enforcing a minimum duration.

```suggestion
  const nowInSeconds = BigInt(Math.floor(Date.now() / 1000))
  const { days = 0, hours = 0, minutes = 0 } = params.expiresIn
  const sessionLifetimeSeconds = days * 24 * 60 * 60 + hours * 60 * 60 + minutes * 60

  if (sessionLifetimeSeconds <= 0) {
    throw new Error(
      'createExplicitSessionConfig: Session lifetime must be greater than 0 seconds. ' +
      'Please provide a non-zero duration in expiresIn.',
    )
  }

  const deadline = nowInSeconds + BigInt(sessionLifetimeSeconds)
```
</issue_to_address>

### Comment 3
<location> `packages/wallet/dapp-client/src/utils/index.ts:160-162` </location>
<code_context>
+  const nativeTokenSpending = params.nativeTokenSpending
+  const valueLimit = nativeTokenSpending?.valueLimit ?? 0n
+  const nativeTokenReceivers = [...(nativeTokenSpending?.allowedRecipients || [])]
+  const nativeTokenSpendingPermissions = nativeTokenReceivers.map((receiver) => ({
+    target: receiver,
+    rules: [],
+  }))
+
</code_context>

<issue_to_address>
**question (bug_risk):** Clarify whether an empty `rules` array matches the intended semantics for native token spending permissions.

`nativeTokenSpending` currently maps each allowed recipient to `{ target: receiver, rules: [] }`. Depending on how `Permission` is evaluated, `rules: []` may either mean “unrestricted spend” or “no effective permission”. Consider either adding an explicit default rule or confirming that the downstream permission logic interprets an empty `rules` array exactly as intended for this use case.
</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.}