HALOWERK kettenwerk

Checks one address on Ethereum, Base, Arbitrum, Optimism, Polygon or BNB Smart Chain against the open verification registry and against the chain itself. For a proxy the answer is deliberately split in two: whether the proxy is verified says almost nothing, whether the implementation it currently points to is verified is the real question, and both are reported separately with the implementation address read from the EIP-1967 storage slot, the EIP-1167 clone pattern or an implementation() call —

Reads the transaction history of one wallet from a public block explorer index and groups it by kind of action. Classification follows the called contract and method, never the amount - a transfer to a known router is a swap, not a payment. Anything that cannot be backed by a method name stays in the category "unbekannt", which is a valid answer here: a large honest remainder beats an invented assignment. Limits: history comes from a public index available for Ethereum, Base, Arbitrum and Optimi

Runs each step separately as a simulation (eth_call with state override) against the current chain state and reports each result on its own, so a token that can be received but not moved on is visible as exactly that. Nothing is ever executed: no transaction is broadcast, no key is held, no approval is given. Limits, and they are decisive: can_buy and can_sell through a DEX router are NOT simulated - that needs a funded account and a router path this service cannot back, so both stay null. What