Canto Application Specific Dollars and Bonding Curves for 1155s - aslanbek's results

minhquanym marked the issue as duplicate of #12

MarioPoneder marked the issue as satisfactory

minhquanym marked the issue as primary issue

OpenCoreCH marked the issue as disagree with severity

OpenCoreCH (sponsor) acknowledged

These are extremely improbable, constructed examples. You could probably create such an example for most protocols, especially the one with the consecutive IDs because many smart contracts use them. If a user wants to be really sure that they are on the canonical chain and this does not happen, they can simply wait a few blocks.

According to our guidelines:

Unless there is something uniquely novel created by combining vectors, most submissions regarding vulnerabilities that are inherent to a particular system or the Ethereum network as a whole should be considered QA. Examples of such vulnerabilities include front running, sandwich attacks, and MEV.

Also reorg-attacks are part of this category, therefore QA seems most appropriate.

MarioPoneder changed the severity to QA (Quality Assurance)

MarioPoneder marked the issue as grade-c

Hi @MarioPoneder Thanks for judging this contest. I am commenting here under the primary issue as the author of one of the duplicates (#312) of this finding.

I acknowledge these kind of issues are related to blockchain itself, and a person could create such an example for most protocols as the sponsor mentioned. However, the upscaling factor related to this protocol is that contract creations are totally permissionless here, which makes this protocol much more vulnerable to this issue.

Based on that sentence in the guideline, frontrunning or MEV issues too would be invalid. However these issues still valid because protocols should take precautions to protect their users. Similar to that, if a protocol allows any user to create contracts permissionlessly, that protocol should also implement protections against the creation mechanism.

The problem here is not reorg itself, it is the protocol not taking necessary precautions while allowing everyone to deploy contracts.

I also would like to point out similar submissions related to permissionless contract creations and reorgs are historically judged as medium. References: August 2023 - PoolTogether: https://github.com/code-423n4/2023-08-pooltogether-findings/issues/31 July 2023 - PoolTogether: https://github.com/code-423n4/2023-07-pooltogether-findings/issues/416 May 2023 - Maia: https://github.com/code-423n4/2023-05-maia-findings/issues/861 April 2023 - Frankencoin: https://github.com/code-423n4/2023-04-frankencoin-findings/issues/155 January 2023 - RabbitHole: https://github.com/code-423n4/2023-01-rabbithole-findings/issues/661

I would appreciate if you could reconsider the severity of this issue and its duplicates. Kind regards

Hi and thank you for your comment and the referenced findings!

After not finding a suitable answer in the org repo, I did some additional research on the C4 Judges Discord channel.
The answer is it depends on how exposed a protocol is to such an attack and how likely/expensive and long (in terms of blocks) such a reorg could be. Therefore I kindly ask for additional sponsor input on this. @OpenCoreCH

According to the README:

The code will be deployed to Canto

Looking at Cantoscan there is a Last finalized block and a Last safe block.
According to What are Ethereum commitment levels? Latest, Safe, Finalized:

The safe block is a block that has received attestations from two-thirds of Ethereum’s validator set. Safe blocks are understood as unlikely to be reorged. For example, one of the few ways safe blocks could experience a chain reorganization is if there is a large-scale, coordinated attack on the network.

I see it as the user's / front-end's responsibility to wait for the Last safe block. Although the protocol does not take precautions for a reorg attack, it's not clear if this is necessary on the Canto chain like on Polygon for example where reorgs are regular.

Therefore, I will finalize my decision after the sponsor has provided additional input about their definition of Last safe block, the occurrence of reorgs on Canto and for how many blocks they last.

Hi @MarioPoneder , thanks for the judging.

My report at the #405 duplicate can contribute to the ongoing discussion in several ways:

1. The sponsor has confirmed that while asDFactory is currently deployed only on CANTO, the 1155tech market is open for deployment on other chains where reorgs occur frequently. The Last safe block to consider could be in minutes. For instance, the Polygon network has recorded several reorgs a day involving hundreds of transactions.

2. We should avoid placing the responsibility on users to wait for the safest time to opt-in to the market after createNewShare was executed. This is because the 1155tech market operates on a BondingCurve pricing mechanism which increases token price over the number of tokens minted. It's in the user's best interest to act in a First-Come-First-Serve (FCFS) manner. If users wait for the safe block, they risk missing out on a good price as others decide to opt in as soon as possible (via other means, i.e., interacting directly with the smart contract). This could discourage them from engaging with the market.

After not finding a suitable answer in the org repo, I did some additional research on the C4 Judges Discord channel. The answer is it depends on how exposed a protocol is to such an attack and how likely/expensive and long (in terms of blocks) such a reorg could be. Therefore I kindly ask for additional sponsor input on this. @OpenCoreCH

Good question, had to look it up, but it looks like these reorgs are not possible. Canto is a fork of Evmos/Ethermint and also uses Tendermint Core BFT consensus. This provides 1-block finality and not probabilisitic finality like other chains: https://docs.ethermint.zone/core/pending_state.html

Thanks everyone for their input on this!

Considering the 1-block finality on Canto, QA will be maintained.
However, those finds are still a valuable contribution, therefore moving forward with grade-b.

1155tech may be deployed on other chains in the future.

According to the README (source of truth of this contest), the protocol will be deployed on Canto and I cannot take potential future deployments into consideration for judgement, especially when we don't know exactly which chain it's going to be.

Further info regarding 1-block finality:
One can observe on Cantoscan that Last finalized block and Last safe block are always the same.

MarioPoneder marked the issue as grade-b