MetaWear ($WEAR) Proxy Contract

Disclosure: At the time of writing this article I own some $WEAR.
Update: (04/25/22) I have exited my position. Too risky IMO!

I’ve made a few videos about smart contracts and how to be more careful by looking at the code. Well, I can’t see the code for MetaWear.. but I still bought it. Maybe I’m a moron. Maybe I’m a glutton for punishment. I don’t want to speak too negatively about this project because, well, I do hope the price goes up, BUT… Something happened that deserves an article written about it.

I bought MetaWear because I liked the idea, but I hadn’t done my due diligence. The fact that it had been listed on gate.io was good enough for me. Surely, they must have vetted the token.

This is the point where I admit that I know enough about solidity code to know that I don’t know much about solidity code. But, enough philosophy. Let’s dig into it.

Let’s start by looking at the MetaWear contract: https://bscscan.com/address/0x9d39ef3bbca5927909dde44476656b81bbe4ee75#code

The first thing I noticed was Contract Name: TransparentUpgradeableProxy . This means that when you’re buying $WEAR through pancake swap, you’re not interacting with the token contract. You’re interacting with a middle man – a routing mechanism that points to the real contract. Now obviously, this is a concern since the owner of the contract can point the proxy to any address they desire. But what lies beyond the proxy? I wanted to see the token contract.

MetaWear’s site boasts an audited contract by Hacken, but the audit report refers to a github respository. This means that the audit team at Hacken analyzed the code on github and declared it secure. But what’s stopping an unscrupulous developer from changing something in the code before deploying it to the smart contract?

This is why bscscan has a verification function that works like this: A developer uploads their source code to bscscan. Bscscan then compiles it and checks if it matches exactly the compiled code that was deployed. If it does, the contract is considered verified and gets a blue checkmark. If the contract is not verified, we can’t know for sure what the contract is doing because it’s in byte-code, or machine language.

Now, I’m not suggesting the MetaWear team has done anything unscrupulous. I’m literally just asking questions – and I got banned from their telegram for doing so. That doesn’t inspire confidence. I was told to speak with one of the channel’s admins. After a brief exchange, it was clear he was not a developer. His attitude was essentially “If it’s good enough for gate.io, it’s good enough for you”. I informed him that an exchange listing only proves that someone paid the listing fee. It’s not the same as a security audit – and if the MetaWear github code has been audited, why can’t I see it on bscscan?

Bscscan has an option to check the contract that is behind a proxy.

here’s the link: https://bscscan.com/proxyContractChecker?a=0x9d39ef3bbca5927909dde44476656b81bbe4ee75

If you click “verify” on that link, you’ll see this message:
The implementation contract at 0x3b4a364687b737f02af26a709ae760b3f7b954f7 does not seem to be verified. And of course, the contract we find on the other side of the proxy is in bytecode. There is an option to decompile it, but it won’t be exactly the same as the original source code. Decompiled code is still very difficult to read.

We can see the address that created the contract: https://bscscan.com/address/0x528830f8d8f7cf652d9ef7c5fa5c95e3b485c53e

This address has a public name tag set to “Metafluence: Deployer”. Metafluence ($METO) is another Metaverse project, which appears to be from the same developer(s). $METO’s contract follows exactly the same design: a proxy that leads to an unverified token contract.

Why go through the trouble to verify the proxy contract but not the token contract? If people see the proxy contract has a blue checkmark on it, won’t they assume that means the token contract is verified? As a tinkerer and developer myself, I don’t see why they wouldn’t want to verify both contracts.

It’s possible that that the token contract is just a standard ERC20 being used as a placeholder until the full project is ready, in order to raise funds. However, I don’t understand why they wouldn’t verify it.

It’s always possible that I missed something, or didn’t understand properly. I’d love to get answers to my questions – but after being banned from their telegram and having my emails ignored, it doesn’t look like I’ll be getting any.

Leave a comment

Your email address will not be published. Required fields are marked *