xanoutas/solidity-security-findings huggingface dataset:
Upgraded Q -> 3 from #114 [1730392914495]
Audit: 2024-08-chakra-findings
Severity: HIGH

Judge has assessed an item in Issue #114 as 3 risk. The relevant finding follows:

 ## [L-02] providing wrong `from_token` data to `create_cross_txs` and `CrossChainLocked` when `cross_chain_erc20_settlement` is called.

The `from_token` data inside `create_cross_txs` state and `CrossChainLocked` event is provided with `address(this)` instead of `token`.

https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L160

```solidity
//...
            //  struct CreatedCrossChainTx {
            //     uint256 txid;
            //     string from_chain;
            //     string to_chain;
            //     address from;
            //     uint256 to;
            //     address from_token;
            //     uint256 to_token;
            //     uint256 amount;
            //     CrossChainTxStatus status;
            // }
            // Save the cross chain tx
            create_cross_txs[txid] = CreatedCrossChainTx(
                txid,
                chain,
                to_chain,
                msg.sender,
                to,
>>>             address(this), 
                to_token,
                amount,
                CrossChainTxStatus.Pending
            );
//...
```

https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L218

```solidity
        //  event CrossChainLocked(
        //     uint256 indexed txid,
        //     address indexed from,
        //     uint256 indexed to,
        //     string from_chain,
        //     string to_chain,
        //     address from_token,
        //     uint256 to_token,
        //     uint256 amount,
        //     SettlementMode mode
        // );
        emit CrossChainLocked(
            txid,
            msg.sender,
            to,
            chain,
            to_chain,
>>>         address(this),
            to_token,
            amount,
            mode
        );
```

### Mitigation

provide `token` as `from_token` instead.
Upgraded Q -> 3 from #92 [1730392578667]
Audit: 2024-08-chakra-findings
Severity: HIGH

Judge has assessed an item in Issue #92 as 3 risk. The relevant finding follows:

 ## [07] The receive_cross_chain_msg function will never return false
## Link
github:[https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/cairo/handler/src/settlement.cairo#L354](https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/cairo/handler/src/settlement.cairo#L354)
github:[https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/cairo/handler/src/handler_erc20.cairo#L108C12-L108C35](https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/cairo/handler/src/handler_erc20.cairo#L108C12-L108C35)
### Description
When a cross-chain message is received, the settlement contract calls the `receive_cross_chain_msg` function of the `handler_erc20` to process the message. The execution status is set based on the result of `receive_cross_chain_msg`: if `receive_cross_chain_msg` returns `true`, the status is set to success; if it returns `false`, the status is set to failure.
```rust
        fn receive_cross_chain_msg(
            ref self: ContractState,
            cross_chain_msg_id: u256,
            from_chain: felt252,
            to_chain: felt252,
            from_handler: u256,
            to_handler: ContractAddress,
            sign_type: u8,
            signatures: Array<(felt252, felt252, bool)>,
            payload: Array<u8>,
            payload_type: u8,
        ) -> bool {
               
            ...
            // call handler receive_cross_chain_msg
            let handler = IHandlerDispatcher{contract_address: to_handler};
            let success = handler.receive_cross_chain_msg(cross_chain_msg_id, from_chain, to_chain, from_handler, to_handler , payload);

            let mut status = CrossChainMsgStatus::SUCCESS;
            if success{
                status = CrossChainMsgStatus::SUCCESS;
            }else{
                status = CrossChainMsgStatus::FAILED;
            }

            self.received_tx.write(cross_chain_msg_id, ReceivedTx{
                tx_id:cross_chain_msg_id,
                from_chain: from_chain,
                from_handler: from_handler,
                to_chain: to_chain,
                to_handler: to_handler,
                tx_status: status
            });

            ...
        }
```
However, the `receive_cross_chain_msg` function will never return false.
If an error occurs, it will cause a revert.
```rust
       fn receive_cross_chain_msg(ref self: ContractState, cross_chain_msg_id: u256, from_chain: felt252, to_chain: felt252,
        from_handler: u256, to_handler: ContractAddress, payload: Array<u8>) -> bool{
            assert(to_handler == get_contract_address(),'error to_handler');

            assert(self.settlement_address.read() == get_caller_address(), 'not settlement');

            assert(self.support_
Upgraded Q -> 3 from #92 [1730392512276]
Audit: 2024-08-chakra-findings
Severity: HIGH

Judge has assessed an item in Issue #92 as 3 risk. The relevant finding follows:

 ## [01] The CreatedCrossChainTx parameter is stored incorrectly
### Link
github:[https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/solidity/handler/contracts/ChakraSettlementHandler.sol#L160](https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/solidity/handler/contracts/ChakraSettlementHandler.sol#L160)
github:[https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/solidity/handler/contracts/BaseSettlementHandler.sol#L59](https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/solidity/handler/contracts/BaseSettlementHandler.sol#L59)
### Description
The `ChakraSettlementHandler` contract incorrectly stores the `from_token` parameter when sending cross-chain messages and recording `CreatedCrossChainTx`. This misstorage creates inconveniences for off-chain tracking and operations.
```solidity
    struct CreatedCrossChainTx {
        uint256 txid;
        string from_chain;
        string to_chain;
        address from;
        uint256 to;
        address from_token;
        uint256 to_token;
        uint256 amount;
        CrossChainTxStatus status;
    }
```
```solidity
    /**
     * @dev Initiates a cross-chain ERC20 settlement
     * @param to_chain The destination chain
     * @param to_handler The destination handler
     * @param to_token The destination token
     * @param to The recipient address
     * @param amount The amount to transfer
     */
    function cross_chain_erc20_settlement(
        string memory to_chain,
        uint256 to_handler,
        uint256 to_token,
        uint256 to,
        uint256 amount
    ) external {
        ...

        {
            // Save the cross chain tx
            create_cross_txs[txid] = CreatedCrossChainTx(
                txid,
                chain,
                to_chain,
                msg.sender,
                to,
                address(this),
                to_token,
                amount,
                CrossChainTxStatus.Pending
            );
        }

        ...
    }
```
### Recommendation
Correctly record the `from_token` field
```diff

    function cross_chain_erc20_settlement(
        string memory to_chain,
        uint256 to_handler,
        uint256 to_token,
        uint256 to,
        uint256 amount
    ) external {
        ...

        {
            // Save the cross chain tx
            create_cross_txs[txid] = CreatedCrossChainTx(
                txid,
                chain,
                to_chain,
                msg.sender,
                to,
-               address(this),
+               address(token),
                to_token,
                amount,
                CrossChainTxStatus.Pending
            );
        }

        ...
    }
```
Upgraded Q -> 3 from #69 [1730392274476]
Audit: 2024-08-chakra-findings
Severity: HIGH

Judge has assessed an item in Issue #69 as 3 risk. The relevant finding follows:

 # L-3. Anyone can increase `nonce_manager[]` of any address

[ChakraSettlement.sol#L118](https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/settlement/contracts/ChakraSettlement.sol#L118)

## Details
The function `send_cross_chain_msg()` is public and allow anyone to increase the `nonce_manager[]` of any address.

```solidity
function send_cross_chain_msg(
    string memory to_chain,
    address from_address,
    uint256 to_handler,
    PayloadType payload_type,
    bytes calldata payload
) external {
    nonce_manager[from_address] += 1;
    // ...
}
```

---
Upgraded Q -> 3 from #55 [1730392153129]
Audit: 2024-08-chakra-findings
Severity: HIGH

Judge has assessed an item in Issue #55 as 3 risk. The relevant finding follows:

 ## Issue4: Parameter `payload_type` can be manipulated on `settlement::receive_cross_chain_msg` 
In the function `settlement::receive_cross_chain_msg`, the parameter `payload_type` is not used in signatures and it is not enforced to be equal to the supported paylaod type. It is only emitted in the event `CrossChainHandleResult` which can be used for callback on the source chain. So, a malicious user can set this parameter to any unsupported payload type leading to wrong event emission.
```rust
        fn receive_cross_chain_msg(
            ref self: ContractState,
            cross_chain_msg_id: u256,
            from_chain: felt252,
            to_chain: felt252,
            from_handler: u256,
            to_handler: ContractAddress,
            sign_type: u8,
            signatures: Array<(felt252, felt252, bool)>,
            payload: Array<u8>,
            payload_type: u8,
        ) -> bool {
            //....

            // emit event
            self.emit(CrossChainHandleResult{
                cross_chain_settlement_id: cross_chain_msg_id,
                from_chain: to_chain,
                from_handler: to_handler,
                to_chain: from_chain,
                to_handler: from_handler,
                cross_chain_msg_status: status,
                payload_type: payload_type
            });
            return true;
        }
```
https://github.com/code-423n4/2024-08-chakra/blob/main/cairo/handler/src/settlement.cairo#L335

Please note that the callback on the source chain, currently does not care about the `payload_type` emitted from the destination chain.
https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/settlement/contracts/ChakraSettlement.sol#L256
Upgraded Q -> 3 from #55 [1730392123695]
Audit: 2024-08-chakra-findings
Severity: HIGH

Judge has assessed an item in Issue #55 as 3 risk. The relevant finding follows:

 ## Issue1: Wrong value of `from_token` in the struct `CreatedCrossChainTx`
When saving the cross chain tx, the `from_token` variable in the struct `CreatedCrossChainTx` is set to `address(this)`, while it should be the address of the token which is going to be bridged.
```solidity
    struct CreatedCrossChainTx {
        uint256 txid;
        string from_chain;
        string to_chain;
        address from;
        uint256 to;
        address from_token;
        uint256 to_token;
        uint256 amount;
        CrossChainTxStatus status;
    }
```
https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/BaseSettlementHandler.sol#L59
```solidity
        {
            // Save the cross chain tx
            create_cross_txs[txid] = CreatedCrossChainTx(
                txid,
                chain,
                to_chain,
                msg.sender,
                to,
                address(this),
                to_token,
                amount,
                CrossChainTxStatus.Pending
            );
        }
```
https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L160

## Issue2: Wrong value of `from_token` in the event `CrossChainLocked`
When emitting the event `CrossChainLocked`, the parameter `from_token` in the event `CrossChainLocked` is set to `address(this)` incorrectly, while it should be the address of the token which is going to be bridged.
```solidity
    event CrossChainLocked(
        uint256 indexed txid,
        address indexed from,
        uint256 indexed to,
        string from_chain,
        string to_chain,
        address from_token,
        uint256 to_token,
        uint256 amount,
        SettlementMode mode
    );
```
https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/BaseSettlementHandler.sol#L47
```solidity
        emit CrossChainLocked(
            txid,
            msg.sender,
            to,
            chain,
            to_chain,
            address(this),
            to_token,
            amount,
            mode
        );
```
https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L218
Upgraded Q -> 3 from #550 [1730391377175]
Audit: 2024-08-chakra-findings
Severity: HIGH

Judge has assessed an item in Issue #550 as 3 risk. The relevant finding follows:

 ## [QA-06] Starknet Handlers Revert When Receiving Cross-Chain Messages from Unwhitelisted Handlers Instead of Returning False Which Can Lead to Issues

### Impact
When Starknet handlers receive cross-chain messages or callbacks from unwhitelisted handlers, they revert instead of returning `false` like implemented in Solidity
```rs
fn receive_cross_chain_msg(ref self: ContractState, cross_chain_msg_id: u256, from_chain: felt252, to_chain: felt252,
    from_handler: u256, to_handler: ContractAddress, payload: Array<u8>) -> bool{
    
    assert(to_handler == get_contract_address(),"error to_handler");
    assert(self.settlement_address.read() == get_caller_address(), "not settlement");
>>>    assert(self.support_handler.read((from_chain, from_handler)) && 
            self.support_handler.read((to_chain, contract_address_to_u256(to_handler))), "not support handler");
}
```
This approach poses a problem: if a cross-chain message from a whitelisted handler is sent to Starknet, but in the interim, the source handler becomes unwhitelisted, the Starknet handler will revert when processing the message. This results in a deadlock where the cross-chain message cannot be processed, leaving it in an unresolved state.

The correct handling should involve emitting a `CrossChainHandleResult` with a `Failed` status, allowing the source chain to manage the issue in the callback, like how it is implemented in Solidity.


### Recommended Mitigation Steps
Consider modifying the Starknet handler to return `false` when receiving a cross-chain message from an unwhitelisted handler, rather than reverting.
Upgraded Q -> 3 from #550 [1730391343380]
Audit: 2024-08-chakra-findings
Severity: HIGH

Judge has assessed an item in Issue #550 as 3 risk. The relevant finding follows:

 ## [QA-02] Incorrect `from_token` Value Set in `CreatedCrossChainTx` struct in `cross_chain_erc20_settlement` During Cross-Chain Message Creation
### Impact
In the `ChakraSettlementHandler` Solidity contract, when a cross-chain message is created, the `CreatedCrossChainTx` structure is populated. However, there is an issue where the 6th argument, which corresponds to the token address on the source chain (`from_token`), is incorrectly set to the address of the handler contract (`address(this)`) instead of the intended token address.
```solidity
function cross_chain_erc20_settlement(
    string memory to_chain,
    uint256 to_handler,
    uint256 to_token,
    uint256 to,
    uint256 amount
) external {
    // --SNIP
    create_cross_txs[txid] = CreatedCrossChainTx(
        txid,
        chain,
        to_chain,
        msg.sender,
        to,
>>>        address(this),
        to_token,
        amount,
        CrossChainTxStatus.Pending
    );
    // --SNIP
}
```

### Recommended Mitigation Steps

Update the 6th argument of the `CreatedCrossChainTx` structure to correctly reference the `from_token` parameter instead of `address(this)`:
```diff
function cross_chain_erc20_settlement(
    string memory to_chain,
    uint256 to_handler,
    uint256 to_token,
    uint256 to,
    uint256 amount
) external {
    // --SNIP
    create_cross_txs[txid] = CreatedCrossChainTx(
        txid,
        chain,
        to_chain,
        msg.sender,
        to,
-       address(this),
+       from_token,
        to_token,
        amount,
        CrossChainTxStatus.Pending
    );
    // --SNIP
}
```

## [QA-03] Incorrect `from_token` Parameter in `CrossChainLocked` Event Emission in `cross_chain_erc20_settlement`

### Impact
In the `ChakraSettlementHandler` Solidity contract, the `CrossChainLocked` event is emitted when a cross-chain message is created. However, there is an issue with the 6th parameter, `from_token`, which should represent the token address on the source chain. Instead, it is incorrectly set to the handler's address (`address(this)`), which could lead to incorrect event logs and confusion when tracking the source token of the transaction.
```solidity
function cross_chain_erc20_settlement(
    string memory to_chain,
    uint256 to_handler,
    uint256 to_token,
    uint256 to,
    uint256 amount
) external {
    // --SNIP
    emit CrossChainLocked(
        txid,
        msg.sender,
        to,
        chain,
        to_chain,
>>>        address(this), 
        to_token,
        amount,
        mode
    );
}
```

### Recommended Mitigation Steps

Update the 6th parameter in the `CrossChainLocked` event to correctly reflect the token address (`from_token`)
```diff
function cross_chain_erc20_settlement(
    string memory to_chain,
    uint256 to_handler,
    uint256 to_token,
    uint
Upgraded Q -> 3 from #553 [1730391034320]
Audit: 2024-08-chakra-findings
Severity: HIGH

Judge has assessed an item in Issue #553 as 3 risk. The relevant finding follows:

 ## [QA-20] Wrong `message_hash` in `receive_cross_chain_callback` on Starknet compared to EVM

**Issue Description:**

`message_hash` of `receive_cross_chain_callback`, constructed in `ChakraSettlement.sol` is completely different from the `message_hash` in `settlement.cairo` .

In Solidity it’s constructed from:

- `txid`
- `from_handler`
- `to_handler`
- `status`

[ChakraSettlement.sol](https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/settlement/contracts/ChakraSettlement.sol#L285C5-L301C6)

```solidity
function verifySignature(
      uint256 txid,
      uint256 from_handler,
      address to_handler,
      CrossChainMsgStatus status,
      uint8 sign_type,
      bytes calldata signatures
  ) internal view {
      bytes32 message_hash = keccak256(
          abi.encodePacked(txid, from_handler, to_handler, status)
      );

      require(
          signature_verifier.verify(message_hash, signatures, sign_type),
          "Invalid signature"
      );
  }
```

In Cairo it’s constructed from:

- `from_chain`
- `cross_chain_msg_id` (txid)
- `to_chain`
- `from_handler`
- `to_handler`
- `status`

[settlement.cairo](https://github.com/code-423n4/2024-08-chakra/blob/main/cairo/handler/src/settlement.cairo#L393C9-L413C74)

```rust
fn receive_cross_chain_callback(
          ref self: ContractState,
          cross_chain_msg_id: felt252,
          from_chain: felt252,
          to_chain: felt252,
          from_handler: u256,
          to_handler: ContractAddress,
          cross_chain_msg_status: u8,
          sign_type: u8,
          signatures: Array<(felt252, felt252, bool)>,
      ) -> bool {
          assert(self.created_tx.read(cross_chain_msg_id).tx_id == cross_chain_msg_id, 'message id error');
          assert(self.created_tx.read(cross_chain_msg_id).from_chain == to_chain, 'from_chain error');
          assert(self.created_tx.read(cross_chain_msg_id).to_chain == from_chain, 'to_chain error');
          assert(self.created_tx.read(cross_chain_msg_id).from_handler == to_handler, 'from_handler error');
          assert(self.created_tx.read(cross_chain_msg_id).to_handler == from_handler, 'to_handler error');
          assert(self.created_tx.read(cross_chain_msg_id).tx_status == CrossChainMsgStatus::PENDING, 'tx status error');

          let mut message_hash_temp: felt252 = LegacyHash::hash(from_chain, (cross_chain_msg_id, to_chain, from_handler, to_handler));
          let message_hash_final:felt252 = LegacyHash::hash(message_hash_temp, cross_chain_msg_status);
          self.check_chakra_signatures(message_hash_final, signatures);
```

As we can see the order is different and `from_chain`, `to_chain` are missing in `Solidity`. But the intentions of the team is to construct hashes in the same way on both chains.

**Recommendation:**

Modify the `message_hash` in Solidity to look