Convexfinance
Convexfinance vote locking gives new deposits voting power in the next epoch
Convexfinance vote locking activates fresh CVX deposits for voting at the next weekly epoch. A confirmed lock can therefore appear in the account while its current voting weight remains zero. Epochs begin on Thursday at 00:00 UTC, and a particular proposal also depends on its eligibility epoch. Check whether the recorded deposit is awaiting activation, became eligible too late for the selected proposal, or needs further investigation because the voting records disagree.
Key takeaway: A confirmed CVX deposit can remain pending for voting, and each proposal uses the balance eligible for its own epoch.
A recorded lock with zero current weight
A pending lock is an expected contract state after a fresh deposit. The least disruptive check is to read the existing lock record for the credited account. Its amount and activation timing establish more than a dashboard total alone. A successful approval only grants spending permission; the separate locking transaction must also have completed. An approval receipt cannot establish that CVX entered the locker.
A blank field or loading indicator does not establish a zero balance. Neither does a zero belonging to another connected account. When a confirmed lock exists and its activation boundary has not passed, another deposit is unnecessary. A missing lock record after an apparently successful locking transaction requires investigation of that transaction and its credited account.
When does a fresh CVX lock become eligible?
A fresh CVX lock becomes eligible in the weekly epoch following its deposit. An epoch is the fixed interval that the locker uses to group balances and determine activation. CVX locking epochs begin each Thursday at 00:00 UTC. The delay therefore follows a shared boundary rather than a personal countdown starting when the wallet signs.
Activation and withdrawal eligibility are different dates. Fresh CVX remains committed for 16 full weekly epochs after the next epoch begins. The initial wait adds to that commitment. A countdown showing more than 16 weeks can therefore reflect normal timing, rather than an extended penalty. The recorded unlock timestamp identifies the maturity of the particular lock.
Current voting weight and a proposal's eligible balance
A proposal evaluates voting weight for its designated epoch. The balance visible in the locker today can differ from the balance that a particular vote accepts.
If a deposit became active after that proposal's eligibility epoch, its absence from the proposal does not establish a deposit failure. Waiting for another weekly boundary will not move the deposit backward into an earlier epoch. Proposal eligibility and current locker eligibility answer different questions, even when both interfaces use the phrase voting power.
Gauge votes allocate weight among pool gauges, which determine how emissions are distributed. Their voting rounds have their own schedule. A weekly locker boundary does not imply that a new gauge vote opens every week. The onchain gauge proposer uses a fortnightly schedule, while its configured proposal duration determines the voting window.
The proposal's start, end, and eligibility epoch are the relevant records. A countdown copied from another round cannot establish whether this vote remains open. Likewise, a current positive balance does not establish that a vote was submitted or accepted. Those conclusions require the proposal's own account and vote records.
Delegation records can lag behind the locker
Delegation assigns voting weight to another address, and its records are separate from the underlying CVX lock. In the onchain voting system, a delegate's stored weight needs synchronization after relevant locker balance changes. Synchronization updates those records; it does not make a fresh deposit eligible before its activation epoch. The voting contracts can synchronize a detected mismatch during account initialization.
Changing the delegate is a separate operation. The onchain delegation contract applies a new assignment starting in the next epoch. Its historical records identify which delegate applied during a proposal's epoch. An account's latest delegate setting therefore cannot, by itself, explain who held its delegated weight for an earlier proposal. Repeatedly changing that setting does not repair a deposit that missed the proposal's eligibility boundary.
Does relocking make CVX eligible immediately?
Relocking expired CVX allocates weight to the current locker epoch, although participation still depends on the proposal's eligibility rules. This treatment applies to expired tokens processed through the relock operation. Withdrawing them and making a fresh deposit follows the fresh-lock timing rule.
Relocking also creates another time commitment. It is not a harmless refresh for an unexplained zero. A fresh pending deposit has not expired and does not acquire this treatment merely because someone wants immediate voting power. The distinction matters when an account contains both older expired locks and a newly deposited amount.
Expired locks can block synchronization
An
ExpiredLocks
error identifies a different problem from a fresh deposit awaiting activation. The onchain delegation contract rejects synchronization when it encounters an unprocessed expired lock with a remaining amount. A voting operation that requires that synchronization can consequently fail, even when the account also has other locks. The error concerns the account's expired records, not necessarily its newest deposit.
Processing the expired amount can withdraw it or commit it through relocking. Those choices have different effects on future voting weight and access to CVX. Where an expired-lock error blocks the operation, simply waiting through another activation boundary leaves that expired record unresolved. Any subsequent transaction must address the identified record rather than repeat the same unsuccessful vote.
Reward balances do not establish voting eligibility
Platform rewards and voting weight use different accounting rules. Expired CVX can continue accruing platform fees while it remains in the locker, despite losing current voting eligibility. A reward balance therefore cannot prove that an account qualifies for a proposal. Ordinary CVX staking and cvxCRV staking are also separate positions; their reward displays do not establish a vote-locked CVX balance. These distinctions explain how an account can show earnings while a voting panel reports no usable weight.
Checks before repeating a lock or vote
For a confirmed fresh lock showing zero weight, begin with its recorded activation time. The weekly boundary is fixed; the selected proposal's voting window and account records supply the remaining conditions. Read those records before signing another transaction.
- If only approval completed, confirm that no locking transaction succeeded before considering the separate lock action.
- If the lock exists and remains pending, wait until its next Thursday boundary, then read the same account's eligible balance again.
- If the locker shows eligible weight but the proposal does not, compare the proposal epoch with the lock's activation epoch. A missed eligibility boundary requires a later eligible proposal.
- If the lock was active during the proposal's eligibility epoch, inspect the applicable delegation record and any synchronization error. Process an identified expired lock only after choosing withdrawal or a renewed commitment.
- If eligible locker weight and proposal records still disagree, stop repeated submissions. Preserve the public account address, transaction hash, proposal identifier, and exact error for investigation; no recovery phrase is needed.
Once the account's eligible balance includes the pending amount and the proposal's record reflects its own eligibility epoch, no further transaction is needed to resolve the activation delay. The boundary to compare is Thursday at 00:00 UTC.
Convexfinance vote locking: frequently asked questions
Does locking additional CVX postpone an older lock's voting power?
A fresh deposit does not restart the activation period of an older eligible lock. The locker groups deposits by their assigned weekly lock period, while locks from different periods retain their own expiry timing. The new amount can remain pending while the older amount continues contributing eligible weight.
How does a transaction near Thursday midnight determine its activation epoch?
The block timestamp when the locking transaction executes determines its epoch assignment. The time that you press the wallet confirmation button does not establish inclusion before the boundary. A transaction signed earlier can execute later, so the receipt's block and the resulting lock record resolve the timing question.
What causes a small difference between locker weight and stored delegation weight?
The onchain delegation contract truncates stored weight to increments of 0.1 vlCVX. That precision can explain a small discrepancy without implying that CVX disappeared from the locker. Compare values for the same account and epoch first; truncation does not explain a large missing balance or a fresh lock awaiting activation.
Will assigning a delegate transfer the CVX held in my lock?
Assigning a delegate changes voting authority without transferring the locked CVX. The delegation record identifies who can exercise delegated weight for the applicable epoch. The tokens remain subject to the lock's existing withdrawal conditions, and changing the delegate does not shorten the commitment or accelerate a pending deposit.
Do I pay gas while a CVX lock waits for voting activation?
The passage of time to the next epoch does not itself charge your wallet gas. Transactions such as locking, changing delegation, or submitting an onchain vote have their own execution costs. A read of an existing lock record does not submit a transaction, so inspecting a pending balance requires no activation payment.