Forem: Erick Fernandez

A Rust-Powered Starfield in the Browser with Macroquad + WASM

Erick Fernandez — Wed, 01 Apr 2026 18:22:05 +0000

AI can get you to a working result quickly. What it doesn’t replace is the value of understanding why something looks right, breaks, or feels good to tune.

I wanted a small Rust project where the mechanics stayed visible, and a browser-based starfield was a good fit: simple enough to build quickly, but visual enough to make the underlying math worth paying attention to.

The nice part is that this effect is mostly a handful of small ideas wired together correctly. We are not building a full engine here. We are just using Rust, a rendering loop, and some basic projection math to create a convincing sense of forward motion.

This walkthrough assumes you're comfortable reading basic Rust, but not necessarily familiar with Macroquad, WASM, or graphics code.

Setting Up the Machine

Before we get to the pixels, we need the right tools in the garage. For this project, we're using Macroquad's own web loader path, which keeps the setup simple: compile to wasm32-unknown-unknown, drop the output into a small web/ folder, and serve it like static files.

1. Create the Project

If you do not already have Rust installed, start with rustup from rustup.rs. Once that is in place, create a new Rust binary project and move into the directory:

cargo new starfield --bin
cd starfield

# Install the WASM target
rustup target add wasm32-unknown-unknown

# Optional: install a simple static server for local testing
cargo install basic-http-server

2. The Blueprint (Cargo.toml)

We only need a few parts to get this engine running. Macroquad handles the graphics, and we’ll use the rand crate for our star distribution.

I landed on this exact rand config after a failed browser build. The small_rng feature is enough for this project, and disabling rand's default features avoids pulling in browser glue that does not match Macroquad's plain HTML5 loader path.

[dependencies]
macroquad = "0.4"
rand = { version = "0.8", default-features = false, features = ["small_rng"] }

3. The Glue (`web/index.html`)

Macroquad's browser path expects a canvas and a JavaScript loader. Create a web/ directory, and inside it add an index.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Rust Starfield</title>
    <style>
        html, body { margin: 0; padding: 0; overflow: hidden; background: black; height: 100%; width: 100%; }
        canvas { display: block; width: 100vw; height: 100vh; }
    </style>
</head>
<body>
    <canvas id="glcanvas" tabindex="1"></canvas>
    <script src="mq_js_bundle.js"></script>
    <script>load("starfield.wasm");</script>
</body>
</html>

Note on mq_js_bundle.js: You need to place a copy of this loader in your web/ directory. You can usually find it in your local Cargo registry:

cp ~/.cargo/registry/src/index.crates.io-*/macroquad-*/js/mq_js_bundle.js web/

Troubleshooting: If you cannot find it locally, you can download it directly from the Macroquad GitHub repository.

The Stack: Macroquad & WASM

There are powerful graphics options in Rust like Bevy, but for this, I wanted something direct.

I chose Macroquad. It’s a minimalist engine with a low-friction API. It doesn't hide the execution loop behind much abstraction; you write a loop and tell it exactly what to draw every frame. It feels less like building a factory and more like working directly on the engine block.

When you compile to WASM, you ship a self-contained binary. You still need that small JS shim (mq_js_bundle.js) to bridge to WebGL, but the setup stays lean.

The Anatomy of a Star

The "star" is our basic unit:

struct Star {
    x: f32,
    y: f32,
    z: f32,
    speed: f32,
    brightness: f32,
}

x, y: Coordinates in space.
z: Depth. As z decreases, the star moves closer.
speed: Allows for different layers of motion.
brightness: Adds visual depth.

To get moving, we populate a Vec with randomized starting positions:

fn init_stars(count: usize) -> Vec<Star> {
    let mut rng = SmallRng::seed_from_u64(0);

    (0..count)
        .map(|_| Star {
            x: rng.gen_range(-1.0..1.0),
            y: rng.gen_range(-1.0..1.0),
            z: rng.gen_range(1.0..32.0),
            speed: rng.gen_range(0.008..0.025),
            brightness: rng.gen_range(0.6..1.0),
        })
        .collect()
}

Two Rust details worth calling out here:

SmallRng::seed_from_u64(0) creates a deterministic field, which is great for debugging.
(0..count).map(|_| ...) is the idiomatic way to say "repeat this count times." The |_| means we don't need the loop index.

One small visual tweak: If you keep x and y in too tight a range, stars bunch around the center. Widening the spawn volume (which we'll do in the "Polish" section) makes the field feel more believable.

The Infinite Loop (The Projection)

The "warp" effect relies on a simple 3D-to-2D projection: as z decreases, we scale coordinates to push stars further from the center.

for star in stars.iter_mut() {
    star.z -= star.speed; // Move forward

    if star.z < 0.2 { // Recycle star
        star.z = 32.0; 
        star.x = rng.gen_range(-1.0..1.0);
        star.y = rng.gen_range(-1.0..1.0);
    }

    // Projection: dividing by 'z' is the key.
    let sx = (star.x / star.z) * screen_width() * 0.5 + center_x;
    let sy = (star.y / star.z) * screen_height() * 0.5 + center_y;

    draw_circle(sx, sy, size, color);
}

The Full Engine (Core Version)

Replace your src/main.rs with this. It sets up the window, initializes the field, and runs the loop.

use macroquad::prelude::*;
use ::rand::rngs::SmallRng;
use ::rand::{Rng, SeedableRng};

struct Star {
    x: f32, y: f32, z: f32,
    speed: f32,
    brightness: f32,
}

const STAR_DEPTH: f32 = 32.0;
const TITLE_TEXT: &str = "RUST // WASM";

fn init_stars(count: usize) -> Vec<Star> {
    let mut rng = SmallRng::seed_from_u64(0);
    (0..count).map(|_| Star {
            x: rng.gen_range(-1.0..1.0),
            y: rng.gen_range(-1.0..1.0),
            z: rng.gen_range(1.0..STAR_DEPTH),
            speed: rng.gen_range(0.008..0.025),
            brightness: rng.gen_range(0.6..1.0),
    }).collect()
}

#[macroquad::main("Starfield")]
async fn main() {
    let mut stars = init_stars(400);
    let mut rng = SmallRng::seed_from_u64(macroquad::miniquad::date::now() as u64);

    loop {
        let screen_w = screen_width();
        let screen_h = screen_height();
        let center_x = screen_w * 0.5;
        let center_y = screen_h * 0.5;
        let time = get_time() as f32;

        clear_background(Color::from_rgba(3, 4, 10, 255));

        for star in stars.iter_mut() {
            star.z -= star.speed;
            if star.z < 0.2 {
                star.z = STAR_DEPTH;
                star.x = rng.gen_range(-1.0..1.0);
                star.y = rng.gen_range(-1.0..1.0);
            }

            let sx = (star.x / star.z) * screen_w * 0.5 + center_x;
            let sy = (star.y / star.z) * screen_h * 0.5 + center_y;

            let depth_factor = 1.0 - (star.z / STAR_DEPTH);
            let size = 1.0 + 2.0 * depth_factor;
            let brightness = star.brightness * depth_factor;

            draw_circle(sx, sy, size, Color::new(brightness, brightness, brightness, 1.0));
        }

        let pulse = 0.5 + 0.5 * (time * 2.0).sin();
        let title_color = Color::new(0.5 + 0.5 * pulse, 0.8, 1.0, 1.0);
        draw_text(TITLE_TEXT, 20.0, 40.0, 30.0, title_color);

        next_frame().await;
    }
}

What's happening in main()?

screen_width() & center_x: Recomputed every frame so it stays centered if you resize the browser.
get_time(): Used for the pulsing title.
clear_background(...): Every frame is drawn from scratch; we must clear the last one.
0.5 + 0.5 * (time).sin(): Maps the sine wave (-1.0..1.0) to a usable color range (0.0..1.0).

Running the Engine

Build the WASM target (use --release for performance):

cargo build --target wasm32-unknown-unknown --release
cp target/wasm32-unknown-unknown/release/starfield.wasm web/starfield.wasm

Serve the web/ folder (Python, Node, or basic-http-server all work):

basic-http-server web
# OR: python3 -m http.server --directory web

Automation (`build.sh`)

To make iteration faster, wrap this in a script:

#!/usr/bin/env bash
set -euo pipefail
PORT=4000
cargo build --target wasm32-unknown-unknown --release
cp target/wasm32-unknown-unknown/release/starfield.wasm web/starfield.wasm

if lsof -i :"$PORT" >/dev/null 2>&1; then
    echo "Server running on $PORT. Refresh browser."
    exit 0
fi
basic-http-server web -a 127.0.0.1:"$PORT"

The Machine in Motion (The Polish)

The "Core" version works, but it feels like a diagnostic test. Let's make it a finished visual.

1. Tighten the Spawn Volume

Add const STAR_SPREAD: f32 = 20.0; at the top. Use this range in init_stars and the recycling block:
star.x = rng.gen_range(-STAR_SPREAD..STAR_SPREAD);
This makes the field feel deeper and less bunched.

2. Increase Density and Speed

In main(), bump the count to 650 and the speed range in init_stars to 0.012..0.032.

3. Center the Title

Use measure_text to center the title perfectly:

let title_size = 84.0;
let title_metrics = measure_text(TITLE_TEXT, None, title_size as u16, 1.0);
let title_x = center_x - title_metrics.width * 0.5;
let title_y = center_y - title_metrics.height * 0.5;
draw_text(TITLE_TEXT, title_x, title_y, title_size, title_color);

Final Optimized Code

rust-wasm-repo

use ::rand::rngs::SmallRng;
use ::rand::{Rng, SeedableRng};
use macroquad::prelude::*;

// One star in 3D space, plus a few values for motion and brightness.
struct Star {
    x: f32,
    y: f32,
    z: f32,
    speed: f32,
    brightness: f32,
}

const STAR_DEPTH: f32 = 32.0;
const STAR_SPREAD: f32 = 20.0;
const TITLE_TEXT: &str = "RUST // WASM";

fn init_stars(count: usize) -> Vec<Star> {
    // Fixed seed so the initial field is repeatable while developing.
    let mut rng = SmallRng::seed_from_u64(0);
    (0..count)
        .map(|_| Star {
            // Spread stars across a wider 3D volume so the field fills the screen.
            x: rng.gen_range(-STAR_SPREAD..STAR_SPREAD),
            y: rng.gen_range(-STAR_SPREAD..STAR_SPREAD),
            z: rng.gen_range(1.0..STAR_DEPTH),
            speed: rng.gen_range(0.012..0.032),
            brightness: rng.gen_range(0.6..1.0),
        })
        .collect()
}

#[macroquad::main("Starfield")]
async fn main() {
    // Create the initial field once at startup.
    let mut stars = init_stars(650);
    // Time-based seed so recycled stars re-enter less predictably.
    let mut rng = SmallRng::seed_from_u64(macroquad::miniquad::date::now() as u64);

    loop {
        // Recompute dimensions every frame so the effect stays centered.
        let screen_w = screen_width();
        let screen_h = screen_height();
        let center_x = screen_w * 0.5;
        let center_y = screen_h * 0.5;
        let time = get_time() as f32;

        // Paint the background before drawing the stars on top.
        clear_background(Color::from_rgba(3, 4, 10, 255));
        draw_rectangle(
            0.0,
            0.0,
            screen_w,
            screen_h,
            Color::from_rgba(18, 10, 36, 90),
        );

        for star in stars.iter_mut() {
            // 1. Move the star forward along the Z-axis
            star.z -= star.speed;

            // 2. Recycle the star if it gets too close to the "windshield"
            if star.z < 0.2 {
                star.z = STAR_DEPTH;
                // Respawn across the full width of the field, not just the center.
                star.x = rng.gen_range(-STAR_SPREAD..STAR_SPREAD);
                star.y = rng.gen_range(-STAR_SPREAD..STAR_SPREAD);
            }

            // 3. Project to 2D screen: dividing by 'z' is the key.
            let sx = (star.x / star.z) * screen_w * 0.5 + center_x;
            let sy = (star.y / star.z) * screen_h * 0.5 + center_y;

            // 4. Scale size and brightness based on depth
            let depth_factor = 1.0 - (star.z / STAR_DEPTH);
            let size = 1.0 + 2.0 * depth_factor;
            let brightness = star.brightness * depth_factor;

            // Draw brighter, larger stars as they get closer to the camera.
            draw_circle(
                sx,
                sy,
                size,
                Color::new(brightness, brightness, brightness, 1.0),
            );
        }

        // Smoothly oscillate between 0.0 and 1.0 for the title pulse
        let pulse = 0.5 + 0.5 * (time * 2.0).sin();
        let title_color = Color::new(0.5 + 0.5 * pulse, 0.8, 1.0, 1.0);
        let title_size = 84.0;
        let title_metrics = measure_text(TITLE_TEXT, None, title_size as u16, 1.0);
        let title_x = center_x - title_metrics.width * 0.5;
        let title_y = center_y - title_metrics.height * 0.5;
        draw_text(TITLE_TEXT, title_x, title_y, title_size, title_color);

        // Present the current frame, then continue the loop
        next_frame().await;
    }
}

What's Next?

We’ve built the universe; now we just need a way to pay for the fuel.

The obvious next step is to make the effect more physical: star trails, camera drift, or mouse input. But even in this stripped-down form, the core lesson holds up: if you want a visual Rust project that feels rewarding quickly.

References

Start the year securely with these development checklists

Erick Fernandez — Wed, 14 Jan 2026 15:27:38 +0000

Start the year securely with these development checklists

The exploit landscape is forever changing, to help you ensure you make a safe start to 2026 we are releasing some security checklists for you to use when developing in Web3. The first looks at architecture and procedures in general.
Join our Discord server and let us know if you find these useful, and above all stay safe in 2026.

Web3 Development General Security Checklist

This checklist is derived from the critical findings and recommendations from our 2025 End-of-Year Security Review.

1. Defensive Architecture & Fail-Safe Engineering

On-Chain Invariant Enforcement: Have you implemented automated checks that revert state transitions if fundamental economic properties (e.g., total supply, collateral ratios, or reward balances) are violated?
Algorithmic Circuit Breakers: Are there automated pause mechanisms triggered by abnormal volatility, suspicious outflow patterns, or internal state desynchronisation?
Formal Verification for Logic Safety: Have you transitioned from simple unit testing to property-based testing and formal verification to prove protocol maths remains sound under extreme edge-case conditions?
Implicit vs. Explicit Failure: Is the system architected to degrade gracefully or halt entirely when core invariants are threatened, rather than assuming ideal behaviour?
Upgrade Safety Is there an upgrade path that has been tested. Can an attacker force an upgrade ? Are upgrades monitored ?

2. Precision Access Control & Authority Management

Scoped Capability Management: Have you moved away from monolithic admin roles toward granular, time-locked capabilities?
Separation of Duties: Are critical tasks and privileges distributed among distinct individuals to prevent single points of failure?
Whitelisted Governance Execution: Is all governance-led interaction restricted to a pre-approved registry of contracts and function signatures, eliminating arbitrary low-level calls?
Operational Security (OpSec) Hygiene: Is "Least Privilege" access enforced for dev-ops pipelines and deployment environments?

3. Identity Integrity & Cross-Chain Security

Domain Separation & Replay Protection: Do all off-chain messages mandate EIP-712 (or equivalent) domain separation, cryptographically binding signatures to a specific Chain ID, contract address, and unique user nonce?
Resolver-Contract Synchronisation: For hybrid or ZK-powered systems, is the off-chain resolver state a perfect mirror of the on-chain source of truth?
Cryptographic Handshakes: Do backends require a cryptographically verified handshake from the smart contract before updating local state?
Contextual Identity Verification: Does the code clearly distinguish between a Signer (initiator) and an Object Owner (asset holder) to eliminate "Confused Deputy" vulnerabilities?

4. User Protection & Behavioural Security

Simulation-First UX: Does the user interface integrate transaction simulation to provide "clear-signing" transparency, preventing blind-signing of malicious requests?
Adversarial UX Testing: Has the user interaction flow been stress-tested against phishing, wallet compromise, and transaction misdirection?
Incident Response Readiness: Is there a documented and tested recovery plan for compromised keys, including pre-deployed emergency pause contracts?

Extropy Security Bytes: w1 & w2, 2026

Erick Fernandez — Tue, 13 Jan 2026 10:50:00 +0000

Welcome back to Extropy Security Bytes, where we discuss the latest incidents shaping the Web3 landscape.

Throughout 2025, we dissected the industry’s most critical incidents together. Now, as we present our first roundup of 2026, the new year has already delivered a wave of critical headlines. Attackers take no breaks — and neither can we.

Truebit: The $26 Million Zombie Code

“When legacy math meets modern liquidity, the result is always catastrophe.”

On January 8, the Truebit Protocol suffered the first major exploit of 2026, losing roughly $26 million (8,535 ETH) to a vulnerability that should have stayed in the past. The attack wasn’t a complex new vector; it was a classic integer overflow in a legacy smart contract that had seemingly been forgotten. The attacker exploited this unmaintained code to mint millions of TRU tokens at near-zero cost, bypassing supply caps effortlessly because the contract pre-dated modern Solidity’s native overflow checks.

Once the infinite mint was complete, the attacker dumped the tokens back into the protocol, draining all available liquidity and causing the TRU token price to collapse by nearly 100% in 24 hours. The impact was total: a project’s market cap evaporated overnight because a single legacy file was left live and unmonitored. While the team scrambled to coordinate with law enforcement, the on-chain damage was already irreversible.

In a pattern that is becoming standard operating procedure, the attacker immediately funneled the 8,535 ETH into Tornado Cash, obliterating the trail before any freeze could be attempted. Security firms have since linked the wallet to a previous exploit of the Sparkle Protocol, suggesting this was the work of a sophisticated, repeat offender who specifically hunts for abandoned, “zombie” contracts that teams have neglected to deprecate.

Lessons Learned

Legacy is Liability: Old contracts do not age like wine; they age like milk. If a contract is live, it must be monitored or deprecated.
Overflows are Still Real: Just because modern Solidity (0.8.0+) handles overflows doesn’t mean your legacy stack does.
The “Zombie” Risk: Nearly 80% of projects hit by such exploits never recover their full value. Abandoned code is a loaded gun waiting for a trigger.

Aave: The Governance Civil War

“When freedom from regulators becomes a license to fight over who owns the treasury.”

Aave spent four years fighting the SEC to prove decentralized finance could work. On December 16, 2025, they won that battle, only to immediately start a civil war over the spoils. The conflict centered on a $10 million annual feestream from the Aave frontend that was flowing to Aave Labs (Stani Kulechov’s company) instead of the DAO treasury. When former CTO Ernesto Boado proposed that the DAO should legally own all brand assets to correct this, the response was a textbook case of governance capture.

On December 21, Aave Labs escalated Boado’s proposal to a Snapshot vote without his consent, triggering a voting period that ran directly through Christmas. This “Grinch” move forced the community to mobilize during the holidays, causing the AAVE token to drop 25% as markets priced in the chaos. The proposal’s own author urged users to abstain, delegitimizing the entire process. The vote ultimately failed with 55% opposing and 41% abstaining, but the damage to trust was profound.

Now, the protocol enters “Phase 2” of negotiations. Stani Kulechov has offered revenue sharing, while delegate leader Marc Zeller is demanding full asset ownership transfer with enforceable “guardrails” for stewardship. The protocol itself works perfectly — holding $35 billion in TVL — but the governance layer is fractured. When a founder can force a vote without the author’s consent to protect a revenue stream, “decentralization” becomes a polite fiction, and the governance token becomes a proxy for political risk.

Lessons Learned

Governance is an Attack Vector: Internal power struggles can damage token value as effectively as a hack.
Timing Matters: Forcing votes during holidays destroys legitimacy and trust; it signals an attempt to bypass scrutiny.
Ownership vs. Stewardship: DAOs must clearly define who owns the brand versus who runs the website before the revenue becomes significant.

TMXTribe: The 36-Hour Bleed

“Was this incompetence so profound it became indistinguishable from malice?”

Between January 5 and January 7, TMXTribe (a GMX fork on Arbitrum) watched $1.4 million drain from their protocol over a continuous 36-hour window. The exploit was mechanically simple: a loop that minted LP tokens, swapped them for the internal stablecoin (USDG), and unstaked, repeated ad infinitum. Because the contracts were unverified, the exact flaw remains opaque to the public, but the result was a systematic drainage of the treasury.

What makes this incident damning is the team’s behavior. While the protocol bled, the team was active on-chain, deploying new contracts and executing upgrades throughout the attack window. Yet, despite being present and capable of signing transactions, they never triggered an emergency pause. They sent an on-chain bounty message to the attacker asking for a return of funds, but failed to take the one technical action that would have stopped the theft.

The attacker ignored the bounty, bridged the funds to Ethereum via Across Protocol, and washed them through Tornado Cash. Meanwhile, the team remained silent on Twitter for days, leaving users to watch the drain in real-time. When a team is competent enough to upgrade contracts during a hack but “forgets” to hit the pause button, the line between negligence and complicity blurs.

Lessons Learned

Unverified Contracts are Red Flags: TMXTribe ran unverified code. You cannot audit what you cannot see, and you cannot trust a team that hides their logic.
The 36-Hour Test: If a protocol cannot stop a slow drain in 36 hours, it effectively has no security operations center (SOC).
Pause Functionality is Mandatory: A kill switch is the most basic defense; failing to use it while actively online is inexcusable.

Ledger: The Supply Chain Leak

“Your keys are safe, but your home address isn’t.”

On January 5, Ledger confirmed a data breach impacting its customers — not through their hardware, but through their payment processor, Global-e. While Ledger’s devices remain secure and user funds are untouched, the personal data of customers — including names, shipping addresses, and contact information — was compromised. This breach exposes users to a threat that cryptography cannot solve: the physical “wrench attack.”

The breach occurred when Global-e identified “unusual activity” that exposed customer databases. Attackers now possess a list of individuals who own crypto hardware wallets, along with their physical locations. This creates a high-fidelity target list for phishing campaigns (fake Ledger letters, emails) and potentially home invasions. It is a bitter irony for a company that previously faced backlash for charging for security features; now, their “free” supply chain partners have cost users their privacy.

Lessons Learned

Vendor Risk is Your Risk: You can have the best hardware security in the world, but if your payment processor leaks the customer list, your users are in danger.
Expect Phishing: Victims should expect sophisticated phishing attempts using the stolen data to establish false trust.
Physical OpSec: Delivering hardware wallets to your home address creates a permanent record connecting your identity to crypto ownership. Use drop boxes or aliases where possible.

MetaMask: The “Party Hat” Phishing Campaign

“The drainer doesn’t need your seed phrase; it just needs your permission.”

A sophisticated phishing campaign flagged by ZachXBT has drained over $107,000 from hundreds of wallets by exploiting the holiday lull. Users received professionally designed emails from “MetaLiveChain” claiming a “Mandatory 2026 Upgrade” was required to keep their wallets active. The emails used legitimate marketing templates (complete with unsubscribe links from real vendors) and featured a disarming “party hat” version of the MetaMask fox logo to bypass user suspicion.

Instead of asking for a seed phrase — which most users now know to protect — the phishing site prompted users to sign a contract approval. This granted the attacker permission to move unlimited tokens from the victim’s wallet. By keeping individual thefts small (typically under $2,000), the attacker avoided triggering major alerts while scaling the theft across hundreds of victims. It serves as a reminder that a signature can be just as lethal as a leaked key.

Lessons Learned

Approvals are Dangerous: You can lose your funds without ever sharing your seed phrase. Never sign a transaction from an email link.
Small Drains Add Up: Attackers are moving towards “low and slow” thefts to stay under the radar of major security firms.
Verify the Sender: MetaMask will never email you about a “mandatory upgrade.” Any email claiming otherwise is a scam.

Futureswap: The Unverified Black Box

“If the code is closed, the exit is open.”

Security firm BlockSec Phalcon detected a quiet drain on the Futureswap protocol on Arbitrum, resulting in an estimated loss of $395,000. The attack appears to be caused by an accounting error in the stableBalance calculation during position updates, allowing the attacker to withdraw more USDC than they were entitled to.

However, confirming the root cause is impossible because the contracts are unverified. Closed-source contracts prevent security researchers from analyzing the flaw or helping the team patch it. As of now, the team has not responded to inquiries, and users are left in the dark about whether their remaining funds are safe. This incident reinforces the golden rule of DeFi: if the code isn’t verified on the block explorer, you aren’t using a decentralized protocol — you’re trusting a black box.

Lessons Learned

Verify or Don’t Trust: Unverified contracts are a massive security risk. They hide bugs from whitehats and hide exploits from users.
Silence is Telling: A lack of communication during an exploit typically signals a lack of capability to respond.

GlassWorm: The macOS Developer Trap

“The malware isn’t targeting your wallet; it’s targeting your codebase.”

A fourth wave of the GlassWorm malware campaign has been detected, specifically targeting macOS developers through malicious VSCode and OpenVSX extensions. Unlike previous waves that targeted Windows, this iteration uses AppleScript and LaunchAgents to establish persistence on Mac systems. The malware hides inside seemingly useful developer tools (like studio-velte-distributor) and executes an AES-encrypted payload after a 15-minute delay to evade sandbox analysis.

The malware’s goal is total credential theft. It scrapes GitHub, NPM, and OpenVSX credentials, giving attackers access to the victim’s code repositories and supply chain. More alarmingly, it contains code designed to replace legitimate hardware wallet apps (like Ledger Live and Trezor Suite) with trojanized versions. While this specific feature appears to be misconfigured in the current version (deploying empty files), the intent is clear: attackers are trying to compromise the developer’s entire environment, from their code to their cold storage.

Lessons Learned

Audit Your Extensions: VSCode extensions run with high privileges. Only install extensions from verified publishers with established reputations.
The Supply Chain is the Target: Attackers want your GitHub credentials to inject malware into your projects, infecting your users downstream.
Delayed Execution: Modern malware waits before striking. A clean scan immediately after download does not guarantee safety.

About Extropy

Since 2017, Extropy has been at the forefront of blockchain security, auditing smart contracts across Ethereum and Zero-Knowledge (ZK) protocols. We have collaborated with leading ecosystems, including Base, Starknet, and MINA, ensuring their smart contracts are resilient, efficient, and secure.

We specialise in DeFi, on-chain games, and ZK applications, leveraging formal verification, static analysis, and deep manual reviews to uncover vulnerabilities before they become exploits. Whether you’re working with Solidity, Rust, Cairo, or zkVMs, our collaborative approach ensures your project meets the highest security standards.

Website: security.extropy.io
Email: info@extropy.io

Into the Ocean

Erick Fernandez — Wed, 07 Jan 2026 14:24:51 +0000

We are leaving the Bay of Rainbows. behind us the "Golden Handle" that perfect polynomial curve is fading.
We are heading South-West, down into the largest basin on the moon: Oceanus Procellarum, The Ocean of Storms.

Why? Because we have a problem.
The smooth curves of Chapter 2 are too "heavy" for us. They rely on real numbers : decimals that stretch to infinity.
But our computers are finite, in the digital world, we cannot handle infinity, and we cannot afford the inaccuracy of rounding down.

Fortunately, we are on the Moon.

If you travel West across the Ocean of Storms and keep going, you don't vanish into infinity. Eventually you wrap around the sphere that is the Moon and return to where you started. The surface of the Moon is a closed loop.

In Chapter 3 we will apply this "closed loop" logic to our mathematics. We will leave the rocky terrain of standard integers where division often fails.
We are moving to a Finite Field.

A Field is a mathematical landscape where you can add, subtract, multiply and divide freely without ever falling off the map.
It is a closed system that allows us to have the complexity of curves with the absolute precision of integers.

We are heading to the Ocean of Storms because we need an ocean to freely sail on, a place where math works in every direction.

But be warned, when you force a smooth curve into a closed loop it shatters. The Golden Handle is about to turn into stardust.

The $3 Billion Loss Year: End-of-Year Security Report

Erick Fernandez — Wed, 31 Dec 2025 12:12:57 +0000

2025 made it unmistakably clear: in Web3, security is no longer a background concern or merely a checkbox; it is the defining factor separating the projects that survived from the ones that collapsed. With an estimation of more than $3 billion in losses across hacks, scams, protocol failures, and key management breaches this year, the ecosystem was forced into a harsh confrontation with its own maturity. While innovation accelerated, attacker sophistication and manoeuvring attacks outpaced both, revealing fundamental weaknesses that are no longer optional to address.

In Extropy, as a security auditing firm working across L1s, L2s, DeFi, gaming, and ZK applications, we reviewed real codebases and attack surfaces that could have resulted in catastrophic losses. We offer a picture of where Web3 security stands today and what development teams must prioritise going into 2026.

Some of the issues our audits uncovered this year

Our audits throughout the year exposed a pattern: even well-funded teams with experienced developers repeatedly fell into the same high-impact traps.

1. Incorrect Reward Accounting in Move Modules

One of the most consequential findings occurred within a Move-based staking system due to a subtle accounting error in the reward distribution logic.

The Issue: The function incorrectly subtracted the collectable_reward from the total removed value without isolating the principal from the reward flow.
Code Snippet:

// Move
// native_pool.move (excerpt)
let collectable_reward = reward_amounts[i];
total_removed_value = total_removed_value - collectable_reward; // Incorrect deduction

Impact: This failure to treat principal and rewards as distinct streams leads to corrupted validator balances, systemic reward imbalances (insolvency), and arithmetic cascades during subsequent cycles.

2. total_supply Underflow Causing Global DoS (Move)

We identified a high-severity vulnerability in a ticket-based staking protocol where critical global state variables were manipulated before validation.

The Issue: The total_supply was modified in the local execution context before verifying the user's available balance.
Impact: If the ticket_amount exceeds the balance, the transaction correctly reverts, but only after the total_supply has been modified. In specific runtime environments, this can lead to an underflow that freezes the contract's core functionality.

3. Settlement-Phase Financial Manipulation (Solidity)

During a Solidity audit, we uncovered a dangerous settlement design where external interactions and internal state updates were intermingled.

The Issue: Relying solely on the onlyAdmin modifier created a "security-by-access-control" fallacy that ignored the risks of compromised or malicious admin keys.
Code Snippet:

// Solidity
function settle() external onlyAdmin {
    uint256 payout = calculatePayout(user);
    userBalances[user] -= payout; // Updated before final validation
    (bool ok,) = user.call{value: payout}(""); // Mixed with external call
}

Impact: This allowed for state inconsistency and atomic misordering, demonstrating that security must be enforced at the state level.

4. Resolver / State Desynchronisation in ZK Games

In ZK-powered gaming systems (Mina/o1js), we identified a recurring structural weakness involving desynchronisation between off-chain resolvers and on-chain verification.

The Issue: The backend infrastructure updated game states independently of the zkApp's on-chain validation.
Impact: Without a cryptographic "handshake," the system was vulnerable to forged state transitions and replay inconsistencies.

5. Lack of Replay Protection & Weak Message Identity

A pervasive issue across multi-chain and intent-based systems was the absence of robust message-identity controls.

The Issue: Hashing functions lacked domain separators or nonces, making signatures vulnerable to collision or forgery.
Impact: Signatures authorized for an action on one chain could be replayed to drain funds on another, a primary driver of cross-chain liquidity loss in 2025.

Analysis: The State of Web3 Security

These findings reveal a fundamental shift in the threat landscape where attackers have pivoted toward architectural exploitation.

Failure of "Safe-by-Default": Over-reliance on the safety of Move and Rust led to "psychological safety," where developers assumed compilation precluded the need for invariant enforcement.
Verification Gap: In ZK systems, the weakest link is often the off-chain resolver—the bridge that must maintain consistency between the proof, the contract, and the server.
Operational & Admin Risk: Privileged admin pathways were responsible for approximately $1.6 billion (70%) of stolen funds in the first half of 2025.
Human-Centric Vectors: Roughly 40% of losses occurred via phishing, unauthorised permit signatures, and front-running, indicating that operational workflows remain highly vulnerable.

Recommendations for 2026

Defensive Architecture: Implement automated on-chain invariant checks and algorithmic circuit breakers to degrade gracefully during attacks.
Precision Access Control: Move toward granular, time-locked capabilities and enforce "Least Privilege" for dev-ops pipelines.
Identity Integrity: Mandate EIP-712 domain separation and ensure off-chain resolvers are cryptographically bound to the on-chain source of truth.
User Protection: Integrate transaction simulation into UIs to prevent "blind-signing" and conduct adversarial UX testing against phishing.

Future Outlook

In 2026, we expect security to serve as a core business differentiator. As highlighted at Abu Dhabi Fintech Week 2025, institutional adoption hinges on provable resilience. The threat landscape will continue to professionalise with AI-driven social engineering and autonomous predator swarms, reinforcing that Web3 security is now full-stack system security.

Final Words

The future of Web3 security is not about the total elimination of risk, but about the rigorous containment and engineering of that risk.
The tools exist; the remaining question is whether development teams will treat security as an indispensable foundation or an afterthought.
Over the next few weeks will be supplying security guidelines and checklists for Web3 developers to ensure that your start to 2026 is a secure one.

Originally published on: security.extropy.io

The Moon and the Maths: The Sea of Tranquility

Erick Fernandez — Tue, 30 Dec 2025 15:57:38 +0000

Chapter 1 - The Sea of Tranquility

This is an exploration of the Moon and the 'Moon Maths' that underlies Zero Knowledge Proofs.

Starting at the Apollo 11 landing site our journey will take us around the moon, each chapter introducing a new area of Maths.
The journey is based on the outline of the Moon Math Manual, a fantastic resource for learning ZKP Maths.

What will we take on our journey?

The Moon math manual (download link) this is the guide to the maths we will be discussing, and we can try some of its exercises as we travel.
Some music to help us think, an appropriate choice would be Apollo Atmospheres and Soundtracks by Brian Eno.
- Charts to help us navigate, fortunately NASA has made many charts available.

For companions we have Peggy and Victor :
Peggy will take the role of the person creating proofs, with Victor the verifier of the proofs.

Victor is a sceptic and always concerned that Peggy maybe trying to cheat him and provide an incorrect proof.
Peggy is most concerned about privacy, she wants to limit the information she provides to Victor.

We are ready to set off, but where are we going ?

Our journey takes us from the well understood landscape of the Sea of Tranquility to the mysterious dark side of the moon, from basic mathematics to elliptic curves and the processes used in ZKP systems

Our itinerary :

Chapter 1: Sea of Tranquility (The basics).
Chapter 2: Bay of Rainbows (Polynomials).
Chapter 3: Ocean of Storms (Finite Fields).
Chapter 4: Apennine Mountains (Abstract Algebra).
Chapter 5: The Far Side (Elliptic Curves).
Chapter 6: Sea of Moscow (R1CS).
Chapter 7: Crater Tycho (Trusted Setup).
Chapter 8 : The North Pole (Groth16 and True Zero Knowledge).

A conflict in the Sea of Tranquility

There is a conflict between Verification and Privacy.
Imagine you want to prove you are 18, you could hand over a driving licence or passport, revealing your name, address, and exact birth date.
You give away everything to prove one thing.
In the digital world most blockchains choose transparency, great for verifiability but no privacy

Banks emphasise privacy, your details remain private to the outside world, but transactions are not verifiable, we have to trust the bank.

The solution to the conflict lies with Zero Knowledge Proofs (ZKP) , we can have both verifiability (mathematical proofs) and privacy, the person verifying the proof learns no new information.

There are many analogies to help visualise ZKPs , lets try some :

Imagine that our journey to the moon started out as a secret search for an alien artifact (as happened in 2001 : A Space Odyssey)
As a research student you think you have discovered the site of the artifact in a photograph, and you need to share this with your supervisor, but if you give the exact coordinates, he will claim the discovery for himself.
A way round this would be to cover the photograph with a large piece of cardboard with just an artifact shaped hole in the cardboard. Your supervisor would be able to see the artifact through the hole, but not gain a frame of reference from other landmarks and so not learn the location.
They know you found it, but they have zero knowledge of where it is.

Of course physically covering information is no use for digital assets, we need mathematical constructs to allow us to hide information.

Our journey then is an exploration of the mathematical concepts we need to create and verify zero knowledge proofs.

Leaving the Sea of Tranquility

The aim in this first chapter is to establish the background in a well known setting, in the Sea of Tranquility (Mare Tranquillitatis).
Our destination is the Bay of Rainbows, some 1,500 kilometres away.
Initially we will head north to take us to the the Sea of Serenity (Mare Serenitatis) .

To the right: the sun is rising in the East.
Behind us the Earth hangs permanently in the sky at about 60 degrees elevation. It never moves.

The lunar surface

The ground we are travelling over is grey and flat. The surface is called 'regolith' it is a collection of shattered rock and charcoal grey powder that covers the bedrock. It has been formed by meteorite impact, but the particles are sharp and can easily damage equipment. .

The horizon is deceptively close only a few kilometres away curving sharply because the moon is small.
There is no atmosphere to scatter the light, so there is no 'distance' haze. A rock 100 metres away looks as sharp and black as a rock 10 kilometres away. It is easy to lose your sense of scale and perspective.

Similarly in the realm of proofs it is easy to lose perspective, we need to establish some rules.

The ground rules for ZKPs

Analogies are fine, but we need to clarify more rigorously what our requirements are for a ZKP. If we were to build a ZKP system it would have to follow 3 rules

Completeness : If Peggy is honest and the statement she is proving is true, the math always works. Victor will always accept her proof
Soundness : If the statement is false, Peggy cannot cheat. The probability of fooling Victor is negligible.
'Zero Knowledgeiness' : If the statement is true, Victor learns nothing else. He is unable to reverse engineer the proof to find any of its secrets.

One hurdle many have encountered when studying ZKPs is the terminology involved, making sense of unfamiliar symbols and terms slows us down, acts as a drag on our understanding.
So while we are on familiar ground, lets go through some symbols we will be using, starting with the classification of numbers.

If you cast your mind back to school we progressed from using numbers that felt familiar and were used for familiar task such as counting, on to fractions, and then stranger numbers such as pi. Overtime we would have become more rigorous in our classification of these numbers.
Fortunately on this journey we stay with the simplest types of numbers.

Integers

These are whole numbers, we represent them with the symbol $\mathbb{Z}$

Rational Numbers

These are numbers that can be represented as a ratio of integers for these we use the symbol $\mathbb{Q}$

Integers , division and remainders

Imagine we have decided to only work with Integers.
If we divide two integers we may get an integer as a result, for example 12 divided by 4 gives 3, but if we divide 13 by 4 we don't get an integer, but we could say we get 4 with a remainder of 1.
In ZKP maths we are often just concerned with remainders, like when we are telling the time we may only be interested in the minute hand rather than the hour hand, here the minutes represent a remainder.
Doing arithmetic in this way is called modular arithmetic, often called Clock Maths.

Congruence

If we explore the remainders we see a concept called congruence, this is grouping together integers that produce the same remainder under division.

For example

13 divided by 4 gives remainder 1
17 divided by 4 gives remainder 1
21 divided by 4 gives remainder 1
and so on

The numbers 13, 17 and 21 ... are said to be congruent.

We will investigate more arithmetic in chapter 3 when we reach the Ocean of Storms and look at fields.

We leave the Sea of Tranquility, rising up to our left is the Apennine Mountain Range.
These are 5,000 metre peaks higher than the Alps forming a massive wall.

The Crater Plinius stands sentinel here. It is a sharp, 43km-wide crater with a central peak.

We are leaving the familiar behind and heading for the unknown, time to introduce more terminology and concepts.

Computational Asymmetry & The Witness

As you read about ZKPs you will come across the term 'witness', this is what we call the secret data, the information that Peggy knows and wants to prove she knows, but doesn't want to reveal to Victor.
The statement is the claim that Peggy is making, she is claiming that she knows the witness, it is this claim that is to be proven.

A fundamental concept in cryptography is Asymmetry, we shall return to this many times in the journey.
In computation there is a difference between doing the work and checking the work.
For example

Finding the Alien Artifact (The Witness): This is hard. It requires a vehicle, fuel, time, and luck. It is computationally expensive.
Checking the Photograph (The Statement): This is easy. It takes a split second.

If solving a problem were easy, we wouldn't need a proof—we would just solve it ourselves.
ZKPs rely on this imbalance, indeed this is an aspect of ZKPs that can seem too good to be true.
We can prove we have done the "hard work" (found the Witness) without forcing the Verifier to redo the whole journey.

This comes into play when we design ZKP systems, we often say that the system needs to be 'succinct' , that is the proof should be small enough to be manageable, and the time taken to verify it should be reasonably short.
Later in our journey I will be much more rigorous about these definitions.

The Crossing into the Sea of Rains (Mare Imbrium)

We cannot drive over the Apennine mountains. We have to pass through the Hadley-Apennine Gap (this is where Apollo 15 landed).

This is a narrow corridor where the mountains meet the marshy Palus Putredinis (Marsh of Decay).

To our immediate left, a massive winding canyon called Hadley Rille, to the right, the towering Mount Hadley.

We won't climb the Apennines yet that is a challenge for Chapter 4, when we tackle the heavy lifting of Abstract Algebra.

Once we clear the mountains, the world opens up. We enter the Sea of Rains.
This is a gigantic, flat impact basin.
It is an ocean of stone.
We have 1,000km of open driving here.

We navigate by three massive craters in the distance: Archimedes, Autolycus, and Aristillus.

Crossing the Terminator

As we travel northwest we will come to the terminator line, marking the boundary between day and night.
On Earth light is reflected from the atmosphere giving a period of dusk.
The lack of atmosphere on the moon means that the change from day to night is much more abrupt.

Such a sharp distinction between light and dark is something we want for our proofs. we want an exact and easily tested cutoff between a valid and an invalid proof.

In the underlying maths, we achieve this through probability. While theoretically 'probabilistic', the chance of a false proof being accepted is so vanishingly small (like guessing a specific grain of sand in this desert) that for all practical purposes, it is a sharp, solid wall.
Victor can be as confident in the math as he is that the Earth will never set

Looking ahead

The shadows are getting longer. The math is about to get steeper.
Next stop: Sinus Iridum where we will learn that every secret is just a point on a polynomial curve.

For more resources about ZKPs and Maths visit our Academy
This content will always be free, if you would like to support our work, you can donate
to the following addresses :
Bitcoin : bc1q528tct2mgn7zl99reuaj0ag770asgeurce5kkl
Ethereum : 0xcc1E7bdA08Abdcf164E9D2E4f78aEDb1d811593D

The Quantum Event Horizon: Cryptographic Vulnerabilities in the Ethereum Network

Erick Fernandez — Mon, 29 Dec 2025 15:38:50 +0000

The intersection of quantum computing and blockchain presents a substantial cryptographic challenge. As Ethereum secures hundreds of billions in digital assets, its reliance on classical Elliptic Curve Cryptography (ECC) constitutes a quantifiable risk.

There has recently been much debate, often acrimonious, about this risk.
In this series of three articles I will provide the technical background and examine the threats to Ethereum, Bitcoin and the process of transitioning to a quantum safe blockchain.

In this first article I want to explore the threat that, what are known as Cryptographically Relevant Quantum Computers (CRQCs), pose to the Ethereum ecosystem.
Even if we can transition to Post-Quantum Cryptography (PQC) we will face economic as well as purely cryptographic challenges.
The primary candidate solution, Module-Lattice-Based Digital Signature Algorithm (ML-DSA), entails signature sizes 40 to 60 times larger than current standards.
To move to this would have severe consequences for gas costs and network throughput. Successful migration depends on Account Abstraction (ERC-4337) and the maturation of Layer 2 scaling solutions to manage the associated data overhead.

The Cryptographic Debt of the Decentralised Economy

Ethereum relies on the computational hardness of the discrete logarithm problem to secure Externally Owned Accounts (EOAs) via the secp256k1 curve and in the consensus mechanism via the BLS12-381 curve.
These primitives were selected for efficiency and compact signature sizes. however, the emergence of quantum computing invalidates the assumption that deriving a private key from a public key is computationally infeasible.

Unlike classical computers, quantum algorithms can solve the discrete logarithm problem in polynomial time, if you are unfamiliar with this term, you can think of this as being a feasible amount of time.
For a permissionless blockchain, this point is critical; if the underlying cryptography is compromised, then the ledger loses integrity.

Quantum Mechanics and Cryptographic Vulnerability

Lets have a look at what is possible in quantum computation, the threat to cryptography is affected by algorithmic efficiency and hardware stability, specifically the distinction between physical and logical qubits.

Quantum algorithms : Shor’s algorithm and Grover's algorithm

Shor’s algorithm provides an exponential speedup in solving the hidden subgroup problem. While classical algorithms require exponential time to solve the Elliptic Curve Discrete Logarithm Problem (ECDLP), Shor’s algorithm reduces this to polynomial time.
What this means for blockchains is that a CRQC could effectively break the ECDSA scheme, authorising transactions by deriving a private key from a public key rapidly.
Another quantum algorithm Grover’s algorithm offers only a quadratic speedup for hashing algorithms like Keccak-256.
This reduces 256-bit security to 128-bit security, which remains is still seen as robust robust.
Consequently, the immediate failure point is the signing algorithm, not the hash function.

The 523 Logical Qubit Threshold

A critical metric for forecasting the threat is the number of logical qubits (error-corrected units) required to break secp256k1. Recent research suggests an algorithmic lower bound of 523 logical qubits. Even conservative models estimating 2,500 logical qubits present a concerning timeline when compared against hardware roadmaps projecting systems with over 1,000 logical qubits by the early 2030s.

The Intercept Problem

The urgency arises from the disparity between hardware velocity and migration latency. Quantum development is accelerating, while upgrading a decentralised protocol requires social consensus, standardisation, and user migration. If hardware capabilities outpace the migration timeline, Ethereum faces an "intercept" scenario where the network is vulnerable before defences are fully deployed.

Ethereum’s Unique Attack Surface

Ethereum’s architecture creates specific vulnerabilities across the execution and consensus layers.

Execution Layer: Externally Owned Accounts (EOAs)

An Ethereum address is a hash of the public key. Addresses that have never sent a transaction are quantum-safe because the public key remains unrevealed. However, once a transaction is signed and broadcast, the public key is recorded on the blockchain. A quantum attacker could harvest exposed public keys from the chain's history and derive the corresponding private keys from those.

This specifically threatens high-value targets such as protocol treasuries and early adopters who reuse addresses.
Unlike the UTXO model which encourages address rotation, Ethereum's account-based model encourages identity persistence, increasing the attack surface.

The risk to the consensus layer: BLS Signatures

The Proof-of-Stake mechanism utilises BLS signatures for their aggregation properties, allowing thousands of validator attestations to be verified simultaneously. A quantum breach of the BLS scheme would allow attackers to forge attestations, equivocate without penalty, and compromise finality.

The Mempool: Quantum Front-Running

Migration itself presents a risk. When a user broadcasts a transaction to move funds to a quantum-secure wallet, the public key is revealed in the mempool. A quantum adversary could derive the private key and broadcast a competing transaction with a higher gas fee, effectively stealing the funds before the migration transaction is processed. We will explore this risk further in the final article in the series.

Post-Quantum Cryptographic Alternatives

To mitigate these risks, Ethereum must transition to PQC standards finalised by NIST in 2024, here are some candidate solutions.

Lattice-Based Cryptography: ML-DSA

The primary candidate is ML-DSA (formerly Dilithium). It relies on the 'Module Learning With Errors' problem. While verification is computationally efficient, the data requirements are significant.
An ML-DSA signature is approximately 3,309 bytes, compared to 65 bytes for ECDSA. This represents a substantial increase in data availability costs.

Hash-Based Cryptography: SLH-DSA

SLH-DSA (formerly SPHINCS+) serves as a conservative backup relying solely on hash functions. However, its signature sizes (8KB to 30KB) and slow verification speeds make it impractical for standard transaction throughput.

Zero-Knowledge Proofs (STARKs)

STARKs offer a blockchain native alternative. They allow users to generate a proof of knowledge of a private key. Their primary advantage is recursive aggregation, where thousands of proofs can be compressed into a single proof, potentially resolving the scaling issues inherent in other PQC solutions.

Comparative Analysis of these solutions

Feature	ECDSA (Current)	ML-DSA	SLH-DSA	STARK Proofs
Problem	Discrete Logarithm	Module Lattices	Hash Functions	Hash Functions
Quantum Resistance	Broken	Strong	Very Strong	Very Strong
Public Key Size	33 bytes	1,952 bytes	32-64 bytes	N/A (Hashed)
Signature Size	65 bytes	3,309 bytes	~8KB - 30KB	Tiny (Aggregated)
Gas Cost	Low	High	Prohibitive	High Fixed Cost

The Economics and Feasibility of Transition

The "defensive downgrade" we face highlights that PQC migration increases costs without immediate functional benefits.

Gas and Throughput

Ethereum’s block gas limit constrains computational throughput. The 50-fold increase in signature size required by ML-DSA would drastically raise the base cost of transactions due to calldata pricing.
Without optimisation, this could reduce Layer 1 throughput by 70-80%.

State Bloat and Centralisation

Moving to larger public keys increases the size of the Ethereum state. This necessitates higher hardware requirements for node operators, potentially driving centralisation.
Solutions such as Stateless Clients or Verkle Trees (alreaady part of the Ethereum roadmap) are essential prerequisites to mitigate this bloat.

Account Abstraction

Account Abstraction (ERC-4337) is critical for migration. It decouples the asset-holding address from the signature scheme, allowing Smart Contract Wallets to upgrade their validation logic.
With this we couls have a smooth transition where wallets can rotate from ECDSA to ML-DSA or STARKs without moving funds to a new address.

Emergency Response: The Quantum Hard Fork

In the event of a sudden quantum breakthrough, a "Freeze and Recover" strategy has been proposed.

Rollback: The chain reverts to a state prior to the attack.
Freeze: The protocol rejects all EOA transactions.
Recovery: Users prove ownership via ZK-proofs of their seed phrase (which remains quantum-secure as it is hashed).

This approach carries significant governance risks. The coordination required to execute a hard fork takes time, during which markets could suffer catastrophic disruption. Furthermore, the political decision of when to rollback could undermine trust in the network's immutability. Recall the controversy regarding the DAO hardfork.

Conclusion

The vulnerability of secp256k1 to a quantum computer with approximately 523 logical qubits places the risk horizon potentially within the early 2030s.
While emergency protocols exist, they would entail severe economic disruption.
The sustainable path involves proactive adoption of Account Abstraction and ML-DSA signatures.
This transition will fundamentally alter network economics, necessitating reliance on Layer 2 scaling to absorb the data overhead required for post-quantum security.

Moon Math Itinerary: The Lunar Map of ZK

Erick Fernandez — Fri, 19 Dec 2025 15:33:13 +0000

They call it "Moon Math" because it feels alien.

They call it "Zero Knowledge" because it feels impossible.

I’m writing a new series to demystify the foundational math of ZKPs. But instead of dry textbooks, we’re mapping the maths to a journey around the Moon.

The Itinerary:

1. Sea of Tranquility: The Paradox of Privacy.

2. Bay of Rainbows: Turning Code into Curves (Polynomials).

3. Ocean of Storms: The endless sea of Finite Fields.

4. The Far Side: The dark, complex world of Elliptic Curves.

...and 4 more stops ending at the Peaks of Eternal Light.

From the safety of the Near Side to the complex geometry of the Far Side—we’re going to map it all.

Our first stage takes us from the Sea of Tranquility to the Bay of Rainbows, from bottom right to top left on the chart.

Why Zero Knowledge Proofs are like a Lunar Landscape.

Erick Fernandez — Mon, 15 Dec 2025 13:30:50 +0000

We're writing a series exploring the famous "Moon Math" paper, but we are taking the name literally.

We are going on an 8-stop journey around the Moon to learn ZKP

My favourite stop? Chapter 2: The Bay of Rainbows (Sinus Iridum).

In ZKPs, the hardest mental shift is understanding how we turn a rigid computer program into a geometric shape.
It’s exactly like the landscape of Sinus Iridum.

We take scattered "rocks" of data—disconnected computational steps and use interpolation to smooth them into a continuous, perfect arc, just like the mountain range bordering the bay.

If you move just one rock (falsify one step of the code), the entire curve ripples and changes shape.

That "fragility" is how we prove truth without revealing secrets.

Join us to explore the beauty of the Moon and the beauty of Maths

An Analysis of Arbitrage Markets Across Ethereum, Solana, Optimism, and Starknet (2024-2025)

Erick Fernandez — Fri, 12 Dec 2025 17:57:01 +0000

The maturation of public blockchains into global financial layers has fundamentally altered the nature of arbitrage. In the nascent years of DeFi arbitrage was a game of simple scripts and public mempools a competitive but largely amateur pursuit.
By 2025, this activity has evolved into a hyper-specialised, institutional-grade industry that dictates the economic limits of blockchain scaling. MEV the total value that can be extracted from block production in excess of the standard block reward and gas fees, has become the dominant economic variable in the design and operation of these networks.

In this article I want to analyse from technical and economic perspectives, the arbitrage landscapes on four distinct blockchain architectures:

Ethereum Layer 1
Solana
Optimism
Starknet

Each network represents a distinct "MEV Regime" a unique combination of consensus mechanisms, transaction ordering rules, and latency constraints that forces arbitrageurs to adopt radically different strategies.

The analysis that follows is shaped by the following idea:

The structure of the underlying chain largely determines the behaviour of the bot

On Ethereum, the separation of proposers and builders has turned arbitrage into a sealed-bid auction for inclusion.
On Solana, the lack of a mempool and the speed of block production have created a latency-sensitive streaming auction.
On Optimism, the combination of low fees and centralised sequencing has incentivised a "spam-as-strategy" equilibrium.
On Starknet, Zero-Knowledge proof generation times and a developing decentralisation roadmap create a temporary environment of slower, atomic a

I have pulled together data and research from late 2024 and 2025, to quantify the number of active bots, their operational costs, and their expected profitability.
I also explore the structural shift from "code is law" to "ordering is economy," where the ability to order transactions is the primary product being sold by validators and sequencers.

The MEV Trilemma in 2025

Arbitrage strategies in the current market cycle are constrained by an "MEV Trilemma" that forces operators to optimise for two of three variables, often at the expense of the third.

Execution Certainty : The probability that a transaction, once submitted, will be included in a block in the exact state required to capture profit.
(High in Ethereum PBS; Low in Optimism FCFS).

Capital Efficiency (Cost) : The ratio of profit to the cost of execution, including failed attempts and infrastructure overhead.
(High in Solana; Low in Ethereum due to high gas/bribes).

Latency Sensitivity: The speed required to identify and capture an opportunity before a competitor.
(Critical in Solana and L2s; Less critical in Ethereum PBS due to bundle auctions).

Lets dig into the structure of the chains to shed light on this behaviour

Ethereum Layer 1: The Oligopoly of the Auction House

Ethereum L1 remains the undisputed "heavyweight" arena of global arbitrage.
While transaction volumes may be lower than high-throughput L1s or L2s, the value per transaction and the depth of liquidity create the largest absolute profit pool. However, the ecosystem has developed into a rigid hierarchy defined by Proposer-Builder Separation , where the "wild west" of priority gas auctions has been replaced by sophisticated supply chains.

The Supply Chain Architecture: Builders, Relays, and Searchers

To understand arbitrage on Ethereum in 2025, we must move away from the notion of the public mempool as the primary battleground. The vast majority of arbitrage transactions over 90% are now routed through private channels known as MEV-Boost. This system separates the role of the Proposer from the Builder.

Searchers run the algorithms that detect price discrepancies.
In 2025, searchers do not broadcast transactions to the public network. Instead, they submit "bundles"—atomic packages of transactions to builders. A bundle might contain a user's transaction followed immediately by the searcher's back run transaction.
The searcher attaches a direct payment to the builder to this bundle.
If the profit is say $100, the searcher might bid $90, keeping $10 as profit.
This high "bid-to-profit" ratio is the defining characteristic of Ethereum arbitrage.

Builders are the power brokers of the Ethereum network.
They aggregate bundles from thousands of searchers and optimise them to create the most profitable block possible. The market for block building has become heavily centralised.
Research indicates that by early 2025, the top two builders capture over 90% of block auctions.

Relays are the trusted intermediaries that pass the block headers from builders to validators, ensuring that the validator cannot steal the MEV inside the block.

This architecture means that for an arbitrage bot to be competitive on Ethereum, its primary "skill" is not just identifying the arbitrage opportunity, but correctly pricing the bribe.

A bot that consistently underbids will never have its transactions included.
A bot that overbids operates at a loss.

Bot Population and Market Concentration

Contrary to the popular image of thousands of bots competing for every trade, the viable professional arbitrage market on Ethereum is surprisingly small and concentrated.
Empirical analysis of MEV searchers reveals that in any given week, the number of unique "core" entities, those consistently winning bids and generating significant profit, often does not exceed 20.

This concentration is driven by the intense capital and technical barriers to entry.

Capital Requirements: To win a bundle auction, a searcher must often hold significant inventory of assets to execute the trade atomically.

Infrastructure Costs: While RPC costs might run $200-$500 monthly , the real cost is in the research and development of proprietary pricing models and simulation engines that allow a bot to bid 99% of the profit margin without going underwater.

The Long Tail: While there are hundreds of active addresses attempting arbitrage, the vast majority are "peripheral" participants who capture sporadic, lower-value opportunities or operate strategies that do not require fighting for the top-of-block position.

Profitability Analysis: The "Black Monday" Case Study

The scale of profits on Ethereum can be staggering during periods of volatility, but these windfalls are captured by a select few. A look at the market turmoil on August 5, 2024 ("Black Monday"), provides a granular view of potential earnings.

On this single day, a specific builder labelled MEV Builder 0x3b secured 1,448 ETH in rewards, valued at approximately $3.5 million at the time. This revenue was not generated by a single trade but by constructing blocks containing massive liquidations and arbitrage opportunities.

Liquidation Efficiency: In Block 20459000, a liquidation event sent 358.7 ETH ($802,000) to the builder.

Arbitrage Integration: Following this liquidation, an arbitrage bot executed a trade that paid 36 ETH to the builder.

This illustrates the "food chain" nature of Ethereum MEV.
The arbitrage bot (the Searcher) likely made a gross profit significantly higher than 36 ETH, but it was forced to pay that 36 ETH to the builder to ensure its transaction was included.
The builder, in turn, paid a portion of that to the validator.
The searcher's net profit is the remainder.
Data from ESMA and EigenPhi supports this, suggesting that searchers often pay more than 90% of their revenue to proposers.

Strategic Nuances: Sandwiching vs. Atomic Arb

Two primary strategies dominate the Ethereum landscape in 2025:

Atomic Arbitrage: The simultaneous buying and selling of an asset across different venues (e.g., Uniswap vs. SushiSwap) within a single transaction. This is risk-free in terms of market movement but carries execution risk (gas costs if the bundle fails, though Flashbots protects against this).

Sandwich Attacks: This controversial strategy involves placing a transaction before and after a victim's pending trade.
Despite improved user protections (like RPCs that hide transactions from the public mempool), sandwiching remains highly profitable.
Sophisticated bots continue to exploit users who set high slippage tolerances on DEXs.

However, the "low-hanging fruit" has diminished, forcing bots to target more complex, multi-hop trades.

Infrastructure Costs and Operational Overhead

Running a competitive arbitrage operation on Ethereum is capital intensive compared to other chains.

Gas Fees: The primary operating cost.
Even with Layer 2 scaling, L1 gas fees can range from $5 to $50 per transaction during congestion, and significantly higher during "gas wars".

Node Infrastructure: Competitive searchers run their own nodes or pay for premium, low-latency RPC services. The cost for a dedicated Ethereum node setup can range from hundreds to thousands of dollars monthly depending on the provider and the level of geographic distribution required.

Simulation: Successful bots run complex off-chain simulations of the Ethereum state to calculate the exact outcome of a trade before submitting the bundle. This requires substantial compute power, adding to the monthly burn rate.

Solana: The High-Frequency Trading Floor

If Ethereum is an auction house, Solana is a high-frequency trading floor.
The network's architecture characterised by 400ms block times, the absence of a public mempool, and a unique "Leader Schedule" creates a fundamentally different environment for arbitrageurs.
Between 2024 and 2025, Solana underwent a radical transformation from a network plagued by spam to one disciplined by the Jito auction mechanism.

The Gulf Stream and The Leader Schedule

Unlike Ethereum, where transactions wait in a mempool to be picked up, Solana forwards transactions directly to the "Leader" the specific validator scheduled to produce the next block.
This protocol, known as Gulf Stream, eliminates the global mempool and theoretically reduces latency.
However, in the absence of a fee market, this design historically encouraged "spam as a service."
Arbitrage bots would flood the Leader with thousands of duplicate transaction requests, hoping that one would be processed first.
This often caused network congestion and outages.

The Jito Revolution: Ordering as a Product

The introduction and widespread adoption of the Jito-Solana client has been the single most significant development in Solana's MEV ecosystem.
By early 2025, validators running Jito software control over 92% of the network stake.

Jito creates an out-of-protocol auction mechanism similar to Flashbots but optimised for Solana's speed.

Bundles : Searchers submit bundles of transactions with a guaranteed tip.

The Auction: Jito's Block Engine simulates these bundles and forwards the most profitable ones to the validator.

Spam Reduction: Because the auction happens off-chain and only the winning bundle is submitted, the incentive to spam the network is drastically reduced for Jito-connected validators.

The economic impact has been profound.
In April 2023, Jito tips accounted for only ~10% of priority fees.
By early 2025, they exceed 60%, indicating that professional arbitrageurs have almost entirely migrated to this auction model.

Bot Ecology: The "Whales" of Solana

The Solana arbitrage market is dominated by a few hyper-active entities. On-chain forensic analysis has identified specific bot addresses that capture massive market share.

The "E6Y" Bot Case Study:

One specific bot, identified by the address prefix E6YoRP..., has been observed capturing 42% of the entire sandwich attack volume on Solana.

Volume: In a single 30-day period, this bot executed trades worth over $1.6 billion.

Revenue: The bot generated a gross revenue of 57,400 SOL.

Costs: It paid 2.8 SOL in transaction fees and a staggering 7,980 SOL in Jito tips.

Net Profit: The operation netted approximately 49,400 SOL, which translates to roughly $300,000 per day at the relevant market prices.

Other Major Players:

The second-largest bot (89Ny...) processed $433 million in volume (11.2% market share).
The third-largest (B91...) processed $277 million (7.2% market share).

Another case study of the B91 sandwich bot showed it extracting 7,800 SOL in gross profit over 30 days, victimising nearly 78,800 retail traders.

These figures illustrate a "power law" distribution where the top 3 bots control over 60% of the market.
This concentration is likely due to the extreme technical difficulty of building low-latency infrastructure that can compete in 400ms block times.

Aggregate Market Statistics

Broader market data confirms the scale of arbitrage on Solana.

Transaction Count: Jito's detection algorithms identified over 90 million successful arbitrage transactions over a one-year period ending in 2025.

Total Profit: These transactions generated $142.8 million in profits.

Average Profit: The average profit per arbitrage transaction is significantly lower than Ethereum, sitting at just $1.58.
This confirms the "high frequency, low margin" nature of Solana MEV compared to Ethereum's "low frequency, high margin" model.

Infrastructure and Costs

Running a competitive Solana bot is less about gas costs and more about hardware and connectivity.

RPC Costs: High-performance, dedicated RPC nodes are a prerequisite. Providers like RPC Fast, Triton One, and Helius offer dedicated nodes ranging from $1,800 to $3,800 per month.

Co-location: The most sophisticated searchers co-locate their servers in the same data centres as major validators to shave milliseconds off transmission time.

Geyser Plugins: Advanced bots use "Geyser Plugins" to subscribe directly to account updates from the validator, bypassing the standard RPC overhead entirely.

Optimism and The Superchain: The Paradox of "Spam-Based Arbitrage"

The arbitrage landscape on Optimism, and the broader "Superchain" ecosystem (including Base), presents a fascinating economic paradox in 2025. While these networks are designed to be efficient and low-cost, the very cheapness of their block space—combined with a centralised sequencing model—has birthed a "spam-as-strategy" equilibrium.

The "Priority Fails" Phenomenon

A groundbreaking research paper titled "When Priority Fails" provides the definitive analysis of arbitrage behaviour on Optimistic Rollups in 2025. The research uncovers a counterintuitive reality:

The Mechanism: Optimism uses a single centralised sequencer that orders transactions on a First-Come-First-Served (FCFS) basis (with some priority fee nuances).

The Incentive: The Dencun upgrade (EIP-4844) drastically reduced the cost of posting data to L1, making L2 transactions incredibly cheap (fractions of a cent).

The Strategy: Instead of building complex bidding systems to win a specific slot (like on Ethereum), arbitrage bots find it cheaper to simply flood the sequencer with duplicate transactions.
If a bot wants to capture an arb, it might send the same transaction 50 times. It doesn't matter if 49 fail; the cost of failure is negligible compared to the potential profit.

Quantifying the Spam

The data on this phenomenon is stark.

Revert Rates: Following the Dencun upgrade, the rate of reverted transactions on L2s spiked from under 5% to over 10%.

Composition: 80% of these reverted transactions are swaps, and 50% target USDC-WETH pools on Uniswap v3/v4. This confirms that the reverts are not user errors but failed arbitrage attempts.

Concentration: The spam is not evenly distributed. On Base, a key member of the Optimism Superchain, just two searcher entities were responsible for more than 80% of all spam.

Sequencer Revenue and the "Invisible Tax"

While this spam congests the network for users, it is highly profitable for the network operators.

Revenue Capture: The centralised sequencer collects fees for every transaction, successful or failed. Reverted transactions contribute disproportionately to sequencer revenue. On Base, reverts generate roughly 20-25% of total priority fee revenue.

Welfare Transfer: This dynamic represents a transfer of welfare from users (who experience slower networks) and unsuccessful searchers (who burn fees) to the Optimism Collective and Base.

Bot Profitability and Market Structure

Volume vs. Users: On-chain analysis of Optimism reveals a "tale of two metrics." Transaction counts have surged to all-time highs (1.88 million daily), while active address counts have remained stagnant at ~63,000. This divergence is a clear signal that the network's growth is being driven by bot activity rather than organic user adoption.

Profit Margins: The barriers to entry for this strategy are incredibly low. Any developer with a script can spam the sequencer. This leads to a "race to the bottom" where margins are compressed to the point where the profit of the arb barely exceeds the cost of the spam.
Unlike the oligopoly of Ethereum or the "whale" dominance of Solana, Optimism is a chaotic arena of high-volume, low-margin grinders.

Base Revenue Contribution

The revenue generated by this activity flows back to the Optimism Collective. In October 2025, Base contributed 44.8% of the total revenue obtained by the Optimism Collective (244.9 ETH), while other chains contributed 13.8%. This highlights how critical the high-volume arbitrage economy on Base is to the sustainability of the broader Superchain.

Starknet: The ZK Frontier

Starknet represents the frontier of arbitrage, operating under the constraints of a Zero-Knowledge Rollup architecture.
The MEV landscape here is nascent, constrained by centralised sequencing and longer confirmation times, but is poised for radical change as the network decentralises.

Unique Constraints: The Validity Proof Bottleneck

Arbitrage on Starknet differs fundamentally from Optimism or Solana due to the mechanics of validity proofs.

Prover Latency: Transactions must be proven valid before they are finalised on L1. While "soft finality" on L2 is faster, the overall cadence of the network is different.

FCFS Ordering: Like Optimism, Starknet currently uses a centralised sequencer with First-Come-First-Served ordering.

No Mempool: Starknet does not have a public mempool. Transactions are sent blindly to the sequencer. This makes "sandwiching" difficult because a bot cannot see a victim's transaction in a pool and insert its own around it.

Dominant Strategy: Atomic Arbitrage and "MAV"

With sandwich attacks largely neutered by the architecture, the dominant strategy is pure Atomic Arbitrage (DEX-DEX or CEX-DEX).

Cross-Domain Opportunities: Bots monitor price discrepancies between Starknet AMMs (like Ekubo and Nostra) and centralised exchanges (CEXs). Because Starknet blocks are slower than a CEX order book, there is significant "stale" pricing on-chain that bots can exploit.

Maximal Arbitrage Value (MAV): Researchers are using a new metric called MAV to quantify these opportunities, specifically looking at the lag between CEX price movements and AMM updates.

Ecosystem Growth and Barriers

Technical Barrier: The requirement to interact with Cairo smart contracts creates a moat. Standard Solidity bots cannot be simply copy-pasted onto Starknet; they must be rewritten, often requiring a deep understanding of the Cairo VM.

Growth: Despite these barriers, the ecosystem is expanding. Starknet grew from 72 to 193 user-centric projects in 2024, a 168% increase.

Bot Population: The active bot population is significantly smaller than the other chains, numbering in the dozens rather than the hundreds. However, as liquidity deepens, this is expected to change.

The Decentralisation Roadmap (2025-2026)

The most critical factor for Starknet's MEV future is its roadmap.

Staking v2/v3: Planned for late 2025, these upgrades will decentralise the sequencer and introduce a consensus mechanism.

MEV Market Emergence: As the single sequencer is replaced by a network of validators, an MEV market will inevitably emerge to manage ordering. Whether this takes the form of an auction (like Jito) or a different mechanism will determine the future profitability of bots on the network.

Comparative Synthesis: Metrics and Outlook

To visualise the stark differences between these ecosystems, the following data synthesise the key metrics derived from the research.

Comparative Metrics Table (2024-2025)

Metric	Ethereum L1	Solana	Optimism (Superchain)	Starknet
Est. Monthly MEV Revenue	~$180 Million	~$45 Million	Undisclosed (High Sequencer Revenue)	Developing / Niche
Dominant Strategy	Bundle Auctions (99% Success)	Stream Auctions & Latency	Probabilistic Spam (High Fail Rate)	Atomic Arbitrage (Latency)
Active "Core" Bots	<20 Entities (Oligopoly)	Top 3 Bots = ~60% Market	High Concentration (2 entities = 80% spam)	Specialised / Low Count
Top Bot Earnings (Est.)	Millions/Day (Outliers)	~$300k/Day (Top Sandwicher)	Volume-driven, thin margins	Moderate / Lower Liquidity
Avg. Profit Per Arb	High (\$100s - \$1000s)	Low (~$1.58)	Cents (offset by spam cost)	Moderate
Primary Cost Driver	Bribes to Builders (90%+ of Rev)	Jito Tips + Hardware	Gas for Failed Txs	Proving/Gas Fees
Infrastructure Cost	High (\$200-\$500 RPC + R&D)	Very High (\$1.8k-\$3.8k RPC)	Low	Moderate

The Strategic Landscape

Ethereum is a "Whale's Game": The market is mature, calcified, and expensive. Success requires deep relationships with builders and massive capital. The "alpha" here is in complex, multi-block strategies and off-chain hedging.

Solana is a "High-Frequency Trader's Game": It is the closest analogue to traditional finance (TradFi) markets. Success is determined by hardware, co-location, and the efficiency of the bidding algorithm in the Jito auction. The volume is massive (90M+ arbs/year), but the per-trade margin is razor-thin.

Optimism is a "Spammer's Game": It is a chaotic, unregulated market where the lack of an efficient auction mechanism forces participants to engage in wasteful behaviour. It is the most accessible market for new entrants but arguably the least efficient.

Starknet is the "Frontier": It offers the highest potential for "informational alpha" due to the technical barriers of Cairo and the ZK architecture, but lacks the deep liquidity of the other chains.

Future Outlook: The Convergence?

As we look toward late 2025 and 2026, the distinctions may blur.

Cross-Chain MEV: The rise of cross-chain bridges and unified liquidity layers (like LayerZero) is creating a new class of arbitrage that spans these networks. Bots are already beginning to arb the price difference between Solana (fast) and Ethereum (liquid).

Solution to Spam: The unsustainable nature of the spam on Optimism and Base will likely force the adoption of "Shared Sequencing" or decentralised auction mechanisms similar to Flashbots, bringing order to the chaos.

Institutionalisation: Across all chains, the trend is clear. The solo developer is being squeezed out by capitalised firms that can afford the $3,000/month RPC nodes, the co-location fees, and the specialised engineering talent required to compete in a market where margins are measured in basis points and milliseconds.

In conclusion

Arbitrage in 2025 is not a story of code, but of market structure.
The bot is merely a rational actor optimising for the specific constraints be they auctions, leader schedules, or sequencer latencies imposed by the chain it inhabits.

Originally published on: academy.extropy.io

A Developer's Guide to Implementing the x402 Protocol

Erick Fernandez — Thu, 11 Dec 2025 15:53:15 +0000

This guide follows on from our previous article about EIP-3009, you can read that here

For developers, the x402 protocol is a practical toolset for monetising web services. It offers a direct alternative to cumbersome API key management and inflexible subscription models, enabling a true, pay-per-use economy.

At its core, x402 is an open-source standard that activates the long-dormant HTTP 402 "Payment Required" status code. It provides a chain-agnostic choreography for an AI agent or client to pay for a resource, like an API call, at the very moment it is requested.

The Server-Side: "One Line of Code" Monetisation

If you are a developer looking to monetise an API (the "supply" side), the integration is simple. Using middleware libraries for popular frameworks, you can payment-gate an endpoint with just a single line of code.

For a Node.js server (using Express for example), the implementation looks like this:

// This example shows how to protect an endpoint and set a price
app.use(
  paymentMiddleware("0xYourWalletAddress", {
    "/your-premium-endpoint": "$0.01" 
  })
);

// That's it. This endpoint is now monetised.
app.get("/your-premium-endpoint", (c) => {
  return c.json({ data: "secret premium data" });
});

This middleware automatically handles the entire payment negotiation, verification, and settlement flow, allowing you to focus on your application's logic.

So what is happening behind the scenes ?

The Core x402 Handshake

While the middleware makes it simple, it's crucial to understand the three-phase HTTP handshake that happens under the hood.

Phase 1: Request → Quote

Initial Request: The client (which could be an AI agent) makes a standard GET request to your protected resource (/your-premium-endpoint).
Payment Required: Your server's middleware intercepts this. Seeing no payment, it returns an HTTP 402: Payment Required status.
Quote: The body of this 402 response is a JSON payload. This is the "bill," specifying the PaymentRequirements, such as the price (0.01 USDC), the supported network (e.g., Base), and the facilitator's API endpoint.

Phase 2: Pay → Verify

Sign Payload: The client's logic (see below) receives the 402, parses the JSON "bill," and creates a payment payload. It then signs this payload off-chain using its private key.
Retry with Payment: The client retries the original request. This time, it includes a new HTTP header: X-PAYMENT. The value of this header is the Base64-encoded JSON Payment Payload, which contains the signed authorisation.

Phase 3: Settle → Deliver

Verify Payload: Your server's middleware intercepts the new request. It doesn't need to understand crypto; it simply forwards the X-PAYMENT payload to the specified facilitator's POST /verify endpoint. The facilitator cryptographically verifies the signature and returns a simple {"isValid": true}.
Settle & Deliver: Once verified, the server does two things in parallel: it fulfils the request (granting access to the data) and sends the payload to the facilitator's POST /settle endpoint to execute the on-chain transfer.
Confirmation: The server returns the final HTTP 200 OK response to the client, containing the requested resource. It also includes an X-PAYMENT-RESPONSE header, which contains the transaction hash as a receipt.

The Role of the Facilitator

The "magic" that makes the server-side implementation so simple is the facilitator. This is a third-party service that acts as the bridge between your HTTP-native server and the blockchain.

Your server remains crypto-agnostic. It never holds keys, runs a node, or pays for gas. It simply makes two stateless REST API calls (/verify and /settle) to a trusted facilitator (like those provided by Coinbase, Meridian, or Mogami), which handles all the on-chain complexity.

The Client-Side: Building an x402-Aware Agent

While the server-side is simple, the client bears the burden of complexity. Developers building agents must integrate client-side SDKs like @coinbase/x402-sdk and manage wallet capabilities.

The agent's core logic must be architected as a state machine capable of handling three scenarios:

Free Requests: Standard handling for response.ok.
Payment-Gated Requests: The primary logic path, triggered by response.status === 402. The agent must parse the 402, use its wallet to sign the payment, and manage the stateful retry with the X-PAYMENT header.
Payment Failures: Graceful error handling if the payment fails or the service fails after payment.

The "Gasless" Magic: How EIP-3009 is Used

The "gasless" client experience is another key technical component. The client doesn't need the network's native gas token (e.g., ETH) to make a payment.

This is enabled by the EIP-3009 standard (transferWithAuthorization). The client doesn't submit a transaction; it simply signs an off-chain authorisation message. The facilitator takes this signed message and submits it to the blockchain, paying the gas fee on the client's behalf.
This abstraction is what makes autonomous, high-frequency micropayments feasible.

Ultimately, x402 is a lightweight and open standard that provides the essential choreography for on-chain value exchange, finally turning the web's original, dormant "Payment Required" code into a live, usable rail for developers.

An Overview of EIP-3009: Transfer With Authorisation

Erick Fernandez — Tue, 09 Dec 2025 18:41:43 +0000

I've never been good with the EIP numbers, so if you are like me and wondering what this is about, this EIP is about making authorisation and transfer more user friendly.

One of the most persistent points of friction for web3 devs has been the user experience of on-chain transactions. EIP-3009, titled "Transfer With Authorisation," is a crucial (though still "Draft" status) protocol that directly tackles this problem.

While often discussed alongside other standards, EIP-3009 is a specific ERC-20 extension that, once implemented by a token, provides a new way to move assets. Its adoption by major stablecoins like USDC has made it a foundational component for the emerging machine-to-machine economy.

The Problem: Gas Fees and Clunky UX

Before EIP-3009, paying for something with an ERC-20 token was a famously clunky, two-step process for a user:

The approve Transaction: A user must first send a transaction to the token contract, calling the approve function to allow a smart contract to spend tokens on their behalf. This costs a gas fee.
The transferFrom Transaction: The user (or the smart contract) must then send a second transaction, calling transferFrom to actually move the tokens. This costs another gas fee.

This flow presents two critical problems:

Bad User Experience: It requires two separate transactions, two gas fees, and two wallet pop-ups.
The Gas Token Problem: The user must hold the network's native token (e.g., ETH on Ethereum) to pay for gas, even if they only want to spend their USDC. This is a massive onboarding barrier for new users and a non-starter for autonomous AI agents that cannot easily manage multiple wallet balances.

How EIP-3009 Works: The "Gasless" Authorisation

EIP-3009 solves this by introducing the concept of meta-transactions for transfers. Instead of sending an on-chain approve transaction, the user signs an off-chain message that authorises a transfer.

This flow is designed to be handled by a third-party "relayer" or "facilitator."

Step 1: Off-Chain Signing (The Client)
The user (or an AI agent's wallet) does not create a transaction. Instead, it creates a structured, EIP-712 compliant typed message. This message contains the precise details of the transfer:
- The token holder's address (from).
- The recipient's address (to).
- The value to be transferred.
- A validAfter and validBefore timestamp (to prevent replay attacks).
- A unique, random nonce (a bytes32 hash).
The client signs this message with its private key, producing a cryptographic signature.
Step 2: The Relayer (The Facilitator)
The client sends this signed message (the authorisation) to a relayer. This relayer can be any service willing to submit the transaction and pay the gas fee (e.g., the x402 facilitator).
Step 3: On-Chain Execution (The Contract)
The relayer takes the signed message and calls a new function on the ERC-20 contract: transferWithAuthorization(...).

This function accepts the signed message parameters (from, to, value, nonce, signature, etc.). The token contract itself then performs the following logic:
- It reconstructs the EIP-712 message.
- It uses ecrecover to verify that the signature matches the from address.
- It checks that the nonce has not been used before.
- It confirms the current time is within the validAfter and validBefore window.
If all checks pass, the contract executes the transfer internally. The user's tokens are moved, and the relayer (who called the function) pays the gas fee.

Key Technical Features for Developers

For developers, two features of EIP-3009 are particularly important:

Atomic Transfer: Unlike EIP-2612 (permit), which only authorises an approval, EIP-3009 authorises the entire transfer. It is a single-call execution.
Non-Sequential Nonces: A traditional Ethereum account uses a sequential nonce (0, 1, 2, 3...). This creates a bottleneck, as you cannot process transaction 3 until 2 is confirmed. EIP-3009's nonce is a random bytes32 hash. This is a critical design choice for high-frequency systems, as it allows an agent to generate thousands of concurrent, independent payment authorisations without any of them conflicting.

The Problem: A Fragmented Standard

If you are thinking we have been here before, well yes, there have been a few attempts to solve this problem.
In fact EIP-3009's primary weakness is not technical but strategic: it is not the only standard. This has fragmented the ecosystem:

EIP-3009 (transferWithAuthorization): The standard for gasless transfers. Implemented by Circle for USDC (v2).
EIP-2612 (permit): A similar but incompatible standard for gasless approvals. Implemented by Maker for DAI.
No Standard: Tether (USDT), the largest stablecoin by market cap, implements neither standard and has stated it has no plans to.

This "token exclusivity" is the main limitation of protocols that rely on EIP-3009. While it provides a seamless experience for USDC, it cannot (by itself) support a truly chain-agnostic or token-agnostic payment layer, as it excludes a massive portion of the stablecoin market.
Despite this, I wanted to introduce this EIP to you as background for some our next articles about the x402 protocol.

Originally published on: academy.extropy.io

Forem: Erick Fernandez

A Rust-Powered Starfield in the Browser with Macroquad + WASM

Setting Up the Machine

1. Create the Project

2. The Blueprint (Cargo.toml)

3. The Glue (web/index.html)

The Stack: Macroquad & WASM

The Anatomy of a Star

The Infinite Loop (The Projection)

The Full Engine (Core Version)

Running the Engine

Automation (build.sh)

The Machine in Motion (The Polish)

1. Tighten the Spawn Volume

2. Increase Density and Speed

3. Center the Title

Final Optimized Code

What's Next?

References

Start the year securely with these development checklists

Start the year securely with these development checklists

Web3 Development General Security Checklist

1. Defensive Architecture & Fail-Safe Engineering

2. Precision Access Control & Authority Management

3. Identity Integrity & Cross-Chain Security

4. User Protection & Behavioural Security

Extropy Security Bytes: w1 & w2, 2026

Truebit: The $26 Million Zombie Code

Lessons Learned

Aave: The Governance Civil War

Lessons Learned

TMXTribe: The 36-Hour Bleed

Lessons Learned

Ledger: The Supply Chain Leak

Lessons Learned

MetaMask: The “Party Hat” Phishing Campaign

Lessons Learned

Futureswap: The Unverified Black Box

Lessons Learned

GlassWorm: The macOS Developer Trap

Lessons Learned

About Extropy

Into the Ocean

The $3 Billion Loss Year: End-of-Year Security Report

Some of the issues our audits uncovered this year

1. Incorrect Reward Accounting in Move Modules

2. total_supply Underflow Causing Global DoS (Move)

3. Settlement-Phase Financial Manipulation (Solidity)

4. Resolver / State Desynchronisation in ZK Games

5. Lack of Replay Protection & Weak Message Identity

Analysis: The State of Web3 Security

Recommendations for 2026

Future Outlook

Final Words

The Moon and the Maths: The Sea of Tranquility

Chapter 1 - The Sea of Tranquility

What will we take on our journey?

A conflict in the Sea of Tranquility

Leaving the Sea of Tranquility

The lunar surface

The ground rules for ZKPs

Integers

Rational Numbers

Integers , division and remainders

Congruence

Computational Asymmetry & The Witness

The Crossing into the Sea of Rains (Mare Imbrium)

Crossing the Terminator

Looking ahead

The Quantum Event Horizon: Cryptographic Vulnerabilities in the Ethereum Network

The Cryptographic Debt of the Decentralised Economy

Quantum Mechanics and Cryptographic Vulnerability

Quantum algorithms : Shor’s algorithm and Grover's algorithm

The 523 Logical Qubit Threshold

The Intercept Problem

Ethereum’s Unique Attack Surface

Execution Layer: Externally Owned Accounts (EOAs)

The risk to the consensus layer: BLS Signatures

The Mempool: Quantum Front-Running

Post-Quantum Cryptographic Alternatives

3. The Glue (`web/index.html`)

Automation (`build.sh`)