Migrating the Admin Address of Membrane Contracts

Proposal Discussion
1

Proposal
This is a proposal to migrate the admin address of Membrane contracts from our old governance (osmo19h8huy2hz4q7detxzv2r2erlsvlq8hzlsquu6n5x83775va4qgkskf20kq) to our new governance contract (osmo1wk0zlag50ufu5wrsfyelrylykfe3cw68fgv9s8xqj20qznhfm44qgdnq86) in a future software upgrade.

The contracts to migrate are:
{
“discount_vault”: “osmo1v8wckds5lvsdd0xrragvleu8srxprjpwdl7mga5uygnwmz5e7qzsl5zexw”,
“governance”: “osmo19h8huy2hz4q7detxzv2r2erlsvlq8hzlsquu6n5x83775va4qgkskf20kq”,
“liq_queue”: “osmo1ycmtfa7h0efexjxuaw7yh3h3qayy5lspt9q4n4e3stn06cdcgm8s50zmjl”,
“liquidity_check”: “osmo1xxx0yuqhmwekt44q00jrf3rwvfa70rpeu622q0x56yaf423vq93q3qpzux”,
“mbrn_auction”: “osmo1qwdlg9le9kdrvgyp35jxz53m8zhdssyvxvyevmdxcn852h6dq9gqknf2aa”,
“oracle”: “osmo160t4k7x8axfd335s0rj5jdffzag684tjrzchlwmqk23xte32alvq6nfz6k”,
“osmosis_proxy”: “osmo1s794h9rxggytja3a4pmwul53u98k06zy2qtrdvjnfuxruh7s8yjs6cyxgd”,
“positions”: “osmo1gy5gpqqlth0jpm9ydxlmff6g5mpnfvrfxd3mfc8dhyt03waumtzqt8exxr”,
“stability_pool”: “osmo1326cxlzftxklgf92vdep2nvmqffrme0knh8dvugcn9w308ya9wpqv03vk8”,
“staking”: “osmo1fty83rfxqs86jm5fmlql5e340e8pe0v9j8ez0lcc6zwt2amegwvsfp3gxj”,
“system_discounts”: “osmo1p0hvtat69dash8f0w340n2kjdkdfq0ggyp77mr426wpnfwp3tjyqq6a8vr”,
“vesting”: “osmo1flwr85scpcsdqa8uyh0acgxeqlg2ln8tlklzwzdn4u68n3p5wegsgspjf6”
}

Current Situation
The old governance contract is unable to execute proposals due to gas&quorum issues so it can not migrate the admin itself. This results in a stagnation of development for Membrane & the inability for its stakers to control the protocol. If the quorum issue was organic we wouldn’t ask for Osmosis’ help here as that’s a coordination tradeoff that Membrane has accepted.

The 1st Governance contract can’t execute a proposal because it’s quorum isn’t counting Total Voting Power with quadratics (i.e. not a square root). This means even with 100% voter participation it’d still be way under the quorum, hence why we are going for this solution instead of trying to get a proposal past the gas issues.

The 2nd Governance contract, using the same staking data as the first contract, can process a proposal to signal from the actual Membrane stakers, the same stakers in the 1st Governance contract, that they are okay with Osmosis making this move for them.

Essentially we could make an infinite amount of Governance contracts for MBRN stakers to vote in, but only one could have admin access, in this case its an instance that can’t execute any proposals.

Solution
The solution to migrate the admins of the existing contracts will allow the new governance contract to handle all control functions of Membrane contracts from this point forward. Sometime during this discussion, prior to this proposal going live, there will be a signaling proposal up on the new governance contract to show buy-in from the Membrane staking community.

The Membrane signaling proposal is a key component as this is a governance procedure outside of Membrane Governance purview. As this can set a precedent for future software upgrades, it’s important to give the affected sovereign community a voice in the matter.

I am willing to support in any capacity on the development end of this if necessary.

4 Likes
2

I think this needs much more explanation of the old and new governance quorums.

I think its generally unacceptable for Osmosis governance to change the governance rights of a contract deployed on it, without explicit signalling of acceptance from the prior governance system. Here the prior governance system is under-explained, as are the reasons as to why it cannot function correctly anymore

2 Likes
3

You’re right, the current situation isn’t explained well, let me try to break it down.

The 1st Governance contract can’t execute a proposal because it’s quorum isn’t counting Total Voting Power with quadratics (i.e. not a square root). This means even with 100% voter participation it’d still be way under the quorum, hence why we are going for this solution instead of trying to get a proposal past the gas issues.

The 2nd Governance contract, using the same staking data as the first contract, can process a proposal to signal from the actual Membrane stakers, the same stakers in the 1st Governance contract, that they are okay with Osmosis making this move for them.

Essentially we could make an infinite amount of Governance contracts for MBRN stakers to vote in, but only one could have admin access, in this case its an instance that can’t execute any proposals.

4

Ah got it! Is there some docs or indication of what the 1st governance is aiming to implement?

Sounds like its trying to do quadratic voting, but right now its implemented as:
sqrt_vp_X = sum_{votes for result X}(sqrt(vote))
decision = max_{results X} (sqrt_vp_X)
quorum = sum_{X}(sqrt_vp_X) / total_voting_power

(instead of quorum = sum_X(vp_X) / total_voting_power )

(Note that if this is quadratic voting, using quorum as sqrt(total_voting_power) would also not be right, as you’d easily get quorums over 100% at least by my above formulation)

If the new gov system does something that can signal from INTENDED_QUORUM amount of original stakers, then it sounds ok for this to go to full osmosis governance (as you mentioned)

Can you link docs / code for what the intended mechanism of the first system was, and whats the second system’s code is doing more precisely.

1 Like
5

Original: https://github.com/MembraneFinance/membrane-core/blob/main/contracts/governance/src/contracts.rs#L800
image
As you can see it quite literally does nothing here but as you mentioned, taking the sqrt_root here is still wrong.

New: https://github.com/MembraneFinance/membrane-core/blob/oracle_pricing/contracts/governance/src/contracts.rs#L834
image
image

The new one is using the voting power list that is created on proposal submission that contains stakers & delegates, + the voting power that vesting recipients have.

2 Likes
6

Osmosis :handshake: Membrane, together we go far!

1 Like