A vision for a mobile and web-based application, controlled by private keys that permission control of tokens in an Ethereum wallet and also govern read and write controls to a cloud-based, decentralised data store.

Why Pocket? 

A pocket is where you keep your most essential and intimate belongings. It’s where you store your wallet, debit card, phone or keys. It’s also where you store your ephemera like receipts, sweet wrappers, ticket stubs, or scraps of paper with random thoughts on them. It’s a place to carry money and memories as you traverse the world.

Pocket is where you store the digital version of your belongings, such as NFTs and ERC-20 standard cryptographic tokens, but also the digital story of you made up of tens of thousands of data points. You can receive money into it. Or you can build up your digital history and save it in a way that can be read by many others.

When you arrive at a digital portal run by a third party, you can effectively take things out of your Pocket to prove who you are, pay for things, put money back into it, or let others read selected parts of your digital story to better serve you just as you would do if you turned up at a book or clothes store and they asked: ‘Are you looking for anything in particular?’ And all of this is under your full control. Because Pocket belongs to you and you alone.

What is Pocket?

Pocket is a simple innovation brought about by a complex web of dependencies. The integration of self-sovereign identity and self-sovereign payments into a single application is a technological holy grail. Given the now reasonably widespread utility and pervasiveness of private keys on the Ethereum network, it is not technically difficult to achieve. Standard wallets in Web3 allow you to store NFTs and of course ERC-20 standard coins and others. The difficult feat has always been integrating data related to an individual. The data being stored must be well governed and structured in order to have utility because a wide ecosystem of other parties must be able to read this data programmatically.

Through working co-operatively with data unions, this is what the Pool ecosystem expects to have in spades – an overabundance of well structured, well governed data. At near zero marginal cost the ecosystem can copy the streams of data that people are already creating and sharing with data unions when they become members. These streams can be ‘pasted’ back to an individual Pocket user automatically. The user needn’t do anything else. This is why we believe Pocket will succeed where others have failed. A co-operative data union ecosystem can utilise with ease what it will take competitors years to build. More than that, our incentives align all the way through the product journey. How?

• People want to join a DU because they get paid. 
• They also get to utilise Pocket and all the extra services and revenue that brings.
• DUOs should want to promote Pocket because it allows them to scale membership faster, it lowers the cost of building secondary but necessary member software and opens the potential to vast amounts of B2B advertising revenue and beyond.  

To stress – it is revolutionary to merge money and ID in a self-sovereign way. Pocket allows people to pay and be known in the digital world, on their own terms. While a payment system must have trust, the individual making the payments must also be trusted in order to reach beyond the simplest of use cases in commerce and finance – from mere transactions and into services. In that regard identity is one of the most fundamental aspects of capitalism. For the digital sphere, Web2 ‘solved’ this issue through either incredibly centralised ID systems (sign in with Google/Facebook etc). Or through the cumbersome conversion of analogue assets into digital (ie, scan your passport). Both systems have left ordinary digital citizens out in the cold; without power, without convenience.

Pocket will rebalance this unequal dynamic – and therefore the app goes right to the heart of Pool’s mission to redistribute power, value and control in the data economy. Pocket can be used as a new, user-controlled and operated ID standard. It can be the single sign-on that provides its controller gradations of choice over how they are known and understood by third parties. More than that, DU data provides for a higher quality identity standard. Real-time data from multiple sources such as banking, commerce and health data will provide the backbone of a far more enriched identity layer. This data ID backbone can also be supplemented by more traditional forms of ID like a passport, address and mobile phone. Built right, Pocket can be the best single application that re-empowers digital citizens for the Web3 era.  

Building principles 

1. The holder of the private key should control just about every feature of this application. It’s your Pocket.
2. Interoperable – we want people to build every kind of service off of Pocket. We are also working cooperatively with the DUs in our ecosystem to leverage the value they are creating. So this application must be as creatively interoperable as possible. 
3. The source code will be readable by all. We are still determining whether (given the nature of personal data) the code will be fully open source.
4. Decentralised – this naturally follows from principles 1-3 above. We are building this for data union members and data union operators.
5. We will seek at every step to increase value and decrease cognitive overhead. This app, unlike so much of Web2, need not vie for people’s attention. We should be creating streams of member/DUO revenue and easy management of one’s data (an important yet boring task)..

Examples of how design choices flow from the above principles: 

1. Wallet should be self-custody; no built-in third-party interference like KYC. (Pocket is itself the KYC tool!) 
2. Users should be able to import their own ETH addresses.
3. In conjunction with data unions and various other stakeholders, Pool should maintain front-end access protocols to provide Pocket users with trust, ie, lowering cognitive overhead. (Uniswap is a good example of this.)
4. It should be possible (with a user’s consent through private key management) for anyone to populate Pocket with the user’s permission.
5. Only two entities should be able to easily populate data in a personal data vault (PDV): DUOs (to which a PDV owner is subscribed) and the individual controller of the vault.  
6. Just like coin storage, data storage should be decentralised on (for example) IPFS, utilising a protocol layer optimised for real-time data storage like Ceramic.  

Who is this for? (Stakeholders)

Pocket is a co-operative application in that there are a good number of stakeholders working together to generate revenue for each other. Pocket’s USP is the fact that the whole of the data union ecosystem is creating well governed, well structured streams of real-time information and will want to leverage this value.

Stakeholders: 

• Data union member/Pocket controller
• Data union operator (DUO) 
• Pool Foundation 
• PDV accessors, eg, advertisers, website owners, credit issuers, identity checkers, retailers 
• Ethereum ecosystem   

For the first time we have users/data creators involved in the system for gathering, controlling and accessing PII. DUOs act as professional bodies representing and bargaining on behalf of their members, ie, Pocket controllers. Pool’s role as a stakeholder will be to remain impartial between different stakeholders, increase overall growth of the ecosystem and retain the long view. Pocket data vault (PDV) accessors are largely made up of the same group of stakeholders as the current cookie economy but can also include credit checking companies and government agencies for identity purposes.

If we were to prioritise use cases as per their stakeholders then this would be the priority list:

1. To help DU members better find, join and manage their DU memberships. 
2. To help DUOs scale their membership. 
3. To help DU members (Pocket controllers) make payments and utilise their data in the most convenient way.
4. To help DUOs and their members further monetise their existing data assets.

So what can a person do with Pocket? 

At first the use cases are simple and obvious and will be highlighted by the features in Pocket itself. 

• Way to discover and join new data unions 
• Way to take receipt of your money from DUs
• Way to store data

But when personal data and money are combined like this, the possibilities are pretty vast. Here are a just a handful of world-defining use cases: 

1. Replace the cookie
2. Self-sovereign, single sign-on with Ethereum (or 4SoE)
3. Self-sovereign autofill 
4. One-click purchases (ie, everyone is Amazon)
5. Peer-to-peer AI services.  

1. Replace the cookie

Pocket inverts the cookie model. Instead of websites and digital retailers forcing a multitude of cookies on users, users ‘carry’ their data vault themselves in their Pocket, which can only be interrogated on terms they set.  

Given the transition away from cookies, the advertising world is most likely to benefit from PDV innovation and adoption. In this user story, the Pocket controller arrives at a website. That website has dedicated some of its web page space to an ad-serving platform. If the Pocket controller has decided to allow their Pocket’s data vault to be read by third parties (a list of whom will be curated by Pool and others) the ad-serving platform then reads the user’s Pocket data vault in order to optimise the delivery of an advert against their inventory of adverts. 

In reading the Pocket data store, it makes a micropayment to a dedicated smart contract, which goes on to pay the data union operators and affiliated stakeholders. 

Because Pocket is open and interoperable, any company is able to build out an ad-serving platform using this technology. The competition will be driven by which services have the most optimised and cost-efficient ad-matching engines, not by who has captured and siloed the most data on users.

In order to mitigate against privacy concerns and fraud, Pool will, on our front end, operate a whitelisting system (in concert with others) to define reputable ad-serving companies. Those who are whitelisted will receive a trusted green light on our user traffic light system on the Pocket interface. A signed permission every six months for trusted ad servers should be sufficient. 

2. Self-sovereign autofill

Digital form filling is laborious and repetitive. Quite like Google’s autofill service, Pocket would be able to capture passwords and basic information like addresses and credit card details, and store these within the data vault. This information would be stored locally and whenever a user wanted to deploy such information on a digital site, they would be able to auto-populate online forms and payment details with a simple click.

3. Self-sovereign single sign-on with Ethereum (4SoE)

Sign-on with Ethereum is now an Ethereum improvement proposal standard (EIP 4361). The elegance of signing in with Ethereum is that not only are Ethereum addresses a common enough protocol, they are of course self-sovereign i.e. they belong to you and you alone. However, unlike signing in with Google or Facebook, Ethereum public keys do not serve as a useful KYC repository. But storing a digital citizen’s data within a repository also controlled by the same private key makes for a brilliantly simple but incredibly powerful sign-on solution. MetaMask is already experimenting with this by utilising 3Box’s storage protocols.

What the Pool/DUO ecosystem has, is a huge, defensible, competitive advantage. Data in Pocket is pre-structured along well-defined protocols, which means that it is scalable and services can be architected to read the stored data. From the user end it means that with a single click you can sign in with Pocket (and any 4SoE enabled service) and know that not only do you control the data and information flow, you can also pay (and have things delivered etc) with a single click in a wallet that you also control. And because Pocket can store website preferences, users can fully control payments made to a site and other user account preferences. This could dramatically reduce the personal data storage overhead of websites/businesses and is possibly a way to end first-party cookies. It would also create a uniform ID across websites, which would make first-party data collection and back-end processing and amalgamation easier.  

For more complex KYC arrangements you could imagine a specific business popping up to utilise the trove of useful information stored in Pocket and give credit scores, provide B2B solutions to verify the likeness of humans vs bots etc.

4. One-click purchases (aka everyone is Amazon)

An airline wants to sell flights to a prospective holidaymaker. Rather like the process for ad-serving technology described above, the airline would query the Pocket app, which could include web behaviours, geolocation information, social media footprint, media habits and health data. This would allow the airline to query much richer, fine-grained information about flight preferences and desires than even Google can currently provide. 

Furthermore, given that convenience is king, delivery address and payment information would also be filled out much faster than before. And with a PDV controller’s permission, the checkout  process could be cut down to a few clicks, rather like with Amazon, because Pocket would nullify the need for users to set up Demand Side Platform (DSP) accounts as identity, consumer preferences and relevant payment information could be stored in Pocket. In only slightly more advanced versions of this, the user would no longer have to even view the forms. You would simply sign on to a website with Pocket and away you go.

5. Peer-to-peer AI services

Artificial intelligence is of course only as good as the data it is trained from. More than that, in order for AI systems to be truly personalised, they will need to read the digital stories of the customers they intend to serve. Let’s say you want to use the best holiday finder AI recommendation engine. The Pocket controller would go to the AI-powered website and then connect their Pocket app to the site. The AI would then be able to connect to a trove of data stored in Pocket – web analytics, finance, wellness data, social and media consumption data – to recommend a holiday package, which the Pocket owner could even pay for directly from the wallet

Pocket technological/biz/feature issues

The following is a non-exhaustive list of issues we want to highlight publicly.

Data issues

1. Data write in 

One primary question with the Pocket data vault (PDV) is who can write to it. There are three main constituents here:  

1. Controller 
2. DUOs
3. Other third party 

A data vault without data is obviously a useless piece of software, which is how most experiments with PDVs-at-scale have turned out. As mentioned above, what makes a Pocket data vault different is that it is attached to an ecosystem that is already incentivised to create and monetise data at scale.  

In the Pocket system there should be only two stakeholders who are able to populate Pocket’s data vault with ease. The first is the Pocket private key controller. They might want to enter personal information into their PDV such as their email address and mobile number. 

The second entity that would populate the Pocket data vault is any data union that the controller had joined as a member. DUs already have well structured, commercially useful data that takes GoPES (governance, privacy, security and ethics) and a member’s preferences into account. So alongside some personal information entered by the PDV controller, what is also being stored in a PDV are copies of a member’s data union streams.

Some examples of the types of data that might populate a PDV are below:

There is also the question of third-party permissions to write data to the PDV. Examples of this data might include the sort of information contained within a third-party cookie today such as user preferences on a site. The PDV will need to take account of this. But standards will need to be devised as to what sort of user information can be collected so it doesn’t ‘tread’ on the toes of DUO-collected information. For example, a site-specific piece of data such as a user’s preference for light or dark mode, or a user’s favourite subjects to read on a media website (politics, tech etc) might be appropriate, but purchase history might cross the line. If, of course, this data was available to others and could be commercially relevant, there’s a question of whether sites would want these cookies to be read at all or whether (as somewhat happens now) the 4SoE would act as an identifier in the database of the first-party website, triggering the right user preferences on the site.

Also relevant to this third-party category would be receipt information (see below).

2. Data read 

Who can read a Pocket data vault? Given our principles, the answer should be anyone, with the controller’s permission. Pocket should also have a toggle to allow controllers to make their data unreadable/completely encrypted. However, rather like Uniswap for tokens, we should build a managed trust system on top. This will display as a traffic light system dialogue box when a third party wants to read a Pocket.

The main risk analysis would presumably follow on from this basic trade-off:

Pocket controllers will be able to set preferences about what type of organisations can query their data and which data sets can be queried. A controller might be comfortable with website owners or advertisers querying their media consumption habits and so switch this preference on. But even though they had joined a data union for financial transaction data, they might not be comfortable with potential advertisers being able to ask what the last five major deposits were into their bank and linking that directly to their name. In some ways this is not too different from the sort of permission dialogue boxes that have been deployed by Apple in its iOS 14.5 update to inform users whether apps may track their data.  

Finally vault owners will, if they want, be able to download all their data and even port it to another service or outlet. Good technical and user interface design will help mitigate the privacy and security risks inherent with having a single party (the data vault controller) having custody of a large swathe of their data footprint.

3. ZK vs non-ZK

Some queries by third parties will, of course, be scripted as zero-knowledge (ZK) queries. For example, ‘how much does this person earn every month?’ could be discovered in a ZK way without the querier needing to have access to all financial data. However, other information such as a Pocket controller’s home address will need access to the entire data set and a ZK query becomes meaningless as the answer to the query contains all (or nearly all) the information in the data set. 

This problem, which is really a privacy problem, can likely be solved in two ways: controller permissions within a suitable trust framework (see above) and access charges, to stop fishing or needless intrusion of privacy. Of course, we need to develop the ZK system around Pocket and these third-party queries need to be answered with very low latency.  

4. Back-end storage/latency 

We have decided to select Ceramic as our back-end storage solution. Our storage solution needs to be able to solve the storing of real-time data (regular but stochastic writing to a store) not just one-off static storage. But when it comes to reading a PDV, latency is also a huge issue, especially in advertising. The current accepted standard is that relevant ads can be served in under 100ms. We expect latency – accessing the data after making a micropayment to do so – to remain a problematic issue, so we have devised workarounds. Take advertising, for example, given that after a rich history of data is served and read, a Pocket controller could be classified by the ad server within a particular behavioural cohort. This cohort classifier could be stored as a simple data point within Pocket, or utilising the 4SoE ID, connected in the ad server’s back-end. On the business end, this would of course reduce access to the PDV and therefore potential financial gain from having third parties pay access fees. 

5. Data verification 

Each time a user deploys a name, address, email or credit card through Pocket, this metadata can be time stamped and tracked by and within the application and used to ultimately verify the data points on the controller write-in side of the database.

6. Signing an individual’s stream to a blockchain as an anti-fraud measure 

What if the worst happens and a Pocket controller’s data is read and copied in full by a nefarious third party, or a controller’s private key is stolen/copied/accidentally given away? While there is little that can be done about the tokens in a controller’s wallet, the data can be somewhat secured against subsequent misuse. By writing random data points and/or all of a controller’s private data to the blockchain, a Pocket controller’s data can be secured. By cross-correlating timestamps in real-time data points against timestamps in a blockchain, this would  allow Pool, DUOs and any third party looking for extra verification to ensure that controllers are who they say they are. 

7. Connections graph – for enhanced KYC 

At some point, Pocket controllers will be utilising the app throughout the digital sphere. They will journey through the web and will be greeting a graph of social and commercial connections in Web3 (which will be logged on the relevant blockchain) and in Web2. Collecting this data and storing it in Pocket should, of course, be under the control of the Pocket controller but could be a very valuable asset for reputation and enhanced KYC services in the more distant future. This data should only be shared with Pool if a controller chooses to (with perhaps incentives) and should not be monetised unless it itself becomes a specific DU.

Wallet/tokens issues

8. KYC 

The question of having KYC in our wallet application has already arisen. Given that this application is fully controlled by the user, no third party should be interfering in this process. This will mean that Pocket will always have to connect to an off ramp where users can change their xDAI into their preferred fiat currency. Similarly they will have to send their xDAI to another wallet or connect with a decentralised exchange in order to swap their tokens. This has never been easier and we can do this in the current industry-standard way, by connecting wallets to exchanges, or making it easy enough to send tokens through QR codes or entering the relevant ETH addresses (note L1/L2 issues will arise here).   

Of course, we believe that people should keep their money digital because that is where it will have most utility. And finally, Pockets will contain far more data than any KYC process currently. Should adoption follow as we hope, Pocket will itself become the KYC tool of choice. 

Other issues

9. Is it a smart contract or is it an Ethereum address? 

So far we’ve been talking about an externally owned account (EOA). Could it be a smart contract instead? Argent has excelled at this by building a smart contract wallet rather than a front-end to operate an EOA. This would allow for far more features in the future such as direct debits and social recovery. The prohibitive aspect of this has been transaction cost. This is no longer the case on Gnosis Chain for example.   

10. Syncing mobile and web-based apps

This is a necessary feature. Many apps do this well, for example WhatsApp or MetaMask. Given that our digital lives are lived on many devices, most especially mobiles, we need Pocket to be able to traverse all these digital realms flawlessly.  

Business model 

Although we can envisage the utility Pocket provides, the question is how does the app return monetary value for all of its stakeholders? 

More thinking needs to go into this but the primary way it does this is through controllers permitting third-party access to the data in Pocket. The payment system for how this occurs is still in development but will require heavy engagement with Pool’s major enterprise partners. 

One clear issue is that money needs to be sent to the DUOs not the Pocket operator otherwise it would instantly encourage spam. DUOs can, of course, be the gateway to stopping bots. The Pocket app will itself act as a tool to identify real humans.

There will also be a question about how payments are split between DUOs since Pocket controllers could be members of several DUs. Also if a controller controls the app, what’s to stop them from accepting direct payment to unlock their Ceramic database? What will make the payments system work is the trust system. Being on the trusted whitelist will be the key to ensuring proper and suitable payments. When Pocket scales, no third-party reader will want to be relegated to non-trusted status.

Other streams of revenue include the ecosystem taking a cut of successful consumer sales. Through Pocket we will be able to demonstrate that a Pocket controller’s data was accessed, a relevant ad was served and then a click-through to the advert occurred and a purchase then took place (within almost any length of time). DUOs should negotiate either discounts for members or a cut of sales for their members. You can imagine a smart meter data union, for example, being central to negotiating a fee for getting members to switch to new services based on smart meter data. This fee would of course be split co-operatively.

Sign up to our email newsletter to keep up with future news and details of Pool events