MUMUBIT TOKEN security record

The centralization risk in the TonClaim contract is that the `owner` has the exclusive power to - `SetProjectCoinAddress`/`SetCoinAddress` - `SetPublicKey` - `SetIDOTimes` - Sign any `Claim` requests with their private key - Adjust the `contract_balance` with `AdminCorrectRecord` - `WithdrawFunds` The centralization risk in the MumubitIdo contract is that the `owner` has the exclusive power to - `SetInvestCoinAddress`/`SetProjectCoinAddress` - `SetProjectInfo` - `SetPublicKey` - `SetIDOTimes` - Sign any the VIP level payload or participants with their private key - `WithdrawFunds` If the `owner` account is compromised, a hacker could potentially extract all the jettons. This central point of failure makes the system vulnerable to attacks and fraud.

The `TonClaim` `Claim` handler doesn't check if `now() >= self.claim_time` and `now() < self.end_time`. The `WithdrawFunds` handler doesn't check if `now() >= self.end_time`. The `SetIDOTimes` handler doesn't check if `msg.endTime > msg.claimTime`. The `MumubitIdo` `SetInvestCoinAddress`/`SetProjectCoinAddress` handler doesn't check if `now() < self.start_time`. The `MumubitIdo` `SetIDOTimes` handler doesn't check if `now() < msg.startTime < msg.protectTime < msg.claimTime < msg.endTime`.

```c=155 send(SendParameters{ to: self.this_contract_projectCoinWallet!!, value: ton("0.1"), mode: SendIgnoreErrors, body: TokenTransfer{ query_id: 0, amount: claimAmount, destination: sender, response_destination: myAddress(), custom_payload: null, forward_ton_amount: ton("0.01"), forward_payload: beginCell().storeUint(0, 1).endCell().beginParse() }.toCell() }); ``` `TokenTransfer` message sending can be improved: 1. The message is sent in bounceable mode but the bounced message is not caught. 2. `ton("0.1")` value is attached to the message, however, the contract balance can be not enough. It was only ensured that `context().value >= ton("0.1")`, the gas consumed by the transaction execution, the storage fee, the message forwarding fee, and the event emitting fee were not accounted for. The developer should always [carefully control the gas](https://blog.ton.org/secure-smart-contract-programming-in-func#ton-smart-contract-developer). 3. The message is sent in `SendIgnoreErrors` mode. That means that the message will be silently skipped in case of not enough ton balance - the user will not get the funds and they will be blocked on the contract wallet. The `AdminCorrectRecord` message is required to unblock them. 4. The `response_destination` should be the `sender` since the excess gas has to be returned to the sender, not the contract. 5. Since `forward_payload` is empty anyway, sending `TokenNotification` to the new jettons owner is not required, so `forward_ton_amount` can be set to 0. 6. Using `emptySlice()` as `forward_payload` is not recommended since the reference jetton implementation requires the `forward_payload` to be not empty. 7. The gas is not checked at the `WithdrawFunds` handler. The transaction can be [partially executed](https://blog.ton.org/secure-smart-contract-programming-in-func#partial-execution-of-transactions). 8. If the handler sends more than one message or emits events, the `SendRemainingValue` mode can't be used. The contract balance will be spent in this case.

The `TonClaim` `Claim` handler sends `TokenTransfer` in a bounceable mode, however, there is no handler of bounced messages. Not properly handled bounced messages can lead to an `ido_claim_amount`/`contract_balance` inconsistency.

The `recipientAddr` address gains fee when the `finishAuction` function is called, over time, more and more fee are transferred into this account.

The `withdrawAddress` address gains fee when the `executeTrade` function is called, over time, more and more fees are transferred into this account.

It needs to return tokens to the user if the tokens to be paid are greater than the `trade.price` or require the paid tokens equal to the `trade.price`.