[Proposal- Discussion] Block Voting From External Contracts

Mirror community ,

As you may or may not be aware Terra recently got it’s first yield optimizer https://spec.finance/. This was long overdue and is a great addition to the ecosystem. However now that we have protocols that hold a sizable amount of community funds , this introduces new risks in to the ecosystem.

Mirror V2 recently introduced rewards for voting participants to incentivize active governance participation.

Spec has decided to implement auto Mirror GOV voting in to it’s autocompounding strategies , and this strategy will basically auto vote “abstain” on all proposals to earn yield for voting. I see this approach of voting as useless governance input, and really goes against the whole purpose of incentivizing governance participation . And while sure someone could write a bot to do this, most people wont, and a protocol doing this on chain with a centralization of community funds is risky and bad for the decentralization of Mirror governance.

Not only that , we should not allow unapproved contracts to vote on mirror goverance as such protocols could amass a large amount of community owned gov tokens, and then possibly maliciously use those community funds to grant a would be attacker funds from the community spend pool (im not accusing spec of this , just something to be wary about as the ecosystem grows) .

Thus we should by default blacklist all contracts from voting on mirror proposals. Leave open the ability to whitelist contracts, but as of right now i dont see a situation where this would be a good idea .

Im interested in hearing the community’s feedback on this issue.



Ensuring that polls consistently reach quorum via abstention votes actively increases the power of active voters, rather than decreasing their power. The decision will still be made based on the balance of yes/no votes.

While SPEC’s system adds nothing to governance, there are other potential systems that would. For example, somebody could write a smart-contract that lets a controller vote the entire pool in governance, while giving them 0 control of the funds… enabling non-custodial staking… delegating your voting authority to somebody that has a better understanding of the ecosystem and is willing to do the research on various proposals as they arise (governance via representation).
Blocking all protocol contracts from active participation in governance would eliminate these types of governance systems that could add substantial value to governance.

Actively differentiating between user accounts and protocol accounts weakens the ecosystem and ensures that mirror protocol can never become a ‘money lego’ in the terra ecosystem, since holding MIR in governance directly will always strictly dominate holding MIR via third-party systems.


But you wont have problems reaching qurom if governance participants are properly incentivized which i believe Mirror V2 does quite well. A protocol providing useless input simply to get part of those rewards disincentives real governance participants who will provide useful (real) input.

Totally agree, but this is why i think we need a blacklist all approach with the ability to whitelist contracts. For example passthrough voting, where spec holders could vote on the proposals and that would be the vote that gets selected for all autocomponded MIR. But with this approach we need to be wary of a protocol granting it’s self community spend.

There’s a fair differentiation. Spec’s auto voting in it’s current implementation provides no useful input to governance.


Thanks for writing this up.

I think this is basically a required upgrade. We must incentivize the right type of behavior, not gaming.


The gov contract in MIR can simply check whether the address attempting to claim rewards belongs to a smart contract and deny claims if they are.

TFL strongly supports this modification in the next release.


Thanks Do. Appreciate the attention here. I think in the future it might be worth considering a whitelist approach as this will enable some interesting representative governance concepts. As far as effort goes probably easiest to blacklist contracts for the time being and if the idea of representative governance becomes popular we could maybe come up with implementation specifications. (Probably a risk to allow contracts to vote on community spend in such an implementation)

1 Like

@papi @dokwon

Fully understand the concerns re:

  • Unverified/unaudited smart contract interacting with the protocol
  • Pooling of funds by the contract to vote maliciously

Could the following be acceptable alternatives that Spec could pursue:
(1) Towards the end of the proposal period, auto-voting in the exact same proportion of votes so that it leaves the voting outcome unchanged.
(2) Auto-voting yes, if the concern is that abstention is detrimental to a proposal.

In the future, there will be smart contracts that allow people to delegate their votes to asset managers, and they would entrust the asset managers to vote on their behalf. If this is the case, then taking an approach to blanket block smart contracts may be an issue for asset managers with delegated MIR.

I have been backing some asset management protocols, and I think that delegated MIR is certainly going to be something to think about. Blocking them completely would not be a good outcome.

Also, just blocking smart contracts, may lead to unacceptable/risky workarounds, e.g. sending it to non-contract addresses for the purposes of voting.

This takes away from the rewards that actual gov participants would otherwise receive for providing their real input.

The concern is garbage governance input does not provide any real input to governance proposals, and takes away from real governance participants.

The only solution i see here is passthrough voting, or representative voting where spec holders indirectly vote on mirror governance proposals. But as is , this approach presents other risks to mirror that should be mitigated before this behavior is allowed (ie a protocol voting it’s self community spend)

I agree that for the time being these types of auto-votes should be blacklisted by default. I do think that there is potential for whitelisting in scenarios where individuals want to delegate their voting rights to another individual/entity, but this is obviously not one of those scenarios. Votes should be purposely put forth in governance, never auto-selected. The whole point of the change in v2 was to incentivize voting participation in governance, and the feature that Spec is attempting to provide completely circumvents this.

1 Like

Your passthrough voting idea is a good approach. This means that those who delegate still need to take responsibility on the votes.

Plus also agree with your comment re: safeguards to prevent abuse.

1 Like

It might be worthwhile waiting to see some of these protocols get some traction before taking action.

Seems to be premature to design countermeasures to attacks that have yet to manifest.

1 Like

Agree, not implying any immediate action in my governance proposal, more so using governance to signal community sentiment around this issue , and specifically in this case help guide spec or any future yield optimizer who wants to build strategies that incorporate governance.

1 Like

Also to add , in this specific case Spec has now withdrawn their vote farming proposal.


The gov contract in MIR can simply check whether the address attempting to claim rewards belongs to a smart contract and deny claims if they are.

And so the community begins destroying itself. Disenfranchisement of particular types of voters because the way they vote is disagreeable… this is antithetical to DeFi in the strongest imaginable way.

ON a more practical level… what about multi-custodial treasuries managed by smart contract? What about DAO’s? What about Spar protocol? What about unannounced projects that are working toward representation models (stake your MIR into the module, module selects a single party to vote all of the MIR staked into the module)?

What about every other as yet unimagined use of MIR (including its governance module) in other protocols that will not happen because of the communities rejection of the very first external protocol that tried to engage in MIR governance in the least impactful way possible?

This is an over exaggeration . Voters gaming voting rewards while not providing real goverance input arnt really voters.

In the metaverse smart contract is law, if smart contracts allow a certain behavior , it’s allowed by law. If Mirror is going to allow smart contracts to vote on proposals in a representive manner , the risks need to be strongly considered . In the current implementation of mirror governance , these risks have not been fully considered . And so in the interim until these risk are fully evaluated and proper mitigation and implementation details are hashed out, i think it’s reasonable to

A. Gauge community sentiment on this issue. Potentially indicating future action if risks are realized

This also encourages protocols who plan to engage in this behavior to be cautious and to engage with the community about their plans to incorporate goverance in to their yield strategies.

B. Have these discussions.

Given your concerns here, what do you propose as an alternative solution?

1 Like

Agreed on the passthrough vote.

QQ: Why would we not require any group that wants to utilize this type of mechanism (handling governance votes in an automated / semi automated fashion) in their design to also create similar workflow to corporate voting. If you own shares in tradfi companies, you typicall get a ping through your brokerage account that there is a proxy vote that is available. Based on the number of proposals in the MIR ecosystem, this seems a reasonable amount of activity for: 1) A company that wants to build a thoughtful project on Terra to spec a solution (holder is pinged to vote when new prop is available) and 2) A holder of auto compounded tokens to vote on.

Admittedly perhaps we just aren’t here yet - thus block and then rework a solution. But of we are it seems like we could require projects to add a proxy push as part of the build specification.

Is this the thought with a passthrough?


1 Like

To clarify my point on blacklisting… I don’t think this means all contracts should be blocked, just those that auto-select the voting option for the participant. Automatically choosing Abstain for everyone, as in this example, should not be the way to go. However, if each participant chose their vote (be it ‘Abstain’ or another) and then Spec passed this vote through to governance, that would be fine. I don’t know if a ‘blacklist all contracts’ approach is the best one to take without some middle ground specification. After discussing on Discord, one acceptable method would be a time-lock mechanism where contracts could propose their method in advance, and if not opposed, would pass by default. This would effectively be a holding period where any bad actions could be halted before they take place. This would help to protect the governance without blocking new protocols from innovation. If the Mirror governance community decided to take no action, then that would count as support in this scenario.

So IF an attack does take place we then have to ??? clean up the damage afterwards.
Is there any ability of the protocol to compensate in this theoretical situation?

The attack vector here is known, this type of governance attack doesn’t happen overnight and requires a considerable build up of community funds, specifically governance tokens.

There’s is no immediate threat . Spec finance respects the community’s concerns here and have withdrawn their plans to implement voting strategies .

And assuming the proposal passes on “YES” this will make it clear to future protocols that this type of goverance interaction is generally frowned upon and against community sentiment. And if the risk ever became real measures could be implemented to mitigate or eliminate the risk.

It’s something to monitor and bring awareness to.

1 Like

Thanks for the clarification to my concern, and Spec has done the right move, I also have interests in Spec as many others in the Terra system. And appreciate you for bringing attention to this potential weakness.