Most of the time, a wallet confirmation screen reads like plain English. It says you are about to swap ETH for USDC, or grant a contract permission to spend a token. Every so often, though, that same screen shows something far less friendly: a generic label like "Contract Interaction," followed by a long string of hexadecimal characters instead of a description. Nothing is broken when that happens. Your wallet is just missing one specific piece of information it needs to translate the request, called the contract's ABI.
What an ABI actually is
ABI stands for Application Binary Interface. It is a structured description, usually a block of JSON, that lists every function a smart contract exposes: the function's name, the type and order of the arguments it expects, and what it returns. Think of it as a menu. The contract itself only understands raw bytecode, and a transaction sent to it is really just a string of hex data, but the ABI tells any outside software how to turn a human request like "swap 100 USDC for ETH" into the exact bytes the contract expects, and how to turn the contract's raw response back into numbers and addresses a person can read.
This matters because a transaction on Base does not travel as a sentence. It travels as data. The first four bytes of that data are a function selector, a short fingerprint derived from the function's name and argument types. Everything after those four bytes is the encoded arguments. Without the ABI, that entire payload is just hex. With it, software can look up which function the selector belongs to, decode the arguments, and show you something like "approve 0x1a2b... to spend unlimited USDC" instead of a block of characters.
Where your wallet gets the ABI from
For well known contracts, wallets and block explorers ship with a built in library of common ABIs, which is why swaps on major exchanges almost always render cleanly. For everything else, the main public source is contract verification on Basescan. When a developer verifies a contract, they submit the original source code, and Basescan compiles it and publishes the resulting ABI alongside it. Wallets, portfolio trackers, and simulation tools that query Basescan's API can then pull that ABI automatically and decode any transaction aimed at that contract.
When a contract has never been verified, there is no published ABI to fetch. Some tools fall back to public databases of known function selectors, which can guess a function's name from its four byte fingerprint even without the full source. That works often enough to be useful, but it is a guess based on a name matching a hash, not a confirmed description from the contract's own code. If the selector is not in any database, or if multiple unrelated functions happen to share it, the tool has nothing reliable to show you, and you are left looking at raw data again.
A decoded name is not a safety guarantee
It is worth being precise about what ABI decoding actually proves, because it is less than people assume. A function's name is chosen by whoever wrote the contract, and nothing stops them from calling a function "claimReward" or "withdraw" when its real job is to drain an approved token from your wallet. Decoding tells you which function is being called and what arguments it was passed, accurately. It does not tell you what that function actually does inside the contract, or whether the name matches the behavior. That deeper check requires reading the verified source itself, or trusting a transaction simulation that shows the real balance changes the call would cause, since a simulation reports outcomes rather than labels.
So a clean, readable confirmation screen and an honest transaction are two separate things that usually, but not always, line up. A well named function on a verified contract is a good sign. It is not proof.
What to do when a transaction is unreadable
Seeing "Contract Interaction" and a hex string instead of a plain description is not automatically a red flag. Plenty of legitimate, newly deployed contracts are unverified, especially in the first hours after launch. But it is a moment to slow down rather than tap confirm on habit, particularly if you were not expecting to interact with that specific contract at all. A few things help:
Check whether the contract is verified on Basescan. Search the contract address directly and look for the verification checkmark. If it is verified, you can read the actual source and see what the function you are calling does, not just its name.
Lean on simulation if your wallet supports it. A simulated preview of token movements and approval changes tells you the outcome regardless of whether the ABI decoded cleanly, which is often more informative than a function name anyway.
Treat an unreadable, unexpected request as a reason to stop. If a page you did not initiate an action on suddenly asks you to sign something opaque, that combination, unfamiliar source plus undecodable payload, is exactly the pattern behind a lot of wallet drainer scams. Closing the tab costs you nothing. Signing blind can cost everything in that wallet.
The ABI is a small, unglamorous piece of infrastructure, but it is the reason a confirmation screen can ever tell you the truth about what you are signing. Knowing when that translation is missing, and why, is what turns a wall of hex from a mystery into a clear signal to pay closer attention.