I am not sure if that would be the right approach. Sounds to me like a “soft” token swap, which I personally would advise not to do.
A contract as outlined above would be the most elegant solution IMO.
Hey @Franklin,
It looks like the amendment to BIP-146 has passed. We’ve been going over the latest changes in the Aura contract grant and would like to know the best course of action for our current grant application.
Here’s what I think we should do:
- Update our application to make sure it’s in line with the new requirements and guidelines in the amended BIP-146. This includes revising any relevant sections with fresh data.
- Review and resubmit the updated application.
Let me know if you have any suggestions or if there’s anything else we need to consider.
1 Like
Sounds good, brother! Feel free to edit the text of this current proposal–you can update it however you feel is best. If you can get this done before Wednesday, then we should be able to move to vote on it this week. No other issues on our end–it looks like we’re making some good progress!
we need the contract deployed so the vote can go thru with the proper on chain specification (send X BAL to 0x…)
1 Like
Hey, brother, we’ll need an address for Balancer and an address for Timeless to deploy this. A multisig would be preferable for both.
if you need that from me I’d like to know what the function or purpose of the balancer multisig would be. if you need it from Fernando then all good he can provide
1 Like
Sounds like everything is in order. Thanks everyone for your help.
Hey guys, the VeBalGrant contract for Timeless and Balancer has been deployed:
-
Contract deployed and verified here: https://etherscan.io/address/0x89f67f3054bFD662971854190Dbc18dcaBb416f6
-
Also updated our fork tests to run against the new deployment, all still passing.
[Feat] veBAL Grant Deployment by phijfry · Pull Request #206 · aurafinance/aura-contracts · GitHub
2 Likes
@Xeonus apparently I can’t amend the proposal with the updated payload without moderator access. May I ask you to update the specs or ask someone from the Maxis to update it? cc @solarcurve
what is the spec exactly?
Correct me if I’m wrong, the requirements to execute the first steps of this proposal would be the following:
- Balancer deposits 50k BAL on 0x89f67f3054bFD662971854190Dbc18dcaBb416f6
- Timeless deposits the corresponding required WETH to create the lock on 0x89f67f3054bFD662971854190Dbc18dcaBb416f6
- Balancer calls setActive on 0x89f67f3054bFD662971854190Dbc18dcaBb416f6
Then Timeless calls createLock if the grant is set as active.
2 Likes
need to know desired parameters for the createLock() call (unlockTime & minAmountOut)
also, we only send tx’s to the DAO multisig to execute once a week. I’m not sure how this contract works precisely but for example if this vote passes and we send BAL but the ETH isn’t there so we can’t call createLock(), we’d have to wait until the following week to try again.
just to be crystal clear, when you say “Balancer deposits 50k BAL” you mean a simple transfer of 50k BAL to 0x89f67f3054bFD662971854190Dbc18dcaBb416f6. no function call.
1 Like
AFAIK Balancer doesn’t need to interact with createLock(), Timeless can do it after the required setActive call by Balancer.
Yes a simple transfer of 50k BAL should be send in the contract balance at 0x89f67f3054bFD662971854190Dbc18dcaBb416f6. Someone like @phijifry should be able to confirm all the above. So all of that could happen in one batch of txs on week 1 from Balancer MS, without requiring another round on week 2.
Then Timeless is autonomous on the following step to send the WETH and create the lock.
Please feel free to correct me if I’m wrong.
1 Like
Actually no the grant contract was updated so that only Balancer can create the lock. So the steps look like this:
- Balancer transfers 50k BAL to 0x89f67f3054bFD662971854190Dbc18dcaBb416f6
- Timeless transfers the corresponding amount of WETH to 0x89f67f3054bFD662971854190Dbc18dcaBb416f6
- Balancer calls
setActive(true)on 0x89f67f3054bFD662971854190Dbc18dcaBb416f6 - Balancer calls
createLock()on 0x89f67f3054bFD662971854190Dbc18dcaBb416f6
@solarcurve regarding the parameters of createLock(), unlockTime should be the Unix timestamp (in seconds) of 1 year in the future, and minAmountOut is a slippage check parameter (not sure what’s an easy way to get the appropriate value for it though, maybe @phijifry can help answer)
3 Likes
We would like to see testing evidence before moving to snapshot. Ideally, we would like test the contract on Goerli with you guys to make sure everything is working as intended (see docs here: Goerli | Balancer ). Therefore, a proper testing routine and payload should be defined and carried out. So the best course of action would be
- If not done yet, deploy your contract on Goerli
- Do a test transfer of X amount of BAL
- Do a test transfer of X goerliETH
- Execute contract calls (we can’t as there is no multi-sig on Goerli AFAIK)
Of course, if you have testing evidences, share them here so we can be more confident that this procedure works as intended. Given the above specs we suspect that there will be 2 txs (one for token transfers and one for the contract calls).
I’m gonna go with the following spec for now.
Transaction A will be executed immediately.
DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will transfer 50,000 BAL to 0x89f67f3054bFD662971854190Dbc18dcaBb416f6
Then, DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will call allowlistAddress on 0x7869296Efd0a76872fEE62A058C8fBca5c1c826C with the following argument:
contractAddress: 0x89f67f3054bFD662971854190Dbc18dcaBb416f6
This will whitelist the veBAL locking contract to lock veBAL in the system.
Transaction B:
DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will call createLock on 0x89f67f3054bFD662971854190Dbc18dcaBb416f6 with following arguments:
unlockTime: 1712959367 which corresponds to 4/12/2024 (max lock)
minAmountOut: 0 placeholder value for now
Once A is executed and the ETH is sent to the contract we can use tenderly sim to figure out if transaction B parameters need to be edited. This wouldn’t require another vote, just forum post explaining reasoning.
3 Likes
B tx seems to simulate success. will pass it to the multisig this week. not sure what actions timeless needs to take to get your vote in but I’d suggest doing that wednesday
Noted, we’ll proceed with the WETH tx in a bit.