Features / Integration / Constraints

• Key Management
  • Support the wallet standard
    • master key and maintain the key paths
  • Support for arbitrary sk’s, not just wallet standard keys.
  • integrate with Key Management Service?
    • Wallet Standard implies sk's are stored in the wallet, should they also be stored in the KMS as well?
• Sync with Cryptarchia
  • update note state based on cryptarchia state (note spent or received in mantle is reflected in wallet)
  • Needs to deal with reorgs gracefully where a note may become unspent if the block in which it's spent is reorged. Functionality
  • Notes go through various states:
    • Unspent-Finalized
      • has not been spent yet, can be spent, will never change state due to reorg
    • Unspent-Unfinalized
      • Unspent, but potentially to become unspendable due to reorgs
    • Unspent-Mempool
      • Unspent note, not yet on the honest chain, can’t be spent until it goes on chain
    • Spent-Unfinalized
      • spent, but potential to become unspent by reorgs
    • Spent-Finalized.
      • spent, has finalized and will never become unspent
  • Careful tracking of these states required to ensure users don’t lose funds.
• Persistance (save secret keys and notes to disk)
  • support for different backends (in-memory vs on-disk)
• Core Wallet Features
  • Ability to spend notes, gracefully recovering from reorgs, support for double signing in the case where a note is used in an impossible transaction
  • Ability to receive notes (either automatically from observing the blockchain or by manually inserting notes in the wallet)
  • Transaction signing using note secret keys

API

• Wallet Standard
  • We can support multiple wallet standard keys in a wallet, OR allow users to create multiple wallet instances.
  • Alternatively, we factor out the wallet standard from the wallet,
  • master_key_gen()
  • child_key(path)
• loading / init wallet from disk
  • load(config)
  • new()
• spending notes
  • spent notes can't be immediately removed from the wallet. But they should be marked as spent but waiting confirmation.
  • mark_spent(note_id)
• receive notes
  • recv_note(note, sk)
    • consider whether we maintain a mapping from the SK to the child_key path (if one exists)
• mantle sync
  • when we receive a mantle block, we should know if we received a note or not.
  • implies that we know the set of addresses that we are receiving for.
  • e.g. when requesting a transfer, we should keep track of address we requested here.
  • exact API depends on where we store our known keys
• Transaction Signing and Transaction building
  • transactions are signed using ZK Signatures, signed by note secret keys.
  • We probably don’t want to couple to the mantle transaction or to the ledger transaction here.
  • Maybe signing becomes a feature of the KMS?
  • Wallet provides an API for collecting together enough notes such that the total value of the collection of notes is larger than the requested amount
    • notes_for_amount(amount) → Vec<Note>
  • Ledger will then need to deal with the output change note and connect it to one of our known keys
• signing of mantle transactions and by extension, approving the ledger transaction
  • API should take an unpayed for mantle transaction and then builds the ledger transaction that will pay for the mantle transaction fees.
• API to build a ledger transaction?
  • deals with collecting enough notes to create the target balance
  • returns change note to self