Ternoa security record

The `transmit_nft()` function returns a `DispatchResult`, which is used to indicate success or failure. In the hook `on_initialize()`, the return value of `transmit_nft()` function is ignored. In other words, even if there is an error in `transmit_nft()`, the iteration on the `on_initialize` function will continue and the state of the system will be inconsistent. The error in `transmit_nft` could come from two sides: - If the `nft_id` is not available in the Transmission storage of the `transmission` pallet. - If the `nft_id` is not available in the NFT storage of the `nft` pallet. The latter is difficult to determine because it depends on all the mechanisms manipulating the NFT state, where the majority is outside the scope of this audit.

There is an issue in the `on_initialize` function, where the number of initial storage reads is inaccurately declared. The `read` variable is initialized with a value of 1, but in reality, two storage reads are being executed. This discrepancy can lead to potential problems, as the weight calculation may not be accurate, possibly affecting the performance and stability of the system.

The `Queue` struct used for `AtBlockQueue` transmission pallet storage implements the `pop_next` method to get the next element on the queue (only if the block number is lower or equal to now). After getting the element, this is deleted from the queue and returned to the method caller. To remove the element the function uses the `remove` method that using the `token_id` can search the queue and find the index where the element is, so it can be deleted. However, the index is already known in the `pop_next` function (index 0), so all the logic in the `remove` function is unnecessary. Considering this function is called on each iteration of a main loop in the pallet hook (called on each block), the current implementation add substantial inefficiency to the system.

The extinct `set_transmission_protocol()` receives an NFT ID, a recipient, a transmission protocol, and a cancellation period. This transmission protocol can be canceled according to the cancellation period. There are three options for this: - Never accept cancellations - Always accept cancellations - Accept cancelations only until a specific block (this option receives a block number) However, there is no validation of the block number passed in the `CancellationPeriod::UntilBlock(BlockNumber)`. A user or the UI could commit a mistake and send a block number in the past which will disable the possibility to cancel it.

In the function `register_enclave()`, there is no check on `apiUri` validity. The user can register an enclave with e.g., an empty apiUri.

The indicated expression creates a reference which is immediately dereferenced by the compiler.

The indicated locations show the usage of the `clone()` method when the cloned value is not consumed or mutated.

In the indicated locations there is a redundant usage of pattern matching.

The functions `remove_registration` and `remove_update` are responsible for removing an enclave registration and an enclave update request from the storage, respectively. Although, it is observed that these functions do not return an error or fail even if the operator does not exist. Specifically, the functions utilizes `try_mutate` to modify the storage value associated with the `operator_address`. If an update or registration exists for the given operator, it sets the value to None. In cases where the operator does not exist or has no associated value, the function still proceeds without error, simply not modifying the storage. Therefore, the call will not return an error and it will be silently omitted if the extrinsic is used to delete, by mistake, an operator that doesn't exists.

The `remove_transmission_protocol` extrinsic is used to remove the transmission protocol of an NFT. It manages the four different types of transmission protocols. However, on some of the protocols, it can have an inefficient performance because it tries to remove data from certain storage that do not contain the NFT. The first case happens with the transmission protocol `OnConsent`. It requires the approval of N accounts but doesn't require activation on a specific block, then it's not stored in the `AtBlockQueue` but the `remove_transmission_protocol` extrinsic will try to remove it anyway, leading to extra unnecessary storage read that could be avoided. The second case happens with the transmission protocols `AtBlock` and `AtBlockWithReset`. They don't require approvals, then they are not stored in the storage `OnConsentData` but the `remove_transmission_protocol` extrinsic will try to remove them anyways, leading to extra unnecessary storage read that could be avoided.