Honest builders never raise timestamp to parent's, so a leader's future timestamp voids honest proposals

Read the builders and timestamp validation in msm/msm.go, starting with buildBlockOrTransitionEpoch and verifyTimestamp; then check the other builder paths at the cited locations for normal, collecting-approvals, Telock, and new-epoch blocks. Reproduce the stated case with a parent timestamped T+9s and verify the built block against its actual parent. Done means every honest builder's block passes VerifyBlock in that case.

Details

One Byzantine validator can stop honest leaders from getting blocks accepted, so the chain advances mostly through the attacker's own blocks. It needs only its normal turn as round leader. Honest builders stamp blocks with their own clock and never raise it to the parent's timestamp, so a future-dated parent makes their blocks fail verifyTimestamp.

flowchart TD
  n1["Byzantine validator acting as leader"]
  n2["honest builders in msm/msm.go (stamp raw sm.GetTime)"]
  n3["verifyTimestamp"]
  n4["honest leaders' proposals and chain progress"]
  n5["clamp of timestamp to parent's"]
  n1 -->|"future-dated block accepted"| n3
  n2 -->|"child stamped below parent"| n3
  n3 -->|"rejects honest blocks, rounds skipped"| n4
  n5 -->|"not applied"| n2
  classDef actor stroke:#2563eb,stroke-width:2px
  classDef vulnerable_code stroke:#dc2626,stroke-width:2px
  classDef existing_control stroke:#16a34a,stroke-width:2px
  classDef missing_control stroke:#dc2626,stroke-width:2px,stroke-dasharray:5 5
  classDef asset stroke:#9333ea,stroke-width:2px
  classDef component stroke:#6b7280,stroke-width:1px
  class n1 actor
  class n2 vulnerable_code
  class n3 existing_control
  class n4 asset
  class n5 missing_control

1. Byzantine validator proposes a block stamped up to about 10 seconds ahead of real time on its turn as leader. The verifier accepts any timestamp up to TimeSkewLimit ahead, and production wiring sets no TimeSkewLimit, so the default maxSkew = 10s applies. (instance.go:570-591)
2. verifyTimestamp accepts the future-dated block, which is then notarized. It rejects a timestamp below the parent's but allows one up to now + timeSkewLimit. (msm/msm.go:526-540)
3. the next honest leader's builder stamps its child block with the raw local clock. buildBlockOrTransitionEpoch uses sm.GetTime() and never raises it to the parent's timestamp, so the child is stamped earlier than its parent. (msm/msm.go:617-632)
4. the honest leader's BuildBlock proposes the block without verifying it. The leader's own node does not run VerifyBlock on what it builds, so only other nodes catch the bad timestamp. (adapters.go:263-277)
5. honest verifiers reject the block with errTimestampDecreasing. verifyNonZeroBlock runs verifyTimestamp first on every non-zero proposal, against the real parent. (msm/msm.go:498-504)
6. honest nodes empty-vote at once, so the round is skipped. triggerEmptyBlockNotarization is called on the verification failure, and the parent stays the attacker's block. (simplex/epoch.go:2227-2242)
7. Byzantine validator builds another future-dated child on its next turn. LeaderForRound is round-robin over round numbers, so the attacker leads again after a fixed number of rounds, skipped ones included. (simplex/epoch.go:3827-3830)

Evidence

1. msm/msm.go:617–632
2. msm/msm.go:1076–1077
3. msm/msm.go:1477–1482
4. msm/msm.go:526–540
5. msm/msm.go:498–504
6. external.go:62–81
7. adapters.go:263–277
8. simplex/epoch.go:2227–2242
9. simplex/epoch.go:3827–3830
10. instance.go:570–591

Impact

Honest leaders' proposals are rejected for up to TimeSkewLimit (10s) after each attacker turn. If the attacker's turns recur inside that window, honest leaders never land a block. The chain then advances only through attacker-built blocks, at a fraction of its normal rate, and the attacker picks every included transaction. No data is disclosed or changed, and every finalized block is valid.

Reproduction steps

1. The attacker is a single Byzantine validator, which the report treats as the primary threat actor. It needs only its own round-robin turn as leader. Only a validator's signed leader proposal is processed. Whether the attack repeats without end depends on how soon the attacker's turns recur. That depends on validator-set size and network delay. With small validator sets a failed round ends after one network delay, so the attacker's turns can recur inside the 10 second window. Each turn is bounded by TimeSkewLimit.

Recommended fix

The builders at msm/msm.go:588, :617, :1076 and :1478 stamp blocks with the raw local clock. The verifier requires timestamps that never decrease but accepts a parent up to TimeSkewLimit in the future. Honest builders therefore make blocks that honest verifiers reject.

Fix criteria: Every block an honest node builds passes verifyTimestamp against its actual parent, the block named by metadata.Prev, for example by using a timestamp at least the parent's. That parent is not the sealing block that buildBlockEpochSealed passes on. Test: with a verifier and an honest builder at time T, a block the honest builder builds on a parent stamped T+9s is accepted by VerifyBlock. Check this for normal, collecting-approvals, Telock and new-epoch blocks.

Status on main

Re-checked against main at 90995e0 on 2026-10-26; still present:

Every builder still stamps blocks with sm.GetTime() directly and never clamps to the parent's timestamp: msm/msm.go:588, 617, 1076 and 1478, via wrapBlock at msm/msm.go:1422. verifyTimestamp (msm/msm.go:526-541) rejects any block whose timestamp is below its parent's (531-533), but accepts timestamps up to now+TimeSkewLimit. The default limit is 10s (msm/msm.go:24, 232-233), and production wiring uses GetTime: time.Now (instance.go:571). No issue or PR tracks this.

Severity: HIGH
Status: Open
Category: Improper input validation
CWE: CWE-20
Repository: ava-labs/Simplex
Branch: main
Date created: 2026-10-26
Claude Security finding: https://claude.ai/security/findings/find_01PE8Rjj8nHkYYyQHYY372eT