v3 transactions & RPC 0.10: old fee-based scripts fail (Missing gas_price / gas_consumed)

[newtgh]

What happened

After Starknet upgrades (v3 transactions, RPC 0.9/0.10),
pre-v3 starknet-py scripts can no longer create transactions.

Transaction creation fails with:
"Missing data for required field: gas_price, gas_consumed"

The same script worked before the Starknet 0.13 / 0.14 upgrades.

Stack trace

Missing data for required field: gas_price, gas_consumed

Steps to reproduce

Context:

• Script was written for pre-v3 StarkNet
• Uses starknet-py to build and send account transactions
• RPC 0.6/0.7 behavior is no longer available
• Ask StarkNet confirmed that fee handling and tx format changed

Questions:

1. Is this expected behavior for pre-v3 scripts?
2. What is the correct current way to estimate fees and build tx v3 in starknet-py?
3. Is there a minimal reference example for sending ETH with RPC 0.10?

I can provide a redacted minimal example if needed.

Thanks.

SDK Version

starknet-py 0.24.2, starknet-py==0.19.0, also tested 0.29.0

Python version

Python 3.10.11 (Windows)

What operating system are you using?

Windows

Is there an existing issue for this?

• I have searched the existing issues and verified no issue exits for this problem.

[franciszekjob]

Hey @newtgh , every starknet.py version supports specified RPC version, e.g. v0.29.0 supports RPC 0.10. The error Missing data for required field: gas_price, gas_consumed comes from the fact that SDK expects different schema than the one returned from node. Please switch to RPC version which is compatible with your starknet.py version.

[newtgh]

Thanks for the clarification.

I found the root cause on my side and want to share detailed diagnostics,
as this might be relevant for Windows users.

Environment:

• OS: Windows 10 x64
• Python: 3.10.11
• starknet-py: 0.29.0
• crypto-cpp-py: 1.4.5

Issue:
On Windows, crypto-cpp-py installs without a native binary (.pyd / .dll).
The package directory contains only Python files:

['cpp_bindings.py', 'utils.py', 'init.py', 'pycache']

Because of that, starknet-py fails during initialization when importing
keccak256, resulting in:

pywintypes.error: (126, 'LoadLibraryEx', 'The specified module could not be found.')

Visual C++ Redistributable (2015–2022, x64) is installed.

This means starknet-py cannot work at all on this setup,
even for basic RPC calls like get_block(),
due to missing native crypto_cpp_py binary.

It looks like there is no available Windows wheel for crypto-cpp-py
for Python 3.10, and pip silently installs a pure-Python package
without the required native extension.

Please let me know if:

1. Windows is currently unsupported for starknet-py due to crypto-cpp-py.
2. There is a recommended workaround (WSL / pure-python backend / pinned versions).
3. A Windows wheel for crypto-cpp-py is planned.

Thanks — happy to provide any additional diagnostics if needed.

[franciszekjob]

@newtgh , did you follow the installation steps for Windows and all the necessary steps https://starknetpy.readthedocs.io/en/latest/installation.html#windows ?

[newtgh]

Yes, I followed the Windows installation guide exactly.

Environment:

• Windows 10 x64
• Python 3.10.11
• Visual C++ Redistributable 2015–2022 installed
• pywin32 installed (win32api import works)

However, crypto_cpp_py installs without a native binary.
The package directory contains only Python files:

['cpp_bindings.py', 'utils.py', 'init.py', 'pycache']

There is no *.pyd file (e.g. crypto_cpp_py.cp310-win_amd64.pyd),
so LoadLibraryEx fails with error 126.

It looks like there is no Windows wheel published for crypto_cpp_py
for Python 3.10+. Could you confirm whether Windows is currently unsupported,
or recommend a pinned Python / version combination that includes a wheel?

[franciszekjob]

@newtgh I need to investigate this and ping you back. For now you can try running it on WSL.

[newtgh]

Thanks for the update!

Just to confirm current status from my side:

• Running the same code on WSL (Ubuntu) works correctly with starknet-py 0.29.0
• On native Windows (Python 3.10 / 3.11), the issue is reproducible and caused by
  crypto_cpp_py missing a Windows binary (.pyd), leading to LoadLibraryEx error 126

This suggests that at the moment:

• Native Windows + starknet-py is effectively unsupported for Python ≥ 3.10
• WSL is the only viable workaround on Windows systems

Could you please clarify:

1. Is native Windows officially unsupported for now?
2. Is there a recommended pinned Python version (e.g. 3.9) that still has a working Windows wheel?
3. Or should users consider WSL / Linux as the supported environment going forward?

I’m happy to test any proposed fix or pinned combination if needed.
Thanks!

[franciszekjob]

@newtgh

1. Is native Windows officially unsupported for now?

It's officially supported - unfortunately you've encountered a bug that we need to fix.

2. Is there a recommended pinned Python version (e.g. 3.9) that still has a working Windows wheel?

Please try v0.28

3. Or should users consider WSL / Linux as the supported environment going forward?

It's the temporary solution until we fix the problem with Windows, will keep you updated about it, thanks for patience

[newtgh]

Title

starknet-py mainnet RPC compatibility issues: Invalid block id / RPC version mismatch (Alchemy v0_10, public RPCs)

Description

Hello Starknet.py team,

I’m running into persistent RPC compatibility issues when using starknet-py 0.27.x on Starknet mainnet.
Despite following the documentation and previous guidance (including issue #1693), I’m unable to make even basic RPC calls reliably.

This is not a production setup, just a very simple local script, but I cannot find any RPC endpoint that works consistently with the expected RPC version.

Environment

• OS: Ubuntu 24.04

• Python: 3.11

• starknet-py: 0.27.0

• Network: Starknet mainnet

• Execution: Docker (python:3.11-slim, clean environment)

• Proxy: HTTP/HTTPS proxy enabled (confirmed working, requests go through)

What I am trying to do

A very minimal and basic flow:

1.Create FullNodeClient

2.Call ERC20 ETH contract balanceOf

3.(Later) send a transfer transaction

No ABI loading, no contract deployment, no advanced features.

Minimal reproducible example

from starknet_py.net.full_node_client import FullNodeClient
from starknet_py.net.client_models import Call
from starknet_py.hash.selector import get_selector_from_name

RPC_URL = "<RPC_ENDPOINT>"

client = FullNodeClient(node_url=RPC_URL)

balance_call = Call(
to_addr="0x049d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7", # ETH
selector=get_selector_from_name("balanceOf"),
calldata=[ACCOUNT_ADDRESS],
)

balance = await client.call_contract(balance_call)

This already fails depending on the RPC used.

RPC endpoints tested
❌ Alchemy (only provides v0_10)
https://starknet-mainnet.g.alchemy.com/starknet/version/rpc/v0_10/<API_KEY>

Result:

1.IncompatibleRPCVersionWarning

2.ClientError: Invalid block id

Example warning:

RPC node uses incompatible version 0.10.0, expected ~0.8.x

❌ Public / community RPCs

Nethermind / Lava

https://rpc.starknet.lava.build

Result:

ClientError: 404 backend NotFound, service rules for the path non-existent

Other public endpoints (Blast, etc.)

1.Either deprecated

2.Or return similar incompatibility / invalid block errors

Observed errors

Most common errors across RPCs:

IncompatibleRPCVersionWarning:
RPC node uses version 0.10.0, expected version ~0.8.x

ClientError: Invalid block id

ClientError: 404 backend NotFound

These happen even for simple call_contract calls, before any transaction execution.

What we already tried

1.Using starknet-py 0.27.x (recommended stable version)

2.Using Python 3.11 in Docker (clean environment)

3.Avoiding ABI resolution

4.Avoiding custom block_id

5.Using multiple RPC providers

6.Following guidance from issue #1693

Despite this, we cannot find a working RPC endpoint compatible with starknet-py 0.27.x on mainnet.

Main question

👉 Which RPC endpoint(s) and RPC version are officially supported and guaranteed to work with starknet-py 0.27.x on Starknet mainnet today?

Because currently:

1.Alchemy only supports v0_10

2.starknet-py 0.27.x expects older RPC behavior

3.Public RPCs appear inconsistent or deprecated

Clear guidance (or confirmation that migration to newer starknet-py versions is required) would be very helpful.

Additional notes

• This is a local script, not infra / node setup

• No ABI, no deployment, no complex transactions

• The issue seems purely RPC compatibility–related

Thank you for your time and for maintaining starknet-py 🙏
Any clarification or recommendation would be greatly appreciated.

[newtgh]

Additional diagnostics after further testing:

Environment:

• OS: Ubuntu 24.04 (WSL2)
• Python: 3.11.14 (venv)
• starknet-py: 0.29.0
• Network: Starknet mainnet
• Transaction type: v3 (invoke)
• Fee token: STRK
• Account type: standard account (Argent X)

What works reliably:

• Read-only RPC calls work consistently:
  • call_contract(balanceOf) for ETH and STRK always succeeds
  • account initialization succeeds
  • signing works (no errors before invoke)

What does NOT work:

• Any write transaction (execute_v3 / invoke) fails to complete:
  • Using Alchemy RPC (v0_10): execute_v3 hangs indefinitely (no tx_hash, no error)
  • Using Nethermind public RPC: DNS resolution fails on my setup (ClientConnectorDNSError)
  • Same behavior with and without HTTP/HTTPS proxy
  • No tx_hash is returned, suggesting invoke never reaches the network

Key observation:

• This appears to be a write-RPC / invoke issue, not a client-side signing or calldata issue.
• The same environment can read state but cannot submit transactions.

Question:

• Is there a currently recommended public RPC endpoint that is confirmed to support invoke tx v3 reliably?
• Is there any known issue with execute_v3 hanging when RPC does not respond to starknet_addInvokeTransaction?

Happy to provide a minimal redacted script if needed.

[newtgh]

Additional note:
The same code path successfully signs the transaction locally.
The hang occurs before receiving tx_hash from starknet_addInvokeTransaction,
suggesting the invoke request is not answered by the RPC.

[franciszekjob]

Hey @newtgh, which provider did you use? Maybe try https://api.zan.top/public/starknet-sepolia/rpc/v0_10

[newtgh]

Thanks for the suggestion!

Just to clarify: my target is mainnet, not Sepolia.
I understand Sepolia is proposed as a diagnostic step to verify execute_v3 behavior.

I’ll try the same code path against Sepolia RPC to check whether invoke tx v3 completes there,
and will report back the result.

[newtgh]

Quick update:

I tested the same setup on Sepolia as suggested.

Environment:

• WSL Ubuntu 24.04
• Python 3.11.14
• starknet-py 0.27.0
• Sepolia network

Result:
Even a simple read-only call (ERC20 balanceOf) fails.

I consistently get:
"IncompatibleRPCVersionWarning: RPC 0.10.0, expected 0.8.1"
followed by:
"ClientError: Invalid block id"

This happens on public Sepolia RPCs (ZAN / Alchemy).
So the issue reproduces even before any invoke/execute_v3 call.

This suggests a general incompatibility between starknet-py and available RPC v0.10 endpoints,
not limited to mainnet.

Please advise on:

• a compatible RPC endpoint, or
• a recommended starknet-py version / workaround for RPC 0.10.

Thanks.

[newtgh]

Hello, please tell me, is there any information?