Reviewing files that changed from the base of the PR and between 55d40ea and 5868fed.

• Cargo.lock is excluded by !**/*.lock

• Cargo.toml (1 hunks)
• crates/starknet-devnet-core/Cargo.toml (0 hunks)
• crates/starknet-devnet-core/src/error.rs (4 hunks)
• crates/starknet-devnet-core/src/lib.rs (0 hunks)
• crates/starknet-devnet-core/src/stack_trace.rs (0 hunks)
• crates/starknet-devnet-core/src/starknet/add_l1_handler_transaction.rs (2 hunks)
• crates/starknet-devnet-core/src/starknet/estimations.rs (3 hunks)
• crates/starknet-devnet-core/src/starknet/mod.rs (8 hunks)
• crates/starknet-devnet-server/src/api/http/endpoints/mint_token.rs (1 hunks)
• crates/starknet-devnet-server/src/api/json_rpc/endpoints.rs (5 hunks)
• crates/starknet-devnet-server/src/api/json_rpc/error.rs (6 hunks)
• crates/starknet-devnet-types/src/rpc/transactions.rs (7 hunks)
• crates/starknet-devnet/src/cli.rs (1 hunks)
• tests/integration/common/background_devnet.rs (3 hunks)
• tests/integration/common/constants.rs (1 hunks)
• tests/integration/common/fees.rs (1 hunks)
• tests/integration/common/utils.rs (11 hunks)
• tests/integration/get_transaction_by_hash.rs (6 hunks)
• tests/integration/get_transaction_receipt_by_hash.rs (11 hunks)
• tests/integration/lib.rs (0 hunks)
• tests/integration/test_abort_blocks.rs (2 hunks)
• tests/integration/test_account_impersonation.rs (3 hunks)
• tests/integration/test_account_selection.rs (4 hunks)
• tests/integration/test_advancing_time.rs (2 hunks)
• tests/integration/test_blocks_generation.rs (5 hunks)
• tests/integration/test_call.rs (5 hunks)
• tests/integration/test_dump_and_load.rs (7 hunks)
• tests/integration/test_estimate_fee.rs (24 hunks)
• tests/integration/test_estimate_message_fee.rs (2 hunks)
• tests/integration/test_fork.rs (7 hunks)
• tests/integration/test_gas_modification.rs (9 hunks)
• tests/integration/test_get_class.rs (3 hunks)
• tests/integration/test_get_events.rs (3 hunks)
• tests/integration/test_messaging.rs (18 hunks)
• tests/integration/test_minting.rs (1 hunks)
• tests/integration/test_old_state.rs (9 hunks)
• tests/integration/test_restart.rs (5 hunks)
• tests/integration/test_simulate_transactions.rs (34 hunks)
• tests/integration/test_subscription_to_events.rs (1 hunks)
• tests/integration/test_subscription_to_tx_status.rs (1 hunks)
• tests/integration/test_trace.rs (9 hunks)
• tests/integration/test_transaction_handling.rs (3 hunks)
• tests/integration/test_v3_transactions.rs (7 hunks)

• tests/integration/lib.rs
• crates/starknet-devnet-core/Cargo.toml
• crates/starknet-devnet-core/src/lib.rs
• crates/starknet-devnet-core/src/stack_trace.rs

tests/integration/test_advancing_time.rs (2)

67-67: Switch to declare_v3 looks correct.

This aligns with the updated transaction version usage. Ensure all references and calls in the test suite remain consistent with the declare_v3 method.

---

76-76: Migration to deploy_v3 is consistent with the new workflow.

The updated method call is appropriate for version 3 deployments. Ensure that any downstream references or usage of deployment logic also aligns with this change.

tests/integration/common/fees.rs (2)

52-52: Confirm that allowing equality for L1 gas is intended.

Switching from > to >= could permit cases where both traces report the same L1 gas usage. Verify whether this is the intended behavior or if strict inequality was expected.

---

62-62: Requiring strictly more L2 gas may cause edge cases.

Replacing >= with > tightens the condition for L2 gas usage. Confirm that there's no scenario where equal L2 gas usage should be accepted.

crates/starknet-devnet-types/src/rpc/transactions.rs (9)

16-18: New imports for resource bounds are appropriate.

These additions (AllResourceBounds, Fee, GasVectorComputationMode, Tip, and ValidResourceBounds) seem consistent with the updated logic for resource management.

---

21-22: Imported mapping and statuses align with new usage.

Introducing ResourceBounds, ResourceBoundsMapping, and transaction status types is consistent with the expanded functionality in resource and execution result handling.

---

347-350: Refined GasVectorComputationMode matching logic.

Mapping ValidResourceBounds::L1Gas(_) to NoL2Gas and AllResources(_) to All is consistent with a clear distinction between single vs. multi-resource usage. Double-check whether partial combinations (e.g., only L1 data gas) are handled elsewhere or implicitly treated as “all resources.”

---

399-424: Review match logic for partial resource bounds.

This block interprets (l1_gas_max_amount, l2_gas_max_amount, l1_data_gas_max_amount) to determine whether we have AllResources or only L1Gas. Verify that cases like “l1_data_gas only” or “l1_data_gas + l2_gas, but no l1_gas” are intentionally treated as AllResources.

---

440-448: Validate conditional checks in resource-bound matching.

Adding these match arms clarifies which combinations of (l1_gas, l2_gas, l1_data_gas) are acceptable. Confirm your fallback ensures correct allowance when only l1_data_gas or l2_gas is nonzero.

---

1013-1019: Optional trace fields improve clarity.

Conditionally serializing validate_invocation, fee_transfer_invocation, and state_diff is a good approach to keep JSON responses smaller. No issues found.

---

1026-1031: Optional fields in DeclareTransactionTrace.

Skipping serialization when fields are none is consistent with the pattern in other traces. Looks good.

---

1038-1045: Flexible deployment trace structure.

The optional constructor and fee transfer details allow partial traces without bloating responses. No concerns here.

---

1053-1054: L1 handler trace now optionally includes state diff.

This preserves consistency with other transaction traces and avoids empty structures. Implementation looks correct.

tests/integration/test_minting.rs (1)

78-78: Test updated to reflect new default unit.

This test adjustment properly reflects the change in default fee unit from WEI to FRI. The test now correctly expects "FRI" in the response when no unit is specified in the request.

tests/integration/test_subscription_to_tx_status.rs (1)

24-24:

Details

❓ Verification inconclusive

Updated expected transaction hash due to fee unit change.

The transaction hash has been updated to reflect the new expected value when using FRI as the default unit. This is a necessary change since the transaction hash depends on the transaction details, which now include FRI instead of WEI.

Run the following script to verify this is the correct transaction hash for the first mint operation:

---

🏁 Script executed:

#!/bin/bash
# Start a fresh devnet instance and check the first mint transaction hash
# to verify the expected hash is correct

PORT=5050
# Start devnet in background
starknet-devnet --port $PORT &
DEVNET_PID=$!

# Give devnet time to start
sleep 2

# Perform the first mint operation
MINT_RESULT=$(curl -s -X POST "http://127.0.0.1:$PORT/mint" \
  -H "Content-Type: application/json" \
  -d '{"address":"0x1","amount":10}')

# Extract the transaction hash
TX_HASH=$(echo $MINT_RESULT | jq -r '.tx_hash')
echo "Actual transaction hash: $TX_HASH"
echo "Expected transaction hash: 0xf33a338433016ad79716afb01599f70ce7f03cdf5acda0137095c8407a2c0b"

# Clean up
kill $DEVNET_PID

Length of output: 716

---

Updated Transaction Hash Verification: Manual Confirmation Required

The updated expected transaction hash is correctly set to account for the fee unit change from WEI to FRI. However, our verification script failed to produce any output because the starknet-devnet command was not found in the current environment. Please ensure that the starknet-devnet tool is installed and available, then re-run the script or manually verify that the first mint transaction hash indeed matches the expected value:

• Expected hash: 0xf33a338433016ad79716afb01599f70ce7f03cdf5acda0137095c8407a2c0b

Once verified, you can approve the change confidently.

tests/integration/test_subscription_to_events.rs (1)

59-61: Great migration from fee calculation to explicit gas parameters!

The code now specifies explicit gas values for different layers (L1, L1 data, L2) instead of calculating them, which aligns with the migration from Wei to Fri (ETH to STRK) mentioned in the PR objectives.

tests/integration/test_estimate_message_fee.rs (2)

33-33: Good simplification of declaration code with new transaction version

The code now uses a more concise approach for declaring classes with the v3 transaction format, which aligns with the updated dependencies.

---

66-67: Appropriate update to gas consumption assertions

The test now correctly checks separate L1 and L2 gas consumption values instead of a single aggregated value, providing more granular verification.

tests/integration/test_abort_blocks.rs (2)

149-149: Successfully migrated fee unit from Wei to Fri

Updated balance retrieval to use FeeUnit::Fri instead of FeeUnit::Wei, which aligns with the PR objective of switching from ETH to STRK as the currency.

Also applies to: 156-156, 162-162

---

249-249: Correctly updated fee unit in pending block test

Updated both pending and latest balance checks to use FeeUnit::Fri, maintaining consistency with the currency migration from Wei to Fri.

Also applies to: 256-256

Cargo.toml (1)

83-87:

Details

❓ Verification inconclusive

Successfully upgraded Starknet dependencies to version 0.13.x

Updated all Starknet-related dependencies to their latest versions, which is consistent with the PR title "Starknet-0.13.4-snrs". This upgrade likely provides new features, bug fixes, and improved compatibility with the latest Starknet protocol.

---

🏁 Script executed:

#!/bin/bash
# Check for any compatibility issues between the updated dependencies
grep -r "starknet-rs-" --include="*.rs" . | grep -v "use" | grep -v "extern crate" | head -20

Length of output: 91

---

Starknet Dependency Upgrade Verified – Manual Compatibility Check Recommended

The upgrade in the Cargo.toml correctly updates most Starknet dependencies to version 0.13.x in line with the PR title "Starknet-0.13.4-snrs". Note that starknet-rs-signers remains at version 0.11.0, which could be intentional if a 0.13.x release isn’t available for that package.

The automated grep check for compatibility issues produced no matches. This may either indicate that no direct compatibility issues exist or that the search approach doesn’t capture all usage scenarios. It’s advisable to manually verify the integration points where these dependencies are employed.

• Confirm that the version pinning for starknet-rs-signers is deliberate.
• Verify that the usage of each Starknet dependency across the codebase remains compatible with these versions.

Please perform a manual review of the affected code areas to ensure overall compatibility.

tests/integration/test_account_impersonation.rs (3)

200-200: Updated from execute_v1 to execute_v3 for transaction simulation

This is part of the Starknet 0.13.4 migration to use execute_v3, which now uses FRI as the default unit (instead of WEI) with STRK as the currency.

---

230-230: Updated from declare_v2 to declare_v3 for contract declaration

The declaration process has been migrated to use the v3 API. The change is consistent with the removal of max_fee parameter that was previously required in v2 declarations, now that the gas currency has changed to STRK (FRI units).

---

253-253: Updated from execute_v1 to execute_v3 for transaction invocation

The execution method has been upgraded to v3, aligning with the Starknet 0.13.4 changes where FRI is now the default unit and STRK is the currency.

tests/integration/test_get_class.rs (3)

60-61: Updated from declare_v2 to declare_v3 for contract declaration

The declaration method has been upgraded to use v3, removing the need for max_fee parameter that was previously required in v2. This change aligns with the Starknet 0.13.4 migration to use FRI as the default unit.

---

111-112: Updated from declare_v2 to declare_v3 in blocks-on-demand test

Similar to the previous change, the declaration API has been updated to v3, removing the max_fee parameter. This is consistent with the migration to FRI units across all transaction-related methods.

---

181-182: Updated from declare_v2 to declare_v3 in block abortion test

The contract declaration method has been updated to v3, consistent with the other changes in this file and across the codebase. The upgrade to v3 methods supports the new fee structure using FRI units for STRK currency.

tests/integration/test_get_events.rs (5)

19-19: Changed predeployed_account to be mutable

The variable is now declared as mutable to support setting the block ID conditionally based on the block_on_demand parameter.

---

27-29: Added conditional block ID setting for block-on-demand mode

Added support for block-on-demand mode by setting the block ID to Pending when required. This ensures transactions can be queued properly in this mode.

This change was previously commented on in a review. The reviewer suggested minimizing conditional logic in tests and recommended specifying gas_bounds in declarations instead. Has this approach been discussed and agreed upon by the team?

---

35-37: Updated from declare_v2 to declare_v3 for contract declaration

The declaration API has been updated to v3, removing the max_fee parameter. This change is consistent with the Starknet 0.13.4 migration to use FRI as the default unit.

---

50-50: Updated from deploy_v1 to deploy_v3 for contract deployment

The deployment method has been upgraded to v3, aligning with other transaction-related method updates. The new API uses FRI units and no longer requires explicit max_fee specification.

---

75-76: Updated from execute_v1 to execute_v3 for transaction execution

The execution method has been upgraded to v3, consistent with other changes across the codebase. This supports the new fee structure using FRI units for STRK currency.

crates/starknet-devnet-server/src/api/json_rpc/endpoints.rs (4)

1-1: Added ContractExecutionError to imports

Added ContractExecutionError to the imports to support the refactored error handling throughout the file.

---

339-343: Streamlined error handling for transaction execution errors in simulation

The error handling has been simplified to directly pass the execution_error to the ApiError, removing the need for error stacks and improving the clarity of error responses.

---

358-360: Enhanced error handling for message fee estimation

Updated the error handling to directly use ContractExecutionError, aligning with the refactored error handling approach throughout the file.

---

469-473: Improved error handling for transaction simulation

The error handling for simulation has been updated to directly use ContractExecutionError, consistent with other error handling changes in the file. This provides a more structured approach to error reporting.

crates/starknet-devnet-core/src/starknet/estimations.rs (3)

16-16: Import update for the new error handling approach.

The import now explicitly brings in ContractExecutionError from the error module, reflecting the transition from ErrorStack to a more structured error representation.

---

82-91: Error handling improved with stronger typing.

The error handling has been refactored to use the more structured ContractExecutionError type instead of relying on generic error stacks. This enhances type safety and improves error clarity for API consumers.

---

134-152: Consider removing the TODO comment as suggested in previous feedback.

The implementation now uses a structured match pattern for handling different types of revert errors, which is more maintainable than the previous approach. However, there's a TODO comment about users preferring structured errors that could be removed since you're now providing structured errors with ContractExecutionError.

Also, as pointed out in a previous review, the revert_error_string parameter could potentially be omitted as it could be handled within the From converter for ContractExecutionError.

-            // TODO Users would probably prefer a structured error, but according to the RPC spec, a
-            // string is allowed. We should improve this for non Execution error
-            let revert_error_string = revert_error.to_string();
             match revert_error {
                 blockifier::transaction::objects::RevertError::Execution(error_stack) => {
-                    return Err(Error::ContractExecutionError(ContractExecutionError::from((
-                        error_stack,
-                        revert_error_string,
-                    ))));
+                    return Err(Error::ContractExecutionError(ContractExecutionError::from(error_stack)));
                 }
                 blockifier::transaction::objects::RevertError::PostExecution(fee_check_error) => {
                     return Err(fee_check_error.into());
                 }
             };

crates/starknet-devnet-core/src/starknet/add_l1_handler_transaction.rs (2)

62-63: Added constant import for error handling enhancement.

The new constant import will be used to verify error messages in test cases, which improves test coverage and error handling validation.

---

136-158: Improved error validation in test cases with structured errors.

The error handling has been refactored to use the more structured ContractExecutionError::Nested type instead of accessing error frames directly. This change improves error handling by:

1. Using strongly typed error structures
2. Validating specific fields of the error (selector, contract_address)
3. Adding a check for the proper error encoded string

This approach makes the tests more robust and better aligned with the new error handling model.

tests/integration/common/constants.rs (1)

85-89:

Details

❓ Verification inconclusive

Updated RPC endpoints to v0_8.

The integration test endpoints have been updated from v0_7 to v0_8, which likely aligns with the API changes in the Starknet protocol. Ensure that the functionality is compatible with these newer endpoints.

---

🏁 Script executed:

#!/bin/bash
# Verify test endpoints are accessible

echo "Checking if the updated endpoints are accessible..."
curl -s --head "${INTEGRATION_SEPOLIA_HTTP_URL}" | head -n 1
curl -s --head "${MAINNET_URL}" | head -n 1
curl -s --head "${MAINNET_HTTPS_URL}" | head -n 1

echo "Looking for any other references to v0_7 that might need to be updated..."
rg -F 'v0_7' --type rust

Length of output: 390

---

Verify that the updated RPC endpoints are indeed reachable.
The constants in tests/integration/common/constants.rs now correctly reference v0_8 endpoints, and a preliminary check for lingering v0_7 references returned no results. However, the automated shell script did not display endpoint accessibility results—likely because the constant values weren’t picked up by the shell environment. Please manually verify that the following endpoints are reachable and return the expected responses:

• INTEGRATION_SEPOLIA_HTTP_URL
• MAINNET_URL
• MAINNET_HTTPS_URL

Once manual checks confirm that these endpoints are operational, we can fully approve this change.

crates/starknet-devnet-server/src/api/json_rpc/error.rs (6)

1-2: Updated imports for enhanced JSON serialization.

The imports have been updated to use serde_json::json macro directly and to import ContractExecutionError from starknet_core, aligning with the new error handling approach throughout the codebase.

---

31-33: Simplified error model with structured error types.

The error variants now use ContractExecutionError directly instead of the legacy ErrorStack, which provides more structured and typesafe error handling. This change aligns with the broader error handling improvements in the codebase.

---

106-112: Enhanced error response structure for contract errors.

The error response format has been improved to directly include the contract_execution_error in the JSON payload, making it easier for API consumers to process and understand the errors.

---

113-120: Consistent error handling for transaction execution errors.

Similar to the contract error changes, the transaction execution error response now includes the structured execution_error directly in the JSON data.

---

357-368: Updated test cases to use the new error structure.

The test cases have been properly updated to use the new ContractExecutionError::Message type and to verify the corresponding JSON structure in the error response.

---

373-389: Refactored transaction execution error tests.

The transaction execution error test cases have been updated to use the new error structure, ensuring that the serialization of errors works as expected.

tests/integration/test_blocks_generation.rs (7)

286-292: Initialize account with caution.
Creating a mutable SingleOwnerAccount with the new ExecutionEncoding::New mode can be appropriate if you consistently use the new transaction format across your codebase.

---

293-293: Ensure correct block context.
predeployed_account.set_block_id(BlockId::Tag(BlockTag::Pending)) will route subsequent operations to the pending block. Verify this is intentional if you rely on pending-state updates.

---

304-304: Migrate to the new declaration version.
Using .declare_v3 aligns with newer protocol requirements. Ensure other references to older declaration methods are updated for consistency.

---

370-377: New account initialization with pending block context.
Creating a mutable account and setting the block ID to pending is consistent with your on-demand block generation approach. Confirm that this interacts well with any subsequent block creation calls.

---

383-383: Updated declare_v3 usage.
Looks good for version 3 declarations. Check that configuration for the Arc reference is properly tested if concurrency is relevant.

---

397-397: Deploy with the new method.
deploy_v3 is the recommended approach in newer APIs. Ensure the constructor arguments and fee structure remain valid under deploy_v3.

---

422-422: Switch to execute_v3.
Upgrading to execute_v3 closes the gap with the new fee model. If you have downstream code parsing older transaction formats, verify it is fully updated.

tests/integration/test_transaction_handling.rs (3)

38-44: Refine customized gas limits.
Using .l1_gas(0), .l1_data_gas(1000), .l2_gas(5e7 as u64) offers more granular control. Be sure these bounds match your testing scenarios and won’t trigger unintended insufficient resource errors.

---

72-75: Validate CASM hash correctness.
Declaring with a dummy CASM hash is expected to fail if mismatched. This test correctly covers that scenario.

---

105-112: Granular gas parameters in execute_v3.
Specifying separate parameters for L1 gas, L1 data gas, and L2 gas is recommended for modern transaction flows. Confirm that the specified amounts align with your devnet configuration.

tests/integration/test_gas_modification.rs (16)

73-79: Adopt version 3 declare with zero resource bounds.
Declaring the contract with .declare_v3(...).l1_gas(0).l1_data_gas_price(0)... is valid for testing minimal gas scenarios. Just ensure it doesn’t conflict with any actual cost modeling.

---

85-85: Establish zero resource bounds JSON.
Defining zero_bounds with max_amount and max_price_per_unit set to 0 is consistent with a baseline scenario.

---

96-101: Upgrade simulation to version "0x3".
The addition of "resource_bounds" clarifies max L1/L2 resource usage, important for detailed fee calculations.

---

105-109: Add optional fields for tipping and paymaster data.
Including "tip": "0x0", "paymaster_data": [], "account_deployment_data": [], and data availability modes ensures the transaction object remains spec-compliant.

---

159-162: Check fee variation with SKIP_VALIDATE.
Ensuring different flags yield different overall fees is important. The numeric values look correct, but watch out for future protocol changes that might alter these values.

---

170-172: Introduce new Fri prices.
Defining distinct FRI prices for L1 gas, data gas, and L2 gas is consistent with the devnet’s advanced fee model.

---

174-179: Set updated gas prices.
Storing new gas_price_wei, gas_price_fri, etc. in JSON is a direct approach for test coverage.

---

193-199: Validate fee estimation with revised FRI gas prices.
Asserting the new gas-related fields in the response ensures that updated FRI prices are recognized.

---

205-211: Fee estimates after skipping validation.
Correctly identifies the difference in overall_fee for skipped vs. unskipped validation. The numeric changes appear correct.

---

217-217: Check skip fee invocation toggle.
should_skip_fee_invocation remains a faithful check for fee invocation differences.

---

248-255: Initialize default data and L2 gas prices.
Mapping them to the same initial values as Wei is appropriate if you want the initial Fri settings to match the default.

---

261-263: Validate default resource prices in genesis block.
Confirming latest_block.l1_gas_price remains the default indicates no user override occurred.

---

380-383: Check pending block L1 gas price.
Ensures that updated or default resource pricing is applied to the pending block.

---

385-390: Check pending block L1 data gas price.
Similar verification for data gas; ensures consistency in resource pricing logic.

---

392-396: Check pending block L2 gas price.
Validates L2 gas usage aligns with your new or default FRI configuration.

---

400-403: Retry after adjusting L2 gas price.
Raising l2_gas to avoid InsufficientAccountBalance errors is valid. This final declare with .declare_v3 confirms the new gas pricing is effective.

tests/integration/test_account_selection.rs (5)

15-15: Network URL constant updated to Sepolia

The constant for network URL has been changed from MAINNET_URL to INTEGRATION_SEPOLIA_HTTP_URL, aligning with the migration to using Sepolia testnet instead of Mainnet for integration testing.

---

127-127: Network URL constant updated in fork configuration

The fork network URL was updated to use Sepolia testnet, which is consistent with the import change on line 15.

---

179-179: Updated to deploy_v3 method

The deployment method has been updated from deploy_v1 to deploy_v3 as part of the migration to newer API versions.

---

197-197: Updated to execute_v3 method

The execution method has been updated from execute_v1 to execute_v3 as part of the migration to newer API versions.

---

167-173:

Details

✅ Verification successful

Upgraded to declare_v3 with gas estimation parameters

The code has been migrated from declare_v2 to declare_v3 with additional gas estimation multiplier parameters. The multiplier values are set to 1.0 (no effect), which appears to be added for API compatibility.

---

🏁 Script executed:

#!/bin/bash
# Check if there are other examples of these multipliers in the codebase
rg -A 1 "gas_estimate_multiplier\(1\.0\)" --type rust

Length of output: 778

---

Action: Verified usage of gas estimation multipliers across integration tests

The migration to declare_v3 with additional gas estimation multiplier parameters has been confirmed. The gas_estimate_multiplier(1.0) and gas_price_estimate_multiplier(1.0) are consistently applied in other integration tests (e.g., tests/integration/test_estimate_fee.rs and tests/integration/get_transaction_by_hash.rs), indicating that these parameters are intentionally set to 1.0 for API compatibility without impacting gas calculations.

tests/integration/get_transaction_receipt_by_hash.rs (9)

7-9: Updated imports to support new transaction types

Added new import types related to transaction finality status and execution results to support the enhanced transaction receipt validation.

---

36-37: Upgraded to declare_v3 method

Updated from declare_v2 to declare_v3 as part of the migration to the newer API version.

---

61-62: Updated to deploy_v3 with gas estimation multiplier

The deployment method has been updated to use deploy_v3 with a gas estimation multiplier of 1.0. The multiplier doesn't affect calculations but maintains consistency with the API.

---

63-64: Improved fee estimation approach

The fee estimation has been updated to directly call estimate_fee() on the deployment object, which is a cleaner approach than the previous implementation.

---

87-95: Upgraded to execute_v3 method

Execution method has been updated from execute_v1 to execute_v3 as part of the migration to the newer API version.

---

106-107: Added finality status assertion

New assertion checks that the transaction finality status is AcceptedOnL2, enhancing the validation of transaction receipts.

---

141-148: Added explicit gas parameter configuration

Added specific gas parameters (l1_gas, l1_data_gas, l2_gas) for deployment, providing finer control over gas usage for the transaction.

---

167-170: Enhanced execution resource validation

Added assertions to verify that consumed gas does not exceed specified limits for l1_gas, l1_data_gas, and l2_gas, improving test robustness.

---

202-208: Improved transaction fee handling

Updated from using a single max fee to specific gas parameters for different gas types (l1, l2, data), providing more granular control over transaction costs.

tests/integration/test_v3_transactions.rs (14)

10-10: Removed NonZeroFelt from imports

The NonZeroFelt type has been removed from imports, likely because it's no longer needed with the new gas handling approach.

---

22-23: Added LocalFee to imports

Added LocalFee to the imports, which is used for more structured handling of gas parameters in the updated code.

---

100-100: Updated to execute_v3 method

Execution method has been updated to use execute_v3 as part of the migration to the newer API version.

---

235-235: Improved fee handling with LocalFee struct

Updated fee estimation to use the structured LocalFee type, providing better organization of gas parameters.

---

239-245: Enhanced declaration with specific gas parameters

Updated the declaration to use specific gas parameters for different gas types instead of a single max fee, allowing for more precise control.

---

328-330: Structured gas parameter handling with LocalFee

Replaced the previous fee calculation with the LocalFee struct, which provides a more organized approach to handling different gas parameters.

---

332-337: Updated gas testing scenarios

Improved test cases for gas units and prices, including edge cases like zero values and combinations of insufficient gas units and prices.

---

341-349: Enhanced declaration configuration with granular gas parameters

Updated declaration configuration to use specific gas parameters for different gas types, allowing for more precise control in testing.

---

350-352: Updated error handling for insufficient resources

Error handling has been updated to check for InsufficientResourcesForValidate instead of InsufficientMaxFee, reflecting changes in how transaction validation works in the newer API.

---

357-364: Enhanced account deployment with granular gas parameters

Updated account deployment to use specific gas parameters for different gas types, providing more precise control over gas usage.

---

365-369: Updated error handling for insufficient resources in account deployment

Error handling has been updated to check for InsufficientResourcesForValidate instead of a previous error type, aligning with the new validation approach.

---

374-381: Enhanced execution configuration with granular gas parameters

Updated execution configuration to use specific gas parameters for different gas types, allowing for more precise control in testing.

---

394-394: Updated error message assertion

Error message assertion has been updated to check for "Insufficient max L2Gas" instead of a previous message, reflecting changes in error handling.

---

400-403: Updated error handling for execution with insufficient resources

Error handling has been updated to check for InsufficientResourcesForValidate instead of a previous error type, maintaining consistency with other error handling changes.

tests/integration/get_transaction_by_hash.rs (8)

11-13: Updated constants import

Changed the imported constant from CAIRO_0_ACCOUNT_CONTRACT_HASH to CAIRO_1_ACCOUNT_CONTRACT_SIERRA_HASH, indicating a migration to newer contract versions.

---

20-20: Updated test function name for v3 API

Function name updated from get_declare_v2_transaction_by_hash_happy_path to get_declare_v3_transaction_by_hash_happy_path to reflect the API version change.

---

36-37: Upgraded to declare_v3 method

Updated from declare_v2 to declare_v3 as part of the migration to the newer API version.

---

52-53: Updated contract hash to newer version

Changed the contract hash from CAIRO_0_ACCOUNT_CONTRACT_HASH to CAIRO_1_ACCOUNT_CONTRACT_SIERRA_HASH, indicating a migration to newer contract versions.

---

61-61: Updated to deploy_v3 with gas estimation multiplier

The deployment method has been updated to use deploy_v3 with a gas estimation multiplier of 1.0, which maintains API compatibility.

Was this multiplier added on purpose? Since it's set to 1.0 (no multiplication effect), it appears to be for API compatibility, but if it's intended to affect gas calculations, a different value might be needed.

---

63-63: Simplified fee estimation approach

Updated fee estimation to directly call the method on the deployment object, providing a cleaner approach.

---

74-74: Updated test function name for v3 API

Function name updated from get_invoke_v1_transaction_by_hash_happy_path to get_invoke_v3_transaction_by_hash_happy_path to reflect the API version change.

---

87-95: Upgraded to execute_v3 method

Execution method has been updated from execute_v1 to execute_v3 as part of the migration to the newer API version.

tests/integration/common/background_devnet.rs (3)

29-29: New constant reference for STRK.
Good replacement of the old ETH constant with STRK_ERC20_CONTRACT_ADDRESS. This aligns with the PR objective of switching from ETH to STRK.

---

256-256: Updated contract address to STRK.
Changing contract_address to STRK_ERC20_CONTRACT_ADDRESS is consistent with the switch to STRK. Ensure that any leftover references to the old address have also been updated.

---

223-226: 💡 Verification agent

🧩 Analysis chain

Confirm consistent usage of FRI when minting.
The newly introduced doc comment and the FeeUnit::Fri call correctly indicate that minting uses FRI units. Verify that no other minting calls are still using Wei to avoid confusion.

---

🏁 Script executed:

#!/bin/bash
# Checking for any references to `mint(` calls using Wei or another unit
rg -A 2 "mint\(" | rg "FeeUnit::Wei"

Length of output: 36

---

I'll run an additional search to double-check for any references to FeeUnit::Wei across the repository.

If the output of this command returns nothing, it confirms that there are no remaining minting calls using Wei; minting now consistently uses FRI (via FeeUnit::Fri). Please verify the command output to ensure that no results are returned.

FRI Minting Usage Confirmed
• Verified that mint calls only use FeeUnit::Fri, ensuring consistency in using FRI.
• No other minting calls using Wei were detected.

---

🏁 Script executed:

#!/bin/bash
# Perform a repository-wide search to look for any usage of FeeUnit::Wei
rg "FeeUnit::Wei"

Length of output: 1363

---

Consistent FeeUnit Usage Required in Minting Tests
The mint function in tests/integration/common/background_devnet.rs now correctly uses FeeUnit::Fri; however, a repository-wide search revealed that at least one mint call in tests (e.g., in tests/integration/test_account_selection.rs) still uses FeeUnit::Wei. Please review these test cases and update them to use FRI—or if the difference is intentional, clearly document why minting in tests differs from production usage.

• Confirm that all minting operations (especially in test files) use FeeUnit::Fri to maintain consistency.
• For cases where FeeUnit::Wei is still used (e.g., mint calls in test_account_selection.rs), either update to FRI or add clarifying documentation.

tests/integration/test_restart.rs (4)

13-13: Switching import to STRK.
Replacing ETH_ERC20_CONTRACT_ADDRESS with STRK_ERC20_CONTRACT_ADDRESS looks correct.

---

61-61: Using STRK in storage retrieval.
Retrieving storage from STRK_ERC20_CONTRACT_ADDRESS now matches the new token. This aligns well with the rest of the changes.

---

91-93: Increased mint amount and new account deployment method.
Switching to .deploy_v3(...) with explicit gas parameters and using 1e21 as the mint amount is consistent with the new testing logic. Verify that tests still pass under high minted values.

---

118-169: Expanded gas price checks for multiple gas types.
Your changes now test distinct L1, L2, and data gas prices and confirm they persist through restarts. This is a comprehensive approach enabling targeted verification of each type of gas price. Good job ensuring they're distinct and verifying them before and after the restart.

crates/starknet-devnet-core/src/error.rs (8)

1-1: Imported stack-trace helper methods.
The addition of gen_tx_execution_error_trace and ErrorStackSegment import sets up for rich error handling.

---

21-26: Introducing ContractExecutionError fields in Error enum.
The new enum variants provide clear separation between normal contract errors (ContractExecutionError) and simulation-specific errors (ContractExecutionErrorInSimulation). This refactor should improve maintainability.

---

134-134: Delegating unhandled execution errors to ContractExecutionError.
Forwarding TransactionExecutionError to ContractExecutionError ensures consistent error representation across the codebase.

---

205-212: Top-level ContractExecutionError enum.
Having a central enum with a nested variant + message variant allows a robust recursive structure of contract call failures.

---

214-218: From conversion.
This pattern is helpful for quickly wrapping simple error strings. Good job keeping it minimal.

---

220-230: From transformation.
Using gen_tx_execution_error_trace to build a stack trace before conversion is an excellent way to keep error details consistent without duplicating logic.

---

328-374: Collecting failed calls in impl From<&CallInfo> for ContractExecutionError.
Iterating over recursively nested CallInfo structures to identify failures is well-structured. Nicely done ensuring that each error is reflected in the final recursive error.

---

377-663: New test module for error handling.
The thorough set of test code here effectively validates the conversion logic from stack traces and call infos into structured error objects. Ensuring that each error frame is reflected in the output will greatly reduce debugging overhead in the future.

tests/integration/test_old_state.rs (12)

3-6: No major concerns about new imports.
The newly imported constants and types are used consistently throughout the file.

---

10-12: Imported v3 transaction types.
Using version 3 transaction types and related structures is consistent with the broader changes in this PR. No issues found.

---

98-98: Switched default fee unit to Fri.
This aligns with the PR objective of updating the default unit to FRI. Implementation looks correct.

---

114-116: Doc comment addition.
Adding a doc comment clarifies the purpose of the test regarding revert scenarios.

---

144-151: Using .declare_v3.
The shift to .declare_v3 with .send().await.unwrap() fits the new transaction model. Just ensure that any dependent code calls match this method’s updated signature.

---

155-169: Building a query call with resource bounds.
Encapsulating BroadcastedInvokeTransactionV3 creation in this closure is neat. No concerns regarding the test setup.

---

175-179: Zeroed resource bounds for testing.
Providing zero resource bounds effectively verifies error and behavior in edge cases. Looks appropriate for test coverage.

---

190-204: Utilizing default devnet constants in simulation.
Applying DEVNET_DEFAULT_L1_GAS_PRICE, DEVNET_DEFAULT_L1_DATA_GAS_PRICE, and DEVNET_DEFAULT_L2_GAS_PRICE helps maintain consistent configuration across tests.

---

209-210: Constructing a dynamic error message.
Using to_fixed_hex_string() for the class hash is a clear and readable approach.

---

213-214: Comment block only.
No changes to functionality; skipping additional remarks.

---

218-240: Nested error verification.
Thoroughly checks multi-level call failures with extract_nested_error and extract_message_error. Implementation looks solid.

---

247-249: Revert reason matches expected error.
Ensuring the revert’s reason ends with the expected message completes the test’s objective properly.

tests/integration/test_call.rs (9)

1-1: New import for assert_contains.
No issues found; the usage aligns with other test utilities.

---

3-5: New imports from starknet_rs_core.
Bringing in ContractErrorData and related types is consistent with the nested error handling approach.

---

11-12: Added Cairo 1 contract paths.
Introducing constants for Cairo 1 contracts supports new test scenarios. No concerns.

---

15-15: Imported utility functions.
declare_v3_deploy_v3, deploy_v3, extract_message_error, and extract_nested_error usage aligns with the new error extraction flow.

---

67-72: EntrypointNotFound handling for Cairo 0 contract.
This match statement ensures the appropriate error is raised. Correct approach for verifying non-existent entry points.

---

77-82: Spawning devnet with Cairo 0 account class.
Specifying --account-class extends coverage for older contract types. Looks fine for integration tests.

---

100-106: EntrypointNotFound handling for Cairo 1 contract.
Again verifying proper error for a non-existent method. Implementation as expected.

---

127-127: Deploying a second contract with deploy_v3.
Straightforward usage. No issues flagged.

---

145-163: Nested revert error checks.
Demonstrates correct usage of extract_nested_error and extract_message_error for multi-level panic verification.

tests/integration/common/utils.rs (16)

19-22: Added references to new types.
No issues found. These imports are needed for the new resource-bounded transactions.

---

23-24: Importing UdcUniqueSettings.
Integrates custom deployment settings for deploy_v3. Implementation looks consistent.

---

35-37: Introducing UDC_CONTRACT_ADDRESS.
Used by the universal deployer contract references. No concerns.

---

247-249: New deploy_v3 function.
Provides a clearer, versioned approach to contract deployment. Implementation is concise and appropriate for test usage.

---

308-310: Specifying only L1 gas (repeat concern).
This mirrors a previous remark from past reviews: consider whether you also need to specify L2 gas or data gas here.

---

319-321: Only L1 gas usage once more.
Reiterating the possibility that additional gas parameters might be required.

---

348-350: Again only L1 gas.
Same observation applies, referencing the past question about broader gas parameter coverage.

---

359-361: Continuing with L1 gas specification only.
Likewise, verify if L2 gas constraints are needed for these tests.

---

389-390: deploy_v3(salt) usage.
Standard flow, no new concerns.

---

392-392: Minting with u128::MAX.
Large mint amount appears intentional for stress or overflow testing. No issues.

---

414-415: Argent account deploy_v3(salt).
Effects are analogous to other deploy_v3 calls. Looks correct.

---

417-417: Minting maximum tokens again.
Repeats the stress test approach. No concerns.

---

467-473: extract_message_error.
Clean helper function for extracting the top-level message. Panics on unexpected variants, suitable for test code.

---

475-481: extract_nested_error.
Complements the message extraction by handling nested errors. Useful for in-depth debugging.

---

591-619: Defining LocalFee struct.
A neat way to store multiple gas parameters and map them to ResourceBoundsMapping. No issues found.

---

620-646: Conversion from FeeEstimate to LocalFee.
Unwrapping byte slices may panic on malformed data, but this is likely acceptable for test scenarios. Implementation otherwise correct.

tests/integration/test_fork.rs (1)

139-139: Looks consistent with the new FRI usage.
This change aligns with the PR’s objective of using FRI as the default fee unit.

tests/integration/test_estimate_fee.rs (47)

4-4: New import for ENTRYPOINT_NOT_FOUND_ERROR_ENCODED.
It’s used later for error validation and looks correct.

---

11-13: Additional imports for extended transaction types.
References to ResourceBoundsMapping, TransactionExecutionErrorData, etc. are properly used below.

---

18-18: HttpTransport import recognized.
Allows correct instantiation of the JSON RPC client.

---

29-29: Added imports for local test utilities and LocalFee.
These utility imports appear correct and used for test coverage.

Also applies to: 31-31

---

36-38: Fee summation logic looks correct.
Summing l1_data_gas_consumed, l2_gas_consumed, and l1_gas_consumed multiplied by their prices is logically consistent.

---

62-62: Using deploy_v3 with gas multipliers.
Declaring deployment and setting multipliers to 1.0 for a straightforward test scenario.

Also applies to: 65-67

---

77-78: LocalFee approach for fee estimation.
Creating a LocalFee from the estimate before testing insufficient resource bounds is well structured.

---

80-83: Testing insufficient resource bounds on deploy_v3.
Calling .l1_data_gas(...), .l1_gas(...), and .l2_gas(...) efficiently checks error handling.

---

89-89: Capturing InsufficientResourcesForValidate error.
Appropriate error handling for resource-bound failures.

---

95-97: Increased gas multipliers to ensure success.
This addresses the insufficient fee scenario in a straightforward manner.

---

122-122: Deploying v3 account for invalid class hash.
The call structure to deploy_v3(salt) is consistent with the updated approach.

---

124-133: Validating TransactionExecutionError for undeclared class.
The assertion confirms that the correct error is produced when class hash is missing.

---

140-140: Introduce estimate_fee_of_declare_v3 test function.
A direct test for the new declare transaction version.

---

164-167: Setting gas estimation multipliers on declare_v3.
Ensures consistent resource usage across repeated calls.

---

176-177: Using LocalFee before testing resource bounds.
Makes the subsequent insufficient gas scenario more natural to handle.

---

179-183: Applying insufficient resource bounds on declare_v3.
Helps confirm correct error handling mechanisms.

---

188-188: InsufficientResourcesForValidate error check.
Matches the expected Starknet error outcome.

---

195-199: Ensuring success via resource multiplier.
Increasing .l1_gas, .l1_data_gas, and .l2_gas by 1.1 is a valid approach.

---

226-227: Declaring V3 contract with zero nonce.
Reflects consistent usage of the updated transaction version.

---

254-254: Estimating fee for an invoke V3 call.
Demonstrates the new approach of calculating fees in invoke scenarios.

---

264-264: Comment clarifies insufficient resource bounds test.
Good to maintain clarity on the test purpose.

---

266-268: Gas multipliers intentionally set below 1.0.
Simulates the underfunded transaction path.

---

279-279: Asserting “Insufficient max L2Gas” reversion.
Accurately checks the correct error message.

---

283-292: Sufficient resource bounds for successful invoke.
Ensures the transaction goes through with a higher gas allocation.

---

319-319: Declaring panicking contract.
No concerns; logic is in line with the newly introduced test scenario.

---

333-333: Deploying panicking contract with deploy_v3.
Matches the approach used elsewhere in this file.

---

339-339: Assigning custom panic reason.
Useful for verifying correct retrieval of panic messages.

---

342-342: Passing the panic reason in calldata.
Ensures the correct fail path test for contract invocation.

---

345-346: Executing V3 call for the panic scenario.
Correct approach to validate error extraction.

---

355-355: Indexing transaction at zero.
Consistent with typical test flows for the first transaction in a batch.

---

361-364: Layered error extraction approach.
Effectively drills down to the final panic message.

---

410-410: Setting expected version for query.
Properly referencing the offset plus 3.

---

417-417: Estimation toggles query behavior.
Ensures no side effects but still calculates the fee.

---

423-423: Function to broadcast invoke V3 for final fee estimation.
Neatly encapsulates the preparation logic into a helper function.

---

434-435: Execution prepared but fee line commented out.
Likely intentional for demonstration or debugging of the resource bounds.

---

437-437: Resource consumption and prices set to zero.
This is presumably a test scenario to confirm minimal bounds.

Also applies to: 439-439, 441-441, 443-443, 445-445, 447-447

---

454-462: Chain method calls to set every resource bound to zero.
Demonstrates complete manual control over transaction resources.

---

467-492: Constructing a BroadcastedInvokeTransactionV3 with zero resource bounds.
Correctly populates all fields, including paymaster_data and nonce_data_availability_mode.

---

523-528: Passing zero bounds on a declare_v3 transaction.
Maintains consistency with the test logic used for the invoke scenario.

---

541-562: Combining a Declare V3 with an Invoke broadcast for fee estimation.
Tests multi-transaction fee estimation thoroughly.

---

606-606: First broadcasted_invoke_v3_for_estimation call.
Ensures partial transaction set is properly tested.

---

620-620: Second broadcasted_invoke_v3_for_estimation call.
Valid test coverage for subsequent transactions in the batch.

---

642-642: Confirming transaction_index == 1.
Ensures we identify the second transaction as the failing one.

---

643-645: Error message matches ENTRYPOINT_NOT_FOUND_ERROR_ENCODED.
Precisely corresponds to the newly imported constant.

---

675-675: Setting l1_data_gas bound to zero.
Maintains the pattern established in these tests.

---

700-713: Building BroadcastedDeclareTransactionV3 in a multi-tx scenario.
All fields are correctly set for a query transaction.

---

714-717: Adding the second broadcasted transaction as an Invoke V3.
Confirms a multi-transaction estimate flow with repeated resource bounds usage.

crates/starknet-devnet-core/src/starknet/mod.rs (5)

76-76: Updated error handling imports.

The import has been updated to include the ContractExecutionError type from the error module, indicating a restructuring of the error handling system.

---

145-150: Enhanced gas price management in block initialization.

The next_block_gas structure has been expanded to include STRK-related gas price fields (gas_price_fri and data_gas_price_fri), completing the gas price tracking capabilities for both WEI and FRI currencies.

---

327-334: Added L2 gas price configuration to pending block.

The L2 gas price values for both WEI and FRI are now explicitly set in the pending block header, ensuring complete gas price information is available for transactions.

---

739-748: Simplified error handling in contract calls.

The error handling logic in the call method has been streamlined. The function now directly wraps execution errors in a ContractExecutionError, eliminating the need for intermediate error trace generation through gen_tx_execution_error_trace.

---

750-755: Improved specific error handling for contract execution failures.

The error handling for failed contract executions has been enhanced to distinguish between EntrypointNotFound errors and general ContractExecutionError cases, providing more precise error reporting to clients.

tests/integration/test_trace.rs (12)

3-5: Updated imports to use STRK ERC20 contract address.

The import has been changed to use STRK_ERC20_CONTRACT_ADDRESS instead of ETH_ERC20_CONTRACT_ADDRESS, reflecting the transition from WEI to FRI as the default fee token.

---

14-14: Added utility import for selector name resolution.

The get_selector_from_name utility has been imported to generate function selectors in a standardized way, improving code readability and reducing potential for errors.

---

23-24: Updated test constants to use Felt type and increased amount.

The DUMMY_ADDRESS constant has been changed from a numeric value to a Felt type with a hex value, and DUMMY_AMOUNT has been increased from 1 to 456, providing more realistic test values.

---

32-51: Enhanced mint invocation assertions to match updated implementation.

The test has been updated to verify the exact structure of mint transaction calldata, checking for:

1. The STRK ERC20 contract address instead of ETH
2. The correct selector for "transfer" function
3. The proper structure of calldata arguments including amount representation

This ensures the tests correctly validate the updated implementation.

---

55-57: Updated fee transfer assertion to use STRK contract.

The fee transfer assertion now verifies that transfers use the STRK ERC20 contract address instead of ETH, aligning with the protocol's switch to STRK as the primary fee token.

---

59-61: Added execution resources validation to trace test.

New assertions verify the correct gas usage pattern:

• L1 gas should be zero
• L1 data gas should be positive
• L2 gas should be positive

This ensures the gas computation model is working as expected.

---

118-122: Migrated to V3 transaction declaration with explicit gas parameters.

The test now uses declare_v3 instead of an earlier version, with explicit parameters for:

• L1 gas (set to 0)
• L1 data gas (set to 1000)
• L2 gas (set to 10^8)

This update aligns with the protocol's evolution to more granular gas handling.

---

149-150: Updated fee transfer check to use STRK contract.

The test now verifies that the fee transfer in the declaration trace uses the STRK ERC20 contract address, consistent with the switch from ETH to STRK as the primary fee token.

---

174-178: Migrated contract declaration to V3 with explicit gas parameters.

Similar to other declaration updates, this test now uses declare_v3 with explicit L1 gas, L1 data gas, and L2 gas parameters, ensuring compatibility with the updated transaction structure.

---

187-191: Updated contract deployment to use V3 with explicit gas parameters.

The test now uses deploy_v3 with explicit gas parameters for all three gas types, matching the updated contract deployment interface and gas handling model.

---

239-246: Updated account deployment to use V3 with explicit parameters.

The account deployment test now:

1. Uses deploy_v3 with explicit gas parameters
2. Sets a nonce value
3. Mints STRK to the new account before deployment
4. Captures the deployment result in a more structured way

These changes reflect the updated account deployment workflow and requirements.

---

271-272: Updated fee transfer assertion in deployment trace.

The test now verifies that the fee transfer in the deployment account trace uses the STRK ERC20 contract address, aligning with the switch to STRK as the primary fee token.

tests/integration/test_simulate_transactions.rs (16)

5-16: Importing STRK constants and Broadcasted structures*
These added imports from starknet_core::constants and the Broadcasted* transaction variants align well with the upgraded API usage (v3 transactions, STRK token, etc.). No issues found.

---

26-28: Updated references to CAIRO_1 constants
These lines add or rename constants for Cairo 1 contract paths and related variables. Everything appears consistent with the new naming scheme.

---

33-35: Added references to new utility methods and LocalFee
Introducing get_flattened_sierra_contract_and_casm_hash and LocalFee is consistent with the v3 fee approach. Implementation details for these utilities aren’t shown here, but usage seems coherent.

---

39-114: Refactored simulate_declare_v3 function

1. Switching to .declare_v3(...) with LocalFee usage, resource bounds, and setting gas parameters (lines 57–65) follows the new fee model. This ensures better granularity but verify all call sites are updated for signature consistency.
2. Adding simulation flags (SKIP_FEE_CHARGE, etc.) in lines 101–109 is correct for test scenarios.
3. Resource bounds mapping in lines 89–94 looks fine, but ensure large or edge values are handled gracefully.

Overall, this function is well-structured and properly tests the new v3 transaction flow.

---

123-146: simulate_deploy_account with v3 deployment support

1. Declaring an account factory for Cairo 1 (line 123) is consistent with the new approach; ensure older references to v1/v2 deployments are fully removed or migrated.
2. Gathering fee estimates (lines 133–134) and applying .l1_gas(...), .l2_gas(...), etc. (lines 138–143) aligns with the new LocalFee config.
3. Checking the updated contract address matches STRK_ERC20_CONTRACT_ADDRESS (line 194) reaffirms the switch to STRK for fee token usage.

Implementation looks sound.

Also applies to: 194-194

---

238-360: simulate_invoke_v3 improvements

1. Using .execute_v3(...) and LocalFee for gas configuration (lines 280–283) ensures uniform handling of L1/L2 gas.
2. Manually setting nonce (line 280) to handle sequential transactions is okay for test environments. Confirm other test methods remain consistent with the new nonce approach.
3. Resource bounds in lines 303–315 match the pattern in simulate_deploy_account.

No issues detected.

---

392-426: Query version logic (simulate with query offsets)

1. Checking version behavior with .execute_v3 plus verifying resource bounds usage (lines 395–402) is correct.
2. The non-trivial offset QUERY_VERSION_OFFSET + Felt::THREE (line 388) is presumably tested here for boundary conditions.

Implementation looks correct for mocking version behaviors.

---

431-492: simulate_of_panicking_invoke

1. This test specifically checks for revert reasons (lines 487–488) when a contract panics. Good coverage for failure scenarios.
2. The direct usage of json_rpc_client.get_block_with_tx_hashes(...) to fetch gas_price from the latest block (lines 455–468) could be combined with standard estimate_fee calls for consistency, but it’s still acceptable for advanced tests.

No major concerns.

---

495-582: simulate_of_multiple_txs with a failing transaction

1. Broadcasting multiple v3 transactions (lines 542–568) and verifying that a revert in one transaction doesn’t break the entire simulation is crucial. The logic is valid.
2. The partial revert check (lines 576–580) is well-structured.

Looks good.

---

585-620: test_simulation_of_multiple_txs_should_return_index_of_first_failing_transaction

1. The custom transaction_index error field (line 668–672) is a neat way to identify the failing transaction.
2. Confirm that indexing logic in external code is consistent with this test’s expectations.

Implementation is straightforward; no issues found.

---

677-718: simulate_with_max_fee_exceeding_account_balance_returns_error

1. Lines 694–704 intentionally set extremely high gas amounts to trigger insufficient balance. This thoroughly tests fee-check logic.
2. The fallback scenario .simulate(false, true) skipping fee transfer is verified.

Implementation aligns with the new fee-charging model.

---

721-887: simulate_v3_with_skip_fee_charge_deploy_account_declare_deploy_via_invoke
This end-to-end test covering (1) deploy account, (2) declare, (3) invoke, all with skip-fee logic, is a solid integration scenario. The code is quite extensive but appears logically consistent with the new approach.

---

890-942: simulate_invoke_v3_with_fee_just_below_estimated

1. Good demonstration (lines 927–933) of a carefully chosen l2_gas just under the estimate to cause an “Insufficient” revert.
2. This ensures accurate boundary testing for resource limits.

Code is correct and thorough in testing partial coverage of gas.

---

945-1071: simulate_invoke_declare_deploy_account_with_zero/bad gas settings

1. Zero or partial gas config is tested (lines 992–1071) which is critical for edge cases.
2. The uniform error “Insufficient resources” (lines 1062–1067) is appropriate.

No issues found.

---

1086-1123: simulate_invoke_v3_with_failing_execution
Verifies revert trace capturing (lines 1107–1115). This is consistent with other panic tests.

---

870-917: withdrawing_should_incur_l1_gas_cost

1. The fee estimation check (lines 889–893) ensures L1/L2 resource usage is non-zero.
2. The final transaction revert on insufficient L1Gas (lines 910–915) is a valid negative test scenario.

Implementation of gas checks looks correct.

tests/integration/test_messaging.rs (10)

43-46: New constants for dummy addresses and message opcode
Replacing string-based addresses with Felt to unify type usage is a good move for consistency. No direct issues.

---

48-49: Comment clarifications for reliance on whitelisted L1 address
This clarifies address usage differs from older Cairo 0 contracts. No concerns.

---

51-66: Refactored withdraw function to return Result

1. Lines 58–59 switch the function to return a Result<InvokeTransactionResult, AccountError<...>>, making error handling more explicit.
2. Using .execute_v3(invoke_calls).send() (line 65) is consistent with the new v3 flow.

This is a solid improvement for error transparency.

---

81-89: Updated increase_balance with L1/L2 gas parameters
Explicitly setting .l1_gas(0), .l2_gas(5e7), etc. ensures correct limit testing. This is beneficial for coverage.

---

183-212: assert_withdrawn helper function

1. Verifies the user’s balance is zero (line 190) and checks the dry-run postman output includes the expected message payload (lines 193–203).
2. The usage of MESSAGE_WITHDRAW_OPCODE, user, amount ensures no confusion with the older approach.

Implementation is well-structured.

---

215-231: can_send_message_to_l1

1. Using the new dummy L1 address and withdraw call (line 229) to produce an L2→L1 message is logically correct.
2. Verifying the final assert_withdrawn (line 230) ensures thorough coverage.

All logic is consistent with the updated approach.

---

254-275: can_send_message_to_l1_from_library_syscall

1. The call to withdraw_from_lib(...) (line 263) reuses similar v3 patterns, now referencing lib_sierra_class_hash.
2. The final assert_withdrawn ensures the message is properly recognized.

No issues noted.

---

355-366: can_consume_from_l2
Setting DUMMY_L1_ADDRESS (line 361) and withdrawing with v3 calls (line 364) looks correct. Ensuring zero balances (line 365) is good final verification.

---

507-507: test_dumping_of_non_rpc_requests (partial changes)
These lines (507,509,511–514) are not directly relevant to messaging logic but clarify the mint call’s new signature (json!({ "address": address, "amount": mint_amount, "unit": unit })). Confirm the updated approach is consistent across all calls.

Also applies to: 509-509, 511-514

---

870-917: withdrawing_should_incur_l1_gas_cost in messaging tests
(Note: This line range also appears in the prior file, but within test_messaging.rs snippet it’s line 869–917? Possibly an artifact. If referencing the final snippet lines 869–917 in test_messaging.rs:)

No changed lines are shown here beyond the snippet boundary. If you intended lines 869–917 in this file, no code is visible in the snippet. If an overlap occurred, please verify the changes are properly tested for L1 gas usage in the messaging context.

tests/integration/test_dump_and_load.rs (7)

83-85: Switched to FeeUnit::Fri
Changing balance queries to use FeeUnit::Fri (line 83) presumably reflects the minted STRK usage. Ensure all relevant calls also adopt Fri consistently across tests to avoid mismatched currency units.

---

373-414: dump_load_endpoints_transaction_and_state_after_load_is_valid

1. The code retrieves balance with get_balance_latest(..., FeeUnit::Fri) (line 404) to ensure loaded state is correct.
2. Checking transaction validity after load (lines 408–413) is an excellent integration step.

No concerns.

---

247-265: declare_deploy with v3 transactions

1. Lines 247–251 show calls to .declare_v3(...).l1_data_gas(...) etc. verifying new usage.
2. The subsequent .deploy_v3(...) block (lines 261–265) is consistent with the updated deploy approach.

Implementation is straightforward.

---

407-413: Verifying loaded mint transaction

1. Checking the minted transaction after load ensures the devnet state matches prior run.
2. The InvokeTransaction::V3 pattern is correct.

Looks good.

---

505-517: test_dumping_of_non_rpc_requests
Although primarily a coverage for non-RPC calls, lines 507 and onward demonstrate the updated “mint + create_block + abort_block” flow. The final dump then replays the correct disk state. Good thorough test.

---

546-548: Loaded balance check
The assertion at line 547 verifies that the minted balance (in Wei or Fri) is persisted properly after a dump/load cycle. No issues.

---

563-569: Dumping after restart
Ensures that on reload (line 566), no leftover data is incorrectly dumped. The check at line 569 for empty output is correct.