Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.



  • Capture critical questions about wallet features requirements and as time allows make decisions

Discussion topics




Controversial features

  • History and auditing (Ed)

    • Consideration, could this be done with an ETH address?

  • Which client platforms supported at launch time (Ed)

  • Are multigs supported at launch time? (Ed)

  • Design of how the contracts work? Locker idea (Ed)

  • How Ethereum-friendly will we be? (lower priority, but related to adoption) (Ed)

    • Decisions needed

  • How do we create a wallet for someone not in RChain (REV issuance or just joining w/o Phlo)? Are there any free transactions? How do you bootstrap new users? (Ovidiu, Ed)

    • Recommendation to first answer these questions for REV, and then think about other tokens

  • Review naming convention (wallet, purse, account)

    Jira Legacy
    serverSystem JIRA

REV issuance

  • Requirement to support ETH-style address at launch of Mercury

    • Can we support this requirement and then make a step to move to a design that is different than an ETH-style address?

      • DECISION - this is an acceptable solution (Greg)

    • Do we have to transact REV with an ETH-style address after launch?

      • No, although this would support ease of adoption for users used to ETH-style transactions

      • DECISION - Do support ETH-style address for REV issuance and beyond, and we can support something else

Definition of ETH-style address

  • Truncated hash of the public key

  • Will ETH users be able to provide their public key, receive a truncated hash, and then use it?

  • I can send REV to an ETH-style address

Out of the box (Mercury)

  • With the address you can interact with the wallet contract

    • Idea that the registry implementation can support this

      • Today registry does not support ETH-style address

      • Today registry maps name to contract using different crypto than ETH.

      • QUESTION - do we change registry implementation to support ETH-style?

History and auditing

  • Various levels of audibility

    • 1st level - REV holders need to be able to verify transactions in and out of my wallet to myself, my transaction partner, and any third party

    • 2nd level - A random 3rd party can look at someone else’s wallet and verify transactions

      • Idea there are different classes of wallet classifications and that some wallets support this 2nd level auditability,

        • DECISION we do need to support different classes of wallets

  • RISK having differing levels of auditability, may impact trust in the platform

    • Discussion that this isn’t about trust in the platform and rather trust in the implementation of a type of wallet and it’s implementation

  • Different types of wallets

    • wallet A - wallet contract supports full audit by all

      • DECISION - this is a Mercury requirement

      • IDEA Auditable wallet is a wrapper around the wallet + purse to keep the transaction history.

        • Need to clearly communicate and support that once the purse goes in, that is does not come out

      • The auditable wallet comes with the ability to request a transaction log

        • IDEA - this is a method call that requires having the name and not the wallet primary address

    • wallet B - wallet contract may not support full audit by all, provides obscurity

      • wallet B does not prevent wallet A from functioning

      • DECISION - This is this not a Mercury requirement?

  • Are there any blockers to providing complete auditability when using purses?

    • RISK Concern that allowing for splitting purses will allow users to obscure activity

      • IDEA mitigate by not allowing users access to purses. Abstract by giving users an account, and keeping the purses below the user’s access

      • IDEA don’t worry about users having access to purses, because once a purse goes into a wallet, it doesn’t come out

  • Happy path to Mercury provides an auditable wallet AND does not ensure all transactions are auditable

Action items

  •  Meeting attendees, if you heard something different during today’s conversation, please make a note here.