Skip to content

feat(core): adapter capabilities, signerAddress & fetchAccount#97

Open
Sanka-D wants to merge 1 commit into
XRPL-Commons:developfrom
Sanka-D:feat/adapter-capabilities-contract
Open

feat(core): adapter capabilities, signerAddress & fetchAccount#97
Sanka-D wants to merge 1 commit into
XRPL-Commons:developfrom
Sanka-D:feat/adapter-capabilities-contract

Conversation

@Sanka-D

@Sanka-D Sanka-D commented Jul 1, 2026

Copy link
Copy Markdown

Part 1/4 of closing the feature gap surfaced by comparing xrpl-connect with Stellar Wallets Kit. All additive & backward compatible.

What & why

1. Declarative adapter capabilities (gap #4)

Some adapters expose signing methods that don't actually work — signMessage is a stub on Xaman (returns an empty signature) and throws UNSUPPORTED_METHOD on WalletConnect. Consumers only discovered this at call time.

  • WalletAdapter.capabilities?: WalletCapabilities ({ sign?, signAndSubmit?, signMessage? }).
  • WalletManager.supports(capability) → tells apps up-front what the connected wallet can do (e.g. hide a "Sign message" button).
  • The manager now throws a typed UNSUPPORTED_METHOD before invoking an adapter that declares the op unsupported.
  • Xaman & WalletConnect declare signMessage: false.
  • Undeclared flags default to true (adapterSupports() / CAPABILITY_DEFAULTS), so every existing adapter keeps working unchanged.

Mirrors SWK's per-module capability gating (signAndSubmitTransaction? optional + clear "not supported" error).

2. signerAddress on sign results (gap #7)

SignedTransaction / SignedMessage gain signerAddress. The manager stamps it with the connected account when the adapter omits it, so callers always know which account produced a signature (matters for multi-account / hardware). Never overwrites a value the adapter already set.

3. fetchAccount() + skipRequestAccess (gap #8)

  • WalletManager.fetchAccount() — live re-fetch from the wallet + refresh the cached account, emitting accountChanged on difference. This is SWK's getAddress (cached) vs fetchAddress (live) distinction, which we only had half of.
  • ConnectOptions.skipRequestAccess — now a documented first-class option (SEP-43 parity); adapters may honour it.

Changes

  • packages/core/src/types.tsWalletCapabilities, adapterSupports, CAPABILITY_DEFAULTS, capabilities on WalletAdapter, signerAddress on sign results, skipRequestAccess on ConnectOptions.
  • packages/core/src/wallet-manager.ts — capability gating, signerAddress stamping, supports(), fetchAccount().
  • packages/core/src/index.ts — exports.
  • packages/adapters/{xaman,walletconnect} — declare signMessage: false.
  • packages/core/tests/wallet-manager.test.ts — +7 tests.

Verification

  • pnpm build (full workspace, 13/13) ✅
  • pnpm test — core 20 passed (+7), xaman 8, walletconnect 10 ✅
  • pnpm lint ✅ · prettier --check

🤖 Generated with Claude Code

…count

Brings three SEP-43-inspired additions xrpl-connect lacked vs Stellar Wallets
Kit, all backward compatible:

- Capabilities: WalletAdapter.capabilities ({ sign, signAndSubmit, signMessage })
  + WalletManager.supports(capability). Operations an adapter declares
  unsupported throw a typed UNSUPPORTED_METHOD before the adapter is called,
  instead of failing deep inside a stub. Xaman and WalletConnect declare
  signMessage: false. Undeclared flags default to true (adapterSupports /
  CAPABILITY_DEFAULTS), so existing adapters are unaffected.
- signerAddress: added to SignedTransaction/SignedMessage; the manager stamps
  the connected account when the adapter omits it, so callers always know which
  account signed.
- fetchAccount(): live re-fetch of the account (vs the cached `account` getter),
  emitting accountChanged on difference. ConnectOptions.skipRequestAccess is now
  a documented first-class option.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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