Repository navigation
Studio Next deployment fails with FeesDistributionMissing for any contract via standard SDK path #421
Description
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
- 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.
- Use the Studio Next endpoint above with chain ID explicitly corrected to 61997; no gas or fee override was supplied.
- 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?
Activity
Snehal707 commentedon Sep 17, 2026
Follow-up: deployment succeeded after resolving two separate compatibility issues.
Using genlayer-js v2-dev (2.0.0-rc.1), we passed the estimated
distributionandfeeValueexplicitly throughdeployContract({ fees }). This resolvedFeesDistributionMissing.Execution then failed with
invalid_contract runner malformed. The tested older runner IDs failed Studio Next'sgen_getContractSchemaForCodecheck. 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: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:
0xacc7139cba4a7fe8db465cd18f2c01dc8ac00578264bb3192fb996de2f61d41d.0x3281a406a15d318b7cbe576d5450146003fc76a69a307848609f092ac13110c2.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 commentedon Sep 27, 2026
Traced
FeesDistributionMissingas 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 aFeesDistributionstruct (inIFeeManager.sol/FeeManager.sol/ConsensusMainWithFees.sol), but noFeesDistributionMissingcustom 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'smainbranch 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-instudionetpreset ischainId: 61_999, and it correctly points athttps://studio.genlayer.com/api(the older hosted Studio — I independently verified that endpoint reports0xf22f= 61999 viaeth_chainIdwhile looking at a different issue earlier). Sostudionetisn'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.