In the past three years, more than four billion dollars' worth of assets have been stolen due to on - chain vulnerabilities. These losses have become one of the biggest obstacles to the mainstream adoption of decentralized applications (DApps). The main reason is that the cost of implementing security measures for smart contracts on Ethereum is very high. While minimizing users' gas fees, Ethereum developers often face a difficult trade - off as they have to give up some additional security checks.

Some common gas - optimization methods include:
Limiting the use of defensive assertions and only including code that is crucial to the application's functionality. Defensive assertions are vital for maintaining invariants, especially when the code is upgraded.
Using some counter - intuitive techniques to save gas, although these techniques sacrifice readability. For example, making any function payable, using mappings instead of arrays, and avoiding the use of libraries all make the code harder to understand and increase the probability of errors during upgrades.
Using shortcuts that reduce on - chain interactions, while a more interactive design might offer better security. For instance, the original ERC - 20 design was for users to approve a specific amount of tokens for an application, but in reality, most front - ends request unlimited approval, partly to avoid users paying gas fees repeatedly.

Approximately 25 billion dollars' worth of value exists on Ethereum in the form of ERC - 20 tokens and NFTs, making the security risks of smart contracts extremely high. Monad, however, significantly reduces gas costs, making most of the current gas - optimization methods unnecessary, thus allowing developers to focus on building the best version of their applications.

In Ethereum, each opcode (operation code) consumes a certain amount of computational units, known as Gas. The more calculations, the more Gas is consumed. When a user calls a function in a smart contract, they need to pay for the Gas consumed by the opcodes in that function.
Due to the extremely limited computational resources on Ethereum, the cost of each operation is very high. Therefore, reducing the number of operations without affecting functionality is crucial for reducing user costs. These optimizations can take various forms, but each comes with some potential risks.

Experienced developers add defensive assertions to smart contracts to prevent unexpected situations. As the name implies, defensive assertions are a way to encode expected behavior into the contract's logic, ensuring that certain conditions are always true. For example, if an internal variable is expected to always be non - negative, a developer can write code like require(var >= 0, 'encountered negative var') to ensure that if this condition is not met, the transaction will be rolled back. This effectively defends against attacks that exploit unexpected situations.
In the DeFi field, many fatal vulnerabilities are caused by reentrancy attacks. In a reentrancy attack, the smart contract enters an unexpected state, usually after being recursively called by a cleverly constructed contract, and then exploits a logical error for the attack. The core of a reentrancy attack is that the contract enters an incorrect state without being aware of it. Through defensive assertions, the "awareness" of this incorrect state can be achieved, and the transaction can be rolled back in time when an error occurs.
The role of defensive assertions is not limited to preventing reentrancy attacks but also avoiding some common low - level errors. For example, a common mistake is sending tokens to the Wrapped Ether (WETH) contract, causing the tokens to be permanently stuck. Although there are often discussions about adding extra checks to prevent this error, these checks will increase additional gas fees, which is a significant burden for users who do not encounter errors.
Overall, defensive assertions are an effective security measure that helps developers avoid common vulnerabilities and errors, ensuring that the contract's logic always executes as expected. Although it increases gas costs, in the case of ensuring contract security and preventing major vulnerabilities, such an expense is worthwhile. (https://x.com/YannickCrypto/status/1487837906538483715)
On the WETH contract alone, more than one million dollars' worth of assets have been lost due to the lack of these protective measures.

There are some clever techniques to save gas, although these practices may sacrifice code readability. Here are some examples:
Marking a function as "payable" (even if the function is not intended to receive Ether) to reduce gas consumption: (https://x.com/Mudit__Gupta/status/1482643410834300931)(https://x.com/samczsun/status/1469477928350240771)
Using Assembly: (https://x.com/0xkkeon/status/1567254237171847168)
Avoiding the use of external libraries: (https://x.com/Mudit__Gupta/status/1474015257945264128)
🔗 More clever optimization techniques: https://github.com/0xKitsune/EVM - Gas - Optimizationshttps://github.com/ControlCplusControlV/Yul - Optimization - Tips
Readability improves understanding, and understanding enhances security. Team members and auditors need to be able to easily understand the code so that they can identify vulnerabilities and avoid introducing errors when making subsequent modifications. (https://x.com/stonecoldpat0/status/1149971603536666625)(https://x.com/nassyweazy/status/1569399374924374026)

In some cases, developers deliberately choose insecure practices for gas efficiency.
ERC - 20 authorization is a good example. The original ERC - 20 specification requires users to authorize a specific amount of tokens for an application so that the application can only spend the expected amount. But in reality, most front - ends request unlimited authorization, partly to avoid users paying gas fees repeatedly. If the deployer of the application is compromised, attackers can directly withdraw funds from the wallets of users who gave these authorizations.
Another example is that Solidity provides SafeMath, which is used to check for overflows and underflows. A popular "trick" is to disable these security checks to save some gas: (https://x.com/KhanAbbas201/status/1627907758409527297)(https://x.com/bantg/status/1488660866547556354)
Security practices are necessary, but in the current state of Ethereum, bypassing these practices does save gas.

Due to the high computational cost, application developers currently have to make a trade - off between security and cost. For applications that are both secure and inexpensive, the simplest way is to significantly reduce the computational cost. Allowing developers to write code without having to be overly frugal is a simple but often overlooked need, and this has not been overlooked in Monad. (https://x.com/fubuloubu/status/1623301907866320897)(https://x.com/LefterisJP/status/998693893918117889)(https://x.com/maurelian_/status/1492307405815824385)
Monad is creating an environment for developers where they don't have to compromise. The path to welcoming the next billion users will require applications that are both secure and easy to use; and building these applications on Monad is the best choice.

In the past three years, more than four billion dollars' worth of assets have been stolen due to on - chain vulnerabilities. These losses have become one of the biggest obstacles to the mainstream adoption of decentralized applications (DApps). The main reason is that the cost of implementing security measures for smart contracts on Ethereum is very high. While minimizing users' gas fees, Ethereum developers often face a difficult trade - off as they have to give up some additional security checks.

Some common gas - optimization methods include:
Limiting the use of defensive assertions and only including code that is crucial to the application's functionality. Defensive assertions are vital for maintaining invariants, especially when the code is upgraded.
Using some counter - intuitive techniques to save gas, although these techniques sacrifice readability. For example, making any function payable, using mappings instead of arrays, and avoiding the use of libraries all make the code harder to understand and increase the probability of errors during upgrades.
Using shortcuts that reduce on - chain interactions, while a more interactive design might offer better security. For instance, the original ERC - 20 design was for users to approve a specific amount of tokens for an application, but in reality, most front - ends request unlimited approval, partly to avoid users paying gas fees repeatedly.

Approximately 25 billion dollars' worth of value exists on Ethereum in the form of ERC - 20 tokens and NFTs, making the security risks of smart contracts extremely high. Monad, however, significantly reduces gas costs, making most of the current gas - optimization methods unnecessary, thus allowing developers to focus on building the best version of their applications.

In Ethereum, each opcode (operation code) consumes a certain amount of computational units, known as Gas. The more calculations, the more Gas is consumed. When a user calls a function in a smart contract, they need to pay for the Gas consumed by the opcodes in that function.
Due to the extremely limited computational resources on Ethereum, the cost of each operation is very high. Therefore, reducing the number of operations without affecting functionality is crucial for reducing user costs. These optimizations can take various forms, but each comes with some potential risks.

Experienced developers add defensive assertions to smart contracts to prevent unexpected situations. As the name implies, defensive assertions are a way to encode expected behavior into the contract's logic, ensuring that certain conditions are always true. For example, if an internal variable is expected to always be non - negative, a developer can write code like require(var >= 0, 'encountered negative var') to ensure that if this condition is not met, the transaction will be rolled back. This effectively defends against attacks that exploit unexpected situations.
In the DeFi field, many fatal vulnerabilities are caused by reentrancy attacks. In a reentrancy attack, the smart contract enters an unexpected state, usually after being recursively called by a cleverly constructed contract, and then exploits a logical error for the attack. The core of a reentrancy attack is that the contract enters an incorrect state without being aware of it. Through defensive assertions, the "awareness" of this incorrect state can be achieved, and the transaction can be rolled back in time when an error occurs.
The role of defensive assertions is not limited to preventing reentrancy attacks but also avoiding some common low - level errors. For example, a common mistake is sending tokens to the Wrapped Ether (WETH) contract, causing the tokens to be permanently stuck. Although there are often discussions about adding extra checks to prevent this error, these checks will increase additional gas fees, which is a significant burden for users who do not encounter errors.
Overall, defensive assertions are an effective security measure that helps developers avoid common vulnerabilities and errors, ensuring that the contract's logic always executes as expected. Although it increases gas costs, in the case of ensuring contract security and preventing major vulnerabilities, such an expense is worthwhile. (https://x.com/YannickCrypto/status/1487837906538483715)
On the WETH contract alone, more than one million dollars' worth of assets have been lost due to the lack of these protective measures.

There are some clever techniques to save gas, although these practices may sacrifice code readability. Here are some examples:
Marking a function as "payable" (even if the function is not intended to receive Ether) to reduce gas consumption: (https://x.com/Mudit__Gupta/status/1482643410834300931)(https://x.com/samczsun/status/1469477928350240771)
Using Assembly: (https://x.com/0xkkeon/status/1567254237171847168)
Avoiding the use of external libraries: (https://x.com/Mudit__Gupta/status/1474015257945264128)
🔗 More clever optimization techniques: https://github.com/0xKitsune/EVM - Gas - Optimizationshttps://github.com/ControlCplusControlV/Yul - Optimization - Tips
Readability improves understanding, and understanding enhances security. Team members and auditors need to be able to easily understand the code so that they can identify vulnerabilities and avoid introducing errors when making subsequent modifications. (https://x.com/stonecoldpat0/status/1149971603536666625)(https://x.com/nassyweazy/status/1569399374924374026)

In some cases, developers deliberately choose insecure practices for gas efficiency.
ERC - 20 authorization is a good example. The original ERC - 20 specification requires users to authorize a specific amount of tokens for an application so that the application can only spend the expected amount. But in reality, most front - ends request unlimited authorization, partly to avoid users paying gas fees repeatedly. If the deployer of the application is compromised, attackers can directly withdraw funds from the wallets of users who gave these authorizations.
Another example is that Solidity provides SafeMath, which is used to check for overflows and underflows. A popular "trick" is to disable these security checks to save some gas: (https://x.com/KhanAbbas201/status/1627907758409527297)(https://x.com/bantg/status/1488660866547556354)
Security practices are necessary, but in the current state of Ethereum, bypassing these practices does save gas.

Due to the high computational cost, application developers currently have to make a trade - off between security and cost. For applications that are both secure and inexpensive, the simplest way is to significantly reduce the computational cost. Allowing developers to write code without having to be overly frugal is a simple but often overlooked need, and this has not been overlooked in Monad. (https://x.com/fubuloubu/status/1623301907866320897)(https://x.com/LefterisJP/status/998693893918117889)(https://x.com/maurelian_/status/1492307405815824385)
Monad is creating an environment for developers where they don't have to compromise. The path to welcoming the next billion users will require applications that are both secure and easy to use; and building these applications on Monad is the best choice.