nautechsystems/nautilus_trader · error

Sealed transaction payload is {} bytes, exceeding the {} byt

Error message

Sealed transaction payload is {} bytes, exceeding the {} byte limit

What it means

parse_envelope rejects sealed transaction envelopes larger than MAX_SEALED_TRANSACTION_BYTES before attempting to parse the header, key id, nonce, or ciphertext. This is a defensive DoS/size guard: the caller passed an envelope byte buffer that exceeds the configured hard limit, so it cannot possibly be a legitimately sealed transaction produced by `seal`.

Source

Thrown at crates/adapters/blockchain/src/execution/sealing.rs:402

    .context("persisted execution calldata is invalid")?;
    let value = U256::from_str(&intent.transaction_value)
        .context("persisted execution value is invalid")?;

    Ok((to, Bytes::from(input), value))
}

pub(crate) fn envelope_key_id(envelope: &[u8]) -> anyhow::Result<[u8; KEY_ID_LEN]> {
    Ok(parse_envelope(envelope)?.key_id)
}

struct ParsedEnvelope<'a> {
    key_id: [u8; KEY_ID_LEN],
    nonce: &'a [u8],
    ciphertext_and_tag: &'a [u8],
}

fn parse_envelope(envelope: &[u8]) -> anyhow::Result<ParsedEnvelope<'_>> {
    anyhow::ensure!(
        envelope.len() <= MAX_SEALED_TRANSACTION_BYTES,
        "Sealed transaction payload is {} bytes, exceeding the {} byte limit",
        envelope.len(),
        MAX_SEALED_TRANSACTION_BYTES
    );
    anyhow::ensure!(
        envelope.len() >= ENVELOPE_HEADER_LEN + TAG_LEN,
        "Sealed transaction payload is truncated"
    );
    anyhow::ensure!(
        envelope[0] == ENVELOPE_VERSION,
        "Unsupported signed transaction payload envelope version {}",
        envelope[0]
    );

    let key_id = envelope[1..1 + KEY_ID_LEN]
        .try_into()
        .expect("fixed key ID slice length");

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Inspect the byte slice length at the call site and find where extra bytes were prepended or appended; pass exactly the sealed envelope bytes
  2. Re-seal the transaction with seal() and re-persist it if the stored payload is corrupted
  3. If payloads legitimately grew, raise MAX_SEALED_TRANSACTION_BYTES deliberately and audit all persisted envelopes for the new limit

Example fix

// before
let envelope = fs::read(path)?;
unseal(&envelope, ...)?; // envelope includes a JSON wrapper
// after
let raw = fs::read(path)?;
let envelope: Vec<u8> = serde_json::from_slice(&raw)?; // extract raw sealed bytes first
assert!(envelope.len() <= MAX_SEALED_TRANSACTION_BYTES);
unseal(&envelope, ...)?;
Defensive patterns

Strategy: validation

Validate before calling

fn ensure_envelope_size(envelope: &[u8]) -> anyhow::Result<()> {
    anyhow::ensure!(
        envelope.len() <= MAX_SEALED_TRANSACTION_BYTES,
        "sealed envelope is {} bytes, limit is {}",
        envelope.len(),
        MAX_SEALED_TRANSACTION_BYTES
    );
    Ok(())
}

Type guard

fn is_valid_envelope_size(envelope: &[u8]) -> bool {
    envelope.len() <= MAX_SEALED_TRANSACTION_BYTES
}

Try / catch

match unseal(&envelope, deployment_id) {
    Ok(tx) => tx,
    Err(e) if e.to_string().contains("byte limit") => {
        // log envelope.len(), quarantine the payload, do not retry
    }
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: Calling unseal() or envelope_key_id() with an envelope byte slice whose length exceeds MAX_SEALED_TRANSACTION_BYTES — e.g. corrupted storage bytes, concatenating/prefixing the ciphertext with extra data, or a buggy producer that wrote trailing bytes.

Common situations: A persisted sealed payload was corrupted or truncated incorrectly during database migration; a caller passes an entire file or JSON-wrapped payload instead of the raw sealed bytes; version skew where a newer writer added fields, inflating size past the older reader's limit.

Understand the failure class

Background: payload too large / request exceeds maximum size: why libraries cap bytes and how to fix oversize payloads — this error's family across 50 libraries.

Related errors


AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08). Data as JSON: /api/errors/55395ea93a06a950. Report an issue: GitHub.