Studio Next deployment fails with FeesDistributionMissing for any contract via standard SDK path

[Snehal707]

Summary

Deploying an Intelligent Contract through the standard genlayer-js / CLI path fails on Studio Next (chain ID 61997) with FeesDistributionMissing, before any contract is created. This is not specific to a large or complex contract: the same failure occurred with a minimal single-field probe.

Environment

• Studio Next RPC: https://studio-dev.genlayer.com/api
• Reported chain ID: 61997 (RPC response: 0xf22d)
• SDK/CLI: genlayer CLI 0.39.2 / bundled genlayer-js
• Fresh ephemeral wallet with balance 0 GEN
• Nonce preflight: latest=0, pending=0

Reproduction

1. Deploy contracts/ic_call_store_probe.py, a minimal contract with one string field and a public view read_it() method, using the SDK deployContract({ code, args: [hello] }) path.
2. Use the Studio Next endpoint above with chain ID explicitly corrected to 61997; no gas or fee override was supplied.
3. The SDK submission returned transaction hash 0xbd05c9232bd9c58a28a4e2f4cb1df5c232a632f477ce9665b2f65e0c3da4b9af.

Receipt response:

{
transactionHash: 0xbd05c9232bd9c58a28a4e2f4cb1df5c232a632f477ce9665b2f65e0c3da4b9af,
blockNumber: 0x0,
gasUsed: 0x0,
contractAddress: null,
status: 0x0,
revertReason: FeesDistributionMissing
}

The SDK also reported that the EVM transaction to consensus contract 0xb7278A61aa25c888815aFC32Ad3cC52fF24fE575 was reverted.

The same FeesDistributionMissing result was previously observed when attempting the much larger Governor source, so the failure is reproducible across contract sizes.

Separate network-preset issue

The SDK built-in studionet preset uses chain ID 61999 and https://studio.genlayer.com/api, while Studio Next reports chain ID 61997. The chain ID had to be corrected manually to reach the network.

Impact

This blocks deployment through the documented standard SDK path, including a minimal contract. It prevents builders from obtaining a Studio Next deployment link when the submission workflow requires one.

Question

What fee-distribution data is required for deployment, and what is the supported way to provide it through deployContract() or the CLI? Is there an updated network preset or documented deployment route for Studio Next?

[Snehal707]

Follow-up: deployment succeeded after resolving two separate compatibility issues.

1. Using genlayer-js v2-dev (2.0.0-rc.1), we passed the estimated distribution and feeValue explicitly through deployContract({ fees }). This resolved FeesDistributionMissing.

2. Execution then failed with invalid_contract runner malformed. The tested older runner IDs failed Studio Next's gen_getContractSchemaForCode check. Using the pinned runner from Studio Next's own live hello-world example, together with its v0.3 header and Python import conventions, passed that check:

   py-genlayer:5jycge4q8k23462jtb0b9fyey1s9qz928sz2nbrd9mg4sxqg2qng
   

The probe subsequently finalized with FINISHED_WITH_RETURN, and its read method returned the expected constructor value. Adapted Stele Governor and VaultTwin contracts also deployed successfully.

Verified deployments on Studio Next, chain ID 61997:

• Probe — transaction 0xacc7139cba4a7fe8db465cd18f2c01dc8ac00578264bb3192fb996de2f61d41d.
• Governor — transaction 0x3281a406a15d318b7cbe576d5450146003fc76a69a307848609f092ac13110c2.
• VaultTwin — transaction 0x926d6423e026d2df51fb8f4c81ba5a6713ef5536e199afdb9577b632a8a3d3b4.

Please document how builders should discover the runner compatible with the currently deployed Studio Next runtime, alongside the matching SDK and fee flow. This hash worked for the tested deployment; it should not be treated as a permanent network default.

Verification scope: successful deployments and initial reads. Stele's full lifecycle has not yet been tested on these Studio Next instances.

This narrows the original report: the failure occurred with the tested published SDK path, not every possible deployment route. Also, stable studionet (61999) and Studio development preview (61997) are distinct environments; using the stable preset against the preview RPC was a configuration mismatch, not by itself evidence that the stable preset was incorrect.

[ygd58]

Traced FeesDistributionMissing as far as I could and hit a dead end I want to flag honestly rather than guess past.

What I checked

Searched genlayer-studio's current public Solidity source (hardhat/contracts/v2_contracts/) for the exact error name. It doesn't exist anywhere — the repo has a FeesDistribution struct (in IFeeManager.sol/FeeManager.sol/ConsensusMainWithFees.sol), but no FeesDistributionMissing custom error is defined in the checked-in contracts at all.

That means whatever's actually deployed on Studio Next (studio-dev.genlayer.com, chain 61997) is running a contract version ahead of — or different from — what's in this repo's main branch right now. I can't trace the actual revert condition without access to that specific deployment's source, which I don't have.

The separate chain-ID preset gap (confirmed, but not something I'm opening a fix for)

You're right that genlayer-js's built-in studionet preset is chainId: 61_999, and it correctly points at https://studio.genlayer.com/api (the older hosted Studio — I independently verified that endpoint reports 0xf22f = 61999 via eth_chainId while looking at a different issue earlier). So studionet isn't miscalibrated for its own target — there's just no preset at all yet for the newer Studio Next environment (chainId 61997, studio-dev.genlayer.com), which is why you had to hand-correct the chain ID to reach it. Worth a small PR to add a dedicated preset once Studio Next is far enough along to be worth naming/shipping as a stable target — happy to open one if/when there's a preferred name for it.

Net

The actual blocker (FeesDistributionMissing) needs someone with visibility into Studio Next's actual deployed consensus/fee-manager contracts to answer what data is missing and how to supply it — this looks like a server-side deployment/config gap on a pre-release environment, not something reachable from the client SDK side.