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
Have you reproduced the bug with the latest dev version?
Yes
Version
v0.5.0
Custom code
Yes
OS platform and distribution
No response
Describe the issue
Right now, it is really confusing to determine when one should use 0x and t4 addresses from the agent. The reason for this is that we use Address throughout all of the IPC agent except when we interact with the ETH RPC. This implies the use of fvm_shared::Address as the underlying type. However, the address used to interact with the subnet, and all the Ethereum tooling, expects a 0x. This leads to many users using their 0x instead of f4 address as arguments. Even our config expects a 0x address for the default accounts in fevm instead of the underlying f4.
A potential implementation could be through a top-level Address wrapper type that can be converted into both f4 and 0x as described in #407.
Repro steps
N/A
Relevant log output
No response
The text was updated successfully, but these errors were encountered:
Issue type
Bug
Have you reproduced the bug with the latest dev version?
Yes
Version
v0.5.0
Custom code
Yes
OS platform and distribution
No response
Describe the issue
Right now, it is really confusing to determine when one should use
0x
andt4
addresses from the agent. The reason for this is that we useAddress
throughout all of the IPC agent except when we interact with the ETH RPC. This implies the use offvm_shared::Address
as the underlying type. However, the address used to interact with the subnet, and all the Ethereum tooling, expects a0x
. This leads to many users using their0x
instead off4
address as arguments. Even our config expects a0x
address for the default accounts infevm
instead of the underlyingf4
.A potential implementation could be through a top-level Address wrapper type that can be converted into both
f4
and0x
as described in #407.Repro steps
N/A
Relevant log output
No response
The text was updated successfully, but these errors were encountered: