chore(deps): bump cosmos-sdk to v0.53.8, ship it as an empty v4.4 upgrade

[RafilxTenfen]

Summary

Bumps cosmos-sdk v0.53.5 → v0.53.8 and cometbft v0.38.22 → v0.38.23, and restructures the pending upgrades so the bump can ship on its own schedule:

• v4.4 becomes an empty upgrade whose only job is to coordinate the binary swap.
• The costaking ActiveBaby recalculation that previously sat in v4.4 moves verbatim to v4.5, which is staged in the tree but deliberately not registered in Upgrades. Registering it is follow-up work, so this binary advertises only the v4.4 plan.

Because x/upgrade halts at a plan height with no registered handler, TestUpgradeV45 is skipped until that follow-up lands. The v4.5 unit test still exercises ResetCoStakerRwdsTrackerActiveBaby directly.

Why this needs a coordinated upgrade

v0.53.8 is state breaking, so it cannot be rolled out node by node. Several changes make an old and a new binary produce different results for the same block:

Change	Divergence
#26408 x/staking getBeginInfo inverted error	a redelegation that used to fail now succeeds; reachable in two ordinary user txs
#26527 / #26571 GetSigningTxData nil guards	a tx that previously died as ErrPanic now executes and mutates state
#26406 x/distribution withdraw refactor	gas accounting changed on the reward-withdraw path, and the FeePool write is now elided on zero remainder
#26518 strict historical-rewards reads	a silent zero becomes a hard error; reachable via SDK hook paths and via CosmWasm contract queries during block execution
#26515 multisig index bounds	multisig depth > 2 or > 32 signatures now rejected with ErrTooManySignatures
x/gov EndBlocker	an undecodable proposal no longer abandons the rest of the queue

Babylon also runs the full ante handler inside ProcessProposal (x/checkpointing/prepare/proposal.go:491), so a mixed-version network would not merely diverge on results, validators would reject each other's proposals.

Two upstream changes that look consequential are not consensus relevant here: the secp256k1 SEC1 tag validation lives only in UnmarshalAmino/UnmarshalJSON, not the consensus proto path, and malformed-SignerInfos txs are rejected at CheckTx so they never reach a block.

Why no migration

No SDK module changed its ConsensusVersion between v0.53.4 (the version both bbn-1 and bbn-test-6 run today) and v0.53.8, so the v4.4 handler is RunMigrations and nothing else, with no store keys added or deleted. The SDK changes are unconditional binary behaviour; the handler exists purely to fix the switch height.

The bump requires no Babylon source changes.

Testing

• go build and go vet under the mainnet, testnet and e2e build tags, and with cgo ledger test_ledger_mock (the ledger-cosmos-go v0.16.0 → v1.0.0 major bump does not reach Babylon)
• make test-unit
• make test-e2ev2: TestUpgradeV44, TestIBCTransfer, TestWasmIBCHandler (TestUpgradeV45 skipped, see above)

TestUpgradeV44 boots the released v4.2.5-testnet image, which runs cosmos-sdk v0.53.4 -- the same SDK both bbn-1 and bbn-test-6 run today, each on babylond v4.3.1. It passes a gov software-upgrade proposal, halts, and restarts on the locally built binary carrying v0.53.8, so the swap exercises the exact SDK delta production will cross.

It additionally asserts that pre-upgrade delegation and balance state is untouched across the swap, and that bank sends and epoched delegations still execute on the new binary.

Follow-ups not in this PR

• Register v4.5 in Upgrades and drop the TestUpgradeV45 skip.
• Nothing covers the redelegation-from-removed-validator flip, the distribution strict-read error path, or the multisig index bounds in e2ev2. Worth separate tickets.

Note also that this PR's diff is v0.53.5 → v0.53.8, but the release ships v0.53.4 → v0.53.8 against both live networks; the v0.53.4 → v0.53.5 hop landed on main earlier and was not re-audited here.

[github-actions]

🔐 Commit Signature Verification

✅ All 1 commit(s) passed verification

Commit	Author	Signature	Key Type	Key Check
d0a6cc17ead1	RafilxTenfen	✅	sk-ssh-ed25519	✅

Summary

• Commits verified: 1
• Signature check: ✅ All passed
• Key type enforcement: ✅ All sk-ssh-ed25519

---

Required key type: sk-ssh-ed25519 (FIDO2 hardware key)

Last verified: 2026-07-30 21:34 UTC

[greptile-apps]

Greptile Summary

This PR separates the coordinated SDK binary swap from the costaking repair.

• Bumps Cosmos SDK to v0.53.8, CometBFT to v0.38.23, and the resulting ledger dependency.
• Makes v4.4 an empty, migration-only upgrade coordinating the state-breaking binary change.
• Moves the existing ActiveBaby costaking recalculation into v4.5 and registers both upgrades for mainnet and testnet.
• Adds separate end-to-end coverage for the v4.4 binary swap and v4.5 state repair.
• No SECURITY-GUARDRAILS.md file is present, so no repository-specific security guardrails apply; the reviewed dependency advisories do not expose a newly introduced reachable vulnerability in Babylon.

Confidence Score: 4/5

The PR appears safe to merge; the only issue is non-blocking stale v4.4 naming in the new v4.5 test documentation.

The production upgrade registration and handler split are internally consistent, while the remaining defect is confined to misleading comments in the moved end-to-end test.

Files Needing Attention: test/e2ev2/upgrades_v4_5_test.go

Important Files Changed

Filename	Overview
go.mod	Updates Cosmos SDK and CometBFT to security-fix releases and accepts the resulting ledger dependency update.
app/upgrades/v4_4/upgrade.go	Reduces v4.4 to a migration-only handler used to coordinate the state-breaking binary swap.
app/upgrades/v4_5/upgrade.go	Introduces v4.5 with the costaking recalculation moved unchanged from v4.4.
app/include_upgrade_mainnet.go	Registers v4.5 alongside v4.4 for mainnet.
app/include_upgrade_testnet.go	Registers v4.5 alongside v4.4 for testnet and e2e builds.
test/e2ev2/upgrades_v4_4_test.go	Replaces the old costaking scenario with coverage of the empty SDK binary-swap upgrade.
test/e2ev2/upgrades_v4_5_test.go	Preserves the costaking repair scenario for v4.5, but its introductory comments still call the upgrade v4.4.

Sequence Diagram

sequenceDiagram
    participant Gov as Governance
    participant Chain as Babylon chain
    participant V44 as v4.4 handler
    participant V45 as v4.5 handler
    Gov->>Chain: Schedule v4.4
    Chain->>V44: Run at coordinated swap height
    V44->>V44: RunMigrations only
    Note over Chain: All validators start Cosmos SDK v0.53.8 binary
    Gov->>Chain: Schedule v4.5 at second epoch block
    Chain->>V45: Run upgrade handler
    V45->>V45: RunMigrations
    V45->>V45: Recalculate costaker ActiveBaby and scores

Loading

_{Reviews (1): Last reviewed commit: "chore(deps): bump cosmos-sdk to v0.53.8,..." | Re-trigger Greptile}