stDYDX is one of Stride’s largest LSTs, with ~$10M in TVL, and a potential inflow of 20M DYDX soon. Because DYDX yield is paid in USDC, the Stride protocol needs to swap USDC to DYDX before reinvesting. Stride is redesigning how USDC → DYDX swaps work, in order to process more swaps with less slippage.
As a result, Stride needs the following two AllowMessages added into the allowed ICA messages list:
Note, this proposal is time-sensitive to accommodate an upcoming chain upgrade for Stride, so we couldn’t wait the entire 3 day discussion period. We discussed with the Osmosis team and they ultimately thought it’d be ok, given that we had already tested this proposal on testnet. See below for the testnet proposal, and if anyone has questions, I’m happy to answer them!
Basically, this would give interchain accounts on Osmosis the right to grant permissions to other wallets.
The usecase for Stride is that the interchain account will be able to grant authz permissions to a wallet running a script that randomizes swap times on the ICA’s behalf. This is being done in order to prevent the ICA swaps from being frontrun, which should maximize the value received by stDYDX stakers.
And that is the part which I find scary. So for a proposal that is NOT on chain yet (and can thus be delayed) we are ok with breaking agreements?
Surely not the way to go, because that effectively means that we are willing to let go of our principles because others are not willing to change their ways.
And maybe the risks are small on this one, but again… setting precedents is a very very bad habit.
If this proposal is time-sensitive and already had prior discussions with the core team, would be great if that information could be written in the governance proposals. Thanks.
Had absolutely zero contention and were even treated as annoying proposals that we should get out of the way in one bulk proposal. These ones were missed and so there is no point following a 3 day period that was intended to modify contentious proposals before they became indelible on chain.
I don’t even necessarily agree with the current extended length of the discussion+voting period but I have seen other proposals shot down with this stated as the reason, so it should stand for anything non-standard.
Then we should change our standards and agree on what kind of proposals are not subject to the 3-day period, just like we did with IBC-proposals and the updates for incentives.
But ignoring our agreed standards before we agree on creating an exception… not good.
I’m not sure what you mean regarding the MsgCreateBalancerPool. This message is required by the Qwoyn Network Aquifer module. If removed, it renders the module useless. Am willing to discuss further if you are trying to get rid of it. Also, its 8am for me so maybe I’m just reading this wrong.
To clarify, Stride contributors are working on a software upgrade that’s due to go on chain in a couple of days. The upgrade will directly leverage the messages being approved in this proposal.
The upgrade is highly time sensitive to accommodate a huge DYDX inflow into Stride (and consequently a huge inflow of trading volume on the DYDX / USDC pool on Osmosis). The messages need to be enabled before the upgrade starts attempting to use them, and it’s risky to put the upgrade on chain without knowing whether this proposal will pass.
Waiting the 3 days would have pushed back the timelines for Stride and dYdX to facilitate this inflow. As @JohnnyWyles mentioned, these proposals have historically been uncontentious, and enabling additional ICA messages is an extremely innocuous change.
Feel like we’re really making a mountain out of a molehill here.
