Gas Optimization Basics for Smart Contract Developers

Every operation in a smart contract costs gas, and users pay for it. On expensive networks, inefficient contracts make apps costly to use. On low-fee networks, gas still matters for high-frequency actions and for staying within block limits. Good gas optimisation reduces costs without sacrificing security or readability.

Storage is the biggest cost

Writing to contract storage is one of the most expensive operations. Reading storage costs less but still adds up. Most meaningful savings come from reducing storage writes.

Techniques include:

• Avoid storing values that can be computed from other data
• Update storage once at the end of a function rather than repeatedly
• Use memory variables for intermediate calculations
• Delete storage that is no longer needed, which can provide gas refunds in some cases
• Store data in events when contracts do not need to read it later

Pack variables

Storage is organised in 32-byte slots. Variables that fit together can share a slot if declared next to each other. For example, several small integers and an address can pack into fewer slots.

Layout	Effect
Large and small types interleaved	More slots used
Small types grouped together	Fewer slots used
Frequently updated variables packed with rarely updated ones	Can still cost gas on each update

Packing helps most for structs stored in mappings and arrays.

Choose calldata for read-only inputs

For external functions that receive arrays or strings without modifying them, declaring parameters as calldata avoids copying data into memory. This saves gas on every call.

Be careful with loops

Loops over unbounded arrays are dangerous. As arrays grow, gas costs rise until transactions exceed block limits and functions become unusable.

Better patterns:

1. Avoid iterating over user-controlled arrays in state-changing functions
2. Use mappings for lookups instead of searching arrays
3. Process large sets in batches across multiple transactions
4. Let users claim individually instead of distributing to everyone in one loop

Use events for history

If data is only needed off-chain, such as activity history or analytics, emit it in events rather than storing it. Events are much cheaper than storage and can be indexed by off-chain services.

Custom errors and short checks

Custom errors are cheaper than long revert strings. Checking conditions early in a function avoids wasting gas on work that will revert anyway. Ordering conditions so cheaper checks run first can also help.

Immutable and constant values

Values that never change after deployment should be declared constant or immutable. They are embedded in bytecode rather than read from storage, which reduces the cost of every access.

Minimise external calls

Calls to other contracts cost gas and introduce security considerations. Cache results of external calls in memory when you need them more than once in a function, and avoid unnecessary calls entirely.

When optimisation is not worth it

Gas optimisation has trade-offs:

• Clever tricks can make code harder to read and audit
• Low-level assembly increases the risk of subtle bugs
• Savings may be tiny on low-fee networks
• Premature optimisation delays shipping

Prioritise functions users call frequently, such as transfers, swaps and claims. Measure gas usage in tests before and after changes, and keep security reviews in the loop for any optimisation that changes logic.

Measure first

Use your testing framework's gas reports to identify expensive functions. Optimise the biggest costs first and track improvements in pull requests.

Efficiency for users

Users notice when actions are cheap. Low fees encourage experimentation and repeat use. When you launch an efficient app, tell people where to find it: consistent official links on your website, docs and profiles such as a Proud Globe pin help new users try it with confidence.