Portfolio Wallets
Evolving token security, transfers, and governance
Originally posted on the Frontier blog »
As we develop the Frontier Platform, I’ve been thinking a lot about the state of wallets.
Today’s wallets for cryptocurrencies are either single accounts, or multiple signature (“multi-sig”) wallets where multiple people need to supply their private keys in order to perform certain operations on the wallet. This might be a daily limit on transfers, or a majority or unanimous decision.
There is the additional type of wallet where an exchange holds your wallet for you. You have control over an address, but you don’t have the private key, so you can only use the wallet on that private exchange or app. This is understandable, as there are many usability and security issues where more usable app interfaces can be built if the app system controls the wallets.
One issue with multisig wallets on the Ethereum blockchain is that they are not token aware. That is, there are now many ERC20 tokens [1] that have been defined, that themselves have significant value or rights associated with them. Today’s multi-sig wallets can have token transfers made to anyone at any time without any limit on the amount of tokens transferred, which is obviously an issue.
Portfolio Wallets
I’m calling wallets that can control token transfers — and in general hold many different items and type of items in them — Portfolio Wallets.
For the Frontier Platform, we will be generating many kinds of tokens. Some will be like e-shares, indicating that they represent equity in a particular company. There will be rules in both the Shareholders Agreement (in the Canadian jurisdiction for private companies — each country’s rules around company equity has different terminology, standard documents, and so on) as well as the regulatory environment that govern when and to whom those tokens can be transferred.
We will work to embed as many of those rules as possible in smart contracts, while others will be implemented by the Frontier Platform, or perhaps integrated with oracle services.
“Trustless” control over transfers which still respect regulatory or other concerns (e.g. KYC, AML) are likely to be hard to embed fully in code. We think of the Frontier Platform as a type of orchestration layer, that bridges between on-chain and off-chain operations, as well as providing usability scaffolding so people don’t have to use the command line and smart code ABIs directly.
It is better for us and for the network ecosystem as a whole the more components are standardized, performant, and secure.
Standards Work
Tokens — which are in reality a token definition and then a contract which further controls and defines these tokens — are difficult to write securely at scale. The best for us is if we work together and out in the open with many groups that want the same thing.
The ERC223 proposal which adds further security and improvements to the token standard is one example, and we’ll be tracking that closely.
A standardized way of making wallet contracts “token aware” and being able to apply multi-sig functionality and restrictions in a similar way to how ether transfers are restricted is the next area to look at.
What are your ideas for evolving wallets, tokens, and transfers? I’d love to hear about other people working in these areas.
[1] The ERC20 token standard proposal has now been accepted as an Ethereum Improvement Proposal (EIP) and is available as EIP-20.
