feat(express): verify created addresses against client-supplied trusted keychains#9109
Merged
rajangarg047 merged 1 commit intoJun 25, 2026
Merged
Conversation
Contributor
d92773f to
16a192b
Compare
…ed keychains Add an opt-in "bring your own trusted keys" check to address creation. When the createAddress request includes trustedKeychains (public key material the caller holds independently), Express locally re-derives each newly created address via coin.deriveAddress and fails the request if it does not match what the service returned — an independent verification folded into the create call, with no client-side round-trip. Unlike the SDK's built-in check (which verifies using keychains fetched from the same service), this uses caller-supplied keys, so a match is an independent trust guarantee. It is purely per-request opt-in: requests without trustedKeychains are unchanged, so other clients/coins are unaffected, and no server config is needed. The caller opted in, so an unsupported coin/wallet surfaces a clear 400 rather than silently skipping. The createAddress result is modeled as a CreateAddressResult type (reusing DeriveAddressOptions types) instead of any, and derivation failures and mismatches alike map to 400. Token (e.g. SPL) deposit addresses derive differently and are not verified here yet (follows WCN-1054). WCN-1055 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
16a192b to
e5129b5
Compare
pranishnepal
approved these changes
Jun 25, 2026
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
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
Adds an opt-in "bring your own trusted keys" check to address creation. When a
createAddressrequest includestrustedKeychains(public key material the caller holds independently), Express locally re-derives each newly created address viacoin.deriveAddressand fails the request (400) if it doesn't match the address the service returned — an independent verification folded into the create call, no client-side round-trip.Why this (and how it differs from the SDK's existing check)
wallet.createAddressalready verifies the new address — but using keychains it fetches from the same service (an integrity check; circular). This feature verifies against caller-supplied keys, so a match is an independent trust guarantee.Key properties:
trustedKeychainsare completely unchanged — so other clients/coins are unaffected and no server config/flag is needed.Scope note
Token (e.g. SPL) deposit addresses derive differently (associated token account) and are not verified here yet — that path depends on token derivation (WCN-1054, PR #9080) and is a fast-follow. Token-address creates (
onToken) are skipped rather than mismatched.Changes
trustedKeychainsto thecreateAddressbody (reuses theaddress/derivekeychain union codec).handleV2CreateAddressrunsverifyCreatedAddressesWithTrustedKeyswhen the field is present.Context
WCN-1055 (FR-465 Phase 2) — requested by Bullish. Chose the client-supplied-keys approach (vs an operator keystore) so it's a single transparent create call with the full independent-trust guarantee and no server-side key management.
Test plan
tscclean (express src);eslint0 errorsonToken→ skipped🤖 Generated with Claude Code