FEY

`closeGhostStake()` is intended to be able to close the users stake that corresponds to the input `_stakingId` after all seconds of the users last day have passed. However, it does this by calling `closeStake(_stakingId)`, which makes the following check: ```solidity require( _stakeElement.userAddress == msg.sender, 'FEYToken: wrong stake owner' ); ``` `closeGhostStake()` can only be called if the `msg.sender` is the owner and `closeStake()` can only be called if the `_stakeElement.userAddress == msg.sender`, so that `closeGhostStake()` can only be called on the owners stakes and cannot be used to close other users stakes.

In the contract `jetton-minter` the role `admin_address` has authority over the functions - op::mint - op::change_admin - op::call_to - op::change_metadata - op::update_fees - op::withdraw_ton - op::upgrade Any compromise to the `admin_address` account may allow the hacker to take advantage of this authority and - extract all the fees, change the fees - change the contract code to extract all the funds - change the jetton metadata - mint any amount of jettons for any wallet - send any message to any jetton-wallet, including jettons extraction, burning, freezing/unfreezing

In the Feyorra contract `FEYToken`, the the role `_owner` has authority over the function `closeGhostStake()`. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and stakes that have fully matured for users. --- In the BEP-20 contract `FEYToken`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and mint any amount of tokens for themselves, or burn their tokens.  --- In the contract `Ownable`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and transfer the contract ownership or renounce ownership rights. 

All of the `FEY` tokens are sent to the contract deployer. This is a centralization risk because the deployer can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

In the contract `FeyorraBridge`, the role `_owner` has authority over the following functions: - `updateCustomChain()` - `allowlistDestinationChain()` - `allowlistSourceChain()` - `allowlistSender()` - `withdrawToken()` - `withdrawNative()` Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and do the following: - Add a malicious destination chain, source chain, or sender to the allowlists in order to steal funds from the bridge. - Call `withdrawToken()` to steal all `FEY` tokens from the bridge. - Call `withdrawNative()` to take any native tokens held by the bridge for themselves. --- In the contract `Pausable`, the role `_owner` has authority over the functions `pause()` and `unpause()`. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and pause the bridge to cause a denial of service. --- In the contract `Ownable`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and transfer the contract ownership or renounce ownership rights. 

In the contract `FeyorraBridge`, the role `_owner` has authority over the following functions: - `manualExecuteBridgeTransfer()` Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and do the following: - Update a chain to be a custom chain so that they can steal funds via `manualExecuteBridgeTransfer()`. - Call `manualExecuteBridgeTransfer()` when no request to bridge funds on another chain was made, allowing them to steal funds. In addition, as only the owner can call `manualExecuteBridgeTransfer()`, it is up to the owner to validate that the request to bridge funds is legitimate and should be executed.

The balance of `msg.sender` is subtracted by `totalSent` and is not decreased after each individual transfer. This amount is obtained by incrementing `_values[i]`, which may overflow allowing the `msg.sender` balance to be decreased by a smaller amount than the total amount of tokens transferred. Note that `_transferCheck()` is always applied to the `msg.sender` balance at the start of the call as it is not updated until after the for loop. Note that in order for `totalSent` to overflow, a user must hold a large enough amount of tokens so that it is possible to transfer their entire balance of tokens enough times so that the total amount being transferred exceeds `2^256 - 1` and is within the block gas limit. With the initial total supply of `1000000000E18` this would require `115792089237316195423570985008687907853269984665641` individual transfers which would well exceed the block gas limit. However, the block gas limit and the total supply may increase, so that in the future this may be possible. Considering this is highly unlikely, but has a critical impact if the right conditions are ever met, we give this a *medium* severity. Furthermore, this allows for a user to transfer tokens to themselves, when they would not have enough tokens. For example assume a user has 2000, tokens, they can call `multiTransfer()` to transfer 2000 tokens to another address and then 1000 tokens to themselves. Since the transfered amount is added before the total amount is subtracted, this will succeed although when transferring 1000 tokens to themselves the users balance should technically be 0.