This may be sidetracked by a recent addition to Icepick. Icepick has a config format that defines the module path as well as the prefix it allows derivation from.
add a config file for this perhaps so i don't have to hardcode everything within icepick thnak u anton
Currently I've defined the envelope as:
#[derive(Serialize, Deserialize, Debug)]
#[serde(rename_all = "kebab-case")]
pub struct Request {
// NOTE: Can't use the proper XPrv type…
Chain, curve, and derivation path should all be verified out of band (probably within the keyfork-derive-path-data crate) so malicious module code can't say "hey I'm actually bitcoin, give me…
Currently, arguments are either positional and therefore required, or --long-args and therefore optional. However, while writing the SOL transfer, I noticed it gets rather bulky when using…
Keys could also be base64 and take up a lot less space, but would require to/from de/serialization.
Blob parsing has been added. CLI will block if input is not a TTY to read a JSON value containing the output of the previous command. This also means we now have a system to get derived keys that…
Progress update: icepick-solana can now generate SystemProgram transfer transactions. The blob returned contains a JSON serialized blob that should be parseable by the next program. This also…
Repurposing this issue for the module implementation strategy, since the overall goal was to be able to say "here's how we define a standard coin". Coins are implemented using the JSON RPC format…