dApp Wallet Connection

Skip key takeaways

Updated September 24, 2026

• EIP-6963 adds a discovery channel, not a window.ethereum fix A second wallet extension can still overwrite the shared global, but the announce and request event pair gives a dApp a race-free way to see every installed wallet instead of whichever one loaded last.
• A SIWE session lives or dies on the nonce A predictable or reused nonce lets a captured signed sign-in message be replayed to open a new session; the wallet's own domain check stops a phishing page obtaining the signature in the first place, the relying party's server-side domain check stops an already-signed message being accepted by a different site and the optional expiration-time field bounds when the signed message can be accepted, which a relying party may use to cap the session, but none of these substitutes for a fresh nonce.
• ERC-1271 alone still misses undeployed smart accounts A verification path that checks isValidSignature but skips the ERC-6492 wrapper rejects a valid signature from any counterfactual account that has not been deployed yet.
• EIP-5792 capabilities must be checked, never assumed A wallet that has not adopted EIP-5792 can reject wallet_getCapabilities itself, not just a batch call, so a dApp needs a fallback to eth_sendTransaction and eth_getTransactionReceipt rather than assuming batching support exists.
• EIP-7702 breaks the EOA-means-no-code assumption A delegated EOA keeps its address and key but now carries code, so a signature or permissions check that infers account type from code presence alone can misjudge exactly the addresses this standard is designed to upgrade.

Copy takeaways

dApp wallet connection gets scoped as a single integration step: render a connect button, get an address back, move on. The Ethereum Provider specification names the actual problem underneath that scope in its own Abstract: "Historically, Provider implementations have exhibited conflicting interfaces and behaviors between wallets." That inconsistency is the reason EIP-1193 exists as a shared floor every wallet and every dApp builds against. A dApp wired to one wallet's quirks breaks the day a second wallet, a mobile session or a delegated account reaches the other end of the connection, which is exactly the layer-by-layer work our dApp development team builds.

In short: the layer table below lists what a dApp has to do at each stage of a connection and where a naive implementation fails in practice. Legacy window.ethereum discovery still runs on a single global, one a second wallet extension can silently overwrite, though EIP-6963 adds a race-free channel beside it. And EIP-7702 means a delegated EOA keeps its address and key but now carries code, which breaks a signature check written to assume otherwise.

The wallet-connection layers and their failure modes

The layer and standard columns below name what each stage of a connection is built on. Next to them, the what-the-dApp-must-do and failure-mode columns describe typical failure modes derived from the specifications, Pharos Production's own engineering framing rather than a claim quoted from any one of them. The sections that follow work through these rows in order.

Layer	Standard	What the dApp must do	Failure mode seen in practice
Provider interface	EIP-1193	Route every call through request() and listen for all five defined events, not just accountsChanged	A dropped disconnect event leaves the UI showing a connected wallet that has actually gone away
Discovery	EIP-6963	Listen for announce events and dispatch a request event	A second wallet extension loads after the first and silently takes over the global, so the dApp connects to the wrong wallet
Mobile pairing	WalletConnect Sign (v2.0)	Establish a pairing first, then propose a session scoped to explicit namespaces	A mobile visitor without an in-app browser hits a QR flow with no second device to scan it
Session identity	EIP-4361 (SIWE)	Bind the session to the address, verify the domain field and issue a fresh nonce per sign-in	A reused or predictable nonce lets a captured SIWE message be replayed against a different session
Signature verification	ERC-1271	Call isValidSignature on the account instead of recovering a single ECDSA signer	A backend written for EOA-only signatures rejects a valid smart-account signature outright
Counterfactual accounts	ERC-6492	Detect the wrapper suffix and run the deployment step before calling isValidSignature	A signature from a smart account that has not deployed yet is rejected as invalid
Capability discovery	EIP-5792	Call wallet_getCapabilities before assuming batching or paymaster support exists, with a fallback to eth_sendTransaction ready	A batch call reaches a wallet that does not implement EIP-5792 at all, which returns 4200, so the dApp falls back to eth_sendTransaction plus eth_getTransactionReceipt
Account code	EIP-7702	Never branch signature or authorization logic on the assumption that a connected address holds no code	A verifier that only calls ecrecover, or only calls isValidSignature, misses a valid signature the other path would have caught
Chain context	EIP-3326 / EIP-3085	Read the chain id from the provider on connect and again on every chainChanged event	A transaction built for one chain gets signed while the wallet is actually set to another
Pre-signature review	Simulation (engineering guidance)	Preview or simulate the call set before it reaches a signature prompt	A malformed batch only fails, or succeeds destructively, after it is already on-chain

Not every row above carries the same stakes. Security-grade failures let an attacker act as the user or take control of funds: a replayed or domain-unbound SIWE session, accepting anything other than the exact 0x1626ba7e magic value from isValidSignature and treating any delegated address as a vetted smart wallet without checking which delegate it points to EIP-7702's own Security Considerations describe. Correctness-grade failures reject a legitimate call rather than exposing anyone to attack: a signature check that only handles EOA or only ERC-1271 accounts locks out the accounts the other path was built for. UX-grade failures degrade the experience without handing anyone control: a missed disconnect listener leaving a stale connected state on screen, or an account or chain read gone stale between accountsChanged and chainChanged events.

Which rows apply also depends on what the dApp does. A read-only dApp displaying on-chain data needs the provider-interface, discovery and chain-context rows, since it never asks for a signature but still has to know which chain it is reading from. A sign-in-only dApp adds the session-identity row, a SIWE sign-in with its nonce and domain binding, plus both signature-verification rows, the account-code row and the mobile-pairing row for a mobile visitor, since mobile pairing applies to any dApp with mobile visitors, sign-in included: a SIWE sign-in from a smart account, a counterfactual account or a 7702-delegated signer is verified through ecrecover, ERC-1271 and ERC-6492 exactly as any other off-chain message signature (personal_sign or EIP-712) would be. What it can skip is capability detection and pre-signature review, since neither applies without a transaction. A transacting dApp needs everything a sign-in-only dApp needs plus capability detection and pre-signature review before a call set reaches a signature prompt.

What EIP-1193 defines, and where a connection begins

Every wallet connection runs through one method. The specification's own purpose statement for it is narrow on purpose: "The request method is intended as a transport- and protocol-agnostic wrapper function for Remote Procedure Calls (RPCs)." Every call, from the first eth_requestAccounts to a later signature request, goes through that one entry point rather than a bespoke method per wallet.

Five more events round out the provider interface, ones a dApp should listen for rather than poll: connect, disconnect, chainChanged, accountsChanged and message. The specification defines the second of those precisely: "The Provider emits disconnect when it becomes disconnected from all chains." A dApp that never wires that listener keeps rendering a connected state after the underlying provider has actually dropped the connection. The other three events cover the state changes a connection has to react to without the user reloading the page: connect fires once a provider first becomes able to serve requests, chainChanged fires whenever the active chain id changes and accountsChanged fires whenever the exposed account list changes, including the case where a user switches accounts inside the wallet itself and the dApp is left holding a stale address until it reads the new list. Treating these as one-time values read at connection time rather than as an ongoing stream leaves a dApp quietly acting on an account or chain the wallet has already moved away from.

The same document tabulates five standard RPC error codes a request can return: 4001 for a user rejection, 4100 for an unauthorized method or account, 4200 for a method the provider does not support and two distinct disconnection codes the specification separates deliberately: "4900 is intended to indicate that the Provider is disconnected from all chains, while 4901 is intended to indicate that the Provider is disconnected from a specific chain only." Treating 4900 and 4901 as the same failure collapses two different situations: 4900 means no chain connection at all, 4901 means the provider is connected to other chains but not the one requested. A wallet simply pointed at the wrong chain is neither case; a dApp detects that by reading eth_chainId and watching chainChanged, not by an error code.

Discovery: EIP-6963 and the single-provider race

Before EIP-6963, a dApp discovered a wallet by reading one global. The specification's Motivation section names what happens once more than one wallet extension is installed: "resulting in a race condition where the user does not have control over which Wallet Provider is selected to expose the Ethereum interface under the window.ethereum object." In practice, the last wallet extension to load usually claims that global, leaving the user with no say in which wallet the dApp actually reaches.

EIP-6963 does not replace that global, it adds a second, race-free channel next to it. The Specification section describes the fix as a two-way event exchange rather than a single shared object: "In order to prevent provider collisions, the DApp and the Wallet are expected to emit an event and instantiate an eventListener to discover the various Wallets." In practice: the dApp adds a listener for wallet announcements, then dispatches a request event and every wallet already on the page re-announces itself in reply, each with a UUID, a display name, an icon and a reverse-DNS identifier, so a wallet that announced before the dApp's listener existed is never missed. A dApp that only reads window.ethereum still works with exactly one installed wallet. The day a second one is installed, that dApp is one browser-extension load order away from connecting the wrong wallet, silently, with no error to catch.

Mobile connection: the WalletConnect Sign protocol

Outside a wallet's in-app browser, a desktop extension has no mobile equivalent, so a mobile connection goes through a different mechanism entirely. The WalletConnect Sign protocol specification states its own scope plainly: "Sign API establishes a session between a dapp and a wallet in order to expose a set of blockchain accounts that can sign transactions and/or messages using a secure remote JSON-RPC transport with methods and events." That session is the mobile equivalent of the in-browser provider object: a persistent, authorized channel a dApp calls into after the wallet approves it once, lasting until it expires or either side disconnects. A visitor already holding the wallet app on the same device they are browsing from cannot scan a QR code shown on that screen, so the pairing URI also opens through a same-device deep link into the wallet app instead of requiring a second device to scan it.

Pairing and session are two distinct steps in the current protocol version, and the specification is explicit that this is a v2.0-specific design rather than a constant across every protocol version: "In v2.0 the session and pairing are decoupled which means that a URI is shared to construct a pairing proposal and only after settling the pairing then the dapp can propose a session using that pairing." A QR code or deep link carries the pairing URI. The session, with its actual account access, is a separate negotiation that only happens after that pairing settles.

What a wallet actually agrees to expose is scoped by a namespace. The Namespaces page defines the construct behind that scoping: "A namespace is a standardized object defined by the Chain Agnostic Improvement Proposal (CAIP) that ensures a common industry standard for chain agnostic purposes." A dApp requests chains, methods and events split into required and optional namespaces. In WalletConnect v2.0, a wallet cannot narrow a required namespace, it rejects the whole proposal if it cannot satisfy one, but it may grant only part of an optional namespace and add chains, methods or events never requested. The rule that follows: treat the session namespace the wallet actually returns, not the original proposal, as the only record of what the session allows for any Web3 development integration.

Session identity: SIWE, nonce and domain binding

A wallet address is not by itself a session. EIP-4361, Sign-In with Ethereum, defines the message format that turns a signature into one, and its Specification section is explicit about what that session is bound to: "Sessions MUST be bound to the address and not to further resolved resources that can change." An ENS name or a profile record can change after sign-in. The address cannot, which is why the address, not anything it resolves to, is the anchor.

The phishing defense SIWE provides is a domain check, and EIP-4361 makes it a MUST on the wallet side rather than an optional courtesy: "Wallet implementers MUST prevent phishing attacks by verifying the origin of the request against the scheme and domain fields in the SIWE Message." That wallet-side check stops a phishing page from obtaining a signature over a domain field that does not match the page actually shown to the user; it runs at signing time, before any message exists to capture. A relying party runs a second, server-side domain check when it later validates an already-signed message, and that is the check a message captured on one site and forwarded to another fails, since the domain field will not match the site now presenting it. The independently maintained SIWE documentation describes the field that defends against a different kind of replay in its own words: "nonce is a randomized token used to prevent replay attacks, at least 8 alphanumeric characters." A dApp that issues a predictable or reused nonce, a sequential counter or a fixed string, gives up exactly the protection that field exists to provide: a captured signed message becomes replayable to open a new session on the same site, the case the domain check alone does not catch. A relying party enforces both server-side: it generates the nonce, marks it used once presented, then checks the domain, uri, chain-id, issued-at and, where present, expiration-time fields before accepting the sign-in.

A session is not necessarily just proof of address ownership. The same SIWE documentation notes what a relying party can build on top of it: "The server may further fetch data associated with the Ethereum address, such as from the Ethereum blockchain (e.g., ENS, account balances, ERC-20/ERC-721/ERC-1155 asset ownership), or other data sources that may or may not be permissioned." SIWE's own expiry mechanism is the optional expiration-time field, which bounds when the signed message can be accepted rather than tracking session activity directly; a relying party may cap the session to that same bound. EIP-4361's Security Considerations separately recommends, with a SHOULD rather than a MUST, that the relying party keep checking for cases tied to ERC-1271 dependent data, an authorization that can change on a smart-account signer after sign-in: "There are several cases where an implementer SHOULD check for state changes as they relate to sessions." As Pharos Production guidance beyond the specification's own scope, also re-checking a token balance or an NFT holding fetched at sign-in and used to gate access is worth doing on the same schedule, since that data can go stale without the signature or the ERC-1271 authorization ever becoming invalid.

Smart-account signatures: ERC-1271 and ERC-6492

A signature check written for an externally owned account assumes one thing the standard itself calls out as untrue for a contract. ERC-1271's Abstract states the gap directly: "Externally Owned Accounts (EOA) can sign messages with their associated private keys, but currently contracts cannot." A smart-account wallet has no private key to recover a signer from, so a verification path built on ecrecover alone has nothing to check against.

ERC-1271 replaces that recovery step with a call the account itself answers, accepting only an exact return of the magic value 0x1626ba7e as proof the signature is valid, anything else is a rejection. Verification moves into the account's own code rather than staying in the caller's, and the specification is direct about how open-ended that code's answer can be: "isValidSignature can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependent (e.g. signers authorization level within smart wallet), signature scheme Dependent (e.g. ECDSA, multisig, BLS), etc." A dApp does not need to know which scheme a given smart account uses. It calls isValidSignature and trusts the account's own answer, which is the entire point of moving verification on-chain.

That still leaves a gap for an account that has not been deployed yet. ERC-6492's Abstract names exactly that case: "We propose a standard way for any contract or off-chain actor to verify whether a signature on behalf of a given counterfactual contract (that is not deployed yet) is valid." Its Motivation section ties the gap directly back to ERC-1271 itself: "Furthermore, not being able to sign messages from counterfactual contracts has always been a limitation of ERC-1271." A wrapped signature carries a deployment step first; an off-chain verifier usually runs that step as a read-only simulated call rather than an actual on-chain deployment, then calls isValidSignature against the account as it would exist once deployed. An integration that checks only for ERC-1271 support, without the ERC-6492 wrapper, rejects a perfectly valid signature from a wallet a user has not deployed yet.

Capability detection with EIP-5792

EIP-5792's Abstract states what it adds to the provider interface in one sentence: "Defines new JSON-RPC methods which enable apps to ask a wallet to process a batch of onchain write calls and to check on the status of those calls." wallet_sendCalls is the method that actually submits a batch, and its own purpose statement is just as short: "Requests that a wallet submits a batch of calls." wallet_getCallsStatus is the companion method a dApp polls afterward to check whether a submitted batch has confirmed.

Neither method is safe to call blind. wallet_getCapabilities exists precisely so a dApp does not have to guess: "This RPC allows an application to request capabilities from a wallet (e.g. batch transactions, paymaster communication), without distinct discovery and permission requests." wallet_getCapabilities itself can be unsupported: a wallet that has never implemented EIP-5792 can return the ordinary EIP-1193 unsupported-method error, code 4200, for the capability check as readily as for a batch call. A dApp needs a fallback path for that case: submit calls individually through eth_sendTransaction and confirm each with eth_getTransactionReceipt instead of batching them through wallet_sendCalls.

EIP-7702: what delegation changes for a dApp

EIP-7702's Abstract states the mechanism in one sentence: "Add a new EIP-2718 transaction type that allows Externally Owned Accounts (EOAs) to set the code in their account." That is a narrower change than a new account type. It lets an address that has always behaved like a plain EOA start executing contract code, without changing the address itself, through a signed authorization tuple rather than a migration to a new wallet.

For a dApp, the consequence is that an EOA address stops being a safe shorthand for an address that carries no code: a delegated EOA keeps its address and key but now carries code, so nothing about the address itself reveals the delegation. Delegation does not change how the EOA's own signatures verify: ecrecover still recovers a valid signature made with the delegated EOA's own private key. The risk sits in the verification logic built around that address, not in the signature itself. As Pharos Production engineering guidance, three failure modes are worth naming: a verifier that routes any address holding code straight to isValidSignature only, rejecting a valid ECDSA signature whenever the delegate lacks ERC-1271 support; an ecrecover-only verifier that never calls isValidSignature, missing a signature only the delegate can validate; and an authorization check written as msg.sender == tx.origin to confirm a plain EOA, which also breaks since that now passes for a delegated address running its own code. The rule: check both the ecrecover and isValidSignature paths, and never infer account type from code presence alone. The risk runs the other direction too. EIP-7702's Security Considerations names it directly: "A poorly implemented delegate can allow a malicious actor to take near complete control over a signer’s EOA." A dApp that only reads whether an address has code, without knowing what that code is or where the delegation points, is reading a signal that can now mean far more than a marker for a smart-contract wallet.

Chain switching and transaction simulation

Among the sources this guide quotes, neither chain switching nor transaction simulation is documented as a first-class specified behavior of the wallet-connection layer itself. Chain switching has its own specifications outside the sources quoted here: EIP-3326 defines wallet_switchEthereumChain, the request a dApp sends to change the wallet's active network, and EIP-3085 defines wallet_addEthereumChain, the fallback when the wallet rejects a chain it does not recognize. A dApp should treat the wallet's own chain as the only truth that matters, especially inside a larger crypto and Web3 product spanning more than one chain: read the chain id on every connection and again on every chainChanged event, rather than trusting a cached value. A transaction built against a cached chain id gets signed against whatever chain the wallet actually has active, not always the one the page assumes.

Transaction simulation exists elsewhere in the ecosystem, in mechanisms such as eth_simulateV1 and the simulation step an ERC-4337 bundler runs before submitting a user operation, but the sources this guide quotes say little beyond one sentence, a permissive, wallet-side condition inside EIP-5792's batch-call flow, not a general simulation requirement: a wallet "MAY reject the request if one or more calls in the batch is expected to fail, when simulated sequentially". That is permission for a wallet to simulate before it signs, not a promise that every wallet does. Previewing the decoded call, the token approvals it grants and the balance changes it produces, before the signature prompt appears, is Pharos Production engineering guidance, catching a malformed batch while still reversible instead of after it has reached the chain.

How Pharos Production helps

Wallet connection is the front door to a stack that has to keep working across a browser extension, a mobile session, a smart account and a delegated EOA that carries code without changing address. Our Web3 stack guide covers the layers a connected wallet talks to next, from indexing to contract interaction.

Our dApp development team builds the connection layer itself: EIP-6963 discovery instead of a single racing global; a WalletConnect session read from the granted namespace rather than the original request; signature verification that checks ecrecover, ERC-1271 and ERC-6492 rather than assuming an EOA; a chain-context read that never trusts a cached value, alongside the broader Web3 development practice at Pharos Production.

Sources: Ethereum Improvement Proposals on eips.ethereum.org (EIP-1193, EIP-6963, EIP-4361, ERC-1271, ERC-6492, EIP-5792, EIP-7702, EIP-3326 and EIP-3085); the WalletConnect Specs site on specs.walletconnect.com (the Sign API Overview and the Namespaces page); the SIWE documentation on docs.login.xyz. Read 23 September 2026. Engineering guidance, not legal or security advice.

FAQ

Last updated: September 24, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• ★ Featured question. Does EIP-6963 replace window.ethereum?

  Copy link Copies a direct link to this answer to your clipboard.

  No. EIP-6963 is additive, not a replacement. window.ethereum injection continues to exist exactly as before, and EIP-6963 adds a second, parallel discovery channel next to it: the dApp adds a listener for wallet announcements, dispatches a request event and each installed wallet re-announces itself in reply.

  A dApp that supports both the event-based flow and a window.ethereum fallback for a wallet that has not adopted EIP-6963 covers the widest set of installed wallets rather than choosing one discovery path over the other.

• Why does a SIWE sign-in need a fresh nonce every time?

  Copy link Copies a direct link to this answer to your clipboard.

  Because the nonce is the field that stops a signed message from being replayed to open a new session. A signature over a SIWE message proves the address authorized the message at signing time and nothing more, so if the nonce is predictable or reused, a captured signed message can be presented again later as though it were a new sign-in.

  The domain-binding check covers a different case, and it runs on two sides: the wallet verifies the domain field against its own origin before signing, which stops a phishing page obtaining a signature over a domain that does not match the page it is actually showing, and the relying party verifies the same field again when it validates an already-signed message, which stops a message captured from one site being accepted on another. The optional expiration-time field bounds when the signed message can be accepted, and a relying party may cap the session to that same bound; a fresh nonce, both domain checks and an expiration time together are what make a signature resist both replay and phishing.

• What happens if a wallet does not support EIP-5792 capability requests?

  Copy link Copies a direct link to this answer to your clipboard.

  wallet_getCapabilities can itself be unsupported. A wallet that has never implemented EIP-5792 can return the EIP-1193 unsupported-method error, code 4200, for the capability check itself, not just for a batch call.

  A dApp needs a fallback path for that case: submit the calls individually through eth_sendTransaction and confirm each one with eth_getTransactionReceipt instead of batching them through wallet_sendCalls.

• How does a WalletConnect mobile connection work on the same device, without a second phone to scan a QR code?

  Copy link Copies a direct link to this answer to your clipboard.

  Outside a wallet's in-app browser, a desktop extension has no mobile equivalent, so a mobile visitor on the same device the wallet app is installed on cannot scan a QR code shown on that same screen. A same-device deep link, opening the wallet app directly through an operating-system deep link rather than a QR code, is how that case is normally handled: the pairing URI opens the wallet app, the wallet approves the session and the wallet can redirect back to the browser or dApp, rather than requiring a second device to point a camera at the first one.

  The resulting session behaves the same as one created via a QR-scanned pairing, and it lasts until it expires or either side disconnects.

• Are all these failure modes equally urgent, and does a sign-in-only dApp need every layer?

  Copy link Copies a direct link to this answer to your clipboard.

  No, and the two questions have different answers. Security-grade failures, a replayed or domain-unbound SIWE session, accepting anything other than the exact 0x1626ba7e magic value from isValidSignature, or treating any delegated address as a vetted smart wallet without checking which delegate it points to EIP-7702's own Security Considerations describe, let an attacker act as the user or move funds.

  Correctness-grade failures, a signature check that only handles the EOA or only the ERC-1271 path, reject a legitimate call rather than exposing anyone to attack, and matter less urgently than a security-grade gap but still lock out real users. UX-grade failures like a missed disconnect listener sit below both. A sign-in-only dApp still needs the signature-verification and account-code rows, since a SIWE sign-in from a smart account, a counterfactual account or a 7702-delegated signer is verified through ecrecover, ERC-1271 and ERC-6492 exactly as any other off-chain message signature (personal_sign or EIP-712) would be. What it can skip is capability detection and pre-signature review, since nothing in a sign-in flow ever submits a transaction.

• What happens if a wallet does not recognize the chain a dApp asks it to switch to?

  Copy link Copies a direct link to this answer to your clipboard.

  The switch request is rejected. A wallet that has no configuration for the requested chain id cannot simply change to it, so the dApp has to fall back to the add-chain path, EIP-3085's wallet_addEthereumChain, which asks the wallet to register the chain's RPC endpoint, currency and block explorer.

  Many wallets switch to the newly added chain as part of that same request, though a dApp should still be ready to send a separate switch request afterward in case the wallet does not. A dApp that only calls the switch method and treats a rejection as a dead end, rather than falling back to the add-chain request, leaves a visitor on an unsupported chain stuck with no way forward.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.