address public ownerOne;
address public immutable ownerTwo;
address public constant ownerThree;

Let’s look at their differences:

• constant: If you use this keyword, you can’t change the state variable in the contract. You have to define the variable hard-coded.

• immutable: If you use this keyword, you have to define the variable in the constructor. After than, you can’t change its value. As you can see it’s very similar to constant.

• If you don’t specify anything, the mutability of the variable will be mutable. You can change its value wherever you want.

You can say “Why would I use constant or immutable”. Freedom has a price.

If you say “I don’t want to use them, I want to be free while I write the contract”, you’ll both fuck your user’s wallet and your wallet.

Here are the test results:

As you can see, there is a big difference in the deployment phase. You can save 51.517 gas by using constants than using mutable variables. You can check the contracts and the test file that I used here.

Give attention to contract call costs. Constant and immutable used the same amount of gas. So, using constant instead of immutable, saves money on your pocket, not from users’.

If you don’t use constant or immutable while you can, your users will pay nearly 5% more for every call!

Don’t screw your users.

You can think “of course it should revert, there is no contract”. But this would be wrong. Those functions return a boolean. If you said, “Oh, okay! So, we’ll get a false”, you’ll be wrong. Because when you call a non-existent contract with those functions, you’ll get a true. This is how EVM works.

Let’s try it with hands-on experience. Here is a contract to try them:

// SPDX-License-Identifier: GPL-3.0
pragma solidity 0.8.15;

contract DarkForest {
    function callWithCall() external returns (bool res) {
        (res, ) = address(1).call(abi.encodeWithSignature("transfer(address,uint256)", msg.sender, 5 ether));
    }

    function callWithDelegatecall() external returns(bool res) {
        (res, ) = address(1).delegatecall(abi.encodeWithSignature("transfer(address,uint256)", msg.sender, 5 ether));
    }

    function callWithStaticcall() external view returns(bool res) {
        (res, ) = address(1).staticcall(abi.encodeWithSignature("transfer(address,uint256)", msg.sender, 5 ether));
    }
}

You can use this contract in remix and you’ll see the results. It doesn’t matter which network you’ve tried (at least most of them). Because probably there is no contract with the 0x0000000000000000000000000000000000000001 address if they don’t have a pre-compiled contract with that address. So basically you can use this contract in your localhost.

You’ll see you are getting a true when you call those functions. But there is no contract with 0x0000000000000000000000000000000000000001 this address.

External calls are so important in Solidity. You have to use them very carefully. This is just an example of bad cases when you are using an external call.

Prevention Technique

If you have to call an external contract that you don’t trust then you have to check if there is a contract with the given address.

In Solidity, we can check an address’ code length. If the code length is greater than 0, it means that address is a contract. So, let’s add our new security method to our contract:

// SPDX-License-Identifier: GPL-3.0
pragma solidity 0.8.15;

contract DarkForest {
    function callWithCall() external returns (bool res) {
        require(address(1).code.length > 0, "non-existent contract");

        (res, ) = address(1).call(abi.encodeWithSignature("transfer(address,uint256)", msg.sender, 5 ether));
    }

    function callWithDelegatecall() external returns(bool res) {
        require(address(1).code.length > 0, "non-existent contract");

        (res, ) = address(1).delegatecall(abi.encodeWithSignature("transfer(address,uint256)", msg.sender, 5 ether));
    }

    function callWithStaticcall() external view returns(bool res) {
        require(address(1).code.length > 0, "non-existent contract");

        (res, ) = address(1).staticcall(abi.encodeWithSignature("transfer(address,uint256)", msg.sender, 5 ether));
    }
}

With the require(address(1).code.length > 0, "non-existent contract"); line, we can determine if the address is a contract. Now you can try to call those functions. You’ll get an error. But are we totally safe right now?

In the constructor, contracts don’t have any code yet. So, a hacker can call our function in a constructor to get what he wants. We don’t want this to happen. We’ll add another layer for security:

// SPDX-License-Identifier: GPL-3.0
pragma solidity 0.8.15;

contract DarkForest {
    function callWithCall() external returns (bool res) {
        require(msg.sender == tx.origin, "only eoas");
        require(address(1).code.length > 0, "non-existent contract");

        (res, ) = address(1).call(abi.encodeWithSignature("transfer(address,uint256)", msg.sender, 5 ether));
    }

    function callWithDelegatecall() external returns(bool res) {
        require(msg.sender == tx.origin, "only eoas");
        require(address(1).code.length > 0, "non-existent contract");

        (res, ) = address(1).delegatecall(abi.encodeWithSignature("transfer(address,uint256)", msg.sender, 5 ether));
    }

    function callWithStaticcall() external view returns(bool res) {
        require(msg.sender == tx.origin, "only eoas");
        require(address(1).code.length > 0, "non-existent contract");

        (res, ) = address(1).staticcall(abi.encodeWithSignature("transfer(address,uint256)", msg.sender, 5 ether));
    }
}

The require(msg.sender == tx.origin, "only eoas"); line be sure the caller is an EOA.

One last thing: Now we can safely make an external call safely. But, we don’t check the result. So, if there is an error in the external call our transaction doesn’t bubble up the error. Usually, we don’t want this to happen. We can protect ourselves by adding this line to the end of our functions: require(res, "failed external call"); .

Now we are safe. Here is the latest code:

// SPDX-License-Identifier: GPL-3.0
pragma solidity 0.8.15;

contract DarkForest {
    function callWithCall() external returns (bool res) {
        require(msg.sender == tx.origin, "only eoas");
        require(address(1).code.length > 0, "non-existent contract");

        (res, ) = address(1).call(abi.encodeWithSignature("transfer(address,uint256)", msg.sender, 5 ether));
        require(res, "failed external call");
    }

    function callWithDelegatecall() external returns(bool res) {
        require(msg.sender == tx.origin, "only eoas");
        require(address(1).code.length > 0, "non-existent contract");

        (res, ) = address(1).delegatecall(abi.encodeWithSignature("transfer(address,uint256)", msg.sender, 5 ether));
        require(res, "failed external call");
    }

    function callWithStaticcall() external view returns(bool res) {
        require(msg.sender == tx.origin, "only eoas");
        require(address(1).code.length > 0, "non-existent contract");

        (res, ) = address(1).staticcall(abi.encodeWithSignature("transfer(address,uint256)", msg.sender, 5 ether));
        require(res, "failed external call");
    }
}

State Variables

At the beginning of our contract, we have two state variables:

bytes16 private constant _HEX_SYMBOLS = "0123456789abcdef";
uint8 private constant _ADDRESS_LENGTH = 20;

We will use these variables in our toHexString functions.

toString() function

This function Converts a uint256 to its ASCII string decimal representation.

First of all, let’s look at the function signature:

function toString(uint256 value) internal pure returns (string memory)

• It takes an uint256 parameter.

• It’s an internal function. So, it can only be accessible in the String contract itself, or a contract inherited from the String contract.

• It’s a pure function. That means it doesn’t read or write from the state.

• And lastly, it returns a string.

The method we used in this function does not work with the number 0. So, if the input number is zero, return ”0”:

if (value == 0) {
  return "0";
}

Next, we are saving our input variable to another variable. We’ll divide it by 10 continuously. Because we want to get how many digits is the input variable and we don’t want to lose the value.

uint256 temp = value;
uint256 digits;

while (temp != 0) {
  digits++;
  temp /= 10;
}

Let’s assume that we sent 100,042 to this function. Now, temp is equal to 0 , and digits is equal to 6.

Now, we are going to create a bytes variable and insert the bytes one by one to it:

bytes memory buffer = new bytes(digits);
while (value != 0) {
  digits -= 1;
  buffer[digits] = bytes1(uint8(48 + uint256(value % 10)));
  value /= 10;
}
return string(buffer);

At the beginning buffer is equal to 0x000000000000. And in every loop it changes these:

• 0x000000000032

• 0x000000003432

• 0x000000303432

• 0x000030303432

• 0x003030303432

• 0x313030303432

If you convert every byte to ASCII, you can get 0 for 0x30, 1 for 31, 2 for 32, etc. 30 to 40 are the numbers 0 to 9.

Let’s break down the confusing line:

• value % 10 is for getting the least important number.

• uint8(48 + uint256(value % 10)) nothing much different. Just type conversion to be able to use bytes1 without losing data.

• bytes1(uint8(48 + uint256(value % 10))) now we can add the resulting number to our buffer .

Let’s run the first loop to understand what is going on in this line:

• value % 10 gives us 2. I am not going to explain to you “what is mod” here. If you don’t know how we are getting 2 from 100,042 % 10 , then just google “what is mod in programming”.

• uint8(48 + uint256(value % 10)) gives us 50. You can think: “what the hell is this number?”. And you’ll be right. They used this, because, we are going to use hexadecimal numbers. If you convert 50 to hexadecimal, you’ll get 32. And 32 is equal to 2 in the ASCII table. Wow! What a conversion, hah?

• bytes1(uint8(48 + uint256(value % 10))) conversion is required for our buffer , which is a bytes variable.

Lastly, we are converting our bytes to string. I love this part. Because if you want to get to result in uint, the result is will be a totally different thing. But, we are telling “convert it to string, I want to see its corresponding value in the ASCII table”.

toHexString() function

Before we go deep dive into this function, you have to know that: there are 3 different toHexString functions in this library. If you don’t know function overloading, you might be thinking “how can they use 3 functions with the same name?”. So, it’ll be better for you to check out function overloading before continuing this article.

Let’s look at our three functions:

function toHexString(uint256 value, uint256 length) internal pure returns (string memory)

function toHexString(uint256 value) internal pure returns (string memory)

function toHexString(address addr) internal pure returns (string memory)

As you can see, they have the same name, but, they all have a different kinds of parameters. Because of that, their function selectors are different. So, EVM is good with that.

Please think the functions in order. For example, the number 1, the first function, is the function that takes two uint256 parameters.

But, you should know that: the second and third functions are calling the first function. It means if you call the second or the third function, your input values are going to the first function at the end of the day.

Enough for talking. Let’s look at the third function’s code:

return toHexString(uint256(uint160(addr)), _ADDRESS_LENGTH);

It has only one line of code. And it is converting our address input variable to uint256. And, send the result with _ADDRESS_LENGTH, which is 20, to our first function.

Let’s convert my address,0x000000000042bAA586DD7161dC0EB8f0CB4a9fBE , to uint256: 346477235235092042596196240046333886 we’ll get this huge number.

We’ll look at the other steps in a minute when we are talking about the first function.

Okay, now time for our second function. If the input value is 0, then we are returning ”0x00”.

if (value == 0) {
  return "0x00";
}

If it is not zero, then we are going to calculate it’s length:

uint256 temp = value;
uint256 length = 0;
while (temp != 0) {
  length++;
  temp >>= 8;
}

I think only the temp >>= 8; line is confusing. Let’s again send to this function our 100,042 number and see what happens in our loop:

• In our first loop length will be 1 and the temp is 390. What? Ok. Now we have to go to the dark side of coding: the binary world. 100,042 in binary is equal to 11000011011001010 and 390 is equal to 110000110 . Did you notice the similarity between to binaries? Their first (start from left) 8 digits are equal. >> means shift bits to right. If you used << this one, the result will be: 25610752 and its binary is 1100001101100101000000000 . Okay, I believe now things are more clear. >> deletes bits, << adds zero to binary. I think we can think like that. So, our loop basically calculates the length of our value in bytes (8 bits are equal to 1 byte). We will use the length of this byte in our first function. Let’s go on to other steps.

• temp’s value was 110000110 . So, we can delete the least significant 8 bits by our hand (last 8 bits). If we delete them here we have binary 1, it is equal to decimal 1. And length is equal to 2 now.

• This is the last step for our value. Because in this step our value is going to equal to 0. And while loop not going to run anymore. In this step temp is equal 0 and length is equal to 3. Now, we are sending 100,042 and length to the first function.

So far so good! Only one function is left, the first function. It starts with defining a bytes variable named buffer and its length is equal to 2 * length + 2. Why is that? It is because every 2 hexadecimal characters are equal to 1 byte. For example, if you want to convert byte 0 to hexadecimal, you'll have 0x00. Since we are returning a string, we don’t actually have 0x at the beginning. So, we have to add it manually. I think you got why we are adding 2 to our length, it is because of 0x.

bytes memory buffer = new bytes(2 * length + 2);
buffer[0] = "0";
buffer[1] = "x";

After than, we are going to determine all of our hexadecimal values one by one.

for (uint256 i = 2 * length + 1; i > 1; --i) {
  buffer[i] = _HEX_SYMBOLS[value & 0xf];
  value >>= 4;
}

We have sent to this function to value, do you remember? One is (100042, 3) and the other one is (0x000000000042bAA586DD7161dC0EB8f0CB4a9fBE, 20) . Let’s run them step-by-step. First (100042, 3) :

• In this step, we are going to determine value & 0xf first. It is a bitwise AND operation. We want to get the last 4 bits We sent 100042 , in binary 11000011011001010. So, value & 0xf gives us 1010, which is equal to decimal 10. 10th item in the _HEX_SYMBOLS list is equal to a. After then we are deleting the least significant 4 bits from value. And now we have 1100001101100 , which is equal to decimal 6252. buffer is equal to 0x3078000000000061. The first 2 bytes 3078 are coming from 0x that we add before the loop. Do you remember 30 is equal to 0 in the ASCII table, right? The same goes with the x and a. 78 is equal to x in the ASCII table. If you convert the buffer to string, you’ll get 0xa.

• Now we are operating 1100001101100 & 0xf which gives us decimal 12 and hexadecimal c. Buffer is equal to 0x3078000000006361, in string 0xca.

• Our number is 110000110 . Again, delete the least significant 4 bits and run the operation bitwise AND. It gives us 0110. Buffer is equal to 0x3078000000366361 , in string 0x6ca.

• Our number is 11000 . In this step, we are getting 8 . Now temp is equal to 1. Buffer is 0x3078000038366361, in string 0x86ca .

• We get 1 in binary in this step. And it gives us hexadecimal 1. temp is 0. Buffer is 0x3078003138366361, in string 0x186ca .

• temp was equal to. Because of that, we are getting a 0 in hexadecimal. Buffer is equal to 0x3078303138366361 , in string 0x0186ca . And this was the last step.

We gave (100042, 3) to this function and it returned 0x0186ca. You can convert these numbers using an online converter and you’ll see the result is true.

Conclusion

I said I also inspect the 346477235235092042596196240046333886 and 20 . But I am not a computer, I am bored doing the same thing over and over. So, you can do it by yourself. Here is the full code of the library that I inspect. I am sharing it because, in the future, it can be changed:

// SPDX-License-Identifier: MIT
// OpenZeppelin Contracts v4.4.1 (utils/Strings.sol)

pragma solidity ^0.8.0;

/**
 * @dev String operations.
 */
library Strings {
    bytes16 private constant _HEX_SYMBOLS = "0123456789abcdef";
    uint8 private constant _ADDRESS_LENGTH = 20;

    /**
     * @dev Converts a `uint256` to its ASCII `string` decimal representation.
     */
    function toString(uint256 value) internal pure returns (string memory) {
        // Inspired by OraclizeAPI's implementation - MIT licence
        // https://github.com/oraclize/ethereum-api/blob/b42146b063c7d6ee1358846c198246239e9360e8/oraclizeAPI_0.4.25.sol

        if (value == 0) {
            return "0";
        }
        uint256 temp = value;
        uint256 digits;
        while (temp != 0) {
            digits++;
            temp /= 10;
        }
        bytes memory buffer = new bytes(digits);
        while (value != 0) {
            digits -= 1;
            buffer[digits] = bytes1(uint8(48 + uint256(value % 10)));
            value /= 10;
        }
        return string(buffer);
    }

    /**
     * @dev Converts a `uint256` to its ASCII `string` hexadecimal representation.
     */
    function toHexString(uint256 value) internal pure returns (string memory) {
        if (value == 0) {
            return "0x00";
        }
        uint256 temp = value;
        uint256 length = 0;
        while (temp != 0) {
            length++;
            temp >>= 8;
        }
        return toHexString(value, length);
    }

    /**
     * @dev Converts a `uint256` to its ASCII `string` hexadecimal representation with fixed length.
     */
    function toHexString(uint256 value, uint256 length) internal pure returns (string memory) {
        bytes memory buffer = new bytes(2 * length + 2);
        buffer[0] = "0";
        buffer[1] = "x";
        for (uint256 i = 2 * length + 1; i > 1; --i) {
            buffer[i] = _HEX_SYMBOLS[value & 0xf];
            value >>= 4;
        }
        require(value == 0, "Strings: hex length insufficient");
        return string(buffer);
    }

    /**
     * @dev Converts an `address` with fixed length of 20 bytes to its not checksummed ASCII `string` hexadecimal representation.
     */
    function toHexString(address addr) internal pure returns (string memory) {
        return toHexString(uint256(uint160(addr)), _ADDRESS_LENGTH);
    }
}

Unlike banks where interest rates are fixed, Compound interest works in a dynamic fashion. The Compound interest keeps changing depending on the balance of a particular liquidity pool. When the total amount of crypto in a liquidity pool is abundantly available, the annual interest is low for lending. However, for a smaller pool with a lesser balance, the Compound Annual Growth Rate is high.

Similarly, the interest rate for borrowing from a larger pool is less since there is sufficient money to borrow. On the contrary, the interest rate is higher when someone borrows from a small liquidity pool.

The principal amount is compounded daily so that your money witnesses exponential growth at an incredibly faster rate. In banks, your savings are locked in for long periods that can be as long as nine years. With the DeFi protocol’s daily compounding interest, you don’t need to wait so long.

In fact, the compounding period is as small as a few seconds. Although the interest rate is displayed for annual terms, Compounding periods are as low as one Ethereum block mine time.

The obvious advantage of such short Compounding periods is that you will be earning interest on a daily compounding basis. This means you don’t need to wait for monthly interests. With a floating interest rate, the returns on your initial investment will also be significantly higher. Overall, compounding interest on your starting amount will give you larger returns on your money.

There are two main contracts in Compound: cToken and Comptroller. Let’s start by exploring them.

The Comptroller

The Comptroller is the risk management layer of the Compound protocol; it determines how much collateral a user is required to maintain, and whether (and by how much) a user can be liquidated. Each time a user interacts with a cToken, the Comptroller is asked to approve or deny the transaction.

As you can understand from its name, The Comptroller is the controller of The Compound. It adds, removes, starts, pauses, etc. cTokens. It is the guardian, accounter, and manager of The Compound. It’s kinda Uniswap v2’s router + factory + some extra shit.

Also, it is upgradable. With the governance token, the community can upgrade the comptroller.

Some of the functions that the Comptroller has:

• enterMarkets: In order to supply collateral or borrow in a market, it must be entered first. So with this function, you can enter any market you want. It takes an address list. This list contains the markets (cTokens) that you want to enter.

• exitMarket: Exited markets will not count towards account liquidity calculations. It takes one address as a parameter.

cToken

In Compound if you have some cTokens (cAAVE, cDAI, etc.), that means you have some rights over Compound. Some of the underlying assets of cToken belong to you. You can get it whenever you want.

cTokens are represents the underlying assets. For example, cAAVE represents the AAVE. But they are not 1-1. All cTokens has exchange rate. It is equal to 0.02 at the beginning but it will increase buy time.

Let’s say you supply 1,000 DAI to the Compound protocol, when the exchange rate is 0.020070; you would receive 49,825.61 cDAI (1,000/0.020070).

A few months later, you decide it’s time to withdraw your DAI from the protocol; the exchange rate is now 0.021591:

• Your 49,825.61 cDAI is now equal to 1,075.78 DAI (49,825.61 * 0.021591)

• You could withdraw 1,075.78 DAI, which would redeem all 49,825.61 cDAI

• Or, you could withdraw a portion, such as your original 1,000 DAI, which would redeem 46,315.59 cDAI (keeping 3,510.01 cDAI in your wallet)

Some of the functions that cTokens have:

• mint: The mint function transfers an asset into the protocol, which begins accumulating interest based on the current supply rate for the asset. The user receives a quantity of cTokens equal to the underlying tokens supplied, divided by the current exchange rate.

• redeem: The redeem function converts a specified quantity of cTokens into the underlying asset, and returns them to the user. The amount of underlying tokens received is equal to the quantity of cTokens redeemed, multiplied by the current exchange rate. The amount redeemed must be less than the user's account liquidity and the market's available liquidity.

• borrow: The borrow function transfers an asset from the protocol to the user, and creates a borrow balance which begins accumulating interest based on the borrow rate for the asset. The amount borrowed must be less than the user's account liquidity and the market's available liquidity.

• repay borrow: The repay function transfers an asset into the protocol, reducing the user's borrow balance.

• liquidate borrow: A user who has negative account liquidity is subject to liquidation by other users of the protocol to return his/her account liquidity back to positive (i.e. above the collateral requirement). When a liquidation occurs, a liquidator may repay some or all of an outstanding borrow on behalf of a borrower and in return receive a discounted amount of collateral held by the borrower; this discount is defined as the liquidation incentive.

References

https://compound.finance/docs

At the most basic level, Compound is an autonomous protocol that calculates interest rates using algorithms. It is permissionless, meaning anyone can access the tools provided at any time. There is no verification process and no user identification mechanism.

For individuals, Compound is primarily used as a cryptocurrency borrowing and lending protocol. Users can deposit one of the supported tokens into a shared pool at any time and receive interest. Or, after depositing their tokens, they can borrow a smaller amount of tokens and pay interest. The amount of interest is determined by the supply and demand of tokens deposited.

There are two main actors in Compound: lenders and borrowers.

Lenders

Lenders deposit or lock their crypto into Compound to earn money at a dynamic annual interest rate. You receive income interest in tokens you lend. Thus, if you lend ETH to Compound, your interest compounds in ETH. Similarly, if you deposit USDT, you will get your compound in USDT.

To lend with this protocol, all you need to do is supply the cryptocurrency that you want to provide liquidity for. Lenders deposit tokens into a liquid fund. Once you do that, you will immediately start earning interest, which is controlled by the supply and demand of the currency.

When lenders put their cryptocurrency in the market, they receive an amount of cToken corresponding to the lend. For example, if you lock USDT in the protocol, you will get cUSDT tokens. These cUSDT tokens can then be used in apps on Ethereum. That way, your locked-up capital isn’t truly locked up like it would be if you were to lend to a borrower in a traditional system.

When a market is launched, the cToken exchange rate (how much ETH one cETH is worth) begins at 0.020000 — and increases at a rate equal to the compounding market interest rate. For example, after one year, the exchange rate might equal 0.021591. Each user has the same cToken exchange rate; there’s nothing unique to your wallet that you have to worry about.

When you need to make use of your cryptocurrency, all you need to do is pay back your cTokens, and you will receive your original tokens in return.

Borrowers

Borrowers can take a loan against their crypto balance in the Compound protocol. When you borrow money from a bank, they usually do a personal finance background check to determine credit ratings. However, Compound is keeping up with DeFi’s promise of anonymity and never inquires about personal finance. Thus, in order to avoid debt and bankruptcy, Compound only offers over-collateralized loans. This means that users who want to borrow have to have collateral that is more than what they want to borrow, that way the lender and the system are exposed to zero risk. The protocol sets a borrowing limit/collateral factor to determine how much a user can borrow. Their deposited amount is also called “borrowing power”. After acquiring that power, they will be able to borrow tokens equivalent to the amount of borrowing power that they have.

Since borrowers take money from the protocol, they need to pay Compound interest on it.

Borrowers should also note that the value of their collateral must remain above a certain value to be viable. If it doesn’t remain above that value, the collateral will be liquidated to pay back the loan. When a user’s collateral enters the liquidation event, other users will have the opportunity to pay the outstanding amount borrowed for a percentage of the collateral of the borrower. To incentivize this purchase, users can buy the collateral for a better price than the market price.

A note on liquidation: many who are wary of this term believe they will lose all of their funds upon liquidation. However, these concerned individuals should realize that they would still have their borrowed funds. For example, if I were to collateralize 100 and borrow 80, if my 100 was liquidated, I would still have 80 (excluding market movements), for a loss of 20, not 100.

The COMP Token

The COMP token is the governance token of Compound. COMP is also the rewards token for Compound’s liquidity mining. Whenever a lender adds cryptocurrencies to Compound’s liquidity pools or borrows from these pools, they get COMP tokens.

What Makes Compound Finance Stand Out

No Need For Negotiations

The great thing about Compound is that it eliminates the need for negotiations. Lenders to the market don’t have to negotiate terms as they would in a regular bank, or even in other DeFi apps.

Lenders and Borrowers only need to interact with the protocol to deposit or borrow cryptocurrency. The entire operation is governed by algorithms. Individuals do not hold the funds. The funds are held in smart contracts. There is no threat of unfair or preferential treatment and no threat of counterparty risk.

It Makes Investing Easier

Lenders aren’t the only ones who benefit from this arrangement. Borrowers who would like to go long on a particular asset can use Compound to do so.

For example, if a trader assumes that the price of ETH can increase exponentially in the long to medium term, he can use his existing ETH as collateral to borrow USDT, which can then be used to buy even more ETH.

If the trader is right, and the increase in their ETH is more than the interest on the USDT they borrowed, they can turn a healthy profit. However, if it doesn’t work out they will still have to repay the loan or be liquidated.

References

https://www.ulam.io/blog/how-compound-protocol-works/

https://thedefiant.io/what-is-compound-crypto/

https://101blockchains.com/compound-protocol/

https://www.kraken.com/tr-tr/learn/what-is-compound-comp

https://decrypt.co/resources/compound-defi-ethereum-explained-guide-how-to

What is X: In those articles, I’ll write what the X project is about and what they want to do in general. Those articles will not be a technical guide. They will appeal to a general audience.

How does the X project works: In those articles, I’ll write more about the X project. Those articles will be a little bit more technical.

Example usage of the X project: After writing general and technical articles, I’ll write some codes about the X project. Because I’m not a writer, I’m a developer. But, I’ll not explain every row. I just write a little paragraph about the code. If you want to learn more about the code, you should look at the code in depth.

Here is my plan. So, let’s BUIDL!