NFTCall security record

The contract, `Premium` serves as the underlying entity to interact with the pricing of premiums on call options. However, the scope of the audit assumes the input `_premiumMesh` is functionally correct and treats it as a black box.

In the contract `NToken`, the functions `_beforeTokenTransfer()` and `supportsInterface()` override their respective functions from the `ERC721` contract. However, when overriding, they only call super on that function, which will simply call the function from the ERC721 contract.

In the batch functions that mint or transfer ERC721 tokens, the `onERC721Received()` hook can be used for reentrancy.

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker manipulates the following contract by re-entering, they could potentially throw off any protocol listening for these events. Additionally, `exerciseCall()` does not conform to check effect interaction patterns by burning before all state changes have been completed. ### `withdrawETH()` can send ETH to an external contract which can trigger a re-entry on fallback which can cause events to be out of order: ```solidity=191 _safeTransferETH(to, amount); emit WithdrawETH(_msgSender(), to, amount); emit BalanceChangedETH(user, _balanceOf[user]); ``` ### `withdraw()` and `exerciseCall()` externally calls `Ntoken.burn()` which can cause events to be out of order: ```solidity=45 function burn(address user, address receiverOfUnderlying, uint256 tokenId) public override onlyOwner{ _burn(tokenId); IERC721(nft).safeTransferFrom(address(this), receiverOfUnderlying, tokenId); emit Burn(user, receiverOfUnderlying, tokenId); } ``` ### `deposit()` and `depositWithPreference()` externally calls `Ntoken.mint()` which can cause events to be out of order: ```solidity=40 function mint(address user, uint256 tokenId) public override onlyOwner{ _safeMint(user, tokenId); emit Mint(user, tokenId); } ```

The contract is serving as the underlying entity to interact with third-party `Oracles` and `NFT's` The scope of the audit treats third-party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets.

In the contract, `CallPool` and `Errors`, the following typos were found: - `CP_NFT_ON_MARKET_OR_UNABAILABLE` should be corrected to `CP_NFT_ON_MARKET_OR_UNAVAILABLE`; - `CP_DID_NOT_SEND_ENOUGHT_ETH` should be corrected to `CP_DID_NOT_SEND_ENOUGH_ETH`. In the contract, `DataTypes`, the following typo was found: - bit 128-192: minimumStrikePrice should be corrected to bit 128-191: minimumStrikePrice. In the contract, `CallPool`, the following typos were found: - In the comments above `STRIKE_PRICE_SCALE`, it should use "greater" as opposed to "great"; - In the function `withdraw()`, the comment `// Burn NToken` should be moved to just before the `NToken` is burned; - In the function `exerciseCall()`, the comment `// Burn NToken and transfer underlying NFT` should be moved to just before the `NToken` is burned.

```solidity=7 event Activate(address account); ``` - `Activate` is declared in `ICallPoolEvents` but never emitted. --- ```solidity=8 event Deactivate(address account); ``` - `Deactivate` is declared in `ICallPoolEvents` but never emitted. --- ```solidity=18 event DepositETH(address indexed user, address indexed receiver, uint256 amount); ``` - `DepositETH` is declared in `ICallPoolEvents` but never emitted.

```solidity=9 interface IPriceOracleGetter { ``` - `IPriceOracleGetter` is declared but never used.

The `STRIKE_PRICE_SCALE` and `MAXIMUM_STRIKE_PRICE` are determine based on the decimals of the price returned by the oracle and the decimals of the strike price. The implementation assumes that the decimals of the price returned by the oracle is 18 and the decimals of the strike price is 9. In addition, the `MAXIMUM_STRIKE_PRICE` is the maximum `uint64` multiplied by the `STRIKE_PRICE_SCALE`.