2022-11-30 Audit Report - Stride StakeIBC ICACallbacks

Security Audit Report

Stride StakeIBC and ICACallbacks Modules: Source Code Analysis

2022/11/30 Last revised 2022/12/08

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

System Overview 7 Data flow diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Deposit & Liquid Staking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Staking & Reinvesment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Unbonding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 IBC/ICA function call hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Methodology 12 Vulnerability classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Impact Score . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Exploitability Score . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Severity Score . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Audit Dashboard 15

Findings 16

Unsafe usage of native arithmetic may lead to catastrophic failures 17 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Unbonding is compromised if the overflow value is greater than zero 20 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

One chain redemption out-of-bounds may halt all chains 23 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

IBC/tokens could be lost during IBC transfer to Delegation ICA 26 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Users may not be able to redeem stake 29 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

StakeExistingDepositsOnHostZones could be a bottleneck in case of many host zones 30 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Failure to send IBC packets may lead to user funds freeze 31 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Consider isolating host zone operations 33 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

GetHostZoneUnbondingMsgs need to be refactored 36 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Variable err not assigned but used inside if condition 39 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Error handling should be reviewed 40 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Different conditions for max number of validators to rebalance 42 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Redemption rate limits are hardcoded 44 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Documentation is not updated (including Linux support) 45 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Coding style recommendations 47 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Stride lacks various test cases 49 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Various kinds of observations 50 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Audit overview The Project In October 2022, Stride development team engaged Informal Systems to conduct a security audit over the documen- tation and the current state of the Stride modules named: stakeibc and icacallbacks. Stakeibc module is the main module of Stride blockchain responsible for all of the interchain (un)staking and reinvestment logic as well as for minting & burning derivative assets (stTokens). It owns 4 Interchain Accounts (ICAs) (Delegate, Withdraw, Redemption, and Fee) on each host stride interacts with. It issues all ICA messages like MsgDelegate, MsgUndelegate, MsgBankSend, IBC transfers. Staking yield accrues to stTokens. Rewards are socialized across all depositors. Icacallbacks is an auxiliary model that allows to store callbacks to be called on IBC packet acknowledgements; the stored callbacks constitute the indivisible part of the stakeibc module logic.

Scope of this report The agreed-upon work plan consisted of the following tasks: T ask1. x/stakingibc - edge cases around ICA (whether all edge cases are handled, like packet acks and failures T ask2. x/stakingibc - the situation when transfer to the Delegation account fails T ask3. x/stakingibc - the correctness of the core functions (MsgLiquidStake, MsgRedeemStake, MsgClaimStake) T ask4. x/stakingibc - whether the icacallbacks in stakeibc are executing as expected T ask5. x/icacallbacks - fully audit the module and check for correctness This report covers the above tasks that were conducted from October 12 through November 30 by Informal Systems by the following personnel: • Darko Deuric • Andrey Kuprianov • Marko Juric

Conducted work Starting with October 12, The Informal Systems team audited the existing documentation and the code. On the same date, the Stride development team representative gave us an hour presentation about the Stride multichain dataflow, with IBC/ICA focus and we define the scope of this audit. The additional details including which tag to use (v2.0.3) to perform an audit for were agreed on at this meeting. The team reviewed all the existing specifications and technical diagrams for the x/stakeibc and x/icacallbacks deep dive. Our team performed the high-quality line-by-line manual code review of the two modules previously mentioned with the main focus on IBC/ICA correctness together with the callbacks mechanism used for updating the state on Stride chain on packet acknowledgment. Over the shared Slack channel, we discussed setting the local test environment, how the validators are being updated, and general work done during the online weekly sync meetings.

Timeline • 10/12/2022: kickoff meeting with Stride team (Aidan and Riley talked about general data flow in Stride blockchain) • 10/19/2022: 1st sync meeting (general code observations, first critical finding discussed - panic related to redemption rate limits) • 10/27/2022: 2nd sync meeting (walkthrough findings related to liquid staking, delegation and reinvestment, Linux installation problems presented, Aidan answered a few questions)

• 10/28/2022: collaboration repo created and 1st finding added by Andrey • 11/3/2022: 3rd sync meeting (additional findings and observations reported, mainly about unbonding process) • 11/4/2022: Stride team provided dockernet branch for Linux • 11/9/2022: 4th sync meeting (majority of findings added to collaboration repo, a short discussion about validators) • 11/30/2022: meeting Informal/Stride to gain feedback on the audit report

Conclusions We found that the x/stakeibc and x/icacallbacks modules design and security models in general are well thought out. The amount of existing unit tests and existing development practices are on a very high level although integration tests could be improved because the only integration test that has been written describes the happy-path so an illusion of security that does not really exist in real life can be provided. There are plenty of potential error messages defined inside stakeibc module so at least some of them should be checked with integration tests. Despite the general high quality, we found some details that should be addressed in order to raise the quality of code and existing specification. 1 Critical severity and 4 High Severity issues were found during this audit; the rest were marked Medium, Low or Informational severity. Until this time, one issue was addressed.

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 enable discovery of issues that are unlikely to be identified through manual review. It is our understanding that the Stride team intends to pursue such measures to further improve confidence in their system.

System Overview In Stride, staking occurs every 6 hours and it goes through 3 epochs: • epoch n: New deposit record (DR) which tracks all deposits in a given epoch for a given host zone is created with 0 tokens. LiquidStake is called then and stTokens are minted, but the actual staking of the user’s tokens is addressed in epoch n+2. • epoch n+1: All tokens on DR from epoch n are IBC transferred from Stride’s module account to Delegation ICA. Whenever a change to delegation happens all of the rewards are withdrawn (to Withdraw ICA). • epoch n+2: Tokens on the DR are staked (by weight) across all (30 at the moment) Stride validators. Reinvestment executes automatically and the rewards are auto-compounded on every epoch (6h). 90% of the rewards are being sent to Delegation ICA (reinvestment) and 10% to the Fee ICA (the only place where Stride charges the fees) • epoch n: Queries Interchain Query (ICQ) to check balances of Withdraw ICA and creates a new record for those tokens. • epoch n+1: Transfers tokens to Delegation ICA from the Withdraw ICA. • epoch n+2: Stakes the tokens. Unstaking executes every day. Only 7 concurrent unbondings are allowed (a constraint on Cosmos) on host zones for a delegator and validator pair. • epoch n: EpochUnbondingRecord is created. It stores many HostZoneUnbondings (HZU), with one HZU per host zone (e.g. for CosmosHub we have 1 HZU per epoch). When the user sends 1stAtom to Stride (Stride now custodies this 1 stAtom) and specifies an address on the Cosmos Hub that the tokens should be sent, HZU is updated and UserRedemptionRecord (URR) is created (claim on user’s tokens that they can trigger later once the tokens have unbonded). • epoch n+m (m = unbondingPeriodOnHostZone / 7 + 1): For CosmosHub it happens every 4 days (unbPeriod = 21 days). MsgUndelegate is triggered and all of the pulled unbonding tokens are undelegated (MsgUndelegate ICAs are triggered across the validators Stride has delegated to). HZUs are updated with unbonding time. • epoch n+unbonding time: Tokens are transferred to Redemption ICA account. The URR is updated so that the tokens are claimable and anyone can transfer tokens to the already specified address which is stored on URR. So this is an ICA call that transfers tokens back to the end user’s account.

Figure 1: Epoch unbonding record

Data flow diagrams

Figure 2: Deposit & Liquid Staking

Deposit & Liquid Staking Withdrawal and deposit belong to regular bank transfers (outside of Stride). After transferring native tokens to Stride, liquid staking can be processed and it includes:

Sending IBC/Tokens to stakeibc account
Minting stTokens to stakeibc account
Sending stTokens from stakeibc account to user account on Stride

Staking & Reinvesment Staking and reinvestment steps:

Sweeps the deposit record (DR) marked TRANSFER_QUEUE from previous epochs. Under the hub, it con- structs IBC MsgTransfer with 30min timeout. TransferCallback is also created which is been called OnAcknowledgementPacket or OnTimeoutPacket. In the case of nill ack or ack_error DR’s status is set back to TRANSFER_QUEUE otherwise it becomes a candidate for delegation with DELEGATION_QUEUE flag.
Delegates DRs with status DELEGATION_QUEUE. It creates a set of MsgDelegate msgs (delegation to every validator from that host zone whose relative amount is positive). Each validator gets targetAmount=valWeight*depRecordAmount / totalValWeight. Also, DelegateCallback is defined. In the case of the happy ibc path, the zone’s staked balance is increased by a delegated amount to each validator whose delegationAmt is updated and finally DR is removed.
Rewards are automatically sent to

Excerpt (19997 of 90043 characters). Read the whole page on informalsystems/audits ↗

← Back to Documentation