nautechsystems/nautilus_trader · error
Manifest probe call data is invalid
Error message
Manifest probe call data is invalid
What it means
The manifest validator parses each contract probe's call_data field with alloy's Bytes::from_str, which requires a valid hex byte string (optionally 0x-prefixed, even length). This error means a probe's call_data is not valid hex, so the verifier cannot build the identity probe call it would use to confirm the deployed contract matches the manifest.
Source
Thrown at crates/adapters/blockchain/src/rpc/verification.rs:1311
let storage_value = B256::from_str(&proxy.storage_value)
.map_err(|_| anyhow::anyhow!("Proxy storage value is invalid"))?;
let target = Address::from_str(&proxy.target_address)
.map_err(|_| anyhow::anyhow!("Proxy target address is invalid"))?;
let target_hash = B256::from_str(&proxy.target_code_hash)
.map_err(|_| anyhow::anyhow!("Proxy target code hash is invalid"))?;
anyhow::ensure!(
target != Address::ZERO
&& target != address
&& target_hash != B256::ZERO
&& storage_value[..12].iter().all(|byte| *byte == 0)
&& storage_value[12..] == *target.as_slice(),
"Proxy target binding is invalid"
);
}
for probe in &contract.probes {
Bytes::from_str(&probe.call_data)
.map_err(|_| anyhow::anyhow!("Manifest probe call data is invalid"))?;
Bytes::from_str(&probe.expected_output)
.map_err(|_| anyhow::anyhow!("Manifest probe output is invalid"))?;
}
}
for contract in &manifest.contracts {
let Some(proxy) = &contract.proxy else {
continue;
};
let target =
Address::from_str(&proxy.target_address).expect("validated proxy target address");
let target_contract = manifest
.contracts
.iter()
.find(|candidate| Address::from_str(&candidate.address).ok() == Some(target))
.ok_or_else(|| {
anyhow::anyhow!("Proxy target has no unique deployment manifest identity")
})?;View on GitHub (pinned to 18893faf8b)
Solutions
- Set probe.call_data to valid even-length hex (e.g. 0x8da5cb5b for owner())
- Encode the intended call with an ABI encoder (cast calldata / ethers) and copy the output verbatim
- Re-run manifest generation so call_data is produced programmatically
Example fix
// before
{"call_data": "owner()"}
// after
{"call_data": "0x8da5cb5b"} Defensive patterns
Strategy: validation
Validate before calling
fn valid_hex_bytes(s: &str) -> bool {
let h = s.strip_prefix("0x").unwrap_or(s);
!h.is_empty() && h.len() % 2 == 0 && h.chars().all(|c| c.is_ascii_hexdigit())
}
assert!(manifest.contracts.iter().flat_map(|c| &c.probes).all(|p| valid_hex_bytes(&p.call_data))); Try / catch
match validate_manifest(&config) {
Err(e) if e.to_string().contains("probe call data") => {
eprintln!("re-encode probe call_data with an ABI encoder: {e}");
}
Err(e) => return Err(e),
Ok(v) => v,
} Prevention
- Generate call_data with an ABI encoder (cast calldata 'fn()' or ethers Interface), never by hand
- Never paste Solidity signatures where hex bytes are expected
- Pre-commit script that hex-validates all probe fields
- Keep the 0x prefix lowercase and intact through JSON tooling
When it happens
Trigger: Running deployment manifest verification when a contract's probes[] entry has call_data that is empty, odd-length, or contains non-hex characters — e.g. an ABI signature string like 'owner()' pasted instead of its 4-byte selector.
Common situations: Writing probe call data by hand instead of encoding with an ABI encoder; pasting a Solidity function signature rather than keccak-derived selector bytes; shell/JSON escaping corrupting the 0x prefix; tools emitting odd-length hex.
Understand the failure class
Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.
Related errors
- Chart function must be callable, was {type(func)}
- Chart '{name}' not found.{suggestion_text} Available charts:
- plotly is required for visualization. Install it with: pip i
- A BacktestNode is required for the bars_with_fills chart
- Manifest probe output is invalid
AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08).
Data as JSON: /api/errors/dba10aeb074802dd.
Report an issue: GitHub.