[Proposal] Allow Whitelist tetuBAL in Balancer VotingEscrow


This is a proposal to hear from the Balancer community about the whitelisting of Tetu contracts for the new product being developed, which is called tetuBAL.

What is tetuBAL?

tetuBAL is the liquid version of veBAL being developed by Tetu. Each tetuBAL represents veBAL locked forever in a 1:1 ratio.

With tetuBAL users will be able to:

  • Deposit 80/20 BAL and ETH on veBAL forever in exchange for tetuBAL.
  • Sell tetuBAL for BAL in the liquidity pool.
  • Participate in governance votes using dxTETU to target Balancer emissions.
  • Exposure to veBAL that is on the Ethereum network with a low cost of gas due to the aggregation of assets.
  • veBAL rewards earnings from the maximum 1 year locking period, swap fees, and protocol fees while receiving the boost that is only available on Ethereum.


All governance discussions take place through Discord, if there is an implicit community consensus the proposal is carried out and dxTETU holders can vote. Eventually, when the will of the community is unclear, draft proposals are submitted for review and amendment prior to publication of the original proposal.

Audits and Security

All audits can be found here Audits - Tetu

Tetu’s security features are 48 hours Time lock and MultiSig Wallet, more information can be seen in the docs. Tetu uses security best practices such as rigorous testing before implementing new code.


Website https://app.tetu.io/


This model has worked very well at Qidao. Looking forward having this for Balancer too.


Look good to me. A win/win for tetu and balancer.


Let’s make this happen! This would be great for veBAL wars as non-Ethereum projects could participate in the wars.

1 Like

Seems like a win-win situation for both parties! We would like to see the proposal flourish.

1 Like

Thank you for your proposal. Could you please be more specific as to what contracts you’d like to be whitelisted?

1 Like

tetu-contracts/BalStakingStrategyBase.sol at dev · tetu-io/tetu-contracts · GitHub

1 Like

Specific contracts that need to be whitelisted:
vault TetuProxyControlled | Address 0xFE700D523094Cc6C673d78F1446AE0743C89586E | Etherscan

strategy TetuProxyControlled | Address 0x308A756B4f9aa3148CaD7ccf8e72c18C758b2EF2 | Etherscan

Hello! I did a quick overview of the contracts, and one thing that caught my attention immediately is the presence of full upgradeability. It looks like both the Vault and the Strategy are OpenZeppelin-based upgradeable proxies, which means that the behavior of the contracts can be arbitrarily changed to, well, anything.

Worryingly, while at first glance it is a contract that performs the upgrade (the Controller at TetuProxyControlled | Address 0x6b2e0facd2f2a8f407ac591067ac06b5d29247e4 | Etherscan), it is actually an EOA (Address 0xbbbbb8c4364ec2ce52c59d2ed3e56f307e529a94 | Etherscan), known as the ‘governance’ address, that instructs the Controller to upgrade. There does seem to be a timelock in place (I imagine the same 48hr one mentioned in the post?), but given the broad nature of the upgrade mechanism I don’t think this would be mitigation enough in this case.

Could you provide more context on the reasoning behind full upgradeabilty, and how you imagine this coming into play in the future? Thanks!


Thanks for the detailed response

0xbbb… address is our deployer and temporary governance, I already started migration of governance power to our msig

Ethereum gnosis has 3/4 signers

  • belbix - lead dev
  • Constantin - front end dev
  • GodInMaking - biz dev
  • JasperS13 - Harvest finance developer

the reason why we have proxy is simple - risks of bugs or simple improvements
it is a common pattern and discussed multiple times - the biggest projects with complex logic have proxies
we have immutable contracts only in case of well-known logic or in case of security reasons
for the reason that this solution will lock tokens forever, I don’t think that the proxy pattern will add any additional risks

1 Like

Whitelisting an upgradeable contract is a no go.

The whitelist is implemented to prevent arbitrary tokenization of veBAL and allow governance to only whitelist a tokenization logic that is appealing to them. Whitelisting an upgradeable contract is essentially a carte blanche to completely circumvent the whitelist from here on and apply any arbitrary tokenization logic (or arguably multiple by another layer of tokenization) without any further consent from governance.

It’s further alarming that you are downplaying the implications of an upgradeable contract.
Glad you’re moving the EOA to a multisig but it’s very surprising that you’d put up a proposal with an EOA in the first place.

1 Like

Hey guys!
I’m a led dev of Tetu.
No problem, we can implement an immutable dedicated contract for deposits.
EOA will be changed to Gnosis msig, of course


Don’t want to discuss your decision, obviously, it is your project and your rules but want to say a few suggestions about ve security:
I think a proxy contract for locked tokens has only one possible vulnerability - the owner will not prolong the lock period, wait 1 year and dump tokens on market.
Everything else has the same risks as an immutable contract:

  • Users will unable to vote directly from Polygon. A solution should contain some kind of delegation.
  • Delegator can be changed - in the case of EOA it can be simply a transfer of private keys, in the case of msig signers can be changed.
    Probably I missed something but looks like a question - will you trust us to manage votes or not.
    If you don’t trust our team, I guess you will not do it with an immutable contract either.
    Could you confirm please that the reason for rejection is only the proxy contract?
    We are spending money and time on this solution. We don’t want to waste more if you don’t want to whitelist us for some internal reasons. Just say it directly please, it will be fair enough.
1 Like

Governance was transferred to Gnosis msig


Please review a new dedicated immutable solution.

If everything looks good to you guys , we will deploy this on mainnet


Posting here again after sharing some thoughts in the Aura proposal.

Broadly speaking, I think it might be too early to worry excessively about which approaches are acceptable, how much control individuals should have over a protocol pooling funds to acquire veBAL, and overall what a healthy solution looks like. Perhaps a saner initial approach would be to be permissive and let all of these systems develop and grow, monitoring them and only potentially acting if it seems like they might become a threat in some way (which, even assuming malicious intent, I don’t expect would happen soon).

With that in mind, and given that Tetu is not a brand new platform, I don’t see much reason to not let them participate. If people are concerned, then maybe those could be addressed with risk mitigation measures such as caps on how much veBAL untested protocols can hold, or agreements on deadlines by which certain measures must be enacted (e.g. no centralized control). That discussion seems a bit out of scope of this proposal though.


Well if this is the case,

I propose to bring this proposal to snapshot.


I brought up the issues around centralization in the Aura thread as well. 0xMaha mentioned:

@DogInMaking @belbix, is the multisig to be assumed as the final destination?

1 Like

since we are doing cross chain staking so afaik its impossible to do cross chain governance

1 Like

@LongJuanSilverado @nventuro
I finished the contract

Only a voter will be able to vote for gauges and delegate snapshot power.
Only the voter can change voter address.
Full control will be in hands of a dedicated msig. DogInMaking will prepare a list of signers.
Tetu will be able to manage only rewards and farm boosted gauges.