TAPIOCA-BAR SECURITY AUDIT REPORT

Table of Contents

Executive Summary

This audit of the Tapioca-bar protocol identified 25 vulnerabilities across 39 Solidity contracts comprising approximately 7,417 lines of code. The protocol implements a CDP lending system (BigBang) for minting the USDO stablecoin, a Kashi-fork lending market (Singularity), and cross-chain token functionality via LayerZero.

The most severe finding is a fundamental accounting bug where normal liquidations in both BigBang and Singularity never decrement totalBorrow, causing phantom debt to accumulate permanently. This leads to inflated interest rates, incorrect solvency calculations, and eventual protocol insolvency. Combined with broken leverage functions (wrong YieldBox asset IDs and token approvals), the protocol has critical operational failures that would affect users immediately upon deployment.

Finding Summary

Scope

Files Audited

Exclusions

System Architecture

Component Overview

+-------------------+
|     Penrose       |  Global registry, fee management, market factory
+--------+----------+
         |
    +----+----+-------------------+
    |         |                   |
+---v---+ +---v--------+   +-----v------+
|BigBang| |Singularity  |   |   USDO     |
| (CDP) | |(Lending Mkt)|   |(Stablecoin)|
+---+---+ +------+------+   +-----+------+
    |            |                 |
    +-----+------+         +------+------+
          |                |             |
    +-----v------+   +----v----+  +-----v--------+
    | YieldBox   |   |Leverage |  |LayerZero OFT |
    | (Vault)    |   |Executors|  |(Cross-chain)  |
    +------------+   +---------+  +--------------+

Key Trust Assumptions

Core Invariants

Critical Findings

C-1: Normal Liquidation Never Reduces totalBorrow (BigBang + Singularity)

In both BBLiquidation._liquidateUser() and SGLLiquidation._liquidateUser(), userBorrowPart[user] is decremented and USDO is burned (BigBang) or assets are deposited back (Singularity), but totalBorrow.elastic and totalBorrow.base are never decremented. Only the owner-only liquidateBadDebt() function correctly updates totalBorrow.

In BBLiquidation.sol:

Contrast with liquidateBadDebt (lines 85-86) which correctly does:

totalBorrow.elastic -= borrowAmount.toUint128();
totalBorrow.base -= userBorrowPart[user].toUint128();

The identical pattern exists in SGLLiquidation.sol:

After every normal liquidation, totalBorrow permanently includes phantom debt:

Add totalBorrow.sub(borrowPart, true) inside _updateBorrowAndCollateralShare() in both BBLiquidation.sol and SGLLiquidation.sol:

// In _updateBorrowAndCollateralShare, after computing borrowPart:
totalBorrow.sub(borrowPart, true);
userBorrowPart[user] -= borrowPart;

C-2: BBLeverage.sellCollateral Deposits to Wrong YieldBox Asset ID

In BBLeverage.sellCollateral(), after swapping collateral for asset tokens via leverageExecutor.getAsset(), the received asset tokens are deposited into YieldBox under collateralId instead of assetId. The approval is also for the wrong token (asset instead of collateral).

// Line 147: shares computed for assetId (correct)
memoryData.shareOut = yieldBox.toShare(assetId, amountOut, false);

// Line 148: approves asset token (wrong - should be collateral if depositing to collateralId)
address(asset).safeApprove(address(yieldBox), type(uint256).max);

// Line 149: deposits to collateralId (WRONG - should be assetId)
yieldBox.depositAsset(collateralId, address(this), address(this), 0, memoryData.shareOut);

Compare with SGLLeverage.sol:135 which correctly uses assetId:

yieldBox.depositAsset(assetId, address(this), address(this), 0, shareOut);

Change collateralId to assetId on line 149:

yieldBox.depositAsset(assetId, address(this), address(this), 0, memoryData.shareOut);

C-3: BBLeverage.buyCollateral and SGLLeverage.buyCollateral Approve Wrong Token

In buyCollateral(), after leverageExecutor.getCollateral() returns collateral tokens, the code approves address(asset) for YieldBox but then calls yieldBox.depositAsset(collateralId, ...). The approval is for the asset token, but YieldBox needs the collateral token approved to pull it during deposit.

// BBLeverage.sol line 103: approves ASSET token (WRONG)
address(asset).safeApprove(address(yieldBox), type(uint256).max);

// BBLeverage.sol line 104: deposits COLLATERAL (needs collateral approved, not asset)
yieldBox.depositAsset(collateralId, address(this), address(this), 0, collateralShare);

Same pattern in SGLLeverage.sol:87-88.

Change the approval to the collateral token:

address(collateral).safeApprove(address(yieldBox), type(uint256).max);
yieldBox.depositAsset(collateralId, address(this), address(this), 0, collateralShare);
address(collateral).safeApprove(address(yieldBox), 0);

High Findings

H-1: _allowedBorrow Pearlmit Integration Is Broken

The TODO comment on line 418 (// TODO review risk of using this) confirms developer awareness of this issue.

Pearlmit-based approvals cannot be used for borrow operations. Any cross-chain flow relying solely on Pearlmit approval for borrowing will revert.

Only decrement allowanceBorrow when it was the satisfying condition:

if (allowanceBorrow[from][msg.sender] >= share) {
    if (allowanceBorrow[from][msg.sender] != type(uint256).max) {
        allowanceBorrow[from][msg.sender] -= share;
    }
} else {
    require(pearlmitAllowed >= share, "Market: not approved");
    // Consume pearlmit allowance via Pearlmit contract
}

H-2: Usdo.executeModule() Allows Direct Module Execution with Controllable srcChainSender

An attacker can call exerciseOptionsReceiver with a crafted srcChainSender. If srcChainSender == _owner, the allowance check in _internalTransferWithAllowance is skipped. This could allow unauthorized token operations for users who have USDO balance and have approved the USDO contract for cross-chain operations.

Add access control to executeModule() or validate srcChainSender against the actual LayerZero origin inside receiver modules:

function executeModule(uint8 _module, bytes memory _data, bool _forwardRevert)
    external payable whenNotPaused onlyEndpoint {
    // ...
}

H-3: Stale Exchange Rate (24-Hour Cache) in Solvency Checks

The exchangeRate is cached with a rateValidDuration of 24 hours. When oracle.get() returns updated=false, the stale cached rate is used as long as rateTimestamp + rateValidDuration >= block.timestamp. In volatile markets, a 24-hour-old rate can deviate significantly from current prices.

Users can borrow against inflated collateral values or avoid legitimate liquidations during price drops. Conversely, users may be unfairly liquidated when the stale rate undervalues their collateral.

Reduce rateValidDuration to a shorter period (e.g., 1 hour) and implement a secondary oracle fallback.

H-4: Liquidation Uses Stale Rate Without Staleness Check on Oracle Failure

catch {
    if (exchangeRate == 0) revert ExchangeRateNotValid();
    // No rateValidDuration check here!
}

If an attacker can cause the oracle to revert (e.g., manipulated pool observations, deprecated Chainlink feed), liquidations proceed at an arbitrarily old rate. This enables unfair liquidations or prevents legitimate ones.

Add the staleness check in the catch block:

catch {
    require(rateTimestamp + rateValidDuration >= block.timestamp, "Market: rate too old");
    if (exchangeRate == 0) revert ExchangeRateNotValid();
}

H-5: BigBang Debt Rate Cross-Market Manipulation via Flash Loans

Non-main BigBang markets compute their debt rate from the ETH main market's totalBorrow.elastic via getDebtRate(). An attacker can flash-loan collateral, borrow heavily in the ETH market to inflate _ethMarketTotalDebt, then accrue on non-main markets at the manipulated rate.

Use a time-weighted average of the ETH market debt rather than a spot reading. Alternatively, introduce a minimum delay between rate changes.

H-6: Division by Zero in _isSolvent When totalBorrow.base == 0

If totalBorrow.base reaches 0 (e.g., after liquidateBadDebt clears the last borrower) but a user retains dust borrowPart due to Rebase rounding, _isSolvent divides by totalBorrow.base (zero), causing a permanent revert. That user can never call removeCollateral because the solvent modifier reverts.

// Line 479 - divides by _totalBorrow.base
>= (borrowPart * _totalBorrow.elastic * _exchangeRate) / _totalBorrow.base;

Line 469 early-returns if borrowPart == 0, but does NOT handle totalBorrow.base == 0 when borrowPart > 0.

Permanent fund lockup for affected users. Their collateral is forever locked in the contract.

Add a zero-check:

if (_totalBorrow.base == 0) {
    return borrowPart == 0; // Solvent only if no borrow
}

H-7: Read-Only Reentrancy in Liquidation (totalAsset Stale During Callback)

In _liquidateUser(), totalAsset.elastic is updated after the external call to _liquidatorReceiver.onCollateralReceiver(). During the callback, any external protocol reading totalAsset sees stale values. The nonReentrant guard on execute() prevents re-entry into Singularity itself, but external protocols composing with Singularity during the callback window get incorrect share price data.

External DeFi protocols integrating with Singularity (e.g., vaults, yield aggregators) could make incorrect decisions based on stale totalAsset during liquidation callbacks.

Move totalAsset.elastic update before the external call, or mark all view functions that external protocols might call with appropriate reentrancy awareness.

H-8: Origins._accrueView Returns Zero Rebase — Breaks computeTVLInfo

All view functions relying on computeTVLInfo() break for Origins markets. Frontend displays, monitoring tools, and external integrations all fail.

Return the actual totalBorrow from _accrueView():

function _accrueView() internal view override returns (Rebase memory) {
    return totalBorrow;
}

Medium Findings

M-1: Singularity First-Depositor Share Inflation Attack

The minimum 1000-share threshold in _addAsset() is insufficient to prevent share inflation attacks. An attacker who is the first depositor can deposit 1000 shares, then donate a large amount directly to YieldBox, inflating the share price. Subsequent depositors lose value due to rounding in the fraction = (share * _totalAsset.base) / allShare calculation. A virtual share/asset offset (like OpenZeppelin's ERC4626 implementation) would provide stronger protection.

M-2: Shared Nonce Between permit() and permitBorrow()

A single _nonces[owner] counter is used for both permit() and permitBorrow(). Submitting one permit type invalidates pending signatures of the other. While different type hashes prevent actual cross-function replay, the shared nonce creates a griefing vector — especially problematic for cross-chain composed operations where timing of permit execution is critical.

M-3: Cross-Chain Market Modules Don't Receive srcChainSender

M-4: Unbounded allBigBangMarkets Loop in _reAccrueMarkets

M-5: SGL _repay Rounds Down Instead of Up

M-6: _accrueView vs _accrue Year Constant Inconsistency

M-7: Seer Oracle Always Returns success=true

The Seer oracle's get() function always returns success=true (line 64) as long as it doesn't revert. It has no mechanism to signal degraded data quality. Since Market.updateExchangeRate() checks the updated return value to decide whether to refresh the cached rate, and Seer always returns true, the market will always accept the returned rate — even if it's based on stale TWAP data from an illiquid pool.

M-8: TWAP Period Configurable to 1 Second (No Minimum Floor)

M-9: Chainlink Missing Explicit price > 0 and answeredInRound Checks

M-10: BigBang init() Missing Module Address Zero-Check

Low Findings

L-1: PearlmitHash Type Hash String Inconsistency

L-2: Conservator Pause/Unpause Has No Timelock

The conservator can instantly toggle pause states for any market operation. No timelock or multi-sig requirement exists. If the conservator key is compromised, an attacker could unpause a market that was paused during an active exploit.

L-3: Origins allowedParticipants Has No Setter Function

Only the constructor sets allowedParticipants[_owner] = true. No function exists to add or remove participants post-deployment. If the owner address needs to be rotated, the entire Origins market becomes unusable.

L-4: _extractLiquidationFees Max Approval Pattern

Invariants Verified

The following invariants were tested and confirmed to hold:

Methodology

Phase 1: Setup

Phase 2: Map

Phase 3: Hunt (Deep Mode)

5 parallel agents scanned all contracts:

Phase 4: Attack

Phase 5: Report

*Report generated by SC Mega Auditor*