User data is a zero-sum game. A user spending time in Snapchat means time sucked away from Instagram.

Privately accessible data on a publicly addressable network. Zero trust. Shared entity - smart contract as a mediator and source of truth.


We track conversion for game studios by calculating overlap between the IP addresses emitted by the in-game pixel and our ad views/clicks. To calculate overlap, both ours and the advertiser's data needs to be in one location. Game studios don't want us to hold their user data since we can use it to calculate revenue. At the same time, we don't want to send them the IPs of our publishers' visitors for privacy reasons.

Possible solutions

The core idea is to never have individual client data touch our servers, and our data would never touch theirs. Most data breaches are worsened by the fact that companies have other companies' data.


IPFS stands for Interplanetary File Storage. Instead of the web today where the content is addressed using a location (URL stands for Uniform Resource Locator), the content is addressed with a hash of itself.

IPFS has been used in many different applications, currently the majority of them are dApps, but there’s a fast and growing undercurrent of use cases that are expanding and can be seen here:

The Airswap DEX uses IPFS to send messages between order takers and makers off-chain, through IPFS. The messages are encrypted from sender to receiver so that Airswap does not gain any unfair information asymmetry. They have senders of messages sign the messages, and use OpenPGP to encrypt them.

Lots of discussions around IPFS privacy and encryption here:

Why not IPFS?

By placing all ad metric data in IPFS, this could mean that information is going to be accessible to the public in some way, and deletion of events would not be possible since the objects might be replicated in other machines.

Even if the data is encrypted, then a quantum computer could come along that could hypothetically de-encrypt everything since it has perfect access. In which case, however, we have bigger problems to deal with.

Data Ownership and Liability

One of the questions that we get around the data is, "who owns our conversion tracking data?"

Alternative Solutions

  • Certification: Is there a solution similar to PCI compliance for payments processing in the fintech space?
  • Legal: Something in the privacy policy?
  • Q: Is there a way of proving that what is deployed is exactly what is in the repository? There is a difference between what's running and what's deployed. It's possible to side-load code into the server.
  • Lends itself to a blockchain solution

Analytics data lives on a shared network:

  • for storing the data
  • Record of transactions
  • Some sort of asymmetric encryption
  • We have records of what happens on the network = auditability
  • Only people who have access to the data can view

Encrypt with the public key on the client end. Since Wonderleap doesn't have the private key for the user, then we can't even access the data.

Q: How does retargeting work?

  • Speed is a limitation on-chain, so have to do this off-chain (use data on IPFS)
  • Ad creatives and copy could still be stored on S3 + CloudFront.


  • Do advertisers see the validity of this?
  • Client SDK design
  • How does IPFS play into this
  • Secure computation


Private Set Intersection

Applications in DEXes

"Secure multi-party computation (also known as secure computation, multi-party computation (MPC), or privacy-preserving computation) is a subfield of cryptography with the goal of creating methods for parties to jointly compute a function over their inputs while keeping those inputs private." (

"A data enclave is a secure network through which confidential data, such as identifiable information from census data, can be stored and disseminated" (