# Expected Q&A

## Q1: What does this differ from calldata solutions like Validium?

A: Totally different. Intmax is zkRollup. In Validium, a Data Availability attack leads to the loss of users' funds. So it affects safety. In Intmax's approach, the Data Availability attack never leads to the loss of user's funds and is only limited to the necessity of exit.

## Q2: What is the difference from Adamantium?

A: First of all, Adamantium is the first post about combining zkRollup and online communications. Starkware is the first pioneer to try this.

The differences are

(1) In Adamantium and Springrollup, the protective withdrawal and force withdrawal are independently simple and elegant ideas. Users' funds get withdrawn to Layer1 with protective withdrawal or requests recorded on Layer1 when they have communication troubles with the aggregators for a relatively long term. However, using Layer1 is expensive, and bridging funds back and forth is not good usability. Since the communication problem can unintentionally happen, the costs of a solution should be minimized. Intmax found a way to cancel a tx.

(2) Adamantium does not make the exit process clear. Intmax uses non-movement proof of assets like Plasma Prime. Users can exit their funds by their selves, not relying on operators. So Liveness/Safety Separation was introduced to Intmax.

## Q3:What is the difference from Springrollup?

A: Springrollup is a cool and elegant idea that shows the possibility of optimizing zkRollup + limited online assumption for transfer usage.

We can add something to it.

Springrollup requires a sender to have two times of communications with an aggregator to receive proofs(witnesses). Furthermore, in the security scenario where the operator does not provide the last proof of the balance/state and goes frozen, it is hard to exit funds with the proof of state distributed before the block generation and the proof of the pending tx. If there is no distribution of a tx proof that leads to the calldata after the block generation, the previous state is not available for the exit since Merkle proof always changes before the block is fixed. Then we need cancelation or additional calldata. This case is the only thing left to be discussed in Springrollup.

We introduced the cancel mechanism, and also the communication became one-time.

Springrollup describes the efficient transfer, but it was limited to one asset. This post describes the many assets to many recipients in an efficient way.

## Q4: Why can aggregators keep the AssetStorageRootTree off-chain?

A: Because users can exit their money to Layer1 even when the data availability attack destroyes the AssetStorageRootTree. In this case, aggregators can execute no more transactions for them, and this loss of liveness means the time to exit funds to Layer1. We call this Liveness/Safety Separation.

## Q5: For example, how can you send 10 types of ERC20s/NFTs to 100 people?

A: The sender purges the 100 state-diff trees and makes a tx-hash from them. Each state-diff contains a different recipient and 10 types of ERC20s/NFTs. He sends the tx-hash and zkp proofs as a transaction, and the operator returns the proof of the tx-hash. He sends this proof and each state-diff content to 100 recipients so that a recipient can merge.

There is no difference between sending one asset to one person and sending 10 types to 100 people; only the size of the circuit changes.

## Q6: Why does Intmax choose the architecture that aggregators know only the root of the user's asset storage and tx-hash.

A: For efficiency. The Client-side can aggregate a lot of transactions thanks to this architecture.

## Q7: Why is IntermidiateAssetRootTree's root needed in calldata?

A: Because after the block generation, the tree will change by the cancelations. It is impossible to make a proof to distribute to a sender before the Merkle tree is fixed.

So we need two roots of the tree. The intermediate one is to distribute, and the final one which is fixed after the online communication is finished.

## Q8: (relevant to the question above) What if a user tries to exit his money with a distributed proof which he did not signed?

A: This is a canceled transaction since he did not sign the proof; the lastBlockNumber does not change with the failure flag. When the exit, the lastBlockNumber should be the same
as the block number of the proof he was given. But this does not correspond.

## Q9: What happens to depositors if the block generation stops after they deposit?

A: This never be on state-diffs on Layer2 if there is no more new block, then there is a need for a refund mechanism for this case.

## Q10: What if there are two transactions from one sender? One is with a timely signature (success flag), and the other is not.

A: Both of them get canceled. Because the address will get marked with the failure flag, and both transactions are not available to merge for the recipients. The lastBlockNumber does not match the block number of the tx-hash for this case.