Shentu - Restaking

Repository: - toolkit-restaking-service File: - toolkit-restaking-service/service/cosmos/query.go The `FilterCoinReceivedAmounts` function in the restaking service assesses whether the expected funds were received based on the transaction's content. Specifically, it checks for transactions of the type `coin_received`, and validates the recipient and amount. However, it does not verify the type of token, which can lead to inaccuracies in the final amount calculation. ```go =232 for _, event := range txResp.TxResponse.Events { if event.Type == "coin_received" { var receiver, amount string for _, attribute := range event.Attributes { if attribute.Key == "receiver" { receiver = attribute.Value } if attribute.Key == "amount" { amount = attribute.Value } } if receiver == targetReceiver { amounts = append(amounts, amount) } } } ``` The current verification method is inadequate. Transactions may involve multiple types of coins, resulting in inconsistencies in the coin types that trigger the `coin_received` event. By not validating the coin types and treating all coin transfers as the default coin, the code risks errors in the final amount calculation. Such errors could potentially cause financial losses to users or the project team.

Repository: - toolkit-restaking-service File: - toolkit-restaking-service/service/cosmos/query.go When verifying the final amount of assets received by the restaking service, `int64` is used as the data type for the result. However, this data type may cause overflow issues, especially when the asset has a large number of decimals. For example, the commonly used 18 decimals can easily lead to overflow. ```go =249 for _, amount := range amounts { splits := strings.Split(amount, cc.Denom) value, _ := strconv.ParseInt(splits[0], 10, 64) totalAmount += value } ``` When the coin's decimal is set to 18, the likelihood of an overflow increases significantly. An overflow can lead to service outages or asset losses.

Repository: - toolkit-restaking-service File: - toolkit-restaking-service/service/cosmos/staking.go The `SimulateStaking` function contains redundant code. Instead of iterating through `totalDays` one by one, calculations can be performed in units of `claimCycle`. ```go func SimulateStaking(initialStake, annualYieldRate, ClaimFee float64, claimCycle int, totalDays int) float64 { stake := initialStake dailyYield := calculateDailyYield(stake, annualYieldRate) // Loop through each day for day := 1; day <= totalDays; day++ { // Claim rewards and restake every claimCycle days if day%claimCycle == 0 { stake += dailyYield * float64(claimCycle) stake -= ClaimFee dailyYield = calculateDailyYield(stake, annualYieldRate) } } return stake } ```

Repository: - toolkit-restaking-service File: - service/restake/restake.go In the `StartRestake` function, while retrieving and processing grants for restaking, there is no validation for the expiration of each grant authorization. The current logic assumes all retrieved grants are valid, even if they have expired. This could lead to failed restaking operations due to the use of invalid or expired grants, impacting the overall reliability of the restaking service.

Repository: - toolkit-restaking-service File: - toolkit-restaking-service/service/restake/restake.go In the `hasSufficientReward` function, the `totalDelegation` variable is defined but not utilized. ```go =321 func (rs *RestakeService) hasSufficientReward(cc *cosmos.ChainConfig, granter string, delegations stakingtypes.DelegationResponses) bool { totalDelegation := sdk.NewCoins() for _, delegation := range delegations { totalDelegation = totalDelegation.Add(delegation.Balance) } distribution, err := cc.QueryDistribution(granter) if err != nil { return false } for _, reward := range distribution.Total { if reward.Denom == cc.Denom && reward.Amount.GT(sdk.NewDec(1e6)) { return true } } return false } ```