DEV Community: David Ekete

Working with Tokens on Solana using Native Rust

David Ekete — Wed, 15 Oct 2025 23:01:52 +0000

Tokens represent money-like assets, utility (governance or access), rewards and points, game items, tickets, and more. Most tokens on Solana follow the SPL Token standard (or Token-2022 with extensions), which defines how tokens are created, transferred, and burned.

This article will cover how tokens work on Solana and how you can use them in your program. The examples in this article are in Native Rust, but the concepts can be applied to any framework/library (Anchor, Pinocchio, Steel).

How Tokens Work on Solana

Every token on Solana has a mint account. A mint account defines key information about the token, such as the decimals, authority (who can mint and optionally freeze), total supply, etc. However, the mint account only defines the token; it doesn’t store it.

Token decimals describe the asset’s fractional precision. If a mint has d decimals, then 1 token = 10^d base units. Because on-chain programs use integers only to keep consensus deterministic (floating-point can round differently across machines), wallets and dapps convert to/from base units by multiplying or dividing by 10^d. For example, many fiat-like tokens (e.g., USDC) use 6 decimals, so 1 USDC = 1,000,000 base units.

Tokens can exist as fungible or non-fungible (NFTs). Fungible tokens typically use decimals like 6 or 9 for divisibility, while NFTs use 0 decimals and a supply of 1 (or small editions).

The token balances live in Associated Token Accounts (ATAs). ATAs are deterministically derived from an (owner, mint, token_program_id) tuple. Names, symbols, and logos aren’t in the mint or token account. UIs read them from a Metaplex Token Metadata account linked to the mint.

Most resources on the web currently cover creating tokens on the client side with a CLI or SDK because it’s simpler, cheaper (no CPI), and fits one-off user-issued tokens or NFTs.

This guide takes the other path, creating mints on-chain inside your program using PDAs and program-controlled authorities. That approach is crucial when the token is core to protocol safety or pricing, e.g., AMM LP shares, vault/receipt tokens, etc., and as such, the examples in this tutorial are helper functions that can be part of a bigger program, not a standalone one.

Setting Up Your Development Environment

To follow along with this tutorial, you will need to set up a minimal Native Rust program.

Start by running the command below to create a new project:

cargo init token-mints --lib

Then add the following crates by running the command below:

cargo add borsh@1.5.7 && \
cargo add solana-program@2.3.0 && \
cargo add solana-system-interface@1.0.0 --features bincode && \
cargo add spl-associated-token-account@7.0.0 --features no-entrypoint && \
cargo add spl-token@7.0.0 --features no-entrypoint

The crates you added above include:

borsh – Deterministic binary serialization/deserialization for your program/account data. Commonly used to (de)serialize instruction payloads and account state.
solana-program: types like Pubkey, AccountInfo, ProgramResult, entrypoint glue, sysvars, and helpers to build/parse instructions.
solana-system-interface (+ bincode feature) – Stable interface types/IDL for the System Program (create accounts, transfers, etc.).
spl-associated-token-account (no-entrypoint) – Instruction builders and CPI interface for the Associated Token Account (ATA) Program (create/find ATAs).
spl-token (no-entrypoint) – Instruction builders, state types, and CPI interface for the SPL Token Program (mint, transfer, burn, etc.).

Note: Ensure you install the exact versions in the command above, else this may not work as expected.

Creating and Initializing a Token Mint

In this section, you’ll build a small helper, create_and_init_mint, that allocates a mint account as a PDA, then initializes it so your program (via a PDA) controls minting. We’ll set the freeze authority to None to keep the asset non-custodial by default.

The function will accept the following inputs:

Accounts:
- Payer (signer, writable): funds rent and signs the create account instruction.
- Mint (PDA, writable, uninitialized): the account to become your mint.
- System Program*:* required by the system create_account.
program_id: your program ID.
token_decimals: u8
mint_authority: Pubkey (recommend a program PDA)
mint_seeds: &[&[u8]] (the PDA seeds/bump for the mint)

Before you proceed, ensure that you have the following imports at the top of your file:

use solana_program::account_info::{next_account_info, AccountInfo};
use solana_program::entrypoint::ProgramResult;
use solana_program::program::{invoke, invoke_signed};
use solana_program::program_error::ProgramError;
use solana_program::program_pack::Pack;
use solana_program::pubkey::Pubkey;
use solana_program::rent::Rent;
use solana_program::sysvar::Sysvar;

use spl_token::id as spl_token_id;
use spl_token::instruction as token_instruction;
use spl_token::state::{Account as SplAccount, Mint as SplMint};

Note that the imports from spl_token are renamed to avoid conflicts with packages from solana_program.

Creating the Token Mint

To create the mint, first, you allocate the mint account as a program-derived address (PDA) and set its owner to the SPL Token program. This ensures that, after creation, only the token program itself can mutate the mint’s data.

Next, you set the mint authority to a PDA controlled by your program, so any future issuance must come through your on-chain logic (you’ll sign CPIs with invoke_signed).

You then intentionally leave the freeze authority as None, avoiding a built-in backdoor that could freeze user accounts. Finally, you choose the decimals explicitly to set the asset’s precision up front (e.g., 6 for fiat-like tokens, 9 for Solana-style precision, 0 for NFTs).

Like so:

pub fn create_and_init_mint(
    program_id: &Pubkey,
    accounts: &[AccountInfo],
    mint_authority: &Pubkey,
    mint_seeds: &[&[u8]],
    token_decimals: u8,
) -> ProgramResult {
    let acc_iter = &mut accounts.iter();

    //payer (signer), mint (writable), system program
    let payer = next_account_info(acc_iter)?;
    let token_mint = next_account_info(acc_iter)?;
    let system_program = next_account_info(acc_iter)?;

    if !payer.is_signer {
        return Err(ProgramError::MissingRequiredSignature);
    }

    if !token_mint.is_writable {
        return Err(ProgramError::InvalidAccountData);
    }

    // Ensure the passed mint is exactly the PDA we expect for these seeds.
    let expected = Pubkey::create_program_address(mint_seeds, program_id)
        .map_err(|_| ProgramError::InvalidSeeds)?;
    if *token_mint.key != expected {
        return Err(ProgramError::InvalidSeeds);
    }

    let space = SplMint::LEN as u64;
    let lamports = Rent::get()?.minimum_balance(space as usize);

    invoke_signed(
        &solana_system_interface::instruction::create_account(
            &payer.key,
            &token_mint.key,
            lamports,
            space,
            &spl_token_id(),
        ),
        &[payer.clone(), token_mint.clone(), system_program.clone()],
        &[mint_seeds],
    )?;

Now, you have created the token mint; next, you will initialize it.

Initializing Token Mints

To initialize the token mint, you need to invoke the initialize_mint2 instruction from the SPL token program. Pass the SPL program ID, the mint account’s public key, the mint_authority, the freeze authority, and the decimals into the instructions and invoke the instruction with the token mint account.

Like so (this snippet is part of create_and_init_mint):

    let initialize_ix = token_instruction::initialize_mint2(
        &spl_token_id(),
        token_mint.key,
        mint_authority,
        None,
        token_decimals,
    )?;

    invoke(&initialize_ix, &[token_mint.clone()])?;

    Ok(())

  }

There’s an alternative to the initialize_mint2 instruction, which is the initialize_mint function. Both set the same mint fields (decimals, mint authority, freeze authority). The difference is in the required accounts:

initialize_mint2 does not require the Rent sysvar; you pass only the mint account in the CPI account list.
initialize_mint requires the Rent sysvar to be passed and will read it during initialization.

After initialization, the mint’s total supply is 0. The SPL Token program does not enforce a cap; your supply policy is up to you.

You create supply by calling mint_to_checked from your mint authority (usually a PDA) into a token account (often a treasury ATA). However, if you want a fixed supply, mint the full amount and then revoke the mint authority by setting it to None (This process is irreversible).

Here’s an example:

// Mint initial supply to a treasury ATA, then lock the mint.
let amount_base = ui_amount
    .checked_mul(10u64.pow(token_decimals as u32))
    .ok_or(ProgramError::InvalidArgument)?;

let ix = token_instruction::mint_to_checked(
    &spl_token_id(),
    token_mint.key,
    treasury_ata.key,
    mint_authority,      // your PDA signs via invoke_signed
    &[],
    amount_base,
    token_decimals,
)?;
invoke(&ix, &[token_mint.clone(), treasury_ata.clone(), /* + authority account */])?;

// Later, make supply fixed:
let ix_disable = token_instruction::set_authority(
    &spl_token_id(),
    token_mint.key,
    None, // new authority = None → revoke
    spl_token::instruction::AuthorityType::MintTokens,
    mint_authority,
    &[],
)?;
invoke(&ix_disable, &[token_mint.clone(), /* + authority account */])?;

Now, you have created and initialized the token mint. Next, you will create associated token accounts for the mints.

Creating an Associated Token Account (ATA)

For any user to hold the token you just minted and initialized, they have to own an ATA for the mint. An ATA is a deterministic address derived from an (owner, mint, token_program_id) tuple, so wallets and programs can compute it and fetch that single account.

When creating ATAs, decide who pays the rent to initialize the account. You can sponsor creation from your program (great onboarding, but costs scale with users), or require the user to fund it themselves (adds a signature step and a bit of friction, but controls your spend). Anyone may pay the fee; payer and owner do not have to be the same, and the payer gains no control over the account.

To create an ATA, invoke the create_associated_token_account_idempotent instruction from the spl_associated_token_account::instruction crate with the following accounts (in the same order): payer, owner, ATA account, token mint account, token program account, system program account.

Like so:

use spl_associated_token_account as ata;

pub fn create_ata_for(accounts: &[AccountInfo]) -> ProgramResult {
    let acc_iter = &mut accounts.iter();

    let payer = next_account_info(acc_iter)?; //pays the fees for account creation
    let owner = next_account_info(acc_iter)?; //Owner of the ATA
    let ata_acc = next_account_info(acc_iter)?;
    let token_mint = next_account_info(acc_iter)?;
    let token_program = next_account_info(acc_iter)?;
    let system_program = next_account_info(acc_iter)?;

    // Derive the expected ATA address and compare
    let expected_ata = ata::get_associated_token_address_with_program_id(
        owner.key,
        token_mint.key,
        &spl_token_id(),
    );

    // Sanity check: is the passed ATA the one we expect?
    if ata_acc.key != &expected_ata {
        return Err(ProgramError::InvalidArgument);
    }

    // Payer must sign
    if !payer.is_signer {
        return Err(ProgramError::MissingRequiredSignature);
    }

    // Create the ATA (idempotent)
    let ata_instruction = ata::instruction::create_associated_token_account_idempotent(
        payer.key,
        owner.key,
        token_mint.key,
        &spl_token_id(),
    );

    // Invoke the ATA creation instruction
    invoke(
        &ata_instruction,
        &[
            payer.clone(),
            ata_acc.clone(),
            owner.clone(),
            token_mint.clone(),
            system_program.clone(),
            token_program.clone(),
        ],
    )?;

    Ok(())
}

Now you can create ATAs for your mints. Next, you will learn how to burn tokens from the ATAs.

Burning Tokens

Burning destroys tokens from a specific token account and reduces the mint’s total supply by the same amount. The SPL Token program enforces that only the token account owner (or an approved delegate) may burn from that account; you do not need the mint authority.

To burn tokens, invoke the spl token programs burn_checked instruction with the following accounts (in the same order): token mint account, ATA owner account, ATA.

Like so:

pub fn burn_user_tokens(accounts: &[AccountInfo], amount_ui: u64) -> ProgramResult {
    let acc_iter = &mut accounts.iter();

    // 0 mint, 1 owner(signer), 2 token_account(ATA), 3 token_program
    let mint_account = next_account_info(acc_iter)?;
    let owner_account = next_account_info(acc_iter)?; // authority, must sign
    let ata_token_acc = next_account_info(acc_iter)?;

    if !owner_account.is_signer {
        return Err(ProgramError::MissingRequiredSignature);
    }

    // Sanity: token account belongs to owner and matches mint
    let token_account = SplAccount::unpack(&ata_token_acc.try_borrow_data()?)?;
    if token_account.mint != *mint_account.key || token_account.owner != *owner_account.key {
        return Err(ProgramError::InvalidAccountData);
    }

    // Derive base units using mint decimals
    let mint = SplMint::unpack(&mint_account.try_borrow_data()?)?;
    let decimals = mint.decimals;
    let amount_base = amount_ui
        .checked_mul(10u64.pow(decimals as u32))
        .ok_or(ProgramError::InvalidArgument)?;

    // Burn (checked) — accounts: [token_account, mint, authority]
    let burn_ix = token_instruction::burn_checked(
        &spl_token_id(),
        ata_token_acc.key,
        mint_account.key,
        owner_account.key,
        &[],
        amount_base,
        decimals,
    )?;

    invoke(
        &burn_ix,
        &[
            ata_token_acc.clone(),
            mint_account.clone(),
            owner_account.clone(),
        ],
    )?;

    Ok(())
}

Conclusion

With the core pieces in place, mints that define the assets, ATAs that hold balances, and a burn mechanism to control supply. You’ve learnt how to create a mint as a PDA, initialize it with explicit decimals and authorities, derive and fund ATAs, mint and transfer in base units, and burn safely.

With these primitives, you can ship payments, points, or NFTs end-to-end in Native Rust.

You can find the code examples with associated tests in this GitHub repository. This is part one of a two-part series; the next part will cover Token-2022 extensions and hooks. To get notified when it drops, follow me on X :).

An Introduction to Remote Procedural Call (RPC) Nodes in Blockchains

David Ekete — Wed, 08 Oct 2025 23:11:14 +0000

A blockchain is a peer-to-peer network of nodes that maintains a shared ledger. Every node communicates with other nodes in the network using specialized peer-to-peer (P2P) protocols to verify blocks/transactions, store state, and so on.

If you’re building an app on a blockchain, you need a way to communicate with these nodes to read the current state of the blockchain (balances, contract/account data, logs) and write a new state.

However, direct P2P communication is impractical because node-to-node communication is optimized for consensus and gossip, not for app developers. This is because they involve a lot of complex processes that browsers and typical backends aren’t designed to handle.

Remote Procedural Call (RPC) Nodes exist to abstract this complexity and provide a stable HTTP/WebSocket-friendly way to read and write blockchain data.

What is an RPC Node?

RPC is a communication protocol that allows a program on one computer to execute a function on a different computer as if it were a local call.

On blockchains, this commonly appears as JSON-RPC over HTTP or WebSocket, so you can call methods like getBalance(address) which returns the balance of an address without handling low-level networking.

An RPC node is a blockchain node configured to expose this developer-friendly API. Behind the scenes, it syncs the chain, validates data, and “gossips” with peers; to you, it presents clear methods (read state, submit signed transactions, subscribe to updates) accessible via an RPC endpoint (the URL of the API).

For example:

curl -X POST https://mainnet.infura.io/v3/YOUR_PROJECT_ID \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "eth_getBalance",
    "params": [
      "0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe",
      "latest"
    ],
    "id": 1
  }'

The request above fetches the address’s balance (in Wei) using Infura (an RPC provider) via an Ethereum JSON-RPC endpoint. In practice, apps use libraries like viem, ethers.js, or web3.js to talk to RPC endpoints.

How RPC Nodes work

RPC nodes are normal blockchain nodes with an exposed API surface. The node maintains chain state (syncs blocks, executes transactions, stores results). The RPC layer maps your requests to the right internal components (state/execution, transaction pool, or subscription engine).

Note: The mechanisms explained below depict how RPC nodes on the Ethereum mainnet behave. It can vary from blockchain to blockchain.

Blockchain Reads

For a read (e.g., “get balance” or a contract view), the node selects state at the block tag (latest, pending, safe, finalized) you asked for, or a specific block number.

If the method requires execution (for example, an eth_call against a contract), the node runs the call against a sandboxed state at that height, without changing the chain. It then serializes the result and returns it.

Blockchain Writes

For a write (submitting a signed transaction), the node validates format and signature (tx type, chainId, nonce, gas limits/fees, optional access list).

If valid, your request enters the mempool and is “gossiped” to peers. A block producer includes it, and after it has been executed, you can query receipts, logs, and confirmation depth.

Subscriptions

Over WebSocket, Ethereum supports eth_subscribe channels such as:

newHeads (new block headers)
logs (filtered by address/topics)
newPendingTransactions

The node manages buffers/backpressure; clients should handle reconnects and resume from the last seen block number to stay consistent.

Using RPC Nodes

To use an RPC node, you can either run your own private RPC node, use a public RPC node, or use an RPC node provider.

Running your own RPC Node

If you need overall control over your own RPC node, you can install and run blockchain clients like Geth, Nethermind, or Reth on your own hardware or virtual server and enable RPC on them.

This method requires a lot of maintenance on your end and is best for teams with special needs.

Using a Public RPC Node

Most blockchains provide free public RPC endpoints that allow anybody to use RPC nodes. Due to their easy accessibility, they are usually overloaded and rate-limited, making them ideal for small Dapps and testing. Additionally, they may not offer WebSocket support.

Examples of Popular Public RPC Nodes include the following:

Chain	Provider	RPC Endpoint
Ethereum	PublicNode	https://ethereum-rpc.publicnode.com
Solana (Mainnet-beta)	Anza (Solana Labs)	https://api.mainnet-beta.solana.com
BNB Smart Chain	BNB Chain (official)	https://bsc-dataseed.bnbchain.org
Sui (Mainnet)	Mysten Labs	https://fullnode.mainnet.sui.io:443

Using an RPC Node Provider

This is the most popular option for most developers because using RPC node providers is cheaper than running your own RPC node, and you can scale your configuration as your usage increases.

To use an RPC provider, you simply need to sign up on their platform, choose a plan, and start querying their endpoint. Some popular RPC Node providers include Alchemy & QuickNode.

Another interesting RPC provider is the Developer Dao Cloud, which is built on the POKT Network and gives you access to 60+ chains with unbeatable uptime. You can join the Developer Dao Cloud waitlist here.

Conclusion

You can think of RPC nodes as the API layer of the blockchain. They abstract all the complexities associated with P2P communication between a node and a Dapp and expose a friendlier UI.

You can access an RPC node via paid providers (often with free tiers), community/public endpoints, or by running your own dedicated node. Whichever route you choose, decide based on your needs for reliability, latency, and cost, and data/privacy requirements.

How to Build Smart Contracts Fast

David Ekete — Wed, 16 Jul 2025 23:25:01 +0000

Writing smart contracts from scratch is a hurdle; you have to manually initialize your contract with the legal header and pragma line, and copy the OpenZeppelin import statements required by your smart contract.

If your contract requires ownership, pausing, or ERC‑20 functionality, you have to manually paste the code. This workflow is very time-consuming and is prone to mistakes that could otherwise be avoided if all the boilerplate your project needed were available out of the box.

Remix templates populate your workspace with a production-ready folder tree and all the boilerplate files you need to get started on your project. For example, the ER20 template contains a .sol file with all the required boilerplate (including OpenZeppelin imports) and deploy scripts for ethers.js and web3.js.

How to use Remix IDE templates

Navigate to the Remix IDE website, click the hamburger icon on the top left, and select the “Create Using Template” option.

In the workspaces page, select a template that suits your project’s needs from the list of available templates.

Available Remix IDE templates

Here’s a list of the currently available templates on the Remix IDE, divided into categories.

Generic templates

The templates are minimal and contain general starter boilerplates. Under this category, you can find blank templates, default templates, and templates for standards like EIP 7702 and ERC-4337 (Account Abstraction).

OpenZeppelin templates

The OpenZeppelin templates provide boilerplates containing OpenZeppelin audited implementations of some ERC contracts, like ERC-721 (for NFTS), ERC-1155 (Multi-token standard), and more.

CookBook.dev templates

Cookbook.dev templates provide boilerplates for audited and unaudited contracts from various projects in the ecosystem, like Aave, Tether, etc., curated by Cookbook.dev.

Note: To use these templates, you have to install the Cookbook.dev plugin in your Remix IDE.

OxProject

A template for a fungible token contract by 0xProject.

Gnosis Safe template

A template for deploying or customizing the Gnosis Safe MultiSig Wallet.

Circom ZKP templates

Remix ships three templates for zero‑knowledge development with the Circom compiler plugin: Semaphore, Hash Checker, and Rate‑Limiting Nullifier (RLN).

Each template is a full project with circuits, TypeScript scripts, and a ready‑made Solidity verifier.

Noir ZKP template

The Noir ZKP template contains a simple multiplier circuit.

Generic ZKP templates

This template contains scripts for compiling circuits and generating Zero-Knowledge Proofs remotely using the Sindri API.

Uniswap V4 templates

Uniswap V4 templates clones the protocol’s official v4 repos (core snapshot, periphery helpers, and a ready‑made Hook template), complete with Foundry tests and deploy scripts.

Solidity CREATE2 templates

Remix provides two Solidity CREATE2 templates for the Solidity CREATE2 opcode. A factory and a script for deploying a contract using the CREATE2 opcode.

Contract verification templates

This template provides a script for verifying a Contract in Etherscan.

GitHub Actions

For GitHub actions, Remix provides templates for a Mocha Chai Test Workflow in a GitHub CI, a Solidity Test Workflow, and a Slither Workflow.

Conclusion

Remix IDE templates remove the tedious setup work so you can concentrate on business logic and security, not boilerplate. By starting from a curated workspace that already includes proven patterns, trusted dependencies, and ready‑made scripts, you sidestep common pitfalls such as mismatched compiler versions, missing imports, and fragile deployment flows.

How to Become a Blockchain Validator

David Ekete — Tue, 10 Jun 2025 13:16:54 +0000

A blockchain validator is a participant in a blockchain network who checks that new transactions and blocks follow the network’s rules before those blocks are permanently added to the ledger.

Blockchains offer incentives in the form of their native tokens to validators, which are usually proportional to their stake in the network. The actual value of these rewards fluctuates based on market conditions, including price, total value locked (TVL), the number of active validators, penalties, commissions, and fee/MEV capture.

Based on these factors that affect validator rewards, here’s a list of blockchains that provide viable profit opportunities for validators and how you can become one on the chain.

Ethereum

To become a validator on the Ethereum network, you need to run an Ethereum node and deposit 32 ETH (~84,000 USD) to activate your validator account. The minimum hardware requirements for running a node include 4-8 GB RAM, 2TB SSD, and a 64-bit x86 processor.

You can build a hardware rig or use a dedicated cloud server. The estimated cost of purchasing the hardware is around 650-800 USD (source: Amazon.com). Cloud servers would cost around ~ 148 USD/month.

As a validator, you have to check new blocks and “attest” to them if they are valid, and propose new blocks when you are randomly selected from the validator pool to propose one.

If you fail to do either of these tasks, you miss out on the ETH rewards associated with that block. Validators can also be tasked with signature aggregation and participating in sync committees.

Validators on ETH earn about 3.148% APY on their stake on ETH issuance rewards alone; this number can rise to about 5.69% if you add block tips and maximal extractable value (MEV), assuming your node has 100% uptime. If your node does anything malicious, such as proposing multiple blocks for the same slot, your staked ETH can be “slashed” by up to 1 ETH, and you will be removed from the network. You can read more on how rewards and penalties are calculated in the official Ethereum documentation.

The approximate cost (excluding electricity and internet costs) for setting up an Ethereum validator is 32 ETH + $800, which amounts to approximately ~ 84,800 USD. Assuming 100% uptime, fair MEV rewards, and tips, the average Ethereum validator earns ~ 1.8203 ETH (~4800 USD) yearly from a single node.

Here’s the official guide on how to become an Ethereum validator, and here’s a handy tool you can use to estimate validator rewards based on real-time market data: Ethereum staking calculator.

Solana

The minimum hardware requirements for running a Solana validator are a 12-core/24-thread CPU at 2.8 GHz or faster with SHA and AVX2 instruction support, 256 GB of ECC RAM, separate PCIe Gen3×4 NVMe SSDs of roughly 500 GB for accounts, 1 TB for the ledger and 250 GB for snapshots with an optional 500 GB OS drive, plus a symmetric 1 Gbps internet connection. You can find the full hardware recommendations in the Agave documentation.

A physical setup would cost anywhere from ~ 2600 to 5000 USD, excluding internet and electricity costs. Alternatively, cloud solutions cost around 4,500 USD per year; however, they are a better option, as managing the bandwidth and internet required for voting can be difficult.

The next substantial cost associated with running a Solana validator is the voting fees. Validators are required to send a vote transaction for every slot they agree with, and these transactions can incur up to 1.1 SOL (~ 185 USD) in fees per day.

There is no strict minimum amount of SOL you need to run a validator, so “theoretically,” you can deposit 1 SOL. However, according to Cogent Crypto’s validator profit calculator, the minimum amount of SOL to be profitable is ~5700 SOL (~ 934,000 USD). Since Solana operates a delegated-POS system, you do not need to own all your stake; you can incentivize SOL holders to delegate their tokens to you and charge them a commission ranging between 0 to 100% deducted from their inflation rewards.

The image below shows the top 14 Solana validators, their commission, active SOL staked, and other parameters.

For earnings, Solana validators earn from inflation/issuance rewards (on their stake), priority fees (tips), and MEV. Most of the rewards come from issuance. However, tips also make up a good portion. According to Blockworks research, $240 million in priority fees/tips flowed to validators in Jan 2025 alone.

The current barrier of entry for a Solana validator is high compared to Ethereum. However, with the Alpenglow upgrade, you can run a Solana validator on an 8- to 16-core CPU (no PoH grind), 128 GB of ECC RAM, a single 1 TB NVMe drive for both ledger and accounts, and the same 1 Gbps uplink, eliminating the need for a separate snapshot drive or vote-spam IOPS.

Alpenglow also removes voting fees, bringing the minimum amount of SOL to be profitable down from ~ 5700 SOL to around ~ 530 SOL. Note that these figures are speculative as the inflation model might be tweaked to balance the removal of the voting fee, thus increasing the minimum amount required to be profitable.

Here’s the official guide on how to setup a Solana validator. To reduce the barrier of entry for validators, the Solana Foundation has some initiatives to reduce cost. Here’s a helpful blog post by Helius, whose validator account earns approximately $ 18 million per year, on Solana validator economics.

Sui

To become a SUI validator, you have to run a SUI node and have a minimum of 30 million SUI (~ 104.7 million USD) in your staking pool (deposited or delegated). The Sui Foundation helps members of their delegation program satisfy the 30 million threshold. However, the application details are very vague, and the only reference to the program is this blog post from 2022.

Once you become a validator, your staking pool must maintain a balance of at least 20 million SUI (~ 69.8 million USD) or risk removal after a 7-epoch (1 epoch = 24 hours) grace period. If your pool falls below 15 million SUI, you will be removed as a validator on the next epoch.

The minimum hardware requirements for running a Sui node are a server with 24 physical CPU cores (48 vCPUs), 128 GB of RAM, a 4 TB NVMe SSD, and a 1 Gbps network connection. The estimated cost for building a hardware rig that meets these requirements, according to Amazon.com is around 1200 - 1400 USD (refurbished) and 8000 - 9000 USD (new).

Running a dedicated server that meets the hardware requirements would cost around 500 USD per month, but this can vary greatly depending on the service you choose.

Sui validators earn an average of 2.34% APY on their stake, which comes from yield on their stake, commission on delegated stake, and an automatic storage-cost rebate. Thus, with the allowable balance of 20 million SUI, validators make ~ 1.63 million USD per year.

There’s currently a proposal to reduce the barrier of entry for new validators, SIP-39. This proposal, when fully rolled out, will replace the 30 million SUI requirement with “3 voting power”. A “voting power” is calculated by dividing a validator’s stake by the total stake and multiplying it by the fixed value of 10,000, which is the total available voting power for each epoch.

Thus, one voting power equals 0.01 % of the total stake. Currently, that value (total stake, May 2025 = 7.49 billion SUI) is 749,000 SUI—making the entry requirement 2.247 million SUI ( ~7.84 million USD).

Here’s the official guide for becoming a validator on Sui.

BNB Chain (BSC)

To become a validator on the BNB chain, formerly known as the Binance Smart Chain, you need to run a BSC node and stake a minimum of 2000 + 1 BNB (~ 1.3 million USD). 2,000 BNB is your self-stake, and 1 BNB is burned to a dead-address.

The hardware requirements to run a BNB chain node are 16 CPU cores, 64 GB RAM, NVMe SSD 2-3 TB, ≥ 1 GB symmetrical bandwidth, which will cost about ~ 875 to 1500 USD (Amazon.com) for hardware. If you use a dedicated cloud server, it would cost anywhere from 104 to 455 USD/month.

Every validator earns a daily base reward of up to approximately 1.92% APY on their deposited stake. If you sit in the top-21 “Cabinet,” (validators with the largest amount of delegated BNB at the end of each UTC-day election cycle) you also keep almost all gas fees and any MEV in the blocks you build, so your real yield rises by a few additional tenths of a percent when traffic is normal and much more during busy periods; on top of that you skim a commission (typically around 10%) from your delegators’ rewards.

Income falls whenever you miss duties, and serious faults are expensive: double-signing or malicious votes forfeit 200 BNB of your own bond and sideline you for thirty days, while extended downtime costs 10 BNB and a two-day “jail”.

Thus, the income of a BNB validator, who holds the minimum stake, is ~ 25,000 USD per year. Here’s the official guide on becoming a validator on BNB Chain.

Cosmos

The hardware requirements for running a validator node on Cosmos are vague, as the docs only mention the RAM and storage requirements: 32 GB of RAM and 500 GB to 2 TB of storage.

Most consumer-grade PCs that fit those specs can be picked up for roughly 350 – 800 USD on Amazon, or rented for about ****$92 – $148 per month on dedicated cloud server plans. There is no minimum stake required to become a validator; however, certain caveats apply to this rule.

To become a validator on Cosmos, you have to send a “declare-candidacy” transaction with some required parameters, which include but is not limited to your PubKey, minimum self-bond amount (minimum amount of ATOM you need to have at all times), initial self-bond amount, etc.

Once you declare candidacy, Atom holders can delegate atoms to your pool, effectively adding stake to this pool. The total stake of an address is the combination of Atoms bonded by delegators and Atoms self-bonded by the entity that designated itself.

Out of all the candidates that signaled themselves, the 100 with the most stake are the ones who are designated as validators. If a validator’s total stake falls below the top 100, then that validator loses its validator privileges.

However, the maximum number of validators increases every year and is set to triple within 10 years since launch. Following the schedule, the current maximum number should be 208 (Year 6).

Thus, making the minimum stake any number of ATOM that puts you in the top 200 (Year 6). That value currently sits at 2,740 ATOM (~ 11,900 USD), which is the stake of the 198th validator.

Cosmos stakers and, by extension, validators earn a “base” compounded ~17 – 19 % APY on their self-stake. In addition to that, they earn from commissions and play a significant role in governance, as all their delegators who don’t vote automatically inherit their vote.

Here’s the official guide to becoming a validator on Cosmos.

Avalanche

To become a validator on Avalanche, you have to run a node and stake a minimum of 2,000 AVAX (~ 41,460 USD). The maximum weight of a validator (their own stake plus the stake delegated to them) is 3 million AVAX.

One interesting quirk of the Avalanche validators is that the maximum amount of tokens your validator pool can hold is 5 times your staked amount. For example, if you stake 2,000 AVAX to become a validator, only 8,000 AVAX can be delegated to your node, making the total 10,000.

The hardware requirements for running a node are vague; publicly accessible materials only list the storage and RAM requirements: 200 GB of storage and 8 GB of RAM.

Most consumer-grade PCs easily satisfy 8 GB of RAM and ~200 GB of SSD storage, and cost anywhere from $ ****120 to $ 260, or roughly $ 8 to $ 27 per month if you rent a VPS or entry-level bare-metal instance.

The current reward percentage for staking is 8.5 % APY. Additionally, validators may also receive a percentage of the transaction fees generated on the network or additional tokens. Thus, on a 2,000 AVAX stake, you’d receive ~ 3,500 USD per year. Here’s the official guide on becoming a validator on the Avalanche chain.

TL;DR

Chain	Number of active validators(May 2025)	Average number of DAW (Daily Active Wallets	Estimated cost of entry (USD)	Minimum stake to become profitable	Average APY on Stake (%)
Ethereum	1,054,030	490k - 529k	85,776	32 ETH	3
Solana	1,231	4.4 - 5 million	938,500	5740 SOL	5-6
Sui	114	286k - 312k	104,706,000	30 million SUI	2.37
BNB Chain	45	1.5 - 1.8 million	1,305,460	2,001 BNB	1.92
Cosmos	200	11k - 16k	13,776	3,000 ATOM	unknown
Avalanche	1,348	41k - 100k	41,784	2,000 AVAX	8.5

Conclusion

Today’s blockchain ecosystem makes validator roles and privileges inaccessible to retail—this is both a feature and a flaw. The high barrier of entry makes attacks on the blockchain expensive and unfeasible.

However, it has made the chain more centralized as only a handful of institutions can afford the hardware and initial capital required. The top validator wallets are also controlled by the foundation responsible for the blockchain, which raises a lot of questions.

Lowering the barrier of entry for validators and offering better incentives would achieve a higher degree of decentralization while maintaining chain security. As crypto gathers more adoption, we cant wait to see what tomorrow holds.

Introducing Alpenglow: Solana’s new consensus protocol

David Ekete — Sun, 01 Jun 2025 23:33:19 +0000

Anza Labs (formerly known as Solana Labs) has proposed the most significant update to the Solana blockchain since it went live: Alpenglow.

Alpenglow replaces TowerBFT and Proof-of-History as the voting and block finalization mechanism with Votor and refines Turbine as the data propagation layer with Rotor. This piece will discuss how these changes affect the Solana ecosystem and what you can expect after Alpenglow’s implementation.

Votor

Until Votor, Solana relied on T**ower Byzantine Fault Tolerance (TBFT) as its consensus algorithm, which is a custom implementation of Practical Byzantine Fault Tolerance (PBFT). You can visualize TBFT as a two-step handshake.

On the first handshake, known as the pre-vote, every validator signs a short “yes, I saw this block” message. The block can move on only after at least two-thirds (2/3) of all stake have sent this first vote. On the second handshake, known as the commit, once the same super-majority notices that the first round succeeded, they sign a second, “now it’s final” vote.

This 2-hop pattern (plus occasional view changes when the leader stalls) is mathematically safe as long as less than one-third of the total stake is actively malicious. However, this introduces a lot of latency, as block finality on Solana averages about 12.8 seconds, which is impractical for real-time applications like games.

Votor keeps the familiar “everyone votes with stake-weighted signatures” idea, but lets the chain stop early if ≈ 80 % of the stake manages to send its first vote before a deadline T₁ ≈ δ (T₁ = first waiting window, δ = network yardstick). If 80% is reached, the block is finalized immediately—no second hop.

If 80 % isn’t reached in time, the protocol relaxes to 60 % in two hops, which is only slightly stricter than the old ⅔-rule but still maintains safety. With this mechanism, Votor achieves a median latency of 150 ms, comparable to Web2 infrastructure.

In essence, Votor shaves hundreds of milliseconds off the common case by trusting that true, coordinated attacks above 20 % stake are rare. The bargain is a slightly narrower safety cushion, tighter uptime requirements for validators, and a protocol that is trickier to reason about and to monitor in production.

Rotor

Originally, the current slot leader was responsible for sending every byte of the block to the rest of the validators, which was a huge bottleneck. To ease the burden, the protocol adopted Turbine, which broke the blocks into shreds, erasure-coded them, and pushed them down a fixed fan-out tree.

This helped; however, it left a few pain points. One, every shred still originates on the leader’s network, tens of thousands of transactions passing through a single pipe. Also, the relay work was uneven. Which node relays to whom is hard-coded by slot number, so the same unlucky validator may forward huge chunks of traffic while others forward almost none, and yet everyone earns identical rewards for “voting”.

This approach was also blind to stake. A validator with a 0.1% stake could end up relaying as much data as one holding 5%, even though the latter has both the resources and the economic incentive to shoulder more load. As throughput crept upward, the leader bottleneck and unfair bandwidth distribution threatened real-time user experience.

Rotor re-imagines block distribution as a stake-weighted peer-to-peer CDN. The leader seeds just enough shreds to a randomly sampled set of relay nodes, each chosen with probability proportional to its stake. Those relays then spray their own stake-proportional bandwidth outward; any γ out of Γ shreds suffice to reconstruct the block, so a fair chunk of relays can drop offline without harm.

The result is that the leader’s outbound traffic falls from “block size × fan-out” to roughly “block size × (log N / Γ)”.

Rotor keeps the idea of “leader seeds a few peers first”, but it

eliminates the fixed tree, the 32-fold duplication, and the unpaid relay work. The price is a heavier dependency on honest capacity provisioning, steeper hardware requirements for validators, and a significantly more intricate networking layer that must stay honest and measurable at scale.

Conclusion

Alpenglow reframes Solana’s guiding idea, “the world computer should feel like the local computer,” by eliminating the leader pipe as a bottleneck and letting a stake-weighted swarm move blocks and votes at near-network speed. If the upcoming test networks confirm the projected latency and fairness gains, Alpenglow could set a new benchmark for high-performance, open-participation blockchains.

Revolutionizing the Stablecoin Market with Solayer USD

David Ekete — Wed, 13 Nov 2024 18:32:45 +0000

Traditional fiat-collateralized stablecoins maintain their value by holding reserves in fiat currency or highly liquid, low-risk assets equal to the value of stablecoins in circulation. However, the yield and interest generated from these reserves benefit only the stablecoin issuer, leaving users without a share in the financial returns.

This mirrors a problem in traditional finance, where individuals don’t fully benefit from the use of their capital, making the system less equitable and reinforcing financial inequality—issues cryptocurrency was designed to solve.

Solayer USD (sUSD) seeks to bridge this gap by introducing the first yield-bearing stablecoin on Solana. It is pegged to the U.S. dollar and backed by real-world assets (RWAs) like U.S. Treasury Bills, bonds, and gold. Unlike traditional stablecoins, sUSD redistributes the yield generated from these assets directly to users.

What is Solayer USD (sUSD)?

sUSD is a yield-bearing stablecoin on Solana that maintains a 1:1 peg with the U.S. dollar through backing from U.S. Treasury Bills, which is considered one of the safest short-term government debt instruments.

In addition to maintaining its peg, T-bill backing also allows it to generate a 4-5% yield, which is automatically redistributed to users through a token multiplier mechanism.

The sUSD yield-bearing mechanism

The Solana blockchain’s account model makes minting and distributing tokens as yield to user accounts difficult due to rent fees, complex transaction handling, and the need for frequent state updates in a system with many accounts.

To handle this, sUSD employs Solana’s token22 program and a token multiplier mechanism that works by changing the multiplier of your sUSD holdings with the interest accumulation rather than changing the amount.

The value of your holdings is then calculated by applying a multiplier to the number of sUSD tokens you’re holding. For example, if you have 1000 (one thousand) $sSUD tokens, assuming a 5% annual yield, the multiplier on your tokens would be 1.05x at the end of the year.

The multiplier is calculated by considering the annual yield and the compounding period, i.e., Multiplier=1+n/r, where r is the annual yield (in this case, 5% or 0.05), and n is the number of compounding periods per year.

Thus, the actual value of your 1000 $sUSD tokens would be calculated by Number of Tokens * Multiplier, i.e. USD 1000 * 1.05, which equals USD 1050.

This allows the value of sUSD in a wallet to increase natively without losing its peg or increasing the number of $sUSD tokens in your wallet.

In addition to getting yield from holding $sUSD tokens, you can delegate them exogenous Actively Validated Services (exoAVSs) to gain additional yields and further secure the decentralized network. However, this feature is still under development at the time of writing.

How does sUSD work?

sUSD is built upon Solayer’s Request for Quote (RFQ) protocol, which is essentially a marketplace matching engine. The RFQ protocol matches USDC quotes with a liquidity provider that has the most optimized interest rates for the quote.

This approach distributes risk and maximizes yield opportunities by leveraging the strengths of different liquidity providers. It also plays a crucial role in the sUSD subscription (buying sUSD) and the redemption process (selling sUSD).

The sUSD subscription process

The sUSD subscription process involves locking USDC to mint sUSD. To achieve this, you’ll need a Solana wallet like Phantom, some SOL tokens for gas, and USDC.

Navigate to the Solayer app on https://app.solayer.org/ and click on sUSD Restaking, as shown in the image below.

This takes you to the sUSD restaking page, where you can mint sUSD tokens with USDC on a 1:1 basis. On the restaking page, connect your Solana wallet containing your USDC and some SOL for gas, enter the amount of USDC you want to lock for sUSD and click the Deposit button that appears.

Clicking the Deposit button locks your USDC and automatically creates a quote that specifies the amount of USDC, the expiry time, and the commission rate for the trade. The RFQ system then broadcasts the quote to all qualified liquidity providers who compete to fulfil the order and receive the offered commission.

The selected liquidity provider fulfils the buy order by transferring the USDC out and sending back a wrapped T-bill (a tokenized representation of a T-bill) as proof. The RFQ protocol then forwards the wrapped T-bill to the sUSD minting program and locks it there.

Finally, the USD minting program mints sUSD based on the value of the wrapped T-Bill, maintaining a 1:1 price peg with USDC, thus depositing your sUSD tokens in your wallet. This process takes a while to finalize and is usually completed in 1 working day.

You should see a processing transaction indicator on the restaking page during this wait time, as shown in the image below.

You will receive an equivalent number of sUSD tokens when this process is complete.

The sUSD redemption process

The sUSD redemption process involves converting your sUSD back to USDC. This conversion does not occur on a 1:1 basis with your sUSD, as a multiplier based on your accumulated yield is applied to your token value, giving you more USDC than you initially locked.

To start your sUSD redemption process, you have to unstake your sUSD tokens (if you staked or used them for collateral) and send them back to the Solayer sUSD program. Then, navigate to the sUSD restaking dashboard, enter the amount you want to withdraw and click the Withdraw button, as shown in the image below.

Clicking the withdraw button will trigger a pop-up modal that provides information about your withdrawal process, such as the fact that it can take up to 2 days to process. Click the Withdraw button on the modal to start your withdrawal process, as shown in the image below.

When you click the withdrawal button, the program calculates the corresponding amount of wrapped T-Bills that need to be redeemed based on your request and forwards it to the RFQ protocol.

The RFQ protocol matches the redemption request to a qualified liquidity provider who receives the wrapped T-Bill and fulfils the withdrawal order by transferring out the wrapped T-Bill and sending the equivalent amount of USDC back to the protocol.

After the liquidity provider fulfils the withdrawal order, the RFQ protocol returns the corresponding amount of USDC to the user, completing the withdrawal process.

As mentioned in the pop-up modal, this process will take about 2 days. During this wait time, you should see a processing transaction indicator on the restaking page, as shown in the image below.

Use cases for sUSD

Solayer’s stablecoin, sUSD, has multiple use cases aside from being a stable store of value. Some of them are covered below.

sUSD as a savings account on Solana

You can use sUSD as a decentralized savings account that offers a higher yield, 4-5%, compared to traditional banks. It also provides greater transparency, as the entire process is on-chain. You can see how yield is generated, which assets back it, and where funds are held.

sUSD is also decentralized and permissionless, meaning anyone can participate regardless of geographical restrictions or access to banking services. It also gives you full control over your assets, unlike a traditional savings account, which relies on financial institutions.

Securing decentralized systems

sUSD not only functions as a stable, yield-generating asset, but it also provides opportunities to contribute to the security of decentralized systems such as Oracles and Bridges by delegating your tokens to them. For example, delegating your sUSD tokens to an exoAVS, which is coming soon to Solayer.

The exoAVS system utilizes the delegated sUSD as part of its security mechanism, ensuring that operations like data validation, cross-chain communication, or decentralized governance are carried out securely.

In exchange, the system compensates you with additional yield, providing an extra incentive beyond the base 4-5% interest from T-bills.

sUSD as Collateral

sUSD can serve as collateral within decentralized finance (DeFi) ecosystems due to its stable value and yield-bearing characteristics. You can lock your sUSD on DeFi lending platforms to access liquidity without selling your sUSD holdings.

A unique feature of sUSD as collateral is that it is yield-bearing. This makes it a more efficient form of collateral than standard stablecoins, as you can maintain a healthy collateral ratio more easily because the interest helps increase the effective value of your collateral over time.

The yield-bearing nature also of sUSD ensures that you continue to benefit from the underlying asset growth even when locked as collateral, providing a buffer against minor market fluctuations.

sUSD for Payments

sUSD is an ideal payment solution due to its stability, low fees, and high speed on the Solana network. Additionally, due to its permissionless and decentralized nature, it is an ideal solution for cross-border payments as it eliminates the need for intermediaries like banks, which often delay and add fees to international payments.

Payments made with sUSD are recorded on-chain, providing full transparency. This can be valuable for businesses that need to maintain an accurate record of transactions or for users who want to track their payment history.

Earn yield on your stablecoins with sUSD

Solayer USD (sUSD) marks a significant innovation in the stablecoin landscape by offering a yield-bearing, real-world asset (RWA)-backed model on Solana. Its permissionless design removes barriers to entry, making sUSD accessible to anyone globally, regardless of their location or financial background.

sUSD shifts the stablecoin model toward prioritizing user yield over centralized profits, contributing to a more decentralized financial ecosystem.

Want to earn a stable RWA-backed yield on your stablecoin reserves and contribute to a more decentralized financial ecosystem? Mint sUSD tokens on https://app.solayer.org/ today!

Understanding Data Transfer Objects (DTO) and Data Validation in TypeScript (NestJS)

David Ekete — Sun, 15 May 2022 23:38:02 +0000

Data Transfer Objects (DTOs) are the basis of data validation in NestJS applications. DTOs enable various layers of flexible data validation in NestJS.

In this publication, you will take a deep dive into data transfer objects, discussing validation mechanisms, authentication models, and everything else you need to know about data transfer objects.

Prerequisites

This tutorial is not beginner-themed. If you’re just getting started with NestJS, read this article.

You’ll need to meet these requirements to fully understand this article.

Prior experience creating NestJS apps with MongoDB.
Competence with PostMan (recommended) or any other API testing tool.
Basic knowledge of bcrypt or the NodeJS crypto module.

Once you meet these requirements, we can get started.

What is a Data Transfer Object?

A data transfer object, commonly called a DTO, is an object used to validate data and define data structure sent into your Nest applications. DTOs are similar to interfaces, but differ from interfaces in the following ways:

Interfaces are used for type-checking and structure definition.
A DTO is used for type-checking, structure definition, and data validation.
Interfaces disappear during compilation, as it’s native to TypeScript and doesn't exist in JavaScript.
DTOs are defined using classes that are supported in native JavaScript. Hence, it remains after compilation.

DTOs alone can only do type-checking and structure definition. To run data validations using DTOs, you’ll need to use the NestJS ValidationPipe.

Validation Mechanisms

Pipes are used to validate data in NestJS. Data passing through a pipe is evaluated, if it passes the validation test, it is returned unmodified; otherwise, an error is thrown.

NestJS has 8 inbuilt pipes, but you’ll be focusing on the ValidationPipe which makes use of the class-validator package, because it abstracts a lot of verbose code and makes it easy to validate data using decorators.

DTOs in a Simple User Authentication Model

A user authentication model is a perfect example to demystify DTOs. This is because it requires multiple levels of data validation. Let’s make one and explore DTOs and the ValidationPipe to validate all forms of data coming into our application.

Setting up Development Environment

To set up your development environment:

Generate a new project using the Nest CLI,
Generate your Module, Service, and Controller using the CLI,
Install Mongoose and connect your application to the database,
Create your schema folder and define the Schema.

A typical user-auth schema should look like:

import { Prop, Schema, SchemaFactory } from '@nestjs/mongoose';
import { Document } from 'mongoose';

export type UserDocument = User & Document;

@Schema()
export class User {
  @Prop({ required: true })
  fullName: string;

  @Prop({ required: true })
  email: string;

  @Prop({ required: true })
  password: string;
}
export const UserSchema = SchemaFactory.createForClass(User);

Having the fullName, email, and password as required properties.

Create a folder inside your module and call it dto. This is where your dto classes will be stored and exported.
Create a file inside your dto folder and name it user.dto.ts.

Structure of a DTO

A DTO is a class, so it follows the same syntax a class does.

export class newUserDto {
  fullName: string;
  email: string;
  password: string;
}

Above is the structure of a basic DTO.

This structure is only useful for type-checking, it has no data validation properties.

Implementing Data Validation

To add validation functions; follow the steps below;

Inside your main.ts,
Import {ValidationPipe} from '@nestjs/common',
Inside the bootstrap function and directly below the app constant, call the useGlobalPipes method on app and pass in new ValidationPipe() as an argument.

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { ValidationPipe } from '@nestjs/common';
import * as dotenv from 'dotenv';
dotenv.config();

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.useGlobalPipes(new ValidationPipe());
  await app.listen(process.env.PORT);
}
bootstrap();

This will enable auto-validation and ensure that all endpoints are protected from receiving incorrect data. The Validation pipe takes in an options object as an argument, you can find out more about it in the official documentation.

Install the class-validator and the class-transformer package by running:

npm i --save class-validator class-transformer

The class-transformer converts JSON objects into an instance of your DTO class and vice-versa.

The class-validator package has a lot of validation queries, which you can find in their documentation, but you’ll be focusing on a few of them related to user data validation. In your user.dto.ts file, import the following queries from class-validator:

IsNotEmpty: This validator checks if a given value is empty. It takes in an object of options as an argument.
IsString: This validator checks if a given value is a real string. It takes in an object of options as an argument.
IsEmail: This validator checks if a given value is of type email. It takes in an object of options as an argument.
Length: This Validator takes in 3 arguments. The first is the minLength, then the maxLength, and finally an object of options.

The above will be used as decorators to validate their respective fields. Implement this in your DTO,

import { IsNotEmpty, IsEmail, Length, IsString } from 'class-validator';

export class newUserDto {
  @IsNotEmpty({ message: 'Please Enter Full Name' })
  @IsString({ message: 'Please Enter Valid Name' })
  fullName: string;

  @IsEmail({ message: 'Please Enter a Valid Email' })
  email: string;

  @Length(6, 50, {
    message: 'Password length Must be between 6 and 50 charcters',
  })
  password: string;
}

The password field has only a Length validation but in production, you might need to add a few more fields to ensure the password is more secure.

These new validation fields might include checking if the password contains uppercase, lowercase, and numbers.

This can be done in several ways, including:

Padding with more validation decorators, like you did in the fullName field.
Using the @Matches validator and passing a regular expression that checks for your requirements as an argument.

But the cleanest way to do this would be by creating a custom validator to suit your specifications. You can learn more about custom decorators here.

Post & Put Requests

Test the data validation by making a few POST and PUT requests to your application. But before that, it’s bad practice to store your passwords in plain text. So hash them first before storing them in the database;

Hashing Passwords

You can hash the passwords using a package called bcrypt or the NodeJS crypto module. This publication covers bcrypt. To install bcrypt run

npm i bcrypt
npm i -D @types/bcrypt

Create a utils folder to store files that contain utility functions, like the function you’ll use to hash the passwords.

To ensure that user passwords are protected, you’ll need to hash them before they are stored in the database. Let’s implement this

Create a file in your utils folder, this will contain your utility functions.
Import * as bcrypt from 'bcrypt'
Create a function that takes in the raw password and hashes it using bcrypt then returns the hashed password. Export the function.

import * as bcrypt from 'bcrypt';

export async function hashPassword(textPassword: string) {
  const salt = await bcrypt.genSalt();
  const hash = await bcrypt.hash(textPassword, salt);
  return hash;
}

There are different ways to use the bcrypt package, which you can find here.

Now that you have a function to hash our passwords, Implement your first POST request.

Creating a New User

To create a new user with valid credentials, you’ll need to import the DTO you created earlier into your service.

Service Logic

Create an async function newUser that takes in a parameter user which should be the data of the new user. Set its type to the DTO created earlier.
Import the hashPassword function.
Inside the async function, create a constant password, and assign the return value of awaiting the hashPassword function with user.password as an argument.
Return a new instance of your own version of my userModel as an argument pass in an object containing a destructured user and the password, and call the save() method on it.

import { Injectable } from '@nestjs/common';
import { Model } from 'mongoose';
import { InjectModel } from '@nestjs/mongoose';
import { User, UserDocument } from './schemas/user.schema';
import { newUserDto } from './dto/user.dto';
import { hashPassword } from './utilis/bcrypt.utils';

@Injectable()
export class AuthService {
  constructor(
    @InjectModel(User.name)
    private userModel: Model<UserDocument>,
  ) {}

  async newUser(user: newUserDto): Promise<User> {
    const password = await hashPassword(user.password);
    return await new this.userModel({ ...user, password }).save();
  }
}

The DTO and the validators we set up earlier will continuously check if the data is valid before storing the user data in the database.

Implement the controller logic so that you can test the DTO with some dummy data.

Controller Logic

import {
  Controller,
  Body,
  Post, 
} from '@nestjs/common';
import { AuthService } from './auth.service';
import { newUserDto } from './dto/user.dto';

@Controller('users')
export class AuthController {
  constructor(private readonly service: AuthService) {}

  @Post('signup')
  async createUser(
    @Body()
    user: newUserDto,
  ): Promise<newUserDto> {
    return await this.service.newUser(user);
  }

As you can see in the code block above, the user parameter has a type of newUserDto. This ensures that all data coming into the application matches the DTO, else it throws an error.

Testing Endpoints

Test the validation with some dummy data by making requests to http://localhost:3000/users/signup using PostMan or your preferred testing tool.

{
    "fullName":"Jon Snow",
    "email":"snow@housestark.com",
    "password":"password"
}

The JSON data above checks all validation boxes. Hence, you’ll get a 201 response with data, with an _id property and a hashed password. Copy the _id property, you’ll need it when testing data validation in PUT requests.

{
    "fullName":"Arya Stark",
    "email":"aryathefaceless@housestark",
    "password":"password"
}

The JSON data above has an invalid email property. Hence, you’ll get a 400 response with a message that describes the error. Save it to the database by updating the email property to aryathefaceless@housestark.com.

{
    "fullName":"Tyrion Lannister",
    "email":"tyrion@houselannister.com",
    "password":"pass",
     "house":"Lannister"
}

The JSON data above has 2 problems, the password is too short (less than 6 characters) and there is an extra field house.

Increase the length of the password and send the request again. You’ll get a 200 request with the processed data, but the house field isn’t stored in the database because it was filtered when it was passed through the validation pipe.

Updating a User

Implement a PUT route to update user data when required.

Service Logic

async updateUser(id: string, userData: newUserDto): Promise<User> {
    return await this.userModel.findByIdAndUpdate(id, userData);
  }

Controller Logic

@Put(':id')
  async updateuser(
    @Param('id')
    id: string,
    @Body()
    user: newUserDto,
  ): Promise<newUserDto> {
    return this.service.updateUser(id, user);
  }

Similar to the POST request, the user is given a type of newUserDto. Hence, all data is checked thoroughly before it is saved in the database.

Test this endpoint by updating one of the users stored in your database. Recall that you copied the _id belonging to Jon Snow.

So make a PUT request to http://localhost:3000/id with the following data;

{
    "fullName":"Jon Snow",
    "email":"snow@housetargaryen.com",
    "password":"password"
}

The data above checks all validation boxes, so it would return a 200 response. If any of the data fields contain invalid data, it would return a 400 response and the PUT request would fail.

Logging Users in

A user-authentication model wouldn't be complete if you couldn't log users in. To implement the logic for that;

Firstly, you’ll need a bcrypt utility function that will compare the hashed and plain text passwords. Like so,

export async function validatePassword(textPassword: string, hash: string) {
  const validUser = await bcrypt.compare(textPassword, hash);
  return validUser;
}

Then, you’ll have to create a new DTO for the login data. The DTO is similar to the newUserDto but without the fullName property.

import { IsEmail } from 'class-validator';

export class loginUserDto {
  @IsEmail({ message: 'Please Enter a Valid Email' })
  email: string;

  password: string;
}

Notice that no validator was added to the password property. This is because it could pose a security threat in the future, as it exposes the password length range to malicious users.

Service Logic

async loginUser(loginData: loginUserDto) {
    const email = loginData.email;
    const user = await this.userModel.findOne({ email });
    if (user) {
      const valid = await validatePassword(loginData.password, user.password);
      if (valid) {
        return user;
      }
    }
    return new UnauthorizedException('Invalid Credentials');
  }

Your service logic should be able to,

Check if the user exists;

If the user exists, validate the passwords
If the user doesn't exist, throw an exception

Validate Passwords;

If the passwords match, return the user
If the passwords don’t match, throw an exception

Controller Logic

@Post('login')
  async loginUser(
    @Body()
    loginData: loginUserDto,
  ) {
    return await this.service.loginUser(loginData);
  }

Your controller should make the POST request to http://localhost:3000/users/login.

Conclusion

You’re finally at the end of this article. Here’s a recap what you’ve covered.

What a DTO is,
Differences between a DTO and an interface,
Structure of a DTO,
NestJS validation mechanism,
Making a simple user-authentication model with bcrypt.

That’s quite a lot, congratulations on making it this far.

You can find the code on Github.

Happy Coding!

The ABCs of NestJS: A Beginner’s guide with MongoDB(Mongoose).

David Ekete — Sun, 08 May 2022 11:36:06 +0000

What is NestJS?

NestJS is a modern NodeJS framework that makes use of popular NodeJS frameworks such as Express and Fastify under the hood. NestJS was largely inspired by Angular, and as a result, it employs an Angular-style module system. NestJS is written in TypeScript, although it also supports native JavaScript.

Prerequisites

To follow this tutorial, you must meet the following requirements

Competence in PostMan or any other API testing tool.
Basic Knowledge of NodeJS and Express apps.
Basic knowledge of TypeScript.
Competence in MongoDB(Mongoose).

The following should be installed on your system

NodeJS v.14 and above.
Visual Studio Code(Recommended) or any other IDE.
PostMan or any other API testing Tool.

Common Terminologies used in NestJS;

Here are some of the most regularly used terms in NestJS that you'll encounter a lot in this article.

Interfaces

An interface is a type definition. As a result, it is utilized as a type checker/enforcer in functions, classes, etc.

interface humanInterface{
  name:string;
  gender:string;
  age:number;
}

const kevin: humanInterface={
  name:'Kevin Sunders',
  gender:'Male',
  age: 25,
}

The humanInterface above performs strict type checking on the kevin object. Typescript would throw an error if you added another field or changed the type of any of the object properties.

Controllers

Controllers are in charge of receiving incoming requests and responding to the client. A controller collaborates with its associated service.

Services

A service is a provider that stores and retrieves data and is used with its corresponding controller.

Decorators

A decorator is a function-returning expression that accepts a target, name, and property descriptor as optional arguments. Decorators are written as @decorator-name. They are usually attached to class declarations, methods, and parameters.

@Get()
   getAll(): Model[] {
    return this.testService.getAll();
  }

The @Get decorator above marks the code block below it as a GET request. More about that later on.

Module

A module is a part of a program that handles a particular task. A module in NestJS is marked by annotating a class annotated with the @Module() decorator. Nest uses the metadata provided by the @Module() decorator to organize the application structure.

Installing the CLI

To get started you’ll have to install the NestJS CLI ****with npm. You can skip this step if you already have the NestJS CLI installed on your system.

npm i -g @nestjs/cli

This code block above will install the nest CLI globally on your system.

Creating a new project

To generate a new project run nest new followed by your desired project name. For this article, we’ll be writing a simple blog API with CRUD functionality while adhering to RESTful standards.

nest new Blog-Api

This command will prompt you to select a package manager, choose npm.

This will then scaffold the entire project structure with a test API endpoint whose port is set to 3000 by default. You can test it at http://localhost:3000 after running the npm run start:dev command which will start the server in watch mode similar to what nodemon does in express apps.

After testing the endpoint, you’ll need to delete some of the default files because you won’t be needing them anymore. To do this;

open the src folder and inside,
delete app.controller.spec.ts,
delete app.controller.ts,
delete app.service.ts,
Open app.module.ts,
Remove the reference to AppController in the controllers array and the imports,
Remove the reference to AppService in the providers array and the imports.

You might also need to change the README.md to meet your specifications.

Your app.module.ts file should look like this,

//app.module.ts

import { Module } from '@nestjs/common';

@Module({
  imports: [],
  controllers: [],
  providers: [],
})
export class AppModule {}

Environmental Variables

As good practice, some sensitive information in your code shouldn't be made public. For example your PORT and your MongoDB URI.

Let's fix this in your code.

On your terminal run

npm i dotenv

Then create a .env file in your directory and add it to your .gitignore file. Store your PORT variable, you will also have to store your MongoDB URI later in the same place. Now replace the exposed PORT in your main.ts file. To do this, import the dotenv package and call the .config() method on it.

import * as dotenv from 'dotenv';
dotenv.config();

This should be your main.ts file after you follow the steps above.

//main.ts

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import * as dotenv from 'dotenv';
dotenv.config();

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(process.env.PORT);
}
bootstrap();

Generating Modules

To generate a NestJS module using the NestJS CLI run the code snippet below.

nest generate module blogs

This command creates a blogs folder that contains a blogs.module.ts file and registers BlogsModule in your app.module.ts file.

Generating Interfaces

Let’s generate an interface using the NestJS CLI to do the type checking for the object that will represent your blog posts. To achieve this you have to first cd into the blogs folder because it is recommended that they be stored near the domain objects to which they are associated.

cd src/blogs

Then run the code snippet below to generate the interface.

nest generate interface blogs

this creates a blogs.interface.ts file. This is where we will define our interface. we’ll name the interface BlogsInterface.

export interface BlogsInterface {
  title: string;
  body: string;
  category: string;
  dateCreated: Date;
}

before running any more commands on your terminal, remember to cd out of the src folder and back into your root folder by running

cd ../..

Generating Services & Controllers

You’ll need to generate a service class to store and retrieve data and handle all the logic and a controller class to handle all incoming requests and outgoing responses.

Service

To generate a service run the command below,

nest generate service blogs

This command creates two files the blogs.service.spec.ts and the blogs.service.ts and registers the service in the providers array in the blogs.module.ts.

Controller

To generate a controller run the command below,

nest generate controller blogs

This command creates two files the blogs.controller.spec.ts and the blogs.controller.ts and registers the controller in the controllers array in the blogs.module.ts.

With these your blogs structure is almost complete, you just need to make the BlogsService accessible to other parts of your program. You can achieve this by creating an exports array in the blogs.module.ts file and registering the BlogsService in that array.

//blogs.module.ts

import { Module } from '@nestjs/common';
import { BlogsService } from './blogs.service';
import { BlogsController } from './blogs.controller';

@Module({
  providers: [BlogsService],
  controllers: [BlogsController],
  exports: [BlogsService],
})
export class BlogsModule {}

MongoDB(Mongoose).

Install mongoose by running,

npm install --save @nestjs/mongoose mongoose

After the installation, import {MongooseModule} from '@nestjs/mongoose’ into your app.module.ts file. Then grab your MongoDB URI and store it in your .env file. Repeat the steps to import dotenv in the app.module.ts file. Then in the imports array call the .forRoot() method which takes your MongoDB URI as an argument on the MongooseModule. Similar to the mongoose.connect() in regular express apps.

@Module({
  imports: [BlogsModule, MongooseModule.forRoot(process.env.MONGODB_URI)],

Creating a Schema.

Let’s create a schema to define the shape of the blogs in our collection. To do this,

Create a folder inside your blogs folder, name it schemas,
Inside the schemas folder, create a file and call it blogs.schema.ts.

Then,

Firstly, you’ll have to,

Import the prop decorator, the Schema decorator, and the SchemaFactory from @nestjs/mongoose,
Create a class Blog and export it,
Turn the class into a Schema by placing the @Schema() decorator above the class,
Create a constant BlogSchema, assign the return value of calling the .createForClass(Blog) with the name of your class as an argument on SchemaFactory that you imported earlier.

//blogs.schema.ts

import { Prop, Schema, SchemaFactory } from '@nestjs/mongoose';

@Schema()
export class Blog {}

export const BlogSchema = SchemaFactory.createForClass(Blog);

Then you’ll need to define the properties of the Schema.

To define a property in the schema you’ll need to mark each of them with the @prop() decorator. The @prop decorator accepts an options object or a complex type declaration. The complex type declarations could be arrays and nested object type declarations.

//blogs.schema.ts

import { Prop, Schema, SchemaFactory } from '@nestjs/mongoose';

@Schema()
export class Blog {
  @Prop({ required: true })
  title: string;

  @Prop({ required: true })
  body: string;

  @Prop({ required: true })
  category: string;

  @Prop({ required: true })
  dateCreated: Date;
}

export const BlogSchema = SchemaFactory.createForClass(Blog);

Next import { Document } from 'mongoose'.

Then create a union type with the Schema class and the imported Document. Like so,

//blogs.schema.ts

import { Document } from 'mongoose';

export type BlogDocument = Blog & Document;

Your final blogs.schema.ts file should look like this,

import { Prop, Schema, SchemaFactory } from '@nestjs/mongoose';
import { Document } from 'mongoose';

export type BlogDocument = Blog & Document;

@Schema()
export class Blog {
  @Prop({ required: true })
  title: string;

  @Prop({ required: true })
  body: string;

  @Prop({ required: true })
  category: string;

  @Prop({ required: true })
  dateCreated: Date;
}

export const BlogSchema = SchemaFactory.createForClass(Blog);

Registering Schema

You’ll need to import everything into your blogs.module.ts file. To achieve this you’ll need to,

Import {MongooseModule} from '@nestjs/mongoose’,
Import {Blog, BlogSchema} from './schemas/blogs.schema'
Create an imports array inside the @module decorator
Call the .forFeature() method on the MongooseModule. This takes in an array containing an object that defines a name and a schema property which should be set to your Blog.name and your BlogSchema respectively.

@Module({
  imports: [
    MongooseModule.forFeature([{ name: Blog.name, schema: BlogSchema }]),
  ],

Injecting Model

You’ll need to inject the Blog model into the blogs.service.ts using the @InjectModel() decorator. To achieve this you’ll have to

import { Model } from 'mongoose',
import { InjectModel } from '@nestjs/mongoose',
Import {Blog, BlogDocument} from './schemas/blogs.schema’,
Create a constructor inside the BlogsService class,
Declare a private variable and call it blogModel and assign a type of Model<BlogDocument> to it. All mongoose methods will be called on this variable.

Recall that, BlogDocument is the union type of the Blog class and the Mongoose Model that you created earlier. It is used as the generic type for your variable.

Decorate blogModel with @InjectModel() and pass Blog.name as an argument.

constructor(
    @InjectModel(Blog.name)
    private blogModel: Model<BlogDocument>,
  ) {}

How Routing Works

By now you must have noticed that the @Controller decorator has the string 'blogs' passed into it. This means that the controller will send all responses and handle all requests made on http://localhost/3000/blogs.

Next up you’ll implement the service and controller logic.

Service and Controller Logic.

It's finally time to implement your CRUD functionality.

Before we get started you’ll need to set up your controller. Start by importing some HTTP method decorators into your controller.

//blogs.controller.ts

import {
  Controller,
  Body,
  Delete,
  Get,
  Post,
  Put,
  Param,
} from '@nestjs/common';

Then, you’ll need to import the service and register it so you can be able to access it and import the interface for type-checking.

//blogs.controller.ts

import { BlogsInterface } from './blogs.interface';
import { BlogsService } from './blogs.service';

To register your service create a constructor inside the BlogsController class and declare a private readonly variable service and set its type to BlogsService.

constructor(private readonly service: BlogsService) {}

Now that you’re all set up, let’s get started.

Create

Service Logic

Import { BlogsInterface } from './blogs.interface' and add an async function to the BlogsService class called createBlog, which will take one parameter blog, with its type as BlogInterface, and its return type as a Promise with a generic <Blog> type.

async createBlog(blog: BlogsInterface): Promise<Blog> {
    return await new this.blogModel({
      ...blog,
      dateCreated: new Date(),
    }).save();
  }

Controller Logic

In your BlogsController class add an async function to the class. Call it createBlog and mark it with the @Post decorator which defines it as a POST request.createBlog takes one parameter blog, with its type as BlogInterface. Mark the parameter with @Body decorator which extracts the entire body object from the req object and populates the decorated parameter with the value of body.

@Post()
  async createBlog(
    @Body()
    blog: BlogsInterface,
  ) {
    return await this.service.createBlog(blog);
  }

Read

Add two async methods, One to return a single blog post and the second to return all the blog posts.

Service Logic

async getAllBlogs(): Promise<Blog[]> {
    return await this.blogModel.find().exec();
  }

  async getBlog(id: string): Promise<Blog> {
    return await this.blogModel.findById(id);
  }

Controller Logic

  @Get()
  async getAllBlogs() {
    return await this.service.getAllBlogs();
  }

  @Get(':id')
  async getBlog(@Param('id') id: string) {
    return await this.service.getBlog(id);
  }

The async functions are marked with the @Get decorator which defines it as a GET request.

The second async function’s decorator has an argument ':id'. Which is what you’ll pass into the @Param decorator. The parameter is marked with the @Param('id') which extracts the params property from the req object and populates the decorated parameter with the value of params.

Update

Let’s implement the logic for the PUT request.

Service Logic

async updateBlog(id: string, body: BlogsInterface): Promise<Blog> {
    return await this.blogModel.findByIdAndUpdate(id, body);
  }

Controller Logic

@Put(':id')
  async updateBlog(
    @Param('id')
    id: string,
    @Body()
    blog: BlogsInterface,
  ) {
    return await this.service.updateBlog(id, blog);
  }

The async function’s second parameter is marked with the @Body() decorator which extracts the entire body object from the req object and populates the decorated parameter with the value of body.

Delete

Let’s implement the logic for delete requests.

Service Logic

async deleteBlog(id: string): Promise<void> {
    return await this.blogModel.findByIdAndDelete(id);
  }

The Promise generic type is void because a Delete request returns an empty promise.

Controller Logic

@Delete(':id')
  async deleteBlog(@Param('id') id: string) {
    return await this.service.deleteBlog(id);
  }

Testing the API

To test this API, you should use an API testing tool. For this article, I’ll be using a popular API testing tool called Postman. I’ll be using random data about popular topics to test.

Create

Make a POST request to http://localhost/3000/blogs with the following JSON objects, this will add all the data to your database.

{
  "title": "jeen-yuhs",
  "body": "The life of superstar rapper Kanye West is currently streaming on Netflix - and according to our jeen-yuhs review, it's a fascinating watch. -credit:Radio Times",
  "category":"Music"
}

{
  "title": "Why You Should Always Wash Your Hands",
  "body": "Germs from unwashed hands can be transferred to other objects, like handrails, tabletops, or toys, and then transferred to another person's hands.-credit cdc.gov",
  "category":"Health"
}

{
  "title": "Why You Should Follow me on Twitter",
  "body": "Well, Because I asked nicely",
  "category":"Random"
}

You should get a 201 response and the created blog with a date and an _id added.

Read

Make a GET request to http://localhost/3000/blogs. This should return a

200 response with an array of all the data you previously added. Copy the _id property of one of the array objects.

Make another GET request to http://localhost/3000/blogs/id with the previously copied id. This should return a 200 response with the data of the object whose id was used to make the request.

Update

Make a PUT request to http://localhost/3000/blogs/id with the data below. The id should be replaced with the one you copied earlier. This should return a 200 response and updates the object bearing the id behind the scenes. if you run another GET request you should get the updated object.

{
  "title": "why you Should Cut your Nails",
  "body": "It's important to trim your nails regularly. Nail trimming together with manicures makes your nails look well-groomed, neat, and tidy.- credit:WebMD",
  "category":"Health"
}

Delete

Make a DELETE request to http://localhost/3000/blogs/id.This should return a 200 response and deletes the object bearing the id behind the scenes. if you run another GET request you won’t see the deleted object.

Conclusion

So we’re finally at the end of this article. Let’s recap what you’ve covered.

What NestJS is,
Terminologies in NestJS,
Creating a NestJS app,
Integrating MongoDB into a NestJS app,
Manipulating and NestJS app,

That’s quite a lot, congratulations on making it this far.

You can find the code on github.

Good luck on your NestJS journey!