Adding Authz messages into allowed ICA messages list


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:



A proposal to add the AllowMessages is being processed on Osmosis testnet. If successful, a mainnet proposal will follow shortly.


Just to get it clear; this would give addresses the Authz-authorisation to set rights for other addresses, right?

Is this limited to addresses which are clearly owned by the owner of the address? I am not entirely sure how it works :slight_smile:


Update: The proposal is on chain.

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!

1 Like

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.

This is not possible with the ICA-account? Or not desirable? (side note: I am not as familiar with ICA as others around here)

edited until further research :eyes:




Can you elaborate on the time-sensitive part?
Since there is no chain upgrade planned currently?

So there is still room to postpone that one to comply with the way things are supposed to be done?

There’s a prop that’s about to go onchain wrt to this. I imagine this is the cause of the time sensitivity.

Stakecito supports this proposal in its current state, given the circumstances.

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.

1 Like

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.


The previous ICA message proposals:

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.

What circumstances? What is the emergency here?

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.

Not trying to remove it at all! Just using it as an example of why this proposal skipped the forum discussion time.

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.

Ahh ok, I knew I was just confused. Thanks!

No, we are trying to comply to agreements made in the past.

If so, why not have the conversation if these kind of proposals can be relieved from the 3-day forum-requirement?

1 Like

I think we should have a discussion about the 3 day period and add ICA messages to the exception list if it seems its a non-issue.

1 Like