Description
The three action hooks guard only on the connection status being connected. A restored-but-locked session is connected — that is the CIP-0103 state the package deliberately models — so calls sail through to the SDK and fail there with whatever the wallet reports, instead of failing clearly as "the wallet is locked". useLedger also reports isReady: true while locked, so a dApp gating its UI on that renders an enabled interface that cannot work.
Found by an adversarial review of PR #47.
Steps to reproduce
- Connect a wallet, then lock it (or restore a session that is already locked).
isLocked is true and status is connected.- Call
useExecute().execute(...), useSignMessage().signMessage(...), or a useLedger() call.
- The call reaches the SDK and fails with a wallet-level error.
Expected vs actual behavior
Expected: the hooks refuse while locked, with an error naming the lock, and useLedger().isReady is false.
Actual: the guards pass, the SDK is called, and the failure is reported in the wallet's own terms.
Environment
canton-connect: unpublished, branch feat/1-canton-connect (PR #47)
@canton-network/dapp-sdk: 1.4.0
Additional context
The package already tracks isLocked and documents the locked-but-connected state as a first-class CIP-0103 condition, so the fix is a guard, not new state. README.md currently describes the guard as applying "before connecting", which is what made the gap easy to miss.
Description
The three action hooks guard only on the connection status being
connected. A restored-but-locked session isconnected— that is the CIP-0103 state the package deliberately models — so calls sail through to the SDK and fail there with whatever the wallet reports, instead of failing clearly as "the wallet is locked".useLedgeralso reportsisReady: truewhile locked, so a dApp gating its UI on that renders an enabled interface that cannot work.Found by an adversarial review of PR #47.
Steps to reproduce
isLockedis true and status isconnected.useExecute().execute(...),useSignMessage().signMessage(...), or auseLedger()call.Expected vs actual behavior
Expected: the hooks refuse while locked, with an error naming the lock, and
useLedger().isReadyis false.Actual: the guards pass, the SDK is called, and the failure is reported in the wallet's own terms.
Environment
canton-connect: unpublished, branch feat/1-canton-connect (PR #47) @canton-network/dapp-sdk: 1.4.0Additional context
The package already tracks
isLockedand documents the locked-but-connected state as a first-class CIP-0103 condition, so the fix is a guard, not new state.README.mdcurrently describes the guard as applying "before connecting", which is what made the gap easy to miss.