Uploaded files for judging

001/001.md

@@ -0,0 +1,74 @@
+Shaggy Smoke Mole
+
+Medium
+
+# Unsafe use of tx.origin in the mint function will leading to unauthorized LP token minting
+
+### Summary
+
+The use of `tx.origin` in the [`mint` function](https://github.com/sherlock-audit/2024-08-velar-artha/blob/main/gl-sherlock/contracts/core.vy#L166) of the Velar protocol allows for a phishing attack. If a user grants unlimited allowance to the contract for `base_token` and `quote_token`, a malicious contract can execute the `mint` function on their behalf, resulting in unauthorized minting of LP tokens. The root cause is the use of `tx.origin` to determine the user, which is unsafe as it can be manipulated by intermediate contracts.
+
+### Root Cause
+
+In [`core.vy:166`](https://github.com/sherlock-audit/2024-08-velar-artha/blob/main/gl-sherlock/contracts/core.vy#L166) there is an unsafe use of `tx.origin` as it can cause unauthorized minting.
+The choice to use tx.origin may be because of `api.vy` contract between user and `core.vy` contract. There is a good explaination of why it is unsafe in the Solidity documentation: https://docs.soliditylang.org/en/latest/security-considerations.html#tx-origin.
+
+The `mint` function in `API.vy` allows users to mint LP tokens by depositing `base_token` and `quote_token` into the contract. The function uses `tx.origin` to identify the user initiating the transaction:
+
+```python
+user : address = tx.origin
+```
+
+This design is problematic because `tx.origin` represents the original sender of the transaction, not necessarily the direct caller. In scenarios where a user interacts with another contract that in turn calls the `mint` function, `tx.origin` will still point to the original user. 
+
+### Internal pre-conditions
+
+1. The victim must have granted an allowance to the core contract address for both `base_token` and `quote_token`, enabling the contract to transfer tokens on the victim's behalf.
+
+2. The victim must initiate a transaction with a smart contract that allows the attacker to indirectly call the `mint` function at any point during the transaction. This can be easily achieved, for example, if the victim interacts with an automated router like Uniswap's that swaps tokens based on optimal trade routes. The attacker could create a malicious token involved in the trade, and within the `transfer` function of this malicious token, the attacker can execute a call to the Velor protocol's `mint` function. Because `tx.origin` will still refer to the victim, the Velor protocol will perceive the transaction as initiated by the victim.
+
+### External pre-conditions
+
+_No response_
+
+### Attack Path
+
+If a user has set an unlimited allowance for `base_token` and `quote_token` to this contract, a malicious contract can execute a phishing attack by:
+
+1. Encouraging the user to initiate a transaction on the malicious contract. As explained in internal pre-conditions, it is not hard.
+2. Having the malicious contract call the `mint` function on `API.vy`.
+3. Using `tx.origin` to transfer tokens from the user’s address to the contract, minting new LP tokens without the user's explicit consent.
+
+
+### Impact
+
+- **Unauthorized Token Minting:** An attacker can exploit this vulnerability to force a user to mint LP tokens, leading to unauthorized token movements, and potential **loss of funds**.
+
+### PoC
+
+_No response_
+
+### Mitigation
+
+To mitigate this vulnerability, replace `tx.origin` with a `user` parameter passed to the `mint` function. This parameter should be set by the `msg.sender` when the `API.vy` contract calls the function. The updated function signature should look like this:
+
+```python
+@external
+def mint(
+  user        : address,
+  id          : uint256,
+  base_token  : address,
+  quote_token : address,
+  lp_token    : address,
+  base_amt    : uint256,
+  quote_amt   : uint256,
+  ctx         : Ctx) -> uint256:
+```
+
+Additionally, the contract call on `api.vy:101` should be updated to:
+
+```python
+  return self.CORE.mint(msg.sender, 1, base_token, quote_token, lp_token, base_amt, quote_amt, ctx)
+```
+
+By passing `msg.sender` as the `user`, the function ensures that only the immediate caller is authorized to initiate the minting process, thus preventing phishing attacks.

001/002.md

@@ -0,0 +1,71 @@
+Shaggy Smoke Mole
+
+Medium
+
+# Unsafe use of tx.origin in the burn function will lead to unauthorized LP token burn
+
+### Summary
+
+The use of `tx.origin` in the [`burn` function](https://github.com/sherlock-audit/2024-08-velar-artha/blob/main/gl-sherlock/contracts/core.vy#L192) of the Velar protocol exposes users to phishing attacks. If a user grants unlimited allowance to the contract for `base_token` and `quote_token`, a malicious contract can execute the `burn` function on their behalf, resulting in unauthorized burning of LP tokens and potential loss of the underlying assets. The root cause is the use of `tx.origin` to determine the user, which is unsafe as it can be manipulated by intermediate contracts.
+
+### Root Cause
+
+In [`core.vy:202`](https://github.com/sherlock-audit/2024-08-velar-artha/blob/main/gl-sherlock/contracts/core.vy#L195), there is an unsafe use of `tx.origin`, which can result in unauthorized token burns. The choice to use `tx.origin` is likely due to the `API.vy` contract serving as an intermediary between the user and the `core.vy` contract. However, `tx.origin` usage is considered insecure because it references the original sender of a transaction, which can lead to unintended consequences when intermediary contracts are involved. The Solidity documentation provides a detailed explanation of why `tx.origin` is unsafe: [Solidity Security Considerations - `tx.origin`](https://docs.soliditylang.org/en/latest/security-considerations.html#tx-origin).
+
+The `burn` function in `core.vy` allows users to burn LP tokens and retrieve their `base_token` and `quote_token`. The function uses `tx.origin` to identify the user initiating the transaction:
+
+```python
+user : address = tx.origin
+```
+
+This design is problematic because `tx.origin` represents the original sender of the transaction, not necessarily the direct caller. In scenarios where a user interacts with another contract that in turn calls the `burn` function, `tx.origin` will still point to the original user.
+
+### Internal Pre-conditions
+
+1. The victim must have granted an allowance to the core contract address for both `base_token` and `quote_token`, enabling the contract to transfer tokens on the victim's behalf.
+
+2. The victim must initiate a transaction with a smart contract that allows the attacker to indirectly call the `burn` function at any point during the transaction. This can be easily achieved, for example, if the victim interacts with an automated router like Uniswap's that swaps tokens based on optimal trade routes. The attacker could create a malicious token involved in the trade, and within the `transfer` function of this malicious token, the attacker can execute a call to the Velor protocol's `burn` function. Because `tx.origin` will still refer to the victim, the Velor protocol will perceive the transaction as initiated by the victim.
+
+### External Pre-conditions
+
+_No response_
+
+### Attack Path
+
+If a user has set an unlimited allowance for `base_token` and `quote_token` to this contract, a malicious contract can execute a phishing attack by:
+
+1. Encouraging the user to initiate a transaction on the malicious contract. As explained in internal pre-conditions, it is not hard.
+2. Having the malicious contract call the `burn` function on `API.vy`.
+3. Using `tx.origin` to transfer tokens from the user’s address to the contract, burning the user's LP tokens and retrieving the underlying assets without the user's explicit consent.
+
+### Impact
+
+- **Unauthorized Token Burning and Asset Transfer:** An attacker can exploit this vulnerability to force a user to burn their LP tokens, leading to unauthorized retrieval of underlying assets and potential **loss of funds**.
+
+### PoC
+
+_No response_
+
+### Mitigation
+
+To mitigate this vulnerability, replace `tx.origin` with a `user` parameter passed to the `burn` function. This parameter should be set by the `msg.sender` when the `API.vy` contract calls the function. The updated function signature should look like this:
+
+```python
+@external
+def burn(
+  user        : address,
+  id          : uint256,
+  base_token  : address,
+  quote_token : address,
+  lp_token    : address,
+  lp_amt      : uint256,
+  ctx         : Ctx) -> Tokens:
+```
+
+Additionally, the contract call on `api.vy:128` should be updated to:
+
+```python
+  return self.CORE.burn(msg.sender, 1, base_token, quote_token, lp_token, lp_amt, ctx)
+```
+
+By passing `msg.sender` as the `user`, the function ensures that only the immediate caller is authorized to initiate the burning process, thus preventing phishing attacks.

001/003.md

@@ -0,0 +1,72 @@
+Shaggy Smoke Mole
+
+Medium
+
+# Unsafe use of tx.origin in the open function will lead to unauthorized position opening
+
+### Summary
+
+The use of `tx.origin` in the [`open` function](https://github.com/sherlock-audit/2024-08-velar-artha/blob/main/gl-sherlock/contracts/core.vy#L230) of the Velar protocol exposes users to phishing attacks. If a user grants unlimited allowance to the contract for `base_token` or `quote_token`, a malicious contract can execute the `open` function on their behalf, resulting in unauthorized creation of leveraged positions. The root cause is the use of `tx.origin` to determine the user, which is unsafe as it can be manipulated by intermediate contracts.
+
+### Root Cause
+
+In [`core.vy:241`](https://github.com/sherlock-audit/2024-08-velar-artha/blob/main/gl-sherlock/contracts/core.vy#L241), there is an unsafe use of `tx.origin`, which can lead to unauthorized opening of leveraged positions. The choice to use `tx.origin` might be due to the `API.vy` contract serving as an intermediary between the user and the `core.vy` contract. However, `tx.origin` is considered insecure because it references the original sender of a transaction, which can lead to unintended consequences when intermediary contracts are involved. The Solidity documentation provides a detailed explanation of why `tx.origin` is unsafe: [Solidity Security Considerations - `tx.origin`](https://docs.soliditylang.org/en/latest/security-considerations.html#tx-origin).
+
+The `open` function in `core.vy` allows users to open leveraged positions by depositing collateral and leveraging it against the pool. The function uses `tx.origin` to identify the user initiating the transaction:
+
+```python
+user : address = tx.origin
+```
+
+This design is problematic because `tx.origin` represents the original sender of the transaction, not necessarily the direct caller. In scenarios where a user interacts with another contract that in turn calls the `open` function, `tx.origin` will still point to the original user.
+
+### Internal Pre-conditions
+
+1. The victim must have granted an allowance to the core contract address for either `base_token` or `quote_token`, enabling the contract to transfer tokens on the victim's behalf.
+
+2. The victim must initiate a transaction with a smart contract that allows the attacker to indirectly call the `open` function at any point during the transaction. This can be easily achieved, for example, if the victim interacts with an automated router like Uniswap's that swaps tokens based on optimal trade routes. The attacker could create a malicious token involved in the trade, and within the `transfer` function of this malicious token, the attacker can execute a call to the Velor protocol's `open` function. Because `tx.origin` will still refer to the victim, the Velor protocol will perceive the transaction as initiated by the victim.
+
+### External Pre-conditions
+
+_No response_
+
+### Attack Path
+
+If a user has set an unlimited allowance for `base_token` or `quote_token` to this contract, a malicious contract can execute a phishing attack by:
+
+1. Encouraging the user to initiate a transaction on the malicious contract. As explained in internal pre-conditions, it is not hard.
+2. Having the malicious contract call the `open` function on `API.vy`.
+3. Using `tx.origin` to transfer tokens from the user’s address to the contract, opening a leveraged position without the user's explicit consent.
+
+### Impact
+
+- **Unauthorized Position Opening:** An attacker can exploit this vulnerability to force a user to open leveraged positions, leading to unauthorized token movements and potential **financial losses** due to unexpected margin calls or liquidations.
+
+### PoC
+
+_No response_
+
+### Mitigation
+
+To mitigate this vulnerability, replace `tx.origin` with a `user` parameter passed to the `open` function. This parameter should be set by the `msg.sender` when the `API.vy` contract calls the function. The updated function signature should look like this:
+
+```python
+@external
+def open(
+  user        : address,
+  id          : uint256,
+  base_token  : address,
+  quote_token : address,
+  long        : bool,
+  collateral0 : uint256,
+  leverage    : uint256,
+  ctx         : Ctx) -> PositionState:
+```
+
+Additionally, the contract call on `api.vy:158` should be updated to:
+
+```python
+  return self.CORE.open(msg.sender, 1, base_token, quote_token, long, collateral0, leverage, ctx)
+```
+
+By passing `msg.sender` as the `user`, the function ensures that only the immediate caller is authorized to initiate the opening of a leveraged position, thus preventing phishing attacks.

001/004.md

@@ -0,0 +1,70 @@
+Shaggy Smoke Mole
+
+Medium
+
+# Unsafe use of tx.origin in the open function will lead to unauthorized position closing
+
+### Summary
+
+The use of `tx.origin` in the [`close` function](https://github.com/sherlock-audit/2024-08-velar-artha/blob/main/gl-sherlock/contracts/core.vy#L272) of the Velar protocol exposes users to phishing attacks. If a user grants unlimited allowance to the contract for `base_token` or `quote_token`, a malicious contract can execute the `close` function on their behalf, resulting in unauthorized closure of leveraged positions. The root cause is the use of `tx.origin` to determine the user, which is unsafe as it can be manipulated by intermediate contracts.
+
+### Root Cause
+
+In [`core.vy:281`](https://github.com/sherlock-audit/2024-08-velar-artha/blob/main/gl-sherlock/contracts/core.vy#L281), there is an unsafe use of `tx.origin`, which can lead to unauthorized closing of positions. The choice to use `tx.origin` might be due to the `API.vy` contract serving as an intermediary between the user and the `core.vy` contract. However, `tx.origin` is considered insecure because it references the original sender of a transaction, which can lead to unintended consequences when intermediary contracts are involved. The Solidity documentation provides a detailed explanation of why `tx.origin` is unsafe: [Solidity Security Considerations - `tx.origin`](https://docs.soliditylang.org/en/latest/security-considerations.html#tx-origin).
+
+The `close` function in `core.vy` allows users to close their leveraged positions by settling them against the pool. The function uses `tx.origin` to identify the user initiating the transaction:
+
+```python
+user : address = tx.origin
+```
+
+This design is problematic because `tx.origin` represents the original sender of the transaction, not necessarily the direct caller. In scenarios where a user interacts with another contract that in turn calls the `close` function, `tx.origin` will still point to the original user.
+
+### Internal Pre-conditions
+
+1. The victim must have granted an allowance to the core contract address for either `base_token` or `quote_token`, enabling the contract to transfer tokens on the victim's behalf.
+
+2. The victim must initiate a transaction with a smart contract that allows the attacker to indirectly call the `close` function at any point during the transaction. This can be easily achieved, for example, if the victim interacts with an automated router like Uniswap's that swaps tokens based on optimal trade routes. The attacker could create a malicious token involved in the trade, and within the `transfer` function of this malicious token, the attacker can execute a call to the Velor protocol's `close` function. Because `tx.origin` will still refer to the victim, the Velor protocol will perceive the transaction as initiated by the victim.
+
+### External Pre-conditions
+
+_No response_
+
+### Attack Path
+
+If a user has set an unlimited allowance for `base_token` or `quote_token` to this contract, a malicious contract can execute a phishing attack by:
+
+1. Encouraging the user to initiate a transaction on the malicious contract. As explained in internal pre-conditions, it is not hard.
+2. Having the malicious contract call the `close` function on `API.vy`.
+3. Using `tx.origin` to transfer tokens from the user’s address to the contract, closing a leveraged position without the user's explicit consent.
+
+### Impact
+
+- **Unauthorized Position Closure:** An attacker can exploit this vulnerability to force a user to close their leveraged positions, leading to unauthorized token movements and potential **financial losses** due to unexpected liquidation or settlement conditions.
+
+### PoC
+
+_No response_
+
+### Mitigation
+
+To mitigate this vulnerability, replace `tx.origin` with a `user` parameter passed to the `close` function. This parameter should be set by the `msg.sender` when the `API.vy` contract calls the function. The updated function signature should look like this:
+
+```python
+@external
+def close(
+  user        : address,
+  id          : uint256,
+  base_token  : address,
+  quote_token : address,
+  position_id : uint256,
+  ctx         : Ctx) -> PositionValue:
+```
+
+Additionally, the contract call on `api.vy:183` should be updated to:
+
+```python
+  return self.CORE.close(msg.sender, 1, base_token, quote_token, position_id, ctx)
+```
+
+By passing `msg.sender` as the `user`, the function ensures that only the immediate caller is authorized to initiate the closing of a leveraged position, thus preventing phishing attacks.