2023-04-06 Audit Report - Neutron SDK DAO Wasmd TGE

Security Audit Report

Neutron: Code Inspection and Protocol Analysis

06.04.2023 Last revised 12.04.2023

Contents Audit overview 3 The Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Scope of this report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Conducted work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Further Increasing Confidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Audit Dashboard 6

System Overview 7 Custom modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Neutron SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Smart contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Interchain Queries Relayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Findings 11 Interchain Queries register and remove logic can be exploited to steal smart contract’s deposit and stop it from creating the queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Non-validated IBC acknowledgement/timeout fees can lead to drainage of relayers funds and spamming of the network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 InitGenesis() execution could cause ICQ-s to be overwritten in the store . . . . . . . . . . . . . . . . . . . 15 Interchain Query keys are not properly validated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Transactions stored for ICQ results of TX type can be removed when the query is removed . . . . . . . . 17 Interchain Query of type TX can not be updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Heights for ICQ results submission are not properly checked . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Consumer governance proposal types whitelisting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 MsgSubmitQueryResult could be optimized to use less gas . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 ValidateBasic() for the MsgRegisterInterchainAccount should validate maximum length of the InterchainAc- countId field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Introduce support for quering the minimum IBC fees from the smart contracts . . . . . . . . . . . . . . . 23 Various minor issues in the Neutron custom modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Various minor issues in the Neutron smart contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Various minor issues in the Neutron SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Various documentation inconsistencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Various minor issues in the Token Generation Event smart contracts . . . . . . . . . . . . . . . . . . . . . 28

Appendix: Vulnerability classification 29

Audit overview The Project In January 2023, P2P staking engaged Informal Systems to conduct a security audit over the documentation and the current state of the implementation of the Neutron project. Neutron is a proof-of-stake blockchain designed as a permissionless smart contracting platform which allows user- deployed smart contracts to easily interact with other Cosmos blockchains by leveraging Neutron’s custom modules and other components. It is based on Tendermint, Cosmos SDK, IBC, CosmWasm and Interchain Security. Neutron blockchain consists of several custom modules: Interchain Queries - allows smart contracts do define a customizable queries to obtain the states from other blockchains. Interchain Transactions - introduces support for smart contracts to register interchain accounts on other blockchains and send transactions by using those accounts. Transfer - a wrapper around IBC Transfer module that allows transfer results to be processed by the smart contracts that initiated the transfer. Contract Manager - handles communication from the Neutron modules to the smart contracts when the results that were requested by the smart contracts have been received on Neutron blockchain. This is done by executing sudo calls on the receiving contracts. It also stores information about any contract failures that occurred in smart contracts during sudo calls execution. Fee Refunder - smart contracts must pay certain fees when they want to execute some transactions or transfer tokens through IBC to other blockchains. These fees are stored on fee refunder module and paid out to the IBC relayers when they deliver the results. Fee Burner - responsible for burning neutron tokens that have been collected through transaction fees. Works in conjunction with a treasury smart contract that will release certain number of tokens from the treasury based on how many tokens were burned by the fee burner module. Neutron deploys three sets of smart contracts that are an integral part of the product. First set is used for the governance of the blockchain, the second one handles the tokenomics by managing the neutron tokens treasury and distribution, and the third one handles the bootstrapping of the Neutron ecosystem. Neutron also has one off-chain component: Interchain Queries Relayer. This component is responsible for tracking the interchain queries on the Neutron chain, executing those queries on destination chains and submitting query results (together with proofs) back to Neutron blockchain.

Scope of this report The agreed-upon workplan consisted of the following tasks:

Audit of the Neutron’s custom modules and application source code.
Audit of the Neutron SDK, a CosmWasm bindings intended to be used by smart contracts to interact with other blockchains through Neutron’s custom modules.
Audit of Neutron DAO set of governance smart contracts, and of tokenomics smart contracts.
Audit of WasmD fork adapted to meet specific needs of the Neutron blockchain.
Audit of Neutron Token Generation Event smart contracts. This report covers the above tasks that were conducted from January 18 through April 6 by Informal Systems by the following personnel: • Dusan Maksimovic • Stana Miric

Conducted work At the kick-off meeting the Neutron team gave us a brief introduction to the Neutron blockchain and Neutron DAO set of governance smart contracts. We agreed upon the exact revisions of each repository that we should audit. The team first read through all the official documentation of the Neutron system overview, custom modules, governance, tokenomics and token generation event smart contracts. After that, the team performed manual code review with a focus mainly on code correctness and the critical points analysis of Neutron’s custom modules, smart contracts and CosmWasm bindings.

Timeline • 18.01.2023: Kick-off meeting with the Neutron team. • 19.01.2023: Sync meeting 1, Andrei and Mikhail did a short code walkthrouh of the Neutron chain modules and partially the governance contracts mechanism. • 26.01.2023: Sync meeting 2, we went through the first findings, one of them was critical (ability for anyone to remove the interchain query immediately, before the first results were submitted, and take the smart contract’s deposit). • 02.02.2023: Sync meeting 3, we went through the new findings in interchaintxs and feerefunder modules and also discussed a potential problem with the way interchainqueries module stores and compares the heights of the submitted results. As a result, a new issue is reported. • 09.02.2023: Sync meeting 4, we discussed the latest finding for whitelisting of the governance proposal types and two other issues that represent a collections of smaller issues in Neutron modules and CosmWasm bindings code, but do not pose a security threat. • 23.02.2023: Sync meeting 5, we started the second part of the audit- the Neutron’s governance and tokenomics smart contracts. No issues have been found so far. • 02.03.2023: Sync meeting 6, we discussed smaller issues found in the governance and treasury smart contracts. • 09.03.2023: Sync meeting 7, we presented the finding with collection of minor issues found in the smart contracts code. • 23.03.2023: Sync meeting 8, start of the third part of the audit- Token Generation Event smart contracts. • 30.03.2023: Sync meeting 9, we presented minor issues found in the Credits, Airdrop and Auction smart contracts. • 06.04.2023: Sync meeting 10, we presented one more minor issue which would stop users from claiming the lockdrop participation rewards. • 07.04.2023: End of audit • 11.04.2023: Submission of first draft of this report • 12.04.2023: Submission of final version of this report

Conclusions We found that the Neutron design and security model in general is well thought out. Despite the general high quality, we found some details that should be addressed to raise the quality of the code. One Critical Severity and one High Severity issues were found during this audit; the rest were marked as Low or Informational severity.

Further Increasing Confidence The scope of this audit was limited to manual code review and manual analysis and reconstruction of the protocols. To further increase confidence in the protocol and the implementation, we recommend following up with more rigorous formal measures, including automated model checking and model-based adversarial testing. Our experience shows that incorporating test suites driven by TLA+ models that can lead the implementation into suspected edge cases and error scenarios enables discovery of issues that are unlikely to be identified through manual review. It is our understanding that the P2P staking team intends to pursue such measures to further improve the confidence in their system.

Disclaimer This report is subject to the terms and conditions (including without limitation, description of services, confidentiality, disclaimer and limitation of liability, etc.) set forth in the associated Services Agreement. This report provided in connection with the Services set forth in the Services Agreement shall be used by the Company only to the extent permitted under the terms and conditions set forth in the Agreement. This audit report is provided on an “as is” basis, with no guarantee of the completeness, accuracy, timeliness or of the results obtained by use of the information provided. Informal has relied upon information and data provided by the client, and is not responsible for any errors or omissions in such information and data or results obtained from the use of that information or conclusions in this report. Informal makes no warranty of any kind, express or implied, regarding the accuracy, adequacy, validity, reliability, availability or completeness of this report. This report should not be considered or utilized as a complete assessment of the overall utility, security or bugfree status of the code. This audit report contains confidential information and is only intended for use by the client. Reuse or republication of the audit report other than as authorized by the client is prohibited. This report is not, nor should it be considered, an “endorsement”, “approval” or “disapproval” of any particular project or team. This report is not, nor should it be considered, an indication of the economics or value of any “product” or “asset” created by any team or project that contracts with Informal to perform a security assessment. This report does not provide any warranty or guarantee regarding the absolute bug-free nature of the technology analyzed, nor does it provide any indication of the client’s business, business model or legal compliance. This report should not be used in any way to make decisions around investment or involvement with any particular project. This report in no way provides investment advice, nor should it be leveraged as investment advice of any sort. Blockchain technology and cryptographic assets in general and by definition present a high level of ongoing risk. Client is responsible for its own due diligence and continuing security in this regard.

Audit Dashboard Target Summary • Type: Specification and Implementation • Platform: Go, Rust • Artifacts – neutron-org/neutron @ 64868908b21f648ad5e8a9b48179134619544e2a – neutron-org/neutron-dao @ 5a0ab5a60f7e1e3d9e532da0be8be3f57c7e16c7 – neutron-org/neutron-sdk @ c19b40c024eeaa8733af9ddee94a52798d78f469 – neutron-org/wasmd @ f37577b9c030221c40823916d47d94e8cd844fe3 – neutron-org/neutron-tge-contracts @ 0da3c1183c18671d601afd12cf80bf20250be62a Engagement Summary • Dates: 18.01.2023 to 07.04.2023 • Method: Manual code review & protocol analysis • Employees Engaged: 2

Severity Summary

Finding Severity # Critical 1 High 1 Medium 0 Low 2 Informational 12 Total 16

Resolution Status Summary

Resolution Status # Resolved 16 Risk-accepted 0 Functioning as Designed 0 Total 16

System Overview In this section, we give a high-level overview of the system, which is useful for understanding the rest of the report. For more details on the system, see the project documentation. Neutron introduces a permissionless smart contracting platform which offers support for any smart contract to easily obtain the values from the state of other Cosmos blockchains, as well as to register interchain accounts and send transactions to other blockchains by using those accounts. It also allows smart contracts to perform IBC transfers and, by using its custom IBC Transfer module, to inform the smart contracts about the outcome of those transfers. To be able to support all of these functionalities, Neutron has created a system which consists of multiple on-chain and off-chain components that are shown in Figure 1.

Figure 1: Neutron system overview

Custom modules Neutron blockchain uses multiple Cosmos SDK modules, as well as the following custom modules:

Consumer module of the Interchain Security, since it will start as a consumer chain

CosmWasm module, which adds support for smart contracts
IBC module, which allows Neutron to communicate with other blockchains
Interchain Accounts module, which allows smart contracts to create accounts on other Cosmos blockchains
Admin module, which allows specified admin addresses to execute governance proposal messages once their proposals have passed It also defines a couple of its own custom modules that are adding support for communication between the smart contracts deployed on the Neutron blockchain and other Cosmos blockchains. Below we present a brief overview of these custom modules. Interchain Queries This module allows smart contracts to create a customizable queries to obtain the desired state from other blockchains. Smart contract manages its interchain queries by using MsgRegisterInterchainQuery, MsgUpdateInterchainQuery and MsgRemoveInterchainQuery messages defined by this module. Currently, there are two types of supported interchain queries: key-value and transaction. Key-value queries allow for querying the state of the store on a destination blockchains by specifying the keys whose values they want to obtain. Transaction queries allow for querying the transactions on destination blockchains that satisfy the specified transaction filter conditions. To create an interchain query, smart contracts must pay the deposit whose amount is specified in the parameters of the module. This is used to protect the Neutron blockchain from a Byzantine smart contracts that could otherwise spam the network and force the blockchain nodes to store the queries which are not used by anyone. Only the smart contract that created the interchain query can remove it from the blockchain. But, if the results for a certain query haven’t been submitted for longer than the submit timeout period of blocks, it becomes free for anyone to submit the MsgRemoveInterchainQuery to remove the obsolete query and claim the deposit that was paid by the smart contract who created it. This is used as an incentive for everyone, which helps with the clean-up of unused interchain queries from the blockchain. The module also defines a MsgSubmitQueryResult message which is used by the Interchain Query Relayer to submit the results of the interchain queries that were obtained from the destination chain. Together with the results, the ICQ Relayer submits the Merkle Proofs which prove that the results actually exist on the destination chain. These proofs are then verified against the IBC light clients stored on the Neutron blockchain. If the verification is successful, smart contract is notified about the results through the sudo calls managed by the Contract Manager module keeper. Additionally, for the interchain queries of key-value type, the results are stored in the interchain queries module store. Interchain Transactions This module allows smart contracts to register interchain accounts on destination blockchains and send transactions to those blockchains by using the created accounts. There is no limitation in number of interchain accounts that one smart contract can register. The module exposes two messages: MsgRegisterInterchainAccount and MsgSubmitTx. Smart contracts that wants to submit transactions to some destination blockchains will send the MsgSubmitTx. When submitting this message, a smart contract must pay acknowledgement and timeout fees that will be locked on the Fee Refunder module account until the results are delivered by the IBC relayer. Transfer This module is a wrapper around the IBC Transfer module, which adds better support for smart contracts to perform IBC token transfers. The main advantage of this module over the standard IBC Transfer module is that it will handle the acknowledgements and timeouts submitted by the IBC relayers and forward them to the smart contracts that initiated the transfer. That way, a smart contract can take proper action to successful or timed out IBC token transfers. Similarly to sending the transactions to destination blockchains through the Interchain Transactions module, smart contract must pay acknowledgement or timeout fees to IBC relayers that deliver the results. Contract Manager This module exposes the API for other Neutron modules to allow them to communicate with smart contracts by leveraging the sudo calls provided by the CosmWasm module. The module is used by Interchain Queries, Interchain Transactions and Transfer modules each time when IBC or ICQ relayers deliver some results to Neutron blockchain. After the results are verified by the modules, they are propagated to the smart contract which initiated transaction submission on destination chain, IBC token transfer, or when the results of interchain query are submitted by the ICQ relayer. It is the responsibility of the smart contract developers to implement corresponding sudo handlers in their smart contracts, which will then be called by the Contract Manager module. If an error occurs during any sudo handler execution in smart contract code, the module will record this

Excerpt (19993 of 59115 characters). Read the whole page on informalsystems/audits ↗

← Back to Documentation