DEV Community: rim dinov

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

The Starknet Challenge

rim dinov — Fri, 17 Apr 2026 09:51:54 +0000

This is a submission for the OpenClaw Challenge.

What I Built

I investigated a critical Gas DoS vulnerability in a Starknet staking contract. The issue was rooted in an unbounded loop that allowed for duplicate token registrations, eventually hitting the block gas limit. I developed a fix using a mapping-based approach to ensure O(1) complexity for token validation and successfully verified the solution with a comprehensive test suite in snforge.

How I Used OpenClaw

I integrated KiloClaw as a professional security assistant to streamline my auditing workflow:
Workflow Integration: I deployed a custom AI agent and connected it to Telegram via BotFather for real-time security briefings.

Real-time Verification: I used the agent to cross-verify my findings on the Gas DoS exploit. The bot provided insights into Starknet-specific monitoring tools like Voyager and suggested custom detector patterns for my remediation plan.

Demo

GitHub Repository: rdin777/starknet-staking_audit1
Proof of Concept: My test suite shows the transition from a failed state (9.8M gas limit hit) to a fully optimized 4/4 passing state.

AI Interaction:

What I Learned

The biggest takeaway was how AI-assisted auditing can bridge the gap between manual discovery and continuous monitoring. While manual analysis identified the logic flaw, KiloClaw helped me conceptualize a long-term monitoring strategy. I also learned the nuances of pairing Telegram bots with the Kilo cloud instance, which is a game-changer for independent researchers.

ClawCon Michigan

I didn't attend in person, but participating in the OpenClaw Challenge virtually has been an incredible deep dive into the future of AI-driven security!

Thanks for participating!

Gas Bomb in Starknet: How One Unbounded Loop Can Brick Your Staking Protocol

rim dinov — Thu, 16 Apr 2026 07:32:11 +0000

Introduction
Many developers migrating from Solidity to Cairo often overlook the fact that Starknet has its own unique gas limits and execution architecture. In this article, I will demonstrate how the absence of loop boundaries can transform a standard smart contract into a "gas bomb" that is impossible to defuse.

The Vulnerability
While auditing a staking protocol, I identified a classic but critical vulnerability: an Unbounded Loop. The contract maintains a list of tokens eligible for rewards, and the core logic iterates through this entire list in a single transaction.

Rust
// Simplified logic from the audited contract
fn update_rewards(ref self: ContractState) {
let mut i: u32 = 0;
let count = self.btc_tokens_count.read();

while i < count {
    let _token = self.btc_tokens.read(i);
    // Reward calculation logic resides here...
    i += 1;
};

}
The flaw is evident: the update_rewards function has no upper bound. As the number of registered tokens grows, the gas required to execute this function increases linearly until it hits a hard limit.

The Attack Scenario
Lack of Access Control: The add_btc_token function is public, allowing any user to register a token.

Storage Bloating: An attacker repeatedly calls this function, filling the storage with hundreds of dummy token addresses.

Denial of Service (DoS): When a legitimate user or admin attempts to trigger update_rewards, the transaction fails consistently with an Out of Gas error.

Proof of Concept (PoC)
Using Starknet Foundry (snforge), I developed a test suite to measure the impact. The results are staggering:

Token Count Gas Consumption (L2 Gas) Status
1 Token ~13,840 ✅ Normal
500 Tokens ~8,047,846 ⚠️ CRITICAL (DoS)
Once the gas cost nears the Starknet block gas limit, the contract becomes "bricked." Users will be unable to claim rewards or withdraw their assets because the reward calculation is a mandatory prerequisite for these actions.

Mitigation Strategies
To prevent such vulnerabilities, developers should:

Implement Pagination: Instead of processing the entire list, handle tokens in batches (e.g., 50 tokens per transaction).

Enforce Access Control: Restrict token registration to an Owner or a DAO-governed role.

Adopt a Pull-over-Push Pattern: Allow users to trigger updates for specific tokens individually rather than forcing a global state update.

Conclusion
In Web3, security is not just about preventing logic errors; it’s about understanding the constraints of the underlying infrastructure. This case serves as a reminder that gas efficiency is directly tied to protocol availability.

Research and PoC developed by rdin777
Check out the full repository here: github.com/rdin777/starknet-staking_audit1

Starknet, #Cairo, #SmartContractSecurity, #Blockchain, #BugBounty

Starknet BTC Staking: How to Extract Rewards with Zero Collateral (And Why the Team Ignored It)

rim dinov — Tue, 14 Apr 2026 11:07:14 +0000

The "AI Slop" That Bypassed Your Security
In the world of Web3 security, the "Proof of Concept" (PoC) is the only source of truth. Recently, I discovered a critical logic bypass in the Starknet BTC Staking Attestation module. When I brought it to the team, the response was dismissive: "This looks like AI slop; we won't review it."

Today, I am releasing the technical details and a public PoC to protect the ecosystem. If a vulnerability is "AI slop," then the protocol is currently being exploited by "AI" that knows how to drain its rewards.

The Technical Deep Dive: The "Ghost Staking" Vulnerability
The core of the issue lies in the Attestation.cairo contract. The protocol attempts to verify BTC staking by checking block data, but it makes a fundamental mistake in its "source of truth."

The Insecure Root of Trust The contract relies on get_block_hash_syscall(target_block_number) to validate proofs.

Фрагмент кода
// Vulnerable logic snippet
let block_hash = get_block_hash_syscall(target_block_number);
assert(block_hash == provided_proof.block_hash, 'Invalid block proof');
The Flaw: Block hashes are public data. Any network participant can retrieve a valid block hash and include it in a forged attestation. The contract validates that the block exists, but fails to verify that a specific transaction (the BTC deposit) belongs to the user submitting the proof.

Lack of Collateral Binding Because the attestation logic doesn't strictly bind a unique BTC transaction to a Starknet address, an attacker can:

Monitor public BTC block data.

Generate a valid-looking attestation structure using public hashes.

Trigger the reward minting function without ever locking a single Satoshi.

Proof of Concept (PoC)
I have isolated the exploit in a clean environment. You can find the full code here: [Insert your GitHub Link: rdin777/starknet-staking_audit1]

To reproduce the vulnerability:

Run Cairo Tests:
cd ghost_staking_audit && snforge test tests/test_ghost_stake.cairo
Result: The test demonstrates a user with zero collateral successfully claiming rewards.

External Simulation:
node scripts/exploit.js
Result: This script generates the forged attestation data that bypasses the assert checks in the contract.

The Disclosure Timeline
March 21, 2026: Submitted the technical report to the team (Lotem Kahana). Dismissed as "AI-generated" without a technical audit.

March 22-24, 2026: Offered private PoC walkthrough. Requested a technical review. Zero response.

March 24, 2026: Public Disclosure.

Conclusion
Dismissing independent research as "AI slop" without running the provided tests is a dangerous precedent. Security is about code, not egos. The vulnerability remains unpatched in the current logic.

I invite the Starknet community to review the PoC and judge for themselves.

Researcher: rdin777
Keywords: #Starknet #Cairo #SecurityAudit #L2 #Vulnerability

The "Ghost" Votes of Olas Protocol: Why Lack of Sync is a Critical Economic Flaw

rim dinov — Fri, 10 Apr 2026 10:16:23 +0000

Introduction
In the world of DeFi and DAO governance, the voter escrowed (ve) model is a gold standard for aligning long-term incentives. Users lock their tokens, receive voting power, and decide how rewards (inflation) are distributed. But what happens when the system "forgets" that you’ve already withdrawn your tokens?

In this article, I’ll break down a vulnerability I discovered in the Olas Protocol (Autonolas) during a Code4rena audit, where a lack of synchronization between core contracts allows for infinite inflation manipulation.

The Architecture: A Tale of Two Contracts
The Olas governance system relies on two main pillars:

veOLAS.sol: The vault where tokens are locked and the time-weighted balance is managed.

VoteWeighting.sol: The engine that calculates voting weights to determine inflation distribution across different "gauges".

For the system to work, VoteWeighting must always know exactly how much power a user has.

The Vulnerability: Persistent Weights after Withdrawal
The flaw lies in the withdraw() flow. When a user's lock period ends in veOLAS.sol, they call the withdraw function to get their tokens back.

The Logic Failure:

veOLAS.sol successfully burns the user's lock and returns the tokens.

However, it does not trigger any update or notification to VoteWeighting.sol.

In VoteWeighting, the user's last recorded slope and bias (the mathematical components of voting power) remain on the books. The contract still "thinks" the user has voting power based on their old, now-deleted lock.

Attack Scenario: The "Sybil Inflation" Loop
An attacker can exploit this "ghost" voting power to capture a disproportionate share of the protocol's inflation:

Lock: Attacker locks a large amount of OLAS in veOLAS for the maximum duration.

Vote: They use this power in VoteWeighting to vote for a specific gauge (e.g., a pool they control).

Wait & Withdraw: Once the lock expires, they withdraw their tokens.

The Ghost Power: The attacker’s tokens are back in their wallet, but their vote in VoteWeighting is still active and counting towards reward distribution.

Repeat: The attacker moves the same tokens to a new wallet and repeats the process.

Result: An attacker can stack "ghost" votes from multiple expired locks to effectively take over the protocol's reward distribution mechanism.

Impact & Final Thoughts
While this was classified as a Low/Medium risk by some due to the specific timing required for locks, from an economic security standpoint, it’s a fundamental flaw. It breaks the "1 token = X voting power" rule.

Key Takeaway for Auditors:
Always check the "Exit" functions. If a protocol uses a multi-contract architecture for governance, ensure that every state change in the Vault is reflected in the Voting Engine.

About the Author
I am RimDinov (rdin777), a Web3 Security Researcher and Bug Bounty Hunter. I document my daily findings as I dive deeper into smart contract audits and protocol security.

https://github.com/rdin777

Ethereum, #Solidity, #SmartContract, #Audit, #DeFi

The Bricking Point: Analyzing Permanent Fund Loss in Panoptic’s SFPM

rim dinov — Tue, 07 Apr 2026 07:06:33 +0000

Executive Summary
During a deep-dive security analysis of the Panoptic protocol (v1.1.x), I identified a critical vulnerability within the SemiFungiblePositionManager (SFPM). The issue, which I’ve categorized as Permanent Bricking, allows for a scenario where user liquidity becomes mathematically "un-burnable." Due to precision loss and rounding discrepancies in the core math libraries, certain positions can enter a state of deadlock, resulting in a 100% loss of funds for the affected user.

Technical Context: The Role of SFPM Panoptic is a groundbreaking protocol for perpetual options built on top of Uniswap V3. At its heart lies the SFPM, which manages Uniswap V3 liquidity positions by wrapping them into ERC-1155 tokens.

While conducting the audit, I utilized the protocol's deployment configurations (deployment-info.json) to identify the target contract. By tracing the CREATE2 Salt (0x82bf455e9ebd6a541ef10b683de1edcaf05ce7a136f15df6a78bf60145fff15c), I was able to isolate the SFPM logic and its interaction with the broader ecosystem.

The Vulnerability: Mathematical Deadlock The vulnerability stems from the way SFPM calculates LiquidityChunks and net shares. In DeFi, rounding is usually a minor "dust" issue, but in Panoptic's complex integration with Uniswap V3 ticks, it can become fatal.

The "Ghost Debt" Scenario:
When a user attempts to burn a position, the contract calculates the required liquidity to be removed. If the internal accounting—affected by prior swaps or time-weighted fee accumulations—results in a required burn amount that is even 1 wei higher than the user's recorded balance (due to rounding up in the protocol's favor), the transaction triggers an Arithmetic over/underflow.

Because there is no "emergency exit" or "rounding tolerance" in the burnTokenizedPosition function, the user's funds are effectively "bricked" inside the contract forever.

Proof of Concept (PoC) To validate this, I developed a test suite using Foundry (Forge) and Solc 0.8.26. The goal was to simulate a state where a position becomes un-burnable.

Key Testing Steps:

Low-Level Injection: Using vm.etch, I injected the contract bytecode at a specific test address (0x...1337) to simulate a precise deployment state.

State Manipulation: Using vm.warp and vm.roll, I simulated the passage of time and block progression to trigger fee accumulation.

The Revert: Attempting to interact with the position resulted in a consistent EVM Revert, as seen in the traces.

Execution Trace Analysis:
The following trace demonstrates the failure point where the EVM execution halts during a call to the bricked address:

Caption: Foundry trace showing a forced Revert during the burn logic execution.

Root Cause & Remediation The root cause is a lack of rounding tolerance in the liquidity accounting logic. In high-precision environments like Panoptic, strict equality or strict subtraction without buffers is dangerous.

Recommended Fixes:

Implement Epsilon Tolerance: Allow for a 1-2 wei discrepancy when burning the final shares of a position.

Virtual Shares: Implement a virtual share mechanism to protect against inflation-related rounding errors.

Invariant Checks: Update the math libraries to ensure that rounding always favors the user's ability to exit, even if it cost the protocol a negligible amount of "dust."

Conclusion Complexity is the enemy of security. While the SFPM is a masterpiece of engineering, the mathematical edge cases of Uniswap V3 tick management create risks that are difficult to catch without rigorous stress testing. This discovery highlights the need for continuous auditing and formal verification of math-heavy DeFi protocols.

Researcher: Rim Dinov (@rdin777)
https://github.com/rdin777/Permanent-loss-of-user-funds-Panoptic

solidity, #security, #ethereum, #web3

Finding a Critical Logic Flaw in Legion Protocol’s Epoch Vesting

rim dinov — Sat, 04 Apr 2026 05:15:37 +0000

By RimDinov (@rdin777)

While performing a deep-dive security audit of the Legion Protocol, I identified a critical vulnerability in their linear epoch-based vesting contract. This flaw isn't just a minor edge case — it’s a fundamental logic error that can lead to permanent loss of user funds and broken protocol invariants.

In this article, I’ll break down how the vulnerability works, why the math fails, and how I built a Proof-of-Concept (PoC) using Foundry to prove it.

The Architecture: Epoch vs. Linear Vesting Most vesting contracts use a simple linear formula based on block.timestamp. However, Legion implemented an Epoch-based approach. Tokens are unlocked in "chunks" (epochs) rather than every second.

While this design can be useful for certain tokenomics, its implementation in LegionLinearEpochVesting.sol introduced a dangerous state dependency.

The Vulnerability: State-Dependent Vesting Math The core issue lies in the _vestingSchedule function. Instead of being a pure function of time, the amount of vested tokens is calculated based on the global state variable s_lastClaimedEpoch.

The "Double-Claim" Trap
Take a look at the vulnerable code snippet:

Solidity
// @notice Vulnerable calculation in LegionLinearEpochVesting.sol
if (currentEpoch > s_lastClaimedEpoch) {
amountVested = ((currentEpoch - 1) * _totalAllocation) / s_numberOfEpochs;
}
The Logic Flaw: If a user (or bot) calls the release() function twice during the same epoch:
The first time currentEpoch > s_lastClaimedEpoch - the transaction goes through, tokens are transferred, s_lastClaimedEpoch is updated.

The second time, currentEpoch becomes EQUAL to s_lastClaimedEpoch. The if condition fails, and amountVested returns 0.

In certain scenarios, this may cause the contract to consider tokens "issued" even though the user received 0.

The "Dust" Problem: Precision Loss Another critical issue is the handling of token decimals. The contract uses a fixed 1e18 denominator (likely from a Constants.sol file) without properly scaling for tokens like USDC or USDT (6 decimals).

This causes massive rounding errors. For low-decimal tokens, a significant portion of the funds (the "dust") will remain stuck in the contract forever because the math simply truncates the value to zero.

Proof of Concept (PoC) To verify the impact, I wrote a dedicated exploit test in Foundry. The test simulates a user trying to claim multiple times and proves that funds become inaccessible due to the epoch-tracking logic.

You can find the full PoC and the audit repository here:
👉 https://github.com/rdin777/ltgion-newaudit

Pro-Tip: Always run your tests with forge test -vvvv to see the exact state changes during the exploit.

Mitigation: How to Fix It To fix these issues, I recommended the following to the Legion team:

Remove State Dependency: Calculate the vested amount based strictly on block.timestamp and the totalAllocated, subtracting only the totalReleased so far.

Dynamic Scaling: Use ERC20(token).decimals() to handle precision instead of hardcoded constants.

Conclusion
Smart contract security is about more than just finding reentrancy or overflow bugs. It's about understanding the business logic. Even a simple vesting contract can hide critical flaws if the state management isn't handled with extreme care.

Follow me for more security deep-dives:

GitHub: https://github.com/rdin777

Audit Speed: Hunting NFT Theft in V11 Finance (Duplicate Story) Subtitle: Why being right is only half the battle in Web3 security.

rim dinov — Wed, 01 Apr 2026 06:24:30 +0000

Execution of the exploit in a local Foundry environment. The 'PASS' status confirms that the skim() function is indeed vulnerable to unauthorized collateral draining.

🧐 Introduction
In the fast-paced world of smart contract audits, being right is only half the battle. You also have to be first. Recently, during the V11 Finance audit on Cantina, I discovered a critical flaw that allowed anyone to drain wrapped NFT collateral.

Although my finding was marked as a Duplicate of #1, the technical journey and the resulting PoC (Proof of Concept) are worth sharing.

🔍 The Vulnerability: Public skim() and Untrusted Collateral
The core of the issue was in the wrapper contract's interaction with the underlying liquidity pool.

The Flaw
The contract exposed a public skim() function. In Uniswap-style pools, skim() is used to recover tokens that are "stuck" in the contract (balance > reserve). However, in V7's implementation, there were no access controls or internal checks to ensure the caller was authorized to touch the "excess" tokens.

The Attack Vector:
An attacker monitors the contract holding wrapped NFT collateral.

By manipulating the internal state or simply catching a moment when the balance exceeds the tracked reserve, the attacker calls skim(attackerAddress).

The contract blindly transfers the excess tokens (representing NFT ownership or collateral) to the attacker.

🛠 The Proof of Concept (Foundry)
To confirm this, I wrote a custom test case: test_SkimAttack_Theft().

Solidity
function test_SkimAttack_Theft() public {
// 1. Setup: User deposits NFT collateral
vm.prank(user);
v7Contract.deposit(nftId);

// 2. The Attack: Unauthorized caller triggers skim()
vm.prank(attacker);
v7Contract.skim(attacker);

// 3. Verification: Attacker now owns the collateral
assertEq(nftToken.ownerOf(nftId), attacker);
console.log("Attack Successful: Collateral Stolen!");

}
Terminal Output:
[PASS] test_SkimAttack_Theft() (gas: 45231)
The test confirmed that the vulnerability was live and easily exploitable.

📉 The "Duplicate" Verdict
When I submitted the report, it was linked to Finding #1.

In big contests, the most "obvious" critical bugs are often caught within the first few hours. While it's a bit disappointing to miss out on the primary reward, it’s a massive confidence booster.

Lesson Learned: If you find a bug that looks "too easy," submit it immediately. Don't wait to polish the report—speed is a feature in competitive auditing.

💡 Conclusion
Even though it's a duplicate, this finding confirms that my "security radar" is calibrated to the same frequency as the top researchers in the space.

Key Takeaways:

Public functions are dangerous: Always ask "Who can call this?"

PoC is King: Having a working Foundry test makes your report undeniable.

Stay Fast: The difference between a $5k reward and a Duplicate is often just a few minutes.

Web3Security #Ethereum #Solidity #Audit #Cantina #V11Finance.

Precision Forensics: Reverse Engineering a DeFi Trading App via Network Analysis

rim dinov — Mon, 30 Mar 2026 07:00:38 +0000

Intro
In the world of DeFi and automated trading, precision is everything. A single rounding error or a missing truncation logic can lead to a "death by a thousand cuts" where users lose small fractions of their funds over thousands of transactions. Today, I decided to perform a quick "Black-box" audit on a popular trading protocol's web application to see how they handle their math under the hood.

The Method: No Source Code? No Problem.
When the source code is private, a security researcher’s best friend is the Browser DevTools (Network Tab). By intercepting the communication between the Frontend and the Backend/Smart-contracts, we can see the "raw" data before it gets prettified for the user.

The Findings: The "8-Decimal" Red Flag
While analyzing the trade history of a strategy, I noticed a significant inconsistency in the API responses.

UI Inconsistency In the user interface, profit values were displayed with an unusual number of decimal places (e.g., 4.18489805 USDT). For a stablecoin display, this is more than just a UI bug; it’s a sign that the data isn't being normalized.

Deep Dive into the JSON Response Looking at the deals endpoint, the raw JSON confirmed my suspicions.

The profit field returned a string with 8 decimals: "4.18489805".

In the same object, total_profit was truncated to 2 decimals: "7.94".

Why This Matters (The Security Risk)
This inconsistency suggests that the protocol's architecture lacks a unified Math/Precision library.

Rounding Direction: If one part of the system rounds up and another rounds down (or doesn't round at all), it creates arbitrage opportunities or "ghost" funds.

Truncation Issues: If the backend isn't truncating these "long-tail" decimals, it might be performing internal calculations with floating-point math instead of fixed-point integer math (which is a cardinal sin in blockchain security).

Conclusion
Even without looking at the Solidity code, we can see that the data handling layer has gaps. For developers, the lesson is simple: Always normalize your precision at the API level and ensure your rounding directions are consistent across all modules.

web3security, #blockchain, #bugbounty, #solidity.