ERC-7846 wallet_connect Explained: Capability Negotiation, Multi-Account Exposure, and Authentication Risk

What ERC-7846 wallet_connect actually does

Ethereum DApps have historically relied heavily on eth_requestAccounts for initiating a wallet connection.

That basic flow works well when the application's immediate goal is simply to ask the wallet which account the user wants to expose.

Modern applications increasingly need more context during onboarding.

A DApp might need to authenticate the user immediately after connection.

Another might want the wallet to provide a capability that has its own structured result.

A future capability could describe metadata sharing or another permission-like feature.

Without an extensible connection method, each feature can require another separate interaction.

ERC-7846 introduces wallet_connect as a wallet-namespaced JSON-RPC request designed to connect one or more accounts while optionally negotiating capabilities in the same exchange.

The core request is intentionally compact.

It contains a method version and an optional capabilities object.

The wallet response returns an array of accounts.

Each returned account contains its address and a capability result object associated with that account.

This is the first important security distinction.

ERC-7846 is not merely a differently named eth_requestAccounts.

It creates a standardized place where richer connection-time behavior can be negotiated.

wallet_connect is not the WalletConnect protocol

The naming can be confusing.

wallet_connect in ERC-7846 is the name of a JSON-RPC wallet method.

WalletConnect is also the name commonly associated with a broader wallet-to-DApp communication protocol and ecosystem.

They should not be treated as synonyms.

A wallet transport could potentially carry ERC-7846-style requests, but the RPC method itself defines connection semantics rather than a complete transport protocol.

When auditing an integration, separate these questions:

This distinction prevents a common security mistake where developers assume security properties of one connection transport automatically define the semantics of every RPC request carried through it.

ERC-7846 is not ERC-7715 delegated execution authority

ERC-7846 and ERC-7715 both live in the broader wallet-interface ecosystem, but they solve different problems.

ERC-7715 is about requesting execution permissions so another account can perform defined actions on behalf of a wallet account.

ERC-7846 is about connecting wallet accounts while optionally requesting modular capabilities.

The difference matters because words such as "capability" and "permission" can sound interchangeable even when the underlying standards give them very different consequences.

This distinction is central to wallet safety.

A connection should not be described as equivalent to an asset-spending approval.

At the same time, users should not interpret "it is only a connection" as meaning there is no privacy or authentication risk.

The ERC-7846 request and response model

The wallet_connect request includes a version field and an optional capabilities object.

The per-account response structure is important.

A wallet can expose more than one account.

Different account objects can theoretically have different capability results.

A DApp therefore should not assume that capability information for the first returned account automatically applies to every other address.

The ERC-7846 connection and authentication surface

What capability negotiation means

ERC-7846 builds on a modular capability approach similar to the capability model used by EIP-5792.

The word capability should be interpreted carefully.

It means structured functionality associated with the wallet connection.

It does not automatically mean unrestricted authority.

Different capabilities can have completely different consequences.

One capability can be authentication

The initial capability defined by ERC-7846 is Sign-In with Ethereum.

The wallet can connect the account and return a valid SIWE message plus signature.

Another capability could expose metadata

The proposal's rationale explicitly anticipates richer capability results such as authentication, user metadata sharing, or permissions granted to the app.

Future capabilities may have stronger consequences

Because the system is extensible, a future capability should be evaluated according to its own specification rather than assuming its security properties from ERC-7846 alone.

Why ERC-7846 returns multiple accounts

The proposal intentionally returns an array of connected accounts.

The rationale is flexibility.

Some applications can interact with more than one user account.

Returning an account array also aligns better with the legacy behavior of eth_requestAccounts.

The proposal notes that many applications will probably use only the first account.

Security analysis should not stop there.

Exposing multiple accounts increases the amount of identity information a site can potentially correlate.

Balances can be correlated

If a DApp receives Wallet A, Wallet B, and Wallet C together, it gains strong evidence that the same user controls all three.

Public blockchain data can then reveal balances, counterparties, token holdings, NFT activity, governance participation, DeFi positions, bridging activity, and transaction history across those addresses.

Pseudonyms can collapse into one identity

A user may deliberately keep one wallet for public activity and another for private investing.

Connecting both accounts to the same application at once can permanently connect those identities in the application's data.

Account labeling can leak purpose

If the wallet exposes labels or metadata through future capabilities, a DApp could learn which address is a treasury, trading wallet, vault, or business account.

Historical privacy cannot be recovered easily

Disconnecting later prevents future account access according to wallet behavior, but it does not force an application to forget blockchain addresses it already legitimately received unless separate privacy or legal requirements apply.

Therefore the safer wallet default is usually progressive disclosure.

Expose only the account or accounts the user actually intends to use with that application.

What wallets should show when multiple accounts are requested

A wallet should avoid a vague confirmation such as "Connect 3 accounts."

The user needs to understand what correlation is being created.

Account choice is not merely convenience.

It is a privacy decision.

The initial ERC-7846 capability: Sign-In with Ethereum

The first capability explicitly defined by ERC-7846 is signInWithEthereum.

This builds on ERC-4361, commonly called SIWE.

The goal is to reduce an onboarding flow that previously required two user interactions.

Without capability bundling, a DApp may first call eth_requestAccounts.

The user approves connection.

The DApp then constructs a SIWE message.

The wallet opens again.

The user signs.

ERC-7846 can combine the connection and authentication request into one structured wallet interaction.

This improves UX.

It also means the connection prompt can now contain authentication consequences that users should understand before clicking approve.

The SIWE fields inside ERC-7846

The capability follows ERC-4361 semantics with some formatting changes appropriate to the JSON-RPC structure.

The connected address must match the SIWE signer

ERC-7846 imposes a critical consistency requirement when Sign-In with Ethereum is used.

The address returned by wallet_connect must match the account address inferred from the SIWE message.

This prevents an application from receiving one connected account while being handed authentication material for another account without an explicit semantic distinction.

The wallet also has to return an ERC-4361-formatted message corresponding to the requested parameters and a signature over the appropriate personal-sign hash.

The application should verify the result itself.

This may sound obvious.

Authentication bugs often come from precisely these consistency assumptions.

Domain binding is the core anti-phishing boundary

SIWE is designed so the wallet can understand which web origin is asking the user to authenticate.

The domain in the authentication message should correspond to the actual requesting origin.

A malicious page on attacker.example should not be able to present a message claiming that secureexchange.example requested the login.

The wallet should compare trusted origin information

A browser wallet can obtain the requesting page origin from the browser environment.

That trusted source should be compared with the SIWE scheme and domain information.

A pretty DApp name is not enough

Wallet interfaces sometimes emphasize logos and application names.

Those can be spoofed.

The origin is a stronger security boundary.

Subdomain differences matter

login.example.com and example-login.com are not equivalent.

Users often miss differences that automated origin verification can catch.

Cross-origin frames create additional complexity

If authentication originates from an embedded frame, the SIWE domain should correspond to the actual requesting origin rather than falsely claiming an ancestor page's domain.

Clear signing remains important here because authentication messages can look harmless even when the origin or resources are wrong. TokenToolHub's clear signing guide explains why wallets should translate opaque signing requests into effects and human-readable security context rather than asking users to approve unexplained data.

Nonce handling prevents authentication replay

A SIWE nonce is intended to make each authentication challenge unique.

The server creates a fresh challenge.

The wallet signs the resulting message.

The server verifies it and marks the challenge appropriately.

If the same signed message can be reused indefinitely, an attacker who captures it could attempt to establish another session.

Nonce should be fresh

A new session initiation should receive a new nonce rather than a static value tied permanently to one account.

Nonce should have sufficient entropy

An attacker should not be able to predict the next challenge easily.

Accepted nonces should not remain reusable

A relying party should prevent a successfully consumed challenge from becoming a reusable login credential by itself.

The connection method does not eliminate server verification

Bundling connection and SIWE through wallet_connect improves interaction count.

It does not make authentication secure automatically.

The server still needs to validate the message, signature, nonce, domain, time conditions, and account relationship.

Where expiry actually exists in ERC-7846

ERC-7846 itself does not define a universal expiry field for the wallet connection.

This is an important distinction from execution-permission standards where expiry can directly bound delegated authority.

Expiry in ERC-7846 is capability-specific.

For the SIWE capability, expirationTime can specify when the authentication message should no longer be considered valid.

notBefore can specify when it becomes valid.

Connection lifetime and authentication lifetime are not necessarily identical

A wallet can remain connected while the server-side SIWE session has expired.

The application can still know the account but require reauthentication before exposing protected functionality.

Authentication can outlive a browser tab

A server can issue its own session cookie or token after successful SIWE verification.

Closing the page does not necessarily invalidate that server session.

Future capability lifetimes may differ

Because wallet_connect is extensible, another capability can define its own lifecycle or revocation behavior.

Developers should not apply SIWE expiration semantics automatically to unrelated future capabilities.

What wallet_disconnect is supposed to do

ERC-7846 also defines wallet_disconnect.

The method instructs the wallet to disconnect the connected account or accounts.

The proposal says the wallet should revoke access to the user's account information and to capabilities associated with those accounts that were granted through wallet_connect.

This is stronger than merely hiding the "Connected" badge in the DApp interface.

Account data access should end

The site should no longer be treated by the wallet as an authorized connected application for the relevant accounts.

Connection-granted capabilities should be removed

Where a capability was specifically granted as part of the wallet_connect relationship, the wallet should revoke that capability access on disconnect.

Server authentication still requires server-side invalidation

Suppose wallet_connect generated a valid SIWE signature and the application exchanged it for a server session.

The wallet cannot necessarily reach into the application's backend and delete its session database entry merely because wallet_disconnect was called.

The DApp needs appropriate logout or session invalidation logic.

Previously published blockchain data remains public

Disconnecting does not make an exposed Ethereum address secret again.

The DApp can no longer rely on wallet-authorized access, but it can still observe public blockchain data associated with an address it already knows.

Disconnect, logout, approval revocation, and permission revocation are different actions

Wallet interfaces increasingly need to distinguish several separate lifecycle controls.

This separation is important during incident response.

Clicking one button should not give the user false confidence that every authorization surface has been removed.

TokenToolHub's crypto approval risk guide explains why persistent token approvals need independent review even after a DApp connection ends.

Capability results are account-specific security data

ERC-7846 returns capability results alongside each connected account.

Applications should preserve that association.

Consider a wallet that returns two addresses.

Account A successfully provides a SIWE authentication result.

Account B is also exposed but does not receive the same capability result.

The DApp should not silently treat Account B as authenticated because Account A is.

Authorization should not bleed between accounts

A successful capability result for one address belongs to that address unless the capability's specification explicitly says otherwise.

Applications should not infer unsupported capabilities

The absence of a result should not be interpreted as an affirmative grant.

Wallet responses should be canonical

Where DApps cache capabilities or obtain capability metadata through another path, current live wallet responses should take precedence when they conflict with stale cached information.

Capability negotiation can create fingerprinting risk

Capability discovery improves UX because a DApp can adapt to what a wallet supports.

The same information can help identify the wallet software.

A rare combination of supported capabilities can act like a fingerprint.

That fingerprint can then be combined with browser characteristics, IP metadata, address exposure, and application usage patterns.

More disclosure is not always better

DApps should ask for capabilities they actually need.

Wallets should avoid exposing unnecessary internal feature information to untrusted callers.

Progressive authorization protects privacy

A site does not need to learn everything a wallet can do before the user even chooses to interact with the application.

Capability caching needs care

Stale cached capability information can cause functional bugs.

Persistent caches can also become another source of user-agent fingerprinting.

Multi-account exposure can deanonymize a wallet portfolio

One of the most practical ERC-7846 risks is not asset theft.

It is identity correlation.

Suppose a user controls four addresses.

One is public on X.

One holds their salary.

One is used for experimental DeFi.

One is a long-term cold-storage address.

If one DApp learns all four in one wallet_connect response, the application can associate them.

Blockchain analytics can then connect activity that the user intentionally separated operationally.

Privacy separation can fail instantly

No on-chain transfer between the wallets is required.

The connection response itself becomes the correlation evidence.

A trusted DApp can still be breached later

Even if the application behaves responsibly today, a future database breach can expose historical account associations.

Wallet account selectors should default conservatively

Do not preselect every account merely because the ERC supports multiple accounts.

The user should deliberately expose additional identities.

Connection authentication creates a server-session risk

After a SIWE signature is verified, most applications create an ordinary authenticated web session.

The session may be represented by a secure cookie, bearer token, server-side session identifier, or another credential.

At that point, wallet security and web-session security intersect.

A secure wallet signature cannot protect a stolen session cookie

If malware steals an application's authenticated browser session, the attacker may not need another wallet signature until that session expires.

Long authentication sessions increase exposure

An application can choose convenience over short login lifetimes.

Users should understand that signing in once can authorize off-chain account access for much longer than the wallet popup is visible.

Privilege changes should invalidate sessions where appropriate

If an account changes control or a contract-account signature mechanism changes, the relying party may need to invalidate authentication sessions.

Logout should be real

A logout button should terminate the application session, not simply remove local UI state.

Smart contract accounts add ERC-1271 verification considerations

SIWE does not apply only to externally owned accounts.

Contract accounts can authenticate using contract-based signature verification mechanisms such as ERC-1271.

That introduces chain-specific state.

A contract account's signature validity can depend on the contract deployed at a particular address on a particular chain.

The correct chain matters

Contract-account validation must resolve against the intended chain context.

An address can contain different code or no code on another network.

Contract logic can change

An upgradeable smart account can change how signatures are validated.

Previously valid authentication assumptions can therefore become stale.

Session invalidation becomes important

If signature-validation logic changes materially, a relying party may need to terminate sessions rather than continuing to trust authentication generated under a previous account state.

How ERC-7846 authentication phishing could look

A malicious connection prompt does not need to ask for a token transfer.

It can attack identity and authentication instead.

Fake exchange login

An attacker clones a popular trading application's interface.

The fake domain sends wallet_connect with a SIWE request.

If the wallet verifies the actual origin correctly, the fake domain should be apparent or rejected when it attempts to claim the legitimate site's domain.

Misleading statement

A site can place confusing text in the SIWE statement or resources.

The wallet should render relevant fields clearly rather than presenting a generic "Sign in" button with no detail.

Wrong URI

A request can try to associate authentication with an unexpected URI.

Users should be able to inspect that information.

Account confusion

A user intends to authenticate a low-value pseudonymous account but accidentally signs with a public business address.

The error may not lose funds, but it can permanently connect identities.

Authentication replay is different from transaction replay

ERC-7846's SIWE capability uses off-chain signatures.

The main replay concern is an attacker reusing a captured authentication signature to establish another application session.

This is why the nonce exists.

Fresh challenge

The server should issue a new nonce for a new sign-in attempt.

Challenge binding

The signature should bind the intended domain, account, URI, chain, time information, and other relevant fields.

One accepted message should not become a password

The DApp should not accept the same signed payload indefinitely.

Expiration complements nonce protection

Even if a signed authentication message is captured, a sensible expiration time reduces how long it can be useful.

Man-in-the-middle risk exists around account and capability transport

ERC-7846's security considerations specifically warn that wallet addresses and shared capabilities must be handled securely to avoid data leakage or man-in-the-middle attacks.

The risk can appear in several layers.

Compromised provider bridge

A malicious browser script attempts to intercept or alter messages between the DApp and wallet provider.

Compromised frontend

The correct domain is compromised and sends a capability request the legitimate application did not intend.

Transport confusion

A mobile deep-link or remote-session transport connects to a different wallet context than the user expects.

Backend session substitution

A valid wallet signature is associated with the wrong application-side user account due to server logic errors.

Cryptographic verification solves only part of the system.

The application still needs secure session binding.

A compromised frontend can request more capabilities than normal

An extensible connection API gives legitimate applications flexibility.

A compromised application can abuse that same flexibility.

Imagine a DApp that historically asks only to connect one account.

Its frontend is compromised.

The attacker changes wallet_connect to request authentication or additional capability data the application normally never asks for.

The wallet should show the capability request

Users need visibility into more than the fact that an application wants to connect.

Unexpected capability expansion deserves stronger confirmation

A wallet can potentially recognize that a request includes authentication or sensitive metadata rather than a simple account connection.

DApps should minimize capability scope

Applications should not request speculative features simply because the wallet might support them.

Capability combinations can create unexpected interactions

The ERC-7846 security section warns that as more capabilities are added, care is needed to avoid unpredictable interactions.

This becomes more important as wallet interfaces become composable.

Imagine future wallet_connect requests that combine:

• Account connection.
• Authentication.
• User metadata sharing.
• A transaction-batching capability.
• A future session capability.
• A capability that changes how another capability is interpreted.

Each feature can be safe alone while the combination creates an unexpected privilege surface.

Wallets should evaluate combinations, not only individual capabilities

Two capabilities can interact in a way their individual specifications did not anticipate.

DApps should avoid kitchen-sink requests

Asking for every supported capability on first connection undermines progressive consent.

Capability results need namespaced semantics

Applications need to know exactly which standard defines each result and avoid collisions between unrelated capability names.

wallet_connect does not remove transaction review

After connection, a DApp can still request ordinary blockchain actions.

A user might connect safely and then approve a malicious transaction five minutes later.

The fact that the initial wallet_connect flow was valid does not make every later request safe.

Connection trust is not transaction trust

A DApp can change after connection.

A contract can be upgraded.

A frontend can be compromised.

A DNS or deployment account can be taken over.

Review the actual transaction

Before approving asset movement, users should understand target contracts, token amounts, approvals, calldata effects, and resulting positions.

TokenToolHub's Transaction Decoder can help inspect EVM transaction targets, token transfers, approvals, nested calls, traces, fees, and execution results when a connected DApp later asks the wallet to perform on-chain activity.

Token approvals remain a separate persistent risk

A common user mistake is to disconnect from a DApp after granting token approval and assume the site can no longer interact with their tokens.

The approval lives in token-contract state.

wallet_disconnect does not inherently erase an ERC-20 allowance created in an earlier transaction.

The same is true for Permit2 authorization.

Therefore:

TokenToolHub's Permit2 and allowances guide explains how persistent spending authorization can remain after a website connection ends and why users should review spender, token, amount, expiration, and downstream contract exposure separately.

What a secure wallet should display for wallet_connect

Connection UX often became too simple because old connection requests seemed low risk.

Capability negotiation means wallets need more structure.

A realistic ERC-7846 authorization sequence

Consider a portfolio application that wants the user to connect and sign in immediately.

Step 1: user opens the application

The page loads from portfolio.example.

The user clicks Connect Wallet.

Step 2: application generates a fresh nonce

The backend creates a unique challenge for this login attempt.

Step 3: DApp sends wallet_connect

The request asks for version 1 and includes the signInWithEthereum capability.

The SIWE parameters identify the nonce, intended chain, domain or default request origin, URI, optional statement, and optional expiry.

Step 4: wallet verifies the requesting origin

The wallet compares trusted origin information with the authentication data.

If a malicious site attempts to claim another domain, the request should not be silently accepted.

Step 5: wallet shows account selection

The user has three wallet accounts.

Only one is needed for the portfolio application.

The wallet should allow that one account to be exposed without linking the other two.

Step 6: wallet shows authentication context

The user sees that portfolio.example wants to authenticate the selected account.

The wallet displays the domain, address, chain, statement, relevant resources, and timing information.

Step 7: user approves

The wallet returns the connected address and capability result containing the SIWE message and signature.

Step 8: server verifies everything independently

The application verifies the message format, signature, address, nonce, domain, chain, timestamps, and any relevant resource rules.

Step 9: server creates an authenticated session

The user can now access account-specific off-chain application features.

Step 10: later transaction requests remain separate

If the application later asks the user to approve a swap, token allowance, vault deposit, or contract interaction, that action should receive its own security review.

Step 11: user disconnects and logs out

The wallet connection is terminated through wallet_disconnect.

The application also invalidates the web authentication session.

Any unrelated on-chain token approvals are reviewed separately.

What wallets should not hide behind one Connect button

The purpose of bundling is to reduce redundant interactions.

Bundling should not reduce clarity.

Connection plus authentication must still be understandable

The user should know that approving the prompt does more than reveal an address.

Multiple accounts should not be silently selected

Privacy-sensitive accounts should not be exposed merely because they exist in the same wallet.

Capabilities should not be buried

A future capability with stronger consequences should not be hidden under generic copy such as "Improve your experience."

Authentication expiration should not be invisible

If the requested SIWE authentication contains a long validity period, the wallet should expose that information.

Hardware signing helps with key protection, not connection interpretation

Hardware wallets can protect high-value signing keys from malware running on the general-purpose computer.

That remains useful when authenticating or approving later transactions.

A device such as Ledger can help isolate private-key operations from the connected browser environment.

Similarly, an air-gapped or QR-oriented workflow such as Keystone can reduce direct exposure of the root signing key.

Neither approach automatically makes a misleading authentication prompt safe.

If the user intentionally signs into the wrong domain or later approves a malicious transaction, strong key custody cannot reinterpret the request on the user's behalf.

Clear signing and origin verification remain essential.

Separate accounts can reduce ERC-7846 privacy exposure

Wallet compartmentalization remains useful even when private keys are secure.

A user can maintain:

• A public identity wallet.
• A low-value DApp wallet.
• A trading wallet.
• A long-term storage wallet.
• A business treasury wallet.

The purpose is not merely loss containment.

It is identity separation.

If every DApp is given all accounts simultaneously, the benefit disappears.

TokenToolHub's Wallet Safety 101 covers practical wallet compartmentalization, transaction hygiene, phishing resistance, seed protection, and approval review for users who want to reduce both asset and identity exposure.

Stale wallet connections are lower risk than stale spend permissions, but still worth cleaning

A forgotten wallet connection is generally not equivalent to an unlimited ERC-20 approval.

Still, stale connections create unnecessary data-access relationships.

A DApp can retain knowledge of connected addresses.

Capability-specific state can remain relevant during the connection.

Users may forget which applications they authenticated to.

A compromised DApp that already has an established connection can look more trustworthy when it later requests a signature.

Review connected applications periodically

Remove applications that are no longer used.

Log out of sensitive sessions

Disconnecting at the wallet layer should be paired with application logout where server authentication exists.

Check on-chain approvals separately

Do not infer allowance safety from the connection list.

What happens when capability negotiation only partly succeeds?

ERC-7846 is designed around modular capabilities.

A DApp therefore needs to handle capability results explicitly rather than assuming every requested feature was granted successfully.

Suppose the application requests connection plus a capability.

The wallet may support account connection but not the optional capability under some future extension model.

The application must not silently act as though the missing capability exists.

Connection success does not equal capability success

Read the returned capability results for each account.

Authentication success should be verified independently

Receiving a capability object is not enough. The application should validate SIWE message and signature semantics.

Fallback flows should remain explicit

If the wallet does not support ERC-7846, the DApp can use legacy connection and signing methods where appropriate.

The user should still understand that two prompts are accomplishing connection and authentication separately.

Method versioning is part of interoperability security

The wallet_connect request contains a version string.

This lets the wallet and DApp identify the RPC method behavior they expect.

Version negotiation may sound like a developer concern.

It becomes a security concern when applications silently assume semantics that a wallet does not actually implement.

Unsupported versions should fail safely

The application should not reinterpret an error as user consent.

Developers should not parse future versions using old assumptions

A future method version can evolve field or capability behavior.

Wallet UI should reflect actual supported semantics

A request should not be displayed as "standard connection" if the wallet only partially understands the requested capability format.

Wallet upgrades can change available capabilities

Wallet software evolves.

A capability unavailable today can become available after an update.

A previously supported capability can also change behavior under a new version or external standard.

DApps should trust current wallet responses over stale assumptions

Hardcoded capability lists become outdated.

Capabilities should remain namespaced and well specified

Two features using the same capability name but incompatible result shapes would create dangerous ambiguity.

Wallet upgrades should not silently broaden existing user consent

If a connection was established under one capability meaning, a later implementation change should not reinterpret that old consent as approval for materially broader behavior without appropriate user involvement.

Authentication is not authorization to spend

This distinction deserves repetition because wallet signatures often create fear for good reason.

A correctly formed SIWE signature authenticates an Ethereum account to an off-chain service.

It is not inherently an instruction to transfer ETH.

It is not inherently an ERC-20 approval.

It is not inherently permission for a contract to spend all tokens.

However, an authenticated session can expose valuable off-chain privileges.

A trading platform account can contain API settings.

A DAO interface can expose administrative functions.

A private application can expose sensitive account metadata.

A business dashboard can expose treasury operations.

Authentication signatures therefore require careful domain and session handling even when no on-chain asset transfer occurs.

Users should distinguish clear SIWE messages from arbitrary personal_sign requests

One benefit of ERC-4361 is a standardized message structure.

A wallet can parse expected fields and display them meaningfully.

A malicious website may instead ask for an arbitrary personal_sign message that visually imitates a login request.

Wallets should be cautious when a message contains language resembling SIWE but fails to follow the actual standardized format.

Structured authentication is easier to verify

The wallet can identify the domain, address, chain, nonce, timestamps, and resources.

Opaque messages weaken clear signing

If the wallet cannot tell what the user is authorizing, the user has to trust application-provided text.

A recognizable login label should not override parser failure

A message saying "Sign-In with Ethereum" is not valid simply because it contains those words.

SIWE resources can expand the authentication context

The resources field can include URI references relevant to authentication.

This can improve expressiveness.

It can also create consent complexity.

Users should be able to inspect referenced resources

A wallet should not hide them behind a generic "Sign in" label.

Applications should interpret resources consistently

SIWE intentionally does not define every possible semantic meaning of resource URIs.

The relying party should document what those references mean in its own authorization model.

Resource changes can require session invalidation

If a session relies materially on referenced resources and those resources change, continuing to honor the old session may no longer be appropriate.

Wallet-builder security checklist

DApp-builder security checklist

User checklist before approving wallet_connect

Incident response after a suspicious connection or authentication

Not every suspicious wallet_connect incident requires moving every asset immediately.

The correct response depends on what actually happened.

If you only exposed an address

The attacker learns public address information.

Disconnect the DApp and expect increased phishing or targeting if the address contains significant value.

If you signed a SIWE authentication message

Log out of the application.

Invalidate active sessions if the service provides session management.

Review the domain, nonce, timestamps, resources, and account that were signed.

If you later approved transactions

Decode those transactions and inspect token transfers, contract calls, approvals, and resulting positions.

If you granted token approval

Review and revoke unnecessary ERC-20 or Permit2 allowances separately.

If multiple accounts were exposed

Assume the application can correlate those addresses permanently.

Changing that privacy relationship can require operational compartmentalization rather than simply disconnecting.

Independent verification workflow

ERC-7846 risk matrix

Worked ERC-7846 security scenarios

Scenario 1: one-account connection with SIWE

A user connects one low-value address to a portfolio tracker.

The DApp requests SIWE with a fresh nonce and a one-hour authentication expiration.

The wallet verifies the correct domain.

The server validates the signature and nonce.

No transaction permission or token allowance is granted.

This is a relatively narrow use of wallet_connect.

Scenario 2: unnecessary multi-account exposure

A DApp needs only one address.

The wallet preselects five accounts.

The user clicks approve without noticing.

The application now knows that a public social wallet, a business treasury, and three private addresses belong to the same wallet user.

No assets are lost.

The privacy damage is still meaningful.

Scenario 3: fake domain requests SIWE

A phishing page imitates a popular exchange.

It requests wallet_connect plus SIWE.

The attacker tries to place the legitimate exchange's domain in the authentication data.

A wallet that verifies request origin against the SIWE domain rejects the mismatch.

Brand appearance is irrelevant to the cryptographic origin check.

Scenario 4: user signs correct domain with wrong account

The user has a public ENS identity and a private trading account.

They intend to authenticate privately.

The wallet selects the public identity address instead.

The sign-in is cryptographically valid.

The security mistake is identity disclosure rather than signature forgery.

Scenario 5: replayed authentication message

An application uses the same static nonce for every login.

An attacker obtains an old signed SIWE message.

The backend accepts the old challenge again.

The wallet did not fail.

The relying party's nonce handling did.

Scenario 6: wallet disconnect but server session survives

A user disconnects the wallet from a site.

The wallet correctly revokes account-access authorization.

The site's authentication cookie remains valid for another seven days because the DApp did not coordinate logout.

The user believes they fully disconnected.

The wallet and server operated according to different lifecycle controls.

Scenario 7: token allowance survives disconnect

The user connects to a DEX through wallet_connect.

Later, they approve USDC spending through a conventional ERC-20 transaction.

The user eventually calls wallet_disconnect.

The wallet connection ends.

The USDC allowance remains in token-contract state.

Disconnecting cannot be treated as approval revocation.

Scenario 8: capability result assigned to wrong account

A wallet returns Account A and Account B.

The SIWE result belongs to Account A.

A buggy DApp assumes the capability applies globally to the connection and creates a privileged session for Account B.

The bug is application-side account association.

Scenario 9: compromised frontend expands capabilities

A legitimate application normally requests account connection only.

An attacker compromises its deployment system and adds authentication and additional capability requests.

The origin remains legitimate because the real site is compromised.

The wallet must therefore show the capability expansion rather than relying exclusively on domain reputation.

Scenario 10: stale capability cache

A DApp cached that a wallet supported a feature six months ago.

The wallet later removed or changed support.

The DApp continues constructing requests under the old assumption.

Live wallet responses should be treated as current authority rather than stale cached capability metadata.

Scenario 11: contract-account authentication changes

A smart account authenticates through ERC-1271.

The account later upgrades its validation module.

A server session created under the old signature configuration remains active indefinitely.

A well-designed relying party considers whether the account-state change requires session invalidation.

Scenario 12: long authentication expiration

A low-risk DApp requests SIWE authentication valid for one year.

The user later loses control of the browser session.

The long validity increases the time in which captured session credentials can matter.

Authentication lifetime should reflect application sensitivity.

Scenario 13: resource change without session invalidation

An authenticated session references a specific protected resource.

The meaning or authorization requirements of that resource later change.

The server continues honoring the old session without revalidation.

Session invalidation policy needs to reflect resource changes where they affect authorization.

Scenario 14: correct connection followed by malicious approval

A user safely connects to the genuine DApp.

Several minutes later, the DApp frontend is compromised.

The next prompt is an unlimited token approval to an attacker-controlled spender.

The safe wallet_connect event does not protect the user from the later approval.

Scenario 15: capability fingerprinting

A website repeatedly queries or requests unusual capability combinations.

The resulting feature pattern uniquely identifies a niche wallet implementation.

Combined with browser fingerprinting and connected addresses, the DApp obtains stronger deanonymization signals than a simple account connection would have provided.

Clear signing should extend to connection-time capabilities

Clear signing is usually discussed in the context of transactions.

The principle also applies to wallet connections.

If a wallet_connect request includes authentication, the wallet should say:

"Connect Account A and authenticate to example.com."

That is clearer than:

"Connect."

If multiple accounts will be exposed, the wallet should say so.

If the SIWE session expires at a particular time, the information should be accessible.

If resources are referenced, users should be able to inspect them.

The goal is to make the user's mental model match the actual protocol effect.

Why connection security and approval security should remain separate in wallet UX

One danger of richer connection APIs is collapsing every wallet interaction into the same visual pattern.

Wallets should preserve distinctions.

Connection

Shares account identity and capability-specific information.

Authentication

Proves control of an account to an off-chain service and establishes an application session.

Approval

Can give a contract or spender persistent token authority.

Transaction

Can move assets or change on-chain state.

Delegated execution

Can allow future execution within a separately defined permission framework.

If all five show the same generic blue Approve button with minimal explanation, users cannot distinguish risk categories.

What to verify after connecting

Most users do not need to investigate every connection deeply.

High-value or security-sensitive accounts benefit from a basic post-connection check.

Confirm the exposed account list

Did the DApp receive one address or several?

Confirm authentication status

Was SIWE requested?

Is the account now logged in on the website?

Confirm connection list

The wallet should show the application as connected.

Confirm no unexpected transaction occurred

wallet_connect itself should not be confused with an on-chain transaction.

If a transaction suddenly appears, review it independently.

Check later approvals

If the workflow involved token spending, inspect allowances after the transaction.

Why transaction decoding still matters in an ERC-7846 workflow

ERC-7846 governs connection.

Most financially meaningful DApp workflows continue afterward.

A user connects.

They authenticate.

They choose an action.

The DApp prepares a transaction.

That transaction can interact with routers, vaults, bridges, token approvals, proxy contracts, or multicall systems.

The wallet connection does not describe those later effects.

When the transaction is complex, TokenToolHub's Transaction Decoder provides an independent way to inspect what actually executed rather than relying solely on the connected application's summary.

Connection incident matrix

A safer mental model for wallet_connect

Think of wallet_connect as entering a building reception desk.

You identify yourself.

You decide which identity card to show.

You may also agree to authenticate for access to particular application services.

The receptionist learning your identity does not automatically receive the key to your vault.

But showing every identity card you own reveals more than necessary.

Signing the wrong login form can establish access for an attacker.

And later handing over a separate payment authorization remains its own security decision.

This model avoids two opposite mistakes:

Common ERC-7846 wallet_connect misconceptions

wallet_connect is an execution-permission standard

No. ERC-7846 standardizes extensible wallet connection with optional capabilities. Execution permissions are a separate authorization category.

wallet_connect automatically gives the DApp permission to transfer tokens

No. Asset transfer requires a separate transaction, approval, or another explicitly defined capability or permission mechanism.

wallet_connect is the same thing as WalletConnect

No. ERC-7846 defines a JSON-RPC method. WalletConnect commonly refers to a broader communication protocol and ecosystem.

Connecting one wallet always exposes only one address

No. ERC-7846 returns an array of connected accounts and intentionally supports multiple accounts.

Sharing multiple addresses is harmless because blockchain addresses are public

No. The addresses may individually be public while the fact that one user controls all of them was previously unknown.

SIWE moves assets

A correctly formed SIWE authentication signature is not inherently an asset-transfer transaction.

SIWE signatures are risk-free

No. They authenticate account control and can establish valuable application sessions. Domain, nonce, chain, timing, and server verification still matter.

A familiar application logo proves the SIWE domain is safe

No. The wallet should verify the actual request origin.

A nonce is optional security polish

No. Fresh nonce handling is a fundamental replay defense in SIWE authentication.

Disconnecting automatically logs me out of the website

Not necessarily. The wallet connection and application server session are separate layers unless the application coordinates them.

Logging out revokes token approvals

No. ERC-20 allowances and Permit2 state remain separate on-chain authorizations.

wallet_disconnect erases the address from the DApp's database

No. It should revoke connection access, but an application can still possess information it already received, subject to its own data policies and applicable law.

Capability results apply globally to every connected account

No. ERC-7846 returns capabilities in association with individual account objects.

The wallet_connect SIWE expiry is the lifetime of the wallet connection

No. SIWE expirationTime concerns authentication validity. Connection lifetime and application session lifetime can differ.

A safe connection guarantees later transactions are safe

No. Every later signature, approval, and transaction must still be evaluated according to its actual effects.

Future ERC-7846 capabilities are where the standard becomes more powerful

The initial proposal becomes useful immediately because connection and authentication can be combined.

Its larger design value is extensibility.

Wallet capabilities continue to expand as account abstraction, smart accounts, paymasters, batching, delegation, authentication, and metadata systems mature.

ERC-7846 creates a structured connection surface where future capabilities can be requested rather than continually adding unrelated bespoke RPC flows.

This can improve interoperability.

It also means security expectations must evolve with the capability ecosystem.

A future low-risk capability can be almost informational

It may simply return wallet metadata useful to the DApp.

A future high-risk capability can create meaningful authority

If a future ERC defines persistent permission through wallet_connect, its lifecycle, scope, revocation, signer, account, chain, and execution semantics will need a security review beyond the ERC-7846 core.

Wallets need composable consent, not one-time blanket trust

The user should approve what each capability means rather than accepting a generic "Enable all supported features" model.

How ERC-7846 fits Ethereum's wallet roadmap

Ethereum wallets are moving beyond a simple model where one EOA address sends one transaction at a time through one fixed RPC method.

EIP-5792 standardized richer wallet-call capabilities and batch status handling.

ERC-4337 expanded smart-account infrastructure.

EIP-7702 provided another path for EOAs to use contract-code behavior.

Other work continues around more native forms of account abstraction and improved wallet security.

ERC-7846 addresses the beginning of the relationship between DApp and wallet.

Instead of treating connection as a static handshake, it allows applications and wallets to establish which capabilities are relevant to the session.

The security objective should remain progressive consent:

Best-practice framework for users

A user does not need to understand JSON-RPC to use ERC-7846 safely.

Five questions cover most connection-time risk.

Who is asking?

Verify the domain, not only the application branding.

Which identity am I sharing?

Expose only the wallet account needed for the task.

What else is bundled into connection?

Check whether the request includes authentication or another capability.

How long will authentication remain useful?

Review timing and application-session behavior.

What separate authority do I grant afterward?

Review approvals and transactions independently.

That can be summarized as:

If each step matches the user's intent, the connection flow is much easier to reason about.

Conclusion: ERC-7846 makes wallet connection more capable, so connection consent must become more precise

ERC-7846 wallet_connect addresses a practical Ethereum wallet problem.

The old connection flow was designed around a simpler era.

A DApp asked for an account.

The wallet returned an address.

Anything more advanced happened through separate prompts.

Modern wallet experiences increasingly require authentication, multi-account support, smart-account functionality, richer metadata, and capability-aware onboarding.

ERC-7846 creates an extensible connection method for that environment.

The request contains a version and optional capability requests.

The wallet returns one or more account objects.

Each account contains an address and associated capability results.

The initial standardized capability is Sign-In with Ethereum.

That allows a DApp to connect and authenticate a user within one wallet interaction instead of requiring a connection prompt followed by a separate personal-sign prompt.

Reducing prompts can improve safety when it removes redundant blind signing.

It can reduce safety if the wallet hides the fact that connection now includes authentication.

The user therefore needs a clearer connection screen, not simply fewer screens.

Multi-account support deserves particular attention.

An Ethereum address is public.

The relationship between several addresses is not necessarily public.

Returning multiple accounts in one connection can collapse privacy boundaries the user intentionally maintained.

A wallet should therefore let users expose one address without exposing every other account in the same software.

This is progressive disclosure applied to blockchain identity.

Capability negotiation adds another dimension.

Connection alone does not mean spending authority.

But connection can carry authentication.

Future capability standards can add other types of functionality.

Each capability needs to be evaluated by its actual semantics.

A wallet should not summarize every capability request as "Connect."

A DApp should not request capabilities merely because they might be useful later.

And users should not interpret one connection approval as consent to every future wallet action.

SIWE itself has strong security properties when correctly implemented.

The message binds authentication to an account, domain, chain, nonce, time information, URI, and optional resources.

The wallet can verify that the origin requesting the signature matches the declared authentication domain.

The nonce can prevent captured signatures from becoming reusable login credentials.

The account returned by wallet_connect must match the account represented in the SIWE message.

The application should verify the resulting message and signature independently rather than treating the wallet response as unconditionally trustworthy.

None of those protections removes the need for good server security.

After SIWE authentication succeeds, the DApp will usually establish an ordinary web session.

That session can be stolen, remain active too long, or fail to invalidate when account state changes.

The wallet cannot solve every backend-session problem.

This is why lifecycle controls must be separated carefully.

wallet_disconnect should terminate wallet connection access and capabilities granted through wallet_connect.

Application logout terminates the web authentication session.

ERC-20 approval revocation terminates token allowance.

Permit2 revocation terminates the relevant Permit2 authority.

Execution-permission revocation terminates reusable delegated authority under the permission system that created it.

Those controls should not be presented as interchangeable.

Users who disconnect a DEX after approving an unlimited spender can remain exposed to that spender.

Users who log out of a website can remain connected at the wallet layer.

Users who disconnect their wallet can still have an authenticated application session if the backend does not invalidate it.

The right incident response depends on which layer was compromised.

Later transactions also remain independent security decisions.

A genuine site can be compromised after a safe connection.

A safe SIWE login can be followed by a malicious token approval.

A connected account can later be asked to interact with an upgradeable router whose implementation changed.

Connection trust should never become permanent transaction trust.

TokenToolHub's clear signing research is useful when evaluating how wallets should communicate the later effects of signatures and transactions.

The crypto approval risk guide explains why persistent token authority needs separate monitoring.

The Permit2 and allowances guide covers another persistent authorization surface that can remain after a DApp connection ends.

For broader operational hygiene, Wallet Safety 101 provides a practical account-separation and signing framework.

And when the connected application eventually sends a complex transaction, TokenToolHub's Transaction Decoder can independently show what actually happened on-chain.

The most useful ERC-7846 security rule is therefore simple:

ERC-7846 can make wallet onboarding substantially cleaner.

Its best outcome is not a future where users click through one giant connection prompt without understanding it.

Its best outcome is a future where wallets can negotiate richer functionality while exposing exactly which accounts and capabilities are being granted, why they are needed, and how the relationship ends.

FAQs

References and further reading

These official standards and Ethereum resources provide the technical foundation for wallet connection, capability negotiation, Sign-In with Ethereum, and related wallet security considerations.

• ERC-7846: Wallet Connection API
• ERC-4361: Sign-In with Ethereum
• EIP-5792: Wallet Call API and Capability Model
• EIP-191: Signed Data Standard
• ERC-1271: Standard Signature Validation Method for Contracts
• Ethereum Improvement Proposals and ERC Standards
• Ethereum.org: Ethereum Security Roadmap

ERC-7846 remains a Draft proposal and capability definitions can evolve independently of the core connection API. Wallets and applications can also differ in connection lifecycle, account selection, server-session handling, and support for future capabilities. Review the exact wallet and DApp implementation in use. This guide is educational security research and not financial, legal, or software-audit advice.