StudioNet 61999 deployment regression / invalid_contract with documented py-genlayer runner

[Chinny070]

We are seeing reproducible contract deployment failures on StudioNet:

Network: StudioNet
Chain ID: 61999
RPC: https://studio.genlayer.com/api
Depends:
py-genlayer:1jb45aa8ynh2a9c9xn3b7qqh8sm5q93hwfp7jqmwsfhh8jpz09h6

We reproduced the problem with two completely different contracts.

1. FairMod

TX:
0x5eeecca70cdd03c116e3c7394dfd5683204c2abf16694a99680dc478cfda4af1

Source SHA-256:
ec0bf1b067008f3477db33bf6ae8579386814b5df3975a44264fd95a42bbee23

2. Minimal runtime probe

TX:
0xfb75f814b3418946e96d3ef51bc4f14ca462f3b60520a36638a60c3b3574470e

Source SHA-256:
cb7c51d435c85f389724ea2ed42b87682243a21e312171a0fc3eaf9afa9d5434

The second contract is intentionally minimal: no nondeterminism, web access, LLM calls, complex storage or constructor arguments. It contains only a trivial view method.

Both transactions reach FINALIZED consensus, but GenVM execution reports:

Execution Result: ERROR
Result Code: Contract Error
Error Message: invalid_contract

The minimal probe received 5/5 validator AGREE on the error outcome.

stdout, stderr, and raw_error contain no application-level traceback.

Neither resulting contract address exists afterward: genlayer schema, genlayer code, and contract calls return "Contract not found".

Tooling:
genlayer CLI 0.39.2
genlayer-js 1.1.8
genlayer-test 0.29.2
genvm-linter 0.11.1rc2
Node 24.14.0
Python 3.12.10

The CLI is using its built-in studionet preset; there are no custom RPC/chain overrides.

Could you confirm:

1. Is py-genlayer:1jb45aa8... currently registered/available to validators on StudioNet 61999?
2. What condition produces invalid_contract before application code begins executing?
3. Is there a currently supported Depends hash/runtime we should use for stable StudioNet 61999?
4. Is this a known StudioNet incident/regression?

We have deliberately not migrated to Studio-dev/61997 or another runner, because we want to identify the compatibility issue before changing the tested contract candidate.

[Chinny070]

Third independent reproduction of invalid_contract, after a full local-toolchain contamination cleanroom

Following up on this issue with a clean, controlled reproduction. Summary first: local tooling contamination has been ruled out as the cause — the failure persists identically under a verified-clean toolchain.

Background

We previously suspected our earlier failures might be explained by mixed GenVM tooling generations in our local environment (specifically, genvm-linter 0.11.1rc2 had auto-resolved and cached v0.6.0-rc1/rc5/rc6 GenVM artifacts — a newer, prerelease generation than the runner we're pinned to). We understand this exact runner hash has deployed successfully elsewhere on StudioNet 61999, so we ran a full cleanroom to eliminate our own tooling as a variable before reporting back.

Cleanroom toolchain (corrected, verified by execution not just metadata)

• Network: StudioNet, Chain ID 61999, RPC https://studio.genlayer.com/api
• Repository-local genlayer CLI: 0.39.1 (proven via direct execution: ./node_modules/.bin/genlayer --version → 0.39.1; global CLI 0.39.2 was present but not used for this test)
• genvm-linter: 0.11.0 (uninstalled 0.11.1rc2 first; deleted ~/.cache/genvm-linter/ entirely — this removed the cached v0.6.0-rc1/rc5/rc6 tarballs and extracted trees, and a corrupted partial-upgrade dist-info remnant)
• genlayer-test/gltest: 0.29.2 (already correct, untouched)
• GENVM_VERSION: confirmed not set anywhere in the environment, and confirmed not read by any code path in the installed gltest package (grepped the full package source)
• Direct Mode (local in-memory test runner)'s own execution cache was independently confirmed to already be the correct, non-RC, stable v0.2.16 generation — and to already contain our exact pinned runner hash pre-extracted — so it was left untouched
• Runner (unchanged throughout): py-genlayer:1jb45aa8ynh2a9c9xn3b7qqh8sm5q93hwfp7jqmwsfhh8jpz09h6

Local validation of our existing contract under this corrected toolchain: Python compile PASS, genvm-lint PASS, schema PASS (30 public methods), Direct Mode PASS, 192/192 tests PASS. No incompatibility of any kind was found locally.

Fresh minimal reproduction

To rule out any possibility that our own (much larger) application contract was somehow contributing to the failure, we wrote a brand-new, deliberately minimal contract from scratch (not a reuse of our earlier control contract) — one Contract class, one deterministic @gl.public.view, no LLM, no web, no nondeterminism, no storage beyond the bare class, using the identical pinned Depends header:

# { "Depends": "py-genlayer:1jb45aa8ynh2a9c9xn3b7qqh8sm5q93hwfp7jqmwsfhh8jpz09h6" }

from genlayer import *

class StudioNet61999CleanProbe(gl.Contract):
	def __init__(self):
		pass

	@gl.public.view
	def get_probe(self) -> str:
		return "FAIRMOD_61999_CLEANROOM_OK"

This passed Python compile, genvm-lint (0.11.0), schema extraction, and a Direct Mode deterministic test (returns the literal string as expected) locally.

Hosted deployment result

Deployed via the repository-local CLI 0.39.1 to StudioNet 61999:

• Transaction hash: 0xdbd7e25d27dbb80b95823a3d7c4bb31f91063d9f202452234ba02a8ab7bc01ab
• Resulting contract address: 0xDEf36e64CC9E3FEaa20b55CaC9489900a1Fa7127
• Protocol status: FINALIZED
• GenVM Execution Result: ERROR
• Result Code: Contract Error
• Error Message: invalid_contract
• Stdout/Stderr: both empty
• Independently confirmed via the Studio Explorer (explorer-studio.genlayer.com/tx/0xdbd7e25d27dbb80b95823a3d7c4bb31f91063d9f202452234ba02a8ab7bc01ab) — identical status/result/error, not just the CLI's own report
• The resulting contract address is not queryable: genlayer schema <address> and genlayer code <address> both return Contract ... not found
• Note for anyone reading transaction logs casually: the CLI itself prints "✔ Contract deployed successfully" on this transaction — that only reflects protocol-level finality/acceptance, not GenVM execution success. We want to flag this because it could cause false-positive "it works" reports elsewhere.

Reproduction history

This is now the third independent occurrence of the identical failure signature (FINALIZED protocol status + GenVM execution_result: ERROR + Contract Error: invalid_contract) under this exact runner hash:

1. Our FairMod application contract's own deployment attempt
2. An earlier, separate minimal control contract
3. This new, from-scratch cleanroom probe (above) — critically, deployed after fully removing the local tooling contamination we'd suspected

What we are and are not claiming

We are not claiming this runner hash is universally broken — we understand it has deployed successfully elsewhere on StudioNet 61999. What this reproduction establishes is narrower: the failure persists after correcting the local-toolchain contamination we previously suspected as the cause. It does not by itself tell us whether the actual cause is validator-side runner resolution, GenVM Manager state/configuration, deployment-source/header handling, account- or node-specific behavior, an RPC/backend inconsistency, or something else entirely on the hosted execution path.

Could you help us look into

1. Why this transaction reaches protocol FINALIZED but GenVM reports invalid_contract — is there a more specific server-side contract-loading error not surfaced in the public transaction result?
2. Whether the validators that processed this specific transaction successfully resolved py-genlayer:1jb45aa8ynh2a9c9xn3b7qqh8sm5q93hwfp7jqmwsfhh8jpz09h6 for it.
3. Whether there's any currently-required StudioNet 61999 deployment/header/configuration change that isn't reflected in the stable tooling path we used (CLI 0.39.1 / genvm-linter 0.11.0 / gltest 0.29.2).
4. Whether you're able to reproduce a deployment of the minimal probe source above against StudioNet 61999 from your side.

Happy to provide any further logs, the full transaction receipt JSON, or try anything else that would help isolate this. Thanks for looking into it.