DEV Community: Maakai123

Aptos Move #Tip 8: Understanding Aptos Objects and ConstructorRef Leaks.

Maakai123 — Tue, 03 Jun 2025 17:54:38 +0000

What Are Aptos Objects?

In the Aptos blockchain, Objects are a way to represent things like NFTs (non-fungible tokens, like digital art or collectibles), tokens, or other assets. Think of an Object as a digital container that holds data and rules about how that data can be used. For example, an NFT Object might store the image URL, its name, and who owns it.When you create an Object (like minting a new NFT), you use something called a ConstructorRef. This is like a special key that lets you set up the Object and decide what rules or resources (like ownership details) it should have. However, this key is powerful, and if it falls into the wrong hands, it can cause serious problems.

What Is a ConstructorRef Leak, and Why Is It Dangerous?

A ConstructorRef is a temporary capability (or permission) created when you make a new Object in Aptos. It allows you to:
Add resources to the Object (like extra data or rules).Create other capabilities, like a TransferRef, which controls who can move or transfer the Object.

If you accidentally share or expose the ConstructorRef (for example, by returning it in a function), someone else could use it to:Add unauthorized resources to the Object.Generate a TransferRef to move the Object, even after it’s been sold or transferred to someone else.Store the ConstructorRef in a way that lets the original creator (or a hacker) regain control later.This is called a ConstructorRef leak, and it’s a big security risk. Imagine selling a digital collectible (like a rare Pokémon card NFT) and then finding out the original creator can take it back because they kept a secret key!

Real-World Example: A Vulnerable NFT Minting Function

Let’s say you’re building an NFT marketplace on Aptos where artists can create (or "mint") NFTs. You write a function that creates an NFT and returns its ConstructorRef. Here’s what that might look like in Move, the programming language used by Aptos:

module 0x42::example {
  use std::string::utf8;
  use aptos_framework::token;

  public fun mint(creator: &signer): ConstructorRef {
    let constructor_ref = token::create_named_token(
        creator,
        utf8(b"Collection Name"),
        utf8(b"Collection Description"),
        utf8(b"Token"),
        option::none(),
        utf8(b"https://mycollection/token.jpeg"),
    );
    constructor_ref // Returning the ConstructorRef
  }
}

What’s the problem?

The mint function returns the ConstructorRef, which is like handing over the master key to the NFT.
Anyone with the ConstructorRef can create a TransferRef (another capability) to move the NFT, even after it’s sold.They could also store the ConstructorRef somewhere (like in global storage on the blockchain) and use it later to steal the NFT back or mess with its rules.

Real-world analogy:
Imagine you sell a car and give the buyer the title, but you accidentally include a duplicate key that lets you unlock and drive the car anytime.
A ConstructorRef leak is like leaving that duplicate key lying around where anyone can grab it.

How to Fix It:

Secure Coding Practices to prevent a ConstructorRef leak, you should never return or expose the ConstructorRef. Instead, keep it private within the function and only use it to set up the Object as needed. Here’s how to fix the code:

module 0x42::example {
  use std::string::utf8;
  use aptos_framework::token;

  public fun mint(creator: &signer) {
    let constructor_ref = token::create_named_token(
        creator,
        utf8(b"Collection Name"),
        utf8(b"Collection Description"),
        utf8(b"Token"),
        option::none(),
        utf8(b"https://mycollection/token.jpeg"),
    );
    // Don’t return constructor_ref; let it be discarded
  }
}

What’s happening here?

The mint function creates the NFT using create_named_token, which generates a ConstructorRef.
Instead of returning the ConstructorRef, the function keeps it internal and lets it be discarded when the function ends.This ensures no one (not even the creator) can misuse the ConstructorRef to tamper with the NFT later.

Real-world analogy:
When you sell that car, you give the buyer the title and keys but destroy any duplicate keys immediately. This way, no one can come back and steal the car later.

Why This Matters in the Real World
ConstructorRef leaks can have serious consequences in blockchain applications.
Here are a few examples:

NFT Marketplaces: If an NFT’s ConstructorRef is leaked, the original creator could generate a TransferRef and take the NFT back after it’s sold, cheating the buyer. For example, someone buys a $10,000 digital artwork, only to have it stolen back by the creator.

Decentralized Finance (DeFi): In a DeFi app, an Object might represent a user’s stake in a pool.
A leaked ConstructorRef could let someone add fake resources or transfer the stake to themselves, draining funds.

Gaming: In a blockchain game, Objects might represent rare items or characters. A leak could allow someone to duplicate or steal those items, ruining the game’s fairness.In all these cases, a ConstructorRef leak undermines trust in the system. Users expect blockchain apps to be secure and fair, and leaks can lead to financial losses or a damaged reputation.

How Move and Aptos Help (But You Still Need to Be Careful)

The Move programming language (used by Aptos) is designed with security in mind.

Objects and their capabilities (like ConstructorRef and TransferRef) are tightly controlled to prevent common mistakes.
For example:ConstructorRef is only created when you make a new Object, and it’s meant to be used immediately and discarded.
Aptos’s Object system ensures that only authorized users (like the creator with a signer) can create Objects, but developers must still be careful not to expose sensitive capabilities.
However, Move can’t stop you from writing code that accidentally shares a ConstructorRef. That’s why secure coding practices, like the example above, are crucial.

Real-world analogy: Think of Move as a bank vault with a strong lock. It’s secure, but if you leave the vault door open (by returning a ConstructorRef), anyone can walk in and take what’s inside. It’s up to you to close the door

Aptos Move Tip #7: Understanding Arithmetic Operations and Division Precision in Move.

Maakai123 — Sun, 01 Jun 2025 12:49:04 +0000

What Are Arithmetic Operations?

Arithmetic operations are the basic math calculations you learned in school: addition (+), subtraction (-), multiplication (*), division (/), and sometimes bit-shifting (like moving numbers around in binary). In programming, these operations are used to calculate things like fees, balances, or rewards in apps, including blockchain applications.In the Move programming language (designed for secure blockchain smart contracts, these operations are critical because they often deal with money or valuable assets. If the math isn’t handled carefully, small mistakes can lead to big problems, like losing money or giving someone an unfair advantage.

What Is Division Precision, and Why Does It Matter?

When you divide numbers, sometimes the result isn’t a whole number. For example, 7 ÷ 2 = 3.5. In many programming languages, including Move, division between integers (whole numbers like 1, 2, or 100) doesn’t keep the decimal part—it rounds down to the nearest whole number. So, 7 ÷ 2 in Move would give you 3, not 3.5. This is called truncation.

While this might sound harmless, it can cause issues in blockchain applications where precision is critical. For example, if you’re calculating fees for a transaction, rounding down might accidentally make the fee zero, letting someone use a service for free! This loss of precision is called a rounding error, and it can lead to:

Financial imbalances: Someone might pay less (or nothing) when they should owe money.

Data inaccuracies: Incorrect calculations can mess up records or reports.

Flawed decisions: Systems relying on these calculations might make wrong choices, like approving invalid transactions.
Safety risks: In extreme cases (like in medical or automotive systems), errors could cause serious harm.In blockchain, where trust and accuracy are everything, these errors can erode user confidence or even allow bad actors to exploit the system.

Arithmetic in Move:
The Basics Move supports six types of unsigned integers (numbers that are always zero or positive, like 0, 1, 10, or 100).
These are:

u8: Can store numbers from 0 to 255.
u16: Up to 65,535
u32: Up to about 4.3 billion
u64: Up to about 18 quintillion
u128: Even bigger numbers
u256: For extremely large numbers.

When you do math with these numbers in Move, the language has built-in safety features to prevent common errors:

Addition (+) and Multiplication (*): If the result is too big for the integer type (e.g., adding two huge numbers), the program aborts (stops running) to prevent incorrect results.

Subtraction (-): If the result would be negative (e.g., 5 - 10), the program aborts because unsigned integers can’t be negative.

Division (/): If you try to divide by zero, the program aborts.

Left Shift (<<): This operation shifts bits in a number (like multiplying by powers of 2). Unlike the others, it doesn’t abort if the result is too big—it just produces an incorrect value, which can be dangerous if not handled properly.
These safety features are great, but they don’t solve the problem of division precision. Let’s dive into a real-world example to see why this matters.

Real-World Example: Calculating Fees in a Blockchain Protocol

Imagine you’re building a decentralized marketplace on a blockchain where users pay a small fee (say, 1%) for every transaction. The fee is calculated using a formula like this:

Fee = Transaction Size * Fee Percentage / 100

In Move, this might be written as code that uses integers. Let’s say the fee percentage is represented as 100 “basis points” (where 1% = 100 basis points, or PROTOCOL_FEE_BPS = 100).
Here’s what the code might look like:


module 0x42::example {
  const PROTOCOL_FEE_BPS: u64 = 100; // 1% fee
  public fun calculate_protocol_fees(size: u64): u64 {
    return size * PROTOCOL_FEE_BPS / 10000; // 100 basis points = 1%
  }
}

What’s the problem? If the size (transaction amount) is small, the division can round down to zero. For example:If size = 50 tokens, the calculation is:50 * 100 / 10000 = 5000 / 10000 = 0.5In Move, this rounds down to 0.

This means a user could make a small transaction and pay no fee at all, which could let them exploit the system by making lots of tiny transactions for free. In a real marketplace, this could lead to thousands of dollars in lost revenue or even crash the system if someone spams it with tiny transactions.

How to Fix It: Secure Coding Practices

To prevent this issue, you need to ensure the fee calculation doesn’t round down to zero.
Here are two ways to fix the code,

explained simply:

Fix 1: Set a Minimum Transaction Size You can require that transactions be large enough so the fee never rounds down to zero.
For example, if the fee is 1% (100 basis points), the minimum transaction size should be at least 10000 / 100 + 1 = 101 to ensure the fee is at least 1.
Here’s the secure code:

module 0x42::example {
  const PROTOCOL_FEE_BPS: u64 = 100; // 1% fee
  const MIN_ORDER_SIZE: u64 = 10000 / PROTOCOL_FEE_BPS + 1; // 101
  public fun calculate_protocol_fees(size: u64): u64 {
    assert!(size >= MIN_ORDER_SIZE, 0); // Check size is big enough
    return size * PROTOCOL_FEE_BPS / 10000;
  }
}

What’s happening here?

The MIN_ORDER_SIZE is calculated as 10000 / 100 + 1 = 101.
The assert! line checks that the transaction size is at least 101. If it’s smaller, the program aborts (stops) with an error.This ensures the fee is always at least 1, preventing free transactions.

Real-world analogy:

Imagine a coffee shop that charges a 1% service fee but requires you to spend at least $10. If you only buy a $1 coffee, they won’t let you pay because the fee would be too small (like 1 cent, which might round to zero in their system). This rule ensures they always collect something.

Fix 2: Check for Non-Zero Fees

Another approach is to calculate the fee and then check if it’s zero. If it is, you can either reject the transaction or set a minimum fee (e.g., 1 token).
Here’s the code:

module 0x42::example {
  const PROTOCOL_FEE_BPS: u64 = 100; // 1% fee
  public fun calculate_protocol_fees(size: u64): u64 {
    let fee = size * PROTOCOL_FEE_BPS / 10000;
    assert!(fee > 0, 0); // Ensure fee isn’t zero
    return fee;
  }
}

What’s happening here?

The code calculates the fee as before.
The assert!(fee > 0, 0) line checks if the fee is zero.
If it is, the program aborts.
This prevents users from making transactions that result in no fee.

Real-world analogy:

Think of a toll booth on a highway. If your toll calculates to zero (maybe because your car is super small), the booth operator says, “Sorry, you can’t pass unless you pay at least something.” This ensures the toll system always collects a fee.

Why Move’s Safety Features Matters

Move’s strict rules about integer operations (like aborting on overflow or division by zero) are designed to make smart contracts safer. For example:
If you try to add two huge numbers and the result is too big for a u64, the program stops instead of giving a wrong answer.If you try to subtract a larger number from a smaller one (e.g., 5 - 10), the program stops because negative numbers aren’t allowed in unsigned integers.
If you try to divide by zero, the program stops to avoid crashing the system.However, the left shift (<<) operation is an exception—it doesn’t abort if the result is too big, which can lead to incorrect calculations. For example, shifting a number too far could “lose” bits, producing a wrong value. Developers need to be extra careful with this operation.

Why This Matters in the Real WorldLet’s

look at a few real-world scenarios where these issues could cause problems.

Decentralized Finance (DeFi)
In a DeFi lending platform, fees are charged on loans. If division rounding causes fees to be zero for small loans, users could borrow tiny amounts repeatedly without paying anything, draining the platform’s revenue.

Aptos Move Tip #6 – Move Abilities

Maakai123 — Fri, 30 May 2025 22:16:49 +0000

In Aptos Move, abilities are like permission tags for data structures, controlling what can be done with them (e.g., copying, discarding, or storing). Think of them as security settings on a file—assign the wrong permissions, and you could expose sensitive data or break your smart contract. This tip explains Move’s abilities, their risks, and how to use them securely to build robust dApps on Aptos.

Why It Matters

Move’s abilities (copy, drop, store, key) define how data structures behave. Misusing them can lead to serious vulnerabilities:Unauthorized copying of sensitive data (e.g., duplicating tokens).
Resource leaks by not allowing data to be discarded.
Storage mishandling, causing data to be inaccessible or misused.By assigning abilities carefully, you ensure your smart contract is secure, efficient, and behaves as intended.

Real-World Example

Imagine a dApp for digital concert tickets on Aptos. Each ticket is a unique Token struct.
If you allow tickets to be copied freely, someone could duplicate their ticket and sell it multiple times, like photocopying a concert pass! Similarly, if a flash loan system lets borrowers “throw away” their debt without repaying, the system collapses. Proper ability management is like setting strict rules for ticket use—only the right actions are allowed.

Move Abilities Explained

Here’s what each ability does and why it matters:
Copy: Allows duplicating a value. Useful for simple data like numbers, but dangerous for assets like tokens or NFTs, as it could lead to double-spending.
Drop: Permits discarding a value from memory. Necessary for cleanup, but risky for assets that must persist (e.g., loans).

Store: Enables saving data in global storage (on-chain). Critical for persistent data, but must be restricted to prevent unauthorized access.

Key: Allows data to act as a key in global storage, enabling retrieval and manipulation. Essential for resources tied to accounts.

Insecure Code Example

This code assigns abilities incorrectly, creating vulnerabilities:

module 0x42::example {
  struct Token has copy { value: u64 }
  struct FlashLoan has drop { amount: u64 }
}

Problems:
Token has copy: The copy ability lets anyone duplicate a Token, potentially creating unlimited tokens (like printing fake money). This could inflate the token supply and crash the dApp’s economy.

FlashLoan has drop: The drop ability allows borrowers to discard a FlashLoan without repaying it, like tearing up an IOU note and walking away debt-free.

Secure Code Example
Restrict abilities to only what’s needed for the business logic:

module 0x42::example {
  struct Token has key, store { value: u64 }
  struct FlashLoan has key, store { amount: u64 }
}

Why It’s Better:

Token: Removes copy to prevent duplication, ensuring tokens are unique. Adds key and store to allow secure storage and retrieval in global storage (e.g., tied to a user’s account).
FlashLoan: Removes drop to prevent discarding unpaid loans, ensuring borrowers must repay. Adds key and store for persistent loan tracking.

Key Takeaways
Assign abilities sparingly: Only give copy, drop, store, or key when the business logic requires it.
Avoid copy for assets: Prevent duplication of tokens, NFTs, or other sensitive resources.
Restrict drop for obligations: Ensure critical data like loans can’t be discarded without proper handling.Use store and key for persistence: Enable secure storage and retrieval of data in global storage.
Impact: Proper ability management prevents vulnerabilities like double-spending or resource leaks, keeping your dApp secure and reliable

Pro Tips for Developers

Review each struct’s purpose and assign only the necessary abilities.
Avoid copy for any resource representing value (e.g., tokens, NFTs).
Use drop only for temporary or non-critical data, not obligations like loans.Test your contract with incorrect ability assignments to catch potential exploits.

Aptos Move Tip #5 – Resource Management and Unbounded Execution

Maakai123 — Thu, 29 May 2025 22:52:43 +0000

Introduction

When building smart contracts on Aptos using Move, security and efficiency are paramount. One critical aspect is resource management and preventing unbounded execution.
Poorly designed contracts can allow attackers to clog the system, exhaust gas (the computational cost of transactions), and block functionality.
This tip explains how to manage resources securely and avoid loops that could spiral out of control, with practical examples to make it crystal clear.

Why It Matters

In Move, unbounded execution happens when a function loops over a data structure (like a list) that can grow infinitely, consuming excessive gas and potentially causing transactions to fail. Similarly, storing all user data in a single global structure can make your contract vulnerable to attacks and inefficient.
It’s like running a store where every customer’s order is piled into one massive, disorganized box—anyone could overwhelm it with junk orders, slowing everything down or crashing the system!
To manage resources effectively store user-specific data (like coins or NFTs) in individual user accounts, not a shared global space.Avoid iterating over unbounded structures that anyone can add to without limits.
Use efficient data structures (like SmartTable) to keep operations fast and secure.This ensures your dApp stays scalable, secure, and gas-efficient.

Real-World Example

Imagine running an online marketplace on Aptos, like eBay, where users place buy orders for items. All orders are stored in one global list accessible to everyone. An attacker could flood the list with thousands of fake orders, making it slow or impossible to search for a specific order because the system has to check every single one. This could crash the transaction or make the app unusable due to high gas costs.The solution? Store each user’s orders in their own account, like giving every customer their own order folder. This isolates data, prevents tampering, and keeps operations fast by avoiding huge loops.

Insecure Code Example

Here’s a problematic code snippet where orders are stored in a single global OrderStore. The get_order_by_id function loops through every order to find a match, which can become slow and costly if the list grows large due to unrestricted additions.

module 0x42::example {
  struct Order has copy, drop, store { id: u64, /* other fields */ }
  struct OrderStore has key { orders: vector<Order> }

  public fun get_order_by_id(order_id: u64): Option<Order> acquires OrderStore {
    let order_store = borrow_global_mut<OrderStore>(@admin);
    let i = 0;
    let len = vector::length(&order_store.orders);
    while (i < len) {
      let order = vector::borrow<Order>(&order_store.orders, i);
      if (order.id == order_id) {
        return option::some(*order)
      };
      i = i + 1;
    };
    return option::none<Order>()
  }

  public entry fun create_order(buyer: &signer) { /* ... adds to global order_store */ }
}

Why It’s Bad:
The orders vector is global and publicly accessible, so anyone can add unlimited orders via create_order.The while loop in get_order_by_id checks every order, making it an O(n) operation (slow for large lists).An attacker could spam the list with fake orders, causing high gas costs or transaction failures, blocking legitimate users.It’s like searching through a giant pile of orders at the post office—slow, costly, and easy to sabotage.

Secure Code Example

Instead, store orders in each user’s account using a SmartTable for efficient lookups. This isolates user data and eliminates unbounded loops, ensuring fast and secure operations.

module 0x42::example {
  struct Order has copy, drop, store { id: u64, /* other fields */ }
  struct OrderStore has key { orders: SmartTable<u64, Order> }

  public fun get_order_by_id(user: &signer, order_id: u64): Option<Order> acquires OrderStore {
    let order_store = borrow_global_mut<OrderStore>(signer::address_of(user));
    if (smart_table::contains(&order_store.orders, order_id)) {
      let order = smart_table::borrow(&order_store.orders, order_id);
      option::some(*order)
    } else {
      option::none<Order>()
    }
  }
}

Why It’s Better:Orders are stored in a SmartTable under the user’s account (signer::address_of(user)), isolating data to prevent tampering.SmartTable enables O(1) lookups (constant time), avoiding costly loops.Only the user can access their own orders, enhancing security and scalability.It’s like giving each customer a personal, indexed filing cabinet—fast, secure, and tamper-proof.Key Takeaways
Avoid unbounded loops: Don’t iterate over structures (like vectors) that anyone can grow infinitely.Isolate user data: Store assets like orders, coins, or NFTs in individual user accounts, not a shared global space.

Pro Tips for Developers

Always check if a data structure can grow uncontrollably before looping over it.Use signer::address_of(user) to tie resources to specific accounts.Opt for SmartTable or similar structures for key-value lookups instead of vectors.Test your contract with large datasets to ensure gas efficiency and scalability.By designing with these principles, you’ll build secure, efficient, and scalable smart contracts on Aptos.

Secure Generics Type Checking APTOS MOVE

Maakai123 — Wed, 28 May 2025 17:38:42 +0000

Generics in Move allow functions and structs to work with different data types, like a universal key. But if you don’t verify the type, attackers could sneak in the wrong key, leading to unauthorized actions or transaction failures.

Real-World Example

Picture a dApp offering flash loans on Aptos. Users borrow coins (e.g., USD tokens) and must repay with a fee. Without checking the coin type, someone could borrow USD but repay with worthless “FakeCoin,” cheating the system! 😈Let’s see how this happens and how to fix it.

Insecure Code

This flash loan code doesn’t ensure the repaid Coin matches the borrowed type, allowing users to repay with any coin type.

module 0x42::example {
  struct Coin<T> { amount: u64 }
  struct Receipt { amount: u64 }

  public fun flash_loan<T>(user: &signer, amount: u64): (Coin<T>, Receipt) {
    let (coin, fee) = withdraw(user, amount);
    (coin, Receipt { amount: amount + fee })
  }

  public fun repay_flash_loan<T>(rec: Receipt, coins: Coin<T>) {
    let Receipt { amount } = rec;
    assert!(coin::value<T>(&coins) >= amount, 0);
    deposit(coins);
  }
}

Problem: The Receipt struct isn’t tied to the coin type T, so users can repay a USD loan with any Coin, like a fake token. It’s like accepting a random gift card to settle a bank loan!

Secure Code ✅

Use Move’s type system (e.g., phantom types) to ensure the Receipt and Coin types match, preventing type mismatches.

module 0x42::example {
  struct Coin<T> { amount: u64 }
  struct Receipt<phantom T> { amount: u64 }

  public fun flash_loan<T>(_user: &signer, amount: u64): (Coin<T>, Receipt<T>) {
    let (coin, fee) = withdraw(_user, amount);
    (coin, Receipt { amount: amount + fee })
  }

  public fun repay_flash_loan<T>(rec: Receipt<T>, coins: Coin<T>) {
    let Receipt { amount } = rec;
    assert!(coin::value<T>(&coins) >= amount, 0);
    deposit(coins);
  }
}

Fix: Adding phantom T to Receipt ensures the repaid Coin matches the borrowed type. It’s like requiring the exact currency for loan repayment—USD in, USD out!

What does returns (uint256) in Solidity means?

Maakai123 — Wed, 27 Nov 2024 08:33:04 +0000

Have you ever seen something like this?

function getBorrowingCapacity(address user) external view returns (uint256) {
    // Example calculation: Borrowing capacity is 75% of collateral
    return (collateral[user] * borrowFactor) / 100;
}

in this function we have external view returns(uint256)
What is (unit256) doing?

When working with Solidity, the Ethereum blockchain's most widely used smart contract programming language, you’ll often encounter function declarations that specify a returns keyword followed by a data type, such as uint256. If you’ve ever wondered why this is necessary or how it works, this guide will break it all down for you.

What Does returns (uint256) Mean?

The returns (uint256) in a Solidity function declaration defines the type of value the function will produce and send back to the caller after it is executed. This lets the caller know exactly what type of data to expect in response.

Here’s an example of a function declaration:

function getBorrowingCapacity(address user) external view returns (uint256).

This function, getBorrowingCapacity, is designed to return a single unsigned integer value (a uint256). This return value might represent something like the borrowing capacity of the specified user.

Why Is uint256 Used?

In Solidity, uint256 is a widely used data type. Here's why it’s appropriate for functions like this:

Non-Negative Values: Since uint256 represents unsigned integers, it can only hold non-negative values. This is ideal for cases like borrowing capacity, balances, and other numbers that cannot logically be negative.
Large Range: The uint256 type can store extremely large numbers, from 0 to . This ensures that even the largest possible borrowing capacities can be accurately stored and returned.
Standard Practice: Solidity defaults to uint256 for most numerical computations because it is safer and more scalable.

How returns (uint256) Works in Practice

Let’s explore a practical example. Imagine you are building a decentralized lending platform where users can borrow tokens based on the value of their deposited collateral. The getBorrowingCapacity function could calculate the maximum amount a user is allowed to borrow.

Here’s how such a function might be implemented:

// Mapping to store each user's collateral balance in tokens

mapping(address => uint256) public collateral;



// Borrowing factor: users can borrow up to 75% of their collateral value
uint256 public borrowFactor = 75;

function getBorrowingCapacity(address user) external view returns (uint256) {
    // Example calculation: Borrowing capacity is 75% of collateral
    return (collateral[user] * borrowFactor) / 100;
}

Example Scenario

Let’s say Alice deposits 1000 tokens as collateral, and the borrowFactor is set to 75%. When the function is called with Alice's address, it calculates her borrowing capacity as follows:

Collateral: 1000 tokens.
Borrowing Factor: 75%.
Calculation: .

If you call the function like this:

contractInstance.getBorrowingCapacity(alice);

The function will return:

750

Why Use returns in Solidity?

In Solidity, the returns keyword is essential for creating readable and reusable functions. Here are the main reasons to use it:

Data Communication: Functions often need to communicate results (like computed values) back to the caller. Using returns explicitly defines the type of value the function will provide.
Clear Expectations: The return type ensures that developers or external contracts interacting with the function know exactly what type of data they can expect. This reduces ambiguity and makes debugging easier.
Chaining and Reuse: Returned values can be stored, reused, or even passed as inputs to other functions. For example:

uint256 capacity = contractInstance.getBorrowingCapacity(alice);
if (capacity > 500) {
// Proceed with borrowing
}

Efficiency: Returning data directly from a function eliminates the need for extra state variables, making the function more efficient and less prone to bugs.

Real-World Use Cases for returns (uint256)

Here are some common scenarios where uint256 is returned in Solidity:

Token Balances: A function might return the balance of tokens a user holds:

function balanceOf(address user) external view returns (uint256);

Borrowing Capacity: As in our example, it might calculate how much a user can borrow:

function getBorrowingCapacity(address user) external view returns (uint256);

Interest Rates: It might compute and return interest rates for loans:

function getInterestRate() external view returns (uint256);

Auction Bids: It could return the highest bid in an auction:

function getHighestBid() external view returns (uint256);

Conclusion

The returns (uint256) in Solidity serves as a powerful tool for defining the outputs of a function. It communicates expectations, ensures clarity, and makes functions reusable and efficient. Whether you’re working with balances, borrowing capacities, or auction bids, understanding how to use return types effectively is key to writing robust smart contracts.

WHAT IS EQUALITY IN JAVASCRIPT?

Maakai123 — Sun, 30 Jul 2023 12:01:36 +0000

*In this short article, you will understand
1) How to use Equality in JavaScript
2)Understand the basics of Logic operators *

What is Equality and how to use them in JavaScript?

In JavaScript, equality refers to comparing two values to see if they are the same.(==,===)
Do not be confused, when you see const toDay = saturday, in JavaScript this means declaration of variable or assignment and not equality.

JavaScript has two ways of comparing two values

1)Loose Equality Operator ==
The Loose equality operators does type coercion, which means converting a string to a number before comparing them.
'18' == 18, ouput: true
the above means string == number is true

2) Strict Equality (===):
The best way to compare values in JavaScript.
The strict equality operator compares both the values and their types without type coercion (meaning without converting a string to a number).
It returns true only when both sides are exactly true.

example '18' === 18 = false 18=== 18 = true

Examples

const age = '20' a) if(age === 20) console.log(You can drive)

b) if(age == 20) console.log(you can drive)

From the above two if statements (a) is strict so the code will not be executed.

If statement (b) Is Loose, and it supports type coercion which means string '20' is equal to number 20. The you can drive will be executed.

Example 2
a)

const foodNumber = '25' if(foodNumber == 25) console.log('Number 25 is Rice')
output:Number 25 is Rice

The above code will be executed because == converts foodNumber which is a string to a number 25 and immediately compare them.

const foodNumber = 25 if(foodNumber == 25) console.log('Number 25 is Rice')
output:Number 25 is Rice

The above code will also be executed because 25 (number) is equal to 25(number).

Example 3
a)

const foodNumber = '25' if(foodNumber === 25) console.log('Number 25 is Rice')
This code will not be executed
Because foodNumber is a string and === don't support type coercion.

HOW JavaScript WORKS BEHIND THE SCENES SIMPLE EXPLANATION.

Maakai123 — Sun, 16 Jul 2023 08:50:30 +0000

Have you ever wondered how JavaScript works behind the scenes?
This will be the simplest explanation ever.

What is a JavaScript engine or Runtime?

JavaScript engine executes JavaScript code.
Example includes V8 (Use in Google Chrome) and other web browsers.

The JS engine has
1) Call Stack: This is where our code is executed using the execution context

2)Heap: This stores Objects

Javascript codes are compiled or Interpreted or both compiled and interpreted.

Why Compilation and Interpretation?

Since every computer processor only understands 0's and 1's, the computer program needs to be converted into a machine code.

Programs can be converted into machine codes by Compilation or Interpretation

What is Compilation?
A Compiler converts the entire code/program into a machine(0's and 1's) code at once and writes to a binary file that can be executed by a computer.

2)Interpretation:
An Interpreter runs through the source code and executes it line by line. This is slow when compared to a compiler.

Over the years, Javascript has been referred to as an interpreter for reading codes line by line.
Since the introduction of Modern Javascript, Javascript now uses both a compiler and an interpreter called Just in Time compilation.

Steps Used in JS Engine

When you write a piece of code inside the Js engine, it passes through the following steps.

1)Js engine will parse the code and read it.

2)The code will be parsed into a data structure called the abstract syntax tree(AST)

3)The AST will split up the codes, check for syntax errors, then generate the machine code (0's and 1's)

5)The machine code will be compiled and executed.

Do you enjoy this? Please drop a comment and follow me @maakayjunior

WHAT IS UNISWAP

Maakai123 — Sun, 26 Feb 2023 18:48:48 +0000

Uniswap

Uniswap is a decentralized token exchange protocol built on Ethereum that allows the direct swapping of tokens without the need to use a centralized exchange.

On Uniswap, you can simply swap your tokens directly from your wallet without depositing tokens to an exchange, place an order on the order book, and then withdraw the swapped tokens as it is in the case of Centralized Exchanges.

All you need to do is send your tokens from your wallet to Uniswap’s smart contract address, you will receive your desired token in return in your wallet. There is no order book and the token exchange rate is determined algorithmically. All this is achieved via liquidity pools and the automated market maker mechanism.

Liquidity Pools

Liquidity pools are token reserves that sit on Uniswap’s smart contracts and are available for users to exchange tokens with. For example, using the ETHDAI trading pair with 100 ETH and 20,000 DAI in the liquidity reserves, a user that wants to buy ETH using DAI may send 202.02 DAI to the Uniswap smart contract to get 1 ETH in return. Once the swap has taken place, the liquidity pool is left with 99 ETH and 20,202.02 DAI.
If someone buys ETH using DAI, ETH will be removed from the liquidity pool while DAI will be added into the liquidity pool.

What is Automated Market Maker Mechanism

Prices of assets in the pool are algorithmically determined using the Automated Market Maker (AMM) algorithm. AMM works by maintaining a Constant Product based on the amount of liquidity on both sides of the pool.

How to get a token added on Uniswap?

Unlike centralized exchanges, Uniswap as a decentralized exchange does not have a team or gatekeepers to evaluate and decide on which tokens to list. Instead, any ERC-20 token can be listed on Uniswap by anyone and be traded as long as liquidity exists for the given pair. All a user needs to do is interact with the platform to register the new token and a new market will be initialized for this token.

Know about Decentralized Exchanges

Maakai123 — Sun, 26 Feb 2023 18:35:21 +0000

While Centralized Exchanges (CEXs) have plenty of liquidity and allow large trades to happen, it still carries many risks because users do not hold custody of their assets in exchanges, due to the introduction of Decentralized Finance, Decentralized exchanges were developed.

What Decentralized Exchange (Dex): A Dex uses Smart contracts and on-chain transactions to reduce or eliminate the need for an intermediary.
Dex includes, Uniswap, Kyber Network, Curve Finance, dYdX, and SushiSwap.

Types of DEX?

There are two types of DEXs: • Order book-based DEXs • Liquidity pool-based DEXs.

Order book-based DEXs: These types DEXs like dYdX and Deversifi operate similarly to CEXs where users can set buy and sell orders at either their chosen limit prices or at market prices

liquidity pool DEXs:

liquidity pool DEXs such as Uniswap and Balancer let users become the market makers by providing liquidity to a pair or pool of assets. Users deposit their assets and become liquidity providers, earning a small fee for each swap transaction performed for that particular pool.

Differences between Centralized Exchanges and Decentralized Exchanges

The main difference between the two is that for CEXs, assets for the trade would be
held on the exchanges’ wallets, whereas for DEXs, assets for the trade would be held in users’ wallets.

Limitations of Dex

Lower liquidity:

The majority of crypto trade still takes place in centralized exchanges. Historically, order books on CEXs have been deeper when compared to DEXs, and traders can thus get better prices when making trades on CEXs.

Limited features Centralized exchanges include many advanced trading features such as limit orders, stop-loss orders, trailing stops, and so on. Most of these trading features are not available on DEXs.
Some DEXs now offer limit orders, allowing for a better trading experience. However, a growing number of DEXs are looking to introduce these advanced trading features to compete more effectively against CEXs.

Blockchain Interoperability Most DEXs today only allow traders to swap tokens within the same blockchain ecosystem. Ethereum-based DEXs, for example, only allow users to trade Ethereum and ERC-20 tokens. It does not permit traders to trade tokens issued on other blockchains like Polkadot or Cosmos. CEXs allows users to trade tokens on various blockchains easily. There are efforts to build cross-chain DEXs, and in the future, trading tokens across multiple blockchains on a DEX will be possible.

What is DAI in Defi?

Maakai123 — Mon, 13 Feb 2023 19:54:03 +0000

What is Dai

Dai is a decentralized stablecoin that is equivalent to 1 dollar, the stablecoin is maintained by Maker, they keep Dail at $1 using a system of collateral and price feeds.

Due to the high volatility in the crypto market, stablecoins were introduced to help save user funds.
DAI is the world’s first stablecoin that does not require a bank.

How is Dai created?

For a user to create Dai, he/she needs to deposit some Ether in Makers smart contract, it lets users take out loans in Dai.

A user can create 66 Dai from an ether valued at $100 and a collateralization ratio of 150%.
Each 100 Dai is created by 1.5 ether.
If the value of ether held as collateral is worth less than the amount of Dai it’s supposed to be backing, then Dai would not be worth one dollar and the system could collapse.

In a case where the price of ether crashes well below the collateralization ratio, to avoid liquidation, Maker stablecoins come in to salvage the situation.

What is Maker stable coin?

Maker stable coin or maker coin (MKR) is a token on the Ethereum blockchain that has governance rights over Maker smart contracts.

How does Maker help sustain Dai?

Should the collateral in the system not be enough to cover the amount of Dai in existence, MKR is created and sold onto the open market in order to raise the additional collateral. This provides a strong incentive for MKR holders to responsibly regulate the parameters at which CDPs can create Dai,

follow me on Twitter https://twitter.com/cz_binance_HJ4J

Why stable coins in Defi

Maakai123 — Fri, 10 Feb 2023 13:35:29 +0000

Cryptocurrencies are well known for their high volatility, they can change in price easily, in order to protect user funds from this fluctuation in market price, Stablecoins were created.

What is a Stable Coin?

A stablecoin is a type of cryptocurrency that is pegged to other stable assets like US Dollars.

Stablecoins maintain this peg through reserves of dollars, other cryptos, or a mix of both kept in U.S-controlled bank accounts.

Use cases of Stablecoins.

Apart from being used as a hedge (protection) against crypto market volatility, they are also used for generating passive income through staking or lending.

Types of some popular stablecoins

1) Tether (USDT),
2) USD
3) USDC
4) Euro Coin (EUROC)
5) Binance Dollar(BUSD)

How are Stablecoins maintained?

Stablecoins are maintained by 3 major methods.

1) Fiat or commodity-backed stablecoins.

In this method, all stablecoins in circulation are backed by an equivalent of the value in fiat currency or cash equivalents, 1 USD equivalent is held on reserve in U.S bank accounts owned by the issuer, and monthly these reserves are audited.
for example USDT

Tether is a centralized, fiat-collateralized stablecoin.

2) Cryptocurrency-backed stablecoins.

This method is also known as The decentralized method
It involves pegging stablecoins through crypto-collateralization.
Stablecoins are backed by reserves of other cryptocurrencies.

Due to the fluctuation of the crypto market, stablecoins are usually overcollateralized to help maintain the peg.
for example, Dai which is a decentralized stablecoin is collateralized at 150%, every 1 Dai in circulation is backed by 1.5x its equivalent value in Ethereum.

3) Algorithm-backed statblecoins

These are stablecoins pegged through smart contracts that automatically execute to manipulate the circulating supply depending on market conditions.