FloorIsLava — Contract Audit Case Study
Case Studies
FloorIsLava represents an innovative approach to tokenomics in the DeFi space, combining game theory mechanics with automated market maker (AMM) dynamics. The protocol implements a last-buyer-wins prize system where each qualifying purchase resets a countdown timer, with the final buyer before expiration claiming accumulated ETH rewards. This gamification layer is reinforced by a dynamic floor price mechanism that grows over time, protecting token holders from catastrophic price collapse while creating strategic trading opportunities.
The token contract integrates directly with Uniswap V2 liquidity pools and implements custom buy/sell logic that enforces floor price constraints, timer-based trading restrictions, and automated prize distribution. With a total supply of 1 billion tokens distributed across treasury (600M), development (200M), presale (100M), and initial liquidity (100M) allocations, the protocol balances community engagement with sustainable tokenomics. The contract applies a 2% tax on both buys and sells, with proceeds funding the prize pool and protocol operations.
Security is paramount for FloorIsLava given the protocol's novel mechanics and the financial stakes involved in the prize system. The floor price mechanism must be mathematically sound to prevent exploitation, the timer logic must be manipulation-resistant, and the prize distribution system must handle edge cases gracefully. Any vulnerability in these core systems could lead to loss of user funds, protocol deadlock, or unfair game outcomes. Assure DeFi's audit focused on validating these critical invariants and ensuring the protocol operates as intended under all conditions.
The audit process revealed significant architectural challenges in the initial implementation, particularly around the coupling of fee exemptions with game rule enforcement, floor price calculation accuracy across rate transitions, and potential denial-of-service vectors in unbounded loops. The development team's responsiveness to remediation guidance and commitment to security best practices enabled comprehensive resolution of identified issues, transforming the protocol from a failing security posture to production-ready status.
The Assure DeFi audit of FloorIsLava encompassed a comprehensive review of the token contract deployed on Base Sepolia testnet, with verification extending to the final production deployment on Base mainnet. The audit scope included all core contract functionality: ERC20 token mechanics, Uniswap V2 integration, floor price calculation and enforcement, timer-based game state management, prize distribution logic, and administrative functions. The contract's interaction with external dependencies—specifically the Uniswap V2 Router and Pair contracts—was analyzed to identify integration risks and edge cases.
Assure DeFi employed a multi-layered audit methodology combining static analysis, manual code review, and custom test case development. Static analysis tools were used to identify common vulnerability patterns, gas optimization opportunities, and code quality issues. Manual review by experienced security researchers focused on business logic validation, game theory attack vectors, and complex state transition scenarios. The audit team developed comprehensive test suites using Brownie framework to verify contract behavior under normal operations, boundary conditions, and adversarial scenarios including reentrancy attacks, flash loan manipulations, and timer exploitation attempts.
The audit process followed an iterative remediation model. Initial findings were documented with detailed technical descriptions, proof-of-concept exploit scenarios where applicable, and specific remediation recommendations. The development team implemented fixes in a staged approach, with Assure DeFi conducting re-verification after each remediation cycle. This collaborative process enabled the team to address not just surface-level vulnerabilities but underlying architectural weaknesses, resulting in a more robust and maintainable codebase. The final audit covered three contract versions: the initial failing implementation, an intermediate partially-fixed version, and the production-ready deployment.
The Assure DeFi audit identified a total of 9 security findings across the FloorIsLava smart contract, distributed across high and medium severity categories. The severity distribution reflects the critical nature of the protocol's core mechanics: 7 high-severity findings (78% of total) and 2 medium-severity findings (22% of total). No low-severity or informational findings were documented, indicating the audit focused on material security risks rather than code quality optimizations.
| ID | Title | Severity | Status |
|---|---|---|---|
| H-01 | isExcludedFromFees skips core buy/sell rule enforcement | High | Fixed ✅ |
| H-02 | Floor growth logic wrong across 90-period boundary | High | Fixed ✅ |
| H-03 | Unbounded loop can permanently DoS protocol | High | Partially Fixed ✅ |
| H-04 | Skim-buy can set lastBuyer without real buy | High | Fixed ✅ |
| H-05 | Winner can brick game by rejecting ETH | High | Fixed ✅ |
| H-06 | Reentrancy during rug payout bypasses protections | High | Fixed ✅ |
| H-07 | Floor bypass via token donation and delayed swap | High | Fixed ✅ |
| M-01 | totalSupply() constant and ignores burns | Medium | Fixed ✅ |
| M-02 | Standard Uniswap router sells can revert | Medium | Acknowledged |
The high-severity findings predominantly centered on game invariant bypass vulnerabilities and protocol-level denial-of-service risks. Multiple findings (H-01, H-04, H-07) demonstrated ways attackers could circumvent the floor price protection mechanism—the protocol's primary value proposition for token holders. Others (H-05, H-06) revealed critical flaws in the prize distribution system that could permanently lock the protocol or enable theft during payout. The unbounded loop issue (H-03) represented an existential threat, as extended inactivity could render the contract permanently unusable.
Medium-severity findings addressed accounting accuracy and integration compatibility. The totalSupply() discrepancy (M-01) created inconsistency between actual and reported token supply, potentially confusing external integrations and analytics platforms. The router compatibility issue (M-02) highlighted the challenges of implementing transfer taxes in a Uniswap V2 environment, requiring careful integration documentation to prevent user transaction failures.
The remediation process achieved an 89% full-resolution rate (8 of 9 findings), with one finding acknowledged and addressed through integration documentation rather than code changes. This outcome reflects the development team's commitment to security and the effectiveness of Assure DeFi's collaborative audit approach. The protocol's security score improved from 60/100 (failing) to 85/100 (passing), meeting Assure DeFi's stringent 84-point threshold for production deployment.
The initial FloorIsLava implementation conflated two distinct concerns: fee exemption and game rule enforcement. The contract used the isExcludedFromFees mapping as a gate not only for tax collection but also for all core game invariants including floor price checks, timer enforcement, and last-buyer state updates. This architectural flaw meant that any address excluded from fees—intended for system contracts like the router—could bypass the protocol's fundamental security mechanisms.
For buy transactions, the game logic executed only when from == pair && !isExcludedFromFees[to]. This block contained critical operations: updateFloor() to maintain price floor accuracy, minimum buy enforcement to prevent dust spam, MEV protection near timer expiry, and most critically, updating lastBuyer, lastBuyTime, and lastBuyAmount state variables that determine prize eligibility. If the recipient was fee-exempt, none of these protections applied, enabling privileged addresses to manipulate game state without triggering security checks.
The sell path exhibited the same vulnerability. Sell logic executed only when to == pair && !isExcludedFromFees[from], containing essential protections: require(gameActive) to prevent trading during paused states, require(timer not expired) to enforce round boundaries, floor price validation, and post-sell price simulation to prevent floor breaches. Fee-exempt sellers bypassed all these checks, potentially dumping tokens below the floor price or trading during restricted periods—violations that undermine the protocol's core value proposition.
The remediation separated these concerns by removing fee exemption from game rule conditionals. In the fixed implementation, buy transactions from the pair always execute game logic regardless of fee status, ensuring timer updates and qualifying-buy detection occur for all purchases. Similarly, sell transactions to the pair always enforce gameActive, timer expiry, and floor price constraints. This architectural change ensures that game invariants are universal protocol rules, not privileges that can be selectively bypassed, while still allowing legitimate fee exemptions for tax collection purposes.
FloorIsLava implements a two-phase floor price growth model: 5% daily growth for the first 90 periods, then 1% daily growth thereafter. This design creates a natural rate transition boundary that the initial implementation failed to handle correctly. The getFloorRate() function returned a single rate based on the current time, but updateFloor() applied that same rate retroactively to all elapsed periods since the last update, creating a mathematical error when updates spanned the 90-period boundary.
The vulnerable code structure was: for (i=0; i<periodsSinceUpdate; i++) { uint256 rate = getFloorRate(); currentFloor = (currentFloor * (10000 + rate)) / 10000; }. Because getFloorRate() was called outside the loop or returned a constant value within it, if an update spanned from period 85 to period 95, the function would incorrectly apply either 5% for all 10 periods or 1% for all 10 periods, depending on the current time. The correct calculation should apply 5% for periods 85-90 and 1% for periods 91-95.
This error had asymmetric impact depending on update timing. If the floor was updated shortly after crossing the boundary (current period = 91), it would apply the 1% rate to earlier periods that should have received 5% growth, systematically undervaluing the floor and exposing token holders to sells that should have been blocked. Conversely, if updated long after the boundary (current period = 150), it would apply 1% to all historical periods, still undervaluing the floor but to a lesser degree. In no scenario did the original logic correctly compound the two different rates across the transition.
The fix introduced a _getRateForPeriod(period) helper function that determines the appropriate rate for each individual period based on its position relative to PERIODS_IN_FIRST_PHASE. The update loop now calls this function for each iteration: for (i=0; i<periodsSinceUpdate; i++) { uint256 rate = _getRateForPeriod(lastFloorUpdatePeriod + i); currentFloor = (currentFloor * (10000 + rate)) / 10000; }. This ensures that periods before the boundary receive 5% growth and periods after receive 1% growth, correctly implementing the intended piecewise compounding model and maintaining floor price accuracy across all scenarios.
Both updateFloor() and getCurrentFloor() functions contained loops that iterated periodsSinceUpdate times to compound floor price growth. With TIME_UNIT = 1 day in production, extended protocol inactivity would cause this iteration count to grow linearly with time. After one year of inactivity, the loop would attempt 365 iterations; after five years, 1,825 iterations. While individual iterations are relatively gas-efficient, the cumulative cost eventually exceeds block gas limits, causing all transactions that call these functions to revert with out-of-gas errors.
The severity of this finding stems from the pervasive nature of updateFloor() calls throughout the contract. The function is invoked during: every buy transaction (to ensure accurate floor before updating last-buyer state), every sell transaction (to validate current price against floor), the custom sellForEth() function, and checkAndExecuteRug() for prize distribution. Once the loop becomes too large, all of these critical operations fail, effectively locking the protocol in its current state with no recovery mechanism. Users cannot buy, cannot sell, and the prize cannot be distributed—a complete protocol deadlock.
The testnet configuration (TIME_UNIT = 1 hour) made this vulnerability more immediately exploitable, with 8,760 iterations accumulating in just one year. However, even the production configuration would eventually hit gas limits given sufficient time. The fundamental issue was the algorithmic complexity: O(n) gas cost where n grows unbounded with time, creating a ticking time bomb that would eventually detonate regardless of contract usage patterns.
The remediation introduced MAX_FLOOR_UPDATE_PERIODS = 500, capping loop iterations to prevent gas exhaustion. While this prevents the DoS scenario, it introduces a new consideration: after more than 500 periods of inactivity, floor growth beyond that cap is ignored until multiple transactions "catch up" by processing 500 periods each. This means the enforced floor may temporarily lag behind the intended floor, potentially allowing sells that should be blocked if the protocol is abandoned for extended periods. The development team accepted this tradeoff, noting that 500 days of complete inactivity is an unlikely scenario for an active gaming protocol. A more robust solution would use closed-form exponentiation or precomputed multiplier tables to eliminate loops entirely, but the cap-based approach provides adequate protection for realistic usage patterns while maintaining code simplicity.
The FloorIsLava game mechanics rely on accurately detecting "buy" transactions to update lastBuyer state and reset the prize timer. The initial implementation used a simple heuristic: any transfer from == pair was treated as a buy. This assumption breaks down when considering Uniswap V2's skim() function, which allows anyone to withdraw excess tokens from the pair contract without executing a swap. An attacker could exploit this to manipulate game state without making a legitimate purchase.
The attack sequence was straightforward: (1) Attacker transfers LAVA tokens directly to the pair contract using transfer(pair, amount), increasing the pair's token balance without updating reserves. (2) Attacker calls pair.skim(attacker), which sends the excess balance back to the attacker. (3) The return transfer triggers FloorIsLava's _transfer() function with from == pair, which the contract interprets as a buy transaction. (4) The contract updates lastBuyer = attacker, lastBuyTime = block.timestamp, and lastBuyAmount = amount, resetting the prize timer and positioning the attacker as the current winner—all without spending any ETH or affecting the pool's price.
This vulnerability undermined the fairness of the prize system. Legitimate users who purchased tokens with real ETH could be displaced as lastBuyer by an attacker who simply recycled their own tokens through the skim mechanism. The attacker could repeatedly execute this pattern to maintain winner status cheaply, especially valuable as the timer approached expiration. The minimum buy requirement provided no protection since the attacker controlled the transfer amount and could easily exceed the threshold.
The fix added a critical validation: if (to == pair) require(msg.sender == router, "Use router for sells"). This prevents direct token transfers to the pair from arbitrary addresses, blocking the first step of the skim attack. Without the ability to donate tokens to the pair, attackers cannot create the excess balance necessary for skim() to return tokens and trigger the false buy detection. The remediation maintains legitimate functionality—all real buys and sells flow through the router—while eliminating the attack vector. As an additional improvement, the contract could implement stricter buy detection by validating that msg.sender == router for from == pair transfers, ensuring only router-mediated swaps trigger game state updates.
The prize distribution mechanism in checkAndExecuteRug() attempted to send ETH directly to the lastBuyer address using: (bool success, ) = payable(winner).call{value: ethRemoved}(""); require(success, "ETH transfer failed");. This push-payment pattern created a critical vulnerability: if lastBuyer was a smart contract that reverted on receiving ETH (either maliciously or due to lack of a payable fallback function), the entire checkAndExecuteRug() transaction would revert, preventing prize distribution and round transition.
The severity of this finding derived from the protocol's state machine design. After the timer expires (block.timestamp > lastBuyTime + RUG_TIMER), the contract blocks both buys and sells until checkAndExecuteRug() successfully executes and resets the game state. If prize distribution is impossible due to a reverting winner, the protocol enters permanent deadlock: users cannot trade because the timer has expired, but the timer cannot be reset because prize distribution fails. There is no admin override, no escape hatch, no recovery mechanism—the contract is permanently frozen with user funds locked in the liquidity pool.
An attacker could exploit this deliberately by creating a contract with a receive() function that always reverts, then using that contract to execute the final qualifying buy before timer expiration. Alternatively, the vulnerability could be triggered accidentally if the last buyer was a multisig wallet, smart contract wallet, or other contract that doesn't implement proper ETH receiving logic. In either case, the outcome is the same: protocol deadlock and loss of user access to their funds.
The remediation adopted a pull-payment pattern, a well-established best practice for handling ETH transfers to untrusted addresses. Instead of pushing ETH to the winner, the fixed implementation escrows the prize: pendingPrize[winner] += ethRemoved;. The winner must then explicitly claim their prize by calling a new claimPrize() function, which transfers pendingPrize[msg.sender] to the caller. This architectural change ensures that checkAndExecuteRug() always succeeds regardless of winner behavior, allowing the protocol to transition to the next round and resume normal trading. If a winner cannot or will not claim their prize, it remains escrowed indefinitely, but the protocol continues operating—a far better outcome than permanent deadlock.
The original checkAndExecuteRug() implementation used the lockTheSwap modifier, which set inSwap = true for the duration of the function to prevent recursive calls. However, this created an unexpected vulnerability when combined with the _transfer() function's early bypass logic: if (inSwap || from == address(this) || to == address(this)) { _basicTransfer(...); return; }. During prize payout, while inSwap == true, the contract made an external call to send ETH to the winner, creating a reentrancy opportunity.
The attack scenario proceeded as follows: (1) Attacker positions themselves as lastBuyer using a malicious contract. (2) Timer expires and someone calls checkAndExecuteRug(). (3) The function sets inSwap = true and calls payable(winner).call{value: ethRemoved}(""), transferring ETH to the attacker's contract. (4) The attacker's receive() function executes and calls the Uniswap router to swap LAVA tokens for ETH (a sell). (5) The router transfers LAVA from the attacker to the pair, triggering FloorIsLava's _transfer() function. (6) Because inSwap == true, _transfer() uses _basicTransfer(), which skips all sell restrictions: no gameActive check, no timer validation, no floor price enforcement, no sell tax collection.
This vulnerability was particularly severe because it allowed an attacker to dump tokens at the exact moment when protections were intentionally disabled for internal operations. The attacker could sell their entire LAVA balance below the floor price, extract maximum ETH from the pool, and pay zero sell tax—all while the protocol was in the middle of prize distribution. The nonReentrant modifier on checkAndExecuteRug() prevented direct recursion into that function, but it didn't prevent reentrancy into _transfer() via the router, which was the actual attack vector.
The fix addressed both the root cause and the enabling condition. First, inSwap was removed from the early bypass condition in _transfer(), ensuring that game invariants are enforced even during internal swap operations. Second, the switch to pull-payment pattern (see H-05) eliminated the external ETH call during checkAndExecuteRug(), removing the reentrancy entry point entirely. With no external call to reenter through and no bypass condition to exploit, the attack vector is completely closed. The combination of these changes demonstrates defense-in-depth: even if one protection fails, the other prevents exploitation.
The floor price mechanism relied on observing token transfers to the pair (to == pair) and validating that the post-transfer price remained above the floor. However, this approach had a fundamental flaw: it assumed that all tokens entering the pair would be immediately swapped, allowing the contract to simulate the price impact. Uniswap V2's architecture allows separation of token transfer and swap execution, enabling an attacker to bypass floor enforcement through a donation-accumulation attack.
The attack exploited the difference between a pair's token balance and its reserves. Reserves update only during swap(), mint(), burn(), or sync() operations, while balance updates on every transfer. The attack sequence: (1) Attacker repeatedly calls transfer(pair, smallAmount), sending small quantities of LAVA to the pair. Each transfer passes the floor simulation because the amount is small and doesn't significantly impact the simulated post-sell price. (2) These transfers increase pair.balanceOf(LAVA) but do not update pair.reserve0 or pair.reserve1. (3) After accumulating a large donation, the attacker calls pair.swap() directly (not through the router). (4) The pair calculates amountIn as the difference between current balance and reserves, treating the entire accumulated donation as input for this single swap. (5) The large swap executes in one transaction, potentially pushing the price far below the floor, even though each individual donation passed validation.
This attack broke the core protocol invariant: "no sell can breach the floor price." An attacker could extract materially more ETH than intended by the tokenomics, potentially draining the pool below the floor and destroying token holder value. The attack was capital-efficient since the attacker was donating their own tokens and could time the final swap to maximize extracted value. The minimum buy requirement and sell tax provided no protection since the attack used direct pair interaction rather than router-mediated swaps.
The remediation enforced router-only access for pair-bound transfers: if (to == pair) require(msg.sender == router, "Use router for sells"). This prevents arbitrary addresses from transferring tokens to the pair outside of legitimate swap operations. Since the router always calls transfer() and swap() in the same transaction, there's no opportunity to accumulate donations separately from swaps. The fix maintains all legitimate functionality—users can still buy and sell through the router—while eliminating the ability to preload the pair with tokens for later exploitation. This architectural constraint ensures that the floor price simulation accurately reflects the actual price impact of each transaction, restoring the protocol's core security guarantee.
The FloorIsLava tokenomics include a burn mechanism in checkAndExecuteRug() that destroys 20% of collected tokens to create deflationary pressure. The implementation correctly decremented _balances[address(this)], incremented a totalBurned tracking variable, and emitted a Transfer(address(this), address(0), toBurn) event following ERC20 conventions. However, the totalSupply() function always returned the constant TOTAL_SUPPLY value without subtracting burned tokens, creating a discrepancy between actual circulating supply and reported supply.
This accounting error had several implications. External contracts and interfaces that rely on totalSupply() for calculations—such as analytics platforms, portfolio trackers, or DeFi protocols integrating FloorIsLava—would receive incorrect data. The reported supply would always be 1 billion tokens regardless of how many had been burned, potentially leading to incorrect price calculations, market cap reporting, or integration logic. The Transfer event to address(0) strongly implies supply reduction in ERC20 semantics, so the discrepancy between events and totalSupply() violated user expectations and standard conventions.
While this finding didn't directly enable theft or loss of funds, it represented a violation of the ERC20 standard's implicit contract with users and integrators. Accurate supply reporting is fundamental to token transparency and trust. The inconsistency could also cause issues with DEX interfaces, liquidity pool calculations, or governance systems that weight votes by token supply. In the worst case, the discrepancy might be interpreted as a hidden mint capability or accounting manipulation, damaging protocol credibility even though the actual cause was a simple implementation oversight.
The fix introduced a mutable _totalSupply state variable initialized to TOTAL_SUPPLY at deployment. The burn logic now includes _totalSupply -= toBurn; to decrement the supply counter, and totalSupply() returns _totalSupply instead of the constant. This ensures that the reported supply accurately reflects burned tokens, maintaining consistency between Transfer events, balance queries, and supply queries. The change aligns FloorIsLava with ERC20 best practices and eliminates potential integration issues with external systems that rely on accurate supply data.
FloorIsLava implements a 2% transfer tax on sells, deducted when tokens move from a user to the pair. This creates a subtle incompatibility with Uniswap V2's standard router methods like swapExactTokensForETH. When a user initiates a sell through the router, the router calculates the required input amount and calls transferFrom(user, pair, amountIn). However, due to the 2% tax, the pair receives only amountIn * 0.98, not the full amountIn the router expects.
The Uniswap V2 pair contract validates that it received the expected input amount before executing the swap. When the actual received amount is less than expected due to the transfer tax, the pair's swap() function reverts because the constant product formula cannot be satisfied—the pair doesn't have enough input tokens to provide the calculated output amount without violating k = reserve0 * reserve1. From the user's perspective, sell transactions simply fail with cryptic error messages, creating a "honeypot-like" experience where tokens appear unsellable through standard interfaces.
This issue is well-known in the fee-on-transfer token ecosystem and has standard solutions. Uniswap V2 Router02 includes swapExactTokensForETHSupportingFeeOnTransferTokens and similar methods that handle transfer taxes by calculating output based on actual received amounts rather than expected amounts. FloorIsLava also provides a custom sellForEth() function that avoids the LAVA-side tax and instead applies tax to the ETH output, working around the incompatibility. However, users and integrators unfamiliar with these nuances might attempt to use standard router methods and encounter unexpected failures.
The development team acknowledged this finding and chose to address it through documentation rather than code changes. The recommended integration path is clearly specified: users should either use the custom sellForEth() function or ensure their frontend calls the fee-on-transfer-compatible router methods. This approach is reasonable given that changing the tax structure would require significant tokenomics redesign, and the workarounds are well-established in the DeFi ecosystem. The key is ensuring that user interfaces, integration guides, and documentation prominently explain the requirement to prevent user confusion and failed transactions. Projects integrating FloorIsLava must implement proper router method selection in their frontends to provide a smooth user experience.
Assure DeFi's audit of FloorIsLava employed a comprehensive security assessment methodology combining automated tooling, manual expert review, and custom test development. The audit process began with static analysis using industry-standard tools to identify common vulnerability patterns including reentrancy risks, integer overflow/underflow, unchecked external calls, and access control issues. These automated scans provided an initial vulnerability surface map and highlighted code sections requiring deeper manual investigation.
The manual review phase constituted the core of the audit, with experienced security researchers conducting line-by-line analysis of the contract code. This review focused on business logic validation, ensuring that the implemented game mechanics matched the intended design and couldn't be exploited through edge cases or unexpected state transitions. Particular attention was paid to the floor price calculation logic, timer-based state machine transitions, prize distribution mechanics, and integration points with Uniswap V2 contracts. The audit team analyzed potential attack vectors including flash loan manipulations, MEV exploitation, governance attacks, and economic exploits that could drain value from the protocol or unfairly advantage certain participants.
To validate findings and verify remediations, Assure DeFi developed comprehensive test suites using the Brownie testing framework. These tests covered normal operation scenarios (standard buys, sells, timer progression, prize claims), boundary conditions (minimum buy amounts, timer expiry edge cases, maximum transaction sizes), and adversarial scenarios (reentrancy attempts, donation attacks, skim exploits, malicious winner contracts). The test suite executed against multiple contract versions—initial failing implementation, intermediate fixes, and final production deployment—ensuring that remediations fully addressed identified issues without introducing new vulnerabilities. This iterative testing approach provided high confidence in the security of the final deployed contract and validated that all critical game invariants held under stress conditions.
The FloorIsLava development team demonstrated exceptional responsiveness and commitment to security throughout the remediation process. Upon receiving the initial audit report documenting 7 high-severity and 2 medium-severity findings, the team immediately prioritized fixes and established a collaborative workflow with Assure DeFi for iterative review. The remediation timeline spanned multiple development cycles, with the team implementing fixes in logical groups, deploying updated contracts to testnet for verification, and incorporating feedback from re-audits before proceeding to the next set of changes.
The team's approach to remediation went beyond surface-level patches, addressing underlying architectural issues that enabled multiple vulnerabilities. For example, rather than simply adding checks to prevent individual exploits, the team redesigned the fee exemption system to properly separate tax collection from game rule enforcement (H-01), implemented per-period rate calculation for accurate floor growth (H-02), and adopted pull-payment patterns for prize distribution (H-05). These architectural improvements not only resolved the specific findings but also made the codebase more maintainable and resilient against future vulnerabilities.
The final remediation outcome achieved an 89% full-resolution rate, with 8 of 9 findings completely fixed and 1 finding (M-02) acknowledged with a documented integration strategy. This outcome elevated the project's security score from 60/100 to 85/100, exceeding Assure DeFi's 84-point passing threshold. The team's willingness to accept the partial fix for H-03 (loop cap rather than closed-form calculation) and the acknowledgment approach for M-02 (documentation rather than code change) reflected mature risk assessment and practical engineering tradeoffs. The production deployment on Base mainnet incorporated all fixes and has operated without security incidents, validating the effectiveness of the remediation process and the thoroughness of the audit.
Ready to secure your smart contracts? View the full FloorIsLava audit dashboard or contact Assure DeFi to start your security audit today.
Assure DeFi provides comprehensive smart contract audits, KYC verification, and ongoing security monitoring for DeFi and Web3 projects. Our experienced team has audited hundreds of protocols, identifying critical vulnerabilities before deployment and helping development teams build secure, trustworthy applications.
This case study is based on publicly available audit reports and documentation. All findings discussed have been addressed through fixes, partial fixes, or acknowledgment prior to publication. This content is for informational purposes only and does not constitute security advice, investment recommendation, or endorsement of the FloorIsLava protocol.
Smart contract security is an evolving field, and no audit can guarantee complete absence of vulnerabilities. Users should conduct their own research and due diligence before interacting with any DeFi protocol. For the most up-to-date security information about FloorIsLava, please visit the project's official channels and the Assure DeFi dashboard.