[Proposal: XX] Audit for Staking Rewards Insurance Cover Contract

Governance Treasury Proposals
, ,
1

[Proposal: 6] [Status: Idea] Audit for Staking Rewards Insurance Cover Contract

Abstract

We (StakeBaby) have developed a smart contract + oracle solution that enables collators to offer staking rewards insurance to their delegators. In other words, delegators can claim missed rewards due to their collator being down, or out of the active set. StakeBaby would like to seek funding from the treasury to pay for a contract audit.

Motivation

StakeBaby has spent 3 months developing the cover contract and associated oracle software. We do not think that an audit makes sense from a business perspective, and we could not afford a full-fledged audit by a popular firm anyways. However, we do think the contract will add value to the Moonbeam and Moonriver ecosystems, and thus, an audit might make sense from the Treasury’s perspective.

Project Overview and Team Experience

Collators deposit MOVR on the contract. The funds are locked and serve as a security deposit, should that collator miss a round or more. If the collator misses a round, their deposit is reduced, and the accounts of their delegators are credited accordingly. Delegators must execute a transaction to claim the cover rewards. They can do so from their account’s cover dashboard at stakemovr.com.

Since there is no on-chain method to check collator performance or get delegator information, the data must be fed into the contract through an oracle quorum. Only collators will be able to run oracles (one each).

You can find the collator-how-to draft article that explains the contract’s features and risks here:

StakeBaby has created stakemovr.com and stakeglmr.com. Both websites run on AWS, with dozens of microservices, real-time chain indexing, and 100GB-scale DB tables. In regard to Solidity, most of our experience has been in developing GitHub - ioannist/crowdrecords: A Decentralized Music Collaboration Platform

Rationale

Rewards cover will contribute towards the diversification and performance of the collator active set

  • Delegators tend to avoid collators in the bottom 15% by total backing because they fear that they will exit the active set. The rewards cover could subside some of that fear, help the weakest collators, level out the playing field, and keep the set diversified.
  • The cover contract allows for more efficient allocation of rewards risk. Currently, only delegators can assume this risk. With the cover contract, capable collators will be able to assume the risk at will.
  • The cover contract should foster healthy competition between collators and more responsibility in keeping their nodes online.
  • Finally, the cover contract will give community or delegator-backed collators, an opportunity to shine through. Anonymous, whale-backed, wallet-type collators, have no reason to provide cover, so this will be an opportunity for delegator-serving collator to differentiate.

Overall Cost

$10K to pay a Solidity security expert to audit the contract.

If the treasury board members believe we should get a full audit by a professional auditing firm, the cost would be higher. The main advantage would be higher adoption by collators.

Use of Treasury Funds

At $250 per hour, $10K would buy 40 manhours. Therefore, we would only have one milestone, that is the delivery of the audit.

Specifications

Solidity contracts + Truffle for testing

Oracle is built in Golang to provide a binary executable.

You can find the contract to be audited at

Line breakdown

Language files code comment blank total
JavaScript 6 2,334 182 354 2,870
Solidity 20 1,834 991 356 3,181

The associated oracle software is here

Steps to Implement

1 Solidity security expert, auditing on the contract for 1 week

8 Likes
2

Hey, Ioannis, first of all, thank you for all your valuable services that you provide, our community really appreciates it!

I think this is a very amazing proposal, and it will partially help eliminate the fear of delegators when a collator stops generating rewards for some reason.
imo, audits have become popular lately because they give users extra confidence, so I think it’s necessary.

the only thing would be nice to hear the opinion of collators, whether they are ready to deposit some funds to the contract

3 Likes
4

Cool! Most community collators are already aware of the contract. Can you ask them in the discord collator channel? I tried posting a link to this thread but got blocked!

2 Likes
5

yeah, sure thing will do!

2 Likes
6

I heard this idea from Ioannis several months ago and I’m very happy (and amazed) to hear that it’s already finalized and ready to be audited

First I think it’s a great idea since it gives another layer of engagement of the collator to his delegators. I believe delegators will feel much safer if they know they are protected from situation where their collator is inactive for any reason. We already know that even being inactive for only 1 round can cause a significant amount of revocation that will eventually kill the collator. Hence, this insurance idea is definitely a way to (try) to prevent it

Finally, I really like it and will be interested to deposit some amount

4 Likes
7

This is a unique idea that Ioannis has come up with and brought to life. I agree that it will provide delegators with more comfort in delegating to collators that are lower in the set, which tend to be community collators. If the code is audited, CertHum will definitely lock up some reserves to cover the risk of stopped delegator rewards due to the scenarios outlined in the proposal.

3 Likes
8

Thank you very much for the proposal @stakebaby , I find it interesting, so that the community nodes can maintain their delegators a little more and maintain enough funds to not be expelled from the active set despite losing a round

Now I have read that the collator must choose the maximum amount that he wants to cover x round (if necessary)

for example in moonbean,

if i have 20k glmr staked that yields around 2 glmr per round if i’m not wrong

if the node fails or leaves the active set for 2 rounds and the collator only covers up to 10k

would I receive 2 GLMR? for those 2 failed rounds ( 1glmr x round)?

I have understood well ?

1 Like
9

And who would the audit be with? do you already have the information?

1 Like
10

Correct! You would receive 1 GLMR per round instead of 2.

The idea is to allow collators to incentivize delegators to split their stake among multiple collators. Collators deactivate this feature if they want (it’s deactivated by default).

Note that, collators cannot set the max covered delegation BELOW a specific amount (so there is a Minimum Maximum covered delegation). The minimum will be relatively high, so think 500-1000 MOVR. Therefore, collators cannot abuse this feature to exclude delegators by setting a very low max. They can only use it to limit coverage for very large delegations.

Obviously, if a delegator really wants to, they can send the funds to another address and split their delegation to avoid the limit. However, it is much more convenient for them to just delegate to another collator from the same address.

2 Likes
11

It seems to me that the purpose of offering a higher APR for lower delegated collators is to evenly distribute the delegated stake across the active set. Unfortunately, the perceived risk of the collator becoming inactive near the bottom is preventing that even distribution. This insurance contract will ease the perception of risk and thus assist in achieving a more even distribution of stake over the active set. We support this idea and intend to participate in the contract when finished.

2 Likes
12

I am already in touch with discord user 0xTaylor. I was introduced to him by Sik. He has experience in Moonbeam and auditing.

1 Like
13

I guess it might also reduce the RUN FOR THE DOOR behavior we see when a collator is kicked out, thereby giving them a chance to recover. It’s mostly community collators that are burdened by this (especially when a huge revoke happens). If a delegator unstakes from a cover collator that is OUT or DOWN, they stop receiving rewards cover, just like they would if that collator was still IN and ACTIVE. So, delegators are incentivized to give the collator a chance to recover. Depending on the cover period, a delegator may have days or weeks to make up their mind without losing any rewards.

2 Likes
14

Hi Ioannis

This is a great idea, nice to see a safety net for delegators. Despite all the research a delegator can do to choose the best collator, accidents and user errors happen. Sometimes it can be scenarios outside of the collators control.

2 Likes
15

Perfect, thanks for the answer sir,

I find it very useful, both for delegators and collators, so it gives you a recovery time without losing a large amount of staked funds

ok something I see is that a lot of action is necessary on the part of stakebaby, at the beginning, after how long, this process will be more independent of you

If I read correctly,
don’t get me wrong, I would just like to know a timeframe so that in case you no longer want to participate or be aware of this process, the collators can continue using it

1 Like
16

Hey @stakebaby Regarding the security of the smart contract, what’s the real risk to collators and delegators? Is there a risk of funds being stolen/drained?

1 Like
17

We support this proposal and ioannis. Cheers bud!

With respect to the alert that will get triggered from web3go/others are there any plans to consider this insurance as a cover before firing alerts?

2 Likes
18

Np. There are a couple of things that must happen before we can remove sudo

  1. Moonbeam must activate smart contract access to the proxy precompile (read-only access to isProxy is enough)
  2. the contract should have at least 15-20 oracles

We don’t control the timing for (1) but I have inquired about it in discord builders, and it looks promising.

Oracle adoption will probably be gradual. Collator members that don’t run oracles must pay the members that run oracles a membership fee that StakeBaby sets. This setup guarantees that the contract can keep running without our participation. We just have to find and set the right fee that results in enough oracles.

Removal of sudo will mean that StakeBaby cannot control oracle membership anymore, and only collators can run oracles (one each). After that, StakeBaby will still have the right to

  1. veto a quorum report, in order to reject an attack from a large number of malicious oracles
  2. manage contract funds staking

Should we decide to stop managing the contract, we can transfer management of the above to other addresses (separately). Note that the contract can continue working without 1 and 2 just fine.

1 Like
19

Excluding bugs, the only important attack vector is the oracle quorum. If one can control the quorum, they can submit a false report that initiates cover claims to a specific delegator/s from any collator/s they want.

Overtaking the quorum would require to control at least a quorum count of collators in the active set. So, one would need to control 15 collators if the quorum is 15.

Even if they do, and submit a false report, the contract has several security mechanisms to avoid or minimize the damage. For a complete list, please check the “How safe is my deposit” answer here:
https://medium.com/@stakebaby/b087bec750ac

The worst case scenario is that collators lose their deposits.

Note that, many contracts have similar risk profiles (bridges, pools, etc.) and most users, have no clue. Using an Oracle quorum is the only way (currently) to implement this contract.

2 Likes
20

You can ask web3go to implement this if you want. Anybody can query the contract for that info.

2 Likes
21

We at Blockshard support this proposal, as we believe it’s a useful initiative especially for community collators.

2 Likes