Chainport2023

Code at the pointed lines searches on the persistent storage for transaction with the given `data_passed` on the provided `network_id`. Then, if such transaction is found the `mint_bridge_tokens` returns with no-operations. The data passed in the `data_passed` parameter includes the transaction signature computed in line 94. The signature algorithm of Ethereum accounts is ECDSA which is based on random one-time-use numbers for signature generation. This means that distinct signatures of the same data by the same account are different. So, querying a transaction by including the signature as a parameter is always going to fail since each transaction, even if containing the same data, will produce different signatures. As a result, the logic to exit the `mint_bridge_tokens` function if `prev_tx_obj` is found is not able to detect already created transactions.

The `cardano_one_time_minter` function mints Cardano tokens and tracks them by saving the new token information on the database. However, no data about the on-chain transaction that caused such mint is contextually stored with the minting operation. As a result, if the `cardano_one_time_minter` handler is called twice (e.g. because of bugs in the calling logic, misconfiguration of cloud resources, ...) in reference to the same on-chain event, then two distinct mint actions are executed, and proportion between locked tokens and minted ones is altered.

Variable with string (`asset_name`) and (`token_name`) is salted with postfix and truncated to first 32 bytes without checking it's length. This may result in collision attack or bugs of wrong parameters in the case of 0 length strings or names which differ only for characters after the 31st.

The function `cardano_one_time_minter()` calls the function `mint_one_time_token()` on the Cardano object in order to mint a new token. Subsequently, code at the pointed locations, updates the off-chain persistent storage. However, such storage updates may fail (e.g. for a database connection issue), trigger an Exception and leave the off-chain logic in an outdated state in respect to what happened on-chain. Considering the the off-chain logic drives the bridge business logic, this condition must be avoided.

The function `burn_utxo()` from `cardano.py` performs three operations on a `try` statement. If any of those operations fail to throw an error, the `except` block will execute. Two of those operations are network related and are prone to fail due to connection errors. But, an issue might arise if one operation was performed successfully and the other one is not (for example, if the slack bot is down). The transaction submission was successful but the slack message threw an exception, the function will return `None` as the transaction hash, losing the correct hash that corresponds to the transaction. A similar issue occurs on the functions `release_tokens()`, `mint_one_time_token()` and `mint_token()` from the same file.

The code at the pointed lines submits a transaction to the network and saves such information on the persistent storage. However, if the transaction submission fails for any reason, there is no error handling to either recover from the failure or investigate the reason of the failure. Moreover, if the error on the transaction submission happens while decoding the answer from the service through which the transaction was submitted, the system could be exposed to a replay of the minting transaction in reference to the same deposit. In fact, if the transaction gets included in the chain but the code fails before saving such information, then the system is in the state in which a new minting operation is issued, which causes a loss of funds.

The functions `session_get_pending_cardano_burn_transactions()`, `session_get_pending_cardano_deposit_transactions()` and `session_get_pending_cardano_mint_transactions()` from `cardano_transaction.py` are almost identical. The shared functionality could be extracted into a separate function from which the linked functions could use with their needed `transaction_type`.

The linked statements are meant to configure the environment on which the script will run. On the platform chosen by the client to deploy the scripts (AWS), the configuration is done outside the code, either via the console or via another script (like terraform). Moreover, lambdas should get their environment variables and context from the `context` parameter. Additionally, the linked whitelists could be defined externally. The reason is that if a change needs to be made into one, there is no need to redeploy the lambdas.

In the function `session_get_latest_cardano_event_counter_by_name` the function returns `1` if a `CardanoBridgeEvent` is not matching with any `name` and `res.counter + 1` if the `name` matches an existing `CardanoBrdigeEvent`. Starting the counter from `0` can avoid the necessity of adding `1` to `res.counter` when the condition is met.

In the function `get_or_create_cardano_deposit_transaction_and_bridge_event` the `deposit_transaction_obj.id` is assigned to two different variables, respectively `bridge_event_obj.deposit_tx` and `bridge_event_obj.burn_tx`, that are stored in DB resulting in a duplicated field.