mumubit

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.