Transaction v3 SNIP

This is to discuss the Transaction V3 Structure SNIP:

Open questions:

  1. Should we separate the fields nonce_data_availability_mode and fee_data_availability_mode or use one data_availability_mode that will be used both for nonce and fee?

I had envisioned paymaster’s being offered by dapps generally on a per-dapp basis. In which case I imagine providing the paymaster_address would allow the dapp’s paymaster to validate the “request” by the account that the tx fees be covered.

I appreciate that backward compatibility is addressed with a transition period for the tx sender, but are there any backward compatibility issues on the contract side? I.e. would an immutable / non-upgradeable Cairo 1 contract deployed prior to 0.13 still be compatible with a v3 tx sent after 0.13?

And although the pre-0.13 contract wouldn’t be able to take advantage of volition with its internal storage, would a user by able to submit a v3 tx to the pre-0.13 contract with a L2DA fee selected, and / or with a paymaster selected?

Yes, Cairo 1.0 contracts won’t break. The OS keeps all syscalls and execution backward compatible for Cairo 1.0.
As you mentioned, non-upgradable contracts won’t be able to benefit from new features (e.g., volition) or the new TxInfo (e.g., max L1_gas price for the tx), but the deployed contract won’t break and will continue functioning.

Users initiating a v3 transaction will be able to enjoy paying fees from their L2DA balance and the use of the paymaster (once implemented in Starknet) regardless of the contracts they’re interacting with.

I have various random questions:

  1. In the document, you use the || operator in some places. What does it do? Is it string concatenation?
  2. The Resource can only be L1_GAS or L2_GAS correct?
  3. How does the nonce_data_availability_mode and fee_data_availability_mode work? What are they for? Isn’t nonce_data_availability_mode set only once when an account is deployed?
  4. How is compiled_class_hash calculated? The link in the document leads to something unrelated. Why do we need it at all? Update: I’ll partially answer myself - v2 declare tx also already has compiled_class_hash.
  5. In the reply above you write “Users initiating a v3 transaction will be able to enjoy paying fees from their L2DA balance” - how will this work? Won’t the token itself need to support L2 DA balance in the first place?