• A view function may read state, but must not modify it.
• A pure function may neither read nor modify state.

These modifiers matter for correctness, composability, and audits because they tell both the compiler and human readers what a function is allowed to depend on.

What each modifier allows

A view function can read:

• contract storage
• external contract state through read-only calls
• block and transaction context such as block.timestamp, block.number, or msg.sender

A pure function can depend only on its inputs and local variables. It cannot read storage, external state, or block/transaction context.

At the EVM level, read-only external calls are enforced with STATICCALL. That matters because view is partly a Solidity-level promise, while STATICCALL is an execution-level restriction.

Code Examples

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract ViewVsPure {
    uint256 public totalSupply = 1_000_000e18;
    mapping(address => uint256) public balances;

    // ── PURE: only uses input parameters and memory ──

    /// @notice Basis-point tax calculation (10000 = 100%)
    function calculateTax(uint256 amount, uint256 bps) external pure returns (uint256) {
        return (amount * bps) / 10_000;
    }

    /// @notice Deterministic hash — same input always yields same output
    function hashData(bytes memory data) external pure returns (bytes32) {
        return keccak256(data);
    }

    // ── VIEW: reads storage or block context ──

    /// @notice Single storage read
    function getBalance(address user) external view returns (uint256) {
        return balances[user];
    }

    /// @notice Reads block context — not allowed in pure
    function getCurrentTimestamp() external view returns (uint256) {
        return block.timestamp;
    }

    /// @notice Reads balances[user] and totalSupply
    function calculateUserShare(address user) external view returns (uint256) {
        uint256 supply = totalSupply;
        if (supply == 0) return 0;
        return (balances[user] * 1e18) / supply; // 18-decimal precision
    }

    // ── STATE-CHANGING: costs gas in every transaction context ──

    function updateBalance(address user, uint256 amount) external {
        balances[user] = amount;
    }
}

Gas: When Read-Only Is Free — and When It Is Not

view and pure functions do not cost onchain gas when invoked off-chain with eth_call, because no transaction is broadcast or included in a block.

But when the same logic executes inside a transaction, it consumes gas like any other code path.

That means:

• calling a view function from your frontend is usually “free” in the onchain sense
• calling a view function from inside a state-changing function is not free
• marking a function pure instead of view does not magically lower gas; it only prevents state reads, which may indirectly avoid expensive operations like SLOAD

A useful mental model is:

view and pure describe what a function is allowed to read, not how the EVM prices its execution.

Here is the common source of confusion:

contract GasExample {
    uint256 public price = 1 ether;

    function getPrice() public view returns (uint256) {
        return price;
    }

    function buy(uint256 qty) external payable {
        // This view call happens inside a transaction.
        // Its storage read still costs gas.
        uint256 cost = getPrice() * qty;
        require(msg.value >= cost, "Insufficient payment");
    }
}

An internal call to a view or pure function is just normal bytecode execution. It is not a special free operation.

Opcode Cost Reference (Post-EIP-2929)

Real-World Application Patterns

Use pure for:

• mathematical libraries
• encoding and decoding helpers
• signature and hash construction
• validation predicates that depend only on inputs

Use view for:

• aggregated state queries
• computed properties derived from storage
• access-controlled reads involving msg.sender or role state
• oracle or adapter reads from external contracts

Common Pitfalls

// ❌ Compiler error: block context is not allowed in pure
function badPure() public pure returns (uint256) {
    return block.timestamp;
}

// ❌ Compiler error: state writes are not allowed in view
function badView() public view returns (uint256) {
    totalSupply = 1000;
    return totalSupply;
}

// ✅ Compiles, but the modifier is weaker than necessary
function add(uint256 a, uint256 b) public pure returns (uint256) {
    return a + b;
}

// ❌ Not pure: depends on external contract state
function externalSupply(IERC20 token) public view returns (uint256) {
    return token.totalSupply();
}

When a view function calls another contract, the compiler requires view, not pure, because the result depends on external state. That value may change across blocks, so frontend caching assumptions should reflect that.

Security Considerations

pure functions reduce chain-state-related risk because they have no storage reads, no external state dependency, and no block-context dependency. That makes them easier to isolate, test, and audit. But they are not automatically “safe” — math bugs, encoding errors, and flawed assumptions can still exist inside pure logic.

view functions carry more nuance:

• external read-only calls use STATICCALL, which the EVM enforces as non-state-modifying
• private only restricts Solidity-level access, not what the declaring contract itself can read internally
• off-chain users can inspect storage slots directly regardless of visibility modifiers
• external view calls are only as trustworthy as the contracts they read from

Never treat onchain storage as secret just because a variable is marked private.

Actionable Takeaways

1. Use pure when logic depends only on inputs and local computation.
2. Use view when logic needs storage, external read-only state, or block/transaction context.
3. Treat view and pure as correctness annotations first, not gas tricks.
4. Remember that eth_call avoids onchain gas, but the same logic still costs gas when executed during a transaction.
5. Split complex flows into pure computation plus state-reading wrappers where possible.
6. Be cautious with external view calls: read-only does not mean trustworthy.

What's the Difference?

Storage

Storage is persistent data stored on the blockchain. It survives
across transactions.

• Writing new storage slot ≈ 20,000 gas
• Updating existing slot ≈ 5,000 gas
• Reading storage ≈ expensive compared to memory
• Clearing storage can generate gas refunds (subject to limits)

Think of storage as your contract's hard drive.

Memory

Memory exists only during function execution.

• Cheap to read/write
• Cleared after execution
• Used for temporary variables

Think of memory as your contract's RAM.

Calldata

Calldata is:

• Read‑only
• Non‑persistent
• Cheaper than memory
• Available only in external function calls

Best used for function parameters that should not be modified.

Code Example

contract StorageVsMemory {

    string public storedData;
    uint[] public numbers;

    function demonstrateStorage() public {

        storedData = "This persists on blockchain";
        numbers.push(42);

    }

    function demonstrateMemory() public pure returns (string memory) {

        string memory tempData = "Temporary execution data";

        uint[] memory tempNumbers = new uint[](3);

        tempNumbers[0] = 1;
        tempNumbers[1] = 2;
        tempNumbers[2] = 3;

        return tempData;

    }

    function processArray(uint[] calldata inputArray) external {

        uint sum = 0;

        for (uint i = 0; i < inputArray.length; i++) {
            sum += inputArray[i];
        }

        uint[] memory modifiableArray = inputArray;

        modifiableArray[0] = sum;

    }
}

Reference vs Copy Behavior (Critical Concept)

Assignment behavior depends on the data location.

From → To Behavior

storage → storage reference
storage → memory copy
memory → memory reference
calldata → memory copy

Example:

uint[] public numbers;

function example() public {

    uint[] storage ref = numbers;

    ref[0] = 999;

    uint[] memory copy = numbers;

    copy[0] = 111;

}

Only the storage reference modifies the contract state.

Struct Example (Real‑World Pattern)

struct User {
    uint balance;
}

mapping(address => User) public users;

function updateBalance(uint amount) public {

    User storage user = users[msg.sender];

    user.balance += amount;

}

Using storage avoids unnecessary copying.

Important Limitation: Mappings Exist Only in Storage

Mappings cannot exist in memory.

Invalid:

mapping(address => uint) memory balances;

Mappings rely on hashed storage slots.

Internal vs External Functions and Calldata

Valid:

function externalExample(uint[] calldata data) external {}

Invalid:

function internalExample(uint[] calldata data) internal {}

Calldata exists only for external call boundaries.

Storage Caching Optimization Pattern

Avoid repeated storage reads.

Better:

uint value = storedValue;

for (uint i = 0; i < 10; i++) {
    total += value;
}

Instead of:

for (uint i = 0; i < 10; i++) {
    total += storedValue;
}

Storage reads are expensive (~2100 gas cold access).

Storage Pointer Aliasing (Advanced Gotcha)

uint[] storage ref1 = numbers;
uint[] storage ref2 = numbers;

Both reference the same storage location.

Modifying one modifies the other.

Emerging Feature: Transient Storage (EIP‑1153)

Transient storage behaves like storage during execution but resets after the transaction completes.

Use cases:

• Reentrancy guards
• Temporary execution flags
• Gas optimization helpers

Example:

tstore(slot, value)
tload(slot)

Real‑World Impact

Reading storage ≈ expensive

Memory operations ≈ cheap

Reducing storage access can save thousands of gas per transaction.

Security Considerations

• Memory resets after execution
• Storage persists permanently
• Always enforce access control when modifying storage
• Avoid unintended storage references

Best Practices

1. Use storage references when modifying persistent state
2. Use memory for temporary calculations
3. Use calldata for external function parameters
4. Cache storage reads if reused multiple times
5. Avoid unnecessary struct and array copies
6. Always explicitly declare data locations

Final Takeaway

Mastering Solidity data locations is one of the highest‑impact gas
optimization skills a smart contract developer can learn. Most inefficiencies come from unnecessary storage access or accidental data copying between locations.

Technical Architecture

Core Technologies

• Next.js 15: App Router with server components and streaming
• TypeScript: Strict mode with comprehensive type safety
• Tailwind CSS v4: CSS-first configuration with @theme directive
• Framer Motion: Smooth animations and page transitions
• PostgreSQL: Third-party database with Row Level Security (RLS)

AI Chatbot System

RAG Implementation (Retrieval-Augmented Generation):

• Document chunking with 300-word chunks and 30-word overlap
• Keyword-based scoring for relevant context retrieval
• 2000-token budget management for optimal context injection
• Session persistence (last 20 messages)

Multi-Provider Support:

• Primary: Claude Sonnet 5.5 via OpenRouter
• Fallback: Claude Opus 5.5 (OpenRouter model routing)
• Streaming responses over plain fetch (no SDK)
• Configurable rate limiting per session

Context Sources:

• Professional bio and experience
• Project descriptions and technical details
• Skills and technologies
• FAQ and common questions

Resume Access System

Workflow:

1. User submits request (Cloudflare Turnstile protected)
2. Database record created
3. Telegram notification sent to admin
4. Admin approves via secure token link
5. Email sent with time-limited access token
6. Token validation on every access

Security Features:

• HMAC-signed tokens with configurable expiry
• Server-side validation on all endpoints
• Persistent rate limiting on access requests
• IP-based tracking with SHA-256 hashing

PDF Generation:

• Dynamic metadata embedding (token, email, download date, URL)
• Date-stamped filenames (YYYYMMDD_Resume_Guillermo_Salazar.pdf)
• Private storage outside public directory
• Authenticated download endpoint

Content Management

CMS:

• Git-based headless CMS
• Markdown content with frontmatter
• Direct repository commits
• Blog posts and project showcase
• No external database dependency

Integrations

Email Service:

• Transactional emails for resume approval
• Contact form submissions
• Graceful fallback when unavailable

Telegram Bot:

• Real-time notifications for resume requests
• Contact form submissions
• Admin alerts

Security (Cloudflare Turnstile):

• Bot protection on all public forms
• Contact form verification
• Resume request validation

Security & Rate Limiting

Server-Side Rate Limiting

Implementation:

• Database-backed persistent rate limits for critical endpoints
• IP hashing with configurable salt for privacy
• Configurable time windows and request thresholds
• Multiple storage strategies (in-memory and persistent)

Protected Features:

• AI chatbot interactions
• Resume access requests
• Public-facing API endpoints

Input Validation

• Server-side validation on all user inputs
• Length limits enforced
• Type checking with TypeScript
• Sanitization before database storage

Security Headers

• Comprehensive Content Security Policy (CSP)
• HTTP Strict Transport Security (HSTS)
• X-Frame-Options and X-Content-Type-Options
• Configured in next.config.mjs

Development Approach

AI-Assisted Development

Code Generation:

• API route scaffolding
• Component structure and boilerplate
• TypeScript interfaces from schemas
• Test case generation

Optimization:

• Bundle size analysis
• Performance profiling
• Accessibility audits
• Security vulnerability scanning

Documentation:

• Inline code comments
• README with setup instructions
• Environment variable documentation

Quality Assurance

• TypeScript strict mode enabled
• ESLint with Next.js rules
• Prettier for consistent formatting
• Build-time type checking

Performance & SEO

Optimization

• Server components for reduced JavaScript
• Image optimization with Next.js Image
• Code splitting and lazy loading
• Static generation where possible

Search Engine Optimization

• JSON-LD structured data
• Open Graph and Twitter Cards
• Semantic HTML markup
• Dynamic sitemap generation
• Robots.txt configuration

Deployment & Monitoring

• Deployment with automatic CI/CD
• Environment variable management
• Build validation before deployment
• Production error tracking

This portfolio demonstrates a production-ready full-stack application combining modern web technologies, AI capabilities, and robust security practices. The modular architecture allows graceful degradation when optional services are unavailable, ensuring core functionality remains accessible.