Contract migration through Governance & New Mirror Oracle structure


Mirror had one of the most active blockchain governance communities in DeFi, with 253 polls created since its birth. Yet, a majority of these polls were TEXT polls which were not effective in bringing about immediate changes that users desired.

A majority of these text polls made suggestions concerning assets that were never implemented. One of the reasons for this is the to lack of access to information on which assets are being price fed by the Band Protocol oracle.

To enhance the existing power of MIR stakeholders, big changes on Mirror governance are required:

  1. Allowing feature upgrades (contract migrations) purely through governance, only by votes of MIR token stakers.
  2. New oracle structure which allows governance participants to decide to whitelist or remove new oracle providers and price feeds

This forum post (and governance poll) suggests these changes to Mirror Protocol through a contract migration done by Mirror community members.

1. Contract Migration through governance

Current Mirror Contract migration process

Previously, any feature upgrades / updates that required contract migrations on Mirror were done through the below steps:

  1. New smart contract code PR is merged on
  2. Text proposal which explains the new updates is uploaded on the Mirror Forum, and Mirror Governance
  3. A week of voting (voting period) ends, and YES vote passes the voting threshold
  4. Manual contract migration takes place, using migration keys

Problems with the current process

The above process resulted in the following problems:

  1. Migration message had to be signed only by the migration key holders
  2. Governance voting period was too long to allow quick bug fixes

A good example would be Poll 240, which included the addition of LunaX collateral and fixing the slippage tolerance on the Mirror Collector contract. But adding a new feature and fixing an existing issue took a week, long since the governance voting period was fixed across all proposal types.

Contract migrations TO-BE (after this update)

To overcome the problems above, Mirror Governance will include two major features:

  1. Modifying existing Mirror contracts through governance voting
  2. Allowing temporary delegations of Admin / Migration key through community consensus (for special migrations such as major upgrade on Terra blockchain or CosmWasm contracts)

Involved Contracts

  1. Admin Manager: all migration related transactions that are sent from the Governance contract after polls pass will go to the Admin Manager contract. Admin Manager contract is the one that actually holds the admin keys necessary for contract migration.
  2. Governance: Users on Mirror Protocol can submit Contract Migration and Admin Key delegation polls through Mirror Governance.

Poll configuration parameters

Currently, all governance polls on Mirror share the same parameters, including voting_period , effective_delay, threshold and quorum. But considering how important the new polls for contract migrations are, different poll configuration parameters are applied:

  • migration_poll_config: Migration poll config will have the following parameters that are different from default_poll_config:
    • Quorum: 40%
    • Threshold: 66.7%
    • Voting Period: 7 days (but if the poll reaches the quorum within the voting period, then poll is immediately executed based on vote results)
    • Proposal Deposit: 2,000 MIR
  • auth_admin_poll_config: Poll config for transfer of admin key will have the following parameters
    • Quorum: 40%
    • Threshold: 66.7%
    • Voting Period: 7 days
    • Proposal Deposit: 3,000 MIR
    • Admin claim period: 7 days

How to submit Contract Migration polls

  1. New contract(s) to be migrated are deployed on Terra

  2. A migration_poll is submitted with the ExecuteMigrations to be executed on Admin Manager contract when the poll ends:

    ExecuteMigrations {
            migrations: Vec<(String, u64, Binary)>

    where string is the contract address to migrate, u64 is the code ID and Binary is the migration execution message.

How to submit Admin Key delegation poll

  1. Create a poll with AuthorizeClaim poll admin action parameter. AuthorizeClaim action requires authorized_addr parameter, which is the address to delegate the admin keys
  2. Once the poll passes, the same address defined from authorized_addr sends ClaimAdmin transaction to Admin Manager contract
  3. The address that claims the admin keys will have the admin rights for the time defined by admin_claim_period.

2. New Oracle Structure

Current Oracle Structure

The current Mirror Oracle contract receives price feeds from Band Protocol to update prices whenever the market is open (at least every 60 seconds). The current structure has the following issues:

  • It is hard to know which assets Band Protocol provides price feeds for
  • There is no way to automate the process of registering a new oracle feed provider

New Oracle Structure

The new TeFi (Terra Defi) Oracle structure provides a new method of fetching prices from multiple oracle providers by allowing the following features

  • Enables whitelisting of new oracle service providers such as Chainlink, as well as updating and removing existing price feeds and oracle providers through Mirror Governance
  • Simple query to Hub contract to look up prices by token address and symbol
  • Proxy Contract which helps oracle providers to feed prices in uniform schema, including information such as asset symbol & name, updated price, timestamp.
  • Prioritizing price feeds if there are more than one price feed for the same asset

Mirror Mint contract would query prices from the Oracle Hub contract only, and it will return prices based on the highest priority setting regardless of how many feeds are being provided to the same asset.

In addition, suggestions such as the below can be more easily integrated into Mirror Protocol in a decentralized manner:

Migrated Contracts


New Contracts


Conclusion & Summary

By voting YES on this poll, you are agreeing to allow members of Mirror community to migrate the contracts listed on Migrated Contracts section to bring the following changes to Mirror Protocol:

  1. Contract Migration through governance
    • Admin Manager contract will own admin keys which holds control over Mirror’s core contracts
    • These admin rights held by Admin Manager can only triggered by governance polls to migrate specific contracts or delegate admin keys to an address defined by these polls.
  2. New Oracle
    • Mirror governance can allow new oracle providers such as Chainlink to officially feed prices on Mirror
    • Mirror Mint will query prices from Oracle Hub contract to allow minting operations on Mirror Protocol.
    • Users can simply query Oracle Hub contract to find which price feeds are available by using the asset’s symbol
    • The current oracle contract will be replaced by the new oracle contract

These contracts have been audited by Oak Security, please follow this link to read the audit report:


Hi Joe. Thanks for posting this. These generally would be nice improvements for Mirror, but a couple concerns.

I’m not sure that ending the poll early is a good idea. You can hit a quorum of 40% with 67% of those votes in favor, but that would only represent ~27% of the possible votes.

Let’s pretend a governance attacker (or group of attackers) is able to accumulate 27% of the MIR in governance. They make a poll which migrates to a malicious contract and immediately vote the 27% that they control. Now if votes against the change to the malicious contract come in, they contribute to quorum and as soon as those “no” votes make quorum reach 40%, the malicious contract is implemented—before the rest of the “no” votes which would block the poll come in.

By allowing the poll to end early, you are effectively creating a threshold of 27% of the governance stake to implement a contract migration. If you feel like there needs to be an option for ending a poll early/executing a change without the full 7 day delay, then I think something like “if 50% of all possible votes are in favor, then the poll ends early and is implemented” may be more appropriate and create less risk for a governance attack.

I believe the naming and description of this poll is a bit misleading/imprecise and would suggest that the language be changed to make more clear what this function would do. Specifically, as I understand it, this is not a delegation of the admin role, but rather a transfer since the governance contract has no way to revoke the admin rights after they are “delegated.” This risk was noted in the audit report and the dev response justifying this structure I think is reasonable, but I think calling it a delegation rather than a transfer creates an additional risk that people may not appreciate the significance/risks associated with this type of poll.


Allowing polls to end early before the full week of current voting period is mainly due to situations where critical bug has been found and it has to be fixed immediately.

Yes, you’re right when if someone gets 27% of the possible staked MIR votes, the polls will be voted against the benefit of the protocol, but at the same time, knowing that most of the polls that were on Mirror protocol had voting quorum quite small, it would even be difficult to have the poll valid (past the quorum), and have it passed / failed for one malicious party’s favor. So even the most important feature updates and bug fixes will be almost impossible to deliver.

40% quorum in our investigation seems sufficiently high enough to not let it pass in most occasions with minimum arguments, but not too high so that it could be pass-able enough for urgent situations.

About the naming of the poll
Yes your description seems more accurate. I will edit the post to make it more clear. But for this poll, the entire community should be expecting to do more due diligence to who they are voting for and what these entities / people are requiring this key rights for.

Having dealt with the critical bug scenario before, I definitely appreciate the value in being able to respond quickly.

The “27% attack” really is leveraging the fact that the bad actor knows when they will post the malicious poll and is therefore able to vote their stake first.

Maybe having a relatively short “minimum voting period” of say 24 or 48 hours before which the poll would not be immediately executed could be an alternative? Another option might be that rather than immediate execution after reaching quorum, there is a very short delay (say 6 hours) during which additional votes could still come in?

There is a single staker currently with over 27% of the vote. They could redirect and drain all funds in protocol if malicious.

What number do you think is a good quorum/threshold?
Increase them to 50% and 66.7% (same)?

Also, it’s 27% of the vote which means it would only take up to 27% of the forum. You’d need extra 13% to get it to be a valid poll.

As I understand it, if the malicious actor(s) votes their 27% first, the only way to stop the poll from executing would be to hope that the rest of the community does not vote at all to prevent the poll from reaching quorum.

Maybe it would be better to allow a one-day delay after reaching quorum to allow the community to respond and possibly fight off a malicious attack.

In general, there needs to be a better way to deal with malicious actors though. This was discussed before after the previous scam polls - that maybe a button can be added to report a malicious poll and if enough MIR voters agree it’s a malicious poll - deposit is lost. This would also force voters to consider whether a poll is a possible attack and require them to do due diligence.

Another idea was a pre-approval for any community spends - similar to how new mAssets need to be whitelisted, same idea for community spends, an extra layer of security.

1 Like