fix: ensure consistent ordering for pagination#492
Open
Conversation
## Description Skipping `should process blocks` test due to holesky deprecation and hoodi/sepolia doesn't have `RewardsClaimed` event yet. ## Type of change - [x] Chore (non-breaking change which does not add functionality) ## How Has This Been Tested? Passing CI test. ## Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [x] Any dependent changes have been merged and published in downstream modules - [x] I have checked my code and corrected any misspellings
## Description ### Testnet Hoodi Upgrades existing contracts (adds new implementation addresses): ``` DelegationManager: 0x6fe5ebe3ed0f4b2419263868efb5cc640e541407 StrategyManager: 0xfc868562d93c4dc192419e970c220279cdab7b26 AVSDirectory: 0xe368218addc4d2ddc5b0afd70f5878dd8c1713eb AllocationManager: 0x4a3027fc3ae9593874123df96e21e89a698cd7d9 RewardsCoordinator: 0x4a93d276ea78b48be9d8bb864bacdd5d5a713084 EigenPodManager: 0x0f264e714a3c03309f4041db26229ef4e9b00f5c ``` Adds new contracts (both proxy and implementation): ``` ReleaseManager: proxy 0xe863060013cb95473b96f7c3e1444e3e3df65671, impl 0x7a2b8c559a8c8c71a9d364ad250fce5a24b18f5d CrossChainRegistry: proxy 0x9269432451965996be7796582c062cb0795d3e8b, impl 0x1bf65df60184a4a112742ce07f857739fedefbc0 OperatorTableUpdater: proxy 0xb02a15c6bd0882b35e9936a9579f35fb26e11476, impl 0x5dd026aa1c431858e439736d063111763243acae ECDSACertificateVerifier: proxy 0xb3cd1a457dea9a9a6f6406c6419b1c326670a96f, impl 0xe867777f7c45cf6af9b08c7ad62b37c1be61dd25 BN254CertificateVerifier: proxy 0xff58a373c18268f483c1f5ca03cf885c0c43373a, impl 0xe5d02648ddd59ba688846fb5d01f738da6c1ffcb TaskMailbox: proxy 0xb99cc53e8db7018f557606c2a5b066527bf96b26, impl 0xda35d6af400ef38e91bf3eb6c57d9e8d1bf35e36 ``` ### Testnet Sepolia Same contracts upgraded + adding missing KeyRegistrar contract ## Type of change - [x] New feature (non-breaking change which adds functionality) ## 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: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [x] Any dependent changes have been merged and published in downstream modules - [x] I have checked my code and corrected any misspellings
fix test fix time to utc fix time time utc fix fix
#474) ## Description ### 1. Database Migration (`202511141700_withdrawalQueueAndAllocationRounding`) - Enhanced `queued_slashing_withdrawals` table with timing columns for 14-day withdrawal tracking: - `completed`, `completion_*` - Completion tracking - Enhanced `operator_allocations` table with rounding support: - `effective_date` - Rounded date when allocation/deallocation takes effect ### 2. Allocation/Deallocation Rounding Logic (Sabine Fork) Implements day-boundary rounding to prevent gaming and mimic existing registration behavior: - **Allocations (increases)**: Round **UP** to next day → starts earning tomorrow - **Deallocations (decreases)**: Round **DOWN** to current day → stops earning immediately - **No change**: Round **DOWN** to current day (conservative default) ### 3. Dual Behavior Implementation Maintains backward compatibility with fork-based behavior switching: - **Before Sabine fork**: Uses old behavior (no rounding, date fields are NULL) - **After Sabine fork**: Applies rounding logic and populates date fields - Model continues processing allocations from Brazos fork onwards ## Type of change - [x] New feature (non-breaking change which adds functionality) ## How Has This Been Tested? Unit tests ## Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [x] Any dependent changes have been merged and published in downstream modules - [x] I have checked my code and corrected any misspellings
…ion (#488) ## Description sidecar was crashing with this error: ``` pq: unsupported Unicode escape sequence ``` the issue is smart contracts can emit Solidity strings containing null bytes (`\u0000`), which are valid in Solidity but not supported by PostgreSQL in text/varchar columns. ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) ## How Has This Been Tested? Unit tests ## Checklist: - [x] My code follows the style guidelines of this project - [x] 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
…ation (#476) ## Description ### Problem Operators were not earning rewards during the deallocation queue period, even though their allocations remain at risk until the `effective_date`. **Current behavior:** - Operator deallocates 100 from allocation on Day 1 (effective_date = Day 15) - `operator_allocations` table immediately shows reduced allocation - Rewards calculation uses reduced amount → ❌ Operator loses 14 days of rewards **Expected behavior:** - Operator should continue earning on OLD (higher) allocation until `effective_date` - After `effective_date`, earn on NEW (lower) allocation ### Solution **Deallocation Queue Adjustment**: Added `AdjustOperatorShareSnapshotsForDeallocationQueue()` function that: 1. Reads `magnitude_decrease` from `deallocation_queue_snapshots` 2. Aggregates across all AVSs per (operator, strategy) 3. Adds the decrease back to `operator_share_snapshots` during queue period This mirrors the existing withdrawal queue adjustment for stakers. **Operator Allocation Snapshots**: New operatorAllocationSnapshots.go generates daily snapshots with allocation rounding: - Allocations round UP to next day (allocation @ 5pm on 1/4 → starts 1/5) - Deallocations round DOWN to previous day (deallocation @ 5pm on 1/4, effective 1/18 → reduced allocation starts 1/17) - Tracks max_magnitude for slashable stake calculations **Gold Tables 15-17 (Unique Stake Rewards):** - Table 15: Operator rewards based on allocated magnitude - Table 16: Staker rewards (distributed from Table 15) - Table 17: AVS refunds for unallocated periods ### Changes - Added deallocationQueueShareSnapshots.go - deallocation queue adjustment - Added operatorAllocationSnapshots.go - allocation snapshot generation with rounding - Added Gold Tables 15-17 for unique stake reward distribution - Integrated into rewards calculation pipeline in rewards.go - Migration: 202511141700_withdrawalQueueAndAllocationRounding - creates operator_allocation_snapshots table ## Type of change - [x] New feature (non-breaking change which adds functionality) ## How Has This Been Tested? ## Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [x] Any dependent changes have been merged and published in downstream modules - [x] I have checked my code and corrected any misspellings
allocate unique stake to operator set add more v2.2 tables fix function call clean v2.1 delete unused file implement total stake rewards
…al Stake (#481) ## Description Implements Rewards v2.2 - Operator Set rewards with automatic stake-weighted distribution for both unique allocated stake and total delegated stake. This brings forward-looking reward capabilities (up to 2 years) to operator sets managed via AllocationManager, closing the architectural gap where only AVSDirectory-based AVSs could create forward-looking rewards. ### Withdrawal Queue Integration (Sabine Fork) 14-day withdrawal delay now integrated into staker share snapshots: - Withdrawals queued on Day 1 → shares removed starting Day 15 - Slashing during queue period adjusts withdrawable amounts - Tracked via queued_slashing_withdrawals table - Migration: 202512101500_queuedWithdrawalSlashingAdjustments ### Unique Stake Rewards (Tables 15-17) Rewards based on allocated unique stake to operator sets: - Table 15: Operator rewards - calculates pro-rata distribution based on (shares × magnitude / max_magnitude) × multiplier - Table 16: Staker rewards - distributes staker portion from Table 15, respects withdrawal queue - Table 17: AVS refunds - refunds for operators without unique stake allocations ### Total Stake Rewards (Tables 18-20) Rewards based on total delegated stake (operator set analog to Rewards v1): - Table 18: Operator rewards - calculates pro-rata distribution based on shares × multiplier - Table 19: Staker rewards - distributes staker portion from Table 18, queue-aware - Table 20: AVS refunds - refunds for operators without sufficient total stake ### Refund Logic Tables 17 and 20 calculate separate refund buckets (not subtractions) for three scenarios: - Operators not registered to operator set - Operators registered but without required stake (unique stake for 15-17, total stake for 18-20) - Operators with stake but strategies not registered These refunds are tracked separately and combined in final staging tables (Table 21). ### Slashable Period Tracking Enhanced operatorSetOperatorRegistrationSnapshots to track slashable_until: - Operators remain in snapshots until deregistration + 14 days - Ensures correct reward distribution during post-deregistration slashable period - Migration: 202512160000_addSlashableUntilToOperatorRegistrationSnapshots ## Type of change - [x] New feature (non-breaking change which adds functionality) ## How Has This Been Tested? Integration testing ## Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [x] Any dependent changes have been merged and published in downstream modules - [x] I have checked my code and corrected any misspellings
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Ensure consistent ordering of query results for pagination
Fixes # (issue)
Type of change
Please delete options that are not relevant.
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: