A validator should never have to feel lucky.

Yet snarkVM deployment verification briefly had a path where local randomness could influence whether a deployment passed. The culprit was not proof verification itself. The trouble began earlier, while CheckDeployment synthesized a program using a burner identity and exposed that identity through self.signer.

With static calls, the burner was mostly harmless scaffolding. Dynamic dispatch changed the deal. A program could derive a call.dynamic target from the synthesized signer, so two validators checking identical deployment bytes could walk toward different callees. One might complete synthesis. Another might abort.

That is fork material.

PR #3346 made the burner signer deterministic. PR #3365 followed the thread further and seeded the remaining ambient RNG sources reachable during deployment verification. I think the second patch carries the larger lesson: consensus code cannot merely seed the random value involved in the first reported exploit. Every source of nondeterminism reachable from validation has to be treated as hostile input.

Core concept

An Aleo deployment contains more than program text. Building a deployment requires executing and proving each function so the transaction can carry the corresponding verifying material. Validators cannot accept those artifacts on faith. They check that the deployment matches the program being installed and that its certificates are valid for the synthesized functions.

Synthesis matters here because a verifying key describes a circuit. Change the circuit's constraints, ordering, or reachable call structure and the expected key can change too. A validator therefore needs a reproducible account of what circuit the deployed function means.

The desired property is simple:

verify_deployment(deployment, consensus_version) -> accept | reject

No hidden machine state belongs on the left side. Wall-clock time does not belong there. Thread scheduling does not belong there either. Neither does an RNG initialized from the operating system.

Deployment verification is consensus-critical synthesis. Given the same deployment and active rules, every honest validator must produce the same result.

Developers sometimes hear "synthesis" and picture a local build task. That mental model is dangerous inside a validator. Local compilation can tolerate temporary files, cache order, and random test identities. Consensus validation cannot. Once synthesis decides whether a transaction may enter canonical state, its inputs are part of the protocol whether the code labels them that way or not.

A random burner key is still a protocol input if program logic can observe the resulting address.

Technical deep dive

Why a burner exists

Deployment checking needs enough execution context to synthesize each function. Real execution normally has an authorization, a signer, inputs, and call state. A deployment checker does not have a user meaningfully invoking every function, so it manufactures placeholder context.

A burner account is a convenient way to produce internally valid cryptographic values for that context. Generate a temporary private key, derive its address, construct the synthetic request, then let the synthesizer proceed.

Reasonable engineering. Wrong randomness boundary.

Before dynamic dispatch, changing the burner often changed only witness-like values. Circuit systems are built to accept different witnesses under the same constraint shape. If Alice and Bob both prove x + 1 = y, their addresses may differ while the arithmetic circuit stays identical.

call.dynamic adds a value that can affect which program is called. Target selection is no longer inert witness data. The chosen target can alter import resolution, function lookup, type checks, and the call graph traversed during synthesis.

Consider a function whose dynamic target is selected by a predicate derived from self.signer:

• Signer class A selects safe_target.aleo.
• Signer class B selects missing_target.aleo.

The exact predicate could inspect an address-derived value or use it in a computation that produces the target. The important part is observability: synthetic self.signer reaches target selection.

Validator V1 draws burner key K1. Its derived address lands in class A, so synthesis resolves the call and the deployment verifies. Validator V2 draws K2. Its address lands in class B, so target resolution aborts. Both validators received the same transaction.

No cryptography failed. Consensus did.

Why dynamic calls expose the bug

Static calls put the callee in the instruction stream. A deployment checker can resolve that callee from the deployment and its imports before it manufactures execution values. Random witnesses should not decide where the call goes.

Dynamic calls move target selection into runtime data. Aleo needs that capability for generic applications, interface-driven composition, and token flows that choose implementations later. I remain bullish on the feature. Runtime-selected composition is useful.

Useful features widen the attack surface, though. My earlier post on snarkVM's record-existence guarantee covered another side of the same shift: values once treated as static assumptions now cross dynamic boundaries and need stronger VM invariants.

Compiler ordering bugs tell a similar story. In Why Leo's stub-ordering bug exposes Aleo's real composability boundary, imported calls carrying finalization behavior made source ordering relevant in places developers did not expect. Dynamic composition keeps finding old assumptions about fixed call graphs. Some assumptions fail safely. Random deployment verification did not.

The certificate connection

Deployment certificates let validators verify that supplied function keys correspond to valid synthesis rather than regenerating every expensive artifact from scratch without evidence. Certificates reduce work, but they do not remove the need for deterministic semantics.

A certificate can attest to one synthesized circuit. If local randomness lets another validator synthesize a different circuit or abort before reaching certificate verification, the certificate cannot reconcile the disagreement. Cryptographic verification answers, "Does this certificate validate against these inputs?" It cannot answer, "Why did two nodes choose different inputs?"

That distinction matters. ZK systems often make engineers comfortable with randomness because proving naturally uses random coins, blinding factors, and sampled witnesses. Those values are fine when their effects are contained within a proof whose public statement is fixed. Randomness that changes the statement being checked is a different animal.

The deployment is the public statement. Validator-local entropy must not edit it indirectly.

What #3346 fixed

PR #3346 made the CheckDeployment burner deterministic. The same verification path now derives the same synthetic signer instead of asking each validator's environment for a fresh identity.

That closes the direct disagreement where self.signer steers call.dynamic toward different targets. Every validator sees the same synthesized signer, evaluates the same target-selection logic, and either reaches the same callee or aborts in the same place.

Deterministic does not mean secret. The burner has no authority and should not be treated as an unpredictable identity. Its job is reproducibility. A fixed or deterministically seeded test identity is better than a cryptographically fresh one because freshness has no security value in this context.

One caveat deserves attention. Seeding an RNG does not automatically guarantee stable output forever. Rust's SeedableRng documentation warns that some generic generators, including StdRng, do not promise reproducibility across versions or architectures. Consensus code should use a specified algorithm or transform deterministic bytes directly into the required test values. "Same seed" is only enough when the generator's byte stream is itself part of the compatibility contract.

Why #3365 was necessary

Fixing the burner addressed the known trigger. PR #3365 took the safer approach and seeded the remaining ambient RNG sources reachable during deployment checking.

That follow-up matters because synthesis code is layered. A top-level verifier may pass through request construction, authorization helpers, call-stack setup, input sampling, and nested synthesis routines. Any helper that quietly opens an entropy-backed RNG can reintroduce validator-local state.

Finding one bad draw does not prove the path is deterministic. You have to audit reachability.

A good implementation gives deployment verification an explicit deterministic RNG context and threads it through every routine that needs pseudo-random test material. Better still, separate APIs by purpose. Proof creation may accept secure entropy. Consensus synthesis should accept a deterministic source whose origin is obvious at the call site.

I would also domain-separate derived streams. Burner generation and synthetic input generation should not consume one shared stream in whatever order the current implementation happens to call them. Derive independent streams from a stable deployment digest plus fixed labels. Refactoring one helper then cannot shift all later values by consuming an extra sample.

PR #3365 closes the immediate exposed paths. The architectural rule should survive the patch: no ambient RNG inside deployment validation, including code reached several layers below the public verifier.

Practical examples

A deployment that becomes a coin flip

Imagine router.aleo accepts a dynamic program identifier. During ordinary execution, an authenticated user supplies or derives the target. During deployment checking, the synthesizer needs representative values, so synthetic context fills the relevant registers.

Now add a branch based on the low bits of self.signer. One branch selects an imported implementation with the expected function signature. The other selects a program that is absent or exposes an incompatible function.

An entropy-backed burner makes acceptance probabilistic across processes. Running verification ten times might yield a mix of passes and aborts. The deployment bytes never changed.

After deterministic seeding, repeated checks produce one stable answer. A malicious deployment may still be rejected, which is fine. Consensus requires agreement, not generosity.

A test that should exist

The regression test should verify process-level determinism rather than checking one expected burner address and calling it done.

Run CheckDeployment repeatedly with fresh verifier instances. Vary thread count and execution order. Clear caches between runs. Feed a deployment whose dynamic target is sensitive to the synthesized signer, then assert that every run returns the same result and synthesizes the same public circuit identity.

A second test should instrument RNG creation. Consensus validation fails the test if any reachable path requests operating-system entropy. Static analysis can help, but runtime instrumentation catches calls hidden behind helpers or feature-gated code.

Agents building deployment tooling can use the same pattern. Preflight the deployment in separate worker processes, compare synthesized key identifiers, and refuse to broadcast if results differ. Such a guard does not repair a validator bug. It does stop an automated deployment pipeline from repeatedly submitting a transaction whose validity depends on local conditions.

Determinism versus unpredictability

Randomness has two separate jobs in cryptographic software.

Provers need unpredictability for secrets, nonces, and blinding. Validators need reproducibility when reconstructing a consensus statement. Mixing those jobs behind a generic rng parameter makes review harder because the type says nothing about the security contract.

I prefer separate types such as SecureProverRng and ConsensusSynthesisRng, even if both wrap similar primitives. The compiler can then prevent a verifier from accidentally calling an entropy constructor. Names are cheap. Forks are not.

Implications

Aleo's move toward dynamic dispatch raises the standard for deterministic synthesis. Static programs can hide sloppy assumptions because many witness values never affect circuit shape. Dynamic target selection lets ordinary values influence resolution paths, so synthetic context becomes observable in new ways.

Validator developers should treat deployment checking like a state-transition function:

• Derive synthetic values only from stable, consensus-visible data or fixed protocol constants.
• Use reproducible algorithms with pinned behavior across supported platforms.
• Domain-separate independent pseudo-random streams so refactors cannot shift unrelated samples.
• Test acceptance across processes, cache states, and execution schedules.

Leo and SDK developers have a smaller but real responsibility. Tooling should never assume that one successful local deployment build proves universal validity. Cache keys should include the program identity, function, edition, and any deployment amendment count. I made a related argument in Why Aleo needs amendments for verifying-key upgrades: proof material has lifecycle and identity rules of its own. Deterministic synthesis is what makes those rules usable across machines.

Protocol reviewers should search for ambient state, not merely calls named random. Hash-map iteration order, locale-sensitive parsing, unpinned algorithms, architecture-dependent serialization, and parallel reductions can all create the same class of failure. RNG was simply the loudest lion in the room.

PRs #3346 and #3365 fixed a sharp bug before it hardened into protocol folklore. The lasting standard is stricter. If deployment data is identical, every validator must synthesize the same program view and return the same verdict.

No dice. Not here.