DEV Community: Coins N Coinsequences

Delta Analysis: How to Audit a Uniswap Fork Without Wasting a Week

Coins N Coinsequences — Sun, 01 Nov 2026 11:33:06 +0000

Delta Analysis: How to Audit a Uniswap Fork Without Wasting a Week

Every DeFi protocol on an EVM chain is, statistically, a fork of something. A Uniswap V2 fork here, a PancakeSwap V3 fork there, a Compound fork in the lending corner. Bug bounty programs list these contracts as critical targets, and researchers — reasonably — point their tools at them.

Then nothing happens. Slither is silent. The audit report from 2021 says "no critical findings." The code has been live for years, processing billions in volume, with no exploit.

The mistake is treating an audited fork as a fresh codebase. The productive approach is delta analysis: identify exactly what the fork changed, and aim only at the delta. Everything else is a waste of time.

This post walks through the methodology I use, with public examples.

Why "just run Slither" fails

Static analysis tools are pattern matchers. They catch reentrancy, unchecked math, unsafe external calls — the classes of bug that have existed since 2016. On an audited fork, those patterns have already been flagged and resolved.

The bugs that survive audits are not pattern-detectable. They live in:

The fork's own additions (a reward mechanism, a migration path, a proxy layer)
Interactions between two audited contracts
Economic invariants that break under specific, legal user behavior
Access control that is present but wrong

Slither cannot find these. You have to read the code — but you have to read the right code.

The five-phase methodology

Phase 1 — Recon and scope mapping

Before any review, answer these questions in writing:

Which contracts are in scope? Copy the addresses verbatim.
Which of them are proxies? Run cast codesize on every address. Anything under ~1KB is a proxy; you need the implementation.
Who controls authority? Call owner(), admin(), getOwners(), getThreshold(). Then call cast codesize on that address. If it returns 0, the owner is an EOA — log it, but do not chase it. Bounty programs almost universally exclude "attacks requiring privileged addresses."
What does the protocol hold? For each contract, call balanceOf on the reward or value token. That number is your maximum damage estimate, and it tells you where to spend time.

Output: a SCOPE.md with all of the above. This document travels with you through the rest of the review.

Phase 2 — Delta analysis against the canonical source

For each contract, identify its upstream parent:

Uniswap V2 → Uniswap/v2-core, Uniswap/v2-periphery
PancakeSwap V3 → pancakeswap/pancake-v3-contracts
Compound → compound-finance/compound-protocol
WETH9 → gnosis/weth9 (canonical reference: etherscan.io/address/0xC02aaA39...)

Clone both the fork and the parent, then diff the function signatures:

diff <(grep -E "^    function" fork/Contract.sol) \
     <(grep -E "^    function" parent/Contract.sol)

⚠️ Critical Caveat: This fast-pass only checks function signatures, not the code inside the function body. A fork can keep the exact same function names but change a single number inside the logic, and this grep command will return zero differences.

A perfect historical example is **Uranium Finance* (April 2021, ~$50M loss). The developers changed the fee multiplier inside the swap() function from 1000 to 10000, but left the K-invariant check at 1000**2. Because the function signature didn't change, signature-only diffing missed it entirely.*

For core math functions (swap, mint, burn), you must perform a full file diff or manually read the function bodies. Also, never forget to compare the INIT_CODE_PAIR_HASH (the pairFor init code hash) used in the Router—if that doesn't match the Factory, routing will break or be exploitable.

Every line with < or > in a full diff is a candidate. Three outcomes:

Diff shape	What it means
No diff in function signatures	Likely canonical — but verify the math inside `swap`/`mint`/`burn`
Renamed function, identical body	Dead — probably a rebrand
New function, or changed logic	This is the target

For a slower but more thorough pass, run git log on the parent repo to find the exact commit that matches the fork's deployment date, then diff full file contents. For an even faster first look, extract the deployed function selectors:

cast code 0x<CONTRACT> --rpc-url $RPC | \
  grep -oE "63[0-9a-f]{8}" | sed 's/^63//' | sort -u | \
while read sel; do
  echo -n "0x$sel -> "
  cast 4byte "0x$sel" 2>/dev/null || echo "(custom)"
done

Selectors that 4byte-decodes to known functions tell you what the contract claims to be. Selectors that come back as (custom) are either compiler error strings pushed into the bytecode (a common source of false positives — look for byte patterns like 0x61 0x6c 0x6c which spell "all" ASCII) or genuine fork additions.

Phase 3 — Invariant testing on a Foundry fork

This is where most of the value is. Canonical code has known invariants. Your fork may break them.

Test pattern:

function test_Invariant() public {
    vm.createSelectFork(vm.envString("RPC"), BLOCK_NUMBER);
    // Assert something that should always be true for a correct implementation
    assertLe(protocol.value(), protocol.maxValue(), "invariant broken");
}

For a Uniswap V3 pool, the invariants are well-documented:

feeGrowthGlobal0X128 and feeGrowthGlobal1X128 are non-decreasing over time
slot0.sqrtPriceX96 is within [MIN_SQRT_RATIO, MAX_SQRT_RATIO]
slot0.unlocked == true after any completed transaction

For a MasterChef-style farm:

totalSupply of the receipt token equals balanceOf of the staking contract
Sum of user.rewardDebt equals totalRewardsDistributed
emergencyWithdraw does not leave residual claims

For a proxy:

implementation.slot0 is initialized (i.e., _disableInitializers() was called)
implementation.owner() is either non-zero or upgradeTo requires onlyProxy

When an invariant fails, you have a lead. When all invariants pass, the canonical claim holds and you can move on.

Phase 4 — Proxy and authority analysis

Modern contracts are almost always behind a proxy. Three patterns exist:

Pattern	How to detect	Attack surface
TransparentUpgradeableProxy	`EIP-1967` admin slot ≠ 0	Admin is a contract (timelock/multisig) or EOA
UUPS (ERC-1822)	`EIP-1967` admin slot = 0, impl has `proxiableUUID`	Implementation initialization — CVE-2021-41251
Beacon	`EIP-1967` beacon slot ≠ 0	Beacon upgrade gate

The UUPS case is the most dangerous because the implementation holds the initializer state. If _disableInitializers() was not called in the constructor, an attacker can:

Call initialize() on the implementation directly
Become the implementation's owner
Call upgradeToAndCall(malicious, "") on the implementation
malicious.selfdestruct() → implementation has no code → proxy bricked

This is CVE-2021-41251, and it has destroyed production protocols.

Test:

cast call $IMPL "owner()(address)" --rpc-url $RPC      # should be 0x0
cast storage $IMPL 0 --rpc-url $RPC                   # should be 0x...ff
cast call $IMPL "initialize()" --rpc-url $RPC         # should revert

If initialize() succeeds on the implementation, stop everything and write the PoC.

Phase 5 — The discipline of stopping

This is the phase no blog post talks about, and it is the most important one.

The instinct after 20 dead ends is to lower the bar: "well, this receipt-token bug could matter if someone deployed a market tomorrow." That is how researchers waste submissions on findings the triager rejects in 30 seconds.

The bar is not "is this technically a bug?" The bar is:

Is there real value at risk right now, on-chain? Not "could be in the future."
Does the exploit work in a single transaction, on a fork, with the current state?
Is the impact measurable in tokens held by the protocol, not just in emitted events?
Does it fall outside the program's explicit exclusions? Most programs exclude "privileged addresses," "devaluing protocol incentive rewards," and "design issues." Read those clauses before writing the PoC, not after.

If any of those four answers is "no," the finding is a portfolio piece, not a submission.

Two public case studies

Case study 1: The four.meme pool pre-creation (BSC, 2025)

A launchpad migrated liquidity to PancakeSwap V3 via createAndInitializePoolIfNecessary. This function only initializes the pool if slot0.sqrtPriceX96 == 0. An attacker pre-created the pool and initialized it at an extreme price. The migration succeeded silently, and the attacker drained the pool for ~$183,000.

The delta: the launchpad's code assumed "create" meant "initialize at a fair price." The canonical function only meant "initialize if empty."

The lesson: when a fork calls a canonical function, check what the canonical function actually guarantees. The fork author's mental model is not the source of truth.

Case study 2: UUPS uninitialized implementation (CVE-2021-41251)

Multiple protocols deployed their UUPS implementations without calling _disableInitializers() in the constructor. Attackers called initialize() on the implementation directly, became the owner, and upgraded to a selfdestructing contract — bricking the proxy and locking all funds.

The delta: nothing in the proxy was wrong. The bug was in the implementation's constructor, which is invisible from the proxy address.

The lesson: audit both layers of every proxy. The proxy's bytecode is short and easy to verify, but the implementation is where the actual state lives — including the initializer.

A small tooling checklist

# Recon
cast codesize <addr> --rpc-url $RPC             # proxy detection
cast call <addr> "owner()(address)" --rpc-url $RPC
cast storage <addr> 0 --rpc-url $RPC             # slot-0 fingerprint
cast code <addr> --rpc-url $RPC | \
  grep -oE "63[0-9a-f]{8}" | sed 's/^63//' | \
  xargs -I{} cast 4byte "0x{}"                   # selector extraction

# Fork testing
forge test --match-contract <Name> -vvvv         # with trace

# Diff
diff <(grep -E "^    function" a.sol) <(grep -E "^    function" b.sol)

Foundry's -vvvv trace is the single most useful tool in the workflow. It shows every SSTORE, CALL, and LOG in a call. A function that "succeeds" for a random caller but has zero SSTORE is a no-op, not a bug. The trace proves it in five seconds.

Conclusion

Most of a smart contract review is proving what is not vulnerable. The findings are a byproduct of the process, not the process itself.

The five phases — scope, delta, invariants, proxies, discipline — are not novel. They are the same approach professional audit firms use. What separates a productive hunt from a frustrating one is resisting the urge to test code you know is clean. Aim at the delta. Test the invariants. Check the proxies. Then stop.

If nothing is vulnerable, you have still produced a documented security review — which is worth more to your portfolio than a single rejected submission.

Methodology refined over multiple bounty programs. Public examples referenced: the four.meme incident (February 2025), CVE-2021-41251, and the canonical Uniswap V2 / PancakeSwap V3 source repositories.

Why Unauthenticated API Endpoints are Still a Major Threat

Coins N Coinsequences — Sat, 31 Oct 2026 21:10:57 +0000

Why Unauthenticated API Endpoints are Still a Major Threat

In the world of modern web development, we often focus heavily on securing the front door. We implement complex login flows, enforce multi-factor authentication (MFA), and integrate Web3 wallet signatures.

But while the front door is locked tight, the back door is often left wide open.

In this article, we are going to talk about Unauthenticated API Endpoints and Broken Access Control (BAC). It is one of the most common vulnerabilities found in bug bounties today, yet it is frequently dismissed by developers as "just data" or "low risk."

Here is why an unauthenticated endpoint can be a massive threat to your infrastructure.

The Anatomy of a Broken Endpoint

When a user logs into your application, they are usually granted a JWT (JSON Web Token) or a session cookie. Every subsequent request they make to your backend API should include this token in the headers (e.g., Authorization: Bearer <token>).

The backend server is supposed to validate this token. If the token is missing, expired, or invalid, the server must reject the request with a 401 Unauthorized.

However, during our recent research on a Web3 frontend, we discovered an API endpoint that was missing this basic check.

We sent a simple GET request to a route designed to list platform assets. We did not include a token. We did not include a cookie. We didn't even include an API key.

The server responded with 200 OK.

The Payload: What Did We Get?

The request didn't just return a small list of public tokens. It returned a 487 Kilobyte JSON payload.

When we analyzed the data, we found a treasure trove of internal information that was never meant to be exposed to the public:

Internal Testnet Addresses: The exact smart contract addresses used for testing environments.
Hidden Assets: Tokens that were explicitly flagged in the code with "hide": true, meaning they were meant to be invisible to the frontend.
Business Logic: Internal transfer limits, fee structures, and exchange routing paths.
Rate Limits & KYC Tiers: The exact limits applied to different KYC levels (e.g., limits for unverified users vs. fully verified users).

The "It's Just Data" Fallacy

A common response from developers when they see this is: "It's public blockchain data anyway," or "It's just a list of tokens, nobody can steal funds with this."

While it’s true that the attacker might not be able to drain a wallet directly with this information, Information Disclosure is the first step in a larger attack chain.

Here is what an attacker does with leaked data:

Mapping the Infrastructure: By finding internal testnet addresses, an attacker can pivot to the testnet environment. Testnets are notoriously less secure than mainnets. If they find a vulnerability there, they can often apply it to the mainnet.
Understanding the Business Logic: Exposing the fee structures and KYC tiers allows an attacker to understand exactly how much they can move before triggering an alert, or how to bypass certain limits using multiple accounts.
Finding Hidden Features: If a token is marked "hide": true, an attacker knows to look for hidden endpoints or UI bypasses to interact with that asset.

How to Fix Unauthenticated Endpoints

If you are a developer building Web3 applications (or any web application), here is how you prevent this:

1. Enforce Authentication Globally

Never rely on the frontend to hide an API call. Even if a UI component isn't rendered, the endpoint still exists on the backend. Use a global middleware on your API gateway that intercepts every request and checks for a valid token, unless the route is explicitly whitelisted as public (like /login).

2. Minimize Response Data

Even if an endpoint is meant to be public, do not send the entire database record to the client. The API should only return the specific fields the frontend actually needs to render the UI.

3. Implement Rate Limiting

If an attacker is probing your API, rate limiting (like a WAF) will slow them down and generate alerts.

The Bug Hunter's Mindset

For security researchers, this is a reminder to always look at the JavaScript. The frontend is a map to the backend. When you find an API route, always test it without your authentication headers. You might just find a 487KB breadcrumb trail.

Authentication is not just about logging a user in; it's about verifying who is asking for what on every single request.

Bypassing Android SSL Pinning: A Journey with mitmproxy and APK-Mitm

Coins N Coinsequences — Sat, 31 Oct 2026 21:07:22 +0000

Bypassing Android SSL Pinning: A Journey with mitmproxy and APK-Mitm

When you start reverse-engineering Web3 applications, you quickly realize that the web frontend is only half the story. Often, the most sensitive API endpoints are locked behind the mobile app.

If you want to intercept the traffic from an Android app to see how it communicates with the backend, the first tool you’ll reach for is a proxy like mitmproxy or Burp Suite.

But here is the problem: Modern apps don't want to be intercepted.

In this article, I’ll walk you through the methodology of intercepting Android traffic, hitting the dreaded SSL Pinning wall, and how to use apk-mitm to bypass it.

Phase 1: The Setup (mitmproxy)

Our journey starts by routing the Android device’s traffic through our machine. We fire up mitmproxy and configure the phone's Wi-Fi to use our local IP as the proxy.

To decrypt HTTPS traffic, we download the mitmproxy CA certificate to the device and install it. For older Android versions, this was enough. We could see every request in plain text.

However, when we opened our target app, the terminal spat out an error:
Client TLS handshake failed. The client does not trust the proxy's certificate.

Phase 2: The Wall (SSL Pinning)

Why did the app reject the proxy?

There are two reasons. First, starting with Android 7 (Nougat), Google changed the security model. Apps no longer trust user-installed CA certificates by default; they only trust system certificates.

Second, and more importantly, the app likely uses SSL Pinning. This is a security mechanism where the app is hardcoded to only accept a specific, cryptographic signature (the server's public key). Even if you install the proxy certificate to the system store, the app will reject it because it doesn't match the hardcoded pin.

So, how do we bypass this? We have to change the app itself.

Phase 3: Extracting the APK

We can't modify the app while it's installed. We need to pull the raw .apk file from the device to our computer.

Using Android Debug Bridge (adb), we connect our phone via USB (or wireless debugging) and locate the path of the installed package. We then pull the base APK to our local machine.

Once we have the app.apk file, we are ready to operate.

Phase 4: The Bypass (apk-mitm)

We could manually decompile the APK using apktool, hunt through the AndroidManifest.xml and smali code to find the pinning logic, modify it, and re-sign the app. But that takes hours.

Instead, we use a brilliant open-source tool called apk-mitm.

apk-mitm automates the entire process. You feed it the APK, and it:

Decodes the APK.
Applies a patch to the network security configuration (allowing user certificates).
Attempts to disable common SSL pinning implementations (like OkHttp).
Re-encodes and re-signs the APK.

# The tool runs automatically on the extracted file
npx apk-mitm app.apk

Once the tool finishes, it spits out a new file: app-patched.apk.

Phase 5: The Catch (App Bundles)

Here is where modern Android development throws a curveball.

When we tried to install the patched APK onto the test device, the installation failed with: INSTALL_FAILED_MISSING_SPLIT.

This happens because modern Android apps are distributed as Android App Bundles (AAB), not single APKs. The base.apk we pulled from the phone is just the skeleton. It relies on "split APKs" for specific screen densities, architectures (ARM64, x86), and languages.

If you patch only the base APK, the app won't run. To fix this, you have to use a tool like SAI (Split APKs Installer) on the Android device to install the patched base APK alongside the original split dependencies.

The Lesson for Developers

SSL Pinning is a fantastic defense-in-depth mechanism. It stops 99% of casual attackers from using a proxy to read the traffic.

However, client-side security is never absolute. If an attacker has physical access to the device, they can extract the APK, remove the pinning, and re-sign it.

To truly secure your mobile app, you need more than just SSL pinning:

Root/Jailbreak Detection: Stop the app from running on compromised devices.
Tamper Detection: Verify the app's signature at runtime. If someone re-signs the app (like apk-mitm does), the app should refuse to launch.
Code Obfuscation: Make it as difficult as possible for an attacker to find your pinning logic in the first place.

Intercepting mobile traffic is a puzzle, but with tools like mitmproxy and apk-mitm, the puzzle is solvable.

How to Reverse Engineer a Web3 Frontend to Find Hidden API Endpoints

Coins N Coinsequences — Sat, 31 Oct 2026 20:59:19 +0000

How to Reverse Engineer a Web3 Frontend to Find Hidden API Endpoints

When we interact with Web3 applications—wallets, decentralized exchanges, or NFT marketplaces—we often assume everything is happening on the blockchain. But here is the reality: the blockchain is slow and expensive.

To provide a seamless user experience, most Web3 applications rely on centralized backend APIs. These APIs handle everything from fetching token prices and calculating fees to managing user profiles and transaction histories.

Because the frontend is usually built with modern frameworks like React or Next.js, this logic is hidden inside minified JavaScript bundles. Developers sometimes assume that because the code is hard to read, the API is secure.

In this article, I’m going to walk you through the methodology of reverse-engineering a Web3 frontend to find its hidden API, and how this process often leads to the discovery of unauthenticated endpoints.

The Illusion of the Frontend

When you visit a Web3 application, your browser downloads a massive bundle of JavaScript. This code is responsible for rendering the UI, connecting to your crypto wallet (like MetaMask), and communicating with the backend.

The first step in our journey is realizing that the frontend is a map to the backend.

If you open your browser's Developer Tools and look at the Network tab, you’ll see a flurry of requests. However, filtering through the noise can be exhausting. A more efficient approach is to pull the JavaScript bundles directly and analyze the source code.

Finding the Hidden Gateway

Once we extract the JavaScript files, we aren't looking for UI logic. We are looking for strings. Specifically, we are looking for hardcoded URLs.

Developers often hardcode their API gateways directly into the frontend code. During our recon, by extracting and searching through the frontend bundles, we found a specific API gateway (let's call it api.web3wallet.com/v2).

Once you have the base API URL, the game completely changes. You no longer need to click around the web app; you can talk directly to the server.

Mapping the Endpoints

With the API gateway in hand, the next step is to discover the routes. Web3 apps have predictable naming conventions. If the frontend shows a "Wallet" page, there is almost certainly an endpoint like /wallet/balance or /user/transactions.

By analyzing how the frontend JavaScript calls the API, we can map out the entire backend architecture. During our investigation, we found routes for:

User profiles
Token listings
Gas fee calculations
Transaction values

The Broken Access Control (BAC) Discovery

Here is where the vulnerability usually hides.

When an API endpoint is called, it should always verify who is making the request. This is done using an Authorization header, usually containing a Bearer Token (a JWT).

During our testing, we sent requests to several endpoints. Some correctly returned a 401 Unauthorized, proving that the backend was checking for a valid session.

However, we found an endpoint designed to list all available tokens in the ecosystem. When we sent a simple GET request without any tokens, cookies, or authorization headers, the server responded with 200 OK.

Not only was it accessible, but it returned a massive payload—nearly 500 Kilobytes of JSON data.

Why Information Disclosure Matters

Some developers might look at a leaked JSON file and think, "It's just a list of tokens, what's the harm?"

But looking closely at the data, we found:

Internal Testnet Addresses: Smart contract addresses used for testing, which could be targeted for testnet-specific exploits.
Hidden Tokens: Assets explicitly marked with "hide": true in the JSON, meaning they shouldn't be visible to the public.
Business Logic: Internal fee structures, transfer limits, and rate limits based on KYC tiers.

In the hands of an attacker, this data is gold. It allows them to map the internal infrastructure, understand the platform's logic, and find other vulnerabilities.

The Lesson for Developers

The biggest takeaway from this methodology is simple: Never trust the client.

Secure Your APIs: Just because an endpoint is buried in minified React code does not mean it is private. If an endpoint shouldn't be public, enforce authentication and authorization on the backend.
Minimize Data Exposure: Don't send your entire database schema to the frontend. Only send the specific data the user needs to see. Remove hidden tokens, internal testnet addresses, and sensitive configuration data from public API responses.
Audit Your Frontend: Regularly review your JavaScript bundles to ensure you aren't leaking API keys, admin routes, or sensitive gateway information.

Reverse-engineering a Web3 frontend isn't about being a wizard; it's about understanding how the pieces connect. By following the trail of JavaScript, you can often find the hidden doors that developers forgot to lock.

Building a Real-Time Funding Rate Monitor for DreamDEX (Somnia Testnet)

Coins N Coinsequences — Fri, 30 Oct 2026 14:25:30 +0000

As part of the DreamDEX Perps Builder Bounty, I set out to solve a simple problem for perpetual traders: staring at funding rate dashboards 24/7 is exhausting.

Traders need to know when a funding rate flips (from positive to negative, or vice versa), but they shouldn't have to monitor it manually.

To solve this, I built the DreamDEX Funding Monitor — a lightweight, automated alert bot and web dashboard that monitors the Somnia Hideki Testnet in real-time.

🏗️ The Architecture

I wanted to keep the architecture clean and decoupled. The project is split into two distinct parts:

The Engine: A background worker that polls the @somnia-chain/markets-sdk every 60 seconds to fetch live rates, check for flips, and fire off Discord alerts.
The Frontend: A live Express.js-powered dashboard that visualizes the data without ever touching the engine's core logic.

The Tech Stack

Backend / Engine: Node.js & TypeScript
Web Server: Express.js + CORS
Web3 Integration: @somnia-chain/markets-sdk
Security: dotenv (to keep Discord Webhook URLs safe)
Frontend: Vanilla HTML/CSS/JS with a custom dark-mode grid layout.

🧠 How the Engine Works

The core engine (funding-alert-bot.ts) connects to the Somnia Testnet Indexer. Smart contracts return raw integers, so I had to handle the decimal precision to make the data human-readable:

// The SDK returns raw integers (e.g., 100000000000000)
const rawRate = Number(market.fundingRate || market.currentFundingRate || 0);

// Dividing by 1e18 converts it to a standard percentage (0.0001 = 0.01%)
const currentRate = rawRate / 1e18;

The bot stores the previous funding rates in memory. When it detects a sign flip (e.g., prevRate > 0 and currentRate < 0), it triggers an Axios POST request to a Discord Webhook, instantly pinging the trader.

🛡️ Security First

Because this is a public hackathon repository, I couldn't hardcode my Discord Webhook URL into the code. I used dotenv to load environment variables, ensuring the secret stays hidden from GitHub crawlers and malicious actors.

📸 The Dashboard

By decoupling the engine, I was able to spin up an Express server that serves a live-updating, dark-mode dashboard. It refreshes every 5 seconds to pull the latest state from the background engine.

🔗 The Core Engine X (Twitter) Post

I've been documenting the build process on X/Twitter. You can check out the exact post about the core engine, Express.js decoupling, and dotenv integration here:

👉 https://x.com/TrAdArSOY/status/2116170770464526425 👈

🚀 Check out the Code

The full MVP is open-source and available on GitHub.

👉 https://github.com/vaultvult/dreamdex-testnet-proof

Built for the @DreamDEXSomnia Perps Builder Bounty.

How I Built a DePIN Solar Energy Protocol for the W3Node Hackathon

Coins N Coinsequences — Tue, 27 Oct 2026 22:35:43 +0000

The Web3 ecosystem is rapidly shifting from speculative finance to real-world infrastructure. For the W3Node Hackathon, I decided to tackle one of the most critical real-world problems: Energy Access in Africa.

Africa needs over 46,000 new mini-grids by 2030 to power rural communities. The hardware is ready, but the financial rails to manage, verify, and pay for this distributed infrastructure don't exist.

To solve this, I built the SHS DePIN Network (Solar Home System Decentralized Physical Infrastructure Network).

Here is a deep dive into how it was built, the architecture, and how it works.

🏗️ The Architecture

The protocol consists of two main smart contracts deployed on the Base Sepolia Testnet:

MockUSDC: A standard ERC-20 stablecoin used for payments.
EnergyMarket: The core engine that handles device registration, consumer payments, machine-to-machine (M2M) reward distribution, and operator withdrawals.

For the frontend, I used Next.js, Wagmi, and Viem to build a sleek, dark-mode dashboard that connects directly to MetaMask.

🔒 Smart Contract Security: The Reentrancy Fix

During the build, Foundry's linter flagged a critical vulnerability in the purchaseEnergy function. The original code made an external call (transferFrom) before updating the state variables.

To make this hackathon project production-ready, I refactored the contract to follow the Checks-Effects-Interactions pattern.

// 1. EFFECTS: Update state first
device.totalRewardsEarned += _amount;
operatorBalances[device.operator] += _amount;

// 2. INTERACTIONS: External call last
require(paymentToken.transferFrom(msg.sender, address(this), _amount), "Payment failed");

This completely eliminates the risk of a reentrancy attack, ensuring that the funds are safe.

🔮 The Future: Real-Time IoT Data

For the MVP, I built an Oracle Simulator in the UI. It allows the admin to inject simulated solar generation data on-chain.

In the real world, this contract is ready to be connected to physical IoT hardware (like an ESP32 chip on a solar inverter) or decentralized oracle networks like Chainlink, transforming it from a simulation into a real-time, automated machine-to-machine economy.

🔗 Live Links

🎥 Watch the 2-Minute Demo: https://youtu.be/xfYc27v8Qho

💻 View the Code: https://github.com/vaultvult/shs-depin-mvp

⛓️ View the Contract on BaseScan: https://sepolia.basescan.org/address/0x6309C657B4fc06B39Ac9Bcb040156898A4F23629

🐦 Follow the Build on Twitter: https://x.com/TrAdArSOY/status/2115206565959524372?a=xyQIUZ1igLA1bC4e-CI&s=20

Building this MVP proved to me that DePIN is the future of infrastructure. The rails are built, and the future of energy is decentralized.

Building Sentinel AI: A Security-First AI Trading Agent for HSK Chain

Coins N Coinsequences — Mon, 26 Oct 2026 13:51:29 +0000

The Problem: Blind AI Trading

In the recent HSK Chain Horizon Hackathon, developers were tasked with building AI agents for DeFi. But as a smart contract auditor, I saw a massive flaw in the standard approach: AI trading bots are blind to security.

They will happily execute a trade on a malicious contract if the API tells them to, draining user funds in the process.

The Solution: Sentinel AI

I built Sentinel AI, a security-first trading agent deployed on the HSK Mainnet. It acts as a gatekeeper. Before any swap is executed on HSKSwap, the agent queries the blockchain RPC to verify the target contract's bytecode.

If the address is fake or malicious, the trade is instantly blocked. If safe, the AI executes the trade and applies a strict -5% Stop-Loss framework.

🛠️ How I Built It (Tech Stack)

Backend / AI Agent: Python, Web3.py, Flask
Smart Contracts: Solidity (AuditRegistry deployed on HSK Mainnet)
Frontend: Custom HTML/CSS/JS Dashboard

⚙️ The Core Logic

Instead of relying on an LLM to make financial decisions, the agent uses a deterministic security check:

It checks if the address is a valid EVM format.
It calls web3.eth.get_code() to ensure it's a real contract and not a spoofed wallet.
It logs the immutable audit proof to a custom Solidity contract on HSK Mainnet before execution.

🔗 Links

Live Demo Video: https://youtu.be/Gjwo1exBdbA?si=qLSPNF9X4_xCaGq0
GitHub Repository: https://github.com/vaultvult/sentinel-ai-hsk
Mainnet Contract: 0xb4FD99d390683DFA2eAE95EbcdDDAa6CF786edc7

Building this taught me a lot about the intersection of AI and security. AI agents are the future of DeFi, but they must be built with strict security guardrails.

How I Found a High-Severity Rounding Vulnerability in Morpho Midnight (Tenor Labs)

Coins N Coinsequences — Sat, 24 Oct 2026 23:52:44 +0000

Introduction

Smart contract security is often about finding the invisible edge cases. While participating in a recent bug bounty for Tenor Labs (a protocol built on top of Morpho Midnight), I discovered a high-severity rounding vulnerability in their migration callbacks.

If exploited, this flaw allows an attacker to artificially inflate a user's Loan-to-Value (LTV) ratio to infinity, triggering an immediate liquidation of the user's pre-existing collateral.

In this article, I’ll break down the vulnerability, explain the math behind the exploit, and provide the Foundry Proof of Concept (PoC) that proves it works.

The Architecture: Tenor Labs & Morpho Midnight

Tenor Labs is a suite of non-custodial smart contracts that extends the Morpho Midnight protocol. One of its core features is the ability for borrowers to seamlessly migrate their debt and collateral between different markets (e.g., moving a position from Market A to Market B).

This is handled by BorrowMidnightRenewalCallback.sol and the CollateralTransferLib.

When a position is migrated, the protocol calculates how much collateral needs to move from the source market to the target market. It does this pro-rata, based on the amount of debt being repaid.

The Vulnerability: `mulDivDown` Rounding to Zero

The core of the bug lies in the transferCollaterals function within CollateralTransferLib.sol. The code uses mulDivDown to calculate the collateral to transfer:

if (sourceDebtBefore != repaidUnits) {
    collateralToTransfer = collateralToTransfer.mulDivDown(repaidUnits, sourceDebtBefore);
}

mulDivDown performs multiplication followed by division, always rounding down.

Here is the fatal flaw: In DeFi, debt accrues interest. If a borrower has 1000e18 in collateral and 1000e18 in debt, after one block, their debt might be 1000e18 + 1 wei due to interest.

If an attacker performs a "dust fill" on the migration offer (repaying exactly 1 wei), the math looks like this:

1000e18 * 1 / (1000e18 + 1) = 0.999...

Because mulDivDown rounds down to the nearest integer, the collateralToTransfer becomes 0.

The Exploit Scenario

The developers actually left a comment in the code acknowledging this rounding behavior, noting that it "temporarily increases the target position's LTV until the position is fully migrated."

However, this assumption is fatally flawed. An attacker can weaponize this "temporary" state:

The Setup: A borrower creates a SELL offer to migrate a large position from Market A to Market B. The borrower also has some pre-existing collateral on Market B.
The Dust Fill: An attacker (or a malicious bot) intentionally fills a tiny fraction of that offer (e.g., 1 wei).
The Rounding: The contract repays 1 wei of debt on Market A, but transfers 0 collateral to Market B.
The Kill: Market B now records a new debt for the borrower, but 0 new collateral backed it. The LTV on Market B is instantly pushed to infinity.
The Liquidation: The attacker immediately liquidates the borrower on Market B, stealing the liquidation penalty and the borrower's pre-existing collateral.

The Proof of Concept (Foundry)

To prove this, I wrote a Foundry test that replicates the math. I mocked the Midnight interface and set up a scenario where a user has 1000e18 collateral but 1000e18 + 1 debt (simulating accrued interest).

// SPDX-License-Identifier: MIT
pragma solidity 0.8.34;

import {Test, console} from "forge-std/Test.sol";
import {CollateralTransferLib} from "../src/libraries/CollateralTransferLib.sol";
import {Market, CollateralParams, IMidnight} from "@midnight/interfaces/IMidnight.sol";

contract DustFillExploit is Test {
    // ... Mocks setup ...

    function testDustFillRoundsCollateralToZero() public {
        // 1. Borrower has 1000e18 collateral on Market A
        midnight.setCollateral(sourceMarketId, borrower, 0, 1000e18);

        // 2. Debt is 1000e18 + 1 (due to accrued interest)
        uint128 sourceDebtBefore = 1000e18 + 1;

        // 3. Attacker does a dust fill of 1 wei
        uint256 repaidUnits = 1;

        // 4. Call the vulnerable library function directly
        (address[] memory tokens, uint256[] memory amounts) = CollateralTransferLib.transferCollaterals(
            IMidnight(address(midnight)), 
            sourceMarket,
            targetMarket,
            borrower,
            sourceMarketId,
            sourceDebtBefore,
            repaidUnits
        );

        console.log("Collateral transferred to target:", amounts[0]);

        // 5. The transferred collateral will be 0, proving the vulnerability
        assertEq(amounts[0], 0, "Vulnerability proven: collateral rounded to zero!");
    }
}

Output:

[PASS] testDustFillRoundsCollateralToZero() (gas: 65335)
Logs:
  Collateral transferred to target: 0

How to Fix It

To mitigate this vulnerability, the transferCollaterals function should enforce a minimum transfer amount. If the pro-rata calculation rounds down to zero, the transaction should revert to prevent unbacked debt from being created.

if (sourceDebtBefore != repaidUnits) {
    collateralToTransfer = collateralToTransfer.mulDivDown(repaidUnits, sourceDebtBefore);
    // Add this check:
    if (collateralToTransfer == 0 && repaidUnits > 0) {
        revert CallbackLib.ZeroAmount();
    }
}

Conclusion

This bug is a perfect example of why rounding directions and edge cases matter so much in DeFi. A simple mulDivDown combined with accrued interest created a path to drain user funds.

If you are a developer, always assume debt and balances will have dust amounts, and protect your math accordingly. If you are a researcher, always read the developer comments—they often point you directly to the attack surface!

You can check out more of my security research and PoCs on my GitHub Portfolio.

DEV Community: Coins N Coinsequences

Delta Analysis: How to Audit a Uniswap Fork Without Wasting a Week

Delta Analysis: How to Audit a Uniswap Fork Without Wasting a Week

Why "just run Slither" fails

The five-phase methodology

Phase 1 — Recon and scope mapping

Phase 2 — Delta analysis against the canonical source

Phase 3 — Invariant testing on a Foundry fork

Phase 4 — Proxy and authority analysis

Phase 5 — The discipline of stopping

Two public case studies

Case study 1: The four.meme pool pre-creation (BSC, 2025)

Case study 2: UUPS uninitialized implementation (CVE-2021-41251)

A small tooling checklist

Conclusion

Why Unauthenticated API Endpoints are Still a Major Threat

Why Unauthenticated API Endpoints are Still a Major Threat

The Anatomy of a Broken Endpoint

The Payload: What Did We Get?

The "It's Just Data" Fallacy

How to Fix Unauthenticated Endpoints

1. Enforce Authentication Globally

2. Minimize Response Data

3. Implement Rate Limiting

The Bug Hunter's Mindset

Bypassing Android SSL Pinning: A Journey with mitmproxy and APK-Mitm

Bypassing Android SSL Pinning: A Journey with mitmproxy and APK-Mitm

Phase 1: The Setup (mitmproxy)

Phase 2: The Wall (SSL Pinning)

Phase 3: Extracting the APK

Phase 4: The Bypass (apk-mitm)

Phase 5: The Catch (App Bundles)

The Lesson for Developers

How to Reverse Engineer a Web3 Frontend to Find Hidden API Endpoints

How to Reverse Engineer a Web3 Frontend to Find Hidden API Endpoints

The Illusion of the Frontend

Finding the Hidden Gateway

Mapping the Endpoints

The Broken Access Control (BAC) Discovery

Why Information Disclosure Matters

The Lesson for Developers

Building a Real-Time Funding Rate Monitor for DreamDEX (Somnia Testnet)

🏗️ The Architecture

The Tech Stack

🧠 How the Engine Works

🛡️ Security First

📸 The Dashboard

🔗 The Core Engine X (Twitter) Post

🚀 Check out the Code

How I Built a DePIN Solar Energy Protocol for the W3Node Hackathon

🏗️ The Architecture

🔒 Smart Contract Security: The Reentrancy Fix

🔮 The Future: Real-Time IoT Data

🔗 Live Links

Building Sentinel AI: A Security-First AI Trading Agent for HSK Chain

The Problem: Blind AI Trading

The Solution: Sentinel AI

🛠️ How I Built It (Tech Stack)

⚙️ The Core Logic

🔗 Links

How I Found a High-Severity Rounding Vulnerability in Morpho Midnight (Tenor Labs)

Introduction

The Architecture: Tenor Labs & Morpho Midnight

The Vulnerability: mulDivDown Rounding to Zero

The Exploit Scenario

The Proof of Concept (Foundry)

How to Fix It

Conclusion

The Vulnerability: `mulDivDown` Rounding to Zero