[BIP-252] Timeless 50k BAL Grant Application [ve8020 Program]

Service Providers Grants
28

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
29

Sounds like everything is in order. Thanks everyone for your help.

30

Hey guys, the VeBalGrant contract for Timeless and Balancer has been deployed:

2 Likes
31

@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

32

what is the spec exactly?

33

Correct me if I’m wrong, the requirements to execute the first steps of this proposal would be the following:

  1. Balancer deposits 50k BAL on 0x89f67f3054bFD662971854190Dbc18dcaBb416f6
  2. Timeless deposits the corresponding required WETH to create the lock on 0x89f67f3054bFD662971854190Dbc18dcaBb416f6
  3. Balancer calls setActive on 0x89f67f3054bFD662971854190Dbc18dcaBb416f6
    Then Timeless calls createLock if the grant is set as active.
2 Likes
34

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
35

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
36

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
38

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

  1. If not done yet, deploy your contract on Goerli
  2. Do a test transfer of X amount of BAL
  3. Do a test transfer of X goerliETH
  4. 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).

39

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
40

https://snapshot.org/#/balancer.eth/proposal/0x438cb8ec286228bb46435efc9e74a3c4e66040eb39e61f4ec7ee7511ff25b8b0

2 Likes
41

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

42

Noted, we’ll proceed with the WETH tx in a bit.

43

lock is executed. you should exec the vote for your gauge before 00:00 UTC thursday if you can

44

Thanks for your support, executed Ethereum Transaction Hash (Txhash) Details | Etherscan

2 Likes