---
title: "Consensus v0.6 Migration"
description: "Migrate applications and tooling to the Consensus v0.6 and Studio v0.123 release family."
source: https://docs.genlayer.com/developers/consensus-v06-migration
last_updated: 2026-09-03
---

# 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

| Component | v0.6 release family |
|:--|:--|
| Consensus contracts and GenLayer Node | v0.6 RC |
| GenLayer Studio | v0.123 RC |
| `genlayer-js` | v2.0 RC |
| `genlayer-py` | v0.19 RC |
| GenLayer CLI | v0.40 RC |
| Transaction Kit and `gltest` fee profiles | matching v0.6-compatible prerelease |

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](https://studio-dev.genlayer.com), 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](/developers/decentralized-applications/fees-and-transaction-kit) and [Fee Profiling & Estimation](/developers/decentralized-applications/fee-profiling-and-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:

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

```python
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](/developers/error-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.

> **Warning:**
> Studio-dev is a release-candidate environment and may reset. Move durable production-like testing to Bradbury only after the compatible v0.6 stack has been promoted there.