{"id":572,"date":"2023-09-13T11:35:28","date_gmt":"2023-09-13T09:35:28","guid":{"rendered":"https:\/\/ackeeblockchain.com\/blog\/?p=572"},"modified":"2024-07-10T16:13:09","modified_gmt":"2024-07-10T14:13:09","slug":"everstake-ethereum-staking-protocol-audit-summary","status":"publish","type":"post","link":"https:\/\/ackee.xyz\/blog\/everstake-ethereum-staking-protocol-audit-summary\/","title":{"rendered":"Everstake: 0.1+ ETH staking solution audit summary"},"content":{"rendered":"<p><a href=\"https:\/\/everstake.one\/\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">Everstake<\/span><\/a><span style=\"font-weight: 400;\"> is a responsible validator trusted by <\/span>625k+ users across 70+<span style=\"font-weight: 400;\"> blockchain networks created by engineers for the entire community in 2018. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">Everstake 0.1+ ETH staking solution is a protocol that allows users to deposit amounts that can be less than 32 ETH. Once users&#8217; deposits exceed 32 ETH, a new validator is created, and the users can start earning rewards. The staking rewards are restaked automatically, and the users&#8217; pool shares are increased.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Everstake engaged Ackee Blockchain to perform a security review of the Everstake protocol (Revision 1.0 and 2.0) for a total of <\/span>20 engineering days <span style=\"font-weight: 400;\">in a period between <\/span>July 3 <span style=\"font-weight: 400;\">and <\/span>August 29, 2023.<\/p>\n<p><span style=\"font-weight: 400;\">Everstake also engaged Ackee Blockchain to perform a fix review of the second audit revision on commit <\/span><span style=\"font-weight: 400;\"><code class=\"codehl\">38970a6<\/code>.<\/span><\/p>\n<h2><b>METHODOLOGY<\/b><\/h2>\n<p><b>Revision 1.0<\/b><\/p>\n<p><span style=\"font-weight: 400;\">We began our review by using static analysis tools, namely <\/span><span style=\"font-weight: 400;\">Woke<\/span><span style=\"font-weight: 400;\">. We then took a deep dive into the logic of the contracts. For testing and fuzzing, we have involved a <\/span><span style=\"font-weight: 400;\">Woke <\/span><span style=\"font-weight: 400;\">testing framework.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">During the review, we paid special attention to:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ensuring the accounting arithmetic of the system is correct<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span><span style=\"font-weight: 400;\">testing whether no unstaking path reverts<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">testing whether users can\u2019t withdraw more than they have deposited (+ rewards)<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">analyzing the management of the validators<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">detecting possible ETH call reentrancies in the code<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ensuring access controls are not too relaxed or too strict<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">testing if rewards are distributed according to users&#8217; shares<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">analyzing that the contracts use proper data structures for storing deposits, withdrawals, etc.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">analyzing the upgradeability pattern (storage collision, access control, etc.)<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">analyzing whether the withdrawal credentials are created correctly<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">looking for common issues such as data validation.\u00a0<\/span><\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><b>Revision 2.0\u00a0<\/b><\/p>\n<p><span style=\"font-weight: 400;\">We followed the methodology established in the previous revision:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">We focused on manually reviewing all the changes and wrote additional tests in <\/span><span style=\"font-weight: 400;\">Woke.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">We wrote a new simple differential fuzz test for the quick sort function and made it available in the <\/span><span style=\"font-weight: 400;\">Woke appendix.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">We also utilized <\/span><span style=\"font-weight: 400;\">Woke <\/span><span style=\"font-weight: 400;\">for static analysis, which was mainly useful for analysis of reentrancies.\u00a0<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">During the review, we had similar objectives as in the previous revision; additionally, we focused on:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">verifying that all the fixes were applied correctly<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">withdrawing edge-case amounts (like very small values, values equalling all shares, etc.)<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">minting shares and subsequent reward distribution<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">reviewing the integer-division-based loss of precision introduced in the amount-share conversions<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">reviewing the view functions (mainly _simulateAutocompound)<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">reviewing the new ordering logic of the validators<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">analyzing transaction ordering and front-running opportunities<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">reviewing the new upgradeability pattern. <\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span><\/li>\n<\/ul>\n<h2><b>SCOPE <\/b><\/h2>\n<p><b>Revision 1.0 <\/b><\/p>\n<p><span style=\"font-weight: 400;\">The audit has been performed on commit <\/span><span style=\"font-weight: 400;\"><code class=\"codehl\">60688fc<\/code>, <\/span><span style=\"font-weight: 400;\">\u00a0<\/span><span style=\"font-weight: 400;\">and the scope was the entire <\/span><span style=\"font-weight: 400;\">contracts <\/span><span style=\"font-weight: 400;\">folder:<\/span><b><\/b><\/p>\n<div class=\"page\" title=\"Page 10\">\n<div class=\"layoutArea\">\n<div class=\"column\">\n<pre>contracts\/\r\n\u251c\u2500\u2500 Accounting.sol\r\n\u251c\u2500\u2500 AutocompoundAccounting.sol \r\n\u251c\u2500\u2500 Governor.sol\r\n\u251c\u2500\u2500 Pool.sol\r\n\u251c\u2500\u2500 RewardsTreasury.sol\r\n\u251c\u2500\u2500 TreasuryBase.sol\r\n\u251c\u2500\u2500 WithdrawTreasury.sol \r\n\u251c\u2500\u2500 Withdrawer.sol\r\n\u251c\u2500\u2500 common\r\n\u2502\u00a0 \u00a0 \u00a0 \u2514\u2500\u2500 Errors.sol\r\n\u251c\u2500\u2500 interfaces\r\n\u2502 \u00a0\u251c\u2500\u2500 IAccounting.sol\r\n\u2502 \u00a0\u251c\u2500\u2500 IDepositContract.sol\r\n\u2502 \u00a0\u251c\u2500\u2500 IPool.sol\r\n\u2502 \u00a0\u251c\u2500\u2500 IRewardsTreasury.sol\r\n\u2502 \u00a0\u2514\u2500\u2500 ITreasuryBase.sol\r\n\u251c\u2500\u2500 lib\r\n\u2502 \u00a0\u251c\u2500\u2500 UnstructuredRefStorage.sol\r\n\u2502 \u00a0\u2514\u2500\u2500 UnstructuredStorage.sol\r\n\u251c\u2500\u2500 structs \r\n\u2502  \u251c\u2500\u2500 ValidatorList.sol \r\n\u2502  \u2514\u2500\u2500 WithdrawRequests.sol\r\n\u2514\u2500\u2500 utils\r\n\u00a0 \u00a0 \u00a0 \u251c\u2500\u2500 Math.sol\r\n\u00a0 \u00a0 \u00a0 \u2514\u2500\u2500 OwnableWithSuperAdmin.sol<\/pre>\n<\/div>\n<\/div>\n<\/div>\n<p>&nbsp;<\/p>\n<p><b>Revision 2.0 <\/b><\/p>\n<p><span style=\"font-weight: 400;\">The review was done on commit <\/span><span style=\"font-weight: 400;\"><code class=\"codehl\">35f9b56<\/code><\/span> <span style=\"font-weight: 400;\">and the files in scope were the same as in the previous audit. Since the last audit 45 new commits were made, a large number of those were fix commits and refactoring commits. The most notable changes were:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">adding upgradeability to treasuries<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">making interchange optional<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">modifying the ordering logic of the validators<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">adding gas optimizations<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">improving naming of the variables and adding comments<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">fixing the issues found in the previous audit.\u00a0<\/span><\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><b>Revision 2.1 <\/b> <span style=\"font-weight: 400;\"><br \/>\n<\/span><span style=\"font-weight: 400;\">We performed a fix review of the second audit revision on commit <\/span><span style=\"font-weight: 400;\"><code class=\"codehl\">38970a6<\/code><\/span><span style=\"font-weight: 400;\">.<\/span><\/p>\n<h2><b>FINDINGS<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Here, we present our <\/span><span style=\"font-weight: 400;\">findings<\/span><span style=\"font-weight: 400;\">.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><b>Revision 1.0<\/b><\/p>\n<h3><b>Critical severity\u00a0<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">No critical severity issues were found.\u00a0<\/span><\/p>\n<h3><b>High severity <\/b><\/h3>\n<p><b>H1: <\/b><span style=\"font-weight: 400;\">_simulateAutocompound can revert<\/span><\/p>\n<p><b>H2: <\/b><span style=\"font-weight: 400;\">DoS due to 0 pending deposits<\/span><\/p>\n<p><b>H3: <\/b><span style=\"font-weight: 400;\">Partial DoS due to interchange<\/span><\/p>\n<p><b>H4: <\/b><span style=\"font-weight: 400;\">DoS due to underflow <\/span><\/p>\n<h3><b>Medium severity<\/b><\/h3>\n<p><b>M1:<\/b><span style=\"font-weight: 400;\"> Missing whenWithdrawActive modifier<\/span><\/p>\n<p><b>M2:<\/b><span style=\"font-weight: 400;\"> Call to depositedBalanceOf reverts<\/span><\/p>\n<h3><b>Low severity<\/b><\/h3>\n<p><b>L1:<\/b><span style=\"font-weight: 400;\"> Withdraw request array monotonically grows<\/span><\/p>\n<p><b>L2: <\/b><span style=\"font-weight: 400;\">Lack of 2-phase role transfers <\/span><\/p>\n<p><b>L3: <\/b><span style=\"font-weight: 400;\">Exiting validators can revert<\/span><\/p>\n<p><b>L4:<\/b><span style=\"font-weight: 400;\"> Replacing validators lacks validation <\/span><\/p>\n<p><b>L5:<\/b><span style=\"font-weight: 400;\"> Validation of owner in treasuries<\/span><\/p>\n<p><b>L6:<\/b><span style=\"font-weight: 400;\"> Data validation in initialize functions<\/span><\/p>\n<p><b>L7:<\/b><span style=\"font-weight: 400;\"> Incorrect return value of _simulateAutocompound<\/span><\/p>\n<p><b>L8:<\/b><span style=\"font-weight: 400;\"> Upgradeable contract constructor without initializer<\/span><\/p>\n<p><b>L9:<\/b><span style=\"font-weight: 400;\"> Insufficient data validation when composing contracts <\/span><\/p>\n<h3><b>Warning severity <\/b><\/h3>\n<p><b>W1:<\/b><span style=\"font-weight: 400;\"> Usage of solc optimizer<\/span><\/p>\n<p><b>W2:<\/b><span style=\"font-weight: 400;\"> Dead code in _autoCompoundUserBalance<\/span><\/p>\n<p><b>W3:<\/b><span style=\"font-weight: 400;\"> Unchecked return of _update<\/span><\/p>\n<p><b>W4:<\/b><span style=\"font-weight: 400;\"> Lack of contract prefix in storage position<\/span><\/p>\n<p><b>W5:<\/b><span style=\"font-weight: 400;\"> Pool fee can be set extremely high <\/span><\/p>\n<h3><b>Informational severity <\/b><\/h3>\n<p><b>I1:<\/b><span style=\"font-weight: 400;\"> Used library<\/span><\/p>\n<p><b>I2: <\/b><span style=\"font-weight: 400;\">Comparison with role outside modifier<\/span><\/p>\n<p><b>I3:<\/b><span style=\"font-weight: 400;\"> Function always returns true<\/span><\/p>\n<p><b>I4:<\/b><span style=\"font-weight: 400;\"> Lack of logging in setters\u00a0 <\/span><\/p>\n<p><b>I5: <\/b><span style=\"font-weight: 400;\">Code and comment discrepancy<\/span><\/p>\n<p><b>I6:<\/b><span style=\"font-weight: 400;\"> Lack of documentation<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><b>Revision <\/b><b>2.0<\/b><\/p>\n<h3><b>Critical severity\u00a0<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">No critical severity issues were found.\u00a0<\/span><\/p>\n<h3><b>High severity <\/b><\/h3>\n<p><b>H5: <\/b><span style=\"font-weight: 400;\">Withdrawal of autocompoundBalanceOf amount reverts<\/span><\/p>\n<h3><b>Medium severity<\/b><\/h3>\n<p><b>M3: <\/b><span style=\"font-weight: 400;\">simulateAutocompound checks only balance diff <\/span><\/p>\n<h3><b>Low severity<\/b><\/h3>\n<p><b>L10: <\/b><span style=\"font-weight: 400;\">Pending deposited can&#8217;t be withdrawn <\/span><\/p>\n<p><b>L11:<\/b><span style=\"font-weight: 400;\"> Lack of call to disableInitializers()<\/span><\/p>\n<p><b>L12:<\/b><span style=\"font-weight: 400;\"> Lack of 0 shares check in simulateAutocompound<\/span><\/p>\n<p><b>L13:<\/b><span style=\"font-weight: 400;\"> Lack of 0 shares check in feeBalance\u00a0<\/span><\/p>\n<h3><b>Warning severity <\/b><\/h3>\n<p><b>W6:<\/b><span style=\"font-weight: 400;\"> Withdraw can return by 1 wei more than requested<\/span><\/p>\n<p><b>W7: <\/b><span style=\"font-weight: 400;\">Withdrawal revert due to rounding\u00a0<\/span><\/p>\n<p><b>W8:<\/b><span style=\"font-weight: 400;\"> unstakePending and activateBalance can revert due to bad timing <\/span><\/p>\n<h3><b>Informational severity <\/b><\/h3>\n<p><b>I7: <\/b><span style=\"font-weight: 400;\">Code duplication for ownership <\/span><\/p>\n<p><b>I8:<\/b><span style=\"font-weight: 400;\"> Typos in code and comments\u00a0<\/span><\/p>\n<p><b>I9:<\/b><span style=\"font-weight: 400;\"> Array length validation <\/span><\/p>\n<h2><b>CONCLUSION<\/b><\/h2>\n<p><b>Revision 1.0<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Our review resulted in <\/span><b>26 findings<\/b><span style=\"font-weight: 400;\">, ranging from <\/span><i><span style=\"font-weight: 400;\">Info<\/span><\/i><span style=\"font-weight: 400;\"> to <\/span><i><span style=\"font-weight: 400;\">High<\/span><\/i><span style=\"font-weight: 400;\"> severity. The highest severity issues were related to <\/span><b>denial of service<\/b><span style=\"font-weight: 400;\"> and the <\/span><b>inability to view the state of the protocol <\/b><span style=\"font-weight: 400;\">due to underflow reverts.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Overall, we do not recommend deploying the current version of the protocol. During the audit, we discovered a couple of issues that caused the protocol to revert, although the state was achieved only through normal, non-malicious transactions.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This implies that the protocol is not sufficiently tested. Additionally, we found the documentation to be lacking, so we dedicated a separate <\/span><span style=\"font-weight: 400;\">informational issue <\/span><span style=\"font-weight: 400;\">to this.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">At the same time, we would like to acknowledge that the development team was able to find some of the issues independently of our review (i.e., both the teams found it independently of each other), most notably, it was <\/span><span style=\"font-weight: 400;\">H3<\/span><span style=\"font-weight: 400;\">. Additionally, during the audit, we observed multiple clever design decisions in the <\/span><i><span style=\"font-weight: 400;\">Pool<\/span><\/i><span style=\"font-weight: 400;\"> and <\/span><i><span style=\"font-weight: 400;\">Accounting<\/span><\/i><span style=\"font-weight: 400;\"> contracts.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">However, due to the high number of issues, including high-severity ones, some work needs to be done to make the protocol production-ready.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Due to the high number of issues, lack of documentation and the fact that the protocol reverted in certain scenarios, our auditing processes were slowed down. As such, we do not feel certain that the protocol will be fully secure after the fixes are applied. We strongly recommend pursuing another audit round, though a shorter one, to ensure that the protocol is secure.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><b>Revision 2.0<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Our second review resulted in <\/span><b>12 findings<\/b><span style=\"font-weight: 400;\">, ranging from <\/span><i><span style=\"font-weight: 400;\">Info<\/span><\/i><span style=\"font-weight: 400;\"> to <\/span><i><span style=\"font-weight: 400;\">High<\/span><\/i><span style=\"font-weight: 400;\"> severity. The highest severity issue related to <\/span><b>integer-division-based error, <\/b><span style=\"font-weight: 400;\">which in certain protocol states resulted in <\/span><b>withdrawal reverts<\/b><span style=\"font-weight: 400;\"> and thus caused <\/span><b>temporal lock of users&#8217; funds.<\/b><span style=\"font-weight: 400;\"><br \/>\n<\/span> <span style=\"font-weight: 400;\"><br \/>\n<\/span><span style=\"font-weight: 400;\">The code quality in the second revision was significantly improved. The code was more readable (mainly due to the use of better names for variables) and the documentation was better. Almost all issues from the previous revision were fixed.<\/span><\/p>\n<p><span style=\"font-weight: 400;\"><br \/>\n<\/span><span style=\"font-weight: 400;\">Based on the observations made during the review, <\/span><b>we recommend focusing on the following high-level objectives<\/b><span style=\"font-weight: 400;\">:<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The documentation is still lacking and could be improved.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Due to the occurrence of another rounding-based issue, we recommend fuzzing.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Protocol to ensure that no other subtle off-by-one errors are present.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Another bug was uncovered in the <\/span><span style=\"font-weight: 400;\">_simulateAutocompound <\/span><span style=\"font-weight: 400;\">function, it is recommended to rethink the approach of writing the simulations and use a more organized and structured approach.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Avoid overly complicated and overengineered solutions like in the case of the reorderings and replacements of validators, such optimizations are not usually worth it in the long run.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">Fix all the reported issues.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><b>Revision 2.1<\/b><span style=\"font-weight: 400;\"><br \/>\n<\/span> <span style=\"font-weight: 400;\"><br \/>\n<\/span><span style=\"font-weight: 400;\">We consider all the issues to be fixed correctly. We believe that by fixing the <\/span><span style=\"font-weight: 400;\">H5 rounding issue <\/span><span style=\"font-weight: 400;\">no other rounding issues that would cause reverts in main user flows are present. Yet still we recommend fuzzing the protocol to analyze the protocol\u2019s behavior in random scenarios and protocol states. <\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span><\/p>\n<p><b>Ackee Blockchain\u2019s full <\/b><b><i>Everstake<\/i><\/b><b> audit report with a more detailed description of all findings and recommendations can be found <\/b><a href=\"https:\/\/github.com\/Ackee-Blockchain\/public-audit-reports\/blob\/master\/2023\/ackee-blockchain-everstake-staking-report.pdf\" target=\"_blank\" rel=\"noopener\"><b>here<\/b><\/a><b>.<\/b><\/p>\n<p><span style=\"font-weight: 400;\">We were delighted to audit<\/span><b> Everstake<\/b><span style=\"font-weight: 400;\"> and look forward to working with them again.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Everstake is a responsible validator trusted by 625k+ users across 70+ blockchain networks created by engineers for the entire community in 2018. Everstake 0.1+ ETH staking solution is a protocol that allows users to deposit amounts that can be less than 32 ETH. Once users&#8217; deposits exceed 32 ETH, a new validator is created, and the users can start earning rewards. The&hellip;<\/p>\n","protected":false},"author":15,"featured_media":573,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,10,80],"tags":[21,24,112,68],"class_list":["post-572","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-audits","category-ethereum","category-solidity","tag-audit","tag-ethereum","tag-everstake","tag-solidity"],"aioseo_notices":[],"featured_image_src":"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2023\/09\/Everstake-600x400.png","featured_image_src_square":"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2023\/09\/Everstake-600x600.png","author_info":{"display_name":"Aleksandra Yudina","author_link":"https:\/\/ackee.xyz\/blog\/author\/aleksandra-yudina\/"},"_links":{"self":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts\/572","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/users\/15"}],"replies":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/comments?post=572"}],"version-history":[{"count":0,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts\/572\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/media\/573"}],"wp:attachment":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/media?parent=572"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/categories?post=572"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/tags?post=572"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}