Posted on Jul 27 • Originally published at blog.bulksendtokens.xyz

How do some dApps pretend to have verified contracts when they don't?

#ethereum #smartcontracts #web3 #security

Recently, I started interacting with many DApps for DeFi, airdrops, or NFT exchanges. I noticed that most of the time, DApps are marked as "contract verified", but in many cases, only the proxy contract is verified—not the implementation.

What does that actually mean? And is the contract truly verified in such cases?

Let’s break it down below.

let's start with some context:

The concept of upgradable smart contracts on Ethereum began emerging around 2017, with more formal and secure patterns being adopted by 2018.

Many decentralized applications (DApps) started using this pattern to prevent and mitigate vulnerabilities that could appear in the future.

What Are Upgradable Smart Contracts?

Upgradable smart contracts follow a simple architecture:

A proxy contract holds the data (storage)
An implementation contract contains the business logic

When you deploy the proxy, it stays fixed. However, you can upgrade the implementation contract at any time—without changing the proxy address or notifying users. This makes upgrades seamless, but also potentially dangerous: a malicious owner could swap in harmful logic without anyone noticing.

As shown above, users always interact with the proxy. This proxy stores both the data and the reference to the implementation address.

The issue is: most users only check if the proxy is verified, and ignore the implementation. This gives a false sense of security, as the real logic could be unverified or even malicious.

Real-World Examples

I checked several popular token tools. Most of them only verify the proxy but not the implementation contract.

BulkSender.app

The proxy contract is verified, but the implementation is not:

CryptoSender.com

Same story: the proxy is verified, the implementation is not.

BulkSendTokens.xyz

✅ In this case, both the proxy and implementation are verified, which is how it should be:

Why This Matters

When the implementation contract is unverified, users can't see what logic is being executed. That means:

Hidden service fees could be added
Backdoors might exist
Logic could be changed at any time

If both contracts are verified, everything becomes transparent: you can inspect the code, see the upgrade logic, and ensure there's no malicious behavior.