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
The current version of warp does not provide some utilities for hardhat-warp anymore in the same way. The ones I catched were:
callClassHashScript: Closest one currently seems to be runStarkNetClassHash, and the path here probably needs an artifacts/ first.
warpEventCanonicalSignatureHash: Closest one currently seems to be warpEventCanonicalSignaturehash256, but it's not equivalent as shown by the return type being changed - is now a { low: string; high: string } instead of a string.
Besides this, there was an encoding issue I encountered - on a contract deployment which got an address and a uint as parameters, the expected encoding by the starknet module was [address, [low, high]], not [address, low, high] as would result from this:
Also, is the deployer supposed to be the first signer you get on ethers.getSigners()? It didn't seem to be the case when I tested it. Some tests rely on this and it may be good to keep this as a standard.
The text was updated successfully, but these errors were encountered:
The current version of warp does not provide some utilities for
hardhat-warp
anymore in the same way. The ones I catched were:callClassHashScript
: Closest one currently seems to berunStarkNetClassHash
, and the path here probably needs anartifacts/
first.warpEventCanonicalSignatureHash
: Closest one currently seems to bewarpEventCanonicalSignaturehash256
, but it's not equivalent as shown by the return type being changed - is now a{ low: string; high: string }
instead of astring
.Besides this, there was an encoding issue I encountered - on a contract deployment which got an
address
and auint
as parameters, the expected encoding by the starknet module was[address, [low, high]]
, not[address, low, high]
as would result from this:hardhat-warp/src/transcode/encode.ts
Line 11 in ff87e9d
Calls worked as usual though.
Also, is the deployer supposed to be the first signer you get on
ethers.getSigners()
? It didn't seem to be the case when I tested it. Some tests rely on this and it may be good to keep this as a standard.The text was updated successfully, but these errors were encountered: