Consensus v0.6 Migration

Consensus v0.6 introduces the complete fee-funded transaction lifecycle used by Studio v0.123. Applications should upgrade Studio, node, SDK, CLI, and fee-profile tooling as one compatible release family rather than mixing release-candidate and stable components.

Compatible release lines

Use the exact versions published in the release notes. Prerelease package tags must be installed explicitly; do not assume an npm or container latest tag resolves to the RC.

Test on Studio-dev first

The release-candidate stack is deployed at studio-dev.genlayer.com (opens in a new tab), with canonical RPC https://studio-dev.genlayer.com/api and chain ID 61997. It is separate from stable Studionet (61999).

Use the JavaScript studioDevnet definition or CLI studio-dev alias supplied by the matching RC. Do not point the stable studionet chain object at the preview RPC: chain identity and consensus contract addresses must move together.

Migrate fee submission

On a fee-charging deployment, every deploy and write must carry a FeesDistribution and its quoted fee value. The recommended path is:

1. exercise representative contract branches in tests;
2. generate and commit a fee-profile.json with gltest --fee-profile;
3. convert the selected profile entry into live estimate options;
4. read current network prices and caps through the SDK estimate; and
5. submit the returned distribution and feeValue unchanged.

The deposit covers consensus time units, execution, child messages, and the chosen appeal/rotation posture. Unused fee budget is refunded at finalization. A Studio deployment can be gasless; detect that from the estimate result rather than from its network name.

See Fees & Transaction Policy and Fee Profiling & Estimation.

Migrate appeals

The authoritative appeal quote contains both the bond and funding for the work induced by the next round. Use the high-level appeal operation and let it bind the active decision:

const charge = await client.getAppealCharge({ txId });
await client.appealTransaction({ txId, value: charge });

charge = client.get_appeal_charge(tx_id)
client.appeal_transaction(tx_id, value=charge)

Both public operations use topUpAndSubmitAppeal. Direct submitAppeal is only suitable for explicit low-level conformance against a next round that is already funded; an ordinary unfunded appeal can otherwise revert with AppealRoundNotPermitted.

A successful appeal returns the bond principal plus profit equal to 1.5× the bond, for 2.5× the bond in total. The induced-work funding is not part of the multiplied reward.

Read status and execution together

An accepted or finalized status does not by itself prove successful contract execution. Treat a transaction as successful only when:

• its status is ACCEPTED or FINALIZED; and
• its execution result is FINISHED_WITH_RETURN.

Use the SDK's isSuccessful helper or Transaction Kit's normalized outcome. Track until finalization when the UI needs exact fee consumption and refunds.

Other protocol-visible changes

• Randomness: validator seed advances use ECVRF proofs bound to the registered operator public key and a per-recipient domain-separated seed chain.
• Tribunals: the electorate and quorum are frozen at creation, consequence processing is bounded and retryable, and a majority-disagree verdict wires the convicted leader into the staking judicial restriction.
• Developer rewards: the first deployment mints one Developer NFT, and later contracts from the same developer are attached to it. One claim processes at most 50 inflation epochs.
• Error decoding: the v0.6 snapshot exposes 363 unique custom-error selectors; use the Error & Revert Reference with the ABI from the deployment you are calling.

Application checklist

• Install one coherent RC set and lock it in the package and deployment manifests.
• Use studioDevnet / studio-dev for the preview and studionet only for stable Studio.
• Replace hand-built fee arithmetic with an SDK estimate generated from a measured profile.
• Cover every message-emitting and materially expensive branch in profile tests.
• Replace direct public submitAppeal calls with appealTransaction / appeal_transaction.
• Display deposit, consumed fees, and final refund as different values.
• Require both successful status and execution result before showing an application action as complete.
• Re-run profile tests whenever contract code, GenVM, Studio, or the fee policy changes.