Additionally, this proposal was reviewed by Jack with VELO and the SNX Ambassadors. You can discuss here, in the OP discord (a thread has been created), or in the Alchemix Discord (here: Alchemix)
Hey, you should verify the new proposal template v2 and add relevant information.
1 Like
Thank you for pointing this out - we will revise ASAP and edit post / comment here when we do.
Glad to see more protocols looking to delegate their tokens. Although there are no standards on this point, my suggestion is that you fold the tokens to be delegated into one of your other asks – or to consider something creative with the OP that you would hold, e.g., devise some utility within Alchemix’s core offerings.
You could then draw down the delegatable OP over time, reacquiring it through market buys should you decide that governance power is something you’d wish to accumulate over the long term (and I candidly think it is!)
Separately, I’m not sure how to get around the KYC issue, and it’s probably worth some discussion. One thing we could do is arrange for a multisig with some KYC’d people on it and set it such that you need at least one KYC’d person signing off on any tx.
I am an Optimism delegate [Delegate Commitments - #136 by jackanorak ] with sufficient voting power and I believe this proposal is ready to move to a vote.
KYC is an open issue but this should be part of the deliberation
1 Like
I’m an Optimism delegate with >0.5% of the current votable token supply and I believe this proposal is ready to move to a Snapshot vote (not an endorsement of the proposal itself but that I think it is ready for voting).
1 Like
I am an Optimism delegate [Delegate Commitments - #65 by mastermojo] with sufficient voting power, and I believe this proposal is ready to move to a vote
I think holding the delegated OP for the potential to bootstrap a future alOP would be a good candidate. alOP would require a yield source, which would most likely come from either AAVE utility (or similar integration), or even better if Optimism eventually earns revenue and shares it with token holders. While we wait for this use case to emerge as a possibility, it gives us a say in what (I think) will be our largest/most popular L2 offering for a while. If it becomes clear this won’t be feasible, then we can look to extend / ramp up liquidity mining to attract more users (should it continue to be proven that our depositors are generally remaining deposited).
1 Like
Hi @Ov3rkoalafied , Thank you for your proposal.
I have few input and would appreciate if your could provide additional information.
- KYC part is negotiable or off the table ? I believe this will be done between your team and foundation.
- Do you have any dashboard where I can see stats on Optimism, I assume the deployment was on 19th Sept.
are you planning to migrate liquidity from other chain to optimism to jump start the launch?
- On self-delegation, would you consider using vault or lp token for self-delegation. Keeping 250K just for delegation is not a good of token, imo.
-
I asked around and looked through the forums, and I haven’t found any elaboration on the KYC requirement besides the one question (including discussions on where it was added). No one on the team has KYC’d before, and we have done plenty of deals without it, including an OTC sale of ALCX tokens shortly after the protocol launched. I believe KYC would be off the table for us, but we are open to other approaches if acceptable.
-
We have deployed the contracts with small (100k) deposit caps. Currently we are working on completing staging for the UI with the live contracts, then we will announce and lift the caps. So there’s not really any stats yet (unless anyone wants to interact with the contracts directly, if they can find them!).
-
See my comment above yours - we could hold onto the OP for an eventual alOP. Alternatively, since I’d like to keep the total quantity the same, we could put the 250k OP into the LP/depositor incentives and self-delegate over the course of time that we are drawing down from those.
Who would be good to ask about KYC? Ultimately is it just a DAO decision? Ie, we would go to vote with a “no” for KYC, and then the DAO could pass or fail it?
The requirement came from OP Labs directly, most likely driven by whatever legal requirements they deemed satisfactory to protect the real world entity.
My current guess is that this items is a hard stop since Phase 0 projects were required to KYC themselves and this was not part of the discussion for Phase 0 nor part of the OPerating manual
A good place to start the discussion would be gov-general channel on discord, another option would be creating a thread and getting community feedback and last option would be to directly contacting Optimism foundation team.
Please update the proposal to reflect the same.
any time line for this ? and what about co-incentives ?
Just posted there, thanks! We do have one team member that would be willing to KYC, so will determine if that would be acceptable.
I’ve updated the proposal to reflect alOP.
Our matching incentives are all on the liquidity incentivization side, since that requires more incentives than the product side to maintain sufficient liquidity for depositors to take loans. Velodrome has done a good job at making liquidity more efficient, so we are incentivizing by taking a larger stake specifically in Velodrome - we own a sizable lock already, purchased more through AIP-49. That AIP also had us move $1 million of protocol owned alETH liquidity from mainnet to Velodrome. If we start to see TVL migrate from mainnet to Opti or a lot of fresh TVL come in on Opti and the incentives aren’t keeping up, then we can also redirect some bribes from mainnet curve to Velodrome (not yet approved by governance).
1 Like
What date have you determined to launch the vaults in Optimism?
Can you indicate the possible protocols to which you will delegate OP tokens?
-
Vaults are live but with low deposit caps. We are working on finalizing the UI, it got delayed due to some DDOS attacks (so we are shoring up our main front end first). I will post here and edit the proposal as soon as we are fully live, including updating TVL when closer to voting. The new voting starts Oct 13th so should be plenty of time to get a bit of TVL.
-
The most likely protocols would be Velodrome (they will be a major partner for us on Optimism for alAsset liquidity, so our goals will be somewhat aligned), or SNX (they have some delegates who have also been active in our community and they have helped us with this proposal). Nothing has been officially decided yet.
Will this distribution be 50/50?
I am against delegation and self-delegation with tokens received through grants.
I think that if you want to give voice to Alchemix you can make purchase of OP tokens in the secondary market. Considering that in AIP-59 you make use of treasury (correct me if I am wrong) to buy VELO tokens, you can use the same resource to buy OP tokens.
1 Like
Yes, 33% (250,000) each.
Delegation is not the primary purpose. As mentioned we would be holding for up to a year with the hopes of incentivizing alOP in the future (requires some updates on the OP side, and we are working on an update that would make launching separate alAssets feasible). If that use case never comes to fruition then after a year, we would fold the OP into the first two use cases, to extend their life. In the meantime, we were thinking we would delegate OP. In this scenario if we want a voice in governance beyond a year we would still have to purchase OP, but at least it gives us some say while we build up the funds / TVL to justify doing so. We also figured delegating/voting would be better than LPing the tokens somewhere (ALCX/OP or something), since that’s effectively a limit-sell order on OP if it goes up, but if LPing those tokens would be more preferable we can do that.
Lastly, if more people voice concerns with delegation or LPing (hard for me to know if your opinion reflects a large portion of voters / past precedent in voting - if you have any insight there please let me know), then we can just fold those OP tokens into the first two use cases.