fix: rewards v2.2 audit fixes by serichoi65 · Pull Request #494 · Layr-Labs/sidecar

serichoi65 · 2026-01-22T17:52:07Z

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Checklist:

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published in downstream modules
I have checked my code and corrected any misspellings

…in support

…lia rewardsCoordinator and StrategyManager

- Table 17/20: evaluate refunds per operator-set/operator, not per-snapshot - operatorShareSnapshots: apply allocations to all backfill days, include cutoff snapshot

- stakerShareSnapshots: Add '+ INTERVAL 1 day' to end_time calculation to include cutoff date snapshot (matches operatorShareSnapshots fix) - 15_goldOperatorOperatorSetUniqueStakeRewards: Fix deregistration queue check to only flag the 14-day window AFTER deregistration, not the entire period from registration to slashable_until

ypatil12 · 2026-01-22T21:21:07Z

pkg/eigenState/precommitProcessors/slashingProcessor/slashing.go

@@ -173,8 +185,9 @@ func (sp *SlashingProcessor) createSlashingAdjustments(slashEvent *SlashingEvent
 			@logIndex as log_index
 		FROM queued_slashing_withdrawals qsw


So we're selecting from queued_slashing_withdrawals, but that hasn't been committed yet. Thus, we could have a lag for slashes that occur in the same block as a queued withdrawal. The reason the tests pass is that they insert the slash into the queued withdrawal table (fine for tests, but doesn't match how this works E2E).

Comment from other PR:

Since this query is selecting from queued_slashing_withdrawal table, which hasn't been committed yet (ie. latest block not updated), could we have a staleness issue? Edge case: a withdrawal has been queued in this block and then we are slashed a couple times in the same block.

We'll need to get the accumulator for withdrawals that occurred in this given block

For a regression, what we can do is something like:

return sharesModel.HandleStateChange(&beaconChainSlashingFactorDecreasedLog)

Since the handleStateChange is called prior to committing the final state to the DB.

Just flagging this @serichoi65

ypatil12 · 2026-01-22T21:30:29Z

pkg/eigenState/precommitProcessors/slashingProcessor/slashing_test.go

+}
+
+func insertQueuedWithdrawalWithLogIndex(t *testing.T, grm *gorm.DB, staker, operator, strategy string, blockNumber uint64, logIndex uint64, shares string) {
+	res := grm.Exec(`


I realized inserting this directly is causing us to miss the edge case of a withdrawal and a slash in the same block. In this case, queued_slashing_withdrawals won't have its state committed yet and db won't be up to date. For this edge case of a withdrawal and slash in the same block, we should do something like:

return sharesModel.HandleStateChange(&beaconChainSlashingFactorDecreasedLog)

And then use the accumulator in slashing.go

ypatil12 · 2026-01-22T21:32:00Z

pkg/eigenState/precommitProcessors/slashingProcessor/slashing_test.go

+	t.Run("CSA-3: Same-block event ordering", func(t *testing.T) {
+		cleanupCSATest(t, grm)
+
+		// Setup: Staker queues withdrawal on block 1000, log_index 2


Ordering reversed here, we want to queue withdrawal (early log index) then slash (later log index) per test plan

This is the edge case for the accumulator

Added as a new test case.

…ares - Remove FULL OUTER JOIN with operator_allocation_snapshots from query - operator_share_snapshots now contains only raw shares from operator_shares - Allocation magnitudes are stored separately in operator_allocation_snapshots - Table 15/18 rewards calculations join both tables as needed: allocated_stake = shares * magnitude / max_magnitude - This removes the dependency on operator_allocation_snapshots being generated before operator_share_snapshots

…tion_records

pkg/eigenState/totalStakeRewardSubmissions/totalStakeRewardSubmissions.go

pkg/eigenState/uniqueStakeRewardSubmissions/uniqueStakeRewardSubmissions.go

…distribution Implement support for UniqueStakeRewardsSubmissionCreated and TotalStakeRewardsSubmissionCreated events with pro-rata distribution across operators. Changes: - Add migration for unique_stake_reward_submissions and total_stake_reward_submissions tables - Create eigenState models for stake-based reward submission events - Add stake_operator_set_rewards denormalized table - Rename Tables 15-21 to 16-22 to accommodate new table - Add Table 15 (ActiveUniqueAndTotalStakeRewards) as source for unique/total stake calculations - Update Tables 16 and 19 to support both OD rewards (per-operator amounts) and stake rewards (pro-rata by operator weight)

pkg/rewards/rewards.go

ypatil12

Notes on table 16

pkg/rewards/15_goldActiveUniqueAndTotalStakeRewards.go

ypatil12 · 2026-01-28T16:09:23Z

pkg/rewards/16_goldOperatorOperatorSetUniqueStakeRewards.go

+const _16_goldOperatorOperatorSetUniqueStakeRewardsQuery = `
+CREATE TABLE {{.destTableName}} AS
+
+-- ============================================================================


Part 1 here doesn't make sense - we are taking active rewards from table 11, but it should be taken from table 15. This query should start from step 2 (it seems like we're doing the same thing in step 1 and step 2)

pkg/rewards/16_goldOperatorOperatorSetUniqueStakeRewards.go

ypatil12 · 2026-01-28T16:47:32Z

pkg/rewards/16_goldOperatorOperatorSetUniqueStakeRewards.go

+        pow.avs, pow.operator_set_id, pow.operator, pow.strategy, pow.multiplier,
+        pow.reward_submission_date, pow.registration_snapshot, pow.slashable_until,
+        pow.operator_allocated_weight,
+        'stake' as reward_source


What is the purpose of reward_source?

Irrelevant after removing Part 1.

ypatil12 · 2026-01-28T17:11:28Z

pkg/rewards/16_goldOperatorOperatorSetUniqueStakeRewards.go

+    FROM combined_operators
+),
+
+-- Common Step 2: Calculate cumulative slash multiplier during deregistration queue


When an operator is slashed, we already decrement their shares. The deregistration queue doesn't need to be factored here - this should already be taken care of in operator registration snapshots (via the slashable_until parameter).

The key issue to solve for is not accounting for queued withdrawals for an operator:

Operator has a staker, Alice. Alice has 500 shares

Alice queues a withdrawal for 200 shares. The operator now has 300 shares. But, we want the operator to have 500 shares!

How do we ensure that the queued withdrawal for Alice is counted in the operator shares? Here is the discrepancy: Operator shares are decremented immediately when a withdrawal is queued. Therefore, the number of shares an operator has does not handle the queued withdrawal adjustments. To fix, one option there is to add these shares back into operator_share_snapshots, like we do for staker shares.

OD rewards are operator-directed with staker distribution handled by staker share snapshots. Removes duplicate processing and reward_source column.

elhajin · 2026-02-02T15:20:51Z

pkg/eigenState/queuedSlashingWithdrawals/queuedSlashingWithdrawals.go

 				Withdrawer:       strings.ToLower(outputData.Withdrawal.Withdrawer),
 				Nonce:            outputData.Withdrawal.Nonce.String(),
 				StartBlock:       outputData.Withdrawal.StartBlock,
 				Strategy:         strategy,


Strategy is stored without strings.ToLower() here, the slashing adjustment query joins on qsw.strategy = @strategy ,if the original event had mixed-case, the join silently fails and no adjustments are created.

should lowercase the strategy here

serichoi65 requested a review from a team as a code owner January 22, 2026 17:52

serichoi65 requested review from 0xrajath and seanmcgary January 22, 2026 17:52

serichoi65 mentioned this pull request Jan 22, 2026

chore: add rewards v2.2 comprehensive unit/integration/Anvil tests #490

Merged

11 tasks

serichoi65 added 6 commits January 22, 2026 13:59

use SlashingAccumulator for real-time slash events and add beacon cha…

6615862

…in support

remove unused var

8fa5cda

fix: compute staker split from slashing-adjusted base in Table 16

8fd126c

add a migration to upgrade preprod-hoodi, testnet-hoodi, testnet-sepo…

0a773a4

…lia rewardsCoordinator and StrategyManager

fix(rewards): address v2.2 audit findings

0d2fd48

- Table 17/20: evaluate refunds per operator-set/operator, not per-snapshot - operatorShareSnapshots: apply allocations to all backfill days, include cutoff snapshot

fix queued_withdrawal_slashing_adjustments primary key and CSA tests

28444d2

serichoi65 force-pushed the seri.choi/rewards-audit-fixes branch from 2a4cc2b to 28444d2 Compare January 22, 2026 18:59

serichoi65 force-pushed the seri.choi/rewards-audit-fixes branch from 33f9055 to a36a9cc Compare January 22, 2026 19:07

ypatil12 reviewed Jan 22, 2026

View reviewed changes

serichoi65 added 3 commits January 23, 2026 13:13

fix: process queued withdrawal slashing regardless of delegation changes

c0a1de0

fix: prevent reward gaming via stale allocation data in ranked_alloca…

d9f5fa4

…tion_records

serichoi65 force-pushed the seri.choi/rewards-audit-fixes branch 3 times, most recently from c419fde to 9e7094c Compare January 26, 2026 16:11

elhajin requested changes Jan 26, 2026

View reviewed changes

pkg/eigenState/totalStakeRewardSubmissions/totalStakeRewardSubmissions.go Outdated Show resolved Hide resolved

pkg/eigenState/uniqueStakeRewardSubmissions/uniqueStakeRewardSubmissions.go Outdated Show resolved Hide resolved

serichoi65 force-pushed the seri.choi/rewards-audit-fixes branch 3 times, most recently from a53235b to 0f4188d Compare January 26, 2026 18:29

serichoi65 force-pushed the seri.choi/rewards-audit-fixes branch from 0f4188d to ffcbafb Compare January 26, 2026 18:39

staker AND operator distributed tokens for refund

ce639eb

elhajin reviewed Jan 27, 2026

View reviewed changes

pkg/rewards/rewards.go Outdated Show resolved Hide resolved

ypatil12 reviewed Jan 28, 2026

View reviewed changes

fix slashing processor same block edge case

30c444f

add shares back into operator_share_snapshots, like for staker shares

2ab53ed

serichoi65 force-pushed the seri.choi/rewards-audit-fixes branch from 86a36ea to 2ab53ed Compare January 28, 2026 21:35

Remove redundant OD rewards path from tables 16/19

10ec46e

OD rewards are operator-directed with staker distribution handled by staker share snapshots. Removes duplicate processing and reward_source column.

seanmcgary force-pushed the master branch from f995246 to 1093849 Compare January 30, 2026 17:18

elhajin reviewed Feb 2, 2026

View reviewed changes

serichoi65 changed the base branch from master to release/rewards-v2.2 February 5, 2026 14:24

		@@ -173,8 +185,9 @@ func (sp SlashingProcessor) createSlashingAdjustments(slashEvent SlashingEvent
		@logIndex as log_index
		FROM queued_slashing_withdrawals qsw

Conversation

serichoi65 commented Jan 22, 2026

Description

Type of change

How Has This Been Tested?

Checklist:

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ypatil12 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ypatil12 Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ypatil12 Jan 28, 2026 •

edited

Loading