fix(payment): bound settle timestamp on the underflow side too

The previous commit guarded only the high side of the settle-timestamp
arithmetic. Int.Int64() panics on either bound, and UpdateStreamRecord has a
route to a hugely negative value: when payDuration <= ForcedSettleTime the code
calls ForceSettle and then falls through to compute the settle timestamp from
the same (stale, negative) payDuration. A deeply indebted account whose netflow
rate collapses while its balance is negative makes that value underflow int64,
and the else-branch Int64() panics. The route is reachable only when forced
(a non-forced update returns early once payDuration drops below
ForcedSettleTime), i.e. inside the no-recover EndBlocker -> chain halt.

Replace the high-only check with a 3-way bound: reject a user deposit on
overflow (unchanged), saturate to MaxInt64 on any other overflow, and saturate
to MinInt64 on underflow (never a deposit; the account is already force-settled,
so "overdue" is the correct hint). TryResumeStreamRecord is unaffected: after
its resume-floor check the pay duration is provably positive.

Relates to MOCA-385

Author: puneet2019

CHANGELOG.md

@@ -66,7 +66,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
 - (app/upgrades) [#289](https://github.com/mocachain/moca/pull/289) Pin v2 feemarket `min_gas_price` to 20 gwei (moca's intended floor) so upgraded chains match genesis.
 - (evm) [#290](https://github.com/mocachain/moca/pull/290) Restore `CallEVM` error-context wrap (method + contract in error message), fix copy-pasted "evil token" comment in `erc721NonTransferable.go`, update stale geth v1.15→v1.16 comments, remove unreachable `AddBalance` blocks in distribution precompile, fix grammar in precompile Run() default cases, and drop dead test-helper expressions.
 - (evm) [#291](https://github.com/mocachain/moca/pull/291) Reject native value sent to precompiles to prevent a balance-reconciliation mint.
-- (x/payment) [MOCA-385] Prevent Int64 overflow panic in `UpdateStreamRecord` and `TryResumeStreamRecord`: settle-timestamp arithmetic is now performed in arbitrary-precision `sdkmath.Int` instead of native `int64`. Only a user-initiated deposit that would push the pay duration past `MaxInt64` is rejected (`ErrSettleTimestampOverflow`) — the depositor can simply deposit less. Every other path (rate decreases from object deletion/discontinue, lazy re-pricing when the SP price falls, and all forced EndBlocker updates) saturates the settle timestamp to `MaxInt64` instead, since it is only a scheduling hint that is recomputed on the next balance change or bucket touch. This keeps a legitimate object deletion from ever being rejected and prevents the EndBlocker from panicking (which would halt the chain).
+- (x/payment) [MOCA-385] Prevent Int64 overflow panic in `UpdateStreamRecord` and `TryResumeStreamRecord`: settle-timestamp arithmetic is now performed in arbitrary-precision `sdkmath.Int` instead of native `int64`, and the result is bounded to the int64 range in both directions before being stored. Only a user-initiated deposit that would push the pay duration past `MaxInt64` is rejected (`ErrSettleTimestampOverflow`) — the depositor can simply deposit less. Every other out-of-range result saturates (to `MaxInt64` on overflow — rate decreases from object deletion/discontinue, lazy re-pricing when the SP price falls, and forced EndBlocker updates; to `MinInt64` on the underflow that a deeply-indebted account can hit in a forced update), since the settle timestamp is only a scheduling hint that is recomputed on the next balance change or bucket touch. This keeps a legitimate object deletion from ever being rejected and prevents the EndBlocker from panicking (which would halt the chain).
 - (x/challenge) [#286](https://github.com/mocachain/moca/pull/286) Retire a challenge from the active set once it is attested, making attestation idempotent so duplicate submissions (e.g. redundant relayers or resubmissions by the in-turn submitter) are rejected instead of re-running heartbeat rewards and re-emitting attestation events.
 - (ci) [#65](https://github.com/mocachain/moca/pull/65) Resolve goreleaser CI failures for arm64 docker builds
 - (audit) [#63](https://github.com/mocachain/moca/pull/63) Apply audit fixes

x/payment/keeper/stream_record.go

@@ -215,38 +215,49 @@ func (k Keeper) UpdateStreamRecord(ctx sdk.Context, streamRecord *types.StreamRe
 				return fmt.Errorf("check and force settle failed, err: %w", err)
 			}
 		}
+		// The settle timestamp is stored as int64; the full expression
+		// (currentTimestamp - forcedSettleTime + payDuration) can land outside the
+		// int64 range in either direction. Calling Int64() on an out-of-range value
+		// panics ("Int64() out of bound"); inside the no-recover EndBlocker that
+		// halts the chain. Saturate instead — the settle timestamp is only a
+		// scheduling hint for the auto-settle queue and is recomputed on the next
+		// balance change or bucket touch, so capping it is loss-free.
 		settleTimestampFull := sdkmath.NewInt(currentTimestamp).
 			Sub(sdkmath.NewIntFromUint64(params.ForcedSettleTime)).
 			Add(payDuration)
-		if settleTimestampFull.GT(sdkmath.NewInt(math.MaxInt64)) {
-			// The settle timestamp is stored as int64; a pay duration beyond
-			// MaxInt64 seconds (~2.9e11 years) cannot be represented.
+		switch {
+		case settleTimestampFull.GT(sdkmath.NewInt(math.MaxInt64)):
+			// Over-funded: pay duration beyond MaxInt64 seconds (~2.9e11 years),
+			// from a huge balance or a collapsed netflow rate.
 			//
 			// Reject only a user-initiated deposit — a positive static-balance
 			// change with no rate change. That depositor is over-funding past what
-			// we can represent and can simply deposit less. Every other path must
-			// NOT error here:
-			//   - forced EndBlocker updates: returning an error would panic the
-			//     chain in abci.go ("should not happen");
-			//   - rate decreases from object deletion/discontinue, and lazy
-			//     re-pricing when the SP price falls: rejecting a legitimate
-			//     delete/re-price would be wrong.
-			// Those saturate the settle timestamp to MaxInt64. It is only a
-			// scheduling hint for the auto-settle queue and is recomputed on the
-			// next balance change or bucket touch, so capping it is loss-free.
+			// we can represent and can simply deposit less. Forced EndBlocker
+			// updates (an error would panic the chain in abci.go "should not
+			// happen") and legitimate rate decreases (object deletion/discontinue,
+			// lazy SP re-pricing) must not error, so they saturate to MaxInt64.
 			isUserDeposit := !forced && change.StaticBalanceChange.IsPositive() && change.RateChange.IsZero()
 			if isUserDeposit {
 				return types.ErrSettleTimestampOverflow.Wrapf(
 					"account %s pay duration %s exceeds int64 range; reduce deposit",
 					streamRecord.Account, payDuration.String())
 			}
 			ctx.Logger().Error("settle timestamp overflow, capping at MaxInt64",
-				"account", streamRecord.Account,
-				"payDuration", payDuration.String(),
-				"forced", forced,
-				"height", ctx.BlockHeight())
+				"account", streamRecord.Account, "payDuration", payDuration.String(),
+				"forced", forced, "height", ctx.BlockHeight())
 			settleTimestamp = math.MaxInt64
-		} else {
+		case settleTimestampFull.LT(sdkmath.NewInt(math.MinInt64)):
+			// Deeply indebted: a large netflow rate collapsed to a tiny one while
+			// the balance was negative makes payDuration hugely negative. Only
+			// reachable in a forced update (a non-forced one returns above once
+			// payDuration is below ForcedSettleTime). Never a deposit, so always
+			// saturate — to MinInt64, so the auto-settle queue treats it as overdue
+			// (the account is already force-settled above).
+			ctx.Logger().Error("settle timestamp underflow, capping at MinInt64",
+				"account", streamRecord.Account, "payDuration", payDuration.String(),
+				"forced", forced, "height", ctx.BlockHeight())
+			settleTimestamp = math.MinInt64
+		default:
 			settleTimestamp = settleTimestampFull.Int64()
 		}
 	}

x/payment/keeper/stream_record_test.go

@@ -865,6 +865,49 @@ func TestUpdateStreamRecord_SettleTimestampOverflow_ForcedSaturates(t *testing.T
 		"forced overflow must saturate to MaxInt64, not panic")
 }
 
+// TestUpdateStreamRecord_SettleTimestampUnderflow_ForcedSaturates covers the low
+// side: a forced update on a deeply indebted active account (a large rate that
+// collapsed to a tiny one while the balance was negative) makes payDuration
+// hugely negative, so currentTimestamp - forcedSettleTime + payDuration underflows
+// int64. Int64() would panic inside the EndBlocker and halt the chain; instead the
+// settle timestamp must saturate to MinInt64. This is reachable only when forced —
+// a non-forced update returns early once payDuration drops below ForcedSettleTime.
+func TestUpdateStreamRecord_SettleTimestampUnderflow_ForcedSaturates(t *testing.T) {
+	k, ctx, dep := makePaymentKeeper(t)
+	ctx = ctx.WithBlockTime(time.Unix(1_000_000_000, 0))
+	ctx = ctx.WithValue(types.ForceUpdateStreamRecordKey, true)
+
+	// No bank account, so the negative-balance auto-transfer (for the user and for
+	// the governance account inside ForceSettle) is skipped.
+	dep.AccountKeeper.EXPECT().HasAccount(gomock.Any(), gomock.Any()).Return(false).AnyTimes()
+
+	params := k.GetParams(ctx)
+	// Buffer matches |rate|=1 so the buffer recompute does not adjust staticBalance.
+	bufferBalance := sdkmath.NewIntFromUint64(params.VersionedParams.ReserveTime)
+	// staticBalance far below MinInt64 → payDuration (÷1) underflows int64.
+	staticBalance := sdkmath.NewInt(math.MinInt64).MulRaw(2)
+
+	user := sample.RandAccAddress()
+	sr := &types.StreamRecord{
+		Account:           user.String(),
+		Status:            types.STREAM_ACCOUNT_STATUS_ACTIVE,
+		StaticBalance:     staticBalance,
+		BufferBalance:     bufferBalance,
+		LockBalance:       sdkmath.ZeroInt(),
+		NetflowRate:       sdkmath.NewInt(-1),
+		FrozenNetflowRate: sdkmath.ZeroInt(),
+		CrudTimestamp:     ctx.BlockTime().Unix(),
+	}
+
+	change := types.NewDefaultStreamRecordChangeWithAddr(user)
+	require.NotPanics(t, func() {
+		err := k.UpdateStreamRecord(ctx, sr, change)
+		require.NoError(t, err, "forced path must not return an error (would panic EndBlocker)")
+	})
+	require.Equal(t, int64(math.MinInt64), sr.SettleTimestamp,
+		"forced underflow must saturate to MinInt64, not panic")
+}
+
 // TestUpdateStreamRecord_SettleTimestampOverflow_UserDepositRejected covers the
 // user-initiated deposit path: a positive static-balance change with no rate
 // change that pushes payDuration past MaxInt64 is rejected with