diff --git a/CIPs/cip-173.md b/CIPs/cip-173.md
new file mode 100644
index 0000000..d3ba63c
--- /dev/null
+++ b/CIPs/cip-173.md
@@ -0,0 +1,68 @@
+---
+CIP No.: 173
+Title: Fix PoS Dispute Evidence and Stake Locking
+Author: Peilun Li (@peilun-conflux)
+Status: Draft
+Type: Spec Breaking
+Created: 2026-07-06
+Required CIPs (*optional): 156
+---
+
+## Simple Summary
+
+A PoS dispute penalizes a validator that signed two conflicting messages in the same round by locking its stake for six months (CIP-156). Currently the evidence check accepts pairs that prove no conflict — for example, two copies of a single vote — and the lock is skipped entirely for a validator whose stake is already fully unlocking. From a PoS activation view, this CIP accepts a dispute only if both pieces of evidence are signed by the accused validator and are genuinely distinct, and extends the lock to a validator whose stake is entirely unlocking.
+
+## Abstract
+
+A dispute transaction carries two votes or two proposal blocks from the same epoch and round as evidence that a PoS validator equivocated; once accepted, the validator's entire stake is locked for six months (CIP-156). Two bugs weaken this mechanism: the verifier accepts evidence pairs that prove no conflict, and the lock is not applied when the accused validator's stake is entirely unlocking. From a PoS transition view, this CIP requires vote evidence to be two valid vote signatures over `LedgerInfo`s with distinct hashes, proposal evidence to be two `Proposal` blocks signed by the accused validator with distinct block ids, and the dispute lock to cover a validator whose entire stake is unlocking.
+
+## Motivation
+
+The dispute verifier checks each piece of evidence individually but never that the pair conflicts, so two copies of the same vote or proposal qualify as a dispute and an honest validator can lose access to its stake for six months. For proposal evidence, NIL blocks pass with no signature from the accused validator at all, while genuine equivocation evidence is rejected because its committee-signed quorum certificates cannot be verified with the accused validator's key alone.
+
+On the penalty side, the CIP-156 lock is skipped for a validator with no locking or locked votes, so a validator that retires all its votes after equivocating recovers its stake on the normal unlocking schedule instead of six months later.
+
+Dispute handling mutates the PoS state on every node, so the fixes require a coordinated activation.
+
+## Specification
+
+### Parameters
+
+`POS_DISPUTE_FIX_TRANSITION_VIEW`: the PoS view at which this CIP activates. This is a view of the PoS chain, not a PoW block height: the rules apply when the view of the PoS state processing the dispute is at least this value.
+
+### Dispute evidence
+
+From the activation view, a dispute transaction is valid only if the accused address matches the payload's public keys and:
+
+- **Vote evidence**: both votes decode, vote for a block of the same epoch and round, and pass signature verification against the accused validator's key; and the two signed `LedgerInfo`s have distinct hashes.
+- **Proposal evidence**: both blocks decode and carry the same epoch and round in their block data; both are `Proposal` blocks authored by the accused validator, each with a valid proposer signature over its block data; and the two block ids (the hash of the block data) are distinct. The embedded quorum certificates are not verified.
+
+A dispute transaction failing these checks is rejected at execution; one validated at a view below the transition view follows the previous rule.
+
+### Stake locking
+
+A dispute-triggered relock covers all of the accused validator's locking, locked, and unlocking votes. From the activation view, the relock triggers whenever any such votes exist; below it, only locking or locked votes trigger it, so a validator whose votes are all unlocking is not relocked.
+
+## Rationale
+
+Distinctness is judged on the message the validator signed — the `LedgerInfo` hash for votes, the block id for proposals — rather than on the submitted evidence bytes, so a single vote re-encoded (for example, with its optional timeout signature attached) does not count as equivocation.
+
+## Backwards Compatibility
+
+This is spec breaking for PoS nodes.
+
+## Test Cases
+
+Test cases for the evidence rules are provided in conflux-rust PR [#3534](https://github.com/Conflux-Chain/conflux-rust/pull/3534).
+
+## Implementation
+
+Reference implementations: conflux-rust PRs [#3524](https://github.com/Conflux-Chain/conflux-rust/pull/3524) (stake locking) and [#3534](https://github.com/Conflux-Chain/conflux-rust/pull/3534) (evidence rules).
+
+## Security Considerations
+
+The evidence rules close a path by which an honest validator's stake could be locked without misbehavior — an accepted dispute now proves the accused validator signed two distinct messages in the same round — and make genuine proposal equivocation disputable, since evidence no longer fails on its committee-signed quorum certificate. The stake-locking rule closes the escape where a validator retires its votes after equivocating and exits on the normal unlocking schedule, restoring the six-month deterrent of CIP-156.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).