Open Basescan and look up any two addresses at random. Both will be 42 characters long, both will start with 0x, and nothing in the format tells you which one is a person's wallet and which one is a piece of running code. That distinction turns out to matter a lot more than the format suggests, especially the moment you are about to send something to an address you have not used before.
Two kinds of address, one shared format
Base, like Ethereum and every other EVM chain, has exactly two kinds of account, and both are identified the same way: a 20 byte address written as 0x followed by 40 hexadecimal characters. Underneath that shared format, they work in completely different ways.
An externally owned account, usually called an EOA, is what people mean when they say "my wallet." It is controlled by a private key. Whoever holds that key can sign transactions from that address, and nobody else can. An EOA has no code of its own. It can send ETH, send tokens, and call other contracts, but it cannot run any logic. It only does exactly what the person holding the key tells it to do, one signed transaction at a time.
A contract address belongs to a smart contract, a program that was deployed to the chain and now lives at a fixed address. Nobody holds a private key for a contract address in the way they do for an EOA. Instead, the contract runs whatever code was deployed to it, and that code decides what happens when the address receives a transaction, a token transfer, or a call. Token contracts, liquidity pools, and the router your swaps go through are all contract addresses. So is every NFT collection.
Why this distinction is worth knowing
Most of the time the difference is invisible. You send tokens to a friend's wallet, it is an EOA, the transfer just works, and you never think about it. The distinction starts to matter in a few specific situations.
Not every contract knows what to do with tokens sent to it directly. A standard ERC-20 transfer to a contract address usually succeeds even if that contract has no logic for handling the tokens it just received, because a plain transfer does not require the receiving address to do anything. This is exactly how tokens end up permanently stuck: the transfer itself goes through, but the contract was never built to move those tokens back out, so they sit there unreachable. That is different from a plain ETH transfer to a contract with no matching function, which will typically revert and simply fail rather than succeed and strand the funds. Either way, the safest habit is the same: before sending anything to an address you have not verified, confirm it is the destination you actually intend, whether that is a person's wallet or a specific contract designed to receive that asset, such as a bridge or a deposit contract.
Some interactions are supposed to go to a contract. Swapping, bridging, and depositing into a lending market all involve sending tokens to a contract address on purpose, because that contract's code is what performs the swap, the bridge, or the deposit. That is normal and expected. The risk is not "contract addresses are dangerous," it is sending to the wrong one, whether by mistyping, pasting a manipulated address, or trusting a link from an unfamiliar source. Our guide on address poisoning covers one common way that goes wrong.
Smart wallets blur the line on purpose. A smart contract wallet, the kind built on account abstraction, is technically a contract address. It has code deployed to it, just like a token or a router does. The difference is that the code is written specifically to represent one person, checking a passkey or another signature scheme instead of the classic EOA signature. From the outside it still looks like "somebody's wallet," and for the purpose of sending it tokens, it behaves like one. Our smart wallets and passkeys article goes into how that works.
How to tell the two apart
The fastest way to check what kind of address you are looking at is a block explorer. Look up the address on Basescan and check the top of the page. If there is a "Contract" label and tabs for Code, Read Contract, and Write Contract, you are looking at a contract address, and you can open the Code tab to see whether the source has been verified. If none of that is present, you are looking at a plain EOA. Our guides on using a block explorer and on Basescan's Read and Write tabs walk through this in more detail.
The practical habit
You do not need to check this before every transaction. Sending to a saved address, a Basename, or a destination you have used before is fine without a second look. The moment worth pausing for is a new address you found in a message, a link, or a site you are not sure about. A quick look on Basescan takes a few seconds and tells you plainly whether you are sending to a person's wallet or to a contract, and if it is a contract, whether its source code is even visible. That one habit closes off a surprising number of the ways self-custody transfers go wrong.