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…
Partially implemented. Need to implement some form of wrapper protocol on the blobs for a blob to import derived keys or export derived paths.
Consideration: Fee payers for SOL/ETH/etc. gas
We need a way to specify multiple derivation paths on the same chain prefix. Should we send a prefix, or should we send multiple derivation…