FEY

The constant `SECONDS_IN_DAY` is initialized to `30`, however, there are `86400` seconds in a day. This is used during interest calculations and staking calculations to determine the amount of interest and time that a user has staked. Since this value is set to 30, it will treat half a minute as a full day so that users will accumulate interest much faster than designed and will be able to close their stake with no penalty after only 2 minutes.

Jetton-wallet `status & 1` bit set means the user can not send jettons. However, `cross_chain_transfer()` ignores the status and allows sending even from locked wallet.

The modifier `validateReceiver()` is used to validate the input `_receiverBridge`, which should be the corresponding `FeyorraBridge` deployed on the destination chain. However, the modifier only checks that this is not the zero address. If the input `_receiverBridge` does not correspond to a deployment of the `FeyorraBridge`, it will call `ccipReceive()` on the wrong address and will not provide any `FEY` tokens on the destination chain. Furthermore, if `transferFeyorraRequest()` is called for a custom chain, then the input `_receiverBridge` is only checked to have nonzero length. Similarly to above, this should be the corresponding `FeyorraBridge` deployed on the destination chain.

According to Chainlink's best practices https://docs.chain.link/ccip/best-practices#using-extraargs, they suggest constructing `extraArgs` off chain in order to be compatible with future CCIP upgrades. However, instead of taking an input such as `bytes memory extraargs`, the code takes an input `_gasLimit` and constructs the `extraArgs` via the code: ```solidity extraArgs: Client._argsToBytes( Client.EVMExtraArgsV1({gasLimit: _gasLimit}) ) ``` As such the code may not be compatible with future CCIP upgrades. In particular, this does not allow supporting out of order execution.

```c=99 () check_amount_is_enough_to_cross_chain_transfer(int msg_value) impure inline { int jetton_wallet_gas_consumption = get_precompiled_gas_consumption(); int send_cross_chain_transfer_gas_consumption = null?(jetton_wallet_gas_consumption) ? SEND_CROSS_CHAIN_TRANSFER_GAS_CONSUMPTION : jetton_wallet_gas_consumption; throw_unless(error::not_enough_gas, msg_value > get_forward_fee(MY_WORKCHAIN, CROSS_CHAIN_TRANSFER_NOTIFICATION_BITS, CROSS_CHAIN_TRANSFER_NOTIFICATION_CELLS) + get_compute_fee(MY_WORKCHAIN, send_cross_chain_transfer_gas_consumption) + get_compute_fee(MY_WORKCHAIN, RECEIVE_CROSS_CHAIN_TRANSFER_GAS_CONSUMPTION)); } ``` The code expects `msg_value` for `op::cross_chain_transfer` to be at least 2658000 + 6446000 + 8386000 = 17490000 = 0.01749 toncoins. However, in this case if the message `op::cross_chain_transfer_notification` will be bounced by jetton-minter due to lack of `ext_chain_fees`, the bounced message will not be processed by jetton-wallet and the original balance will be lost. The `total_supply` will be left intact.

Chainlinks CCIP router ensures that a request is not executed multiple times. However, the bridge has functionality to manually bridge which does not ensure the same request is not executed multiple times. While only the owner can call `manualExecuteBridgeTransfer()`, the owner may accidentally execute the same request multiple times resulting in a loss of funds for the protocol. Furthermore, if the CCIP router is given a setter function, then it is possible that the new router may not ensure that a request is not executed multiple times. As added protection the smart contract can also ensure the same request is not executed multiple times when bridging via CCIP as well. While this may cause redundant checks, it can reduce the trust assumptions on the CCIP router.

`op::mint` handler in jetton-minter works this way: 1. `admin_address` sends `op::mint` request with `query_id` equal to `last_executed_mint_query_id + 1` 2. `op::internal_transfer` message is sent to destination jetton wallet 3. `last_executed_mint_query_id` is incremented 4. In case the `op::internal_transfer` is bounced, the `last_executed_mint_query_id` is decremented back However, that opens the risk for race condition. The previous messages can be bounced when the new messages are already processed.

The `requestId` for a custom chain is generated by calling `generateRandomBytes32()`, which is determined using the `nonce`, `msg.sender`, `block.timestamp`, and `address(this)`. If two bridge contracts on different chains are deployed to the same address, then it is possible for the same `requestId` to be generated on two different chains. This may cause issues in the bridging process.

The `FeyorraBridge` utilizes Chainlink's CCIP for the transfer of `data` in order to execute the bridging of their `FEY` tokens. However, it does not utilize the built in functionality to bridge tokens that follow the CCT standard. In particular, it does not include rate limits, so that if the bridge is compromised the amount of tokens that can be lost is the entire balance of the bridge. Similarly, if bridging to a custom chain that is not supported by Chainlink's CCIP, there are no limits on the amount of tokens that can be transfered, so that if the owner is compromised the amount of tokens that can be lost is the entire balance of the bridge.

Allowlisted senders are not mapped with their corresponding source chain. This can cause issues if a sender is only intended to be allowlisted on certain chains and not on others.