Cosmoon will support this proposal
2 Likes
Iceberg Nodes supports this proposal and we look forward to use this additional feature when will be available and audited.
Thank you 
1 Like
We support this idea. I think itās a good way to reward small delegators, and balance between all the matchers. we will use the contract once it is audited.
1 Like
As long as itās not Certik, I am all for it.
1 Like
Like is mentioned above want that 0xTaylord do it the audit
2 Likes
What is wrong with Certik?
1 Like
Happy new year!
I have received the following quote from Chaintroopers:
āOur estimate for the above is that we will need 12 work days to cover the delegator (1) and 5 days for the oracle (2). That would be at 17 workdays bringing up the cost to $42.5k. Weād be happy to apply a 20% first time audit discount which would bring the total to $34k.ā
I donāt think that we need to do an oracle audit, as it doesnāt provide any security benefits. therefore, I assume that the final quote for an official audit is $24K (waiting for confirmation on that).
So, this gives the treasury 3 options:
- no audit
- one-man audit by Taylor at $10K (at $250 per hour)
- āofficialā firm audit by Chaintroopers at $24K
1 Like
I come from a BSC background. Many of the projects they audited had hidden mint functions and many other holes that made me question their validity as an auditor.
3 Likes
Thank you for the information, Ioannis. It would be very appreciated if @0xTaylor could share his experience. Taylorās experience could provide a more comprehensive view when considering him as an auditor
1 Like
Thanks. I asked Taylor to post his CV here. Both quotes have the same hourly rate but Chaintroopers quoted many more days. Itās a fairly complicated contract, so, just wanted to also ask Taylor if the 10K would allow him to perform a full audit.
3 Likes
Hi, Iām 0xTaylor, a seasoned Web2 security consultant with a decade of experience in conducting offensive security assessments for Fortune 100 entities across various verticals. My foray into the realm of Web3 security began as a hobby in the summer of 2021, when I completed the highly regarded Secureum Epoch 0 bootcamp for smart contract auditing, sponsored by The Ethereum Foundation, Trail of Bits, Consensys Diligence, and Sigma Prime. My repository on the subject has garnered significant attention, amassing nearly 600 stars on GitHub and being referenced in numerous Twitter threads and blog posts. (https://github.com/x676f64/secureum-mind_map)
While my past experience in the realm of smart contract auditing has largely been limited to an advisory capacity, I have successfully disclosed a Web3 vulnerability to RomeDAO and assisted the Moonbeans team in resolving an issue with their smart contracts that had vexed them. Additionally, I served as a technical adviser for the RMRK EVM contracts development process and created a distribution contract for the ChaosDAO MOVR validator participants, which can be reviewed at the following link: https://github.com/ChaosDAO-org/ApeStrapper. In my capacity as a security auditor, I am well-versed in the nuances of this technology and am enthusiastic about the opportunity to contribute to this project.
While I operate pseudonymously in Web3, I am willing to disclose my identity to the Moonbeam team if you wish to verify my credentials further. Please do not hesitate to reach out to me privately should you have any further questions.
2 Likes
Thank you for your detailed response, Taylor. personally, I like your experience. if the community chooses you as an auditor, how much will your services cost and how long will it take?
also, if I understand correctly, if we take, for example, Chaintroopers, then the degree of their responsibility for the code they audited may depend on the terms of the agreement between the auditor and the client. but, what does this practice actually look like, if a vulnerability is suddenly discovered in a part of the code that they have audited, will they compensate for the losses?
iām just trying to figure out if there is a difference in audit quality, or advantages between you and Chaintroopers
1 Like
I think that ācode insuranceā is beyond the scope and my guess is Chaintroopers does not include something like that. They just put their name on the line, which is probably enough of an incentive.
Also, note that the quoted rate is the same by both Chaintroopers and Taylor (what differs is the manhours), so I think the main question is if Taylor can also provide 100% coverage (as Chaintroopers says it will).
2 Likes
I cannot speak for Chaintroopers there. Personally, I would be able to offer no guarantees or warranties of the work performed as this is a point-in-time, time boxed limited audit using a snapshot of the code.
I bill a flat rate of $250/hr USD. Initially, when Sik reached out to me to see if I was interested, I knew he and Ioannis were self-funding so I quoted them 10-20 hrs of work. In that timeframe I could perform a manual review of the main core contracts, write some of my own test cases, and maybe sneak in some property based fuzzing. I had already started on some test cases because I wanted to play with it either way https://github.com/x676f64/movr-validator-cover/blob/main/test/testDepositStaking.sol. Ultimately, I was planning to deliver specific technical findings in markdown but not a full technical report as I understood it to be for their own consumption mostly and it would have increased the price.
However, with the Foundations support, spending 5 to 10 days reviewing the codebase would result in a more complete review. Budget constraints ultimately dictate the time constraints. For a 5 day effort, there would be 1 day of reporting and a 10 day effort would warrant 2 days of report writing.
For my methodology, I like to read over the documentation and then have a walk-through discussion with the developer. Through this, I will attempt to mental model potential areas of attack or weakness. With that, I will attempt to prove or disprove my notions. I follow that up with, a manually walk over the contract again using the Solcurity checklist: https://github.com/transmissions11/solcurity with PR7 applied.
Hopefully this gives you a more complete picture of things but I am happy to continue to answer any other questions you or anyone else may have.
4 Likes
Sorry for coming up late to the discussion.
I think those initiatives are great in general 
Concerning this āStaking Rewards Insuranceā, I have some doubts about its benefit.
Currently, when a collator falls into the tail of the top candidates, the collator has less staked GLMR than others and so provide a higher distribution to delegators than other collators (for the same amount of produced blocks).
That mechanism incentivize people who are interested in the GLMR highest distribution to consider more the collators at the bottom of the list.
If, as you suggested, the āreward insuranceā works by preventing people to āunstakeā when the collator is out for 1 or few rounds, it means that the ācompetitionā to stay in will go on for longer and you will need more GLMR to pay them. I think it is ādelayingā the exit of a collator, at a high cost, than āpreventingā it.
Technically: Currently I think you donāt need an oracle, but simply allowing anyone call the contract to āstoreā if the collator(s) is selected and then later to call the SC to ācheckā if the collator(s) has awardedPoints (and distribute the payout if needed). It is less automated than an oracle but probably more reliable and simple (the risk being that nobody calls the āstoreā during the round)
2 Likes
Thank you for your input Alan!
The mechanism that you describe works well to even out the distribution. Still, thousands of delegators have found themselves receiving zero rewards because they delegated to a collator that was kicked out. When they delegated again, they avoided collators with in the bottom of the list. Offering insurance could help reassure them a little, but I donāt think thatās were the main benefit lies.
When a collator goes out for one round undelegations start rolling in. This is more of a problem for community collators than whales because they rely on their delegators. Delaying that death spiral is vital for community collators. The cost is like 9 MOVR per day (12 rounds), so itās super-low price to pay if it can stop the undelegation of thousands of MOVR.
More than anything, insurance is a way for the collator to put their money where their mouth is. For example. Collator A is a professional collator that runs backup servers and failover services. He knows this and he knows he has 0.001% risk of downtime. On the other hand, collator B runs a server at home without a UPS. He knows he has 1% risk of downtime. For collator A the risk-adjusted price of the insurance contract is 5 MOVR. For collator B the risk-adjusted price is 500 MOVR. However, the benefits of the contract are the same for both collators. This sums to up a more fair, competitive, and frictionless environment where the best can thrive over the worst. Itās also why insurance is many times the size of the entire crypto market.
Ultimately, I think that the users that want this the most are the delegators themselves. For most people, staking should be a set-and-forget affair. Choosing a collator that offers to cover them for missed rounds (for up to a specific duration) could mean that they have to check stakemovr oner per month instead of every day (there goes our traffic 
).
On the technical points - I would love to get the oracle logic out but I donāt think itās currently possible. Please correct me if I am wrongā¦
- We can check if a collator was selected with the staking precompile but we cannot check if they were offline (server down) during an entire round
- I donāt think there is a way to ācall the SC to ācheckā if the collator(s) has awardedPointsā; maybe this is a new method in the precompile?
1 Like
I kindly disagree here. The incentive to delegate to the tail of the list via higher APY is countered by the fear of loosing out on rewards for a week āsoonā when the collator sits on rank 63-68 and the waiting list is full of sharks ready to jump in. If people see the revocations flying in and do the math on the probability of the collator to stay active they probably stay away after a big revoke came in, despite the high APY. The only ones who can step in risk free are people who themselves can ensure that the collator of their choice will make it through the storm.
We also have several collators that made it back to the active set after dropping out, even for several rounds. That for sure has to do with personal preference of wealthy benelovent actors and can not be turned into a rule but for up to 3 rounds Iād say there is a realistic chance to keep delegators from revoking when they still receive rewards during that time. once they made the decision to revoke itās game over tho. I barely witnessed anyone canceling his revoke.
2 Likes
It is true that the higher rewards for delegating with collators at the bottom of the set is an incentive for many delegators. But many delegators are also concerned about lost rewards if their delegator falls out of the set. Granted, often that fall from the active set is permanent and the collator can never recover. But that isnāt always the case ā we have seen many times a collator fall out for a round or two and then recover.
Seems to me that offering insurance would contribute to higher delegations for at risk collators and thus avoid the fall in the first place. Also, if there is a fall from the set, insurance seems like it would delay the revocation cycle and increase the odds of survival for the collator.
2 Likes
Thank you for the replies.
Concerning the benefit of using the reward insurance to protect against nodes having the resources to self-sustain, it also means that they can provide a higher insurance (which might be more attractive). This is the case already for CEXs which offer staking through their platform and āguaranteeā a certain rewards even if their node is down some rounds or missing blocks.
Overall it will benefit the delegators but less likely the collators.
Also, the insurance you are proposing is going to fight mostly against other node of the community who canāt afford to self-delegate more. The new candidates at the moment are people or companies with a large amount of tokens (to be able to reach the minimum needed to join the top collators). I donāt think those are worried about being at the bottom of the list or being kicked out. But maybe Iām wrong on this one.
Technically there are more precompile getters/setters being added for the new version (RT2100). I can check if the AwardedPts/TopCollators are there, which is enough to know if a collator was down or out.
Also, if this is considered a good solution by the community, I invite you to include the insurance mechanism inside the staking pallet (in Moonbeam github repo) directly. Someone from the team can help you with the design/implementation, and we already have audit in place for all the code that goes into our pallets.
Good points.
On the ability of bigger players to provide more insurance - Iāve thought about it myself, so I included a hard cap on the max insurance amount to kill the rat race. We can decide what a sensical value might be, but something like a month worth of coverage would be 300 movr for a collator with 27K backing.
I agree that the new candidates in town are nodes that care less about delegations. Itās actually part of the reason we want to offer insurance to our delegators - to show that we care. Also, as you say, it would make community collators that have it more competitive than those that donāt. But thatās what any competitive service/product does, i.e. one cannot design against such quality. The node that cannot afford to self-delegate more is the node that cannot afford to lose one big delegation, and it is that node that can use insurance to keep that delegation and attract the next one.
To get rid of the oracles, we would need AwardedPts, and a list of the top 300 delegators per collator, their delegation amounts to that collator and pending undelegation/revoke requests. If we only have AwardedPts we canāt remove the oracles but we can reduce risk, so do let us know for sure.
Canāt speak about the teamās intentions to include this in a pallet, but I think that insurance is āderivativeā enough to be a good use case for the precompile.