> For the complete documentation index, see [llms.txt](https://docs.chiliz.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.chiliz.com/chiliz-chain-changelog/governance-proposals-and-decisions/september-2026-sherlock-audit-remediation-proposal.md).

# September 2026: Sherlock Audit Remediation Proposal

CIP-051 proposal to upgrade the Chiliz Chain system contracts to v5.0.3, deploying every accepted fix from the Sherlock security audit (contest #550) to mainnet.

**Proposal ID:** CIP-051

**Title:** Upgrade Chiliz Chain System Contracts to v5.0.3 - Sherlock Audit Remediation

**Voting Deadline:** Monday, September 28th, 2026 at 11:00am CET

**Contracts upgraded:** Staking (`0x…1000`), SystemReward (`0x…1002`), StakingPool (`0x…7001`), Governance (`0x…7002`), ChainConfig (`0x…7003`)

### Summary

In 2025 Chiliz ran a public security audit of the Chiliz Chain system contracts through Sherlock (contest #550). This proposal deploys release v5.0.3 of the system contracts to mainnet, which contains every accepted fix from that audit. The audit fixes have been running on Spicy testnet since late 2025 across four executed governance proposals, with a dedicated Foundry regression test for each finding. The release also carries a few minor follow-ups made after the Spicy batches: per-validator tracking of pending unstakes in StakingPool, a corrected `isProposer` check in Governance, and a gas optimisation for delegator reward calculations.

No CHZ balances, delegations or validator positions are modified by this upgrade. Storage is preserved; only contract bytecode is replaced, plus three one-shot initializers that copy existing consensus parameters into new epoch-indexed storage.

### What the upgrade fixes

**Protects delegator funds.** Closes a cheap denial-of-service on the undelegation queue that could permanently lock a delegator’s stake, fixes a case where partial reward claims silently forfeited rewards, and stops governance from removing a validator while it still has delegators (which previously stranded their funds).

**Fixes reward accounting.** Corrects how historical validator snapshots are looked up, closing an inconsistency that could be exploited to over-claim rewards from the Staking contract. Liquid-staking pool shares are now deducted at unstake time rather than at claim time, so the pool’s exchange ratio can no longer be inflated during the cooldown period. Small “dust” rewards accumulating in the pool are now recycled once they reach 500 CHZ.

**Hardens reward distribution.** System-fee payouts can no longer be blocked by a single recipient that cannot receive CHZ; such recipients are set aside and can withdraw separately. Slashing fees are forwarded to SystemReward through a new permissionless path so they no longer depend on an inactive validator’s owner claiming.

**Makes governance quorum tamper-proof.** Quorum and voting supply are now computed from the validator set and the active-validator count *as they were at the proposal’s snapshot epoch*. A validator can no longer shift quorum during a vote by getting jailed, and parameter changes made mid-vote no longer affect the outcome. Validator ordering is now deterministic when two validators have equal stake.

**Removes dangerous administrative functions.** `Staking.fixValidatorEpoch()` (could rewrite historical stake totals) and `ChainConfig.setEpochBlockInterval()` (would desynchronise every epoch-indexed structure) are deleted. Epoch length can now only change via hard fork.

**Validator lifecycle corrections.** Re-registered validators can no longer re-claim past fees, the felony jail check uses `>=` so no validator can skip past the threshold, and jail release is computed from the next epoch, consistent with the undelegation epoch logic (jail effectively lasts one epoch longer).

### Behavioural changes to be aware of

* Changes to `activeValidatorsLength` and `misdemeanorThreshold` now take effect from the next epoch, not immediately.
* `claimValidatorFee` can be triggered by anyone; rewards are still paid only to the validator owner.
* Staked balances shown by the liquid-staking pool drop at unstake time instead of at claim time. Integrations that subtracted pending unstakes manually must update.
* Governance can no longer remove a validator that still has delegators or unclaimed rewards.

### Rationale

These are the highest-impact findings from an independent public audit. Several were rated High by Sherlock, including two paths to draining the Staking contract and an incorrect quorum calculation affecting every governance vote. Deploying them as one coherent release, after a full testnet cycle, is lower risk than leaving known issues on mainnet.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.chiliz.com/chiliz-chain-changelog/governance-proposals-and-decisions/september-2026-sherlock-audit-remediation-proposal.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
