# MIP-3: Linear Memory

Source: https://www.eipsfordesigners.com/standards/MIP-3
Agent brief: https://www.eipsfordesigners.com/standards/MIP-3/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/MIP-3
Last reviewed: 2026-04-05
Last updated: 2026-04-05

| Field | Value |
| --- | --- |
| Status | Proposed |
| Chain | monad |
| Category | Infrastructure |
| Journey stages | Gas & Fees |
| Detailed guide | Yes |
| Official specification | https://github.com/monad-crypto/MIPs/blob/main/MIPS/MIP-3.md |

## UX Impact

Linear memory pricing replaces Ethereum's quadratic model — gas costs scale predictably with operation size. Design implications: show tighter estimate ranges with higher confidence, use Monad-specific gas estimation (not Ethereum defaults), enable batch and data-heavy flows without surprise fee jumps. Design decisions: whether to explain linear scaling to users or just show accurate estimates; how to present confidence levels on fee previews.

## Summary

MIP-3 changes how Monad charges for memory usage. Instead of quadratic pricing (where doubling memory costs 4x), it uses linear pricing (doubling costs 2x). This makes gas costs more predictable and prevents certain contract patterns from being prohibitively expensive. For users, it means gas estimates are more accurate and fewer surprise fee jumps.

## For Designers

- You can design UI that delivers linear pricing = estimates match actuals more closely.
- You can design UI that delivers predictable cost scaling for data-heavy operations.
- You can collapse multi-step actions into one confirmation users understand.

## Applicability

### When to Use

- Your product addresses: gas estimates often wrong for memory-heavy operations.
- Your product addresses: some operations unexpectedly expensive.
- The flow should deliver: linear pricing = estimates match actuals more closely.
- Fee screens need estimates, speed options, and plain-language breakdowns.

### When to Avoid

- Use Monad-specific gas estimation.
- Show confidence level, range when uncertain.
- Show per-item cost comparison.

## Problems It Solves

### Gas estimates often wrong for memory-heavy operations

Impact: high

Old way: Estimate shows $2, actual cost is $8 due to quadratic memory pricing

New way: Linear pricing = estimates match actuals more closely

### Some operations unexpectedly expensive

Impact: high

Old way: Returning large arrays costs exponentially more

New way: Predictable cost scaling for data-heavy operations

### DeFi protocols avoid certain patterns

Impact: medium

Old way: Can't efficiently process large batches on-chain

New way: Batch operations economically viable

### Users hit gas limits unexpectedly

Impact: medium

Old way: Transaction fails partway through due to memory cost spike

New way: More consistent gas consumption

## Anti-Patterns

### Using Ethereum gas estimates on Monad

Severity: high

Different pricing models lead to wrong estimates

Instead: Use Monad-specific gas estimation

### Showing low confidence estimates as precise

Severity: medium

Users budget wrong, get frustrated

Instead: Show confidence level, range when uncertain

### Not explaining why batch is cheaper per-item

Severity: medium

Users don't understand value of batching

Instead: Show per-item cost comparison

## UI Components

### LinearGasEstimate

Shows gas estimate with confidence indicator
States: estimating, confident, uncertain
Props: gasUnits, gasPrice, confidence

### BatchSizeSelector

Slider or input for selecting batch size
States: single, batch, max
Props: min, max, value, costPerItem, onChange

### CostScaleExplainer

Visual explanation of linear cost scaling
States: collapsed, expanded
Props: baseCount, selectedCount, baseCost

## On Monad

### Memory Pricing

Ethereum: Quadratic: memory_cost = a × size²

Monad: Linear: memory_cost = b × size

Design implication: Batch operations much more predictable in cost

### Estimate Accuracy

Ethereum: ±20-50% common for complex operations

Monad: ±5-10% typical with linear model

Design implication: Can show tighter ranges, higher confidence

### Large Data Operations

Ethereum: Often prohibitively expensive

Monad: Economically viable

Design implication: Enable features like batch claims, large airdrops

## Key Takeaways

- MIP-3 = linear memory pricing (more predictable)
- Gas estimates are more accurate on Monad
- Batch operations scale predictably
- Use Monad-specific gas estimation, not Ethereum's
- Show confidence levels when displaying estimates

## UX Patterns

### Predictable Gas Estimates

Show users accurate cost predictions

User flow:

- User initiates batch operation
- App estimates gas (linear scaling)
- Shows high-confidence estimate
- Explains predictable pricing
- User confirms with accurate expectation

Mockup registry key: `concept/nft-gallery` (React UI on the live standard page).

### Batch Size Slider

Let users choose batch size with live cost preview

User flow:

- User adjusts batch size slider
- Live cost updates (linearly)
- User sees predictable scaling
- Chooses optimal batch size
- Confirms with known cost

Mockup registry key: `concept/bundled-defi` (React UI on the live standard page).

## Technical Notes

MIP-3 modifies the EVM memory expansion cost formula. Ethereum uses: memory_cost = (size² / 512) + (3 × size). Monad uses linear pricing: memory_cost = k × size. This primarily affects contracts that allocate large memory regions, like those processing arrays or returning large data structures.