AerodromefinanceAerodromefinance voting windows for changing veAERO pool allocations
Aerodromefinance voting permits one ordinary pool-allocation vote per veAERO lock in each weekly epoch. Its ordinary window runs after Thursday 01:00 UTC through Wednesday 23:00 UTC. An earlier vote or managed deposit in that epoch blocks another ordinary vote, while a weight refresh preserves existing pool choices.
In short: A weight refresh updates an existing allocation during an eligible window without allowing the lock to select different pools.
veAERO Locks Connect Pool Choices to Gauge Emissions
A veAERO lock supplies voting power that the Voter contract assigns to selected liquidity pools on Base. The lock is an ERC-721 non-fungible token, also called a veNFT. AERO held outside a lock does not supply this pool-voting power. Each lock has its own epoch record, so separate locks have separate voting eligibility.
The Voter records allocations against the lock’s tokenId and maps each selected pool to its gauge. Gauges distribute AERO emissions to eligible staked liquidity. The lock’s pool votes influence the distribution of those emissions. Fee rewards and external voting incentives follow their own reward contracts. Changing pool choices therefore affects both emission allocation and the pools whose voting rewards the lock participates in.
When Can You Change a veAERO Vote?
A lock can submit a replacement allocation when its last vote or managed deposit predates the current epoch and the relevant voting window is open. The restriction follows an epoch boundary, not a rolling wait measured from the previous transaction.
The Weekly Boundary
A 7-day epoch begins on Thursday at 00:00 UTC. The ordinary pool-voting window runs strictly after Thursday 01:00 UTC through Wednesday 23:00 UTC. The contract evaluates the transaction’s block timestamp, so signing or submitting before a cutoff does not establish timely execution.
Operation-Specific Boundary Rules
The Opening Distribution Hour
The Voter blocks votes, resets, weight refreshes, managed deposits, and managed withdrawals during the opening distribution window. The check also rejects these operations at exactly Thursday 01:00 UTC. Execution must occur after that boundary.
The Closing Restricted Hour
Direct voting after Wednesday 23:00 UTC requires the particular veNFT to be whitelisted. That exception retains the same-epoch restriction. Managed deposits remain closed during this final hour. Resets and weight refreshes do not share the final-hour whitelist restriction, although their other requirements still apply.
Can a Reset Reopen a Vote in the Same Epoch?
A reset cannot reopen an ordinary lock that has already voted or entered a managed position during the current epoch. The reset function itself checks that the recorded action belongs to an earlier epoch. It cannot erase a current-epoch vote to make another pool choice available.
An eligible reset clears the existing allocation without updating the lock’s lastVoted timestamp. A subsequent vote remains possible within the applicable window.
A replacement vote already clears previous pool selections internally. A separate reset is therefore unnecessary solely to replace an eligible allocation. Clearing votes also leaves the underlying AERO lock in place; its duration and withdrawal conditions remain separate.
Weight Refreshes Preserve Existing Pool Choices
The poke operation updates an existing allocation using the lock’s available voting power while retaining its selected pools and relative weights. Adding AERO to an eligible lock can increase that power. A timed lock’s voting power also declines as its remaining duration shortens. Permanent locks do not have that time decay.
Unchanged pool selections carry into the following epoch. Their recorded reward balances do not automatically track every change in voting power. A refresh updates those balances without providing a new selection of pools. It does not update lastVoted or consume the ordinary new-vote opportunity. The opening distribution window still blocks it, and the selected gauges must satisfy the allocation checks.
Pool Vote Shares Determine Voting Rewards
Voting rewards come from fees assigned to a pool’s voters and external incentives deposited for that pool. These rewards differ from the AERO emissions that its gauge distributes to staked liquidity. Fee rewards retain their underlying token identities, while external incentives use accepted reward tokens. Selecting a pool does not establish a fixed reward amount.
A lock’s voting rewards are proportional to its recorded share of the selected pool’s total voting weight. The reward contract uses the last applicable balance and total-supply checkpoints for each completed epoch. It applies that share separately to each reward token’s deposited amount. Further votes and reward deposits can change the eventual entitlement while the epoch remains open. Rewards assigned to that voting epoch become claimable after the next epoch begins.
Managed Deposits Change Which NFT Casts the Votes
A normal veNFT deposited into a managed veNFT contributes its locked balance to that aggregate position. Its individual escrow state becomes LOCKED, and the managed NFT supplies the combined pool-voting power. The depositor’s NFT no longer represents an independently available allocation of that deposited balance.
Voting directly and depositing into a managed NFT share the same per-epoch eligibility record. A lock cannot perform both during one epoch. Managed deposits also require an active destination and remain unavailable in the final restricted hour, even for a whitelisted NFT.
Managed withdrawal requires an epoch later than the deposit and the end of the opening distribution window. The returned NFT regains individual voting control, subject to ordinary vote eligibility. Its AERO remains locked; the protocol sets a fresh maximum-duration expiry rounded down to a weekly boundary.
If a withdrawal reduces the managed NFT’s voting power to zero, the Voter clears that NFT’s allocation and lastVoted record. A later eligible deposit can then allow the aggregate to vote again within the same epoch’s applicable window. The exception belongs to the managed NFT whose voting power reached zero. The withdrawing lock keeps its own epoch record.
A Replacement Allocation After an Epoch Change
In this hypothetical example, a normal veAERO lock remains outside a managed position. Its owner wants different pool choices. Its previous vote belongs to the preceding epoch, its voting power is positive, and every proposed pool has a live gauge. The ordinary voting window is open. The proposed pool list contains no duplicates and stays within the pool-count limit. Its weight list has the same length and yields positive computed voting weight for every selected pool.
The owner first compares lastVoted with the current epoch’s start. The earlier record satisfies the new-epoch requirement. A direct vote can then replace the old allocation without a separate reset. After successful execution, the stored pool selections and per-pool weights reflect the replacement.
The updated lastVoted record now falls within the current epoch. Those stored allocations establish the change; a wallet signature alone does not. The lock has used its ordinary vote for this epoch, so another pool-selection change must await a later eligible window.
Pool Eligibility Constrains Replacement Allocations
A replacement allocation requires a registered, live gauge for every selected pool and positive computed voting weight for each entry. Duplicate pool entries can also invalidate a vote. A very small relative allocation can round down to zero, even when the lock has positive total voting power. An open time window does not override these requirements.
An invalid pool or zero-weight entry reverts the allocation. The previous on-chain choices remain in place after a reverted vote.
What to know about Aerodromefinance voting
Can an Approved Operator Cast Pool Votes for My veAERO NFT?
An approved operator can cast pool votes for a veAERO NFT under the Voter contract’s ownership-or-approval check. Approval does not bypass epoch eligibility, voting windows, or pool requirements. For direct pool-voting rewards, the reward contract sends claimed tokens to the NFT’s owner, including when an authorized operator initiates the claim.
Does Transferring a veAERO NFT Reset Its Epoch Restriction?
Transferring a veAERO NFT does not clear the Voter’s lastVoted record for that tokenId. The recipient inherits its existing epoch eligibility. VotingEscrow also reports zero voting power for an NFT during the block in which ownership changes, so an otherwise eligible transfer does not establish immediately usable voting power in that block.
How Does the Voter Handle Allocations Below 100%?
The Voter normalizes submitted relative weights across the selected pools, using the lock’s available voting power. Leaving the entered percentages below 100% therefore does not reserve the remainder as unused power. The allocation follows each entered weight divided by their sum, subject to integer rounding and the requirement for positive computed weights.
Which Setting Limits the Number of Pools in One Vote?
The Voter’s maxVotingNum setting limits the number of pool entries in a vote. The governor can change that setting, so a deployment’s initial value should not be treated as a permanent limit. The pool list and weight list must also contain matching numbers of entries.
Are Pool Allocations Also Votes on Protocol Governance Proposals?
Pool allocations do not cast votes on protocol governance proposals. The Voter handles pool choices and gauge emissions, while ProtocolGovernor handles protocol proposals. EpochGovernor has a separate role in adjusting emissions once the Minter’s tail-emission regime applies. These mechanisms use veNFT voting power for different decisions.