Aurafinance
Aurafinance vote locking assigned delegates voting weight from eligible AURA locks
Aurafinance vote locking used locked AURA to establish governance weight, with delegation accounting scheduled for the following epoch. A lock contributed to a newly selected delegate only when its unlock time extended beyond that epoch’s start. Selecting an address therefore didn’t activate its new weight immediately. Self-delegation and delegation to another address followed that timing rule in AuraLocker. These were legacy governance mechanics: Aura has entered its sunset, with pools in withdrawal-only mode and existing locker positions remaining withdrawable.
A changed delegate could appear in the stored selection before its newly assigned voting weight became active.
Delegate selection and a rejected repeat
A holder with an eligible AURA lock could delegate to themselves or another address. Both choices used the same expiry filter and epoch schedule in AuraLocker. Self-delegation kept that weight under the holder’s voting address.
AuraLocker rejected repeat selections with the message “Must choose new delegatee”. The call stopped before it changed the delegation mapping or emitted DelegateChanged, leaving the existing delegate in place.
If the stored address already matched the intended destination, another call added nothing. If a different delegate was intended, correcting the destination removed this particular rejection before a retry.
An accepted change updated delegates(account) and emitted DelegateChanged. Those records showed the address change; the upcoming-epoch checkpoint showed scheduled weight. A vote lookup could confirm active weight once that epoch began.
- Keep the existing selection when it already names the intended delegate.
- Choose a different address when the intended delegate has actually changed.
- Compare each lock’s unlock time with the next epoch’s start.
- Confirm the stored delegate and its upcoming-epoch checkpoint; check active weight after that epoch begins.
A successful address change could coexist with unchanged current-epoch weight. The stored selection identified the destination for the upcoming allocation.
When did a new delegate receive voting weight?
Newly assigned delegated weight took effect at the next epoch boundary in the legacy AuraLocker implementation. Its epoch length was seven days. The contract found the upcoming boundary by adding an epoch to the transaction timestamp, then rounding down to an epoch start. A transaction’s position within the current epoch therefore determined the remaining wait.
Locks expiring at or before the upcoming epoch’s start contributed no weight to the newly selected delegate. Longer-lasting locks contributed their recorded amounts. Changing delegates reduced the old delegate’s scheduled weight and increased the new delegate’s amount by the same eligible sum. The reassignment covered the eligible lock records that the account held.
Lock dates and the 16-week description
Each new lock received an unlock timestamp tied to an epoch start. In the legacy AuraLocker implementation, lockDuration equalled 17 seven-day epochs. The contract added that duration to the current epoch’s starting timestamp when it created the lock. It didn’t add it directly to the deposit timestamp. That formula produced a boundary-aligned expiry for each lock record.
Subtracting the deposit timestamp from that expiry gives a waiting period of more than 16 weeks and at most 17 weeks. Voting eligibility began at the following epoch boundary. Deposits in different epochs could create records with different expiry dates, while same-epoch deposits joined an existing record with the shared unlock time. The eligible delegated amount could therefore differ from the account’s total deposited AURA.
Checkpoint accounting and expiry deductions
Delegate checkpoints recorded vote amounts against epoch starts, and AuraLocker reused an upcoming-epoch checkpoint for further changes targeting that epoch. At later epochs, its vote lookup subtracted amounts whose locks had expired. Account-level locked-balance views and delegate-level vote views used different accounting. Several holders could select the same delegate, so its delegated weight didn’t have to equal its own deposited AURA. A stored checkpoint described its recorded epoch; a later lookup also accounted for intervening expiries.
Did delegation transfer locked AURA to the delegate?
Changing a delegate didn’t transfer the holder’s locked AURA to that address. The delegate method updated the selection, expiry allocations, and vote checkpoints. The holder retained the separate withdrawal entitlement. DelegateChanged also recorded the delegating address and both delegate addresses, exposing that address association in the event log.
Governance choices and Base delegation
Aura’s earlier governance used separate Snapshot spaces for improvement proposals and Balancer gauge votes. The improvement-proposal space covered Aura Improvement Proposals and Balancer Improvement Proposals, including protocol and treasury decisions. Gauge votes influenced where incentives flowed to Balancer pools. Their participation rules required delegation, with self-delegation permitted. Selecting a delegate assigned voting responsibility; the delegate call itself didn’t cast a proposal vote or choose a gauge.
Base vote locking followed different delegation controls after AIP-68. That route offered no delegation option for the general improvement-proposal space. For gauge votes, it encouraged delegation to an auto-voter. Users could override delegated votes, although votes cast that way could lack rewards on Base. Ethereum’s delegation controls therefore didn’t describe every network interface.
Shutdown and the vlAURA balance
Aura’s sunset moved its pools into withdrawal-only mode and left existing locker positions withdrawable. AuraLocker’s shutdown flag controlled whether its legacy deposit path accepted new locks. Setting that flag made the lock method reject deposits and enabled the emergency withdrawal path for existing locked principal.
Shutdown withdrawal differed from ordinary lock expiry. The emergency method required shutdown and a positive locked balance, and returned that recorded AURA without waiting for each lock’s scheduled expiry. This method skipped reward updates, so withdrawing principal didn’t settle a separate locker reward claim. The emergency method also bypassed delegate checkpoint updates, so withdrawing principal didn’t itself remove delegated weight before the recorded lock expiries.
vlAURA named the vote-locked governance balance. Its eligibility followed the lock records and applicable epoch, while the underlying deposited token remained AURA.
Aurafinance vote locking: what people ask
Could another address fund a vote lock for my account?
AuraLocker’s legacy lock method allowed a sender to fund a specified beneficiary’s lock while the locker accepted new deposits. The contract took AURA from the sender and recorded the lock under the beneficiary. Funding that deposit didn’t assign the sender voting authority over the recipient’s lock.
Was a new token approval necessary to change delegates?
The delegate method didn’t require a fresh AURA spending approval. It updated voting records without pulling tokens from the wallet. Approval applied to the separate deposit method, which transferred AURA into the locker. An existing token allowance therefore didn’t determine whether a delegate change satisfied its address and lock-record requirements.
Could I clear delegation by choosing the zero address?
AuraLocker rejected delegation to the zero address. Its delegate method required a nonzero destination, so the empty address wasn’t a supported way to clear the selection. Self-delegation could keep eligible voting weight assigned to the holder’s own address, subject to the same next-epoch timing.
Did additional AURA follow an account’s existing delegate?
A new lock for an already delegated account followed that account’s stored delegate in the legacy implementation. The lock method added the amount to the delegate’s expiry allocation and updated the upcoming-epoch checkpoint. This branch required a nonzero stored delegate and a locker that accepted new locks.
How many delegates could one account select at a time?
AuraLocker stored one delegate selection per account and reassigned all locks eligible for the upcoming epoch to that destination. The method didn’t accept per-lock destinations or percentage splits. Several holders could select the same delegate, which differed from dividing one holder’s voting weight.
Did getPastVotes expect a timestamp or a block number?
The legacy AuraLocker method getPastVotes expected a timestamp, not a block number. It mapped that time to an epoch and rejected timestamps later than the current block timestamp.
Would changing a delegate restart a lock’s expiry period?
Changing a delegate didn’t restart the AURA lock period. The delegate method read existing lock records and moved eligible voting allocations; it didn’t rewrite their unlock timestamps. Relocking was a separate operation that created a new scheduled lock, where the locker permitted it.