Wallet Insights

Wallet Insights are read-only checks on a wallet that are not part of the score. They reuse data zkCodex already reads, so they add little or no waiting, and none of them asks for a signature.

• Wallet Health, at the top of Token Approvals and of a wallet's Approvals tab: one verdict on approvals, account code and holdings.
• Account type and first funder, at the top of the Identity tab: whether the address is a plain wallet, an EIP-7702 smart account or a contract, and who first sent it native coin.
• Transactions, on the Transactions tab: every transaction 20 a page, with filters, an explanation of each one from the explorer and a question to Ask zkCodex about them.
• Wallet Flow, the Flow tab of the Transaction Visualizer: where the wallet's coins and tokens came from and where they went, starting from its first funder.
• Journey and the Activity Fingerprint, on the Journey tab: the wallet's milestones on the network, and six activity axes scored on their own.
• Identity, on the Identity tab: the wallet's public names, social accounts and reputation, its web3.bio profiles and name records, its EAS attestations, its funding trail, the wallets it funded and its activity hours.
• Unclaimed, on the Unclaimed tab: bridge withdrawals never finished, rewards, vested and streamed tokens, fees and locks the wallet left on the network, and on request the deposits still sitting in other contracts it used.

Wallet Health opens Token Approvals (every network you scan) and the Approvals tab of a wallet analysis (that network). It gives one of three levels with the findings behind it. There is no 0-100 health score.

Approvals hidden as spam (worthless tokens, empty balances) never raise a finding. While some networks are still being scanned, problems already found show at once and Looks fine waits for the rest. A check or network that could not be read is shown as such and raises nothing, so a missing answer never looks like a problem or like a clean bill.

Holdings are checked on mainnets only; testnets have no prices. The value spenders could move is in the totals right below the panel.

Both sit in a strip at the top of the Identity tab of a wallet analysis; the lookup starts once the strip is on screen. The funder links to its own wallet page and the funding transaction to the explorer. The type comes from one read of the address's code on the network. The first funder is the sender of the first transfer of native coin into a wallet, found in the oldest 25 rows of its transaction list and of its internal transaction list (transfers paid out by contracts, such as bridge fills). Contracts are not looked up; their type links to the contract page (Contract Details), and Safe multisigs and ERC-4337 smart accounts are named as such.

A funder never changes once found, so the server keeps it and your browser stores it for 30 days. The account type is checked again on every visit, because an EIP-7702 delegation can be set or removed with one signature.

A funder gets a name when one is known: the same address (bridged from L1), a network system contract or a bridge from zkCodex's own list, or otherwise a name tag from Blockscout Metadata, such as an exchange hot wallet. A wallet first funded by "Binance: Hot Wallet" was most likely funded by a withdrawal from that exchange. Hover a tagged name to see where it came from.

For a smart account (EIP-7702) the strip also names the contract the wallet delegates to, with the same verdict Wallet Health gives: known code, unknown code to review, or flagged as malicious. It shows on every network, including the ones where token approvals cannot be scanned and Wallet Health is not available.

The Transactions tab lists every transaction the analysis loaded, newest first, 20 a page. Each row says what it did (a swap, a buy or sell, coins sent or received, an approval, a mint, a bridge, a deploy) with the assets in and out, the app or counterparty, the time, the value and the fee.

• Filters: free text (a hash, an address, a method, a token or an app), the type, the direction (sent by the wallet or received), the period (any time, or the last 24 hours to the last year), a token and an app. The type, token and app choices come from this wallet's own history, each with its count; the direction and period choices are fixed.
• A hash, or the file icon on a row, opens what the transaction did right under the row without leaving the list: it is read from the network's explorer (Etherscan or Blockscout) and says in one sentence what happened, with its status, the approvals it granted and the signals worth a look. Open the transaction page, under that summary, opens its full page in a new tab.
• Ask AI about these opens Ask zkCodex with a question about the period and the type the filters show. With Any time it asks about the last 30 days; Ask reads at most the last 90.

Flow is the fifth tab of the Transaction Visualizer on the wallet page. It reads left to right: Origin (the first funder from the account lookup), Sources (addresses that sent the wallet native coin or tokens), the wallet, and Destinations (addresses it sent to). Line weight follows the number of transfers. On phones it opens as a table with the same rows; the Graph and Table switch changes it anywhere.

• Each side shows up to eight addresses, ranked by number of transfers; past that, the top seven stay and the rest fold into one Other row.
• Direction (both, in, out), asset (the native coin, a token or an NFT collection) and period (30D, 90D, 1Y, All) filter the scan already on the page, so they never wait for a request.
• Tokens minted to the wallet come from a Mint node and tokens it burned go to a Burn node.
• Drag the graph with the mouse to move it and zoom with the buttons in its corner. Full screen gives it the whole window, where the wheel, a finger and a pinch move and zoom it too; on a phone it opens zoomed on the wallet.
• Each node is one line: the address (or its known name) and the number of transfers. Hovering shows the address and what moved.
• Clicking a node shows what moved, when, and links to that address's wallet page (its contract details page for a contract), the explorer and the latest transaction's page (Transaction Details).

Sources and destinations are named from zkCodex's protocol list and the scan first. The busiest 50 counterparties left without a name are looked up once in Blockscout Metadata, so exchanges, bridges and routers the list does not know still show a name. A name tag says who an address belongs to, not that it is safe.

The Journey tab of a wallet analysis opens with the wallet in numbers on that network (onchain since, transactions, active days and months, longest streak, busiest month, apps used), then lists its milestones grouped by year, oldest first. Each one shows its date (UTC) and links the transaction that proves it in the explorer. Under them, Apps over time lists every app from zkCodex's list the wallet used, in the order it first used each, with its transaction count and first and last date. It reads the transaction history the page already loaded; only the first funder comes from the account lookup above.

Milestones not reached yet are listed under Still ahead, with a link where zkCodex has the tool (bridge and swap, NFT mint, contract deploy, GM). For counts, only the next step is shown there, with how many are left. On a network zkCodex has no app list for, the app milestones are left out instead of shown as ahead, and Apps used reads n/a.

The Activity Fingerprint, under Journey, scores six axes from 0 to 100, each on its own. They are not shares of one whole and there is no total. Value, fees and USD prices are never an input, so the Fingerprint does not measure how much money a wallet moves. Open an axis to see its inputs, their curve and weight. The score details no longer label wallets with behaviour patterns; this describes the mix instead.

Linear is min(1, value / target). Log is log10(1 + value) / log10(1 + target), capped at 1, so a single action already counts. An axis is 100 times the weighted sum, rounded.

The line on top reads Light activity so far when no axis reaches 25, Mostly X when one axis leads by 10 or more, and X + Y when the top two are both 25 or more and within 10 of each other. Axes showing n/a are left out.

The Identity tab of a wallet analysis starts with the account (a plain wallet or an EIP-7702 smart account, the code it delegates to, and its first funder) and gathers what public sources say about a wallet: its names, the social accounts tied to it, its reputation, its profiles and the registry records of its names, the attestations it received or made, where its first coin came from, the wallets it funded and when it is active. Each source is read on its own; one that does not answer is named as such and the rest still show.

Every account lists the source and the name or profile it came from. web3.bio's copy of an ENS or Basename record is not counted as a second source when zkCodex read that record itself, so one record cannot corroborate itself.

An attestation is its issuer's word. zkCodex names the schemas it knows by chain and schema id (Coinbase Verifications, Optimism Citizen, Gitcoin Passport, Optimism Retro Funding, Karma GAP, DeVouch, Gitcoin Grants), so a lookalike schema name cannot pose as one; any other schema is read by its registered name and fields. A project record's own website and documents are shown as text; only the platforms' own pages are links. Wallets an attestation ties to this one (wallets it listed as its own in a statement about itself, a grant's payout wallet) and a wallet that holds this wallet's primary name join the linked wallets with that source.

The funding trail stops at an exchange, a bridge, a mixer, a protocol or a contract, at the wallet's own address bridged from L1, at a wallet with no funder in its first transactions, when it comes back to a wallet already on it, or after three hops. An exchange at the end says where the coin entered, not who withdrew it.

Funded wallets leave out exchanges, bridges, protocols and DEXs named by Blockscout Metadata or zkCodex's app list, contracts and calls, and amounts under 0.0002 of the native coin. At most 25 are listed, two-way and repeat ones before one-off ones. A burner batch is three or more wallets this wallet funded first, each within 300 seconds of the one before. Activity hours need at least 10 sent transactions; the quiet window needs 40 and is shown in UTC only. zkCodex does not turn it into a guess at where the owner lives.

The Unclaimed tab of a wallet analysis looks for value the wallet left behind on that network: a bridge withdrawal started and never proven or finalized, a USDC transfer burned and never minted, a reward never claimed, tokens vested or streamed and never withdrawn, LP fees never collected, a lock past its unlock time, creator fees a launchpad holds. It runs the checks of Beachcomb (yusufky63/beachcomb), ported into zkCodex and run on zkCodex's own server, explorer keys and RPC endpoints. The tab shows only on networks at least one check covers: Ethereum, Base, Arbitrum, OP Mainnet, Linea, Scroll, ZKsync Era, Polygon, BNB Chain, Avalanche, Unichain, Soneium, Ink, World Chain, Celo, Shape, Abstract, Robinhood Chain and Plume.

A finding is read from the contract's current state, or from the protocol's own API where there is no onchain state (Merkl, Hyperliquid, Lighter, Circle's attestation service). Explorer history only finds candidates; it is never the proof. A finding counts in the totals only at Onchain confirmed, Multi-source confirmed or Official API confidence; Likely means the amount or timing is an estimate and Needs review is never counted. A position without a trustworthy price shows USD unavailable, never $0, and a priced one under $1 is hidden and counted.

The deposit check simulates, from the wallet at the latest block, every call that could pay it (a withdrawal of its own deposit, or a claim of something owed on top). Only a call a simulation paid is exact; a contract that only returned a number is a hint. Its answers are leads, never findings: no one has reviewed those contracts, and leads are never added to the totals. A tab view asks the 40 contracts the wallet put the most into, within 40 seconds, and lists what it could not ask.

A lead a simulation paid can be sent from the tab, and only from the wallet it belongs to: zkCodex simulates the exact call again on its server, shows the contract, the function and what it pays, and says it sends 0 and approves nothing. The transaction goes straight from the wallet to the contract, with no fee and nothing in between. Approvals and transfers are never sent from here, and neither is a call that would also take tokens from the wallet. Findings are claimed in the protocol's own app.