# Connecting a wallet: account access, signatures and approvals Connecting a wallet usually lets an application request access to selected account addresses and communicate with the wallet. That connection alone is different from granting a token allowance or signing a transaction. A signature can itself authorize spending, so its meaning matters even when no gas fee is shown. Evidence: [EIP-1193: Ethereum Provider JavaScript API](https://eips.ethereum.org/EIPS/eip-1193); [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20); [ERC-2612: Permit Extension](https://eips.ethereum.org/EIPS/eip-2612) Canonical: https://degreesofsatoshi.com/encyclopedia/connecting-a-wallet/ Published: 2026-10-02 Substantively modified: 2026-10-02 Independently verified by an automated reviewer: 2026-10-02T15:08:18.373Z AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied. ## Key facts - **Account access:** Wallet account exposure is an explicit permission boundary. ([EIP-1193: Ethereum Provider JavaScript API](https://eips.ethereum.org/EIPS/eip-1193)) - **Allowance:** ERC-20 spending permission belongs to a token contract and spender. ([ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20)) - **Signature:** ERC-2612 permits authorize allowances using signed messages. ([ERC-2612: Permit Extension](https://eips.ethereum.org/EIPS/eip-2612)) ## Connection exposes an account interface An application asks the wallet for accounts and the selected network, then uses a provider to request reads, signatures or transactions. EIP-1193 distinguishes connectivity to a chain from account authorization. A connected provider can still have no account permission. An address lets an application inspect public chain activity and associate that activity with the session. Connection does not require sending a recovery phrase to a website. The wallet remains the component that manages keys and signing. Use [Follow a Transaction](/tools/transaction-walkthrough/) to separate signing from submission, inclusion and finality. Evidence: [EIP-1193: Ethereum Provider JavaScript API](https://eips.ethereum.org/EIPS/eip-1193) ## A spending approval is a separate operation Suppose a swap interface asks permission for a router to spend 50 token units. The ERC-20 allowance records that spender and amount on the token contract; a later transferFrom can use it. Granting permission and performing the swap are distinct state changes even when an interface groups them. ERC-2612 permits let a signed message create an allowance when submitted on-chain. The message binds fields including spender, amount, deadline and nonce. A gas-free signature is therefore not necessarily a harmless login message. Evidence: [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20); [ERC-2612: Permit Extension](https://eips.ethereum.org/EIPS/eip-2612) ## Disconnecting does not erase on-chain authority Removing a website’s connection permission changes its wallet access. It does not send an ERC-20 approval transaction and does not by itself set an existing allowance to zero. The token contract’s state persists independently of the browser session. When examining a request, distinguish the account being exposed, chain, token, spender, quantity and operation. A transaction simulation can clarify proposed changes, but interpreting a signed authorization also requires its scope and validity conditions. Evidence: [EIP-1193: Ethereum Provider JavaScript API](https://eips.ethereum.org/EIPS/eip-1193); [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20); [ERC-2612: Permit Extension](https://eips.ethereum.org/EIPS/eip-2612) ## Questions ### Does a connection give the website my private key? The provider interface is designed to pass requests to the wallet, which manages private keys separately. Account access does not itself reveal the key or authorize every future transaction. Evidence: [EIP-1193: Ethereum Provider JavaScript API](https://eips.ethereum.org/EIPS/eip-1193) ### Can a signature move tokens later? Yes. A valid permit can be submitted later to set an allowance, subject to its deadline and nonce. The resulting spender authorization is separate from an ordinary site connection. Evidence: [ERC-2612: Permit Extension](https://eips.ethereum.org/EIPS/eip-2612) ## Claims and scope ### connecting-a-wallet-quick-answer Connecting a wallet usually lets an application request access to selected account addresses and communicate with the wallet. That connection alone is different from granting a token allowance or signing a transaction. A signature can itself authorize spending, so its meaning matters even when no gas fee is shown. Scope: {"collection":"defi","dataAsOf":null,"blockHeight":null} ### connecting-a-wallet-fact-account-access Account access: Wallet account exposure is an explicit permission boundary. Scope: {"collection":"defi","dataAsOf":null,"blockHeight":null} ### connecting-a-wallet-fact-allowance Allowance: ERC-20 spending permission belongs to a token contract and spender. Scope: {"collection":"defi","dataAsOf":null,"blockHeight":null} ### connecting-a-wallet-fact-signature Signature: ERC-2612 permits authorize allowances using signed messages. Scope: {"collection":"defi","dataAsOf":null,"blockHeight":null} ## Sources - [EIP-1193: Ethereum Provider JavaScript API](https://eips.ethereum.org/EIPS/eip-1193) — Ethereum Improvement Proposals. Account access, chain selection, RPC requests and provider connectivity. Locator: Connectivity; User Account Exposure and Account Changes. Retrieved: 2026-10-02. - [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) — Ethereum Improvement Proposals. The token spending allowance is separate from a website connection. Locator: Methods: approve, allowance, transferFrom. Retrieved: 2026-10-02. - [ERC-2612: Permit Extension](https://eips.ethereum.org/EIPS/eip-2612) — Ethereum Improvement Proposals. Signed approvals have spender, amount, nonce, deadline and domain semantics. Locator: Specification; Security Considerations. Retrieved: 2026-10-02. ## Revision history - 2026-10-02: First publication after primary-source research and independent automated verification. - 2026-10-02: Before first publication, independent review checked and revised: sections, prerequisites. Compared EIP-1193 account exposure and provider connectivity with ERC-20 approve/allowance/transferFrom and ERC-2612 permit fields. Connection, allowance and signature authority remain separate; disconnection does not mutate token allowance. Checked signed permit deadline/nonce/domain scope and the private-key boundary. Added coherent Ethereum prerequisites and the existing transaction tool link. ## Cite this entry Degrees of Satoshi editorial project. “Connecting a wallet: account access, signatures and approvals.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/connecting-a-wallet/