Introduction
veBoost V2 was first introduced in this forum post several years ago, and has been working since then. In a nutshell, it allows users to delegate (“transfer”) their veBAL balance to other accounts.
Specification
We have two veBAL lockers (delegators) that currently cannot delegate their veBAL balances, as the contracts are not prepared to do so:
- tetuBAL mainnet locker:
0x9cC56Fa7734DA21aC88F6a816aF10C5b898596Ce - sdBAL locker:
0xea79d1A83Da6DB43a85942767C389fE0ACf336A5
To allow the lockers to operate their veBAL balances, we’ll follow the same approach that has already been executed on past versions of the delegation contract as described in this forum post. In short, veBoost 2.1 shall add hardcoded infinite allowance for operators designated by each DAO to be able to manage the veBAL balance in the name of the lockers:
- Operator tetu:
0xB9fA147b96BbC932e549f619A448275855b9A7D9 - Operator stakeDAO:
0xB0552b6860CE5C0202976Db056b5e3Cc4f9CC765
Other than that, the new implementation of the veBoost contract shall be equivalent to the active one in terms of functionality. The state of the current veBoost contract shall be ported over to the new one using a permissionless migrate function, which is the only significant modification over the code. This means that existing delegations as of Jun 23, 2025 won’t need to be recreated manually.
The rest of the modifications to the code are just readability improvements without any other practical effect; complete changes can be seen here.
Technical Specification
Call setDelegation on the VotingEscrowDelegationProxy (0x6f5a2eE11E7a772AeB5114A20d0D7c0ff61EB8A0) with the following arguments:
- delegation:
0x2cf8e145Bdfe7c52b49AD9bB3c294a31B2736c59
Doing this requires the permission to call setDelegation, which is 0xac0fcdc4520d7bde1c58bbefd7c8dd39aaf382a20c27991134c14fe63d2c96f3. This permission is currently held by the Governance DAO Multisig (0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f), so it doesn’t need to be granted.
Preseed
The existing boosts have already been loaded into the new contract in this tx. No further action is needed other than wiring up the contract to the rest of the system as described above.
Risk
The contract is fundamentally the same, the migration function can only be called once and the state that is ported over to the new contract is hardcoded. If there is a mistake (e.g. a missing delegation) it can be created again using the usual mechanisms.
