Output Bech32Address for initial accounts #594
Conversation
| @@ -14,6 +15,9 @@ use serde_with::{serde_as, skip_serializing_none}; | |||
| use serialization::{HexNumber, HexType}; | |||
| use std::{io::ErrorKind, path::PathBuf, str::FromStr}; | |||
|
|
|||
| // Fuel Network human-readable part for bech32 encoding | |||
| pub const FUEL_BECH32_HRP: &str = "fuel"; | |||
There was a problem hiding this comment.
Hmmm. Is there some way to import the SDK instead of duplicating code? If the SDK isn't set up for that, then we can merge as-is then have a follow-up good first issue to clean up.
There was a problem hiding this comment.
I think we can import from the SDK as it is currently declared as public but do we want to depend on the SDK from fuel-core? If that is acceptable, we will need to declare fuels-types as a dependency and after that we can fetch it from there
There was a problem hiding this comment.
The bech32 encoding logic for Address should probably reside in fuel-types.
It's also worth noting that none of the fuel-core GraphQL APIs currently support bech32, so hijacking the output format here for the SDK would make them unusable for local client dev just using the graphql API directly.
We should decide whether base16 or bech32 is the standard encoding for addresses, since this is going to cause more confusion for the foreseeable future.
There was a problem hiding this comment.
@kayagokalp for now, let's just return both hex and bech32 format for the address until we settle on a standard approach.
# Conflicts: # fuel-core/src/chain_config.rs
#594 This change was done at teh same time with moving of this file into another place, so during conflicts resolving we missed it.
…#921) [This change](FuelLabs/fuel-core#594) was done at the same time as moving this file into another place, so during conflict resolution, we missed it. Closes FuelLabs/fuel-core#593
closes #593.