You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 22, 2024. It is now read-only.
I'm forwarding a message from @kkovaacs :
"starknet_in_rust uses the ContractClass type from cairo-lang-starknet when creating a Declare v2 transaction. Unfortunately the JSON representation for that type isn’t quite the same as the one used on Starknet.
The ABI is defined as a string on Starknet to avoid the issue of the class hash depending on the exact method of JSON-serializing the ABI data structure. However, the ContractClass type contains a parsed representation of the ABI which is then transformed back to string when starknet_in_rust is doing class hash calculation."
This leads to potencial hash mismatches.
The starknet_estimateFee call fails with starknet_in_rust because the class hash miscalculation leads to an invalid transaction hash, which then fails signature check...
I'm forwarding a message from @kkovaacs :
"
starknet_in_rust
uses the ContractClass type fromcairo-lang-starknet
when creating a Declare v2 transaction. Unfortunately the JSON representation for that type isn’t quite the same as the one used on Starknet.The ABI is defined as a string on Starknet to avoid the issue of the class hash depending on the exact method of JSON-serializing the ABI data structure. However, the ContractClass type contains a parsed representation of the ABI which is then transformed back to string when
starknet_in_rust
is doing class hash calculation."This leads to potencial hash mismatches.
Thanks @kkovaacs for the report.
The text was updated successfully, but these errors were encountered: