Our synthetic constructor returns runtime bytes that differ in length from the runtime recorded in its compiled artifact. A trace identifier searching only artifacts near the observed runtime length skips the correct constructor. A different artifact with superficially similar runtime can then supply the wrong label and ABI.

We build an independent trace selection fixture with invented byte sequences. It models identity precedence and constructor argument offsets. It does not invoke Foundry or decode real deployment traces and contains no contract addresses or deployment configuration.

Creation code and runtime answer different questions

Creation code runs during deployment and returns the runtime installed at the resulting address. A constructor using assembly can return bytes that do not resemble the runtime recorded in its own compiled artifact. Treating those two byte sequences as interchangeable loses information about how the deployment happened.

Foundry traces use local compilation artifacts to attach names and ABI information. A runtime length index can reduce the number of candidate comparisons but that optimization must not exclude a valid creation identity merely because the returned runtime has another length.

function identify({ input, runtime, success }, known) {
  if (!success || runtime.length === 0) return null;
  const candidates = known.filter((a) => input.startsWith(a.creation));
  if (candidates.length === 0) return null;
  const exact = known.find((a) => a.runtime === runtime && a.metadata);
  if (exact) return { name: exact.name, offset: null };
  candidates.sort((a, b) => b.creation.length - a.creation.length);
  const selected = candidates[0];
  return { name: selected.name, offset: selected.creation.length / 2 };
}

The fixture searches successful creations using the input bytes even when the observed runtime has a different length. If one artifact's creation sequence is a prefix of another the longer valid match wins in this simplified model. The argument offset then begins after the selected creation sequence.

Preserve stronger runtime identity when it exists

A constructor can intentionally return the runtime of another known artifact. In that case an exact runtime match may supply the appropriate ABI for later calls. A useful selection rule needs to distinguish that exact identity from a fuzzy similarity score.

Our fixture gives an exact runtime plus matching metadata precedence over the creation fallback. A metadata mismatch prevents that override. The example uses a Boolean metadata field as an explicit test input and does not implement Solidity metadata parsing or immutable reference normalization.

We keep exact runtime identity separate from approximate runtime similarity because a constructor can deliberately install another artifact's code while a nearly matching byte sequence can also belong to an unrelated artifact and choosing an ABI from the latter makes a trace look authoritative even though the identity evidence never justified that interpretation.

An actual artifact matcher also has to account for populated immutables and linked library references. Those regions can differ from placeholder bytes in a compiled artifact. Comparing the entire byte array literally is insufficient when the artifact describes permitted substitutions.

Constructor arguments depend on the selected identity

Deployment input contains creation code followed by constructor arguments. An identifier that selects the wrong creation artifact can choose the wrong boundary and decode arbitrary bytes as arguments. Keeping the offset from the successful creation match preserves the relationship between identity and decoding.

The fixture appends invented argument bytes after a longer creation sequence and asserts the resulting offset. An exact returned runtime match has no constructor offset for that runtime artifact because the observed constructor belonged to another identity. Those are separate pieces of evidence.

Creation fallback selects constructor at byte offset 4; exact runtime can retain identity
6 assertions passed

Failed creation attempts and successful empty runtime constructions receive no new creation fallback identity in the model. This is a deliberate selection policy. It prevents a prefix match alone from presenting an unsuccessful construction as an installed runtime identity.

Make misleading candidates part of the regression

A positive test containing only the desired artifact is too forgiving. We include a fuzzy decoy and a shorter creation prefix alongside the correct artifact. Another case supplies an exact runtime artifact and verifies that it wins only when its metadata condition holds.

For a Rust trace matcher the full regression set needs actual artifact structures and trace success flags. It should also include CREATE2 failures and immutable references. Our JavaScript model defines the precedence questions but does not establish compatibility with a particular Foundry release.

An assembly constructor returning a second contract's runtime makes a focused Foundry integration fixture. Inspect the deployment label and subsequent call decoding independently so each assertion names the identity evidence it expects the matcher to preserve.

Sources and examples