DEV Community: Duron Epps

Polygon and L2 Smart Contract Differences: What Auditors Find That Gets Protocols Rekt

Duron Epps — Tue, 07 Jul 2026 20:51:56 +0000

$3.8M drained from Umbrella Network in February 2022 because the attacker understood how on-chain conditions worked better than the protocol's own team did. The exploit wasn't exotic. It was a price manipulation attack made possible by low liquidity — the exact kind of liquidity environment that's normal on L2s and sidechains at launch. The team built for Ethereum mainnet economics. They deployed somewhere with different rules. That gap cost them everything.

This is the central problem with deploying to Polygon, Arbitrum, Optimism, Base, or any other L2/sidechain: the EVM is largely the same, so developers assume the security model is too. It's not. And auditors who don't understand the specific execution environment they're reviewing will miss the issues that matter most.

Here's What Actually Happens When You Deploy to an L2

The EVM compatibility is real. Your Solidity compiles. Your tests pass. Your mainnet fork works fine. What changes is everything underneath — block timing, gas economics, sequencer behavior, bridging trust assumptions, and oracle reliability. These aren't edge cases. They're load-bearing parts of your security model that work differently depending on where you deploy.

Take block timestamps. On Ethereum mainnet, miners have ~15 seconds of manipulation wiggle room on block timestamps. On Polygon's PoS chain, block times are around 2 seconds and validators control timestamps with similar relative flexibility — but the absolute precision is different, and anything using block.timestamp for time-sensitive logic (vesting, auctions, TWAP windows) needs to account for this. On Arbitrum, block.number doesn't return the Arbitrum block number by default in all contexts — it returns the L1 block number. If you're using block numbers for timing, you might be off by orders of magnitude.

The sequencer is its own attack surface. Arbitrum and Optimism run centralized sequencers right now. A sequencer can front-run your transactions, delay them, or reorder them in ways that Ethereum's mempool can't. This matters for any protocol where transaction ordering creates economic advantage — DEX arbitrage, liquidations, NFT mints with price curves. The sequencer operator has privileges your threat model probably doesn't account for.

And then there's the bridge. Every asset that moves from L1 to L2 went through a bridge contract. Every bridge contract has its own trust assumptions, delay windows, and failure modes. When you write a contract that depends on bridged tokens or cross-chain messages, you're inheriting those assumptions whether you know it or not.

The Code Reality: Where This Breaks in Practice

Here's a pattern I see constantly in L2 contracts — timestamp-dependent logic that worked fine in mainnet testing but creates exploitable windows on faster chains:

Vulnerable Pattern

// Solidity 0.8.24
// DANGEROUS: Assumes block timing similar to Ethereum mainnet
// Deployed on Polygon 2 second blocks destroy this assumption

contract VestingVault {
uint256 public constant VESTING_PERIOD = 30 days;
mapping(address => uint256) public vestingStart;
mapping(address => uint256) public vestedAmount;

function claimVested() external {
    uint256 elapsed = block.timestamp - vestingStart[msg.sender];
    uint256 claimable = (vestedAmount[msg.sender] * elapsed) / VESTING_PERIOD;

    // No upper bound check — on Polygon a validator with timestamp
    // manipulation ability can influence elapsed in a single block
    // In low-liquidity conditions this amplifies with oracle manipulation

    vestedAmount[msg.sender] = 0;
    vestingStart[msg.sender] = block.timestamp;

    token.transfer(msg.sender, claimable);
}

}

The bigger issue here isn't just timestamp manipulation in isolation. It's that on Polygon, if this contract also references an AMM price feed for any reason (say, for USD-denominated limits), the low liquidity typical of Polygon deployments means that price is cheap to manipulate in the same block. Stack the two together and you have a compound exploit vector that looks fine in mainnet fork tests because mainnet has deep liquidity.

The Corrected Version

// Solidity 0.8.24 — L2-aware vesting with OpenZeppelin 5.x patterns
// Works safely on Polygon, Arbitrum, Optimism

import "@openzeppelin/contracts/utils/math/Math.sol";

contract VestingVaultV2 {
uint256 public constant VESTING_PERIOD = 30 days;
uint256 public constant MAX_TIMESTAMP_DRIFT = 15 seconds; // explicit tolerance

struct VestingPosition {
    uint256 totalAmount;
    uint256 claimedAmount;
    uint256 vestingStart;
    uint256 lastClaimTime;
}

mapping(address => VestingPosition) public positions;

function claimVested() external {
    VestingPosition storage pos = positions[msg.sender];
    require(pos.totalAmount > 0, "No position");

    // Cap elapsed at VESTING_PERIOD — no over-claim possible
    uint256 elapsed = Math.min(
        block.timestamp - pos.vestingStart,
        VESTING_PERIOD
    );

    uint256 totalVested = (pos.totalAmount * elapsed) / VESTING_PERIOD;
    uint256 claimable = totalVested - pos.claimedAmount;

    require(claimable > 0, "Nothing to claim");

    // Update state before transfer (reentrancy protection)
    pos.claimedAmount += claimable;
    pos.lastClaimTime = block.timestamp;

    token.transfer(msg.sender, claimable);
}

// Use Chainlink L2 sequencer uptime feed before any price-sensitive logic
// https://docs.chain.link/data-feeds/l2-sequencer-feeds
function _checkSequencerUp() internal view {
    (, int256 answer, uint256 startedAt,,) = sequencerFeed.latestRoundData();
    require(answer == 0, "Sequencer down");
    require(block.timestamp - startedAt > GRACE_PERIOD, "Sequencer restarted recently");
}

}

Notice the _checkSequencerUp() pattern at the bottom. That's something Chainlink provides specifically for L2 deployments. When the Arbitrum or Optimism sequencer goes down and comes back up, price feeds can be stale. Protocols that don't check sequencer status have been exploited during exactly these windows. The Chainlink L2 Sequencer Uptime Feed is a direct fix for this — and it's almost never in contracts I see getting submitted for audit.

The Polygon-Specific Issues Nobody Talks About

Polygon PoS is technically a sidechain, not an L2. The distinction matters for security. Ethereum L2s like Arbitrum and Optimism inherit Ethereum's security for finality — fraud proofs or validity proofs anchor the state to L1. Polygon PoS does not. Its finality is secured by its own validator set, which is ~100 validators with economic security significantly lower than Ethereum mainnet. This is not a knock on Polygon — it's a fact that changes your threat model.

What this means practically:

A 51% attack on Polygon PoS is economically feasible in ways that Ethereum mainnet is not. This happened — Polygon was hit by a critical inflation bug in December 2021 (white-hat disclosure, ~$2M bounty paid) partly because the economic stakes of the chain itself were lower than mainnet

Bridge withdrawals from Polygon to Ethereum take ~3 hours with the PoS bridge and up to 7 days with the Plasma bridge. Contracts that assume atomic cross-chain operations will break

Gas token is MATIC (now POL), not ETH. Any contract that uses msg.value for ETH-denominated pricing and gets deployed to Polygon without adjustment is pricing in the wrong asset

That last one sounds obvious. You'd be surprised. I've seen it.

How I'd Catch This Before It Ships

When I'm auditing a contract destined for an L2 or Polygon, I run a different checklist than mainnet. Here's the actual walk-through:

Grep for every instance of block.timestamp and block.number. For each one, ask: what's the exploit if a validator/sequencer manipulates this by 30 seconds? By 3 minutes? On Polygon with 2-second blocks, 30 seconds is 15 blocks — meaningful for anything with short time windows.
Identify every oracle call. Is it Chainlink? Does it check the sequencer uptime feed? What's the heartbeat and deviation threshold for that specific feed on that specific chain — not mainnet? Chainlink's MATIC/USD feed on Polygon has different parameters than ETH/USD on mainnet. Don't assume.
Map all bridge interactions. Where do tokens come from? If they're bridged, what happens if the bridge is paused? What happens if a message is replayed? The Nomad bridge hack ($190M, August 2022) was a message validation failure — bridged assets are only as safe as the bridge contract's logic.
Check MEV exposure under sequencer conditions. Centralized sequencers on Optimism and Arbitrum can front-run. If your protocol's liquidation mechanism or dutch auction relies on competitive MEV to function correctly, a cooperative sequencer removes that competition. Model what happens when one entity controls ordering.
Test gas assumptions explicitly. L2 gas is cheap and variable in ways mainnet isn't. Contracts that use gas limits as a security mechanism (require(gasleft() > X), or designs that assume certain operations are too expensive to be worth attacking) need re-evaluation. An attack that costs $500 in mainnet gas might cost $0.02 on Polygon.

Static tools like Slither will catch some of the timestamp manipulation patterns and flag missing access controls. They won't catch the economic logic — the "this oracle is manipulable because liquidity is low on this specific chain" issue doesn't show up in a static scan. That requires contextual analysis of the deployment environment.

The Take That'll Surprise You

Everyone auditing L2 contracts is focused on reentrancy and overflow. Those are solved problems in Solidity 0.8.x with OpenZeppelin 5.x. The real killer on L2s right now is deployment environment assumptions — contracts that were secure on mainnet, passed a mainnet audit, and then got deployed to a chain with different block timing, different oracle behavior, and different economic conditions without a re-audit. The contract didn't change. The security model did.

Three protocols I know of have had material losses from exactly this pattern in the last 18 months. None of them made crypto Twitter's highlight reel because the amounts were under $5M. That doesn't mean you want to be the fourth.

Specific Actions to Take Right Now

If you're deploying to Arbitrum or Optimism: Implement the Chainlink L2 Sequencer Uptime Feed check in every function that reads a price oracle. The code is four lines. There's no excuse not to.

Audit your block.number usage: On Arbitrum, block.number returns the L1 block number in some contexts. Use ArbSys(address(100)).arbBlockNumber() if you need the actual Arbitrum block count.

Re-examine every time-locked function with the actual block time of your target chain. A 10-block delay is ~2 minutes on Ethereum. On Polygon it's 20 seconds. That's not a timelock, it's barely a speed bump.

Run your contract on the actual target chain's fork, not mainnet. Use --fork-url pointing to your L2 RPC in Foundry. Mainnet fork tests will lie to you about oracle prices and liquidity depth.

Before you ship: Paste your contract into SmartContractAuditor.ai. It flags L2-specific patterns — sequencer dependency, timestamp manipulation windows, oracle configuration issues — and explains in plain English why each one is dangerous in your deployment context. Thirty seconds before deploy beats thirty days after exploit.

The chains are different. The contracts need to know that. Make sure yours does before someone else discovers it first.

How I Built a Local ONNX AI Detector Inside a Chrome MV3 Extension

Duron Epps — Mon, 29 Jun 2026 21:03:48 +0000

Chrome's Manifest V3 killed a lot of the tricks extension developers relied on. No persistent background pages. No remote code execution. Strict CSP. And if you want to run a machine learning model inside a service worker — have fun, because nothing in the docs tells you how.

Here's how I got ONNX Runtime Web running inside a Chrome MV3 service worker for Faux Spy, an AI image detection extension.

Why Local Inference?

The naive approach: send every image to an API, get a result back. That works, but it's slow (network round trip), costs money for every scan, and fails when the API is down.

Our approach: run a local ONNX model as a pre-filter. If it's confident (>88% AI probability or <12%), return the result immediately. Only send ambiguous cases to the API. This reduces API calls by ~60% and makes obvious cases instant.

The Stack

ONNX Runtime Web (ort.min.js) runs ONNX models in browser JS
SMOGY AI Image Detector a 50MB binary classifier (class 0 = artificial, class 1 = human)
Chrome Cache API caches the model file so it only downloads once
OffscreenCanvas renders images in the service worker without DOM

The Hard Parts

Loading the model in a service worker

Service workers can't use importScripts for WASM files the way regular pages can. We had to import ORT as a module and configure the WASM binary path explicitly:

js
import * as ort from './lib/ort.min.js';
ort.env.wasm.wasmPaths = chrome.runtime.getURL('lib/');

Getting image pixels without canvas access Service workers don't have DOM or canvas access. We use OffscreenCanvas:

const bitmap = await createImageBitmap(blob, { resizeWidth: 224, resizeHeight: 224 });
const canvas = new OffscreenCanvas(224, 224);
const ctx = canvas.getContext('2d');
ctx.drawImage(bitmap, 0, 0);
const imageData = ctx.getImageData(0, 0, 224, 224);

ImageNet normalization in CHW format Most ONNX vision models expect CHW (channels-height-width) format with ImageNet normalization. Converting from RGBA pixel arrays:

const mean = [0.485, 0.456, 0.406];
const std = [0.229, 0.224, 0.225];
const float32 = new Float32Array(3 * 224 * 224);

for (let i = 0; i < 224 * 224; i++) {
float32[i] = (pixels[i*4] / 255 - mean[0]) / std[0]; // R
float32[i + 224*224] = (pixels[i*4+1] / 255 - mean[1]) / std[1]; // G
float32[i + 224*224 * 2] = (pixels[i*4+2] / 255 - mean[2]) / std[2]; // B
}

Label order — a bug that cost us a week The SMOGY model outputs [artificial_logit, human_logit] class 0 is AI, class 1 is real. We had them swapped. Every real image was getting "Definitely Faux" and every AI image was "No AI Detected." Check your label order before shipping.

The Result
Local inference adds ~200ms for the first run (model loading) and ~50ms for subsequent runs. The model achieves ~85% accuracy on easy cases, which is enough to filter before the API handles the hard ones. End-to-end for cached scans: under 100ms.

The extension is on the Chrome Web Store as Faux Spy. The detection architecture is open to questions drop a comment if you're building something similar.

Pre-Deploy vs. Post-Deploy Web3 Security: Two Different Problems

Duron Epps — Mon, 29 Jun 2026 02:39:50 +0000

The $625M Ronin Bridge hack wasn't a code bug it was a social engineering attack on validator keys. The $197M Euler Finance exploit was a code flaw that three separate audit firms missed over seven months in production. Two completely different failure modes, and the Web3 security industry keeps pretending one solution covers both.

It doesn't.

Stage One: Pre-Deployment (The Developer's Problem)

Before a contract is deployed, the threat surface is the code itself. Reentrancy bugs, unchecked return values, access control flaws, oracle manipulation vectors all of these are detectable in Solidity source before any funds are at risk.

The Euler Finance exploit is the clearest example of a pre-deployment failure. The vulnerable donateToReserves() function had been in production since August 2022 seven months before it was exploited in March 2023. Three audit firms reviewed the codebase. None caught it. The bug existed in the code the entire time.

Pre-deploy tools are designed to catch exactly this category of issue:

Reentrancy vulnerabilities the $60M DAO hack pattern, still appearing in 2024
Integer overflow/underflow in Solidity <0.8.0
Unprotected selfdestruct calls
Improper access control on privileged functions
Flash loan attack vectors in AMM logic
tx.origin authentication bypasses

This is where most legitimate audit work happens. A firm like Trail of Bits charges $100k–$300k per engagement to put senior researchers through a codebase for several weeks. AI-assisted tools like SmartContractAuditor.ai run analysis in under 60 seconds — not a replacement for a manual audit on a $50M protocol, but fast enough to surface systematic bugs before you spend $30k on a formal review.

The hard constraint here: none of this is useful after deployment. You can't audit a live contract and un-deploy it. Once the code is on-chain, pre-deploy tooling becomes irrelevant and post-deploy monitoring has to take over.

Stage Two: Post-Deployment (The Trader's Problem)

Once a contract is live, the threat shifts from "is the code broken?" to "is this token a scam?" These are fundamentally different questions that require fundamentally different tools.

Rug pulls don't require buggy code. The Squid Game token rug in October 2021 was technically competent the contract had a sell restriction that prevented anyone but the deployer from exiting. An audit tool would have flagged that function. Most people never looked.

Honeypots are the same pattern: clean-looking tokens where the buy function works perfectly and the sell function silently fails. Over 50,000 honeypot tokens launched on Ethereum in 2023 alone, according to on-chain analysis. A pre-deploy code audit wouldn't help a trader who encountered one of these tokens two weeks after launch — they didn't write the contract, and they never had access to the source.

What post-deploy monitoring catches that static analysis can't:

Rug pulls on newly launched liquidity pools ranked by ETH extracted from victims
Honeypot detection tokens where sells are silently blocked at the contract level
Real-time drain events as they happen, via WebSocket streams
Risk scoring on any deployed token address, in seconds
Trend analytics on scam frequency useful for spotting new attack patterns before they peak

The Nomad Bridge illustrates the cost of missing this layer. It lost $190M in August 2022, four months after a security review. The initial attack exploited a misconfiguration in a single transaction then hundreds of copycat transactions followed automatically. Real-time monitoring would have caught the first anomalous transaction and triggered an alert before most of the $190M drained.

The Workflow That Actually Works

If you're a developer shipping a contract:

Run AI pre-audit on your codebase before touching a formal review — catch the obvious bugs cheaply
Commission a manual audit if your TVL will exceed $1M or you're handling complex DeFi logic
Deploy with anomalous transaction monitoring in place, not just performance monitoring

If you're a trader or investor evaluating a new token:

Check the contract address against a real-time scam database before buying
Verify honeypot status — can you actually sell what you buy?
Set live alerts for drain events on protocols you're exposed to

Why "We Got Audited" Isn't a Security Posture

The audit firm model has dominated Web3 security for years and created a damaging mental shortcut: security = audit checkbox. It doesn't.

Getting audited means a researcher reviewed your code at a single point in time. It says nothing about:

Whether the deployed bytecode matches the reviewed source (it sometimes doesn't)
Whether functions added post-audit introduced new attack surfaces
Whether the token economics create deployer exit incentives
Whether someone is actively draining a liquidity pool right now

Security is a continuous posture, not a one-time event. Pre-deploy tools catch code bugs. Post-deploy monitoring catches live threats. Using only one is like installing a reinforced front door and leaving every window unlocked.

Where to Start

If you're building a contract and want to catch issues before spending on a manual audit: SmartContractAuditor.ai runs in under 60 seconds and is free to start.

If you're trading tokens or need live scam detection infrastructure: RektRadar has a free tier with real-time rug pull tracking and honeypot detection for Ethereum tokens.

Both problems are real. Both ends of the lifecycle need coverage. The teams that treat them as one problem are the ones making headlines for the wrong reasons.

Originally published at https://smartcontractauditor.ai/blog/pre-deploy-vs-post-deploy-web3-security

I Built an AI-Powered Smart Contract Auditor Looking for Feedback from Developers

Duron Epps — Mon, 29 Jun 2026 01:40:17 +0000

Smart contract security has come a long way, but one thing still stands out to me: many vulnerabilities are discovered much later in the development process than they should be.

Professional audits are essential before deploying production contracts, but they're expensive and usually happen near the end of development. I wanted to build something that helps developers catch issues much earlier.

So I started building an AI-powered Smart Contract Auditor.

What It Does

The goal isn't to replace security firms or experienced auditors. Instead, it's designed to act like an always-available security assistant while you're writing code.

Current features include:

Analyze Solidity smart contracts for common vulnerabilities
Detect common security issues such as reentrancy, unchecked external calls, and access control problems
Explain vulnerabilities in plain English
Suggest possible fixes
Generate a security score and audit summary
Produce reports that developers can review before deployment
Why I Started This Project

I've spent a lot of time learning blockchain development and noticed that many developers rely on a combination of documentation, static analyzers, and manual code reviews.

Those tools are incredibly useful, but I wanted something that could also explain why an issue matters instead of simply flagging it.

The goal is to help developers learn while improving their contracts.

Where I'd Like to Take It

Some ideas I'm exploring include:

GitHub repository scanning
Continuous monitoring of contracts
CI/CD integration
VS Code extension
Gas optimization suggestions
Multi-chain support
Interactive AI explanations for vulnerabilities
Security best-practice recommendations
I'd Love Your Feedback

If you're a smart contract developer, security researcher, or auditor, I'd really appreciate your thoughts.

Some questions I have:

What features would make you actually use a tool like this?
What existing tools do you rely on today?
What's your biggest frustration with current smart contract security tooling?
Would AI-assisted vulnerability explanations be useful, or would you rather see traditional static analysis?

Constructive criticism is more valuable than praise at this stage. My goal is to build something developers genuinely find useful.

Thanks for reading, and I look forward to hearing your thoughts.