[MRC-11] Renew Temporary Delegations

Authored by:
@traianoverse with helpful inputs by @larry0x

Summary

This proposal aims to provide funding of 25 million MARS to a smart contract mars18a2u6az6dzw528rptepfg6n49ak6hdzkf8ewf0n5r0nwju7gtdgqzczfke (source code here) through which the temporary delegation program can be extended. This smart contract will manage the distribution of the delegations.

Abstract

At present, without any intervention, after the temporary delegations are removed and returned to the community pool (which will require a 14-day unbonding period), the first two validators will collectively hold a voting power of over 30%.
A single entity controlling 33% of the total stake can compromise consensus and potentially lead to censorship, ultimately causing the chain to come to a halt.

Motion

To mitigate this risk, we propose expanding the delegation program by distributing 25 million tokens among all validators, not limited to genesis operators.

Delegation Criteria

The following are the measures to manage and be entitled to the temporary delegation program:

  • Given that these funds belong to the community, validators with a commission exceeding 5% will not be taken into account for a temporary delegation.

Implementation

This proposal aims to allocate funds from the community pool to the entitled address. However, a separate proposal is necessary to execute the delegations

5 Likes

Why renew the delegation? At current staked amount the APY to stake will be greater than 50% which would likely result in a lot of MARS holders staking their tokens & thereby organically increasing security. Renewing will keep the APY low and we will come back to the same problem the subsequent month as everyone prefers the higher APY in the LP.

1 Like

I’m in favor of extending the delegation program for another month, but there are a few considerations:

  1. The current delegations totalling 50M MARS are managed by a smart contract (mars1nc5…) which we shall call it the “delegator” contract. This contract does not has the functionality of unbonding only a portion of tokens. It is programmed to unbond the *entire* delegations and return all unbonded tokens to community pool.

    Instead of modifying this contract, it is easier to deploy a new contract (“delegator 2”) and have it make new delegations. This will involve two governance proposals:

    • fund delegator 2 with tokens from he community pool
    • execute the delegations
  2. Whereas delegator 1 only delegates to genesis validators, for delegator 2 we can have it delegate evenly to all validators in the active set.

  3. 35M may be an overkill; considering the current circulating supply and available liquidity of MARS token in exchanges, 25M should be sufficient. A smaller amount also results in a higher staking APR which incentivizes more token holders to delegate.

3 Likes

Thx for initiating the discussion @ExpeditionMars. I reducing the delegation by only 15M isn’t enough.

I support @larry’s adjustment. Considering there’s only 16M MARS staked atm, it’s too big of a risk to cancel the entire loan delegation. However the loan delegation for month 2 should be the minimum the community is comfortable with as it dilutes overall staking rewards.

25M is the right number imo, hopefully this increases staking rewards sufficiently to cancel the entire loan delegation buy next month.

1 Like

Ideally we do without altogether, but since there’s only 16M MARS staked atm imo an extension of the loan is required due to safety concerns.

See also my reply to @larry’s comment.

Hey @Bitcoin_Sage, thanks for your feedback. I’ve just adjusted the draft with Larry’s comments. Let me know what you think.

1 Like

awesome, thx! Re-reading the prop, there’s one other point I disagree with:

I don’t think the protocol should discriminate on the above and should strive to stay as neutral as possible by default. Spreading the delegation amongst all validators in the active set is already to the detriment of current validators who have a high % of tokens delegated. The rule above ‘punishes’ these validators even more.

1 Like

Gradual change as proposed should be sufficient to reduce the chance of a high risk event.

I’ve incorporated your feedback.
I think the criteria related to the percentage of commissions is enough, if a validator does not want to receive the temporary delegation, he can increase the commissions to 6% and thus express his will.

1 Like

I agree with Larry’s suggestion above.

I also agree with Larry’s suggestion above. I think the proposal as written right now sounds like a good balance of providing security to the chain without diluting the APR too much.

1 Like

we currently have a 3rd validator enter the fray with 2.8m tokens.
so if we remove the initial delegations now there will be ~3 validators with above 2M
2 with 800k and several (including me) at 400k.

I don’t see a single entity holding 33% any longer.

I believe the temporary delegations have served their purpose.
Also remember the team still holds a lot of voting tokens, so they can still step in if they choose if they see voting irregularities.
but as for consensus… it isn’t ideal, but it isn’t critical, and community pool could be used to reward validators providing utility to the channel (via regular governance votes)

1 Like

Shouldnt this proposal include the undelegation of the 50M from the previous contract?

Just to address this. With current prices, a 33% attack would only cost $5million, not taking into account wallets with a lot of liquid Mars.

For delegator 1, once the ending time is elapsed , anyone can invoke a method on the contract to unbond these delegations. Once unbonding is completed, anyone can invoke refund to return all funds to the community pool.

Source: Releases · mars-protocol/periphery · GitHub

you assume they can simply get purchased OTC in a single lump-sum.
I don’t think the markets are that liquid

Given that the active validator set was voted and passed to increase to 75 max, we currently have a handful of validators that have very little track record of uptime or blocks signed. Potentially some of these validators could be much more likely to be slashed that others. Since this proposal would aim to distribute delegations linearly across all validators, should some stipulations be added in the case of slashing events? Should the community funds be redelegated in the event one of the new validators severely underperforms, or does the time period and/or amount make this risk negligible?

1 Like