You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a short follow-up on the state of the LSM module after a series of audits is drawing to a close.
Findings are only relevant to cosmos-sdk v0.50.x-lsm releases used on the Cosmos Hub.
While no significant issues were found, some smaller issues were already fixed and will be part of the next cosmos-sdk-lsm release.
For posterity, we're posting 2 informational findings that could inform future decisions around the x/staking modifications to support LSM that were first introduced in gaiad v12.0.0.
Informational finding 1
The difference in calculated total amount of liquid staked tokens and the reported total amount of liquid staked tokens (obtained by calling stakingKeeper.GetTotalLiquidStakedTokens()) was established and its impact was studied.
It was discovered that the difference is around 3000 uatom [0.003 atom], while the total amount of liquid staked tokens is around 7 400 000 000 000 uatom [7.4 M atom]
The impact on the system is insignificant and consistent with expected rounding errors while truncating decimals to integers for accounting purposes.
Action point
For completenes, it should be checked if there is an impact on the system while the total amount of liquid staked tokens approaches zero (i.e. check if the total liquid staked tokens can fall below 0 and if it would halt the chain or not). This might come into play if the LSM changes would get phased out and a state migration is in progress.
Informational finding 2
Identyfying delegations coming from liquid staking accounts (DelegatorIsLiquidStaker check) uses as simplistic check to determine the type of account.
Simply checking if the account address bytes slice is 32 bytes long is too simplistic and it may potentially interfere with other module accounts that have the same account address bytes slice length.
Further investigation is needed to identify if this issue actually ever manifests in a way that could impact users, modules or the system as a whole.
The total liquid staking cap is 25% while the current total liquid staked ATOM (at the time of writing) is ~3%. There should be no immediate risk to the system.
The text was updated successfully, but these errors were encountered:
This is a short follow-up on the state of the LSM module after a series of audits is drawing to a close.
Findings are only relevant to
cosmos-sdk v0.50.x-lsm
releases used on the Cosmos Hub.While no significant issues were found, some smaller issues were already fixed and will be part of the next
cosmos-sdk-lsm
release.For posterity, we're posting 2 informational findings that could inform future decisions around the
x/staking
modifications to support LSM that were first introduced ingaiad v12.0.0
.Informational finding 1
The difference in calculated total amount of liquid staked tokens and the reported total amount of liquid staked tokens (obtained by calling
stakingKeeper.GetTotalLiquidStakedTokens()
) was established and its impact was studied.It was discovered that the difference is around
3000 uatom [0.003 atom]
, while the total amount of liquid staked tokens is around7 400 000 000 000 uatom [7.4 M atom]
The impact on the system is insignificant and consistent with expected rounding errors while truncating decimals to integers for accounting purposes.
Action point
For completenes, it should be checked if there is an impact on the system while the total amount of liquid staked tokens approaches zero (i.e. check if the total liquid staked tokens can fall below 0 and if it would halt the chain or not). This might come into play if the LSM changes would get phased out and a state migration is in progress.
Informational finding 2
Identyfying delegations coming from liquid staking accounts (
DelegatorIsLiquidStaker
check) uses as simplistic check to determine the type of account.Simply checking if the account address bytes slice is 32 bytes long is too simplistic and it may potentially interfere with other module accounts that have the same account address bytes slice length.
Further investigation is needed to identify if this issue actually ever manifests in a way that could impact users, modules or the system as a whole.
The total liquid staking cap is 25% while the current total liquid staked ATOM (at the time of writing) is ~3%. There should be no immediate risk to the system.
The text was updated successfully, but these errors were encountered: