Skip to content

✨ server: add credential salt to account derivation#1143

Draft
aguxez wants to merge 4 commits into
mainfrom
salt
Draft

✨ server: add credential salt to account derivation#1143
aguxez wants to merge 4 commits into
mainfrom
salt

Conversation

@aguxez

@aguxez aguxez commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Add a credential salt field to the shared credential contract and persist it in the database with validation
  • Use the salt when deriving account addresses and building account init code across server and client flows
  • Return the salt in auth and passkey responses so downstream consumers stay in sync

Testing

  • Updated API tests to assert salt propagation and default salt behavior
  • Not run (not requested)

Summary by CodeRabbit

  • New Features
    • Added credential salt support across account creation, address derivation, authentication, registration, passkey metadata, and credential validation.
    • Authentication and passkey responses now include the credential salt.
    • Account addresses and initialization data now incorporate the configured salt.
  • Bug Fixes
    • Ensured credential salts are stored and validated consistently (with a secure default) and that all related flows derive the same addresses using the same salt.

@changeset-bot

changeset-bot Bot commented Jul 13, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 89dd049

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages
Name Type
@exactly/mobile Patch
@exactly/server Patch
@exactly/common Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@coderabbitai

coderabbitai Bot commented Jul 13, 2026

Copy link
Copy Markdown

Review Change Stack

Walkthrough

Credential salt is added to the shared credential contract, database schema, address derivation, authentication and passkey responses, client account initialization, Intercom flows, tests, and package Changesets.

Changes

Credential salt flow

Layer / File(s) Summary
Salt contract and derivation
common/accountInit.ts, common/deriveAddress.ts, common/validation.ts
Credential validation, address derivation, and account initialization now accept optional salt values and encode them into derived addresses and creation calldata.
Salt storage and server responses
server/database/schema.ts, server/api/auth/authentication.ts, server/api/auth/registration.ts, server/api/passkey.ts, server/utils/createCredential.ts
Credentials store a validated non-null salt, while server authentication, registration, passkey, and credential creation paths select, use, and return it.
Client credential propagation
src/utils/server.ts, src/utils/accountClient.ts
Client credential state, Intercom address derivation, account client creation, and account initialization code now carry salt.
Flow validation and release metadata
server/test/api/auth.test.ts, .changeset/*
Authentication tests assert returned salt values, and patch Changesets are added for the common, server, and mobile packages.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant AuthAPI
  participant CredentialsDB
  participant AddressDerivation
  Client->>AuthAPI: Authenticate credential
  AuthAPI->>CredentialsDB: Read credential and salt
  AuthAPI->>AddressDerivation: Derive account with factory, x, y, and salt
  AddressDerivation-->>AuthAPI: Derived account address
  AuthAPI-->>Client: Authentication response including salt
Loading

Possibly related issues

Possibly related PRs

  • exactly/exa#1089: Both PRs modify credential creation and authentication derivation inputs in server/utils/createCredential.ts and related flows.

Suggested reviewers: cruzdanilo, nfmelendez, franm91

🚥 Pre-merge checks | ✅ 4
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title is concise and correctly reflects a major part of the change, though it doesn’t mention the broader shared contract and persistence updates.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch salt
✨ Simplify code
  • Create PR with simplified code
  • Commit simplified code in branch salt

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@cruzdanilo cruzdanilo changed the title Add credential salt to account derivation ✨ server: add credential salt to account derivation Jul 13, 2026

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a credential salt for address derivation and account initialization across the common, server, and mobile packages. It adds a salt column with a hex check constraint to the database schema, updates API endpoints (authentication, registration, and passkey) to retrieve and return the salt, and integrates it into the account client creation process. There are no review comments, so I have no feedback to provide.

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.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1


ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 7163f50a-fc04-4626-aa68-304a73dc98f3

📥 Commits

Reviewing files that changed from the base of the PR and between f0f3659 and 5aeb5aa.

📒 Files selected for processing (14)
  • .changeset/fuzzy-cows-breathe.md
  • .changeset/neat-eggs-turn.md
  • .changeset/quick-koalas-thread.md
  • common/accountInit.ts
  • common/deriveAddress.ts
  • common/validation.ts
  • server/api/auth/authentication.ts
  • server/api/auth/registration.ts
  • server/api/passkey.ts
  • server/database/schema.ts
  • server/test/api/auth.test.ts
  • server/utils/createCredential.ts
  • src/utils/accountClient.ts
  • src/utils/server.ts

const authResponse = parse(Authentication, await response.json());

assert.ok(authResponse.intercomToken);
expect(authResponse.salt).toBe(zeroAddress);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add an end-to-end non-default salt test.

All four assertions validate only zeroAddress, so a regression that discards a stored custom salt and returns the default would pass. Add one persisted non-zero salt fixture and assert the exact value through authentication and registration.

📍 Affects 1 file
  • server/test/api/auth.test.ts#L87-L87 (this comment)
  • server/test/api/auth.test.ts#L469-L470
  • server/test/api/auth.test.ts#L566-L568
  • server/test/api/auth.test.ts#L714-L715

@aguxez

aguxez commented Jul 13, 2026

Copy link
Copy Markdown
Contributor Author

close #1143

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2


ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 0a3fdbee-d558-4037-889e-3f4d6bcfe5b1

📥 Commits

Reviewing files that changed from the base of the PR and between 5aeb5aa and 89dd049.

📒 Files selected for processing (14)
  • .changeset/fuzzy-cows-breathe.md
  • .changeset/neat-eggs-turn.md
  • .changeset/quick-koalas-thread.md
  • common/accountInit.ts
  • common/deriveAddress.ts
  • common/validation.ts
  • server/api/auth/authentication.ts
  • server/api/auth/registration.ts
  • server/api/passkey.ts
  • server/database/schema.ts
  • server/test/api/auth.test.ts
  • server/utils/createCredential.ts
  • src/utils/accountClient.ts
  • src/utils/server.ts

Comment thread server/api/passkey.ts
Comment on lines 40 to 42
factory: parse(Address, credential.factory),
salt: credential.salt,
...decodePublicKey(credential.publicKey),

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🔴 Critical | ⚡ Quick win

Parse the salt to ensure proper validation, checksumming, and type safety.

Since factory is explicitly parsed to satisfy the Address brand and apply checksumming, the raw credential.salt from the database should be parsed similarly. Passing the raw Drizzle property risks TypeScript errors (due to a missing Address brand and potential null incompatibility vs undefined), and bypasses backend validation.

🛡️ Proposed fix to ensure type safety and checksum validation
         factory: parse(Address, credential.factory),
-        salt: credential.salt,
+        salt: credential.salt ? parse(Address, credential.salt) : undefined,
         ...decodePublicKey(credential.publicKey),
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
factory: parse(Address, credential.factory),
salt: credential.salt,
...decodePublicKey(credential.publicKey),
factory: parse(Address, credential.factory),
salt: credential.salt ? parse(Address, credential.salt) : undefined,
...decodePublicKey(credential.publicKey),

Comment thread server/database/schema.ts
({ account, bridgeId, salt }) => [
uniqueIndex("account_index").on(account),
uniqueIndex("bridge_id_index").on(bridgeId),
check("credentials_salt_hex_check", sql`${salt} ~ '^0x[0-9a-fA-F]{40}$'`),

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Adjust the regex to allow 32-byte salts.

The credentials_salt_hex_check constraint restricts the salt to exactly 40 hex characters (20 bytes), which matches an address size. However, standard CREATE2 salts are encoded as uint256 and are typically 32 bytes (up to 64 hex characters). If the intent is to support generic salts, the regex should allow up to 64 characters to prevent rejecting valid 32-byte salts.

💡 Proposed fix
-    check("credentials_salt_hex_check", sql`${salt} ~ '^0x[0-9a-fA-F]{40}$'`),
+    check("credentials_salt_hex_check", sql`${salt} ~ '^0x[0-9a-fA-F]{1,64}$'`),
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
check("credentials_salt_hex_check", sql`${salt} ~ '^0x[0-9a-fA-F]{40}$'`),
check("credentials_salt_hex_check", sql`${salt} ~ '^0x[0-9a-fA-F]{1,64}$'`),

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant