The stablecoin race has been going on quietly for a long time until recently. Almost every ecosystem has its own stablecoins; Ethereum, Solana, and even Hyperliquid. But how come there has never been a Bitcoin-backed stablecoin? This is where Hermitica’s USDh comes into the chat! Perhaps you just heard about USDh and you’re curious about its internal mechanics. Or you are considering whether you should invest in it… This short blog has everything you need to know; from how the yield works, to the risk, and even a review of the smart contract behind it. What is USDh? USDh is a yield-bearing dollar-pegged stablecoin backed by Bitcoin, instead of fiat or an algorithm. At the moment, it currently has a Total Value Locked (TVL) of $6.6 million. Created by the Hermitica team, there are 2 main theses behind why USDh was created. The first is how no stablecoin is backed by Bitcoin. Of course, some popular stablecoins like USDT are backed by dilution of Bitcoin, gold, and bond. But none is fully backed by Bitcoin. Meanwhile, Bitcoin has proven to be the most sound monetary system over the years with incremental adoption and economic relevance. Also, Bitcoin is an onchain asset that is not controlled by any nation-state, which makes it a perfect backer for a solid stablecoin. Moving on, the second reason rests on how holding stablecoins doesn’t profit the holders. For instance, anyone who keeps $500k worth of USDT will still meet that same amount in the next 6 years. For context, there are now avenues where you can stake USDT for rewards. However, none offers the percentage of yields that USDh currently places on the table. USDh was created to effect a change where holders can get rewards, or yields as we prefer to call them. There is a promised 25% APY on USDh, and we will explain how such a percentage of yield is accumulated later on in this blog. Hermitica has been running the token for over a year now, and its APY mechanics seems to be working. Of course, this is not to mean an investor should 100% trust the system. Bear this in mind, because a protocol has delivered on a promise in the past is not a guarantee it will do in the future. That said, the APY scheme seems to be among the highest in the market. How is it created and pegged? The system of minting USDh is pretty straightforward: any doxxed entity can approach Hermitica to mint the token, so far they are willing to deposit Bitcoin in return. The main concern here is how Hermitica emphasizes KYC/AML. While these preconditions can be understandable from a regulatory perspective, they raise concerns on the cyperphunk philosophy, which is based on anonymity. At the moment, these entities are largely exchanges and big protocols that want to provide USDh as liquidity within their products. That said, they can always redeem their USDh back for their Bitcoin, if they so will. Moving on to the peg, what are the systems in place to ensure one USDh is always equal to $1 USD? This is where the concept of Arbitrage comes in. Hermitica has some approved addresses that can exploit the difference in the price for their benefit. If USDh drastically drops to $0.7, they can buy up lots of the token and sell it to the protocol at the $1 tag to stabilize the market. Again, if it’s the case that it’s higher than $1, they can mint more USDh at $1 to draw down the price to its peg. Along this line, there is also an Hermitica Reserve Fund kept specifically to stabilize the market and manage any onchain stress. So, where does the yield come from? In DeFi, we say if you don’t know where the yield is from, then you are the yield. Yes, USDh promises an impressive APY, but you must also investigate how that yield is made. Or else, you are one rug away – remember UST! The yield mainly comes trading Bitcoin futures. If you are also familiar with futures trading, then you must be well aware of funding rates; simply put, it’s the fraction long traders pay to those who short. Now, since Bitcoin is always going up, there will always be longed trades. As a result, long traders will always pay funding rates. It is from these funding rates that USDh extracts its yield, demonstrated in sUSDh, to pay holders. See it this way. Long Bitcoin trades → Funding Rates → Yield What are the risks in buying USDh? Just before you go ahead to add some USDh into your portfolio, you should be aware of the things that can go wrong and can potentially make you lose your bags. It’s not the case that these risks will happen, but they sure have a chance of occurring. As a result, you should prepare your mind; diversify your holding, and be on the edge. Platform Risk There are many platforms involved in how liquidity is stored and moved for USDh. The first one is the treasury. Hermitica seems to be quite transparent with how they are storing the funds at Copper and Cefu. If anything goes wrong there, there will be instability in the market. But on a good note, there is no history of breach with these platforms. The second one is the risk around exchanges. USDh revolves heavily around future trades, which heavily happen on exchanges. There can be market instability if these exchanges are hacked. Excessive Bitcoin Shorting The entire premise of generating yields is predicated upon the fact that traders will always want long leverage in Bitcoin. The aforementioned premise is further based on the fact that Bitcoin will always go up, and there will always be demand for it. However, what if Bitcoin has a sudden marginal fall, and the desire to long leverage it drastically reduces? In that case, there will be no much yield, and the promise of

Recently, USDG came up as one of the topmost stablecoins in the Solana ecosystem, and it is equally gaining gradual adoption in the EVM. If you are a developer or security researcher, there are quite a lot of exciting things you will want to know about USDG. For instance, even though it’s an abstraction of legacy ERC20, it has a couple of modifications, it’s denylisting bit calculation is also one for the books. Do you want to build a similar product and wants to understand the nitty-gritty? Or you want to find criticals in the codebase and are looking for technical chops to start? Keep reading. The project has 3 components: Let’s take it one after the other. Diving into the ERC20Upgradeable_V2 The ERC20Upgradeable_V2 is a succession of the initial ERC20Upgradeable contract with a zero-day vulnerability; we will cover the details of this implementation flaw later on. By the way, we will only cover the functions that are necessary and jump over the overly straightforward ones. Imports and State Variables The contract uses some upgradeability imports from OpenZeppelin such as: You will get to know how these libraries are utilized in the contract, as in their specific purposes, as we move on. Of course, the created usual ERC20 mappings [like balances and allowances] and variables like _totalSupply, _name, and _symbol all of which are made private as anyone would expect. But this is where you need to pay attention: how the BALANCE_DENY_FLAG_SET_MASK and MAX_ALLOWED_SUPPLY are created. Put on your thinking caps. Explaining the BALANCE_DENY_FLAG_SET_MASK Design and Implementation For you to fully understand what’s going on here, I have to refresh your mind on some basics of Computer Science, particularly bits. Bits are the smallest unit of data processing and storage. Bit are always been 0 and 1. On the other hand, a byte is a bunch of 8 bits. In line with that, a storage slot in the EVM stores 256 bits, which is an equivalent of 32 bytes. Hold that on one hand, we digressed, now, let’s go back to the denylisting variable. Hope you understand it to this point. Moving forward, you definitely know that data fill storage slots linearly. However, in cases where we need to manipulate slots and have more control, we can use masks – this should ring a bell if you remember bitwise operations well. This is what the developers of USDG did here: In plain language, denylisted objects will be pushed to the last bit of the binary for easier identification. By the way, have you wondered why we shift to 255 instead of 256? The reason is simple: 0 is an actual value in binary, so our bit started from 0. If you count 0 to 255, we have 256 numbers. Hope you get it. Well, I’ll now explain the entire design with a story: Imagine you are in a barrack with 255 rooms, with a guardroom at the 255th room. So anytime a soldier messes up, they switch their room from say R6 to R255 where they will be locked there for a long time. Why this design decision? Left for me, I would have simply created a boolean variable where I can simply denylist by saying denylisted = true or something similar. This is quite what any dev would have done, it’s the easiest and most straightforward technique you can think of. However, the USDG smart contract architect noticed a huge problem circle was facing – denylisting with other methods are quite costly, unnecessarily so. According to Alex Kroeger’s research, the blacklist functionality of USDC eventually cost approximately $4 million in 2022. This was absurd and equally unsustainable. Hence, from the onset, USDG took a different approach with regards to implementing denylisting. In short, the reason they used bitmask was to make the contract more efficient. Explaining the MAX_ALLOWED_SUPPLY Design and Implementation The same bitmask technique used above was used here, albeit with slight modifications. Here is a breakdown of what the devs did here: You might want to ask, “why not shift the bit to 254, so there will be no need to reduce it by 1 slot?” That’s really a brilliant observation. Just that Bitwise operations don’t work that way, especially in line with the intended design. If we quickly pull it up to 255, that will be the arbitrary highest bit in the slot, and that will backstab our intended design of keeping denylisted objects at 255. ERC20 Initializations This is an upgradeable contract, meaning we can initialize it without or with constructors. Thus, the name and symbol variables above were initialized. In each cases, they both have the onlyInitializing modifier which will prevent reset from blackhats. You might wonder, what’s the different between these two initialization techniques. The full gist is on OpenZeppelin docs, but I’ll do a quick abstraction. The latter can be overridden in child contracts, while the former is specifically for this contract itself. Native OZ ERC20 Functions For proper customization, some functions must be modified in the contract. This includes name and symbol. Let’s zoom in a bit on how the balanceOf was implemented: return _balances[account] & ~BALANCE_DENY_FLAG_SET_MASK; The instruction in this function is the balances of accounts along with their status of denylisting, whether they are or not, should be returned. This line is quite a marriage of bits, let’s take some time to break it down: The transfer, allowance, transferFrom and approve functions work normally in accordance with usual ERC20 implementation of OZ. Allowance Incrementation and Decrementation One of the banes of approvals is that things can go south and you wouldn’t be able to decrease or increase your approved tokens as you wish. More particularly, if you give a maximum allowance or you were compromised, you cannot reduce your allowance. In the increaseAllowance function, the first control implemented is that only the sender can give it. Secondly, the logic adds new value to the existing given allowance. Moving to the decreaseAllowance function, it checks, first of all, that

If you are set to found a protocol in this industry, you must have had to ask yourself this question during your research face, “How come many protocols similar to what I want to build are no longer around today?”

This is a valid question and introspection; it shows you want to build something that lasts, which is commendable.

How would you feel if there were an application on Solana for you to track your expenses? Great, right? That is the goal of this tutorial – to build an expense tracking program with Anchor. Anchor is quite a dynamic language for any developer to express their ideas and build them into products on Solana. Apart from the use case, this tutorial will also help you become more comfortable with Anchor and also learn more about the language along the way. Scope of this Tutorial This tutorial is more of a CRUD onchain application. It enables users to create an expense, modify, or delete it. In the process of creating this application, you will also learn more about both Anchor and how SVM works. For instance, you’d get to know more about the practical application of seed bumps, contexts, PDA and so on. After writing the program, you’d also test it with a TypeScript client to be sure the program works as expected. Obviously, this will also make you more comfortable with TypeScript. Setting Up Anchor Before you can build a program with Anchor, you obviously should have it running on your machine. It’s so simple to setup. Simply run this command in your Ubuntu [or perhaps Bash]: It will not only install Anchor, but every other dependency you need to have it run. This includes: Once you are done running this, you should have this printed on your terminal: Step-by-step Guide on Building An Expense Tracker with Anchor Now that you have Anchor setup, it’s time to commence writing our program. For this tutorial, I’ll recommend using the Solana playground online IDE. You can create a program file with lib.rs In this program, we will be utilizing structs to pack our application’s features. Step 1: Importing Anchor and Kickstarting the Program In the first line above, we imported the prelude of Anchor. Essentially, this acts more like a library that contains everything we need to build our program with Anchor. Remember that we are not using native Rust, so prelude importation gives us access to types and macros we will need to use Anchor conveniently and without have an unduly verbose program. Some of the types and macros in prelude include #[program], Context, system and so on. Immediately after importing Anchor, we declared [or rather set] our program ID – this is the public key of your program. If it were to be in the EVM world, program ID could have been called contract address. Hope you get it. Now, your program ID will be needed to generate Program Derived Address (PDA) and also for validation when you are writing a client test. In a test project like this, Solana playground automatically supplies one. All you have to do is just put the ””. The #[program] macro we wrote next tells the compiler [and SVM by extension] that the block of code next to this should be treated as the core part of the code. These are the functions that users can call and interact with. Once that was done, we went ahead to create the etracker public module. Meanwhile, the way pub works in SVM is similar to public functions on Ethereum. Mod there refers to a module, which is more like a packet for functions and or instructions. And here is where you must pay attention: use super::* has a close connection with the anchor prelude we set at the beginning of the program. It allows our local functions to use the types that anchor prelude imported. Step 2: Creating the Initialize Expense Function This is a public function named initialize_expense. It has 2 main parameters: context and ID. The work of Context above is deeper than it appears. It is an Anchor type, which works on account validation and access security constraints before a user can call a public function. NB: You can read more about Context here or I might write another technical blog on it soon. The id contains the details a user must pass into the function as arguments. In the instant case, we demand id, name, and amount. We want this function to return something, hence the reason we included Result. This is why we have Ok(()) at the end of the program. We could have gone on another route of error handling, where we set the error in case anything in the function fails. Moving on, we created a variable called expense_account within the initialize_expense function, and made it mutable so we can modify it later as we want. Subsequently, we assigned the parameters of the function to their respective types. But if you notice, we set the owner to *ctx.accounts.authority.key. This simply means the owner has access to the authority key of the context accounts. Step 3: Creating a Modification Function This is a function that modifies expenses. It takes in some parameters like id, name, and amount. Then these parameters were assigned in the body of the function. For context, this function makes it possible to change anything on an already initialized expense. Step 4: Creating the Initialize Expense Struct We have created an initialize expense function above. Nonetheless, we will also create an initialize expense struct. Don’t confuse both of them. The first one defines what accounts can do when they call the function, while the latter is more about the accounts that can interact in the first place. #[derive(Accounts)] is a macro in Anchor that deals more with the cryptographic security of the interacting accounts. It validates accounts, verifies signatures, and does general safety-check. #[instruction(id: u64)] essentially passes args into the #[derive] struct. The id that the instruction passes will be used in the struct of accounts. Then we created a public struct called InitializeExpense and passed info as a lifetime annotation. Since info has quite an infinite duration, it makes the struct enjoy the same attribute. Then we created a mutable account, meaning we can change its state, and gave the Signer public authority. Once

Proper tracking of monetary flows is always helpful in personal finance. I participated in a recent hackathon where I built an MVP that users can utilize in visualizing their bank statements. This blog is a break-down of this feature. You’ll learn how you can also build the same with Python for backend and Nextjs for frontend. Interestingly, you’ll learn how to use some python libraries for data visualization, which are quite impressive. Building the Backend Let’s write our backend with Python. You can create a folder, and then a file called app.py for the program. Step 1: Dependency Installation Head to your terminal and install . Step 2: Import Dependencies Once these deps are installed via the terminal, they should also be imported into the program. These are important libraries in our application. For those who are not aware, Flask is a web framework for Python applications. In the instant case, it will be useful for building our API routes and connecting them with the web successfully. We will also be using Request, a native Python library for efficient HTTP interaction. It will be useful for accepting data from API routes that are sending information. Along this line, Jsonify helps us in communicating back to the API we will create so our frontend and backend can communicate effectively well. Now, you should bear in mind that we want our API to be accessible from any point, and this is where Cross-Origin-Resource Sharing becomes useful. By the way, browsers block this to checkmate security threats, but we are enabling it intentionally for what we want to do. Moving on to Re and Counter, their main purposes is largely for pattern matching. Step 3: App Initialization This is where we initialize our Flask application where name is passed as the root path. Then we enabled CORS. Step 4: Transaction Extraction This function helps us extract the data we need from the provided bank statements. The sample bank statement we have has “send to” and “received from” pre-fixes for fund flows. As a result, we are incorporating that into our program for easier catching. We created an POST API route for it called /paste . Step 5: Paste Transaction Now, many bank statements have various formats of pdf and formatting that our program might not catch. Therefore, it is better to request customers paste their statements rather than upload them. On this note, here is a function that does that. Immediately after declaring the function, we also ran the application. Here is the full code: Creating the Pie Component Add a PieCharts.js component. Here is the first slice of our frontend part. Step 1: Initialize Nextjs Run this in your terminal: npx create-next-app@latest my-next-app Step 2: Install Recharts We have to install Recharts for our pie data representation: Step 3: Chart UI The stage is set to build our pie-chart UI: In the code above, we installed the necessary things we need from recharts, then set the colors and layout of our application. Here is the full code: Transaction Pasteing Interface Create a PasteBankStatement.js page. You can paste this code: Here is a brief rundown of what went on here: Demo Run both the Python application and Nextjs program. Open your localhost, then paste this sample bank statement. You should have something like this:  That’s it! Leave a comment if you find it helpful…

From the very day you got the idea of what your Web3 startup will be, you will also think of various ways it can possibly become big. Even though you have read Paul Graham’s essay about doing things that don’t scale, you have some low-key plans of how you want it to scale. Today is not the day I catechize on various Startup building rules. But this is my main point: from launch to seed stage and series A, you always think of scaling in whatever way possible. If the Startup is bringing an average of $3k MRR now, as a visionary founder, you will think of ways to increase it to $5k MRR ad infinitum. And that feeling, my friend, is valid. Without much ado, I am writing this short essay to teach how you can dramatically increase the activities and revenue of your protocol. You might want to ask, “John, have you built production-level Web3 protocols or startups before? Why should I listen to you?” I understand you. It’s normal. We are in the internet age where everyone tend to tell you what they haven’t even practice. So I think I should commend your intelligence for bringing up that observation — impressive! I won’t beg the question, here are a few reasons you should take what I will tell you seriously: So anything I tell you is a result of various insider-level experiences I have. That was quite an unusual introduction, don’t you think? Anyway, let’s quickly get into the main discourse. The Era of Developer-to-developer Content What marketers or DevRels call “D2D Content” means Developer-to-Developer content. This often involve publishing developer tutorials, documentations, workshops and lots more. Here is a good fact to keep in mind: developer-centric content have been a thing from the Web2 days. So it is not native to Web3. For those who are aware, Postman, RapidAPI, Vercel and other Web2 companies are really focused on pushing out content to educate and marinate the developers that use them. Why is Web3 content marketing also going this route? You need to understand that the bulk of Web3 is technical. There is always one migration to do, a component to reroute, an API to call, an ABI to insert. You should be familiar with these things too. For example, an RPC provider will always push out content around smart contract development and deployment because that is what their target customers do. A smart contract security firm will center their content marketing efforts on how to build secure code and educate people more around Web3 security. Why? That is the audience they are trying to attract. In short, the services or products of several Web3 companies are technical. Now, do you see why developer-to-developer content is essential? But there is something more exciting, and I will share it with you. D2D is now the Gateway to Web3 B2B For the technical folks who might not understand what B2B approach means, it means a Business-to-Business content narrative. Now, you might wonder, how will D2D lead to B2B? Let me give you two examples: The first one is Linea, an Ethereum L2. Their content marketing is entirely focused on developers. This way, they attract people who build DApps on their network. The ROI is in two ways; a DApp that exists on another blockchain can support them, and a new founder looking for a suitable blockchain might come across their content and choose to settle on Linea. That means they are attracting more businesses to build on them. The more these DApps growing in user activities and revenue, Linea gets more network activity and slices of fees from the DApp’s revenues. This is how L2s make money. Another example? The second example is Biconomy, a protocol that helps abstracts gas payment for Web3 DApps. They also create a lot of D2D content, which makes them prominent whenever developers are thinking of implementing gas abstraction in their projects. This way, they are selling their products to other businesses or protocols in the space. How can you commence D2D content? Now that you know Web3 D2D content is the way, you might wonder about how you can commence it for your Web3 protocol. To make everything short, these are the two things you should look out for: Teach Devs What They Can Build With Your Product There is a saying in marketing, “don’t say the feature, but the benefit.” It is old, but gold. Don’t say you are the next gen L2 with abstracted ZK layer using lightweight microprocessor. What people rather care about is how your product helps them. In the same way, if you are building a protocol similar to The Graph, spend the bulk of your content effort teaching developers how to index and query on-chain data with ease with their favorite stack. Show people what to do, and a good way to show this is to create tutorials—whether video or content—on it. This will help prospective users know the capability of your product. Hold Workshops There is a Web2 developer Startup that I love so much – Platformatic. One of the things I admire about them is how they hold periodic Node.js workshops to groom developers using their product. I have always loved and followed each of their workshops because they make me a better dev; I will always learn something new. Indeed, their attendance grew. That is something you should keep in mind: devs will always be where they are getting value, and D2D content in workshops is a goldmine. Plan the workshop in a way that will not overwhelm you; the best frequency is the monthly one. Here is another bonus: you can turn your D2D blog content into what you will explain in greater details during the workshop. How about a technical content engine for your Web3 D2D content? Really, how does it sound? While you are going about with business development, product building, and other core tasks, what if there is a

Have you ever tried to send funds to your friend in Syria or Nigeria with Stripe or Paypal? Then you will get what I mean. Incredibly, crypto is the first payment system that broke down the walls of international payments for everyone regardless of where they live: lower barrier of entry and incredible speed. Indeed, it is a game-changer. At the same time, I have met people who do not take the idea of crypto seriously. You might ask, “C’mon, everyone sees how easy this system is, why would anyone not like it?” I am a crypto-native, but I must also agree that these people who don’t take crypto seriously are not entirely wrong. I am mainly writing this for my fellow builders, so we can build what more people will take seriously. This is more like mainstream feedback we all can use to build better products and a saner ecosystem. The Parallel of Ponzi and Meme Economy This is the pattern of ponzi programs: people rush into it, so they can cash out and dump on others. So the first set of people gain by using the last sets as exit liquidity. Unfortunately, this same pattern powers some crypto projects at the moment. They claim to have some utilities, which are either unrealistic or even worthless. Then they pump millions into these tokens to attract people. As people buy into it, a point will come when demand will stop, and the token will no longer be worth anything.  Some call this the meme economy, but we all know it is extremely fraudulent and simply a pyramid scheme. Yes, some traders often gain from these meme projects because they are after their bags. But from any ecosystem perspective, I do not fancy the idea of meme tokens; they misrepresent us to the wider world. Frequent Cases of Security Breaches Anyone building a financial product in any industry should be security-minded, whether Web3 or Web2. However, the cases of hacks in Web3 are way too much. Do hacks happen in Web2? Yes, but the number is not close to Web3’s. From a financial perspective, people put their money where they trust. To be honest, who would want to put their life savings in an industry where they can wake up tomorrow and someone would have stolen everyone’s funds? That is why some people will always prefer to keep their funds in banks where they are double-sure it will be safe.  People don’t really care about decentralization or any grammar we cook up, they care about the overall safety of their funds. They want to come back in the next 6 years and see their funds intact. People want financial security, they can’t play with it. As a founder of a crypto product, work hand-in-hand with nerdy and insanely good security researchers to secure your DApp. You owe your users that duty of care. Transaction-related Frictions I am a Technical Content Manager in a company where I also have the authority to pay the content creators I manage. I can remember a month when I wanted to pay a staff from my wallet, and I couldn’t because I could only pay gas fees with ETH. In my mind, I wondered, “Since I have USDC in this wallet, why then can’t I simply pay the gas fee with USDC?” I mean, isn’t that the similitude of what banks do? This is my feedback for builders: build products that are easy to use. It is that simple. Feedback to Get Better As I mentioned earlier, I mainly wrote this for other founders to build products people can trust and easily use. I believe crypto will go mainstream in the future. And no, the memecoin projects won’t take us to the limelight. Crypto products that are safe and easy to use will take us far. I am not a bystander, I am building too, so—like I said—this is a note to other passionate builders.

Any production-worthy codebase must be secure and safe for its users. Imagine a financial application where the users’ passwords are plainly available in the database. Such a product is way more susceptible to malicious attacks. Not long ago, threat actors stole over 8 million passwords of DailyQuiz users because they were in plaintext. In this short tutorial, we will go over how to hash passwords from the backend for higher security. We will leverage Bcrypt, a cryptographic password hashing library to do this. Whether you are a more advanced Node.js developer or a junior, this tutorial will be simple enough for you to follow and replicate the same thing. A Brief Note on Bcrypt There is a popular belief that cryptography is mainly applicable in decentralized finance and popular tokens such as Bitcoin and Ethereum. While this is right, it is not holistically true. Cryptography has been a bedrock of privacy in engineering, including the zero-knowledge space. That cleared, Bcrypt is a cryptographic library that complicates passwords. For instance, if a password is plainly “PharaohOfTech,” it will be encrypted as “$2a$12$kB5WhlAaQfzQYUoNPBjgXe6QlbCF/Ciofp1U3/d4TaQa9drfMXPei.” How does it work? Bcrypt takes in a human-readable password and transforms it into a 72-byte alphanumeric characters. Within a single encrypted password is a hash algorithm identifier, rounds identifier, salt, and computed by hash; in that order. With the way it encrypts passwords, it protects against brute-force searching and rainbow table attacks. In fact, big companies like Linux adopted it for some of their products. At the moment, Bcrypt does not have detailed documentation. Anyone who wants to know more about it should read and probably contribute to it on the NPM website. Requirements Project Initialization Run this command to initialize your project: It should initialize a JSON package, which you can modify if you want to. Install Express and Bcrypt Express is a Node.js framework, which we will be using. As mentioned earlier, Bcrypt is a password privacy library. Enter this command to have them both in your script: Rest Client This is a VS Code extension we will use to test our routes. Download on the VS Code extension marketplace. Step-by-Step Guide: Building a Secure Node.js Application with Bcrypt Create a file named server.js in which you will write the code in the subsequent subheading. Step 1: Setting Up Express and Bcrypt Libraries Express is a popular JavaScript framework we will use in this application. Therefore, we had to import it into our application using require. Having set-up Express, the second line helps us create an Express application. You might wonder how. Check Node Modules, search for Express, click on Lib, then check out express.js. Notice there is a createApplication function there with an app variable. Thus, the const app = express() done above implements the inner function explained above. Moving on, we set up the Bcrypt library in the third line. Step 2: Creation of User Array and JSON Settings JSON is a human-readable method of storing, displaying, and communicating data across several applications. We want the usernames and passwords of the users to be rendered in JSON eventually. Therefore, the first line is a declaration that Express should process and display data in JSON format. Data of who? The users. This prompted us to create an array of users. A quick digression here: this approach is not a smart engineering decision for production applications. Integrate your data into a database software like Supabase. We only used this approach because this is simply an extremely basic application. In relation to the above, the GET function stores data from the users array created earlier. Step 3: Creation of User Routes This is a POST request with a predefined /users URL indicating user’s path. We made the request asynchronous within the parameters for concurrent request and response interaction. The main idea of the rest of this code block is that the user should be able to create their usernames and hashed passwords. This was implemented with a try/catch. The first line in the try is for salt generation. Recall that salt, in the instance case, is a cryptographic add-on that makes hashed passwords harder to crack. Then we spelt out that the users must supply their name and passwords, which will be turned to a hashed password at the backend for security reasons. Once this is done, the user is pushed into the user array created successfully at the state. Peradventure, the activities do not flow as defined above, there is a catch statement to return an error 500, which is an HTTP status code that shows the request cannot be generated. Step 4: Creating the Login Route At this stage, the users can create their usernames and passwords but cannot log in yet. This POST request predefines the users/login route. For authentication, we compared every user.name with the req.body.name. Within the if statement, ‘||’ is a the logical Or operator which checks the truism of operands and returns the boolean true or false as the case may be. The statement checks whether a user is null or undefined; if true, it returns a bad request with error 400. Having taken care of the users, it is time to fraud-proof the password. We created a isPassword variable to compare if the provided password actually matches the password of the purported user within the database. If this is true, the user should be given access into their account. Otherwise, access should be denied. The last line is a statement that makes the server listens to the connection on port 3000. At the end of the day, your server.js should be like this: Testing the API with Rest Client Run this command on your command line to run the server: Then create a file named request.rest where you will create a port for each route thus: Note: You can use other usernames and passwords for testing your API. Once you have this in your VS Code, you will see a “Send Request” link on top of each of

Smart contracts, unlike what most people think, are not smart in themselves. Humans write them, and humans are imperfect; therefore, smart contracts often contain vulnerabilities. There are tales of reputable protocols that hackers drained. Should I start with the story of The DAO hack? Or should I talk about the Euler Finance hack? Numerous incidents of hacks threaten the prosperity of Web3. This is where Web3 auditors and security researchers come in. They help review smart contracts and protocols and detect their vulnerabilities on time. Thereby helping the team to fix up. Within a short time, Web3 security has also become a recognized business like the general cybersecurity in Web2. Spearbit DAO, one of the leading security firms in Web3, pays their junior researchers $3k weekly, and lead researchers take home nothing less than $20k weekly. Yes, the Web3 security space is that lucrative. However, I must also be honest and clear to say that a greater percentage of researchers don’t even earn anything close to the above figures. You can ask anywhere. So, how do you stand out and build a profitable audit firm or solo career? I explained everything here. Be Technically Sound “You cannot build something on nothing and expect it to stand.” – Justice Niki Tobi of Blessed memory To thrive in Web3 security, you must know your onions. As the founder, you have to be technical; you should know about security yourself, too. Once a good number of your clients get hacked, you start getting bad PR in the industry as incompetent. Most leading firms or auditors with no record of their clients getting hacked are always topping in the space. Now, how do you become technically sound in security? Go take the Secureum Bootcamp, learn from Damn Vulnerable DeFi, and participate in CTFs. Of course, you should have learned languages like Solidity, Rust, Cairo, or anyone that catches your fancy. Apart from that, read audit reports. Don’t only read for the sake of reading it, critically study and know how blackhats think. Everything I have mentioned above is good, but they are insufficient to make you a sound researcher. You need to start auditing. Become a security researcher on Code Arena, Code Hawks, Sherlock DeFi, and Immunefi. Roll your sleeves and get into audit contests; that will sharpen your skills and make you have testaments of brilliance. Again, I emphasize being technically sound. Before learning about the business side of things, you must be exceptionally good. Quality services, like I always say, are easier to sell. Learn and Master Sales The difference between profitable and not-too-profitable auditors is not necessarily skills. As a matter of fact, there are a lot of skilled auditors in the space. If you want to build a business in the security space, you need to realize that tech is one thing, and business is another thing in its entirety. Start to think like an entrepreneur. For a moment, drop everything you know and start learning about marketing. Learn about customer journey, conversion, and retention. How do you brand and sell your service? What gives you an edge over other solo auditors or firms? Do you know who your target audience should be and how you can talk to them? As a founder, this is more of what you will do as time progresses. Don’t delegate sales. You have to do it yourself. Get your first 10 and 50 clients with whatever you have learned in sales. I may write more about this in the future. Get More Brilliant Auditors Onboard Initially, I told you to be exceptionally good at Web3 security. That is valid. Without prejudice, it is sheer arrogance to think you are the only best researcher in the world. No, no. There are other exceptional people around. Look for them and tender your offer. Having more brilliant people in your team will help you provide more bespoke audit services. Two good heads, they say, are always better than one. Don’t pick based on familiarity or closeness when hiring people to join you. Check out the most promising security researchers in audit contests. Use meritocracy in choosing your team members. By the way, you do not have to look far when assembling brilliant people into your team. They are always around you. When I kicked off my company, I realized some of my friends were exceptionally good, and I am now building with them. So, while you are objective enough to look outside, don’t forget that Twitter bro you did peer-audit together the last time and discovered critical vulnerabilities in a contract. Put Structure Into The Business I worked in a Web3 security firm earlier this year, and I enjoyed the structure of the business. It enhanced efficiency for everyone. As a founder, you must realize that you, as the leader, only need to focus on the most essential things for the company to move forward with an impressive face. Don’t be the only one managing payment, accounting, client communication, etc. You must entrust responsibilities to other members of the team as well. Who will manage your social media? Who will attend events and represent the companies? Who will always be available to hold discovery calls with clients? How will you maintain relationships with clients post-audit? You need to answer these questions and put structures in place accordingly. When that is fixed, you, as the founder, can decide to be the lead security researcher and catch any bug your teammates might have missed. The goal of having a structure is to optimize for performance and efficiency. Attend Web3 Events I have heard many people say events are a total waste of time and that any serious developer or researcher should not bother attending them. Those who hold this view are equally right and wrong in some contexts. Know this: You should never jeopardize the primary purpose of your firm, which is excellent security research, by merely attending events. I mean, your researchers should not get too busy

I began my Ethereum smart contract engineering journey some years back. My main motivation was to increase my technical proficiency in the Web3 space. The first question I asked was, “Which language do I need to learn?” Everyone I reached out to recommended Solidity. After over a year of writing Solidity, I got to know that there is another popular language in the Ethereum ecosystem called Vyper. When I heard the word “Vyper,” my mind mapped it with Python, a popular Web2 language. I became interested in this new language, and took about a month to enter its rabbit hole. I really enjoyed writing Vyper because it was a simple and easily readable language. I must also admit that my knowledge of Solidity and Python helped me grasp it faster. Months after I took interest in Vyper, the Curve Finance hack happened. In this hack, the attackers exploited a compiler bug in Vyper and siphoned funds from various projects. This was the time Vyper got the attention of a greater number of developers in the space. Enough with the backstory, the main reason I am writing this is to explain that the Web3 ecosystem needs more Vyper developers. Then, I will teach you the basics of writing a smart contract with Vyper to make you comfortable with the language. I will split this article into two parts: the first one for explaining conceptual underpinnings and the second part for code. In a way, this is a short handbook for developers who want to understand and become good at writing Vyper contracts. Let’s have some fun. What Vyper is all about? Vyper is a high-level programming language for building smart contracts on the Ethereum blockchain, and any other blockchain that supports the Ethereum Virtual Machine. I have noticed that the language was created to enhance accessibility into the Ethereum smart contract development scene. This is why I said that: A greater percentage of Web2 developers can build projects with Python, or at least they have a good idea of the language’s syntax and how it works. Vyper has a similar syntax to Python. Therefore, Python developers can easily build Ethereum smart contracts with it. The main engineering philosophies behind the language are: How Vyper is Different From Solidity? The difference between both languages goes beyond the individual names. To be clear, I will point out some operations and possibilities that Solidity supports but Vyper does not: Yul or Assembly We can optimize the storage of a Solidity contract in the EVM slot stack with Yul, which some other developers call Julia. Yul is simply the possible integration of the Assembly language into smart contracts. It is often written inline. I have written in-line assembly to optimize my Solidity contracts in the past. However, Vyper does not support the concept of using inline assembly for smart contracts. The reasoning behind it, according to the documentation, is that in-line assembly can be quite hard to search and trace for variable names. Function Overloading If you are a JavaScript developer, you should be familiar with the concept of function overloading, which is also applicable in Solidity. This is what function overloading means: Using the same name for two or more functions. Vyper does not support it for two basic reasons. First, it makes code easier to read; anyone might mix up the particular function being called at a given instance. Secondly, it can even be used to write manipulative or misleading code. Operator Overloading The concept behind operator overloading is giving an operator, such as a + or -, more than one responsibility in an operation. The Vyper creators believe operator overloading will lead to more complexities, which is against the ethos of simplicity. Binary-fixed Points Vyper is a language that loves things to be exact. However, binary-fixed points do not always give exact results. Instead, you will get some approximations. In contrast, Vyper supports decimal-fixed points as they give greater precision. Modifiers The concept of function modifiers is popularly understood among Solidity developers. We often use modifiers to introduce security checks or business logic to functions in a contract. Vyper does not support modifiers due to auditability and execution reasons. Personally, I do not really admire this engineering decision, and I disagree with the Vyper creators on this. Will Vyper replace Solidity? No, the intention behind Vyper is not to replace Solidity. Instead, it was designed to be an alternative. This is not really a new thing in engineering. For instance, Android development developers can use either Kotlin or Java to build their applications. Back to Vyper and Solidity, I must emphasize that each language has its trade-offs. As a result, engineers can pick the particular language that suits their needs per time. The presence of language choice is fun as it gives engineers the possibility of preference. After all, variety is the spice of life. I strongly believe that Vyper will not replace Solidity, and both languages will thrive in the ecosystem. Why should you learn Vyper? Solidity is the most popular language in the Ethereum ecosystem, and only a tiny fraction uses Vyper in production. So you might wonder why you should learn Vyper. This is why you should consider learning it: The Best Entry Point for Python Developers As I mentioned earlier, Vyper has good syntactical similarities with Python. So, if you are a Web2 dev coming to Web3, Vyper will be the easier language for you to pick. Become more EVM-native I am quite proficient with Solidity as well. But I wanted to be comfortable with more EVM languages, and Vyper was the best option. Knowing Vyper will help you to become a more proficient developer in the ecosystem as you have more languages under your belt. Become a Better Auditor As an auditor, you have to be familiar with many languages in the space to review contracts written in such languages. If you only know Solidity, you might find it quite hard to review the security of

Understanding Solidity is the most popularly adopted language for writing smart contracts among EVM-compatible chains. Anyone who wants to be proficient at writing Solidity smart contracts for several use cases needs to understand an important concept — functions. Functions form the larger part of most smart contracts in Solidity. They help define business logic and several other important terms. Whether you are a complete beginner or an intermediate smart contract developer, I wrote this blog post to teach you how you can confidently define functions yourself. I will start from the fundamentals, then teach you how to do more fantastic operations with functions. That leads us to the question, what is a function? What is a Solidity function? A function in Solidity is a block of code that generally starts with the keyword function and outlines the modality for executing an action. Let me explain with a couple of real-world scenarios: Why do you use your phone? I guess one of the main reasons is to receive calls. Then communication is one of the functions of your phone. You cannot enter your house with your door locked unless you have the key or remote, then the function of those items is to give you access to your house. Do you get the idea? Now, let’s talk code: The purpose of the function above is to send an order. It is a public function, and it can receive ether due to adding the payable keyword. It has a require statement that only a customer can be the msg.sender, which is the address that makes a call. Then it passes some details into an array once a customer creates an order. Don’t worry if you didn’t understand what was playing out here. The main point I want you to know is that this function helps customers of a platform create an order. Can you see how we use functions in smart contracts? What is the syntactical format of a Solidity function? There is a format for writing a Solidity function. This is it: The Solidity compiler will only recognize a function as one if and only if it starts with the function keyword. This is something you must always bear in mind as a developer. Then you must name your Solidity functions following the Camel Casing Convention. It must start with a lower case, then other words can start with capital letters, and there must be no space in between. Examples include theFunctionName instead of TheFunctionName. Moving on, you can define parameters if you need them as local variables within your function. Here is what I mean: Let us use the earlier function as an example: When we were done, we realized burgerMenu and quantity were not recognized locally, hence the reason we defined them as parameters after naming our function. You can include some other details like visibility, mutability, payability, and modifiers after the parameters. You can also have a returning parameter if you write a getter function. A returning parameter is the data type or the detail you want a function to send back once you call it. Consider this example: The function above has these returning parameters: address customer, uint orderNo, uint invoice_date. When you call this function, you can get these details—which are the returning parameters—about a customer. Free Functions and Contract-based Functions As a developer, you can write functions in two major locations, either within or outside a contract. This is an example of functions written inside a contract: We wrote functions increase, decrease, and getTimes within a contract named Mentation. Let us examine the one written outside of a contract: We didn’t write myBalance within a contract. Hold this in your left palm: Functions declared outside a contract are called Free Functions. You might wonder, “How do free and contract-based functions operate? Are there any differences?” There is really no glaring difference between a free function and a contract-based one. But there are a few ones on a closer look. First, free contracts do not enjoy the benefits of leveraging state variables, which are variables created outside of any function in a contract. Secondly, you cannot use the keyword this in them, as in address(this).balance. Understanding Function Visibility in Solidity You might have seen a couple of cases where developers marked some contracts as external, public, private, or internal. Those keywords specify the extent to which other contracts can interact with those functions. The more you write smart contracts, the more you will understand how to classify functions based on their sensitivity or use. There is no brick-and-mortar rule on this; you, the developer, are in charge, and everything is at your discretion. We will examine the four possible forms of visibility in Solidity: Public Public functions have an open design. They are visible to every other contract to call. This is an example: Private Private functions are like shaving sticks; you don’t share them with others. Once a developer declares a function private, it will not be callable whenever other contracts inherit it. The reason is simple: it is private to the actual contract where it was defined. External You cannot call external functions within a contract. External functions are declared to be called by other contracts. Hence, the name external. Internal Internal functions can only be accessed within the contract they are created or an inheriting contract. The difference between internal and private functions is that the latter remains invisible even in inheriting contracts. About Getter Functions and Their Mutability Specification Functions with returning parameters are getter functions. These functions can often alter the current data or condition—better put as the state—of a smart contract. As a developer, you are in charge of deciding which getter function can affect the mutability of the state. We have two major mutability-related specifications. View A function marked with view can read and alter the state of the smart contract. It can update the current data, or even the logic. For instance, a function that sends ether or

There has been a paradigm shift in the history of technology. Web3, a new evolution of the web, is challenging the old pattern of one entity ruling everywhere and everyone. The industry has witnessed exponential growth over the last couple of years. We have seen many Web3 companies like Aave, Consensys, and Chainlink making the numbers. This has also inspired many other people to provide solutions to other problems of humanity with Web3. After weeks—or even months—of building from the engineering standpoint, new or early-stage Web3 companies often have problems with visibility, sales, and conversion. This posits a technical marketing problem, and some Web3 companies underperform due to this reason. This is the truth: Web3 has a lot of innovative solutions, but the target audience can find it overwhelming or unnecessary when they do not understand the technological underpinnings. From another angle, many brilliant technical Web3 companies do not often have enough PR for their target audience to even know they exist. Nonetheless, Web3 currently has over 50 unicorns. That means these top companies have hacked how to break Web3 solutions to their audience in a way that they find interesting. If you plan to build an incredible company in Web3, this is a must-read! What is Web3 technical content marketing? Web3 technical content marketing refers to the overall strategy that Web3 companies can use to communicate with their users, make them understand the importance of their products, and make them recurring customers or users. As against popular belief, Web3 technical content marketing is beyond technical tutorials and guides. It also involves leveraging podcasts, videos, newsletters, documentation, social media,  courses, and reports. In practice, Web3 technical content marketing is similar to pure content marketing as we know it. But there is a big difference: Web3 technical content marketing targets one or more of these people: Those who are; In essence, the peculiarities of the industry and her audience is what shape Web3 technical content marketing. Web3 companies engage—or should engage—in technical content marketing for three major reasons: To; By the way, “companies” in this piece is a blanket term for protocols, projects, and startups. That said, another major subtle difference exists between the general form of content marketing and Web3 technical content marketing. Peep into the next subheading. Technical Marketing in Web3 is Subtle, Not Blatant The general idea of marketing is, “Hey folks, we are the best thing after sliced bread. Come swipe your card for our products.” I have been in Web3 for quite some years now as a developer and a marketer, and I can say that the above method doesn’t work. It doesn’t. The more you shill your project, the more Web3 devs and users doubt everything about it. Marketing here is subtle, not blatant. The ones who know this ensure the subtlety idea informs their overall technical content marketing. How do you do this in practice? Educate and inform your prospective users or customers. The quality of your education will influence them to check out your platform and be a paid user. With this ethos in mind, let’s look further into how some top Web3 companies run their technical content marketing. Examples of Web3 Companies That Do Marketing Right While some Web3 companies have serious issues using technical content marketing to generate visibility and conversion, others do it seamlessly. You can learn from these top companies—some of which are even unicorns—to up your Web3 technical content marketing game. Alchemy – Technical Blog Content Creation Alchemy is an infrastructure provider in Web3. They mainly provide RPC and APIs for the developers. They have facilitated around $100 billion in on-chain transaction volume. The Alchemy marketing team has always been heavy on publishing tutorials and guides for their audience. Going through their blog, one can notice a consistent pattern of publishing developer-focused content. I worked at Alchemy last year and have insights into how they structure their Web3 technical blog content marketing. They have two categories: conceptual content and tutorials. Conceptual content is focused on breaking down terminologies or popular concepts. For instance, they can explain metamorphic contracts to Solidity developers. Conversely, tutorials involve a step-by-step guide for developers to build smart contracts or dApps. The Alchemy content team will use Alchemy endpoints within the tutorials while building. Subtly, the readers following the tutorial will use and get accustomed to using Alchemy endpoints. No wonder they have about 4 million developers using their infrastructure. Thirdweb – YouTube Content Creation Thirdweb is one of the most remarkable dev-tool and no-code companies in Web3. Their recent acquisition of Paper makes them more robust. The company currently boasts of over 100k developers using its products. First of all, Thirdweb ships market-fit products that developers want. Their infrastructure spans across UI components, SDK, Auth, and so on. Apart from technical blog content, another form of marketing channel Thirdweb mans well is YouTube content creation. Most of the content spans around building projects using Thirdweb tools. In addition, they maintain a pattern of 1 video per week, and none of their videos have less than 1k views. This sends a message: 1 quality video per week is enough for your Web3 company. Consistency matters more than intensity. Magic Eden – Social Media Marketing Many companies are fighting for their users with only their blog page while neglecting social media as a less important channel. This is not true, and I can say that as a marketer. Developers and prospective users spend an average of 4 hours on Twitter or similar social media platforms daily. What a perfect platform to meet them! Magic Eden is a wallet in the Solana ecosystem, and their social media management team is doing wonders. They use their Twitter to communicate with their users and share updates. Recall that this is Web3, and their audience are degens, so they share memes occasionally and a little shitpost here and there — on a lighter note. In addition to the above, you can use your social media as a platform