Elchai security record

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Addresses should be checked before assignment or external call to make sure they are not zero addresses. ```solidity=285 lpPair = newPair; ``` - `newPair` is not zero-checked before being used. --- ```solidity=322 marketingAddress = payable(marketing); ``` - `marketing` is not zero-checked before being used. --- ```solidity=323 marketingAddress2 = payable(marketing2); ``` - `marketing2` is not zero-checked before being used.

Contract `BEC` is vulnerable to [a known ERC20 race condition issue](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729), which could lead to token theft. When a user calls `approve()` for a second time on a spender that has already been allowed, the spender could call `transferFrom()` to transfer the previous value and still receive the authorization to transfer the new value. Exploit scenario: 1. Alice calls `approve(Bob, 100)` to allow Bob to spend 100 tokens. 2. Alice changes her mind and calls `approve(Bob, 50)`. 3. Bob observes the second `approve(Bob, 50)` function call and calls `transferFrom(Alice, Bob, 100)` before the second `approve(Bob, 50)` call. 4. The above scenario can be achieved by front-running. In this case, Bob can transfer another 50 tokens from Alice and in total, he transferred 150 tokens from Alice.

The `transferOwnership` method in the `Ownable` contract is implemented using a typical "Push" pattern, which can result in the loss of contract ownership if an invalid owner address is supplied.

```solidity (success,) = marketingAddress.call{value: mark1, gas: 35000}(""); (success,) = marketingAddress2.call{value: mark2, gas: 35000}(""); ``` The variable `success`, which means if the function call succeeds, is not checked.