# Table of Contents - [Welcome to Ankr Docs — Ankr](#welcome-to-ankr-docs-ankr) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) --- # Welcome to Ankr Docs — Ankr Welcome to Ankr Docs Welcome to Ankr Docs ==================== Ankr is the leading Web3 infrastructure company. It has a set of different products for building, earning, gaming, and more — all on blockchain. ![](https://www.ankr.com/docs/build/rpc-welcome.png) This documentation explains how to use Ankr's products and services as a developer as well as a regular Web3 user. From [public RPC endpoints (opens in a new tab)](https://www.ankr.com/rpc/) that developers have come to know and love, alongside new [Premium and Enterprise plans (opens in a new tab)](https://www.ankr.com/rpc/pricing/) packed with [advanced developer tools (opens in a new tab)](https://www.ankr.com/advanced-api/) — all powered by a globally distributed and decentralized network of nodes. Node API[](https://www.ankr.com/docs/#node-api) ------------------------------------------------ ![](https://www.ankr.com/docs/build/node-api.png) * Access RPC/REST Endpoints via HTTPS or WebSockets. * Interact with 80+ [supported blockchains](https://www.ankr.com/docs/rpc-service/chains/chains-list/) . * Test out and get important stats. * Suitable for Web3 developers and enthusiasts of all skill levels. [Empower your projects with blockchain interaction](https://www.ankr.com/docs/rpc-service/overview/) ↗ Advanced API[](https://www.ankr.com/docs/#advanced-api) -------------------------------------------------------- ![](https://www.ankr.com/docs/build/aapi.png) * Access a specifically-tailored collection of JSON-RPC API endpoints. * Interact with 19 mainnet and 7 testnet chains supported. * Use Ankr JavaScript/Python SDKs and React Hooks. * Tailored to support most popular Web3 scenarios. [Query multiple chains for most popular Web3 scenarios](https://www.ankr.com/docs/advanced-api/overview/) ↗ Contract Automation[](https://www.ankr.com/docs/#contract-automation) ---------------------------------------------------------------------- ![](https://www.ankr.com/docs/build/contract-auto.png) * Execute contract functions based on various triggers. * Choose time-based or event based automation. * Rely on robust Ankr infrastructure for your automation tasks. * Easily manage automation tasks from a single dashboard. [Automate calls to contracts](https://www.ankr.com/docs/automation/overview/) ↗ Scaling Services[](https://www.ankr.com/docs/#scaling-services) ---------------------------------------------------------------- ![](https://www.ankr.com/docs/build/scaling.png) * Transition from Web2 to Web3 seamlessly. * Choose between two major products-as-a-service: Sidechains or Rollups. * Deploy a fast and secure network. * Choose additional components from Developer Marketplace. [Bring your project to Web3](https://www.ankr.com/docs/scaling-services-overview/) ↗ Staking[](https://www.ankr.com/docs/#staking) ---------------------------------------------- ![](https://www.ankr.com/docs/build/staking.png) * Easily stake 5+ tokens on a secure, decentralized network. * Earn rewards on tokens without needing technical knowledge. * Connect staking rewards to DeFi to trade/farm for even higher APY. * Integrate Ankr Staking into your projects. [Stake, earn, and integrate](https://www.ankr.com/docs/staking-overview/) ↗ Gaming[](https://www.ankr.com/docs/#gaming) -------------------------------------------- ![](https://www.ankr.com/docs/build/gaming.png) * Take your game to the next level — Web3. * Launch your Web3 monetization strategy. * Integrate Web3 wallets easily. * Compatible with Unity and Unreal Engine. [Take your game to Web3 (opens in a new tab)](https://mirage.xyz/docs/) ↗ Tutorials[](https://www.ankr.com/docs/#tutorials) -------------------------------------------------- ![](https://www.ankr.com/docs/build/tutorials.png) * Learn how to develop Smart Contracts, build dApps, explore tools and frameworks, and more. * Find getting-started tutorials, guides and follow along to ship cool stuff. * Explore code guides, tools, tutorials, and resources you need to write and deploy smart contracts. * Find end-to-end tutorials to build and ship full-fledged decentralized applications. [Learn and practice Web3](https://www.ankr.com/docs/basic-tutorials/dapp-on-ethereum-using-nocode/) ↗ [Information Map](https://www.ankr.com/docs/info-map/ "Information Map") --- # Unknown Public SMART CONTRACT AUDIT REPORT for ANKR Protocol Prepared By:Patrick Lou PeckShield July 9, 2022 1/17PeckShield Audit Report #: 2022-102 Public Document Properties ClientANKR TitleSmart Contract Audit Report TargetANKR Protocol Version1.0 AuthorPatrick Lou AuditorsPatrick Lou, Xuxian Jiang Reviewed byXiaotao Wu Approved byXuxian Jiang ClassificationPublic Version Info VersionDateAuthor(s)Description 1.0-rc1March 19, 2022Patrick LouRelease Candidate #1 1.0July 9, 2022Patrick LouFinal Release Contact For more information about this document and its contents, please contact PeckShield Inc. NamePatrick Lou Phone+86 156 0639 2692 Emailcontact@peckshield.com 2/17PeckShield Audit Report #: 2022-102 Public Contents 1 Introduction4 1.1 About ANKR Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 About PeckShield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Findings9 2.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Key Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3 Detailed Results11 3.1 Properly Update State Variables in burnAndSetPending()/updatePendingBurning() . 11 3.2 Improved Validation Checks In distributeManual() . . . . . . . . . . . . . . . . . . . 12 3.3 Trust Issue of Admin Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4 Conclusion16 References17 3/17PeckShield Audit Report #: 2022-102 Public 1 | Introduction Given the opportunity to review the design document and related smart contract source code of the ANKRprotocol, we outline in the report our systematic approach to evaluate potential security issues in the smart contract implementation, expose possible semantic inconsistencies between smart contract code and design document, and provide additional suggestions or recommendations for improvement. Our results show that the given version of smart contracts can be further improved due to the presence of several issues related to either security or performance. This document outlines our audit results. 1.1 About ANKR Protocol TheANKRliquid staking is an enhanced method of staking on theBNB Smart Chain(previouslyBSC). The enhancement allows the users to stake their funds through the corresponding smart contracts onANKR, accumulate rewards, and receive their stakes as well as rewards when unstaking. The basic information of the audited protocol is as follows: Table 1.1: Basic Information of ANKR Protocol ItemDescription NameANKR TypeBSC Smart Contract PlatformSolidity Audit MethodWhitebox Latest Audit ReportJuly 9, 2022 In the following, we show theMD5hash value of the compressed file used in this audit: •MD5(BNB.zip)=f44d26579438b7b2f43b6cd6d5ed659f And here is the finalMD5hash value of the compressed file after all fixes for the issues found in the audit have been checked in: • MD5(BNB.zip)=b8616b15df08e972030e2a757fd9bde3 4/17PeckShield Audit Report #: 2022-102 Public 1.2 About PeckShield PeckShield Inc. \[7\] is a leading blockchain security company with the goal of elevating the secu- rity, privacy, and usability of current blockchain ecosystems by offering top-notch, industry-leading services and products (including the service of smart contract auditing). We are reachable at Telegram ( https://t.me/peckshield), Twitter (http://twitter.com/peckshield), or Email (contact@peckshield.com). Table 1.2: Vulnerability Severity Classification Impact HighCriticalHighMedium MediumHighMediumLow LowMediumLowLow HighMediumLow Likelihood 1.3 Methodology To standardize the evaluation, we define the following terminology based on the OWASP Risk Rating Methodology \[6\]: •Likelihood represents how likely a particular vulnerability is to be uncovered and exploited in the wild; • Impact measures the technical loss and business damage of a successful attack; • Severity demonstrates the overall criticality of the risk. Likelihood and impact are categorized into three ratings:H,MandL, i.e.,high,mediumand lowrespectively. Severity is determined by likelihood and impact and can be classified into four categories accordingly, i.e.,Critical,High,Medium,Lowshown in Table 1.2. To evaluate the risk, we go through a checklist of items and each would be labeled with a severity category. For one check item, if our tool or analysis does not identify any issue, the contract is considered safe regarding the check item. For any discovered issue, we might further deploy contracts on our private testnet and run tests to confirm the findings. If necessary, we would 5/17PeckShield Audit Report #: 2022-102 Public Table 1.3: The Full Audit Checklist CategoryChecklist Items Basic Coding Bugs Constructor Mismatch Ownership Takeover Redundant Fallback Function Overflows & Underflows Reentrancy Money-Giving Bug Blackhole Unauthorized Self-Destruct Revert DoS Unchecked External Call Gasless Send Send Instead Of Transfer Costly Loop (Unsafe) Use Of Untrusted Libraries (Unsafe) Use Of Predictable Variables Transaction Ordering Dependence Deprecated Uses Semantic Consistency ChecksSemantic Consistency Checks Advanced DeFi Scrutiny Business Logics Review Functionality Checks Authentication Management Access Control & Authorization Oracle Security Digital Asset Escrow Kill-Switch Mechanism Operation Trails & Event Generation ERC20 Idiosyncrasies Handling Frontend-Contract Integration Deployment Consistency Holistic Risk Management Additional Recommendations Avoiding Use of Variadic Byte Array Using Fixed Compiler Version Making Visibility Level Explicit Making Type Inference Explicit Adhering To Function Declaration Strictly Following Other Best Practices 6/17PeckShield Audit Report #: 2022-102 Public additionally build a PoC to demonstrate the possibility of exploitation. The concrete list of check items is shown in Table 1.3. In particular, we perform the audit according to the following procedure: • BasicCodingBugs: We first statically analyze given smart contracts with our proprietary static code analyzer for known coding bugs, and then manually verify (reject or confirm) all the issues found by our tool. •SemanticConsistencyChecks: We then manually check the logic of implemented smart con- tracts and compare with the description in the white paper. •AdvancedDeFiScrutiny: We further review business logics, examine system operations, and place DeFi-related aspects under scrutiny to uncover possible pitfalls and/or bugs. • AdditionalRecommendations: We also provide additional suggestions regarding the coding and development of smart contracts from the perspective of proven programming practices. To better describe each issue we identified, we categorize the findings with Common Weakness Enumeration (CWE-699) \[5\], which is a community-developed list of software weakness types to better delineate and organize weaknesses around concepts frequently encountered in software devel- opment. Though some categories used in CWE-699 may not be relevant in smart contracts, we use the CWE categories in Table 1.4 to classify our findings. Moreover, in case there is an issue that may affect an active protocol that has been deployed, the public version of this report may omit such issue, but will be amended with full details right after the affected protocol is upgraded with respective fixes. 1.4 Disclaimer Note that this security audit is not designed to replace functional tests required before any software release, and does not give any warranties on finding all possible security issues of the given smart contract(s) or blockchain software, i.e., the evaluation result does not guarantee the nonexistence of any further findings of security issues. As one audit-based assessment cannot be considered comprehensive, we always recommend proceeding with several independent audits and a public bug bounty program to ensure the security of smart contract(s). Last but not least, this security audit should not be used as investment advice. 7/17PeckShield Audit Report #: 2022-102 Public Table 1.4: Common Weakness Enumeration (CWE) Classifications Used in This Audit CategorySummary ConfigurationWeaknesses in this category are typically introduced during the configuration of the software. Data Processing IssuesWeaknesses in this category are typically found in functional- ity that processes data. Numeric ErrorsWeaknesses in this category are related to improper calcula- tion or conversion of numbers. Security FeaturesWeaknesses in this category are concerned with topics like authentication, access control, confidentiality, cryptography, and privilege management. (Software security is not security software.) Time and StateWeaknesses in this category are related to the improper man- agement of time and state in an environment that supports simultaneous or near-simultaneous computation by multiple systems, processes, or threads. Error Conditions, Return Values, Status Codes Weaknesses in this category include weaknesses that occur if a function does not generate the correct return/status code, or if the application does not handle all possible return/status codes that could be generated by a function. Resource ManagementWeaknesses in this category are related to improper manage- ment of system resources. Behavioral IssuesWeaknesses in this category are related to unexpected behav- iors from code that an application uses. Business LogicWeaknesses in this category identify some of the underlying problems that commonly allow attackers to manipulate the business logic of an application. Errors in business logic can be devastating to an entire application. Initialization and CleanupWeaknesses in this category occur in behaviors that are used for initialization and breakdown. Arguments and ParametersWeaknesses in this category are related to improper use of arguments or parameters within function calls. Expression IssuesWeaknesses in this category are related to incorrectly written expressions within code. Coding PracticesWeaknesses in this category are related to coding practices that are deemed unsafe and increase the chances that an ex- ploitable vulnerability will be present in the application. They may not directly introduce a vulnerability, but indicate the product has not been carefully developed or maintained. 8/17PeckShield Audit Report #: 2022-102 Public 2 | Findings 2.1 Summary Here is a summary of our findings after analyzing the implementation of theANKRprotocol. During the first phase of our audit, we study the smart contract source code and run our in-house static code analyzer through the codebase. The purpose here is to statically identify known coding bugs, and then manually verify (reject or confirm) issues reported by our tool. We further manually review business logic, examine system operations, and place DeFi-related aspects under scrutiny to uncover possible pitfalls and/or bugs. Severity# of Findings Critical0 High1 Medium1 Low1 Informational0 Total3 We have so far identified a list of potential issues: some of them involve subtle corner cases that might not be previously thought of, while others refer to unusual interactions among multiple contracts. For each uncovered issue, we have therefore developed test cases for reasoning, reproduction, and/or verification. After further analysis and internal discussion, we determined a few issues of varying severities need to be brought up and paid more attention to, which are categorized in the above table. More information can be found in the next subsection, and the detailed discussions of each of them are in Section 3. 9/17PeckShield Audit Report #: 2022-102 Public 2.2 Key Findings Overall, these smart contracts are well-designed and engineered, though the implementation can be improved by resolving the identified issues (shown in Table 2.1), including1high-severity vulnerability, 1medium-severity vulnerability and1informational recommendation. Table 2.1: Key ANKR Protocol Audit Findings IDSeverityTitleCategoryStatus PVE-001HighProperly Update State Vari- ablesinburnAndSetPend- ing()/updatePendingBurning() Coding PracticesFixed PVE-002LowImproved Validation Checks In dis- tributeManual() Coding PracticesFixed PVE-003MediumTrust Issue of Admin KeysSecurity FeaturesConfirmed Besides the identified issues, we emphasize that for any user-facing applications and services, it is always important to develop necessary risk-control mechanisms and make contingency plans, which may need to be exercised before the mainnet deployment. The risk-control mechanisms should kick in at the very moment when the contracts are being deployed on mainnet. Please refer to Section 3 for details. 10/17PeckShield Audit Report #: 2022-102 Public 3 | Detailed Results 3.1 Properly Update State Variables in burnAndSetPending()/updatePendingBurning() •ID: PVE-001 •Severity: High •Likelihood: High •Impact: High •Target:BinancePool\_R2 •Category: Coding Practices \[4\] •CWE subcategory: CWE-563 \[2\] Description TheANKRliquid staking allows the users to stake their funds through the corresponding smart contracts on theBNB smart chain, accumulate rewards, and receive their stakes/rewards when unstaking. While reviewing theunstake()logic, we notice that the function logic ofaBNBb\_R2::burnAndSetPending() needs to be corrected. To elaborate, we show below thisburnAndSetPending()function. The function is called at the end of theBinancePool\_R2::unstake()to burn the corresponding staked bonds as well as reset some contract state variables to reflect the amount changes of the unstaked bonds (lines214-217). It comes to our attention that it does not update the\_totalStakedstate variable which stores the value of total staked bonds. In other words, the\_totalStakedstate is incorrectly updated, hence leading to an incorrect calculation of the exchange ratio between bonds amount and underlying shares (in the updateRatio()function). More specifically, there is a need to reflect the deduction of total staked bonds. 209function burnAndSetPending(address account , uint256 amount) 210public 211override 212onlyBondMinter 213{ 214\_pendingBurn\[account\] = \_pendingBurn\[account\] + amount; 215\_pendingBurnsTotal = \_pendingBurnsTotal + amount; 11/17PeckShield Audit Report #: 2022-102 Public 216uint256 sharesToBurn = \_bondsToShares(amount); 217\_totalUnbondedBonds += amount; 218\_burn(account , sharesToBurn); 219emit Transfer(account , address (0), amount); 220} Listing 3.1:aBNBb\_R2::burnAndSetPending() Also we notice there is another similar case which does not update the\_totalUnbondedBondsstate variable. During the unstaking process, upon the cross-transaction completion, theBNBbackend service executesBinancePool\_R2::distributeRewards()to distribute stakes and rewards to the users. It will invoke the followingupdatePendingBurning()function in which the related state variables are updated (lines229-230). It comes to our attention that the\_totalUnbondedBondsis not updated as it should be the same as inburnAndSetPending()function. Namely, we need to reflect the total unbounded bonds amount change by the following statement:"\_totalUnbondedBonds -= amount". 209function updatePendingBurning(address account , uint256 amount) 210public 211override 212onlyBondMinter 213{ 214uint256 pendingBurnableAmount = \_pendingBurn\[account \]; 215require(pendingBurnableAmount >= amount , "amount is wrong"); 216\_pendingBurn\[account\] = pendingBurnableAmount - amount; 217\_pendingBurnsTotal = \_pendingBurnsTotal - amount; 218} Listing 3.2:aBNBb\_R2::updatePendingBurning() RecommendationProperly update the\_totalStakedand\_totalUnbondedBondsstate variables as suggested above. StatusThis issue has been fixed in the following latest code package. • MD5(bnb.zip)=b8616b15df08e972030e2a757fd9bde3 3.2 Improved Validation Checks In distributeManual() •ID: PVE-002 •Severity: Informational •Likelihood: NA •Impact: NA •Target:BinancePool\_R2 •Category: Coding Practices \[4\] •CWE subcategory: CWE-563 \[2\] 12/17PeckShield Audit Report #: 2022-102 Public Description In theBinancePool\_R2contract, thedistributeManual()function is used to distribute stakes and rewards to the specific user manually if thedistributeRewards()function failed to do so for the user. It is used as a way to make sure the specific user can receive the stakes and rewards in case of the user fails to get them viadistributeRewards(). While reviewing the function, we notice that there is an issue with the condition check on whether to proceed with the function execution. To elaborate, we show below thisdistributeManual ()function. Specifically, it validates the balance of this contract to ensure there is enoughBNBleft to transfer to the user (lines207-210). In this case, theamountvariable stores the amount ofBNB that will be sent to the user and it only needs to checkaddress(this).balance >= amountinstead of the current logicaddress(this).balance >= amount + stashedForManualDistributes(line208). 192function distributeManual(uint256 id) external nonReentrant { 193require( 194markedForManualDistribute\[id\], 195"not marked for manual distributing" 196); 197address \[\] memory claimers = new address \[\](1); 198uint256 \[\] memory amounts = new uint256 \[\](1); 199 200address claimer = \_pendingClaimers\[id\]; 201address payable wallet = payable(address(claimer)); 202uint256 amount = pendingClaimerUnstakes\[claimer \]; 203 204markedForManualDistribute\[id\] = false; 205stashedForManualDistributes -= amount; 206 207require( 208address(this).balance >= amount + stashedForManualDistributes , 209"insufficient pool balance" 210); 211claimers \[0\] = claimer; 212amounts \[0\] = amount; 213IInternetBond(\_bondContract).updatePendingBurning(claimer , amount); 214pendingClaimerUnstakes\[claimer\] = 0; 215 216(bool result , ) = wallet.call{value: amount }(""); 217require(result , "failed to send rewards to claimer"); 218delete \_pendingClaimers\[id\]; 219 220emit RewardsDistributed(claimers , amounts , 0); 221} Listing 3.3:BinancePool\_R2::distributeManual() RecommendationRevise the abovedistributeManual()function to properly validate the con- tract balance check as below. 13/17PeckShield Audit Report #: 2022-102 Public 207require( 208address(this).balance >= amount , 209"insufficient pool balance" 210); Listing 3.4:BinancePool\_R2::BinancePool\_R2() StatusThis issue has been fixed in the following latest code package. •MD5(bnb.zip)=b8616b15df08e972030e2a757fd9bde3 3.3 Trust Issue of Admin Keys •ID: PVE-003 •Severity: Medium •Likelihood: Low •Impact: High •Target:Multiple Contracts •Category: Security Features \[3\] •CWE subcategory: CWE-287 \[1\] Description In theANKRprotocol, there are privilegedowner/minter/operatoraccounts that play a critical role in governing and regulating the system-wide operations (e.g., mint and burn aBNBb tokens). These privileged accounts also have the capability of controlling or governing the flow of assets managed by this protocol. Our analysis shows that these privileged accounts need to be scrutinized. In the following, we examine these privileged accounts and the related privileged accesses in current contracts. To elaborate, we show below example privileged routines in multiple contracts. These routines al- low theowner/minter/operatoraccounts to mint newaBNBb, set system parameters, distribute rewards, etc. 26function mint(address account , uint256 shares) public onlyMinter { 27\_lockedShares = \_lockedShares - int256(shares); 28\_mint(account , shares); 29emit Transfer(address (0), account , shares); 30} 31 32function burn(address account , uint256 amount) public override onlyMinter { 33uint256 shares = \_bondsToShares(amount); 34\_lockedShares = \_lockedShares + int256(shares); 35\_burn(account , shares); 36emit Transfer(account , address (0), amount); 37} Listing 3.5:aBNBb\_R2::mint()/burn() 14/17PeckShield Audit Report #: 2022-102 Public 255function setMinimumStake(uint256 minStake) external onlyOperator { 256\_minimumStake = minStake; 257} 258 259function getRelayerFee () external view returns (uint256) { 260return \_tokenHub.getMiniRelayFee (); 261} 262 263function changeIntermediary(address intermediary) external onlyOwner { 264\_intermediary = intermediary; 265} 266 267function changeBondContract(address bondContract) external onlyOwner { 268\_bondContract = bondContract; 269} 270 271function changeTokenHub(address tokenHub) external onlyOwner { 272\_tokenHub = ITokenHub(tokenHub); 273} Listing 3.6:BinancePool\_R2::Multiple Functions It would be worrisome if each privilegedowner/minter/operatoraccount is a plain EOA account. Note that a multi-sig account could greatly alleviate this concern, though it is still far from perfect. Specifically, a better approach is to eliminate the administration key concern by transferring the role to a community-governed DAO. In the meantime, a timelock-based mechanism can also be considered as mitigation. RecommendationPromptly transfer the privileged account to the intendedDAO-like governance contract. All changed to privileged operations may need to be mediated with necessary timelocks. Eventually, activate the normal on-chain community-based governance life-cycle and ensure the in- tended trustless nature and high-quality distributed governance. StatusThis issue has been confirmed. 15/17PeckShield Audit Report #: 2022-102 Public 4 | Conclusion In this audit, we have analyzed the design and implementation of theANKRprotocol, which allows the users stake their funds through the corresponding smart contracts, accumulate rewards, and receive their stakes and rewards when unstaking. During the audit, we notice that the current code base is well organized and those identified issues are confirmed and fixed. Moreover, we need to emphasize thatSolidity-basedsmart contracts as a whole are still in an early, but exciting stage of development. To improve this report, we greatly appreciate any constructive feedbacks or suggestions, on our methodology, audit findings, or potential gaps in scope/coverage. 16/17PeckShield Audit Report #: 2022-102 Public References \[1\] MITRE. CWE-287: Improper Authentication. https://cwe.mitre.org/data/definitions/287.html. \[2\] MITRE. CWE-563: Assignment to Variable without Use. https://cwe.mitre.org/data/ definitions/563.html. \[3\] MITRE. CWE CATEGORY: 7PK - Security Features. https://cwe.mitre.org/data/definitions/ 254.html. \[4\] MITRE. CWE CATEGORY: Bad Coding Practices. https://cwe.mitre.org/data/definitions/ 1006.html. \[5\] MITRE. CWE VIEW: Development Concepts. https://cwe.mitre.org/data/definitions/699.html. \[6\] OWASP. Risk Rating Methodology. https://www.owasp.org/index.php/OWASP\_Risk\_Rating\_ Methodology. \[7\] PeckShield. PeckShield Inc. https://www.peckshield.com. 17/17PeckShield Audit Report #: 2022-102 --- # Unknown FTM SmartContractSecurityAudit V1.1 No.202203241830 Mar24 th ,2022 FTM-StakeSecurityAudit Contents Summaryofauditresults...................................................................................................................................1 1Overview...........................................................................................................................................................3 1.1ProjectOverview.....................................................................................................................................3 1.2AuditOverview.......................................................................................................................................3 2Findings.............................................................................................................................................................4 \[FTM-1\]Operatorhasahighauthority.........................................................................................................5 \[FTM-2\]swapFeeOperatorisnotinitializedandcannotbemodified..........................................................7 \[FTM-3\]Incorrectfunctioncall....................................................................................................................8 \[FTM-4\]Centralizationrisk..........................................................................................................................9 \[FTM-5\]Thecorrespondingeventisnottriggered.....................................................................................10 \[FTM-6\]Publicfunctionscanbedeclaredexternal....................................................................................12 \[FTM-7\]Tokennameandsymbolcanbemodifiedarbitrarily..................................................................13 3Appendix.........................................................................................................................................................14 3.1VulnerabilityAssessmentMetricsandStatusinSmartContracts........................................................14 3.2AuditCategories....................................................................................................................................16 3.3Disclaimer.............................................................................................................................................18 3.4AboutBEOSIN.....................................................................................................................................19 FTMSecurityAudit 1 Summaryofauditresults Afterauditing,1High-risk,3Low-risksand3InfoitemswereidentifiedintheFTMproject.Specific auditdetailswillbepresentedintheFindingssection.Usersshouldpayattentiontothefollowingaspects wheninteractingwiththisproject: \* Notes:  RiskDescription: 1.Centralizationrisk ThecontractownerintheFTMprojecthasfullcontrolofthecontract.Theownercansettheoperator address,andboththeownerandoperatoraddressescanmodifykeyparametersinthecontract.Forsome parameters,onlytheownerhasthepermissiontomodify.Theprojectpartyrepliestoretaintheowner's fullcontroloverthecontract.Theremaybesomecentralizationrisk. ProjectDescription: 1.BasicTokenInformation TokennameAnkrFantomRewardEarningBond TokensymbolaFTMb Decimals18 Pre-mint0 TotalsupplyInitialsupplyis0(Mintable,burnable) TokentypeERC-20 FTMSecurityAudit 2 TokennameAnkrFTMRewardBearing Certificate TokensymbolaFTMc Decimals18 Pre-mint0 TotalsupplyTheinitialsupplyisthesameasthe totalamountofaFTMbtokenshares atthetimeofdeployment(Mintable, burnable) TokentypeERC-20 2.Businessoverview TheFTMprojectcontainstwotokencontractsandtwobusinesscontracts.IntheaFTMbtokencontract,the numberofsharesisrecordedinsidethecontract,andwhattheuserqueriesisthenumberofbonds.Sharesand bondsareconvertedaccordingtoacertainratio(theratiocanbearbitrarilymodifiedbytheowneroroperator address).IntheaFTMctokencontract,thetotaltokensupplyisthesameasthenumberofsharesinthe aFTMbtokencontract.aFTMbtokensandaFTMctokenscanbeswappedintheaFTMbtokencontract,anda certainfeemaybechargedfortheswap.UserscanstakeFTMtokensintheFantomPoolcontracttoobtain aFTMbtokens,andtheFTMstakedbytheusercanbesenttotheFantomStubcontractbytheowneror operatoraddress.WhenuserswithdrawtheFTMtokensstakedbytheFantomPoolcontract,theyneedtobe operatedbytheoperatoraddressbeforetheycanbesuccessfullywithdrawn.TheFantomStubcontractis mainlyusedtointeractwiththeSFCcontract.TheSFCcontractisnotwithinthescopeofthisaudit. FTMSecurityAudit 3 1Overview 1.1ProjectOverview ProjectNameFTM PlatformFantom FileHash(SHA256) aFTMb\_R1.sol fc9d30dbff297974ff329783440eb2de9d44a7b6dfa8684d30 2395d34e7ccb4f(Initial) 67dd52344781a6a23d33b57a4d637e7482bfa2c9c4357765c 8a167faf4b6cef5(Final) FantomPool\_R1.sol a5871b1cc5430b6d5f57f5e3287efc53f7c9678d7377d0bdb2 b8ba9dc5def3ac(Initial) ecfce4e30fa1dcf1954165f48ec0c00b5c8de2f40f141b4bae9 5dba249812942(Final) FantomStub\_R0.sol ab4f9c1a0d0f8cca7af7d314faeeb7fb5decb62db60a0682c87 a1b97e6924f86 aFTMc\_R0.sol 82e828d7adb1923c2beb5dfb167706a9779ea9baf71a1b1cb5 23cead9d996977 1.2AuditOverview Auditworkduration:March15,2022–March24,2022 UpdateDetails:April1,2022.Codeupdate. Auditmethods:FormalVerification,StaticAnalysis,TypicalCaseTestingandManualReview. Auditteam:BeosinTechnologyCo.Ltd. FTMSecurityAudit 4 2Findings IndexRiskdescriptionSeveritylevelStatus FTM-1OperatorhasahighauthorityHighFixed FTM-2 swapFeeOperatorisnotinitializedandcannotbe modified LowFixed FTM-3IncorrectfunctioncallLowFixed FTM-4CentralizationriskLowAcknowledged FTM-5ThecorrespondingeventisnottriggeredInfoFixed FTM-6PublicfunctionscanbedeclaredexternalInfoPartiallyFixed FTM-7TokennameandsymbolcanbemodifiedarbitrarilyInfoFixed RiskDetailsDescription: 1.FTM-4isnotfixedandmaycauseapotentialcentralizationrisk. 2.FTM-6isnotfullyfixedbutdoesnotcausesecurityissues. FTMSecurityAudit 5 \[FTM-1\]Operatorhasahighauthority SeverityLevelHigh TypeBusinessSecurity LinesaFTMb\_R1.sol#L115-137,L147-150 DescriptionIntheaFTMb\_R1contract,theoperatorcancalltheburnBondsFromand burnSharesFromfunctionstoburnaFTMbtokensatanyaddress,andcallthe mintBondsToandmintSharesTofunctionstominttokenstoanyaddress.Thereisa problemofexcessivepermissions. Figure1Sourcecodeofrelatedfunctions Figure2SourcecodeofonlyPoolOrOperatormodifier RecommendationsItisrecommendedtomodifytheburnBondsFrom,burnSharesFrom,mintBondsTo andmintSharesTofunctionstobecalledonlybythepoolcontract. StatusFixed. FTMSecurityAudit 6 Figure3Sourcecodeofrelatedfunctions Figure4SourcecodeofonlyPoolmodifier FTMSecurityAudit 7 \[FTM-2\]swapFeeOperatorisnotinitializedandcannotbemodified SeverityLevelLow TypeBusinessSecurity LinesaFTMb\_R1.sol#L31 DescriptionIntheaFTMbtokencontract,theswapFeeOperatoraddressisnotinitializedand cannotbechanged. Figure5SourcecodeofvariableswapFeeOperator RecommendationsItisrecommendedtoaddafunctiontomodifythevariableswapFeeOperator. StatusFixed. Figure6SourcecodeofchangeSwapFeeOperatorfunction FTMSecurityAudit 8 \[FTM-3\]Incorrectfunctioncall SeverityLevelLow TypeBusinessSecurity LinesaFTMc\_R0.sol#L90 DescriptionThebalanceWithRewardsOffunctionintheaFTMc\_R0contractcallsthe balanceToSharesfunctionoftheaFTMbtokencontract,buttheinputisshares. Figure7SourcecodeofbalanceWithRewardsOffunction(Unfixed) RecommendationsItisrecommendedtomodifythecalledfunctiontosharesToBalance. StatusFixed. Figure8SourcecodeofbalanceWithRewardsOffunction(Fixed) FTMSecurityAudit 9 \[FTM-4\]Centralizationrisk SeverityLevelLow TypeBusinessSecurity LinesaFTMb\_R1.sol#L49-53 FantomPool\_R0.sol#L114-122,L162-168,L174-188 FantomStub\_R0.sol#L78-82 DescriptionTheoperatorintheaFTMb\_R1contractcancalltheupdateRatiofunctiontomodify theratioofbondsandshares,andthechangeOperatorandchangePoolContract functionstochangeoperatorandpooladdress.IntheFantomStub\_R0contract,the operatorandownercancallthesetWithdrawalBoundsfunctiontomodifythedata correspondingtovalidatorId.TheoperatorandownerintheFantomPool\_R0contract cancalltheupdateFeeParametersfunctiontomodifythefeeratiointhecontract. TheownercanalsocallfunctionssuchaschangeOperator,changeBondContract, setMinimumStake,allowDeploy,disallowDeploy,etc.Theremaybesome centralizationrisk. Figure9SourcecodeofupdateRatiofunction Figure10SourcecodeofchangeOperatorandchangeBondContractfunctions RecommendationsItisrecommendedtouseDAO,governancecontractsormulti-signaturewalletsas operatorandowner. StatusAcknowledged. FTMSecurityAudit 10 \[FTM-5\]Thecorrespondingeventisnottriggered SeverityLevelInfo TypeCodingConventions LinesFantomPool\_R0.sol#L162-168,L174-188 DescriptionThechangeOperator,changeBondContract,setMinimumStake,setSFC,allowDeploy anddisallowDeployfunctionsintheFantomPool\_R0contractdonottrigger correspondingevents. Figure11Sourcecodeofrelatedfunctions(Unfixed) Figure12Sourcecodeofrelatedfunctions(Unfixed) RecommendationsItisrecommendedtodeclareandtriggerthecorrespondingevent. StatusFixed. FTMSecurityAudit 11 Figure13Sourcecodeofrelatedfunctions(Fixed) Figure14Sourcecodeofrelatedfunctions(Fixed) FTMSecurityAudit 12 \[FTM-6\]Publicfunctionscanbedeclaredexternal SeverityLevelInfo TypeCodingConventions LinesFantomPool\_R0.sol#L162-168,L174-180 aFTMb\_R1.sol#L23-28,L53-57,L76-85,L91-141 FantomStub\_R0.sol#L29-36,L40-82 DescriptionFunctionssuchaschangeOperatorandchangeBondContractfunctionusethepublic modifier,whichmaycausemoregasconsumption. Figure15SourcecodeofchangeBondContractandchangeOperatorfunctions(Unfixed) RecommendationsItisrecommendedtomodifythevisibilityofonlyexternallycalledfunctionsto external. StatusPartiallyFixed.Thevisibilityofsomefunctionshasbeenchangedtoexternal. Figure16SourcecodeofchangeBondContractandchangeOperatorfunctions(Fixed) FTMSecurityAudit 13 \[FTM-7\]Tokennameandsymbolcanbemodifiedarbitrarily SeverityLevelInfo TypeBusinessSecurity LinesaFTMb\_R0.sol#L37-43 DescriptionThenameandsymboloftheaFTMb\_R1contractcanbemodifiedrepeatedly. Figure17SourcecodeofsetNameandsetSymbolfunctions RecommendationsItisrecommendedtoremovethesetNameandsetSymbolfunctions. StatusFixed.Therelatedfunctionhasbeenremoved. FTMSecurityAudit 14 3Appendix 3.1VulnerabilityAssessmentMetricsandStatusinSmartContracts 3.1.1Metrics Inordertoobjectivelyassesstheseveritylevelofvulnerabilitiesinblockchainsystems,thisreport providesdetailedassessmentmetricsforsecurityvulnerabilitiesinsmartcontractswithreferenceto CVSS3.1(CommonVulnerabilityScoringSystemVer3.1). Accordingtotheseveritylevelofvulnerability,thevulnerabilitiesareclassifiedintofourlevels: "critical","high","medium"and"low".Itmainlyreliesonthedegreeofimpactandlikelihoodof exploitationofthevulnerability,supplementedbyothercomprehensivefactorstodetermineofthe severitylevel. Impact Likelihood SevereHighMediumLow ProbableCriticalHighMediumLow PossibleHighHighMediumLow UnlikelyMediumMediumLowInfo RareLowLowInfoInfo 3.1.2Degreeofimpact Severe Severeimpactgenerallyreferstothevulnerabilitycanhaveaseriousimpactontheconfidentiality, integrity,availabilityofsmartcontractsortheireconomicmodel,whichcancausesubstantial economiclossestothecontractbusinesssystem,large-scaledatadisruption,lossofauthority management,failureofkeyfunctions,lossofcredibility,orindirectlyaffecttheoperationofother smartcontractsassociatedwithitandcausesubstantiallosses,aswellasothersevereandmostly irreversibleharm.  High Highimpactgenerallyreferstothevulnerabilitycanhavearelativelyseriousimpactonthe confidentiality,integrity,availabilityofthesmartcontractoritseconomicmodel,whichcancausea greatereconomicloss,localfunctionalunavailability,lossofcredibilityandotherimpacttothe contractbusinesssystem. FTMSecurityAudit 15 Medium Mediumimpactgenerallyreferstothevulnerabilitycanhavearelativelyminorimpactonthe confidentiality,integrity,availabilityofthesmartcontractoritseconomicmodel,whichcancausea smallamountofeconomiclosstothecontractbusinesssystem,individualbusinessunavailability andotherimpact. Low Lowimpactgenerallyreferstothevulnerabilitycanhaveaminorimpactonthesmartcontract, whichcanposecertainsecuritythreattothecontractbusinesssystemandneedstobeimproved. 3.1.4LikelihoodofExploitation Probable Probablelikelihoodgenerallymeansthatthecostrequiredtoexploitthevulnerabilityislow,withno specialexploitationthreshold,andthevulnerabilitycanbetriggeredconsistently. Possible Possiblelikelihoodgenerallymeansthatexploitingsuchvulnerabilityrequiresacertaincost,orthere arecertainconditionsforexploitation,andthevulnerabilityisnoteasilyandconsistentlytriggered.  Unlikely Unlikelylikelihoodgenerallymeansthatthevulnerabilityrequiresahighcost,ortheexploitation conditionsareverydemandingandthevulnerabilityishighlydifficulttotrigger. Rare Rarelikelihoodgenerallymeansthatthevulnerabilityrequiresanextremelyhighcostorthe conditionsforexploitationareextremelydifficulttoachieve. 3.1.5FixResultsStatus StatusDescription FixedTheprojectpartyfullyfixesavulnerability. PartiallyFixedTheprojectpartydidnotfullyfixtheissue,butonlymitigatedtheissue. AcknowledgedTheprojectpartyconfirmsandchoosestoignoretheissue. FTMSecurityAudit 16 3.2AuditCategories No.CategoriesSubitems 1CodingConventions CompilerVersionSecurity DeprecatedItems RedundantCode require/assertUsage GasConsumption 2GeneralVulnerability IntegerOverflow/Underflow Reentrancy Pseudo-randomNumberGenerator(PRNG) Transaction-OrderingDependence DoS(DenialofService) FunctionCallPermissions call/delegatecallSecurity ReturnedValueSecurity tx.originUsage ReplayAttack OverridingVariables Third-partyProtocolInterfaceConsistency 3BusinessSecurity BusinessLogics BusinessImplementations ManipulableTokenPrice CentralizedAssetControl AssetTradability ArbitrageAttack Beosinclassifiedthesecurityissuesofsmartcontractsintothreecategories:CodingConventions,General Vulnerability,BusinessSecurity.Theirspecificdefinitionsareasfollows: CodingConventions Auditwhethersmartcontractsfollowrecommendedlanguagesecuritycodingpractices.Forexample, smartcontractsdevelopedinSoliditylanguageshouldfixthecompilerversionanddonotuse deprecatedkeywords.  GeneralVulnerability FTMSecurityAudit 17 GeneralVulnerabilityincludesomecommonvulnerabilitiesthatmayappearinsmartcontract projects.Thesevulnerabilitiesaremainlyrelatedtothecharacteristicsofthesmartcontractitself, suchasintegeroverflow/underflowanddenialofserviceattacks. BusinessSecurity Businesssecurityismainlyrelatedtosomeissuesrelatedtothebusinessrealizedbyeachproject, andhasarelativelystrongpertinence.Forexample,whetherthelock-upplaninthecodematchthe whitepaper,ortheflashloanattackcausedbytheincorrectsettingofthepriceacquisitionoracle. \* Notethattheprojectmaysufferstakelossesduetotheintegratedthird-partyprotocol.ThisisnotsomethingBeosincancontrol. Businesssecurityrequirestheparticipationoftheprojectparty.Theprojectpartyandusersneedtostayvigilantatalltimes. FTMSecurityAudit 18 3.3Disclaimer TheAuditReportissuedbyBeosinisrelatedtotheservicesagreedintherelevantserviceagreement.The ProjectPartyortheServedParty(hereinafterreferredtoasthe"ServedParty")canonlybeusedwithinthe conditionsandscopeagreedintheserviceagreement.Otherthirdpartiesshallnottransmit,disclose,quote, relyonortamperwiththeAuditReportissuedforanypurpose. TheAuditReportissuedbyBeosinismadesolelyforthecode,andanydescription,expressionorwording containedthereinshallnotbeinterpretedasaffirmationorconfirmationoftheproject,norshallanywarranty orguaranteebegivenastotheabsoluteflawlessnessofthecodeanalyzed,thecodeteam,thebusinessmodel orlegalcompliance. TheAuditReportissuedbyBeosinisonlybasedonthecodeprovidedbytheServedPartyandthetechnology currentlyavailabletoBeosin.However,duetothetechnicallimitationsofanyorganization,andintheevent thatthecodeprovidedbytheServedPartyismissinginformation,tamperedwith,deleted,hiddenor subsequentlyaltered,theauditreportmaystillfailtofullyenumeratealltherisks. TheAuditReportissuedbyBeosininnowayprovidesinvestmentadviceonanyproject,norshoulditbe utilizedasinvestmentsuggestionsofanytype.Thisreportrepresentsanextensiveevaluationprocessdesigned tohelpourcustomersimprovecodequalitywhilemitigatingthehighrisksinBlockchain. FTMSecurityAudit 19 3.4AboutBEOSIN AffiliatedtoBEOSINTechnologyPte.Ltd.,BEOSINisthefirstinstitutionintheworldspecializinginthe constructionofblockchainsecurityecosystem.Thecoreteammembersareallprofessors,postdocs,PhDs,and Internetelitesfromworld-renownedacademicinstitutions.BEOSINhasmorethan20yearsofresearchin formalverificationtechnology,trustedcomputing,mobilesecurityandkernelsecurity,withoverseas experienceinstudyingandcollaboratinginprojectresearchatwell-knownuniversities.Throughthesecurity auditanddefensedeploymentofmorethan2,000smartcontracts,over50publicblockchainsandwallets,and nearly100exchangesworldwide,BEOSINhasaccumulatedrichexperienceinsecurityattackanddefenseof theblockchainfield,andhasdevelopedseveralsecurityproductsspecificallyforblockchain. OfficialWebsite https://www.beosin.com Telegram https://t.me/+dD8Bnqd133RmNWNl Twitter https://twitter.com/Beosin\_com Email Contact@beosin.com --- # Unknown Auditing Report Hardening Blockchain Security with Formal Methods FOR Ankr Token Staking Veridise Inc. February 21, 2023 ▶Prepared For: ANKR https://www.ankr.com/ ▶Prepared By: Jon Stephens Xiangan He ▶Contact Us:contact@veridise.com ▶Version History: Feb 21, 2023V1 ©2023 Veridise Inc. All Rights Reserved. Contents Contentsiii 1 Executive Summary1 2 Project Dashboard3 3 Audit Goals and Scope5 3.1 Audit Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Audit Methodology & Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Classification of Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 Vulnerability Report7 4.1 Detailed Description of Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1 V-ATS-VUL-001: Incorrect Credit on Migrate . . . . . . . . . . . . . . . . 8 4.1.2 V-ATS-VUL-002: Rewards can be claimed multiple times . . . . . . . . . 10 4.1.3 V-ATS-VUL-003: Potential Overflow on Downcast . . . . . . . . . . . . . 12 4.1.4 V-ATS-VUL-004: No Validator Punishment Mechanisms . . . . . . . . . 13 4.1.5 V-ATS-VUL-005: Potential gas DoS . . . . . . . . . . . . . . . . . . . . . 14 4.1.6 V-ATS-VUL-006: No Validation for Setters in StakingConfig . . . . . . . 15 4.1.7 V-ATS-VUL-007: Potentially Stuck Validator due to Unset Status . . . . . 16 4.1.8 V-ATS-VUL-008: DelegateCall Dangerous in Upgradable Contracts . . . 17 4.1.9 V-ATS-VUL-009: No status check in Migrate . . . . . . . . . . . . . . . . 18 4.1.10 V-ATS-VUL-010: Potential Validator State Inconsistencies . . . . . . . . . 19 4.1.11 V-ATS-VUL-011: TokenStaking does not override \_safeTransferTo . . . . 21 4.1.12 V-ATS-VUL-012: Locked Native Tokens . . . . . . . . . . . . . . . . . . . 22 4.1.13 V-ATS-VUL-013: Possible Reentrancy . . . . . . . . . . . . . . . . . . . . 23 Veridise Audit Report: ANKR©2023 Veridise Inc. Executive Summary1 From Feb. 13 to Feb. 20, ANKR engaged Veridise to review the security of their Ankr Token Staking protocol. The review covered the on-chain contracts that implement the protocol logic. Veridise conducted the assessment over 2 person-weeks, with 2 engineers reviewing code over 1 weeks on commit57a718c. The auditing strategy involved a tool-assisted analysis of the source code performed by Veridise engineers as well as extensive manual auditing. Code assessment.The Ankr Token Staking protocol is an upgradable contract that is already deployed on mainnet. The new version of the protocol, which is the focus of this audit, streamlines the previous version of the contract. To do so, it removes validator punishment mechanisms and places the validator maintenance in the hands of governance so that they are the only ones that may add or remove validators. Similar to the previous version, delegators can then stake their funds with validators to receive a share of the rewards given to validators. Those funds are locked by the contract for a certain staking period of time, after which a user can undelegate to receive their funds back along with any unclaimed rewards. Since the contract will be upgraded to this new version, the developers also include migration code to migrate state from the old contract to the new one. ANKR provided the source code for the Ankr Token Staking protocol for review. In addition, they provided a set of tests based on the Truffle testing framework. Summary of issues detected.The audit uncovered 13 issues, 2 of which are assessed to be of high or critical severity by the Veridise auditors. Specifically, V-ATS-VUL-001 identifies a logic error in the migration logic that could prevent users from withdrawing funds and V-ATS-VUL-002 identifies a logic error that could allow users to claim rewards multiple times. In addition, the auditors identified a moderate-severity issue where user funds could be improperly tracked due to an overflow while downcasting (V-ATS-VUL-003). Finally, the auditors identified several other security concerns, including some potentially unsafe functions (V-ATS-VUL-008, V-ATS-VUL-010, V-ATS-VUL-011) and missing validation (V-ATS-VUL-006, V-ATS-VUL-007, V-ATS-VUL-009). Disclaimer.We hope that this report is informative but provide no warranty of any kind, explicit or implied. The contents of this report should not be construed as a complete guarantee that the system is secure in all dimensions. In no event shall Veridise or any of its employees be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the results reported here. Veridise Audit Report: ANKR©2023 Veridise Inc. Project Dashboard2 Table 2.1:Application Summary. NameVersionTypePlatform Ankr Token Staking57a718cSolidityEthereum Table 2.2:Engagement Summary. DatesMethodConsultants EngagedLevel of Effort Feb. 13 - Feb. 20, 2023Manual & Tools22 person-weeks Table 2.3:Vulnerability Summary. NameNumberResolved Critical-Severity Issues00 High-Severity Issues22 Medium-Severity Issues10 Low-Severity Issues33 Warning-Severity Issues75 Informational-Severity Issues00 TOTAL1310 Table 2.4:Category Breakdown. NameNumber Maintainability4 Data Validation2 Logic Error2 Overflow1 Validator Punishment1 Denial of Service1 Locked Funds1 Reentrancy1 Veridise Audit Report: ANKR©2023 Veridise Inc. Audit Goals and Scope3 3.1 Audit Goals The engagement was scoped to provide a security assessment of the on-chain portion of the Ankr Token Staking protocol defined in the following scope. In our audit, we sought to answer the following questions: ▶Can users steal funds from the pool? ▶Will users be paid upon unstaking? ▶Can rewards be claimed multiple times? ▶Is there a method to punish malicious validators? ▶Can a delegator unstake before the lock period has elapsed? ▶Can funds be locked within the contract? 3.2 Audit Methodology & Scope Audit Methodology.To address the questions above, our audit involved a combination of human experts and automated program analysis & testing tools. In particular, we conducted our audit with the aid of the following techniques: ▶Static analysis.To identify potential common vulnerabilities, we leveraged our custom smart contract analysis tool Vanguard, as well as the open-source tool Slither. These tools are designed to find instances of common smart contract vulnerabilities, such as reentrancy and uninitialized variables. ▶ Fuzzing/Property-based Testing.We also leverage fuzz testing to determine if the protocol may deviate from the expected behavior. To do this, we formalize the desired behavior of the protocol as \[V\] specifications and then use our fuzzing framework OrCa to determine if a violation of the specification can be found. Scope. The audit reviewed the on-chain behaviors of the Ankr Token Staking protocol, including delegator and validator migration, validator management and delegator staking. The Veridise engineers first inspected the provided documentation to understand the high-level design of the protocol. They then inspected the provided test-cases to better understand the specific contract behavior. Finally, the auditors performed a week long audit of the code assisted both by static analyzers and automated testing. In terms of the audit, the following files were in-scope: ▶contracts/protocol/AnkrTokenStaking.sol ▶contracts/staking/BaseStaking.sol ▶contracts/staking/Staking.sol ▶contracts/staking/StakingConfig.sol ▶contracts/staking/ValidatorRegistry.sol ▶contracts/staking/ValidatorStorage.sol ▶contracts/staking/extension/TokenStaking.sol Veridise Audit Report: ANKR©2023 Veridise Inc. 63 Audit Goals and Scope ▶contracts/libs/SnapshotUtil.sol ▶contracts/libs/ValidatorUtil.sol ▶contracts/libs/DelegationUtil.sol ▶contracts/libs/Multicall.sol 3.3 Classification of Vulnerabilities When Veridise auditors discover a possible security vulnerability, they must estimate its severity by weighing its potential impact against the likelihood that a problem will arise. Table 3.1 shows how our auditors weigh this information to estimate the severity of a given issue. Table 3.1:Severity Breakdown. Somewhat BadBadVery BadProtocol Breaking Not LikelyInfoWarningLowMedium LikelyWarningLowMediumHigh Very LikelyLowMediumHighCritical In this case, we judge the likelihood of a vulnerability as follows: Not LikelyA small set of users must make a specific mistake Requires a complex series of steps by almost any user(s) Likely - OR - Requires a small set of users to perform an action Very LikelyCan be easily performed by almost anyone In addition, we judge the impact of a vulnerability as follows: Somewhat BadInconveniences a small number of users and can be fixed by the user Affects a large number of people and can be fixed by the user Bad- OR - Affects a very small number of people and requires aid to fix Affects a large number of people and requires aid to fix Very Bad - OR - Disrupts the intended behavior of the protocol for a small group of users through no fault of their own Protocol BreakingDisrupts the intended behavior of the protocol for a large group of users through no fault of their own ©2023 Veridise Inc.Veridise Audit Report: ANKR Vulnerability Report4 In this section, we describe the vulnerabilities found during our audit. For each issue found, we log the type of the issue, its severity, location in the code base, and its current status (i.e., acknowleged, fixed, etc.). Table 4.1 summarizes the issues discovered: Table 4.1:Summary of Discovered Vulnerabilities. IDDescriptionSeverityStatus V-ATS-VUL-001Incorrect Credit on MigrateHighFixed V-ATS-VUL-002Rewards can be claimed multiple timesHighFixed V-ATS-VUL-003Potential Overflow on DowncastMediumOpen V-ATS-VUL-004No Validator Punishment MechanismsLowIntended Behavior V-ATS-VUL-005Potential gas DoSLowAcknowledged V-ATS-VUL-006No Validation for Setters in StakingConfigLowFixed V-ATS-VUL-007Potentially Stuck Validator due to Unset StatusWarningFixed V-ATS-VUL-008DelegateCall Dangerous in Upgradable ContractsWarningOpen V-ATS-VUL-009No status check in MigrateWarningFixed V-ATS-VUL-010Potential Validator State InconsistenciesWarningOpen V-ATS-VUL-011TokenStaking does not override \_safeTransferToWarningFixed V-ATS-VUL-012Locked Native TokensWarningFixed V-ATS-VUL-013Possible ReentrancyWarningFixed Veridise Audit Report: ANKR©2023 Veridise Inc. 84 Vulnerability Report 4.1 Detailed Description of Bugs 4.1.1 V-ATS-VUL-001: Incorrect Credit on Migrate SeverityHighCommit57a718c TypeLogic ErrorStatusFixed FilesStaking.sol FunctionsmigrateDelegator The following code is used to migrate delegators from the old version of the staking contract to the new version. To do so, it must update added storage state such as \_ stakerAmountsand \_ stakerShares. During the course of this calculation, thedelegatedvalue is will either be delegations.delegateQueue\[j\].amountor2 \* delegations.delegateQueue\[j\].amountdepend- ing on the path taken (wherej = delegations.delegateQueue.length - 1). We believe this value is not computed correctly as it appears that the \_ stakerAmounts is intended to track the sum of the active delegated funds. 1functionmigrateDelegator(addressdelegator)public{ 2... 3 4uint112delegated; 5for(uint256j = delegations.delegateGap; j < delegations.delegateQueue.length; j++) { 6if(delegations.delegateQueue\[j\].amount < delegated) { 7delegated -= delegated - delegations.delegateQueue\[j\].amount; 8continue; 9}else if(delegations.delegateQueue\[j\].amount == delegated) { 10continue; 11} 12uint112realAmount = delegations.delegateQueue\[j\].amount - delegated; 13delegated += realAmount; 14newDelegations.push(Delegation(delegations.delegateQueue\[j\].epoch, realAmount,uint256(realAmount) \* BALANCE \_ COMPACT \_ PRECISION, 0)); 15delegated += delegations.delegateQueue\[j\].amount; 16} 17 \_ stakerAmounts\[validatorAddress\]\[delegator\] += delegated; 18 \_ stakerShares\[validatorAddress\]\[delegator\] +=uint256(delegated) \* BALANCE \_ COMPACT \_ PRECISION; 19 20... 21} Snippet 4.1:The migration function that over-credits the \_ stakerAmountsand \_ stakerShares ImpactSince the \_ stakerAmountsis intended to track the sum of active delegated funds across the user’s history, the value stored in \_ stakerAmountsis likely to be inconsistent with the true value that should be stored. From what we can tell if \_ stakerAmountsis too high, users may be able to withdraw too many funds from the pool if the delegation computation is also incorrect. Alternatively, if \_ stakerAmountsis too small this could prevent users from undelegating all of ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs9 their funds. Asdelegatedis likely to be too large, we believe that this code will likely cause user funds to become locked. RecommendationUpdate the logic so that user funds will not be locked. Veridise Audit Report: ANKR©2023 Veridise Inc. 104 Vulnerability Report 4.1.2 V-ATS-VUL-002: Rewards can be claimed multiple times SeverityHighCommit57a718c TypeLogic ErrorStatusFixed FilesStaking.sol Functions\_stashUnlocked When a user undelegates, the protocol must determine if sufficient funds have passed their lock period and what rewards have been claimed so far. This information is then used to credit the user with funds that they can withdraw and send the user any pending rewards. However, some paths through the function do not report any rewards have been claimed as shown below. 1function \_ stashUnlocked( 2ValidatorPoolmemoryvalidatorPool, 3addressdelegator, 4uint112expectedAmount, 5uint64beforeEpoch 6)internal returns(uint96claimed,uint256spentShares) { 7... 8 9while(history.delegationGap < delegations.length&& delegations\[history. delegationGap\].epoch + lockPeriod < beforeEpoch && expectedAmount > 0) { 10if(delegations\[history.delegationGap\].amount > expectedAmount) { 11// deduct undelegated amount 12uint256shares = \_ toShares(validatorPool,uint256(expectedAmount) \* BALANCE \_ COMPACT \_ PRECISION); 13delegations\[history.delegationGap\].amount -= expectedAmount; 14require(delegations\[history.delegationGap\].shares >= shares, " overflow"); 15delegations\[history.delegationGap\].shares -= shares; 16spentShares += shares; 17// expected amount is filled 18expectedAmount = 0; 19// save changes to storage 20storageDelegations\[history.delegationGap\] = delegations\[history. delegationGap\]; 21break; 22} 23expectedAmount -= delegations\[history.delegationGap\].amount; 24claimed += delegations\[history.delegationGap\].claimed; 25... 26} 27 28... 29} Snippet 4.2:Location where claimed rewards are not being calculated ImpactSince the return value of this function is used to determine how many rewards have yet to be paid to the user, an individual can make repeated requests toundelegateto receive ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs11 rewards multiple times. RecommendationIf a single delegation can cover the remaining funds, calculate the amount of claimed funds and reduce the claimed funds appropriately (as otherwise some rewards may be unclaimable) Veridise Audit Report: ANKR©2023 Veridise Inc. 124 Vulnerability Report 4.1.3 V-ATS-VUL-003: Potential Overflow on Downcast SeverityMediumCommit57a718c TypeOverflowStatusOpen FilesStaking.sol, ValidatorRegistry.sol FunctionsMultiple To reduce the storage cost, the developers store delegated amounts as multiples ofBALANCE \_ COMPACT \_ PRECISION so that values can fit into auint112. Doing so requires frequent downcasting as values are typically passed in as auint256. Since downcasting can overflow without causing a revert to occur and there may be some left over dust that isn’t accounted for, we recommend that the developers validate the given compact version is equivalent to what the user passes in. 1function \_ delegateUnsafe(addressvalidator,addressdelegator,uint256amount, uint64sinceEpoch)internaloverride { 2uint112compactAmount =uint112(amount / BALANCE \_ COMPACT \_ PRECISION); 3// add delegated amount to validator snapshot, revert if validator not exist 4 5... 6} Snippet 4.3:Snippet in \_ delegateUnsafethat converts an amount to its compact form ImpactIf a user passes in a large value, for amount it is possible that this could cause an overflow, resulting in inaccurate accounting. RecommendationAdd a requirement that the compact representation is equivalent to the original value. ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs13 4.1.4 V-ATS-VUL-004: No Validator Punishment Mechanisms SeverityLowCommit57a718c TypeValidator PunishmentStatusIntended Behavior FilesValidatorRegistry.sol FunctionsN/A Currently, the ValidatorRegistry contract allows the governance to add and activate validators. To enforce the good behavior of Validators, typically there is a mechanism to punish misbehaving or malicious validators by slashing or jailing them. In this contract, all of the slashing and jailing behaviors have been removed. ImpactWith no punishment mechanism, validators may misbehave for financial gain. RecommendationAdd a punishment mechanism to the ValidatorRegistry contract. Developer ResponseWe plan to start with a single trusted validator so we do not need the slashing logic. If we allow other validators to be added in the future we will add this functionality back in. Veridise Audit Report: ANKR©2023 Veridise Inc. 144 Vulnerability Report 4.1.5 V-ATS-VUL-005: Potential gas DoS SeverityLowCommit57a718c TypeDenial of ServiceStatusAcknowledged FilesStaking.sol FunctionsmigrateDelegator The protocol makes frequent use offorloops (and in some cases nested loops) over arrays and integer ranges which can lead to expensive gas costs. 1functionmigrateDelegator(addressdelegator)public{ 2... 3 4for(uint256i; i < validators.length; i++) { 5... 6for(uint256j = delegations.delegateGap; j < delegations.delegateQueue. length; j++) { 7... 8} 9 10... 11 12for(uint256j = delegations.undelegateGap; j < delegations. undelegateQueue.length; j++) { 13... 14} 15... 16} 17 18... 19} Snippet 4.4:Function with nested loops ImpactSuch loops can result in prohibitive gas costs rendering certain functions as in- executable by users. RecommendationIf possible, bound the execution of loops. ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs15 4.1.6 V-ATS-VUL-006: No Validation for Setters in StakingConfig SeverityLowCommit57a718c TypeData ValidationStatusFixed FilesStakingConfig.sol FunctionsN/A The StakingConfig contract stores important configuration information about the system and allows the governance to change these values via setters. However, many of these functions lack validation on the input values. 1functionsetGovernanceAddress(addressnewValue)externaloverride onlyFromGovernance { 2addressprevValue = \_ slot0.governanceAddress; 3 \_ slot0.governanceAddress = newValue; 4emitGovernanceAddressChanged(prevValue, newValue); 5} Snippet 4.5:A setter in the StakingConfig contract that doesn’t validatenewValue ImpactWithout input validation, an admin could make a mistake such as setting the gover- nance address toaddress(0). RecommendationPerform appropriate validation of input values in the setters. In addition, to prevent the governance address from being transferred to a malicious user or a location that is inaccessible, the developers should consider a propose/accept mechanism. In this case the governance address would propose a new governance address and after an appropriate delay (24 hours for example) the new governance address can accept the appointment. Within the waiting period, the governance address transfer may be canceled. Veridise Audit Report: ANKR©2023 Veridise Inc. 164 Vulnerability Report 4.1.7 V-ATS-VUL-007: Potentially Stuck Validator due to Unset Status SeverityWarningCommit57a718c TypeMaintainabilityStatusFixed FilesValidatorStorage.sol Functionscreate create allows the pool to create validators. There is, however, no enforcement that the Validator’s new created status is notNotFound. If the Validator’s new status is set toNotFound(either by missing param input to status, or by mistake). 1functioncreate( 2addressvalidatorAddress, 3addressvalidatorOwner, 4ValidatorStatus status, 5uint64epoch 6)externaloverride onlyFromPool { 7Validatorstorageself = \_ validatorsMap\[validatorAddress\]; 8require(self.status == ValidatorStatus.NotFound, "Validator: already exist"); 9self.validatorAddress = validatorAddress; 10self.ownerAddress = validatorOwner; 11self.status = status; 12self.changedAt = epoch; 13 14// save validator owner 15require(validatorOwners\[validatorOwner\] ==address(0x00), "owner in use"); 16validatorOwners\[validatorOwner\] = validatorAddress; 17 18// add new validator to array 19if(status == ValidatorStatus.Active) { 20activeValidatorsList.push(validatorAddress); 21} 22} Snippet 4.6:The function with no input validation on the status ImpactIfcreatewas called with the statusNotFound, then the pool to callcreate, which will create a validator with bad status. SincevalidatorOwners\[validatorOwner\] = validatorAddress, any subsequent attempts to callcreateagain on the validator address with the same owner will fail. In addition,activaterequiresself.status == ValidatorStatus.Pendingso the validator will never be activated RecommendationCheck that the user passes in a valid status. ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs17 4.1.8 V-ATS-VUL-008: DelegateCall Dangerous in Upgradable Contracts SeverityWarningCommit57a718c TypeData ValidationStatusOpen FilesMulticall.sol Functions\_fastDelegateCall The staking contract is both upgradable and it extends the MultiCall contract. The MultiCall contract allows a user to batch calls to the contract by repeatedly delegated calls to itself with calldata provided by the user. However, OpenZeppelin advises that users avoid the use of delegate call in their documentation on Upgradable contracts as they could potentially be used to destroy the implementation contract. ImpactIf a self-destruct could be invoked using the delegate call on the implementation contract, it could prevent users from interacting with the staking contract. RecommendationTo avoid the case were a user could interact with the implementation contract, OpenZeppelin suggests “breaking” the implementation contract in the constructor so that it cannot be used. Their recommendation on how to do so is provided here. Veridise Audit Report: ANKR©2023 Veridise Inc. 184 Vulnerability Report 4.1.9 V-ATS-VUL-009: No status check in Migrate SeverityWarningCommit57a718c TypeMaintainabilityStatusFixed FilesValidatorStorage.sol Functionsmigrate Themigratefunction is used to migrate validators from the old contract version to the new contract version. When doing so the function automatically pushes the validator onto the active validators list but does not check the validator’s status to ensure it is active. 1functionmigrate(Validator calldata validator)externaloverride onlyFromPool { 2 \_ validatorsMap\[validator.validatorAddress\] = validator; 3validatorOwners\[validator.ownerAddress\] = validator.validatorAddress; 4activeValidatorsList.push(validator.validatorAddress); 5} Snippet 4.7:Function to migrate validators to new contract version ImpactThis could allow a validator with a non-active status to be added to the active validator list, potentially allowing a validator to accidentally be marked as active. RecommendationCheck the validator’s status to make sure it is active. ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs19 4.1.10 V-ATS-VUL-010: Potential Validator State Inconsistencies SeverityWarningCommit57a718c TypeMaintainabilityStatusOpen FilesValidatorRegistry Functions\_touchValidatorSnapshot The protocol stores snapshots of the validator state over epochs of time. It will then read and update information in these epochs as the validator state changes. Certain values, however, are intended to be maintained across epochs such as thetotalDelegatedandcommissionRate. The API below, however, allows developers to request and modify in previous epochs without changing the ones that come after. 1function \_ touchValidatorSnapshot(Validator memory validator, uint64 epoch) internal returns (ValidatorSnapshot storage) { 2ValidatorSnapshot storage snapshot = \_ validatorSnapshots\[validator. validatorAddress\]\[epoch\]; 3// if snapshot is already initialized then just return it 4if (snapshot.totalDelegated > 0) { 5return snapshot; 6} 7// find previous snapshot to copy parameters from it 8ValidatorSnapshot memory lastModifiedSnapshot = \_ validatorSnapshots\[validator .validatorAddress\]\[validator.changedAt\]; 9// last modified snapshot might store zero value, for first delegation it might happen and its not critical 10snapshot.totalDelegated = lastModifiedSnapshot.totalDelegated; 11snapshot.commissionRate = lastModifiedSnapshot.commissionRate; 12// we must save last affected epoch for this validator to be able to restore total delegated 13// amount in the future (check condition upper) 14if (epoch > validator.changedAt) { 15 \_ validatorStorage.change(validator.validatorAddress, epoch); 16} 17return snapshot; 18} Snippet 4.8:The function used to find validator state at a given epoch for modification. ImpactIf a user changes values in an epoch beforevalidator.changedAtthose values will not be reflected in the most recent epoch. Since it appears that certain values, such astotalDelegated, are intended to be consistent across epochs such modifications could result in inconsistent states and locked funds (i.e.totalDelegatedin some epoch X should be the same in X+1 unless a user undelegated those funds). Note that this could also be used to copy recent changes into a previous epoch but this only appears to impact the frontend. RecommendationIt appears that this API is currently used almost exclusively to get the next epoch. In the one case where this does not occur, the modified value does not appear to be Veridise Audit Report: ANKR©2023 Veridise Inc. 204 Vulnerability Report tracked across epochs (totalRewards). To prevent future errors, we would recommend checking that only states at or more recent thanchangedAtare modified. ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs21 4.1.11 V-ATS-VUL-011: TokenStaking does not override \_safeTransferTo SeverityWarningCommit57a718c TypeMaintainabilityStatusFixed FilesTokenStaking.sol Functions\_safeTransferTo TheTokenStakingcontract overrides the behavior ofStakingso that ERC20 tokens can be staked instead of native tokens. To do so, it overrides the payment methods used byStakingso that ERC20 payments are performed instead. TheTokenStakingcontract, however, only overrides two of the 3 native payment methods as the \_ safeTransferTo function still performs native payments. ImpactSince \_ safeTransferTo is never used, this doesn’t impact the current version of the protocol. If future changes to the contract do call this function, however, users may be paid using the wrong currency. RecommendationOverride \_ safeTransferTo inTokenStakingso that it also pays users ERC20 tokens. Veridise Audit Report: ANKR©2023 Veridise Inc. 224 Vulnerability Report 4.1.12 V-ATS-VUL-012: Locked Native Tokens SeverityWarningCommit57a718c TypeLocked FundsStatusFixed FilesTokenStaking.sol Functionsreceive TheTokenStakingcontract overrides the behavior ofStakingso that ERC20 tokens can be staked instead of native tokens. This contract still accepts native tokens though due to the definition of receiveshown below in the Staking contract. 1receive() external payable { 2} Snippet 4.9:Thereceivefunction defined byStakingand not overriden byTokenStaking ImpactSinceTokenStakingdoes not provide support for native tokens, any tokens sent to this contract will be locked in the contract. RecommendationOverridereceivein TokenStaking so that funds are rejected or add in functionality to rescue such tokens. ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs23 4.1.13 V-ATS-VUL-013: Possible Reentrancy SeverityWarningCommit57a718c TypeReentrancyStatusFixed FilesStaking.sol FunctionsmigrateDelegator The Staking contract migrates users from the old version of the contract to their new version with the functionmigrateDelegator. This function processes the old state of the contract and updates delegations in the new contract state. While doing so, the migration process will transfer any unclaimed rewards to the user with the function shown below. While it is likely that the native version of the \_ safeTransferWithGasLimitwould not succeed since it strictly limits gas and themigradeDelegatorfunction is gas-intensive, it is possible that the ERC20 version of the API could reenter. This is because some ERC20 tokens, such as those that adhere to the ERC777 specification (which extends ERC20) introduce an unsafe callback intransferand transferFrom. 1function \_ transferDelegatorRewards(address validator, address delegator) internal { 2// next epoch to claim all rewards including pending 3uint64 beforeEpochExclude = \_ MIGRATION \_ EPOCH; 4// claim rewards and undelegates 5uint256 availableFunds = \_ processDelegateQueue(validator, delegator, beforeEpochExclude); 6// for transfer claim mode just all rewards to the user 7 \_ safeTransferWithGasLimit(payable(delegator), availableFunds); 8// emit event 9emit Claimed(validator, delegator, availableFunds, beforeEpochExclude); 10} Snippet 4.10:Function used to send unclaimed rewards to users during the migration process ImpactIf a reentrancy were to occur here, someone could receive rewards multiple times. RecommendationSincemigrateDelegatormust either execute fully or revert, move the state- mentisMigratedDelegator\[delegator\] = true;to right after theisMigratedDelegatorcheck. Veridise Audit Report: ANKR©2023 Veridise Inc. --- # Unknown Auditing Report Hardening Blockchain Security with Formal Methods FOR Native BNB Token Staking Veridise Inc. February 17, 2023 ▶Prepared For: ANKR https://www.ankr.com/ ▶Prepared By: Jon Stephens Jacob Van Geffen Yanju Chen ▶Contact Us:contact@veridise.com ▶Version History: Feb 17, 2023V1 ©2023 Veridise Inc. All Rights Reserved. Contents Contentsiii 1 Executive Summary1 2 Project Dashboard3 3 Audit Goals and Scope5 3.1 Audit Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Audit Methodology & Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Classification of Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 Vulnerability Report7 4.1 Detailed Description of Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1 V-ANS-VUL-001: Users Charged Twice by ERC20 Staking Pool . . . . . . 8 4.1.2 V-ANS-VUL-002: Locked Funds in Staking Pool . . . . . . . . . . . . . . 10 4.1.3 V-ANS-VUL-003: Potential Reentrancy . . . . . . . . . . . . . . . . . . . 12 4.1.4 V-ANS-VUL-004: Missing Requirements on Unstaking Amount . . . . . 13 4.1.5 V-ANS-VUL-005: Unguarded External Function . . . . . . . . . . . . . . 14 4.1.6 V-ANS-VUL-006: Incorrect Gap Tracking . . . . . . . . . . . . . . . . . . 15 4.1.7 V-ANS-VUL-007: Min Delegation Requirement Bypassed . . . . . . . . . 17 4.1.8 V-ANS-VUL-008: Inconsistent Values Passed to Token Transfer Utility Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.9 V-ANS-VUL-009: Potential Unlock DoS . . . . . . . . . . . . . . . . . . . 20 4.1.10 V-ANS-VUL-010: Potential Theft from Queue . . . . . . . . . . . . . . . 21 4.1.11 V-ANS-VUL-011: Potential Underpay for Shares . . . . . . . . . . . . . . 22 4.1.12 V-ANS-VUL-012: Wasting Gas via External Call . . . . . . . . . . . . . . 23 4.1.13 V-ANS-VUL-013: Double Converting between Shares and Bonds . . . . 24 4.1.14 V-ANS-VUL-014: Unused State . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1.15 V-ANS-VUL-015: Duplicated Code . . . . . . . . . . . . . . . . . . . . . 26 4.1.16 V-ANS-VUL-016: Potential Overflow on Downcast . . . . . . . . . . . . . 27 4.1.17 V-ANS-VUL-017: Potentially Unsafe Conditional . . . . . . . . . . . . . . 28 Veridise Audit Report: ANKR©2023 Veridise Inc. Executive Summary1 From Jan. 19 to Feb. 3, ANKR engaged Veridise to review the security of their Native BNB Token Staking protocol. The review covered the on-chain contracts that implement the protocol logic. Veridise conducted the assessment over 6 person-weeks, with 3 engineers reviewing code over 2 weeks on commit41c5531for thestakefi-smart-contractrepository andc004d02for the ankr-contractsrepository. The auditing strategy involved a tool-assisted analysis of the source code performed by Veridise engineers as well as extensive manual auditing. Code assessment.The ANKR Native BNB Token Staking protocol allows users to stake funds in return ANKR’s liquid staking tokensaBNBbandaBNBc. These tokens earn yields for users over time as the token’s ratio decreases. The staking pool allows validators to stake the pool funds in Binance’s native staking pool to earn rewards on the staked funds. Since user funds may be staked at the time of withdraw, the staking pool also provides a waiting queue so that users can be paid in the order that withdraws were requested. ANKR provided the source code for the Native BNB Token Staking protocol for review. In addition, they provided some documentation about the intended behavior of the protocol. Finally, they provided a set of tests based on the Truffle testing framework. Summary of issues detected.The audit uncovered 17 issues, 2 of which are assessed to be of high or critical severity by the Veridise auditors. Specifically, V-ANS-VUL-001 charges users twice for staking their funds and V-ANS-VUL-002 would cause funds to be locked in a waiting queue. In addition, the auditors identified two moderate-severity issues, including the potential to underpay users when unstaking their funds (V-ANS-VUL-004). Finally, the auditors identified several other security concerns, including logic errors (V-ANS-VUL-006), a possible theft from the waiting queue (V-ANS-VUL-010) and a potential overflow on downcast (V-ANS-VUL-016). Disclaimer.We hope that this report is informative but provide no warranty of any kind, explicit or implied. The contents of this report should not be construed as a complete guarantee that the system is secure in all dimensions. In no event shall Veridise or any of its employees be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the results reported here. Veridise Audit Report: ANKR©2023 Veridise Inc. Project Dashboard2 Table 2.1:Application Summary. NameVersionTypePlatform Native BNB Token Staking41c5531, c004d02SolidityBNB Smart Chain Table 2.2:Engagement Summary. DatesMethodConsultants EngagedLevel of Effort Jan. 19 - Feb. 3, 2023Manual & Tools36 person-weeks Table 2.3:Vulnerability Summary. NameNumberResolved Critical-Severity Issues11 High-Severity Issues11 Medium-Severity Issues22 Low-Severity Issues76 Warning-Severity Issues65 Informational-Severity Issues00 TOTAL1715 Table 2.4:Category Breakdown. NameNumber Logic Error4 Locked Funds3 Reentrancy2 Theft2 Dead Code2 Denial of Service1 Overflow1 Data Validation1 Gas Optimization1 Veridise Audit Report: ANKR©2023 Veridise Inc. Audit Goals and Scope3 3.1 Audit Goals The engagement was scoped to provide a security assessment of the on-chain portion of the Native BNB Token Staking protocol defined in the following scope. In our audit, we sought to answer the following questions: ▶Can users steal funds from the pool? ▶Are users fairly rewarded with ANKR’s liquid staking tokens upon staking? ▶Will users be paid upon unstaking? ▶If users are placed in the waiting queue, will they eventually be paid? ▶Can one user deny payment to others in the waiting queue? ▶Can users steal funds from the waiting queue? ▶Will users be processed by the waiting queue only once? ▶Are all external functions guarded by a reentrancy guard? ▶Are all bearing tokens backed by certificate tokens? 3.2 Audit Methodology & Scope Audit Methodology.To address the questions above, our audit involved a combination of human experts and automated program analysis & testing tools. In particular, we conducted our audit with the aid of the following techniques: ▶Static analysis.To identify potential common vulnerabilities, we leveraged our custom smart contract analysis tool Vanguard, as well as the open-source tool Slither. These tools are designed to find instances of common smart contract vulnerabilities, such as reentrancy and uninitialized variables. ▶Fuzzing/Property-based Testing.We also leverage fuzz testing to determine if the protocol may deviate from the expected behavior. To do this, we formalize the desired behavior of the protocol as \[V\] specifications and then use our fuzzing framework OrCa to determine if a violation of the specification can be found. Scope. The audit reviewed the on-chain behaviors of the Native BNB Token Staking protocol, including user staking, pool funds staking, user withdrawals and liquid staking tokens. The Veridise engineers first inspected the provided documentation to understand the high-level design of the protocol. They then inspected the provided test-cases to better understand the specific contract behavior. Finally, the auditors performed a multi-week audit of the code assisted both by static analyzers and automated testing. In terms of the audit, the following files were in-scope: Repository: ankr-contracts ▶contracts/earn/BearingToken.sol Veridise Audit Report: ANKR©2023 Veridise Inc. 63 Audit Goals and Scope ▶contracts/earn/CertificateToken.sol ▶contracts/earn/EarnConfig.sol ▶contracts/earn/LiquidTokenStakingPool.sol ▶contracts/earn/extension/ERC20LiquidTokenStakingPool.sol ▶contracts/earn/extension/ImmediateLiquidTokenStakingPool.sol ▶contracts/earn/extension/ManualClaimLiquidTokenStakingPool.sol ▶contracts/earn/extension/MixedLiquidTokenStakingPool.sol ▶contracts/earn/extension/QueueLiquidTokenStakingPool.sol ▶contracts/earn/extension/ReferralLiquidTokenStakingPool.sol Repository: stakefi-smart-contract ▶bnb-v2/contracts/native-staking/BNBStakingPool.sol ▶bnb-v2/contracts/tokens/aBNBb.sol ▶bnb-v2/contracts/tokens/aBNBc.sol ▶bnb-v2/contracts/tokens/upgrades/aBNBb\_R1.sol ▶bnb-v2/contracts/tokens/upgrades/aBNBc\_R1.sol 3.3 Classification of Vulnerabilities When Veridise auditors discover a possible security vulnerability, they must estimate its severity by weighing its potential impact against the likelihood that a problem will arise. Table 3.1 shows how our auditors weigh this information to estimate the severity of a given issue. Table 3.1:Severity Breakdown. Somewhat BadBadVery BadProtocol Breaking Not LikelyInfoWarningLowMedium LikelyWarningLowMediumHigh Very LikelyLowMediumHighCritical In this case, we judge the likelihood of a vulnerability as follows: Not Likely A small set of users must make a specific mistake Requires a complex series of steps by almost any user(s) Likely - OR - Requires a small set of users to perform an action Very LikelyCan be easily performed by almost anyone In addition, we judge the impact of a vulnerability as follows: Somewhat BadInconveniences a small number of users and can be fixed by the user Affects a large number of people and can be fixed by the user Bad- OR - Affects a very small number of people and requires aid to fix Affects a large number of people and requires aid to fix Very Bad - OR - Disrupts the intended behavior of the protocol for a small group of users through no fault of their own Protocol BreakingDisrupts the intended behavior of the protocol for a large group of users through no fault of their own ©2023 Veridise Inc.Veridise Audit Report: ANKR Vulnerability Report4 In this section, we describe the vulnerabilities found during our audit. For each issue found, we log the type of the issue, its severity, location in the code base, and its current status (i.e., acknowleged, fixed, etc.). Table 4.1 summarizes the issues discovered: Table 4.1:Summary of Discovered Vulnerabilities. IDDescriptionSeverityStatus V-ANS-VUL-001Users Charged Twice by ERC20 Staking PoolCriticalFixed V-ANS-VUL-002Locked Funds in Staking PoolHighFixed V-ANS-VUL-003Potential ReentrancyMediumFixed V-ANS-VUL-004Missing Requirements on Unstaking AmountMediumFixed V-ANS-VUL-005Unguarded External FunctionLowFixed V-ANS-VUL-006Incorrect Gap TrackingLowFixed V-ANS-VUL-007Min Delegation Requirement BypassedLowIntended Behavior V-ANS-VUL-008Inconsistent Values Provided to FunctionLowFixed V-ANS-VUL-009Potential Unlock DoSLowFixed V-ANS-VUL-010Potential Theft from QueueLowFixed V-ANS-VUL-011Potential Underpay for SharesLowOpen V-ANS-VUL-012Wasting Gas via External CallWarningFixed V-ANS-VUL-013Double Converting between Shares and BondsWarningIntended Behavior V-ANS-VUL-014Unused StateWarningIntended Behavior V-ANS-VUL-015Duplicated CodeWarningInvalid V-ANS-VUL-016Potential Overflow on DowncastWarningFixed V-ANS-VUL-017Potentially Unsafe ConditionalWarningOpen Veridise Audit Report: ANKR©2023 Veridise Inc. 84 Vulnerability Report 4.1 Detailed Description of Bugs 4.1.1 V-ANS-VUL-001: Users Charged Twice by ERC20 Staking Pool SeverityCriticalCommitc298180 TypeLocked FundsStatusFixed FilesERC20LiquidTokenStakingPool Functions\_beforeStake The ERC20LiquidTokenStakingPool contract extends the LiquidTokenStakingPool so that users can pay with ERC20 tokens rather than native tokens. To do so, the developers override the \_ beforeStakeutility function to accept ERC20 payments from users as shown below. 1function \_ beforeStake( 2addressaccount, 3uint256amount, 4uint256/ \* shares \* / 5)internalvirtual override { 6require( 7 \_ stakeableToken.transferFrom(account,address(this), amount), 8"failed to receive stakeableToken" 9); 10} Snippet 4.1:The override of \_ beforeStaketo accept ERC20 payments The contract, however, does not override the staking functionality that it inherits from the LiquidTokenStakingPool contract. As shown below, however, these functions require payment in native tokens. 1functionstakeBonds() 2external 3payable 4override 5nonReentrant 6bondStakingUnpaused 7{ 8 \_ stakeBonds(msg.sender,msg.value); 9} 10 11functionstakeCerts()external payableoverride nonReentrant { 12 \_ stakeCerts(msg.sender,msg.value); 13} Snippet 4.2:The functions used to stake funds in the Liquid Staking Pool ImpactGiven that the staking functions require payment in native token, and that this contract transfers ERC20 tokens from the user without crediting them additional funds, the contract ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs9 essentially charges users twice. In addition, if \_ unsafeTransferis used to pay the user back on an unstake (as done in other extensions), these users will only be refunded the ERC20 tokens. RecommendationAdd a separate API specifically for ERC20 tokens so that users will not need to pay ERC20 tokens and native tokens. In addition, if the intention is to only accept ERC20 tokens move the staking functionality from LiquidTokenStakingPool to one of the extensions. Veridise Audit Report: ANKR©2023 Veridise Inc. 104 Vulnerability Report 4.1.2 V-ANS-VUL-002: Locked Funds in Staking Pool SeverityHighCommitc298180 TypeLocked FundsStatusFixed FilesQueueLiquidTokenStakingPool.sol Functions\_distributePendingRewards If the LiquidStakingPool does not have sufficient funds to pay all unstaking users, those users will be placed in a queue to wait for more funds to become available. Refunds are then distributed by popping users off the queue and sending the appropriate refund. If the funds are not successfully sent, the user is moved out of the queue and their funds must be claimed manually by the user. During the process in which funds are marked as manually claimed, however, a user’s \_ pendingClaimerUnstakes state is not updated to reflect that they no longer have funds in the queue to claim as shown below. 1function \_ distributePendingRewards()internal{ 2... 3 4while( 5i < \_ pendingClaimers.length&& 6poolBalance > 0 && 7gasleft() > \_ DISTRIBUTE \_ GAS \_ LIMIT 8) { 9addressclaimer = \_ pendingClaimers\[i\]; 10... 11uint256toDistribute = \_ pendingClaimerUnstakes\[claimer\]; 12... 13boolsuccess = \_ unsafeTransfer(claimer, toDistribute,true); 14/ \* when we delete items from array we generate new gap, lets remember how many gaps we did to skip them in next claim \* / 15if(!success) { 16toDistribute = \_ pendingClaimerUnstakes\[claimer\]; 17// already accounted in var \_ stashedForManualClaims 18 \_ pendingTotalUnstakes -= toDistribute; 19 \_ setForManualClaim(claimer, toDistribute); 20gaps++; 21i++; 22continue; 23} 24... 25} 26... 27emitRewardsDistributed(claimers, amounts); 28} Snippet 4.3:Snippet of the refund distribution function that handles situations where funds are not successfully sent ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs11 Since the \_ pendingClaimerUnstakes state is non-zero if a user must ever perform a manual claim, future attempts to add a user will update the user’s refund state but will not add the user to the queue as shown below. 1function \_ addIntoQueue(addressclaimer,uint256amount)internal{ 2require( 3claimer !=address(0), 4"LiquidTokenStakingPool: claimer is zero address" 5); 6if( \_ pendingClaimerUnstakes\[claimer\] == 0) { 7 \_ pendingClaimers.push(claimer); 8} 9 \_ pendingTotalUnstakes += amount; 10 \_ pendingClaimerUnstakes\[claimer\] += amount; 11emitPendingUnstake(claimer, claimer, amount); 12} Snippet 4.4:The function that adds users to the refund queue. ImpactSince users who have required manual claims in the past will not be added to the refund queue array, their funds will be locked within the contract. RecommendationWhen a user must manually claim funds, ensure \_ pendingClaimerUnstakes is properly updated. Veridise Audit Report: ANKR©2023 Veridise Inc. 124 Vulnerability Report 4.1.3 V-ANS-VUL-003: Potential Reentrancy SeverityMediumCommitc298180 TypeReentrancyStatusFixed FilesManualClaimLiquidTokenStakingPool.sol FunctionsclaimManually It is common practice to guard against reentrancy vulnerabilities by modifying state before making potentially dangerous calls to untrusted sources. TheclaimManuallyfunction, however, makes an external call to some receiver and then adjust the contract state as shown below. 1functionclaimManually(uint256id)externalnonReentrant { 2... 3 4boolresult = \_ unsafeTransfer(receiverAddress, amount,false); 5require( 6result, 7"LiquidTokenStakingPool: failed to send rewards to receiverAddress" 8); 9 \_ stashedForManualClaims -= amount; 10 \_ manualClaims\[receiverAddress\] = 0; 11 \_ markedForManualClaim\[id\] =address(0); 12emitRewardsClaimed(receiverAddress,msg.sender, amount); 13} Snippet 4.5:TheclaimManuallyfunction makes an unsafe call before modifying state. ImpactWhile a majority of the external functions are guarded with a reentrancy guard, a few functions are not guarded. In addition, several view functions and modifiers could use stale values, such as:getFreeBalance,getStashedForManualClaims,getForManualClaimOfand getForManualClaimOf. RecommendationPerform the state modifications before the given external call. ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs13 4.1.4 V-ANS-VUL-004: Missing Requirements on Unstaking Amount SeverityMediumCommitc298180 TypeLocked FundsStatusFixed FilesLiquidTokenStakingPool.sol Functions\_unstakeCertsFor InLiquidTokenStakingPool.sol, the functions \_ unstakeBondsForand \_ unstakeCertsForlack lower bounds on the amount to be unstaked. This is a problem because it allows users to first stake some amount of shares, then unstake an amount just under the value of a share without losing any staked shares. To understand, consider the following code from \_ unstakeBondsFor : 1function \_ unstakeBondsFor(addressreceiverAddress,uint256amount) 2internal 3{ 4addressownerAddress =msg.sender; 5uint256shares = \_ bearingToken.bondsToShares(amount); 6... 7 \_ certificateToken.burn(address( \_ bearingToken), shares); 8 \_ bearingToken.burn(ownerAddress, shares); 9 \_ afterUnstake(ownerAddress, receiverAddress, amount); 10... 11} SincebondsToSharesrounds, it’s possible that the amount returned to the user when unstaking is incorrect. ImpactWithout the restriction onamount, it’s possible that a user may unstake almost an entire share’s worth of ether for free, or accidentally lose a share with almost no ether returned to them. RecommendationIn both the \_ unstakeBondsForand \_ unstakeCertsForfunctions, include the following requirement on the amount to unstake: 1require(amount >= getMinStake() && amount % getMinStake() == 0) Alternatively, convert the number of shares to burn back to bonds to determine the actual value of the burnt shares. Veridise Audit Report: ANKR©2023 Veridise Inc. 144 Vulnerability Report 4.1.5 V-ANS-VUL-005: Unguarded External Function SeverityLowCommitc298180 TypeReentrancyStatusFixed FilesReferralLiquidTokenStakingPool.sol FunctionsstakeBondsWithCode, stakeCertsWithCode A majority of the liquid staking pools in the earn repository use a ReentrancyGuard to prevent potential reentrancy vulnerabilities. The ReferralLiquidTokenStakingPool contract, however, does not use such a reentrancy guard and is inherited by MixedLiquidTokenStakingPool which does have suitable reentrancy protections. Since there are several locations where control is transferred to the user, we would recommend protecting these functions with a ReentrancyGuard. 1functionstakeBondsWithCode(bytes32code)external payableoverride { 2 \_ stakeBonds(msg.sender,msg.value); 3emitReferralCode(code); 4} 5 6functionstakeCertsWithCode(bytes32code)external payableoverride { 7 \_ stakeCerts(msg.sender,msg.value); 8emitReferralCode(code); 9} Snippet 4.6: The functions within ReferralLiquidTokenStakingPool that are not protected by a reentrancy guard. ImpactSuch unprotected external functions could leave the protocol open to reentrancy attacks. RecommendationGuard all external functions with a ReentrancyGuard. ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs15 4.1.6 V-ANS-VUL-006: Incorrect Gap Tracking SeverityLowCommitc298180 TypeLogic ErrorStatusFixed FilesQueueLiquidTokenStakingPool.sol Functions\_distributePendingRewards Thegapvariable is not correctly tracked in all potential branches in the following code snippet of \_ distributePendingRewardsfunction: 1function \_ distributePendingRewards()internal{ 2... 3uint256gaps = 0; 4uint256i = \_ pendingGap; 5 6while( 7i < \_ pendingClaimers.length&& 8poolBalance > 0 && 9gasleft() > \_ DISTRIBUTE \_ GAS \_ LIMIT 10) { 11addressclaimer = \_ pendingClaimers\[i\]; 12// if claimer for manual distribute skip him and increase ’i’ 13if(this.isMarkedForManualClaim(claimer)) { 14i++; 15continue; 16} 17uint256toDistribute = \_ pendingClaimerUnstakes\[claimer\]; 18if(claimer ==address(0) || toDistribute == 0) { 19i++; 20gaps++; 21continue; 22} 23 24... 25if(!success) { 26toDistribute = \_ pendingClaimerUnstakes\[claimer\]; 27// already accounted in var \_ stashedForManualClaims 28 \_ pendingTotalUnstakes -= toDistribute; 29 \_ setForManualClaim(claimer, toDistribute); 30gaps++; 31i++; 32continue; 33} 34... 35i++; 36gaps++; 37} 38 \_ pendingGap += gaps; 39... 40} Snippet 4.7:Snippet of the \_ distributePendingRewardsfunction wheregapis updated Veridise Audit Report: ANKR©2023 Veridise Inc. 164 Vulnerability Report In particular, when a claimer is skipped due to being marked for manual claim, the corresponding gapis not increased which causes miscalculation of the gaps in the array \_ pendingClaimers. ImpactFor an array of \_ pendingClaimersthat has at least one claimer that is marked for manual claim and skipped in the middle of the while iteration, the next time the function \_ distributePendingRewards is invoked, the very last (few) claimer processed in the previous call to this function will be processed again. RecommendationThegapvariable is not needed since it synchronizes withi; useiinstead to track the gaps on the array. ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs17 4.1.7 V-ANS-VUL-007: Min Delegation Requirement Bypassed SeverityLowCommitc298180 TypeLogic ErrorStatusIntended Behavior FilesBNBStakingPool.sol Functionsundelegate When using theBNBStakingPool, there is a requirement on the minimum amount allowed to be delegated. However, this requirement can be circumvented by performing the following operations: 1.delegatethe amountminDelegation + e 2.undelegatethe amountminDelegation Sinceundelegatedoes not check that the resulting amount delegated is at leastminDelegation (only that the amount undelegated is at leastminDelegation), this may result in a state where the amount delegated ise, which may be less thanminDelegation 1functionundelegate(addressvalidator,uint256amount) { 2... 3uint256minDelegate = \_ stakingContract.getMinDelegation(); 4require( 5amount >= minDelegate, 6"BNBStakingPool: amount less than minDelegate amount" 7); 8... 9} Snippet 4.8:The undelegate function that does not ensure the minimum amount is delegated. ImpactAllowing stakers to delegate less than theminDelegationamount may violate properties of the consensus protocol. RecommendationAdd additional constraints toundelegatethat ensures either zero or at least minDelegationfunds remain. Developer ResponseTheminDelegatevariable is not used to indicate the minimum value that should be delegated but rather the smallest amount that can be delegated or undelegated at once. Veridise Audit Report: ANKR©2023 Veridise Inc. 184 Vulnerability Report 4.1.8 V-ANS-VUL-008: Inconsistent Values Passed to Token Transfer Utility Functions SeverityLowCommitc298180 TypeLogic ErrorStatusFixed FilesBearingToken.sol Functions\_transfer, \_mint, \_burn Similar to OpenZeppelin’s ERC20 contract, the BearingToken contract allows inherited con- tracts to add behaviors to a token transfer using two functions: \_ beforeTokenTransferand \_ afterTokenTransfer. Unlike an ERC20 contract, however, theBearingTokentracks two values (bonds and shares) using a single token. When calling \_ beforeTokenTransferand \_ afterTokenTransfer in some casesbondsare passed to the function while in otherssharesare passed to the function as shown below. 1function \_ transfer( 2addressfrom, 3addressto, 4uint256amount 5)internalvirtual override { 6uint256shares = bondsToShares(amount); 7require(from !=address(0), "ERC20: transfer from the zero address"); 8require(to !=address(0), "ERC20: transfer to the zero address"); 9 \_ beforeTokenTransfer(from, to, amount); 10... 11 \_ afterTokenTransfer(from, to, amount); 12} Snippet 4.9:Definition of the \_ transferfunction that calls the utility functions with bonds. 1function \_ mint(addressaccount,uint256shares)internalvirtual override { 2uint256amount = sharesToBonds(shares); 3require(account !=address(0), "ERC20: mint to the zero address"); 4 \_ beforeTokenTransfer(address(0), account, shares); 5... 6 \_ afterTokenTransfer(address(0), account, shares); 7} 8 9function \_ burn(addressaccount,uint256shares)internalvirtual override { 10uint256amount = sharesToBonds(shares); 11require(account !=address(0), "ERC20: burn from the zero address"); 12 \_ beforeTokenTransfer(account,address(0), shares); 13... 14 \_ afterTokenTransfer(account,address(0), shares); 15} Snippet 4.10:Definition of the \_ mintand \_ burnfunctions that calls the utility functions with shares. ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs19 ImpactAny functionality that is added to transfer using these functions in the future is extremely likely to introduce errors as the function has no way of determining if shares or bonds are provided. RecommendationEither only pass bonds to these functions or only pass shares. Veridise Audit Report: ANKR©2023 Veridise Inc. 204 Vulnerability Report 4.1.9 V-ANS-VUL-009: Potential Unlock DoS SeverityLowCommitc298180 TypeDenial of ServiceStatusFixed FilesBearingToken.sol Functions\_mint The BearingToken allows users tolockandunlockCertificateTokens within the contract. When these tokens arelocked, they are transferred to the BearingToken contract and new BearingTokens are minted for the user. They can thenunlockedwhich burns the BearingTokens and transfers CertificateTokens back to the user. Since the CertificateTokens are owned by the BearingToken and transferred to the user on anunlock, it is possible that if BearingTokens are unbacked by CertificateTokens, every holder of BearingTokens could notunlock. Since there is a separate mint function that does not check if new BearingTokens are backed by CertificateTokens it is possible that this can happen in the future. 1function \_ mint(addressaccount,uint256shares)internalvirtual override { 2uint256amount = sharesToBonds(shares); 3require(account !=address(0), "ERC20: mint to the zero address"); 4 \_ beforeTokenTransfer(address(0), account, shares); 5 \_ totalSupply += shares; 6 \_ shares\[account\] += shares; 7emit Transfer(address(0), account, amount); 8 \_ afterTokenTransfer(address(0), account, shares); 9} Snippet 4.11:The \_ mintfunction that does not ensure minted tokens are backed. ImpactIf a user is able to receive unbackedBearingTokens, they could intentionallyunlock them as a Denial of Service attack against the unlocking functionality of theBearingToken RecommendationCurrently themintAPI is used correctly in that Certificate Tokens are minted to the BearingToken when BearingTokens are minted for a user. However, we would recommend that the developers add a check in themintfunction to ensure that theBearingToken is backed by a sufficient number ofCertificateTokensto prevent any future mistakes. ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs21 4.1.10 V-ANS-VUL-010: Potential Theft from Queue SeverityLowCommitc298180 TypeTheftStatusFixed FilesQueueLiquidTokenStakingPool Functions\_addIntoQueue If the LiquidStakingPool does not have sufficient funds to pay all unstaking users, those users will be placed in a queue to wait for more funds to become available. Currently the queue maintains an array of users to be repaid and mapping of amounts to repay individual users. When added to the queue, a check is performed to see if a user has a pending refund. If they don’t, they will be added to the end of the array. In addition their pending refund amount will be increased. This implementation has an implicit assumption that any user in the queue also has a non-zero refund amount. As shown below though, there is no check to prevent a user from being added to the queue with a refund of 0. 1function \_ addIntoQueue(addressclaimer,uint256amount)internal{ 2require( 3claimer !=address(0), 4"LiquidTokenStakingPool: claimer is zero address" 5); 6if( \_ pendingClaimerUnstakes\[claimer\] == 0) { 7 \_ pendingClaimers.push(claimer); 8} 9 \_ pendingTotalUnstakes += amount; 10 \_ pendingClaimerUnstakes\[claimer\] += amount; 11emitPendingUnstake(claimer, claimer, amount); 12} Snippet 4.12:The function that adds users to the refund queue. ImpactSinceaddToQueuewill allow a user to be added with a refund amount of 0, an attacker could be added multiple times with a zero refund amount so that they appear in the queue multiple times. They could then be added one more time with a non-zero refund to potentially receive multiple non-zero refunds from the pool. RecommendationWhile the current implementation won’t allow a user to be added to the queue with a zero refund due to a conditional in another function, Veridise Audit Report: ANKR©2023 Veridise Inc. 224 Vulnerability Report 4.1.11 V-ANS-VUL-011: Potential Underpay for Shares SeverityLowCommitc298180 TypeTheftStatusOpen FilesLiquidTokenStakingPool.sol Functions\_stakeBonds When staking some amount, it’s possible for users to underpay for shares due to the nature of thebondsToSharesconversion. The following code fromLiquidTokenStakingPoolcalculates the number of shares to stake for a given amount of bonds: 1function \_ stakeBonds(addressstaker,uint256amount)internal{ 2uint256shares = \_ bearingToken.bondsToShares(amount); 3 \_ stake(staker, amount, shares,true); 4 \_ afterStake(staker, amount, shares); 5} However, sincebondsToSharesrounds up, it is possible to stake a small amount of bonds and still acquire a share. This is possible whenevergetMinStake() % sharesToBonds(1) != 0 ImpactUsers may acquire shares for cheaper than expected, resulting in a loss of funds. RecommendationAdd a requirement that the amount staked should be a positive multiple of sharesToBonds(1). This can be implemented in a variety of ways, but we recommend doing so by maintaining the invariantgetMinStake() % sharesToBonds(1) == 0 && getMinStake() > 0. This could be done by: 1.Adding the following requirement to thesetMinimumStakefunction:require(newValue % sharesToBonds(1) == 0 && newValue > 0) 2.Adding the following call to thesetInternetBondRatioFeedfunction: \_ liquidStakingPool. setMinimumStake(sharesToBonds(1)) Alternatively,getMinStakecould returnsharesToBonds(1) \* MwhereMis number set by setMinStaketo indicate how many multiples someone must stake. Since \_ stake already has the requirementamount%getMinStake()==0 && amount>=getMinStake(), this will ensure the invariant that any number of sharesNstaked has been paid for by the appropriate number of bonds from the user. ©2023 Veridise Inc.Veridise Audit Report: ANKR 4.1 Detailed Description of Bugs23 4.1.12 V-ANS-VUL-012: Wasting Gas via External Call SeverityWarningCommitc298180 TypeGas OptimizationStatusFixed FilesMultiple FunctionsMultiple In several contracts, external functions are being invoked using the formthis.fn(...)as shown below. Such invocations cause the function to be invoked via an external call rather than a function call. 1functiongetFreeBalance()external viewvirtual overridereturns(uint256) { 2return 3address(this).balance \_exits\[provider\].add(\_configContract.getConfig("EXIT\_BLOCKS")),"Recentlyexited"); delete\_exits\[msg.sender\]; \_; } The\_exitsstatevariableisusedinthenotExitRencently()modifier,whichmodifiesthe claimAETH()andclaimFETH()function. legacy/contracts/upgrades/GlobalPool\_R42.sol:L606-L613 functionsoftLockBlockNumber(addressprovider)publicviewreturns(uint256){ uint256exitedAt=\_exits\[provider\]; if(exitedAt==0){ return0; } uint256waitFor=\_configContract.getConfig("EXIT\_BLOCKS"); returnexitedAt.add(waitFor); } The\_exitsisalsousedinthesoftLockBlockNumber()function. However,the\_exitsvariableisnotbeingsetbyanyfunctionintheGlobalPool\_R42contract. Recommendation TheoperatorcancallforceAdminProviderExit()tomakeprovidersexit.Thisfunctionuses the\_forceProviderExitFor()internalfunctiontohandleitsbusinesslogic.Wesuspect \_forceProviderExitFor()shouldupdate\_exitsbutdoesnot.Ifthatisthecase,we recommendupdating\_exitsin\_forceProviderExitFor(). Status Theteamhasresolvedthisissuebyremovingthelogicrelatedto\_exits. 8 3.LackofaccesscontroloncleanUserLocks() Severity:MediumCategory:Accesscontrol Target: -legacy/contracts/upgrades/AnkrDeposit\_R3.sol Description ThecleanUserLocks()functioninAnkrDeposit\_R3contractisusedbyotherfunctions(e.g. \_claimAndDeposit(),\_unfreeze())toclearthelockinformationforauser. However,thisfunctionisdefinedasapublicfunction,meaninganyonecancallit,whichcan resultinstate-changinglogicbeingexecutedinanunintendedcontext. Recommendation IfcleanUserLocks()isdesignedforinternaluseonly,changeitsvisibilitytointernalor private.Ifitisalsoforexternaluse,addproperaccesscontroltoit. Status Thisissuehasbeenacknowledgedbytheteam.Theteamstatedthatpublicisokayfor cleanUserLocksbecauseithasanifstatementtoskiplocksthatdonotend. 9 4.Slashedamountforeachprovidersisnottracked Severity:MediumCategory:Businesslogic Target: -legacy/contracts/upgrades/GlobalPool\_R42.sol Description The slashETH()functionintheGlobalPool\_R42contractcanbeusedbytheoperatorto slashaprovider.However,thisfunctiononlytracksthetotalslashedamount, \_totalSlashedETH,anddoesnottracktheamountslashedforeachindividualprovider. The slashingsOf()functionintheGlobalPool\_R42contractisintendedtoreturntheamount slashedforaprovider,butcurrentlyitreturnszero.Thismaycauseconfusionforendusers anddeveloperswhowishtointegratetheprotocol. Recommendation Werecommendaddingastatevariabletotracktheamountslashedforaprovider,and updatingitintheslashETH()function.Then,wecanusethisstatevariableinthe slashingsOf()functiontoreturntheamountslashedfortheprovider. Status TheteamhasresolvedthisissuebyremovingthelogicrelatedtoslashedETH. 10 5.Returnvalueof\_unsafeTransferisnotbeingcheckedin severalplaces Severity:MediumCategory:Validation Target: -legacy/contracts/upgrades/GlobalPool\_R42.sol Description The\_unsafeTransfer()functionintheGlobalPool\_R42contractreturnsabooleanvalue indicatingwhetherthetransferissuccessfulornot. However,thepushToVault()anddistributeRewards()functionsuse\_unsafeTransfer()without checkingitsreturnvalue.Thiscanresultin \_unsafeTransfer()failingsilentlyandthe subsequentlogicbeingexecutedregardless. Recommendation Addacheckfor\_unsafeTransfer()’sreturnvalueinthesefunctions. Status Theteamhasresolvedthisissue. 11 6.Lackofaccesscontrolonclaim() Severity:LowCategory:Accesscontrol Target: -legacy/contracts/upgrades/FeeRecipient\_R1.sol Description Theclaim()functionintheFeeRecipient\_R1contractisintendedtotransferthebalanceto theGlobalPoolandthetreasury.Currently,anyonecancallthisfunction,whichcouldresult initbeingexecutedinanunintendedcontext. Recommendation Currently,theclaim()functioniscalledbytheupdateRatioAndClaim()functioninthe AETH\_R18contract.Werecommendaddingproperaccesscontroltothe claim()functionifit isdesignedtobeusedonlybyAETH. Alternatively,ifthefunctionisintendedforpublicuse,wesuggestaddingacommentto indicateitspublicvisibilityandpreventtheadditionofsensitiveoperationsinfuture upgrades. Status Thisissuehasbeenacknowledgedbytheteam.Theteamhasstatedthattheclaimdoesn’t haveanyspecialcontext,itcanbetriggeredwithoutrestrictions,thegoalistotransferETH tothetreasuryandstakingpool. 12 7.FlawedimplementationoftotalSupply() Severity:LowCategory:Businesslogic Target: -legacy/contracts/upgrades/FETH\_R18.sol Description IntheFETH\_R18contract,userscanusethelockShares()andunlockShares()functionsto swapbetweenAETH(i.e.ankrETH)andFETH(i.e.aETHb).The\_sharesstatevariableis usedtotrackthelockedamountforauser,andthebalanceOf()functionreturnstheFETH balanceofauserbasedonthe\_shares\[user\]value. legacy/contracts/upgrades/FETH\_R18.sol:L124-L127 functiontotalSupply()publicviewoverridereturns(uint256){ uint256totalLocked=IERC20(\_aEthContract).balanceOf(address(this)); returnsharesToBonds(totalLocked); } However,thetotalSupply()functionintheFETHcontractusesthecontract’sAETHbalance asthetotallockedAETHshares.ThiscouldleadtoissuesbecausepeoplecansendAETH tokendirectlytothecontractwithoutusingthelockShares()function.Asaresult,thesumof lockeduserAETHsharesmaynotequaltheAETHbalanceinthecontract.Thismeansthat totalSupply()’sreturnvaluemaynotequalthesumofthebalanceOf()foralltheusers,and thecallerofFETH’stotalSupply()mayusethisincorrectvalueinitssubsequentlogic. Recommendation ConsideraddingastatevariabletotrackthetotallockedAETHamountinthecontract.This statevariablecanbeupdatedwheneverauserlocksorunlocksAETHshares.Wecanthen usethisvariableinthe totalSupply()functiontoreturnthecorrecttotalsupplyofFETH. Status Thisissuehasbeenacknowledgedbytheteam. 13 8.Incorrectvalueloggedinevent Severity:LowCategory:Logging Target: -legacy/contracts/upgrades/FETH\_R18.sol Description legacy/contracts/upgrades/FETH\_R18.sol:L73-L87 functionlockShares(uint256shares)external{ addressspender=msg.sender; //transfertokensfromaETHctoaETHb require(IERC20(\_aEthContract).transferFrom(spender,address(this),shares),"can't transfer"); //calcswapfee(defaultswapfeeratiois0.3%=0.3/100\*1e18,feecan'tbegreater than1%) uint256fee=shares.mul(\_swapFeeRatio).div(1e18); if(msg.sender==\_swapFeeOperator){ fee=0; } uint256sharesWithFee=shares.sub(fee); //increasesendersandoperatorbalances \_shares\[\_swapFeeOperator\]=\_shares\[\_swapFeeOperator\].add(fee); \_shares\[spender\]=\_shares\[spender\].add(sharesWithFee); emitLocked(spender,shares); } IftheLocked()eventinthecodeismeanttorecordtheshareslockedforauser,thenthe lockShares()functionshould emitLocked(spender,shares.sub(fee)) instead. Recommendation LogtheactualshareslockedforauserintheLocked()event. Additionally,toimproveclarity,werecommendredesigningtheLocked()eventto event Locked(addressaccount,uint256lockedShare,uint256fee) . Status Theteamhasresolvedthisissue. 14 9.mint()doesnotreturncorrectvalue Severity:LowCategory:Businesslogic Target: -legacy/contracts/upgrades/AETH\_R18.sol Description legacy/contracts/upgrades/AETH\_R18.sol:L92-L95 functionmint(addressaccount,uint256amount)externalreturns(uint256\_amount){ require(msg.sender==address(\_bscBridgeContract)||msg.sender== address(\_globalPoolContract),'Notallowed'); \_mint(account,amount); } Themint()functionintheAETH\_R18contractisdefinedtoreturnauint256value.However, thereiscurrentlynoreturnstatementinthisfunction,andthereturnparameter,\_amount,is notbeingupdatedinthefunction. Recommendation Ifthemint()functionismeanttoreturnavalue,wesuggestaddingareturnstatementinthe functiontoreturnthecorrectvalue. Alternatively,ifthemint()functiondoesnotneedtoreturnavalue,werecommendchanging itsdefinitionto functionmint(addressaccount,uint256amount)external{...} .Thiswillmake itclearthatthefunctiondoesnotreturnavalue. Status Theteamhasresolvedthisissue. 15 2.3InformationalFindings 10.Mismatchbetweencodeanddescription Severity:InformationalCategory:Codequality Target: -deposit-wrapper/contracts/DepositWrapper.sol -legacy/contracts/upgrades/GlobalPool\_R42.sol Description 1.deposit-wrapper/contracts/DepositWrapper.sol:L186-L189 require( newDepositAddr!=pauseAddr, "Depositaddressmustbedifferentfromdepositaddress" ); Theerrormessageshouldbe"Depositaddressmustbedifferentfrompauseaddress". 2.legacy/contracts/upgrades/GlobalPool\_R42.sol:L125 mapping(address=>uint256)private\_aETHProviderRewards;//slot:323 Thecommentstatesthattheslotfor\_aETHProviderRewardsis323,butinreality,itis328. 3.legacy/contracts/upgrades/GlobalPool\_R42.sol:L615-L618 /\*\* @devSlasheth,returnsremainingneedstobeslashed \*/ functionslashETH(addressprovider,uint256amount)publiconlyOperator{ ThecommentindicatesthattheslashETH()shouldreturnavalue.However,theslashETH() isdefinedwithoutareturnvalue. 4.legacy/contracts/upgrades/GlobalPool\_R42.sol:L361 r equire(amount>=\_configContract.getConfig("UNSTAKE\_MIN\_AMOUNT"),"Valuemustbe greaterthanminimumamount"); The“greaterthan”shouldbe“nolessthan”. Recommendation Alignthedescriptionwiththecode. Status Theteamhasresolvedthisissue. 16 11.Mixeduseofreentrancypreventionmodifiers Severity:InformationalCategory:Reentrancy Target: -legacy/contracts/upgrades/GlobalPool\_R42.sol Description IntheGlobalPool\_R42contract,boththeunlock()modifierandnonReentrant()modifierare usedtopreventreentrancyattacks.Theissuewithmixeduseofthemisthatafunction modifiedbyunlock()canenterafunctionmodifiedbynonReentrant()andviceversa.In otherwords,cross-functionreentrancyispossiblewhenyoumixthesetworeentrancy preventionmodifiersinonecontract. Recommendation Replacetheunlock()modifierwiththenonReentrant()modifierthroughoutthecontract. Status Theteamhasresolvedthisissue. 17 12.Missingreentrancyguard Severity:InformationalCategory:Reentrancy Target: -legacy/contracts/upgrades/GlobalPool\_R42.sol Description ThenonReentrant()modifiercanbeaddedtothefollowingfunctionsintheGlobalPool\_R42 contracttopreventtheintroductionoffuturereentrancyvulnerabilities: -distributeRewards() -claimManually() Recommendation ConsideraddingthenonReentrant()modifiertothesefunctions. Status Theteamhasresolvedthisissue. 18 13.CanaddoldparameterstoSwapFeeParamsChanged()event Severity:InformationalCategory:Logging Target: -legacy/contracts/upgrades/FETH\_R18.sol Description TheSwapFeeParamsChanged()eventonlylogsthenewvalues,whiletheother“changed” events(e.g.GlobalPoolAddressChanged())logboththepreviousvalueandthenewvalue. Toprovidemoreinformationandcontextinthe SwapFeeParamsChanged()event,we suggestaddingtheoldparameterstotheeventaswell.Thiswillallowdevelopersandusers toseethepreviousvaluesoftheparametersandbetterunderstandthechangesmadeto theswapfeeparameters. Recommendation Change eventSwapFeeParamsChanged(addressoperator,uint256ratio); To eventSwapFeeParamsChanged(addressprevOperator,addressnewOperator,uint256prevRatio, uint256newRatio); andupdatingtheeventemittingcodeaccordingly. Status Theteamhasresolvedthisissue. 19 14.Lackofevents Severity:InformationalCategory:Logging Target: -legacy/contracts/upgrades/GlobalPool\_R42.sol -legacy/contracts/upgrades/FeeRecipient\_R1.sol Description 1.LackofeventwhenpoolBalanceisinsufficientindistributeRewards() WhenpoolBalanceisinsufficienttodistributefurtherrewards,thedistributeRewards() functiondoesnotemitrelevantevents.Toenableoff-chaintrackingforthissituation,an eventforthissituationshouldbeaddedtonotifytheteamandallowthemtotakeappropriate action. 2.LackofeventinFeeRecipient’sclaim()function Theclaim()functionintheFeeRecipient\_R1contractisacriticalfunctionthattransfersfunds tothepoolandthetreasury.However,norelevanteventsareemittedinthisfunction.To enableoff-chaintracking,werecommenddefininganappropriateeventandemittingitinthe claim()function. Recommendation Designpropereventsandaddthemtoaforementionedfunctions. Status Theteamhasacknowledgedthisissue. 20 15.Redundantcode Severity:InformationalCategory:Redundancy Target: -timelock/time-lock/contracts/AnkrTimeLock.sol -legacy/contracts/upgrades/FETH\_R18.sol -legacy/contracts/upgrades/GlobalPool\_R42.sol Description 1.timelock/time-lock/contracts/AnkrTimeLock.sol:L6-L7 //Uncommentthislinetouseconsole.log //import"hardhat/console.sol"; Theabovelinesareunnecessaryandcanberemovedbeforedeployingthecontract. 2.TheonlySwapFeeOperator()modifierintheFETH\_R18isdefinedbutnotused. 3.Logicthathasbeencommentedoutcanberemoved. Recommendation Removetheredundantcode. Status Theteamhasresolvedthisissue. 21 Appendix Appendix1-FilesinScope Thisauditcoveredthefollowingfiles: 1.TheDepositWrappercontractinpullrequest514: FileSHA-1hash eth-deposit-wrapper/contracts/DepositWrapper.sol7649c3e8b91e01fe7cab7228380f88d7c4fe2f76 2.TheAnkrTimeLockcontractinpullrequest505: FileSHA-1hash time-lock/contracts/AnkrTimeLock.sole6ddc47cafb6ae6c50c66d773c2fcd9ad48e3392 3.Thefollowingfilesincommit71a4183: FileSHA-1hash legacy/contracts/Config.sol6417bffeb53287b84a3cca96ffd6f2764c183f1c legacy/contracts/Governable.sola33d161fbee771da246e78643d69c942ec4b92d6 legacy/contracts/SystemParameters.sol206aaaf1bf2e8a8add4e32b8593596031edaa433 legacy/contracts/WithdrawalPool.sol59d754f3d47a5d02ce9fd72a13dbebd9dc9c5d63 legacy/contracts/lib/Lockable.sold4cd0ba14a368e85494c28ae8a805628713e193d legacy/contracts/lib/MathUtils.sol744b1d9c802aa2720eb411c9399482ba9aa8f485 legacy/contracts/lib/Ownable\_R1.sol3292409bf77499da7569ba68dcf9bcc530e9a607 legacy/contracts/lib/Pausable.sol47447228ed508e26ffea4bc42f2be3ec4325396e legacy/contracts/lib/interfaces/IAETH.sol876e6df562909ab6094dfe97e58a925438df420d legacy/contracts/lib/interfaces/IConfig.sol8fa3a101ba9369d5ced7fd323433d3dd93245c65 legacy/contracts/lib/interfaces/IDepositContract.sole30792721e4299995549a296663fc19cbcaa27bf legacy/contracts/lib/interfaces/IFETH.sol1ef777e075775643d3a8883404e0ccf7cb36c048 legacy/contracts/lib/interfaces/IFeeRecipient.sol23846760b12254494e94295177b9bc1d21461abc legacy/contracts/lib/interfaces/IGlobalPool.sol80dfe187de9eb9251b113f30ec2be11e65d541c9 22 legacy/contracts/lib/interfaces/IWithdrawalPool.sol5ff64705c97f87e87e1c742b768f6fff3f8b9c04 legacy/contracts/lib/openzeppelin/ERC20UpgradeS afe.sol1001e78c89b070e04c249242ebab224fc98e02cb legacy/contracts/upgrades/AETH\_R18.sol7bd5a51b994825b6a005eee3cd122efd07b7027c legacy/contracts/upgrades/FETH\_R18.sol206b34e1ebdf9cd0786afdc45d0cfcf620f9f13e legacy/contracts/upgrades/GlobalPool\_R42.sola04393756d6dad654c501bb14c07876312fd4568 legacy/contracts/FeeRecipient.sol11b399f4e60fb8f7d197cb081c441653fdeb000f 23 --- # Unknown Ankrbas SmartContractSecurityAudit V1.3 No.202204261400 Apr26 th ,2022 CrossYield-StakeSecurityAudit Contents Summaryofauditresults...................................................................................................................................1 1Overview...........................................................................................................................................................2 1.1ProjectOverview....................................................................................................................................2 1.2AuditOverview......................................................................................................................................2 2Findings............................................................................................................................................................3 \[Ankrbas-1\]Avalidatorcanvotemultipletimes........................................................................................4 \[Ankrbas-2\]Poorlydesignedctorfunction.................................................................................................5 \[Ankrbas-3\]Userfundswillnotbeavailableforwithdrawal.....................................................................6 \[Ankrbas-4\]The\_slashValidatorfunctionisnotrigorouslyjudged..........................................................8 \[Ankrbas-5\]Poorlydesignedundelegatefunction......................................................................................9 \[Ankrbas-6\]Poorlydesigned\_delegateTofunction..................................................................................10 \[Ankrbas-7\]Missingevents.......................................................................................................................11 \[Ankrbas-8\]Poorlydesignedclaimfunction.............................................................................................12 3Appendix.........................................................................................................................................................13 3.1VulnerabilityAssessmentMetricsandStatusinSmartContracts.......................................................13 3.2AuditCategories...................................................................................................................................15 3.3Disclaimer.............................................................................................................................................17 3.4AboutBEOSIN.....................................................................................................................................18 AnkrbasSecurityAudit 1 Summaryofauditresults Afterauditing,1Critical-risk,1High-risk,1Medium-riskand5InfoitemswereidentifiedintheAnkr basproject.SpecificauditdetailswillbepresentedintheFindingssection.Usersshouldpayattentiontothe followingaspectswheninteractingwiththisproject： \* Notes：  RiskDescription: 1.Ifcontractusethelatestopenzeppelin-contracts,theremaybepreviousproblems.BecausetheGovernor inthelatestopenzeppelin-contractscontracthasaddeda\_castVote,itwillcausethevotetostillbe manipulated.Pleasemakesuretousethecorrectopenzeppelinversion.  ProjectDescription: 1.Businessoverview TheStakingcontractimplementstheValidatorregistrationfunctionandtheuserstakefunction.Anyone canregisterasaValidatorbypledgingthecorrespondingfundsthroughtheStakingcontract,andafter registration,theValidatorcanonlybecomeaValidatoriftheGovernancecontractisvotedon.The GovernancecontractcanbeinitiatedbytheValidatoraddressandmusthavemorethantwo-thirdsofthe votesbeforetheproposalcansucceed;theRuntimeUpgradecontractisusedtoupgradethesystem contract. AnkrbasSecurityAudit 2 1Overview 1.1ProjectOverview ProjectNameAnkrbas PlatformAnkrChain Githubhttps://github.com/Ankr-network/bas-genesis-config Commit c40a8d82bf48f5365ca3296be598c28886f18b64(first) a26f9e10ba6149947d20d64d7608b4d3750ee968(latest) FileHash (SHA256) Staking.sol 466e8bf3e88fb7f828bb89fb2b7c21c4e4ca6d042215a8daa1dffab0e51 2a6c8(Unfixed) ad2fdf8565190b1b9972fe91fa6fa4e044c7f783a5b0423381663f6330d 20f83(Fixed) StakingPool.sol 1eca905566e42760e6cedcb0e0d9d6ad35e94b3f1d5dd8a857afe1c1 4cef70bd Injector.sol 37a7d2351fa0e9e42907231de3a54651be952c045c45562e846eb1b 2787902bf RuntimeUpgrade.sol 5b9e85557561c1895c55b1a1b60d8b15112b1fe9864ff18c7d9db5c 0dab2050f Governance.sol 5c76fc9e0b25d805bc0045a3ecbde8da89b577a243886d99f35a4c86 37b3e234(Unfixed) 2caf68fedf5e6ead15f496a8d06dc5c63f003e7bcb8672dd497c55745 550e497(Fixed) 1.2AuditOverview Auditworkduration:April13,2022–April21,2022 Updatereporttime:April26,2022 Auditmethods:FormalVerification,StaticAnalysis,TypicalCaseTestingandManualReview. Auditteam:BeosinTechnologyCo.Ltd. AnkrbasSecurityAudit 3 2Findings IndexRiskdescriptionSeveritylevelStatus Ankrbas-1AvalidatorcanvotemultipletimesCriticalFixed Ankrbas-2PoorlydesignedctorfunctionHighFixed Ankrbas-3UserfundswillnotbeavailableforwithdrawalLowFixed Ankrbas-4The\_slashValidatorfunctionisnotrigorouslyjudgedInfoPartiallyFixed Ankrbas-5PoorlydesignedundelegatefunctionInfoFixed Ankrbas-6Poorlydesigned\_delegateTofunctionInfoAcknowledged Ankrbas-7MissingeventsInfoFixed Ankrbas-8PoorlydesignedclaimfunctionInfoFixed RiskDetailsDescription: 1.Ankrbas-4isnotfullyfixedbutdoesnotcausesecurityissues. 2.Ankrbas-6isnotfixedbutdoesnotcausesecurityissues. AnkrbasSecurityAudit 4 \[Ankrbas-1\]Avalidatorcanvotemultipletimes SeverityLevelCritical TypeBusinessSecurity LinesGovernance.sol# Description IntheGovernancecontract,onlytheValidatorOwneraddresscanvote,butinthe Stakingcontract,theValidatorOwneraddresscanbemodifiedthroughthe changeValidatorOwnerfunction,andthenyoucanstillvote. RecommendationsItisrecommendedtousevalidatortocountthevotes. Status Fixed. Figure1Sourcecodeof\_castVotefunction(Fixed) AnkrbasSecurityAudit 5 \[Ankrbas-2\]Poorlydesignedctorfunction SeverityLevelHigh TypeBusinessSecurity LinesStaking.sol#L122 Description ThectorfunctioninthestakingcontractshouldnotspecifyinitialStakes,becausethis functiondoesnottransferthecorrespondingfunds.Ifthevalidatorhasotherusers participatinginthestake,itwillcausethevalidatortowithdrawthestakefundsof otherusers. Figure2Sourcecodeofctorfunction(Unfixed) Figure3Sourcecodeof\_addValidatorfunction RecommendationsItisrecommendedtosetinitialStakestozero. Status Fixed. Figure4Sourcecodeofctorfunction(Fixed) AnkrbasSecurityAudit 6 \[Ankrbas-3\]Userfundswillnotbeavailableforwithdrawal SeverityLevelLow TypeBusinessSecurity LinesStaking.sol#L313,535-544 Description Afterthevalidatorisdeletedthroughgovernance,ifthevalidatorhasstakefunds,the userwillnotbeabletowithdrawthefundsstakedonthevalidator. Figure5Sourcecodeof\_removeValidatorfunction Figure6Sourcecodeof\_undelegateFromfunction(Unfixed) RecommendationsItisrecommendedtoremovethevalidatorafterthefundsinthevalidatorhavebeen withdrawn. AnkrbasSecurityAudit 7 Status Fixed. Figure7Sourcecodeof\_undelegateFromfunction(Fixed) AnkrbasSecurityAudit 8 \[Ankrbas-4\]The\_slashValidatorfunctionisnotrigorouslyjudged SeverityLevelInfo TypeBusinessSecurity LinesStaking.sol#L741,743 Description Inthe\_slashValidatorfunction,"validator.status!=ValidatorStatus.NotFound"isjudged, because"makesurevalidatorwasactive"isalsowritteninthecomment.Sothefunctionhere shouldjudgevalidator.status==ValidatorStatus.Active. Figure8Sourcecodeof\_slashValidatorfunction(Unfixed) RecommendationsItisrecommendedtodeterminethestatusofthevalidatorasactive. Status PartiallyFixed.Projectpartydescription:Validatorcanbeslashedevenifthisvalidatoris alreadyinjailbecauseepochmightbestillactivewherethisvalidatorisintheactivevalidator set.They’vechangedthemisleadingcommentforthisline. Figure9Sourcecodeof\_slashValidatorfunction(PartiallyFixed) AnkrbasSecurityAudit 9 \[Ankrbas-5\]Poorlydesignedundelegatefunction SeverityLevelInfo TypeBusinessSecurity LinesStaking.sol#L216 Description Intheundelegatefunction,thereisnooperationonmsg.value. Figure10Sourcecodeofundelegatefunction(Unfixed) RecommendationsItisrecommendedtodeletethepayable. Status Fixed. Figure11Sourcecodeofundelegatefunction(Fixed) AnkrbasSecurityAudit 10 \[Ankrbas-6\]Poorlydesigned\_delegateTofunction SeverityLevelInfo TypeBusinessSecurity LinesStaking.sol#L277 Description Inthe\_delegateTofunctionofStakingPool,itisjudgedas"validator.status!= ValidatorStatus.NotFound",whichmeansthatwhenthevalidator'sstatusisPending orJail,userscanalsostake. Figure12SourcecodeofpreMintfunction(Unfixed) RecommendationsItisrecommendedthatwhenthestateoftheValidatorisactivebeforeitcanbe staked. Status Acknowledged.Projectpartydescription:Theycan’tlimitvalidatorsfrombeingelectedeven iftheyareinjailornotactive.Stakerswhodelegatemoneytojailedorinactivevalidatorswill bepunishedbecausetheywon’tgainanyrewardsforit.Butthevalidatorownermightwantto increasethetotalstakedamountforhisvalidatorjusttoincreaseitspositionintheactive validatorlistandbepreparedforvalidatingblocksrightafterthejailperiodends. AnkrbasSecurityAudit 11 \[Ankrbas-7\]Missingevents SeverityLevelInfo TypeBusinessSecurity LinesStaking.sol#L551-569 Description The\_disableValidatorand\_activateValidatorfunctionsintheStakingcontractlack thecorrespondingeventtriggers, Figure13Sourcecodeof\_disableValidator&\_activateValidatorfunctions(Unfixed) RecommendationsItisrecommendedtoaddtheireventtriggers. Status Fixed. Figure14Sourcecodeof\_disableValidator&\_activateValidatorfunctions(Fixed) AnkrbasSecurityAudit 12 \[Ankrbas-8\]Poorlydesignedclaimfunction SeverityLevelInfo TypeBusinessSecurity LinesStakingPool.sol#L166 Description Whentheuserdoesnotcancelthestake,thependingUnstake.epochatthistimeis equaltozero,thentheuseofgreaterthanorequaltozerohereisconstant. Figure15Sourcecodeofclaimfunction(Unfixed) RecommendationsItisrecommendedtomodifyittobegreaterthanzero. Status Fixed. Figure16Sourcecodeofclaimfunction(Fixed) AnkrbasSecurityAudit 13 3Appendix 3.1VulnerabilityAssessmentMetricsandStatusinSmartContracts 3.1.1Metrics Inordertoobjectivelyassesstheseveritylevelofvulnerabilitiesinblockchainsystems,thisreport providesdetailedassessmentmetricsforsecurityvulnerabilitiesinsmartcontractswithreferenceto CVSS3.1(CommonVulnerabilityScoringSystemVer3.1). Accordingtotheseveritylevelofvulnerability,thevulnerabilitiesareclassifiedintofourlevels: "critical","high","medium"and"low".Itmainlyreliesonthedegreeofimpactandlikelihoodof exploitationofthevulnerability,supplementedbyothercomprehensivefactorstodetermineofthe severitylevel. Impact Likelihood SevereHighMediumLow ProbableCriticalHighMediumLow PossibleHighHighMediumLow UnlikelyMediumMediumLowInfo RareLowLowInfoInfo 3.1.2Degreeofimpact Severe Severeimpactgenerallyreferstothevulnerabilitycanhaveaseriousimpactontheconfidentiality, integrity,availabilityofsmartcontractsortheireconomicmodel,whichcancausesubstantial economiclossestothecontractbusinesssystem,large-scaledatadisruption,lossofauthority management,failureofkeyfunctions,lossofcredibility,orindirectlyaffecttheoperationofother smartcontractsassociatedwithitandcausesubstantiallosses,aswellasothersevereandmostly irreversibleharm.  High Highimpactgenerallyreferstothevulnerabilitycanhavearelativelyseriousimpactonthe confidentiality,integrity,availabilityofthesmartcontractoritseconomicmodel,whichcancausea greatereconomicloss,localfunctionalunavailability,lossofcredibilityandotherimpacttothe contractbusinesssystem. AnkrbasSecurityAudit 14 Medium Mediumimpactgenerallyreferstothevulnerabilitycanhavearelativelyminorimpactonthe confidentiality,integrity,availabilityofthesmartcontractoritseconomicmodel,whichcancausea smallamountofeconomiclosstothecontractbusinesssystem,individualbusinessunavailability andotherimpact. Low Lowimpactgenerallyreferstothevulnerabilitycanhaveaminorimpactonthesmartcontract, whichcanposecertainsecuritythreattothecontractbusinesssystemandneedstobeimproved. 3.1.4LikelihoodofExploitation Probable Probablelikelihoodgenerallymeansthatthecostrequiredtoexploitthevulnerabilityislow,withno specialexploitationthreshold,andthevulnerabilitycanbetriggeredconsistently. Possible Possiblelikelihoodgenerallymeansthatexploitingsuchvulnerabilityrequiresacertaincost,orthere arecertainconditionsforexploitation,andthevulnerabilityisnoteasilyandconsistentlytriggered.  Unlikely Unlikelylikelihoodgenerallymeansthatthevulnerabilityrequiresahighcost,ortheexploitation conditionsareverydemandingandthevulnerabilityishighlydifficulttotrigger. Rare Rarelikelihoodgenerallymeansthatthevulnerabilityrequiresanextremelyhighcostorthe conditionsforexploitationareextremelydifficulttoachieve. 3.1.5FixResultsStatus StatusDescription FixedTheprojectpartyfullyfixesavulnerability. PartiallyFixedTheprojectpartydidnotfullyfixtheissue,butonlymitigatedtheissue. AcknowledgedTheprojectpartyconfirmsandchoosestoignoretheissue. AnkrbasSecurityAudit 15 3.2AuditCategories No.CategoriesSubitems 1CodingConventions CompilerVersionSecurity DeprecatedItems RedundantCode require/assertUsage GasConsumption 2GeneralVulnerability IntegerOverflow/Underflow Reentrancy Pseudo-randomNumberGenerator(PRNG) Transaction-OrderingDependence DoS(DenialofService) FunctionCallPermissions call/delegatecallSecurity ReturnedValueSecurity tx.originUsage ReplayAttack OverridingVariables Third-partyprotocolinterfaceconsistency 3BusinessSecurity BusinessLogics BusinessImplementations Manipulabletokenprice Centralizedassetcontrol Assettradability Arbitrageattack Beosinclassifiedthesecurityissuesofsmartcontractsintothreecategories:CodingConventions,General Vulnerability,BusinessSecurity.Theirspecificdefinitionsareasfollows: CodingConventions Auditwhethersmartcontractsfollowrecommendedlanguagesecuritycodingpractices.Forexample, smartcontractsdevelopedinSoliditylanguageshouldfixthecompilerversionanddonotuse deprecatedkeywords.  GeneralVulnerability AnkrbasSecurityAudit 16 GeneralVulnerabilityincludesomecommonvulnerabilitiesthatmayappearinsmartcontract projects.Thesevulnerabilitiesaremainlyrelatedtothecharacteristicsofthesmartcontractitself, suchasintegeroverflow/underflowanddenialofserviceattacks. BusinessSecurity Businesssecurityismainlyrelatedtosomeissuesrelatedtothebusinessrealizedbyeachproject, andhasarelativelystrongpertinence.Forexample,whetherthelock-upplaninthecodematchthe whitepaper,ortheflashloanattackcausedbytheincorrectsettingofthepriceacquisitionoracle. \* Notethattheprojectmaysufferstakelossesduetotheintegratedthird-partyprotocol.ThisisnotsomethingBeosincancontrol. Businesssecurityrequirestheparticipationoftheprojectparty.Theprojectpartyandusersneedtostayvigilantatalltimes. AnkrbasSecurityAudit 17 3.3Disclaimer TheAuditReportissuedbyBeosinisrelatedtotheservicesagreedintherelevantserviceagreement.The ProjectPartyortheServedParty(hereinafterreferredtoasthe"ServedParty")canonlybeusedwithinthe conditionsandscopeagreedintheserviceagreement.Otherthirdpartiesshallnottransmit,disclose,quote, relyonortamperwiththeAuditReportissuedforanypurpose. TheAuditReportissuedbyBeosinismadesolelyforthecode,andanydescription,expressionorwording containedthereinshallnotbeinterpretedasaffirmationorconfirmationoftheproject,norshallanywarranty orguaranteebegivenastotheabsoluteflawlessnessofthecodeanalyzed,thecodeteam,thebusinessmodel orlegalcompliance. TheAuditReportissuedbyBeosinisonlybasedonthecodeprovidedbytheServedPartyandthetechnology currentlyavailabletoBeosin.However,duetothetechnicallimitationsofanyorganization,andintheevent thatthecodeprovidedbytheServedPartyismissinginformation,tamperedwith,deleted,hiddenor subsequentlyaltered,theauditreportmaystillfailtofullyenumeratealltherisks. TheAuditReportissuedbyBeosininnowayprovidesinvestmentadviceonanyproject,norshoulditbe utilizedasinvestmentsuggestionsofanytype.Thisreportrepresentsanextensiveevaluationprocessdesigned tohelpourcustomersimprovecodequalitywhilemitigatingthehighrisksinBlockchain. AnkrbasSecurityAudit 18 3.4AboutBEOSIN AffiliatedtoBEOSINTechnologyPte.Ltd.,BEOSINisthefirstinstitutionintheworldspecializinginthe constructionofblockchainsecurityecosystem.Thecoreteammembersareallprofessors,postdocs,PhDs,and Internetelitesfromworld-renownedacademicinstitutions.BEOSINhasmorethan20yearsofresearchin formalverificationtechnology,trustedcomputing,mobilesecurityandkernelsecurity,withoverseas experienceinstudyingandcollaboratinginprojectresearchatwell-knownuniversities.Throughthesecurity auditanddefensedeploymentofmorethan2,000smartcontracts,over50publicblockchainsandwallets,and nearly100exchangesworldwide,BEOSINhasaccumulatedrichexperienceinsecurityattackanddefenseof theblockchainfield,andhasdevelopedseveralsecurityproductsspecificallyforblockchain. OfficialWebsite https://www.beosin.com Telegram https://t.me/+dD8Bnqd133RmNWNl Twitter https://twitter.com/Beosin\_com Email Contact@beosin.com --- # Unknown Avalanche SmartContractSecurityAudit V1.0 No.202207121350 Jul12 nd ,2022 Avalanche-StakeSecurityAudit Contents Summaryofauditresults...................................................................................................................................1 1Overview...........................................................................................................................................................3 1.1ProjectOverview....................................................................................................................................3 1.2AuditOverview......................................................................................................................................3 2Findings............................................................................................................................................................4 \[Avalanche-1\]OwnerandOperatorhaveahighpermission.......................................................................5 \[Avalanche-2\]Unusualamountofburnedtokens........................................................................................7 \[Avalanche-3\]Wrongbalanceused.............................................................................................................8 \[Avalanche-4\]DenialofServiceAttackRisk..............................................................................................9 \[Avalanche-5\]Addthesamedatatothearrayrepeatedly..........................................................................11 \[Avalanche-6\]CentralizationRisk.............................................................................................................12 \[Avalanche-7\]Theeventtriggerdoesnotmatchtheactualnumber..........................................................14 3Appendix.........................................................................................................................................................15 3.1VulnerabilityAssessmentMetricsandStatusinSmartContracts.......................................................15 3.2AuditCategories...................................................................................................................................17 3.3Disclaimer.............................................................................................................................................19 3.4AboutBEOSIN.....................................................................................................................................20 AvalancheSecurityAudit 1 Summaryofauditresults Afterauditing,1High-risk,3Medium-risk,2Low-riskand1Infoitemswereidentifiedinthe Avalancheproject.SpecificauditdetailswillbepresentedintheFindingssection.Usersshouldpay attentiontothefollowingaspectswheninteractingwiththisproject: \* Notes:  RiskDescription: 1.Centralizationrisk Theownercansettheoperatoraddress,andboththeownerandoperatoraddressescanmodifykey parametersinthecontract.Forsomeparameters,onlytheownerhasthepermissiontomodify.Theremay besomecentralizationrisk. 2.Riskofinsufficientgas Multipleforloopsareusedinmanyplacesinthecontract.Iftherearetoomanyloops,therelated functioncallsmayfail. 3.Userwithdrawalrisk WhenuserswithdrawstakedtokensfromtheAvalanchePoolcontract,theyfirstneedtoapply,andthen theoperatoraddresswillissuethem.IftheoperatoraddressdoesnotcalltheserveClaimsfunctionor doesnotpassinenoughAVAXtokens,theusermaynotbeabletowithdrawasexpected. AvalancheSecurityAudit 2 ProjectDescription: 1.BasicTokenInformation TokennameAnkrAvalancheRewardBearing Certificate TokensymbolaAVAXc Decimals18 Pre-mint0 TotalsupplyInitialsupplyis0(Mintable,burnable) TokentypeERC-20 Table1aAVAXctokeninfo TokennameAnkrAvalancheRewardEarningBond TokensymbolaAVAXb Decimals18 Pre-mint0 TotalsupplyInitialsupplyis0(Mintable,burnable) TokentypeERC-20 Table2aAVAXbtokeninfo 2.Businessoverview TheAvalancheprojectcontainstwotokencontractsandonebusinesscontracts.Inthetokencontract, thenumberofsharesisrecordedinsidethecontract,andwhattheuserqueriesisthenumberofbonds. Sharesandbondsareconvertedaccordingtoacertainratio(theratiocanbearbitrarilymodifiedbythe owneroroperatoraddress).UserscanstakeAVAXtokensintheAvalanchePoolcontracttoobtain aAVAXbtokens,andtheaAVAXbtokensandaAVAXctokensareinterchangeableona1:1ratio.When theuserswithdrawtheAVAXtokensstakedintheAvalanchePoolcontract,theyneedtofirstapplyfor thewithdrawal,andthentheoperatoraddresscallstheserveClaimsfunctiontosendtheAVAXtokensto theuser. AvalancheSecurityAudit 3 1Overview 1.1ProjectOverview ProjectNameAvalanche PlatformAvalancheC-Chain FileHash(SHA256) FutureBondAVAX.sol d079c8a0cb045aae71d5b9838dbc2b60762a0d77676d29 6c5015d1ecd6412a8d(Initial) 01e87a28e0e0cc1d8a24077e9de210a9666a6f6150ab6b5 bd0be99af5268351c(Final) ERC20Bond.sol 9a1cb553d096174761689ac666beaba184e1a90172d913a bdfcf6fd6c8a0d12d AvalanchePool.sol 966992b8581529734edbb5cc69aaca7f399ce0542d070a6 5cefab7512f65cc10(Initial) ca5a28b55f210ed450d5c22f92f8302f0dd17e95624345ac ad2038780da6a5d9(Final) FutureCertAVAX.sol ad6307d62303b12582be56bb4ac46f3a1fbc37a6d54424e 09ee1fd80ac6881a1 1.2AuditOverview Auditworkduration:June6,2022–July12,2022 Auditmethods:FormalVerification,StaticAnalysis,TypicalCaseTestingandManualReview. Auditteam:BeosinTechnologyCo.Ltd. AvalancheSecurityAudit 4 2Findings IndexRiskdescriptionSeveritylevelStatus Avalanche-1OwnerandOperatorhaveahighpermissionHighFixed Avalanche-2UnusualamountofburnedtokensMediumFixed Avalanche-3WrongbalanceusedMediumFixed Avalanche-4DenialofServiceAttackRiskMediumFixed Avalanche-5AddthesamedatatothearrayrepeatedlyLowFixed Avalanche-6CentralizationRiskLowAcknowledged Avalanche-7TheeventtriggerdoesnotmatchtheactualnumberInfoFixed RiskDetailsDescription: 1.Avalanche-6isnotfixedandmaycauseacertaincentralizationrisk. AvalancheSecurityAudit 5 \[Avalanche-1\]OwnerandOperatorhaveahighpermission SeverityLevelHigh TypeBusinessSecurity LinesFutureBondAVAX.sol#L117-125,L132-136,L147-159,L274-287 DescriptionTheOwneraddressintheFutureBondAVAXcontractcancallmintandmintBonds functionstominttokenstoanyaddress,andburn,lockForDelayedBurnand commitDelayedBurnfunctionstodestroyanyaddresstokens.Thereisaproblemthat theownerpermissionistoolarge. Figure1Sourcecodeofrelatedfunctions Figure2Sourcecodeofburnfunction Figure3Sourcecodeofrelatedfunctions AvalancheSecurityAudit 6 Figure4Sourcecodeofrelatedmodifiers(Unfixed) Recommendations Itisrecommendedtoremovetheowner'smintingandburningpermissions. StatusFixed. Figure5Sourcecodeofrelatedmodifiers(Fixed) AvalancheSecurityAudit 7 \[Avalanche-2\]Unusualamountofburnedtokens SeverityLevelMedium TypeBusinessSecurity LinesFutureBondAVAX.sol#L152-159,L270-272 DescriptionIntheFutureBondAVAXcontract,whenthebalanceOffunctionqueriesthenumber oftokensheldbythespecifiedaddress,ratioisusedwhenconvertingsharesto bonds,butinthecommitDelayedBurnfunction,lastConfirmedRatioisusedwhen burningshares.IfratioandlastConfirmedRatioarenotequal,thenumberofbonds queriedbytheuserbeforeandafterthecommitDelayedBurnfunctioniscalledmay change. Figure6SourcecodeofcommitDelayedBurnfunction(Unfixed) Figure7Sourcecodeof\_fAvaxToSharesConfirmedRatiofunction RecommendationsItisrecommendedtoalsouseratiotocalculatethequantitywhenburning. StatusFixed. Figure8SourcecodeofcommitDelayedBurnfunction(Fixed) AvalancheSecurityAudit 8 \[Avalanche-3\]Wrongbalanceused SeverityLevelMedium TypeBusinessSecurity LinesFutureBondAVAX.sol#L209-223 DescriptionIntheFutureBondAVAXcontract,the\_unlockSharesfunctionuses "super.balanceOf(account)"tocalculatethebalance,butthebalanceinthe pendingBurnstateisnotexcluded. Figure9Sourcecodeof\_unlockSharesfunction(Unfixed) RecommendationsItisrecommendedtoexcludethebalanceinthependingBurnstate. StatusFixed. Figure10Sourcecodeof\_unlockSharesfunction(Fixed) AvalancheSecurityAudit 9 \[Avalanche-4\]DenialofServiceAttackRisk SeverityLevelMedium TypeBusinessSecurity LinesAvalanchePool.sol#L230-280 DescriptionIntheAvalanchePoolcontract,whentheserveClaimsfunctioncallswallet.transfer,if thewalletisacontractandrefusestoaccepttheplatformtoken,itmaycauseaDOS attack. Figure11SourcecodeofserveClaimsfunction(Unfixed) RecommendationsItisrecommendedthattheaddresstocall\_claimfunctioncannotbethecontract address. StatusFixed. AvalancheSecurityAudit 10 Figure12SourcecodeofserveClaimsfunction(Fixed) AvalancheSecurityAudit 11 \[Avalanche-5\]Addthesamedatatothearrayrepeatedly SeverityLevelLow TypeBusinessSecurity LinesAvalanchePool.sol#L219-228 DescriptionIntheAvalanchePoolcontract,iftheamountinputbythe\_claimfunctionis0, functioncanrepeatedlypush\_pendingCaimers. Figure13Sourcecodeof\_claimfunction(Unfixed) RecommendationsItisrecommendedtojudgewhetherthenumberisgreaterthan0. StatusFixed. Figure14Sourcecodeof\_claimfunction(Fixed) AvalancheSecurityAudit 12 \[Avalanche-6\]CentralizationRisk SeverityLevelLow TypeBusinessSecurity LinesFutureBondAVAX.sol#L90-102,L55-84 DescriptionTheownerandoperatorintheFutureBondAVAXcontractcancall setNameAndSymbol,updateRatio,updateLastConfirmedRatio,updateBothRatios, updateBothRatiosAndFeeandotherfunctionstomodifysomerelatedparametersof thecontract.TheOwneraddresscanalsocallfunctionssuchaschangeOperator, changeAvalanchePool,changeCrossChainBridge,changeCertToken, changeSwapFeeOperator,updateSwapFeeRatio,repairCollectableFee,and repairRatiostomodifysomecontractparameters.Theremaybesomecentralization risk. Figure15Sourcecodeofrelatedfunctions Figure16Sourcecodeofrelatedfunctions Recommendations Itisrecommendedtousemulti-signaturewallet,DAO,TimeLockcontract, AvalancheSecurityAudit 13 etc.asthecontractowner. StatusAcknowledged. AvalancheSecurityAudit 14 \[Avalanche-7\]Theeventtriggerdoesnotmatchtheactualnumber SeverityLevelInfo TypeCodingConventions LinesFutureBondAVAX.sol#L161-165,L231-251 DescriptionThenumberoftokensineventssuchastokentransferandauthorizationinthe FutureBondAVAXcontractisshare,butwhattheuserqueriedisbonds. Figure17Sourcecodeoftransferfunction Figure18Sourcecodeoftransferfunction(Unfixed) Recommendations Itisrecommendedtomodifythenumberoftokensintherelevanteventto bonds. StatusFixed. Figure19Sourcecodeoftransferfunction(Fixed) AvalancheSecurityAudit 15 3Appendix 3.1VulnerabilityAssessmentMetricsandStatusinSmartContracts 3.1.1Metrics Inordertoobjectivelyassesstheseveritylevelofvulnerabilitiesinblockchainsystems,thisreport providesdetailedassessmentmetricsforsecurityvulnerabilitiesinsmartcontractswithreferenceto CVSS3.1(CommonVulnerabilityScoringSystemVer3.1). Accordingtotheseveritylevelofvulnerability,thevulnerabilitiesareclassifiedintofourlevels: "critical","high","medium"and"low".Itmainlyreliesonthedegreeofimpactandlikelihoodof exploitationofthevulnerability,supplementedbyothercomprehensivefactorstodetermineofthe severitylevel. Impact Likelihood SevereHighMediumLow ProbableCriticalHighMediumLow PossibleHighHighMediumLow UnlikelyMediumMediumLowInfo RareLowLowInfoInfo 3.1.2Degreeofimpact Severe Severeimpactgenerallyreferstothevulnerabilitycanhaveaseriousimpactontheconfidentiality, integrity,availabilityofsmartcontractsortheireconomicmodel,whichcancausesubstantial economiclossestothecontractbusinesssystem,large-scaledatadisruption,lossofauthority management,failureofkeyfunctions,lossofcredibility,orindirectlyaffecttheoperationofother smartcontractsassociatedwithitandcausesubstantiallosses,aswellasothersevereandmostly irreversibleharm.  High Highimpactgenerallyreferstothevulnerabilitycanhavearelativelyseriousimpactonthe confidentiality,integrity,availabilityofthesmartcontractoritseconomicmodel,whichcancausea greatereconomicloss,localfunctionalunavailability,lossofcredibilityandotherimpacttothe contractbusinesssystem. AvalancheSecurityAudit 16 Medium Mediumimpactgenerallyreferstothevulnerabilitycanhavearelativelyminorimpactonthe confidentiality,integrity,availabilityofthesmartcontractoritseconomicmodel,whichcancausea smallamountofeconomiclosstothecontractbusinesssystem,individualbusinessunavailability andotherimpact. Low Lowimpactgenerallyreferstothevulnerabilitycanhaveaminorimpactonthesmartcontract, whichcanposecertainsecuritythreattothecontractbusinesssystemandneedstobeimproved. 3.1.4LikelihoodofExploitation Probable Probablelikelihoodgenerallymeansthatthecostrequiredtoexploitthevulnerabilityislow,withno specialexploitationthreshold,andthevulnerabilitycanbetriggeredconsistently. Possible Possiblelikelihoodgenerallymeansthatexploitingsuchvulnerabilityrequiresacertaincost,orthere arecertainconditionsforexploitation,andthevulnerabilityisnoteasilyandconsistentlytriggered.  Unlikely Unlikelylikelihoodgenerallymeansthatthevulnerabilityrequiresahighcost,ortheexploitation conditionsareverydemandingandthevulnerabilityishighlydifficulttotrigger. Rare Rarelikelihoodgenerallymeansthatthevulnerabilityrequiresanextremelyhighcostorthe conditionsforexploitationareextremelydifficulttoachieve. 3.1.5FixResultsStatus StatusDescription FixedTheprojectpartyfullyfixesavulnerability. PartiallyFixedTheprojectpartydidnotfullyfixtheissue,butonlymitigatedtheissue. AcknowledgedTheprojectpartyconfirmsandchoosestoignoretheissue. AvalancheSecurityAudit 17 3.2AuditCategories No.CategoriesSubitems 1CodingConventions CompilerVersionSecurity DeprecatedItems RedundantCode require/assertUsage GasConsumption 2GeneralVulnerability IntegerOverflow/Underflow Reentrancy Pseudo-randomNumberGenerator(PRNG) Transaction-OrderingDependence DoS(DenialofService) FunctionCallPermissions call/delegatecallSecurity ReturnedValueSecurity tx.originUsage ReplayAttack OverridingVariables Third-partyProtocolInterfaceConsistency 3BusinessSecurity BusinessLogics BusinessImplementations ManipulableTokenPrice CentralizedAssetControl AssetTradability ArbitrageAttack Beosinclassifiedthesecurityissuesofsmartcontractsintothreecategories:CodingConventions,General Vulnerability,BusinessSecurity.Theirspecificdefinitionsareasfollows: CodingConventions Auditwhethersmartcontractsfollowrecommendedlanguagesecuritycodingpractices.Forexample, smartcontractsdevelopedinSoliditylanguageshouldfixthecompilerversionanddonotuse deprecatedkeywords.  GeneralVulnerability AvalancheSecurityAudit 18 GeneralVulnerabilityincludesomecommonvulnerabilitiesthatmayappearinsmartcontract projects.Thesevulnerabilitiesaremainlyrelatedtothecharacteristicsofthesmartcontractitself, suchasintegeroverflow/underflowanddenialofserviceattacks. BusinessSecurity Businesssecurityismainlyrelatedtosomeissuesrelatedtothebusinessrealizedbyeachproject, andhasarelativelystrongpertinence.Forexample,whetherthelock-upplaninthecodematchthe whitepaper,ortheflashloanattackcausedbytheincorrectsettingofthepriceacquisitionoracle. \* Notethattheprojectmaysufferstakelossesduetotheintegratedthird-partyprotocol.ThisisnotsomethingBeosincancontrol. Businesssecurityrequirestheparticipationoftheprojectparty.Theprojectpartyandusersneedtostayvigilantatalltimes. AvalancheSecurityAudit 19 3.3Disclaimer TheAuditReportissuedbyBeosinisrelatedtotheservicesagreedintherelevantserviceagreement.The ProjectPartyortheServedParty(hereinafterreferredtoasthe"ServedParty")canonlybeusedwithinthe conditionsandscopeagreedintheserviceagreement.Otherthirdpartiesshallnottransmit,disclose,quote, relyonortamperwiththeAuditReportissuedforanypurpose. TheAuditReportissuedbyBeosinismadesolelyforthecode,andanydescription,expressionorwording containedthereinshallnotbeinterpretedasaffirmationorconfirmationoftheproject,norshallanywarranty orguaranteebegivenastotheabsoluteflawlessnessofthecodeanalyzed,thecodeteam,thebusinessmodel orlegalcompliance. TheAuditReportissuedbyBeosinisonlybasedonthecodeprovidedbytheServedPartyandthetechnology currentlyavailabletoBeosin.However,duetothetechnicallimitationsofanyorganization,andintheevent thatthecodeprovidedbytheServedPartyismissinginformation,tamperedwith,deleted,hiddenor subsequentlyaltered,theauditreportmaystillfailtofullyenumeratealltherisks. TheAuditReportissuedbyBeosininnowayprovidesinvestmentadviceonanyproject,norshoulditbe utilizedasinvestmentsuggestionsofanytype.Thisreportrepresentsanextensiveevaluationprocessdesigned tohelpourcustomersimprovecodequalitywhilemitigatingthehighrisksinBlockchain. AvalancheSecurityAudit 20 3.4AboutBEOSIN AffiliatedtoBEOSINTechnologyPte.Ltd.,BEOSINisthefirstinstitutionintheworldspecializinginthe constructionofblockchainsecurityecosystem.Thecoreteammembersareallprofessors,postdocs,PhDs,and Internetelitesfromworld-renownedacademicinstitutions.BEOSINhasmorethan20yearsofresearchin formalverificationtechnology,trustedcomputing,mobilesecurityandkernelsecurity,withoverseas experienceinstudyingandcollaboratinginprojectresearchatwell-knownuniversities.Throughthesecurity auditanddefensedeploymentofmorethan2,000smartcontracts,over50publicblockchainsandwallets,and nearly100exchangesworldwide,BEOSINhasaccumulatedrichexperienceinsecurityattackanddefenseof theblockchainfield,andhasdevelopedseveralsecurityproductsspecificallyforblockchain. OfficialWebsite https://www.beosin.com Telegram https://t.me/+dD8Bnqd133RmNWNl Twitter https://twitter.com/Beosin\_com Email Contact@beosin.com --- # Unknown Ankr 2.0: A Decentralized Node Marketplace ankr.com July 8, 2022 Ankr 2.0: Introduction Table of Contents About Ankr The Ankr Story 7B 345 39K 27 30+ Our Focus Ankr Network: Connecting Devs to Nodes Overview Ankr Network Version 1: Fast and Reliable Web3 Infrastructure The first version of Ankr Network was launched in a centralized fashion. It was created to address a crucial need for node infrastructure in the Web3 community. With initially centralized roots, Ankr Network was able to grow quickly, scale its solutions, and develop an eminently useful suite of features. Now, Ankr Network handles over 7.2 billion RPC calls to blockchains daily via endpoints that are geo-distributed all around the world and benefit from efficient load balancing. A majority of are operated by Ankr, but many of them are independently operated by participating node providers — a force for decentralization. By becoming a node provider with Ankr Network, participants are essentially providing their own infrastructure to receive requests from Ankr’s RPC network and earning rewards for doing so. these nodes Ankr Network Version 2: A Decentralized Infrastructure Marketplace The evolution of Ankr Network includes our free, public RPC endpoints that developers have come to know and love, alongside new Premium and Enterprise plans packed with advanced developer tools — all powered by a globally distributed and decentralized network of nodes. In the new Ankr Network, developers pay-as-they-go for access to on- chain data, independent node providers serve blockchain requests to earn ANKR tokens, and stakers contribute ANKR tokens to full nodes to secure the network and share in the rewards. Public RPCs are available to all and free to use on the Ankr Network platform. Today, blockchain developers and projects can use these RPC endpoints to access Polygon, Avalanche, Arbitrum, Solana, Celo, Near, Fantom, Ethereum, and many other blockchain networks with no need to input user info or login credentials. Simply visit to get started using these endpoints. https://www.ankr.com/ protocol/ How It Works: Under the Hood of Ankr Network Users Interact with Ankr Network to create RPC requests There are three RPC consumer tiers on Ankr Network – Community, Premium, and Enterprise. Those using the Community RPCs don’t need to go through any account setup or process. They will simply copy and paste public RPC endpoints into their project code for free access. However, those who wish to access premium features will need to go through the process below: Connect a wallet such as MetaMask Follow prompts to provide public key access to Ankr and sign the login message Signing this message will automatically trigger an account creation with a new premium ID The user will be taken to their new account page, where they must deposit a minimum of 1,000 ANKR The user will then be able to pay as they go for every RPC request method out of their API credits Smart Contracts Consensus Mechanism Cryptography When the consensus mechanism issues a JWT token, the user receives that token encrypted. So, even if a potential bad actor oversaw the transaction, knew the address, public key, and so on, it wouldn’t benefit them. To decrypt a JWT token and use it (send it to the load balancer), a person would need to calculate a super- complex cryptographic task similar to hacking the Ethereum blockchain. In other words, somehow pick a private key that correlates with a public key and address. Currently, it is assumed that such a task can’t be solved. Only authenticated users are allowed to view their sensitive data stored on the backend, such as current account balance, transaction history, and so on. Therefore, the protocol will need to confirm that the user has the right to receive information with their address. So, if they want to be able to view their information, they will need to sign a line with their private key from the corresponding address. Once the protocol receives the signature, it is able to find the address on file and ensure it matches the one that is provided. In any instance where the addresses do not match, it will not permit access. When a user signs up, the protocol needs access to the user's public key (via MetaMask). The protocol then gives the public key to the consensus mechanism so it can know the address where encrypted JWT tokens will be assigned. The protocol will interact with MetaMask to decrypt a JWT token issued to the address by the consensus mechanism. To prove to the protocol’s backend that the user indeed owns a private key from a particular address. RPC request traffic is assigned through the load balancer After all security and cryptography measures are satisfied, users are free to make RPC requests to the protocol. When they create new requests, they are not sent to nodes at random. All requests are first sent to the load balancer that acts like a router to ensure traffic is sent to the best-suited nodes for the job. Ankr RPC Load Balancer RPC Nodes FailedFailed Succeed A Scoring Algorithm Determines the Best Possible Node Connection Failover Ensures Requests Are Served Rapidly Traffic Served With Maximum Performance The load balancer routes requests to a hybrid infrastructure of cloud and bare-metal servers with nodes running on more chains than any other web3 infrastructure provider. This combination provides a unique combination of benefits that give the very best of speed, reliability, redundancy, and decentralization. Ankr’s nodes are spread across independent data centers worldwide. Ankr has been installing bare metal servers for years in 30 of the various cloud regions in North America, South America, Europe, the Middle East, Asia, Oceania, and Africa. Bare metal servers provide impressive performance and avoid many drawbacks of AWS and cloud providers, such as geofencing and concentrated outages. In addition to Ankr-run nodes, our independent node providers serve traffic from data centers around the world and make Ankr Network more decentralized – a service much more in line with the original principles and purpose of blockchain tech. DeFi Protocols Web3 Projects Metaverse Games Polygon Binance Optimism Aave SpiritSwap Avalanche Load Balancer Cloud Nodes Bare Metal Nodes Archive & RPC Nodes From Ankr and Independent providers RPC Traffic ServedRPC Traffic Served RPC Request s Ankr Users Distributed RPC Endpoints Provide High Performance Archive Nodes - Store an entire copy of the blockchain from the genesis block Full Nodes - Hold the complete current state of the blockchain Light Nodes - Only store block headers and reference full nodes to seek complete data We are seeking to add as many archive nodes as possible to Ankr Network as they have the most capabilities. However, this comes with additional requirements for hardware as the archive nodes are expected to meet higher specifications.Archive nodes are crucial for receiving historical data, but not all the requests coming to blockchains necessitate archive data retrieval. Most users are interested in the state of a current block, sending transactions, or finding out if a transaction has been validated. In some cases, full nodes and light nodes are more than adequate enough to serve certain types of requests, so we also deploy those in appropriate amounts. We know the request percentages for all node types, and use this information to estimate how many nodes we will need at any given time and what type. Caching Provides Efficient Access To Data Distributed Infrastructure Improves Blockchain APIs and RPCs Ankr Network’s Developer Features Free, Community RPC Endpoints for All Having public Community RPCs serves a critical purpose: it powers Web3 applications like MetaMask and other free, open-source software to connect with information on different blockchains. With easy access to free RPC endpoints, developers and projects can interact with blockchain data and execute tasks like crypto wallet transactions. It also allows developers to build dApps freely on their own terms. Ankr currently operates to the most popular blockchain networks for Web3 development. Combined with other endpoints, these RPCs are serving over 7.2 billion requests to blockchains daily, a number that is only expected to grow every week. We’ve been working around the clock to expand our public RPC services to meet this ever-increasing demand. As the Ankr Network welcomes a nearly infinite supply of community node providers, our public RPC service will provide a free gateway for 17 free, public RPCs developers to interface with the blockchain and build the future of Web3. Premium and Enterprise Features Community RPCs Unlimited requests Global node distribution Exclusive endpoints Prioritized requests Access to blockchain analytics Advanced Developer APIs WebSockets (WS) capabilities Arbitum Solana Avalanche Tron BSC Celo Optimism Fantom Ethereum Gnosis Harmony Polygon Syscoin Solana Nervos Near IoTeX Moonbeam Join the Largest Network of RPC Partners Advanced Developer APIs Reduce the number of requests you need to make Reduce the amount of time you spend making requests Save time and money by querying multiple chains at once Query API Token API NFT API The ANKR Token ANKR Token Utility on Ankr Network Pay for Ankr Network Premium Plans under a pay-as-you- go model Pay collateral deposits (self stake) required to become a node provider on Ankr Network Reward node providers for serving network traffic Reward ANKR token stakers for helping to secure Ankr Network Provide a means of payment for independent node auditors Vote on proposals in the Ankr DAO DeFi Protocols Web3 Projects Metaverse Games ANKR Token Holders Decentralized network of node providers Serving Traffic Stake ANKR Earn ANKR rewards Deposit ANKR Data request s & ANKR rewards Serving Traffic Blockchain data request s & ANKR Ankr Network User Fees Ankr Network users with Premium Plans will pay for every request they make to blockchains in our new pay-as-you-go model that ensures developers won’t overpay for annual subscriptions. The cost of an individual request averages to about $0.00004 USD, with certain types of requests costing more or less based on their respective resource requirements. In turn, these fees are used to incentivize independent node operators and are redistributed amongst node providers and stakers. Anyone can see the current cost of RPC requests by viewing the in our docs. This pricing is drastically cheaper than popular centralized node infrastructure providers like Infura and Alchemy. And when paying Ankr Network fees with ANKR tokens, users will receive an additional discounted rate. Certain Advanced API features may only be accessible to those who use the ANKR token for access. Ultimately, the Ankr DAO will decide the future price of Ankr Network Premium services based on the price of the ANKR token at the time pricing data Node Provider Collateral Deposits Node Provider Rewards 21% goes to the self- stake pool (node provider) 49% goes to the staking insurance pool (individual stakers) Staking ANKR to Independent Node Providers Node Auditing Mechanisms Ankr DAO Voting Ankr DAO Governing Web3 Infrastructure Ankr Grants Funding for Web3's Future Ankr has launched to more heavily reward builders who create value for Ankr DAO and further bolster the growth of Ankr becoming the de facto infrastructure for Web3. Distributed over two years, the grant will be used to fund multiple tiers of development that appeal to a wide range of Web3 users, including: a grant program valued at $10 million USD in ANKR tokens Smart contracts developers Authors of in-depth developer tutorials and educational materials Independent node operators wanting to join Ankr Network Small projects that need access to Ankr’s advanced protocol features Other Offerings Technical Solutions for Partners and Open Source Public Goods Ankr has attracted some of the most talented engineers in the industry that have become integral in helping our ecosystem of contributors and partners solve extremely complex technical problems. Not only does Ankr provide the foundational infrastructure for partners like the BNB Chain, Polygon, Optimism, Avalanche, and Syscoin, we also offer technical assistance that has upgraded the very framework of Proof-of- Stake systems with open-source solutions such as the Erigon performance upgrade for the BSC. Ankr is uniquely positioned to offer technical expertise as our team is already deeply involved in the environments of our supported blockchains. As a core contributor to PoS chains, Ankr has overhauled the underlying node architecture of projects while detecting weaknesses and implementing performance upgrades whenever possible. Together with our partners, Ankr has explored new tech that is leading to the future of Web3. Ankr goes above and beyond for key partners in: Architecting frameworks for bridges, sidechains, testnets, and more Support in engineering, DevRel, DevOps, benchmarking, and development Consulting for Web2 companies entering the space, such as Mastercard Helping projects bootstrap their infrastructure with additional tools like block explorers DeFi project consulting, staking, tokenomics, and more Validator binary + config file (.toml) Load-balanced RPC endpoint White-labeled block explorer Faucet for testnet tokens Direct staking support through a UI Ankr’s “Exchange Readiness” program Ankr App Chains won’t just make it easier to create custom blockchains, it will open the gates for Web3 adoption with an improved user experience. With scalability issues out of the way, devs can focus on providing dApps so streamlined that they will take next to no knowledge to get involved – leading the way for Web3 to finally onboard billions of new users, not millions. Ankr App Chains Web3 Game Development Tools The Web3 gaming SDKs built and deployed by Ankr contributors and ecosystem partners help game studios and developers integrate their games and in-game functionalities with Web3. With Web3 gaming SDKs for both Unity and Unreal, Ankr makes it easy for game developers and game studios to give their games full Web3 capabilities — including integrating cryptocurrencies and non-fungible tokens (NFTs). With these tools, users can save an incredible amount of time with readymade solutions so they can get to market faster. With Ankr’s gaming SDK, developers can easily: Support Web3 wallets for in-game transactions Integrate NFT capabilities like minting, renting, and trading Detect and connect to multiple blockchains Launch and distribute in-game currency as tokens Optimize games for Web3 on mobile Innovative Staking Products Staking secures blockchains by making it prohibitively expensive to attack networks. However, the need to lock up tokens to stake makes staking inefficient. For this reason, Ankr pioneered liquid staking, which is designed to solve capital inefficiency by allowing users to still utilize their assets while they’re being staked. To do so, users who stake their assets with Ankr can mint liquid staking tokens in their place, which represent the originally staked assets plus staking rewards. Liquid staking tokens are immediately liquid and can be traded, sold, or deployed on other DeFi protocols to compound earnings. This greatly reduces the opportunity cost of staking and gives stakers more options, flexibility, and liquidity for their assets. By reducing this opportunity cost, liquid staking has caused an explosion of the Total Value Locked (TVL) in assets staked to Proof-of-Stake blockchains. Ankr aims to be the leading multichain staking-as-a-service provider by delivering a consistent staking experience to users, integrators, applications, and institutions across every major blockchain. While doing so, Ankr will continue to pursue long-term partnerships with key DeFi integrators and applications to drive utility to liquid staking tokens facilitated on the platform. Educational Content and DevRel To Boost Web3 Accessibility We recognize some Ankr solutions may require additional explanations and tutorials so that they are easily digestible and accessible to more users. Ankr is working to produce innovative content via an educational platform that will consist of resources such as documents, tutorials, articles, videos, infographics, and more — all to be launched in multiple phases. We will introduce the community to Ankr’s Web3 products, educate them about the importance of decentralized infrastructure, build awareness of liquid staking features, and provide general insight into development and earning strategies in crypto. We believe an Ankr education platform will help transform our UX, build trust among users, and grow the size of the Ankr community. Market Analysis What Will Happen in the Coming Years? We fully anticipate that the continued growth of Web3 and metaverse adoption will bring to market a wide range of connectivity types, devices, and technologies that will offer more functionality and interoperability than the closed-loop systems and sandboxes that typify the status quo of the current tech stack. With the proliferation of DeFi services, it has become clear that winners of the new internet will emerge from the subset of developers and projects who design and build with a deep understanding of the value of composable infrastructure building blocks. As more bridges are built between blockchains, they will also emerge between the offline and digital worlds. Those connections will spawn new products and experiences augmenting the metaverse, IoT, and AI, which will create new use cases for crypto assets, blockchain systems, and so on. And as the barriers to the global adoption of decentralized blockchain systems recede, so too will the perceived limits on the growth potential of Web3 technologies. Competitive Landscape What sets Ankr apart? Ankr’s service model stands in contrast to centralized node infrastructure providers. Centralized infrastructure providers offer gated services and Web2 business models that go against the principles of decentralization at the heart of Web3. That said, any project that’s in the business of increasing node infrastructure to support the growth of Web3 is, in some sense, striving toward a common goal alongside Ankr. The way we go about facilitating the growth of Web3, however, is what sets Ankr apart. As a decentralized node infrastructure provider that sources nodes from all kinds of independent node operators, Ankr’s success is in part derived from the proliferation of nodes of all kinds. As such, Ankr isn’t in direct competition with other node infrastructure providers. Rather, Ankr Network is a force that takes existing node infrastructure and makes it more resilient, secure, and decentralized. For example, if a DeFi project exclusively uses Alchemy for its node infrastructure, the project’s infrastructure can be made more robust by leveraging Ankr Network’s decentralized node infrastructure in conjunction with its existing nodes for added redundancy, intelligent load balancing, and security in the event of outages with a centralized provider. Pocket Network (POKT) is another project (and Ankr ecosystem partner) that’s building decentralized node infrastructure for Web3. And, once again, their success is not mutually exclusive with Ankr’s. The more decentralized node infrastructure is available to the Web3 industry, the better. That said, Ankr has solidified itself as the world’s fastest-growing decentralized infrastructure provider by request volume, supported ecosystems, and rate of growth. Our performance as a provider is directly responsible for our rapid growth. Ankr has built out precise performance benchmark analytics to track how our RPCs and infrastructure stack up to our competitors, and we consistently work to provide constant improvements to every facet of our service that affects developers: Reliability Low latency Affordability Global distribution Decentralization Team A globally distributed team pushing innovation worldwide. Ankr contributors and ecosystem partners are uniquely equipped to handle the problems that Web3 developers face, armed with years of experience building, scaling, and managing cryptocurrency and Web3 infrastructure companies. We are a team of engineers and creatives with a vast combined experience spanning cloud computing, finance, and blockchain, with a history at the world’s leading companies and organizations like AWS, Microsoft, Goldman Sachs, Google, Yandex, Oracle, Ethereum, BitGo, and more. Conclusion Ankr - Decentralized services powering the (r)evolution Web3 ---