xanoutas/solidity-security-findings huggingface dataset:
Upgraded Q -> M from 207 [1666364300864]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #207 as Medium risk. The relevant finding follows:

[L-03] Use safeTransferFrom for ERC721 tokens
Description
As [OpenZeppelin recommends](https://docs.openzeppelin.com/contracts/4.x/api/token/erc721#IERC721-transferFrom-address-address-uint256-), the transferFrom function should not be used for transferring ERC721 NFT tokens and instead the safeTransferFrom function should be used to prevent tokens from being locked.

Findings
https://github.com/code-423n4/2022-07-golom/blob/7bbb55fca61e6bae29e57133c1e45806cbb17aa4/contracts/core/GolomTrader.sol#L236
https://github.com/code-423n4/2022-07-golom/blob/7bbb55fca61e6bae29e57133c1e45806cbb17aa4/contracts/core/GolomTrader.sol#L301
https://github.com/code-423n4/2022-07-golom/blob/7bbb55fca61e6bae29e57133c1e45806cbb17aa4/contracts/core/GolomTrader.sol#L361

Recommended mitigation steps
Use the safeTransferFrom function in place of the transferFrom function.
Upgraded Q -> M from 460 [1666364175291]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #460 as Medium risk. The relevant finding follows:

7. transfer is used to transfer Ether
Description: GolomTrader [uses](https://github.com/code-423n4/2022-07-golom/blob/main/contracts/core/GolomTrader.sol#L154) transfer method to send Ether.
This is generally less recommended these days (see [article](https://consensys.net/diligence/blog/2019/09/stop-using-soliditys-transfer-now/) from Consensys Diligence), mainly because gas costs can change in the future and smart contracts (including multisigs such as Gnosis Safes - [see article](https://help.gnosis-safe.io/en/articles/5249851-why-can-t-i-transfer-eth-from-a-contract-into-a-safe)) even now would not be able to receive the Ether.
There are other ways to protect against reentrancy, which you've already employed - correct usage of CEI pattern and reentrancy locks. Therefore the usage of transfer is not needed to protect from reentrancy AFAIS.
Mitigation: Send Ether using call instead of transfer.
Upgraded Q -> M from 336 [1666364078201]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #336 as Medium risk. The relevant finding follows:

Using transfer() For Sending Ether
Permalinks
https://github.com/code-423n4/2022-07-golom/blob/e5efa8f9d6dda92a90b8b2c4902320acf0c26816/contracts/core/GolomTrader.sol#L154

Description
The transfer() and send() functions forward a fixed amount of 2300 gas. Historically, it has often been recommended to use these functions for value transfers to guard against reentrancy attacks. However, the gas cost of EVM instructions may change significantly during hard forks which may break already deployed contract systems that make fixed assumptions about gas costs. For example. EIP 1884 broke several existing smart contracts due to a cost increase of the SLOAD instruction.
[SWC-134: Message call with hardcoded gas amount](https://swcregistry.io/docs/SWC-134)

Mitigation
Avoid the use of transfer() and send() and do not otherwise specify a fixed amount of gas when performing calls. Use .call.value(...)("") instead.
Upgraded Q -> M from 236 [1666363743332]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #236 as Medium risk. The relevant finding follows:

# ERC721 token can be lost in `fillAsk`

## PROBLEM

When a user fills an ask order by calling `fillAsk`, the `ERC721.transferFrom` method is used to transfer the NFT to the `receiver`. Should the `receiver` be a smart contract that is unable to handle ERC721 tokens, this would result in the NFT being locked forever.


## SEVERITY

Low

## PROOF OF CONCEPT

Instances include:

### GolomTrader.sol

- [ERC721(o.collection).transferFrom(o.signer, receiver, o.tokenId)](https://github.com/code-423n4/2022-07-golom/blob/e5efa8f9d6dda92a90b8b2c4902320acf0c26816/contracts/core/GolomTrader.sol#L236)



## TOOLS USED

Manual Analysis

## MITIGATION

Consider using a `safeTransferFrom` [method](https://github.com/transmissions11/solmate/blob/eaaccf88ac5290299884437e1aee098a96583d54/src/tokens/ERC721.sol#L111-L124). It is a common approach to avoid using this sort of method to avoid reentrancy, but as it is not mentioned in the readme, this issue is still worth raising.
Upgraded Q -> M from 463 [1666363539691]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #463 as Medium risk. The relevant finding follows:

Ignores return value of onERC721Received
The try block should include a check to make sure the function returns its selector as specified by IERC721Receiver. While the function may have the same parameters as the standard, its return value may differ, a signal that the receiving smart contract has not properly implemented IERC721Receiver.

Instances include:
https://github.com/code-423n4/2022-07-golom/blob/main/contracts/vote-escrow/VoteEscrowCore.sol#L604
Upgraded Q -> M from 796 [1666363133014]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #796 as Medium risk. The relevant finding follows:

[L‑01] Use of `transferFrom()` rather than `safeTransferFrom()` for NFTs in will lead to the loss of NFTs
The EIP-721 standard says the following about `transferFrom()`:
```
    /// @notice Transfer ownership of an NFT -- THE CALLER IS RESPONSIBLE
    ///  TO CONFIRM THAT `_to` IS CAPABLE OF RECEIVING NFTS OR ELSE
    ///  THEY MAY BE PERMANENTLY LOST
    /// @dev Throws unless `msg.sender` is the current owner, an authorized
    ///  operator, or the approved address for this NFT. Throws if `_from` is
    ///  not the current owner. Throws if `_to` is the zero address. Throws if
    ///  `_tokenId` is not a valid NFT.
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
```
https://github.com/ethereum/EIPs/blob/78e2c297611f5e92b6a5112819ab71f74041ff25/EIPS/eip-721.md?plain=1#L103-L113
Code must use the `safeTransferFrom()` flavor if it hasn't otherwise verified that the receiving address can handle it

There is 1 instance of this issue:
```
File: contracts/core/GolomTrader.sol

236:              ERC721(o.collection).transferFrom(o.signer, receiver, o.tokenId);
```
https://github.com/code-423n4/2022-07-golom/blob/e5efa8f9d6dda92a90b8b2c4902320acf0c26816/contracts/core/GolomTrader.sol#L236
Upgraded Q -> M from 873 [1666362235337]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #873 as Medium risk. The relevant finding follows:

## Avoid payable(address).transfer
GolomTrader#payEther uses payable(address).transfer to send native ETH. It's considered a best practice to avoid this pattern for ETH transfers, since it forwards a fixed gas stipend that may be insufficient for smart contract recipients, and could potentially revert in the future if gas costs change. (See the Consensys Diligence article [here](https://consensys.net/diligence/blog/2019/09/stop-using-soliditys-transfer-now/)).

[GolomTrader#payEther](https://github.com/code-423n4/2022-07-golom/blob/e5efa8f9d6dda92a90b8b2c4902320acf0c26816/contracts/core/GolomTrader.sol#L151-L156):

    function payEther(uint256 payAmt, address payAddress) internal {
        if (payAmt > 0) {
            // if royalty has to be paid
            payable(payAddress).transfer(payAmt); // royalty transfer to royaltyaddress
        }
    }
Impact: Some orders may be unfillable if payment destination addresses are smart contract wallets.

Suggestion:
Consider using payable(address).call, or OpenZeppelin [Address.sendValue](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/fcf35e5722847f5eadaaee052968a8a54d03622a/contracts/utils/Address.sol#L60). However, note that any use of call() introduces an opportunity for re-entrancy.
Upgraded Q -> M from 437 [1666362126304]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #437 as Medium risk. The relevant finding follows:

Use safetransferfrom() instead of transferfrom() for ERC721.
According to [OpenZeppelin's documentation](https://docs.openzeppelin.com/contracts/4.x/api/token/erc721#IERC721-transferFrom-address-address-uint256-), transferFrom() is discouraged and use safeTransferFrom() instead.
Upgraded Q -> M from 266 [1666361934775]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #266 as Medium risk. The relevant finding follows:

Stop Using Transfer
Use [call instead of transfer](https://github.com/code-423n4/2022-07-golom/blob/7bbb55fca61e6bae29e57133c1e45806cbb17aa4/contracts/core/GolomTrader.sol#L154), [as per](https://consensys.net/diligence/blog/2019/09/stop-using-soliditys-transfer-now/). This does not introduce any issues for re-entrancy as all calling functions are marked non-reentrant.
Upgraded Q -> M from 696 [1666361742731]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #696 as Medium risk. The relevant finding follows:

L05 - Usage of trasfer over call to send Ether could cause unexpected Reverts
https://github.com/code-423n4/2022-07-golom/blob/e5efa8f9d6dda92a90b8b2c4902320acf0c26816/contracts/core/GolomTrader.sol#L154-L155

            payable(payAddress).transfer(payAmt); // royalty transfer to royaltyaddress
The function payEther sends ether via transfer which passes a 2.3k gas stipend to the recipient, this sometimes could not be enough and could cause a Out Of Gas Revert which would prevent users from using the contract.

From my experience transfer is sufficient to send even to a Gnosis Safe, however the contract could break when interacting with other smart contracts
Upgraded Q -> M from 921 [1666361310869]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #921 as Medium risk. The relevant finding follows:

1. Should use call instead of transfer
Line References
[GolomTrader.sol#L154](https://github.com/code-423n4/2022-07-golom/blob/main/contracts/core/GolomTrader.sol#L154)

Impact
The payable(address).transfer function has a limit of 2300 gas ([source](https://consensys.net/diligence/blog/2019/09/stop-using-soliditys-transfer-now/)). If the receiver has a fallback/receive function that requires more gas then the transaction would revert. If this is the case with the signer of the order, the orders of ordertype 0 might not be fillable.

Recommended Mitigation Steps
Consider using the call function instead of transfer to send ETH.
Upgraded Q -> M from 868 [1666360678566]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #868 as Medium risk. The relevant finding follows:

Using .call() instead of .transfer()
Currently it is using .transfer to transfer ETH
```
payable(payAddress).transfer(payAmt);
```
Using deprecated transfer() on address payable may revert in these cases:

1. The withdraw recipient is a smart contract that does not implement a payable function.
2. The withdraw recipient is a smart contract that does implement a payable fallback which uses more than 2300 gas unit.
3. The withdraw recipient is a smart contract that implements a payable fallback function that needs less than 2300 gas units but is called through proxy, raising the call's gas usage above 2300.
Additionally, using higher than 2300 gas might be mandatory for some multisig wallets.

Consider using these

      (bool success, ) = payAddress.call{value: payAmt}("");
      require(success, "ETH transfer failed");
Upgraded Q -> M from 964 [1666360503408]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #964 as Medium risk. The relevant finding follows:

Non-critical: EIP712 signatures on GolomTrader could be replayed in case of blockchain forks
The chainId is burnt into EIP712_DOMAIN_TYPEHASH rather than checked each time.

This means that signatures could be replayed on a forked chain.

See how OpenZeppelin handles this case with _domainSeparatorV4 which is actually being used by the GolomToken.sol via ERC20Votes.
Upgraded Q -> M from 100 [1666359995498]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #100 as Medium risk. The relevant finding follows:

[L-05] address.call{value:x}() should be used instead of payable.transfer():-
File: 2022-07-golom/contracts/core/GolomTrader.sol (line 154):

payable(payAddress).transfer(payAmt);
Upgraded Q -> M from 129 [1666359797557]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #129 as Medium risk. The relevant finding follows:

1.use transfer to pay eth
GolomTrader.sol payEther() use transfer() to pay eth , and receiver can be specified arbitrarily,
it is recommended to use call() to avoid a certain chance of failure due to 2300 gas fee exceeded
https://github.com/code-423n4/2022-07-golom/blob/e5efa8f9d6dda92a90b8b2c4902320acf0c26816/contracts/core/GolomTrader.sol#L154
Used call instead. For example

    (bool success, ) = receiver.call{amount}("");
    require(success, "Transfer failed.");
Upgraded Q -> M from 612 [1666359673078]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #612 as Medium risk. The relevant finding follows:

## [NC-01] Replace assembly chainid with Solidity's chainId()
Description
Retrieving the current chain id via the Yul chainid expression can be replaced with the Solidity native call to chainId().

Findings
[GolomTrader.sol#L98](https://github.com/code-423n4/2022-07-golom/blob/e5efa8f9d6dda92a90b8b2c4902320acf0c26816/contracts/core/GolomTrader.sol#L98)

```
uint256 chainId;
assembly {
    chainId := chainid()
}
```
#### Recommended mitigation steps
Change the constructor code of the GolomTrader contract to the following:
```
constructor(address _governance) {
  // sets governance as owner
  _transferOwnership(_governance);

  EIP712_DOMAIN_TYPEHASH = keccak256(
      abi.encode(
          keccak256('EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)'),
          keccak256(bytes('GOLOM.IO')),
          keccak256(bytes('1')),
          chainId(),
          address(this)
      )
  );
}
```
Upgraded Q -> M from 744 [1666359441654]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #744 as Medium risk. The relevant finding follows:

2. Use safeTransferFrom() to transfer ERC721
https://github.com/code-423n4/2022-07-golom/blob/main/contracts/core/GolomTrader.sol#L236
https://github.com/code-423n4/2022-07-golom/blob/main/contracts/core/GolomTrader.sol#L301
https://github.com/code-423n4/2022-07-golom/blob/main/contracts/core/GolomTrader.sol#L361
For safety and consistency with ERC1155, ERC721 tokens transfered by GolomTrader should use the safeTransferFrom() function.
Upgraded Q -> M from 744 [1666359368684]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #744 as Medium risk. The relevant finding follows:

7. Usage of deprecated transfer() in payEther()
https://github.com/code-423n4/2022-07-golom/blob/main/contracts/core/GolomTrader.sol#L154

The original transfer used to send eth uses a fixed stipend 2300 gas. This was used to prevent reentrancy. However this limit interaction with others contracts that need more than that to process the transaction.

Related: https://consensys.net/diligence/blog/2019/09/stop-using-soliditys-transfer-now/.

In GolomTrader, ether paid to rewards distributor and exchanges will probably be paid to contracts. If one target throw on transfer(), the order will not be processed.
Upgraded Q -> M from 312 [1666358324138]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #312 as Medium risk. The relevant finding follows:

[L-02] Use safeTransferFrom instead of transferFrom for ERC721 transfers
Description
Always best practice to use safeTransferFrom instead of transferFrom to protect users from input mistakes. Avoids a large number of other potential problems and should be the default anytime tokens are transferred to an arbitrary address.

Lines of Code
https://github.com/code-423n4/2022-07-golom/blob/7bbb55fca61e6bae29e57133c1e45806cbb17aa4/contracts/core/GolomTrader.sol#L9
https://github.com/code-423n4/2022-07-golom/blob/7bbb55fca61e6bae29e57133c1e45806cbb17aa4/contracts/core/GolomTrader.sol#L236
https://github.com/code-423n4/2022-07-golom/blob/7bbb55fca61e6bae29e57133c1e45806cbb17aa4/contracts/core/GolomTrader.sol#L301
https://github.com/code-423n4/2022-07-golom/blob/7bbb55fca61e6bae29e57133c1e45806cbb17aa4/contracts/core/GolomTrader.sol#L361
Upgraded Q -> M from 563 [1666357986146]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #563 as Medium risk. The relevant finding follows:

### [L03] Use of transferFrom instead of safeTransferFrom
**Description:**
When using transferFrom if the receiving address is a smart contract that hasn't correctly implemented a way to receive ERC721 tokens then the NFT can be lost.

**LOC:**
[GolomTrader.sol#L236](https://github.com/code-423n4/2022-07-golom/blob/e5efa8f9d6dda92a90b8b2c4902320acf0c26816/contracts/core/GolomTrader.sol#L236)
[GolomTrader.sol#L301](https://github.com/code-423n4/2022-07-golom/blob/e5efa8f9d6dda92a90b8b2c4902320acf0c26816/contracts/core/GolomTrader.sol#L301)
[GolomTrader.sol#L361](https://github.com/code-423n4/2022-07-golom/blob/e5efa8f9d6dda92a90b8b2c4902320acf0c26816/contracts/core/GolomTrader.sol#L361)

**Recommendation:**
Consider using the safeTransferFrom function instead of transferFrom.
Upgraded Q -> M from 563 [1666357879710]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #563 as Medium risk. The relevant finding follows:

### [L02] payEther() can fail if sending to non EOA

**Description:**
As transfer() has a limit of 2,300 gas, when transfering eth to smart contract accounts the transfer can fail. This can be due to either failure to implement a payable fallback function or the function call costs exceed the limit of 2300 gas. 

**LOC:**
[GolomTrader.sol#L151-L156](https://github.com/code-423n4/2022-07-golom/blob/e5efa8f9d6dda92a90b8b2c4902320acf0c26816/contracts/core/GolomTrader.sol#L151-L156)

**Recommendation:**
As payEther is only called from within contracts with reentrancy guard It can be replaced with call().
Upgraded Q -> M from 100 [1666354099039]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #100 as Medium risk. The relevant finding follows:

## [L-05] address.call{value:x}() should be used instead of payable.transfer():-
1. File: 2022-07-golom/contracts/core/GolomTrader.sol (line 154):

`payable(payAddress).transfer(payAmt);`
Upgraded Q -> M from 960 [1666353893155]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #960 as Medium risk. The relevant finding follows:

## [L5] `chainId` constant
In GolomTrader, `EIP712_DOMAIN_TYPEHASH` is calculated during deployment and it's considered immutable. However the parameter `chainId` can change during a hard-fork of the blockchain, leading to replay attacks between the two child chains.

https://github.com/code-423n4/2022-07-golom/blob/main/contracts/core/GolomTrader.sol#L106

### Recommendations
Consider checking `chainId` against a deployment-fixed value, so in case it's different the appropriate `EIP712_DOMAIN_TYPEHASH` can be calculated.
Upgraded Q -> M from 622 [1666353656331]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #622 as Medium risk. The relevant finding follows:

## **6. Fork chain stored**

If there is a hard fork, the `EIP712_DOMAIN_TYPEHASH` is not computed. After initialization, the variable `EIP712_DOMAIN_TYPEHASH` in contract `GolomTrader` is cached in the contract storage and does not change. However, if a hard fork takes place after the contract deployment, the block would cause the domain to become invalid on one of the forked chains. `chainid` is now different.

Affected source code:

- [GolomTrader.sol#L96-L109](https://github.com/code-423n4/2022-07-golom/blob/7bbb55fca61e6bae29e57133c1e45806cbb17aa4/contracts/core/GolomTrader.sol#L96-L109)
Upgraded Q -> M from 622 [1666353412903]
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #622 as Medium risk. The relevant finding follows:

## **5. Ether could be blocked**

The user's ether could be locked and unrecoverable.

Because to transfer ether the `.transfer` method (which is capped at 2300 gas) is used instead of `.call` which is limited to the gas provided by the user. If a contract that has a `fallback` method more expensive than 2300 gas, creates an offer, it will be impossible for this contract cancel the offer or receive funds back to that address.

Reference:

- **transfer** -> The receiving smart contract should have a fallback function defined or else the transfer call will throw an error. There is a gas limit of 2300 gas, which is enough to complete the transfer operation. It is hardcoded to prevent reentrancy attacks.
- **send** -> It works in a similar way as to transfer call and has a gas limit of 2300 gas as well. It returns the status as a boolean.
- **call** -> It is the recommended way of sending ETH to a smart contract. The empty argument triggers the fallback function of the receiving address.

Affected source code:

- [GolomTrader.sol#L154](https://github.com/code-423n4/2022-07-golom/blob/7bbb55fca61e6bae29e57133c1e45806cbb17aa4/contracts/core/GolomTrader.sol#L154)
Split from 907 -> H from 907 [1665663356224] - nCheckpoints - 1 will revert for underflow.
Audit: 2022-07-golom-findings
Severity: MEDIUM

Judge has assessed an item in Issue #907 as High risk. The relevant finding follows:

# Lines of code

https://github.com/code-423n4/2022-07-golom/blob/main/contracts/vote-escrow/VoteEscrowDelegation.sol#L210
https://github.com/code-423n4/2022-07-golom/blob/main/contracts/vote-escrow/VoteEscrowDelegation.sol#L242


# Vulnerability details

## Impact
In VoteEscrowDelegation.sol, function `_transferFrom` will attempt to remove the delegations to the token transferred.
```js
// remove the delegation
this.removeDelegation(_tokenId);
```
<!--
However this external call will change `msg.sender` to `address(this)`, reverting the call when checking the owner
```js
    function removeDelegation(uint256 tokenId) external {
        require(ownerOf(tokenId) == msg.sender, 'VEDelegation: Not allowed');
        uint256 nCheckpoints = numCheckpoints[tokenId];
        Checkpoint storage checkpoint = checkpoints[tokenId][nCheckpoints - 1];
        removeElement(checkpoint.delegatedTokenIds, tokenId);
        _writeCheckpoint(tokenId, nCheckpoints, checkpoint.delegatedTokenIds);
    }
```

Also, even if the call was made internal, another revert is possible: --> 
if the token doesn't have any checkpoints yet, `nCheckpoints - 1` will revert for underflow.

## Proof of Concept
https://github.com/code-423n4/2022-07-golom/blob/main/contracts/vote-escrow/VoteEscrowDelegation.sol#L210
https://github.com/code-423n4/2022-07-golom/blob/main/contracts/vote-escrow/VoteEscrowDelegation.sol#L242

## Recommended Mitigation Steps
<!--
1) Change `removeDelegation` to `public`, and write `removeDelegation(_tokenId)` instead of `this.removeDelegation(_tokenId)`;
2) -->
Add a `if (nCheckpoints == 0) return;` in `removeDelegation` before the possible underflow.