Documentation

Auditing Euler Vault Kit (Euler V2) with Olympix AI VS Code Extension

Step-by-step guide to analyze the Euler Vault Kit codebase for security vulnerabilities using the Olympix Web3 Cybersecurity Assistant.

1. Clone the Repository

First, clone the Euler Vault Kit and checkout the known-v2 commit:

git clone https://github.com/euler-xyz/euler-vault-kit.git
cd euler-vault-kit
git checkout f6fd0ee3b454630abd961d6471beb0c7eaf1216a

2. Open VS Code Extensions Panel

  • Open the Command Palette (Cmd+Shift+P / Ctrl+Shift+P)
  • Run View: Show Extensions

3. Install Olympix Extension

  1. In the Extensions search box, type “Olympix Web 3 Cybersecurity Assistant”
  2. Click Install Extensions Panel Placeholder

4. Authenticate Olympix

  • Click the Olympix icon in the sidebar to the left Post-Install Modal Placeholder
  • Enter your email when prompted
  • Check your inbox for the verification code
  • Paste the code into the modal to unlock the extension Authentication Placeholder

5. Run the Vulnerability Analysis

  • Open the root folder of the project in VS Code
  • Click the Start Analysis button in the Olympix pane

Note: The first run can take 3–5 minutes. If it hangs or fails, cancel and retry.

6. Review Findings

Once complete, Olympix will list:

  • Vulnerabilities with severity & confidence
  • File paths and line numbers
  • AI-generated explanations Analysis In Progress Placeholder

7. Deep Dive Example

Below are some vulnerabilities that Olympix AI flagged in the Euler Vault Kit (Euler V2). Vulnerability Breakdown Placeholder

Vulnerability 1: Locked Ether

What is the Locked Ether vulnerability?

When a contract accepts ETH but provides no way to withdraw it, those funds become permanently “locked” in the contract’s balance.

Real-world example:
In 2017, a bug in Parity’s multisig wallet library allowed an attacker to self-destruct the shared library contract, freezing over 513 000 ETH across thousands of wallets.

Locked Ether

Vulnerable code:

contract Locked {
    mapping(address => uint) public balances;
 
    function receiveEther() payable public {
        balances[msg.sender] += msg.value;
    }
 
    function payToUser(address user, uint256 amount) public {
        require(balances[msg.sender] >= amount);
        balances[msg.sender] -= amount;
        balances[user] += amount;
    }
}

Here, receiveEther lets users deposit ETH, and payToUser only updates an internal ledger—there is no withdraw function to send ETH out.

Fix: add a withdraw function

contract Unlocked {
    mapping(address => uint) public balances;
 
    function receiveEther() payable public {
        balances[msg.sender] += msg.value;
    }
 
    function payToUser(address user, uint256 amount) public {
        require(balances[msg.sender] >= amount);
        balances[msg.sender] -= amount;
        balances[user] += amount;
    }
 
    function withdraw(uint amount) public {
        require(balances[msg.sender] >= amount);
        balances[msg.sender] -= amount;
        payable(msg.sender).transfer(amount);
    }
}

Vulnerability 2: abi.encodePacked with Dynamic Types

What is the issue?

abi.encodePacked(...) concatenates arguments tightly. If you pack multiple dynamic types, different inputs can collide, leading to the same hash.

encodepacked

Vulnerable code:

contract SimpleVoting {
    mapping(bytes32 => bool[]) public sessionVotes;
 
    function createSession(string memory name, string memory date) public {
        bytes32 sessionId = keccak256(
            abi.encodePacked(name, date)
        );
        // ...
    }
}

Two different (name, date) pairs can produce the same sessionId.

Fix: use abi.encode or a single dynamic argument

bytes32 sessionId = keccak256(
    abi.encode(name, date)
);

Vulnerability 3: Unchecked Block with Subtraction

What is the issue?

Inside an unchecked { ... } block, arithmetic will wrap on underflow/overflow instead of reverting—potentially giving a malicious user an inflated balance.

unchecked-block

Vulnerable code:

function withdraw(uint256 _amount) external {
    unchecked {
        balances[msg.sender] = balances[msg.sender] - _amount;
    }
    // transfers omitted...
}

If _amount exceeds the balance, balances[msg.sender] underflows to a huge value.

Fix: rely on Solidity >=0.8’s built-in checks (no unchecked), or validate manually:

function withdraw(uint256 _amount) external {
    require(balances[msg.sender] >= _amount, "Insufficient balance");
    balances[msg.sender] -= _amount;
    // transfers...
}

These were a few examples showcasing the capabilities of Olympix AI, you can review the full report in the Olympix pane and click into any finding for detailed AI explanations, call stacks, and suggested fixes.

Conclusion

You’ve now seen how to use Olympix AI to scan any Solidity project for security issues. Integrating AI into your code review process can surface subtle bugs, speed up audits, and help teams ship more secure smart contracts from the get go.