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.
Governance
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.
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.
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.
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
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.
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.
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.
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.
