# Transaction v3 SNIP **URL:** \ **Category:** SNIPs\ **Created:** [August 9, 2023, 5:08pm UTC](https://community.starknet.io/t/transaction-v3-snip/98228 "2023-08-09T17:08:59Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![EvyatarO](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/evyataro/32/394_2.png) [@EvyatarO](https://community.starknet.io/u/EvyatarO)\ **Post date:** [August 9, 2023, 5:08pm UTC](https://community.starknet.io/t/transaction-v3-snip/98228/1 "2023-08-09T17:08:59Z")
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? ---
**Author:** ![darkosnightmare](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/darkosnightmare/32/745_2.png) [@darkosnightmare](https://community.starknet.io/u/darkosnightmare)\ **Post date:** [August 10, 2023, 1:02pm UTC](https://community.starknet.io/t/transaction-v3-snip/98228/3 "2023-08-10T13:02:47Z")
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. ---
**Author:** ![darkosnightmare](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/darkosnightmare/32/745_2.png) [@darkosnightmare](https://community.starknet.io/u/darkosnightmare)\ **Post date:** [August 10, 2023, 1:10pm UTC](https://community.starknet.io/t/transaction-v3-snip/98228/4 "2023-08-10T13:10:09Z")
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? ---
**Author:** ![EvyatarO](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/evyataro/32/394_2.png) [@EvyatarO](https://community.starknet.io/u/EvyatarO)\ **Post date:** [August 13, 2023, 3:07pm UTC](https://community.starknet.io/t/transaction-v3-snip/98228/5 "2023-08-13T15:07:44Z")
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. ---
**Author:** ![milan](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/milan/32/23836_2.png) [@milan](https://community.starknet.io/u/milan)\ **Post date:** [August 14, 2023, 2:50pm UTC](https://community.starknet.io/t/transaction-v3-snip/98228/6 "2023-08-14T14:50:44Z")
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](https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/Blocks/transactions/#declare_v2) 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? ---
**Author:** ![martriay](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/martriay/32/25_2.png) [@martriay](https://community.starknet.io/u/martriay)\ **Post date:** [December 19, 2023, 4:33am UTC](https://community.starknet.io/t/transaction-v3-snip/98228/7 "2023-12-19T04:33:44Z")
Great proposal! A few questions: 1. We’re adding a `tip` for tx order, is this somehow enforced? Or just implemented at the sequencer level but can be changed by the sequencer? 2. Why is `account_init_code` needed in the declare fields? 3. I’m not really sure why account deployments are treated differently (`Deploy_account_v3_tx_hash`, `deploy_account` as TX\_PREFIX). Can’t **validate\_deploy** be used by any other, regular contract? I don’t think it should be account specific. 4. What does `||` mean? 5. I assume that if no paymaster is being used, `paymaster_address` should be `0`? or oneself? 6. on the `get_execution_info` changes, the first element is not named, just typed (`List[Resource]`) i guess the obvious name would be `resources`. 7. How will single-tx deployments (deploy + invoke) would look like? 8. and what about declare + invoke? this one confuses me a bit Also, some small typos: - hybris → hibryd - Daeclare → declare - ` __validate_delcare__ ` → ` __validate_declare__ `