Solana merged SIMD-0392 and SIMD-0123, a consensus-level protocol change that adjusts stake delegations during the rewards payout process to properly account for rent deductions — fixing a long-standing edge case in how effective stake is calculated.

> impact

**What changed:** SIMD-0392 and SIMD-0123 have been merged into the Solana protocol, introducing a precise adjustment to how stake delegations are handled during the epoch rewards payout phase. Previously, when rent was deducted from a stake account, the effective delegation amount used for rewards calculation could become inconsistent with the account's actual lamport balance. The merged implementation now reconciles the stake delegation with the post-rent balance *before* rewards are distributed, ensuring the effective stake accurately reflects the real capital at risk. **Why it matters:** This is a consensus-level change — meaning every validator on the network will enforce this new logic once the feature is activated. The prior behavior created a subtle discrepancy: a stake account could have rent deducted from its lamport balance while its `stake.delegation.stake` field still reflected the pre-rent amount. This meant validators could, in edge cases, earn rewards on phantom stake — lamports that had already been consumed by rent. While the per-account impact was small, across the network and over many epochs, these rounding errors compound. Correcting this tightens the integrity of Solana's Proof-of-Stake economics and ensures reward distributions are mathematically consistent with actual delegated capital. **Impact on developers and validators:** For most application developers, this change is transparent — it lives below the application layer. However, **validator operators**, **staking infrastructure providers**, and anyone building **custom rewards tracking or staking analytics** should take note. Effective stake values returned by `getStakeActivation` and account data deserialization may now differ slightly from pre-activation behavior for accounts where rent was deducted. If you maintain off-chain systems that mirror on-chain stake state (dashboards, reward estimators, MEV-aware delegation strategies), you should audit your logic to ensure it accounts for rent-adjusted delegations. LST (liquid staking token) protocols that compute share prices based on aggregate stake should verify their reward accounting remains accurate post-activation.

> Try this now

try this

# Walkthrough: Inspecting how rent-adjusted stake delegations affect your accounts
# This isn't new API surface — it's a change in on-chain behavior. Here's how to observe it.

# 1. Fetch a stake account and inspect the delegation vs. lamport balance
# Using @solana/web3.js v2 (or v1 — the concept is identical)

import { Connection, PublicKey } from '@solana/web3.js';
import { StakeProgram } from '@solana/web3.js';

const connection = new Connection('https://api.mainnet-beta.solana.com');
const stakeAccountPubkey = new PublicKey('YOUR_STAKE_ACCOUNT_ADDRESS');

# 2. Get the parsed stake account data
const accountInfo = await connection.getParsedAccountInfo(stakeAccountPubkey);
const parsedData = accountInfo.value?.data?.parsed;

# 3. Compare delegation stake vs. actual lamports
# Pre-SIMD-0392: these could diverge after rent deduction
# Post-SIMD-0392: delegation.stake is adjusted downward to match post-rent balance
const delegationStake = parsedData?.info?.stake?.delegation?.stake; // in lamports
const accountLamports = accountInfo.value?.lamports;
const rentExemptMin = await connection.getMinimumBalanceForRentExemption(
  StakeProgram.space
);

console.log(`Delegation stake:  ${delegationStake}`);
console.log(`Account lamports:  ${accountLamports}`);
console.log(`Rent-exempt min:   ${rentExemptMin}`);
console.log(`Non-stake balance: ${accountLamports - delegationStake}`);

# 4. For validator operators / staking infra:
# If you track effective stake per epoch for reward estimation,
# ensure your snapshots are taken AFTER rewards distribution completes.
# The rewards payout now internally adjusts delegation before calculating payouts.

# 5. For analytics / LST protocols:
# Verify that your reward-per-epoch calculation accounts for the possibility
# that delegation.stake < previous_delegation.stake even without an explicit
# deactivation — rent adjustment is now a valid cause of delegation decrease.

# Key RPC calls to audit your integration:
# - getStakeActivation(pubkey)  → effective stake may be slightly lower
# - getInflationReward([pubkey]) → rewards now computed on rent-adjusted stake
# - getAccountInfo(pubkey) → delegation.stake field reflects post-rent value