So You Want to Hire Someone to Deploy Your Smart Contract Without Getting Scammed…
Well…
I don’t fault you for wanting to dive head-first into the world of Web3 and NFTs without fully knowing what you’re getting yourself into. But usually, when I consult a new client for the first time, there are a couple common things I hear clients say that are dead giveaways that they would be an easy mark to take advantage of if they ran into the wrong person. The purpose of this article is not to ridicule anyone, and although to the initiated, all of these issues may seem totally obvious, but they’re honestly not.
Lastly, before I start, I would like to invite anyone to contribute to this list. There are no stupid questions in this classroom (lol):
#1: You don’t know and can’t tell the difference between a Testnet and Mainnet.
Any initial consultation with a decent developer (who has done this before) should include a frank discussion about gas prices and alternative options should the client decide that Ethereum Mainnet is too expensive. Honestly, I don’t even think it is always the developer’s intention to scam you if they forget to mention this, but at the very least it indicates that the developer you’ve chosen to work with is inexperienced. FYI, if your developer hands off a project with a contract address that points to “Rinkeby,” “Kovan,” “Ropsten,” or “Goerli,” and they call it done, they’re either incompetent or scamming you.
#2: Landing procedure has not been contemplated or discussed prior to the outset of the project or payment
I’ve borrowed the concept of “landing” a project from my project management days. The “landing” is the point in the project where all tasks are complete (all milestones reached and the contract is fully tested and functioning) and it is time to hand off the project to the client. In the world of smart contracts this is actually pretty complicated. For me, the handoff procedure may take more time than actually writing the program. This is because I have to properly brief the client, establish expectations, and suggest a course of action that the client will be comfortable with.
For example, does the client feel comfortable with me deploying the contract for them. If so, then they will need to supply me with a sufficient amount to pay the gas fees. This requires a significant amount of trust, but if you don’t trust your developer to do this for you, then who did you hire? (More on that later). Alternatively, you could request the developer not deploy and instead deliver the source code to you. It’s a secure option, perhaps. But could go horribly wrong for two reasons: 1) Do you really know what you’re looking at? For all the YouTube tutorials in the world, I’ve seen a lot of “what to do,” but very few “why it is and how it does.” For this reason, deploying the source code yourself won’t safe you from a person scamming you if you don’t even understand what you’re looking at anyway. And 2) Smart contracts are immutable, meaning if you’re planning on deploying to Mainnet yourself, you had better be sure or have some way to check that the developer’s contract does what they say it does (more on that later also). Otherwise, once it’s deployed, you won’t be able to change it. You have no idea how many contracts I’ve audited that have zero flexibility (few to no set functions) or are full of functions that don’t actually do what the client/developer think they do. If you run into such an issue with your smart contract, just know you’ll have to redeploy. Depending on the contract, you may have just wasted $300-$600+.
#3 Admit it. You were being cheap in the first place.
I recently had a conversation with a prospect who was really trying to lowball me on price. We agreed that my services may not be what he was looking for and he asked me for advice on finding a good developer within his budget. I told him this: If you hire cheap, you’re basically begging to get scammed.
My rule of thumb: If the value of the contract you’re deploying is higher than you’re willing to pay your developer for their services, then the difference will be your ransom when it comes time to hand off the project.
Makes sense, doesn’t it? So, you mean to tell me you want to find someone willing to accept $500 worth of funds from you in order to deploy your contract while only paying them $100 or less? If I’m a shady individual, guess which one I’m keeping?
#4 Their service doesn’t include any kind of testing
Just because testing isn’t offered, doesn’t necessarily mean it’s a scam. But to me, it at least indicates that the developer is inexperienced. Testing the contract is so important in this arena because, as I mentioned before, the contracts are expensive to deploy and immutable once deployed. I’ve chai-tested (i.e. written a script to uncover any flaws in my Solidity code) and thought it was perfect until I launched to Rinkeby testnet and literally went through a checked every function. (In this example, I had to do this because I was initially only hired by the client to integrate the front-end design and I mistakenly trusted that the backend developer really knew what he was doing. Oops.)
The reason why I think lack of testing is indicative of a novice Solidity developer is because chai-testing is boring and it takes time. You have to devise scenarios to uncover mistakes in your code, and then understand how to correct them. Copying and pasting from Github or following a YouTube tutorial might seem like all you need to do, and the code you paste in might indeed compile without error. But I’ve seen code that compiled perfectly and the funds got stuck in the contract because the developer hadn’t realized that the withdraw function didn’t actually work.
A Word to the Wise: Even though what you copied and pasted from Github compiles perfectly doesn’t mean the functions do what you intend them to do.
#5 There is just absolutely no attention paid to gas optimization
Gas is expensive, y’all. For your cars and for your contracts. I have repeatedly received contracts that feature a smorgasbord of imports that are totally redundant or unnecessary, every unsigned integer is uint256, and the contract contains a ton of functions the client didn’t need or didn’t even ask for. The files are too huge and they’re causing you to pay more in gas than you even have to.
#6 You don’t know how to read Etherscan/BSCScan, etc.
I don’t blame you. Etherscan’s interface is not very sexy or interesting. But at the very least, you want to be able to confirm for yourself that your developer actually transferred ownership of the contract to you.
#7 The developer asked you for your private key or your 12-word secret phrase
This is probably the biggest giveaway that the developer wants to scam you. Never share your private key or secret phrase with anyone. I think an easy way to fall victim to this is if you want the developer to deploy for you, but you don’t trust them enough to send them funds to do so. (Again, who are you hiring?) In this case, the developer would need your secret phrase in order to deploy from your wallet on your behalf, but once they have your secret phrase, they have control of your wallet and can do whatever they want with it. Your money is gone.
#8 The developer you’re looking to hire has no online presence
In a field where anonymity is valued on the part of the consumer, that is not a thing when it comes to developers bidding for your business. You can find me everywhere and my reputation matters to me. You can read my blogs, my entire peer-reviewed thesis is published online, check my Github, watch my YouTube channel, and ask me for references. When I do good work, I love showing it off. I love inviting clients to connect with me on other platforms. At the end of the day, I stand by my work. If you are seeking the services of someone who can’t point to their credentials or you can’t find a legitimate trail of their work (no social media portfolios where the oldest post is two days old), then erring on the side of caution I would consider it a scam, or at the very least, the mark of an inexperienced developer.
This article is a growing list and will be updated periodically.
