# Hardcoded message fields in cross-chain handlers

Trace every user-supplied field into outbound message construction; check hardcoded payloads, vote types, and single-field validity checks

_Area: Smart contract access control and control flow. Seen in 3 disclosed reports; latest 2024-09-06. Updated 2026-10-23._

## How it works
Cross-chain and handler code often builds an outbound message or a validity decision from a fixed value instead of the real input. The assumption that breaks is that the field the user supplied (message body, vote outcome, recipient) is faithfully carried through. When a constructor hardcodes an empty payload, a fixed success vote, or infers intent from one top-level field, the downstream contract or verifier sees something different from what the user intended, and delivery, slashing, or verification silently fails.

## Where it shows up
- Outbound message constructors that pass a literal empty string or zero value where a user field should go [E1](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AH-06.md)
- Vote handlers that always pass a single outcome (e.g. success) to the ballot, unlike sibling handlers that map status [E2](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-05.md)
- Verifiers that infer validity from one field (tx.To) rather than the logical action [E3](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-21.md)
- Event post-processing paths that read a struct but drop fields before building the next message [E1](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AH-06.md)

## How to review
Trace each field of the user-supplied struct from the event/source all the way into the outbound message or decision. The invariant: every user-controlled field must reach its destination unchanged, and every threshold path must be able to express both outcomes. For verifiers, check whether the same logical action can occur via an intermediary (wrapper, multicall, proxy) that changes the field being checked [E3](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-21.md).

## Variants seen
- Hardcoded empty message field breaks destination callback [E1](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AH-06.md)
- Hardcoded success vote removes failure path and slashing deterrent [E2](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-05.md)
- Single-field validity check misses intermediary-routed deposits [E3](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-21.md)

## Impact and severity
E1 breaks messaging and risks locked or burned funds. E2 enables free ballot spam that honest observers must process but cannot slash. E3 causes valid deposits to be dropped. Severity is high where funds are locked or slashing is disabled; worse when the broken path is the only delivery or verification route.

## Evidence
- E1: https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AH-06.md
- E2: https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-05.md
- E3: https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-21.md
