Resource type: Template
Version: 1.0
Updated: October 20, 2026

Wallet Context Change Test Matrix

Use nine fields to record wallet events, expected session decisions and observed evidence. Includes blank files and a fictional account-switch example.

Wallet provider events feed a nine-field test record; the application policy owns the session decision. A proposed test is not a passed test.

Blank test record

Use this wallet integration test matrix for one transition at a time. In the test ticket, identify the application release, wallet or provider version, environment and approved policy revision. Use a controlled test environment with disposable accounts and no production authority.

Nine-field record to copy into your test system
Field and purpose	Your value
`test_id` A stable reference for one transition and its reruns.	Enter your value.
`initial_account` The exposed account before the event. Use an alias in shared records.	Enter your value.
`initial_chain` The chain ID before the event, with its representation stated.	Enter your value.
`provider_event` The event name and sanitized payload, including the resulting account or chain.	Enter your value.
`session_revision` A non-secret reference to the application session context being evaluated.	Enter your value.
`expected_application_decision` The approved allow, hold, deny or reauthentication rule for this action.	Enter your value.
`observed_result` What actually happened. Keep NOT RUN until the test is executed.	Enter your value.
`evidence_ref` A sanitized trace or test artifact that supports the observed result.	Enter your value.
`owner` The person accountable for resolving a mismatch or missing policy.	Enter your value.

The blank CSV contains four empty rows. Duplicate rows as needed. Keep account aliases consistent across the record and its evidence. Never place a session cookie, access token, seed phrase or private key in these fields.

Four transitions to scope

Each row below is a proposed test. Write the expected decision from your application's policy before running it. The event labels use aliases for readability and are not executable payloads.

Starter scenarios, with no execution results claimed
ID	Provider transition	Policy question	Evidence to collect
WT-01	accountsChanged: account A to account B	Can the existing session authorize the requested action as B?	Event, resulting account and server authorization decision.
WT-02	chainChanged: 0x1 to 0x89	Does the authorized context cover the new chain?	New chain ID and the application decision for a chain-specific action.
WT-03	accountsChanged: empty account list	Which wallet-scoped actions stop, and what happens to application login?	Empty account list plus separate frontend and server states.
WT-04	disconnect: provider cannot reach any chain	How does the application handle unavailable RPC independently of login state?	Provider error and the separately observed application session state.

EIP-1193 defines account and chain events. Its disconnect event concerns loss of connectivity to all chains. A wallet interface's Disconnect button may perform a different operation. Record the actual event and application behavior.

Fictional account-switch example

In this invented scenario, the application session still identifies account A after the provider exposes account B. Fictional policy P-DEMO-1 holds privileged wallet actions until a fresh proof for B is verified. This is a policy example, not a universal requirement to log out after every event.

WT-DEMO-01: illustrative entries, not a passed test
Field	Example entry
`test_id`	WT-DEMO-01
`initial_account`	account A (fictional alias)
`initial_chain`	0x1 (illustrative context; no chain contacted)
`provider_event`	accountsChanged: [account B] (alias, not a literal address payload)
`session_revision`	app-context-r17; subject=account A
`expected_application_decision`	Under fictional policy P-DEMO-1, hold privileged wallet actions until a fresh proof for B is verified. Do not reassign the session subject implicitly.
`observed_result`	NOT RUN - illustrative example only
`evidence_ref`	NONE - no execution artifact exists
`owner`	Authentication owner - role to assign

Download the fictional example CSV. Replace its aliases and policy with your own scoped fixture before execution. The example contains no client result.

Compare the expectation with the observation

Capture the provider event and resulting wallet context.
Observe the application's decision for the scoped action, including the server response when authorization is server-side.
Compare the result with the approved policy. A refreshed account label alone does not demonstrate the authorization outcome.
Link sanitized evidence. Leave an unexecuted check as NOT RUN. Record a mismatch as an open issue with an owner.

For Sign-In with Ethereum, ERC-4361 binds the session to the signing address and includes a chain ID in the message. Do not treat newly exposed account B as proof that an existing session now belongs to B. Implementers must also consider the standard's session-invalidation guidance for relevant state changes.

Scope, ownership and implementation

This form records expectations and evidence. It does not execute wallet tests, certify security or choose a custody model. Key recovery, delegated session keys and token allowances need separate reviews. Extend the starter scenarios for your supported wallets and for stale or overlapping requests.

When a wallet change leaves the application's session decision undefined, Pharos Production's blockchain application development services cover wallet and decentralized application implementation. The completed record makes the behavior to specify and verify explicit. It does not establish that an implementation has passed.

For the wider identity-to-wallet review, use the blockchain integration readiness worksheet.

Resource owner: Dmytro Nasyrov, Founder and CTO. Version 1.0, October 20, 2026. This reusable template reports no executed client test.

Primary references

EIP-1193: Ethereum Provider JavaScript API - event definitions and connectivity.
ERC-4361: Sign-In with Ethereum - address-bound sessions, message fields and session invalidation.

Sources checked October 20, 2026. Review the template when your wallet, provider or application policy changes. The standards authors have not reviewed or endorsed this template.