# Flipside as a Frontend for Web3

Fill out metadata above. Delete notes in *italics*. Remove sections that are not applicable. Please do not modify this template. 🙂

**Approver(s)**: ***********************************************the author(s) can choose relevant approvers. Leadership may add or adjust these.***********************************************

**Other reviewer(s)**: *people whose comments would be helpful but who don’t need to approve.*

## **Overview:**

I propose we enable Web3 integrations in our DataApps, as this would potentially bring new revenue streams. Additionally, it would make our users capable of performing operations on protocols with our analytics, and without needing to leave our platform.

We can implement support for this in a easy-to-code, maintainbale, scalable, peformant and secure way using a tool like Polywrap. We wouldn't need to change our current tech stack or Streamlit either; the process should be non-disruptive for us.

## **Goals and Non-Goals:**

*What problems are you trying to solve? What problems are you not trying to solve?*

The general goal is to enhance DataApps with mutations support, turning them into full dApps. This would enable users to send transactions, interact with protocols, connect their wallets and sign messages, among other features.

More specific goals include:

- Decrease the need for users to leave our platform to operate on protocols
- Provide a smoother, and more advanced, experience for users that would wish to interact with multiple protocols based on our platform's analytics.
- Explore new revenue streams

## **Background & Motivation:**

*What is the current state of the world? Why is this change being proposed?*

*Define any key terms or internal names here.*

Users in the Web3 space, constantly seek solutions to ease their navigation through the ecosystem; and information to have better visibility and take more informed decisions. Platforms like Flipside exist to provide exactly that; by presenting aggregated information to our users that would otherwise be very hard for users to retrieve and digest.

Nonetheless, when users want to act on the information they received from us, they need to go to different multiple places to do so; esentially, needing to manually navigate through the crypto sphere again.

Even if a notable amount of Web3 projects are open source, the barrier of entry and learning curve are very steep for non-coders and non tech or crypto-savvy people. The onboarding process of new enthusiasts is a long process and frequently full of errors, given the UX of these technologies are not on par with the classic Web2 ones yet.

But we could be the ones to lower this barrier, bring more new people into the space, and provide a better experience for the already existing ones; and try to generate more revenue through it.

Currently, our DataApps use Streamlit. What Streamlit does is wrapping, or providing already existing, components and pass data from our application in Python, into them.

Polywrap does something similar in concept: it wraps protocol interactions into self-contained, isolated, interoperable units called "wrappers", which can be consumed from our applications. So Polywrap could be an interesting tool to explore, if we want to enable protocol interactions through our platform.

They are backed by a notable amount of reputable organizations, and prominent projects like Gnosis, DxDAO, Gelato, among others. They've also earned grants to build wrappers for protocols like Uniswap or Near.

## **Design:**

The solution would mainly consist of an instance of the Polywrap client in our DataApps, and we would perform mutations on protocols through it. This could be achieved by either using Polywrap's Python Client or wrapping Polywrap's Typescript Client into a Streamlit Component.

The key advantages of protocol interaction through the Polywrap Client are:

- **It offers a consistent interface across protocols**. So the code we'd need to write to interact with Uniswap will have the same structure as the one we'd write to interact with, for example, Balancer.
- **It's inherently more secure, and it's permissions-based**. Wrappers, at a low level, are WebAssembly modules; which run in an isolated execution environment with no access to the host machine. Host machine interactions, like signing a Tx through Metamask, are handled by a permissions system; so we'd have a stricter control over the sensitive parts of the application.
- **Requires significantly less Web3-specific knowledge**. This is because interactions have already been abstracted, so our data engineers can focus on data tasks instead of being concerned with the specificities and nits of Web3 integrations.
- **Lightweight and performant**, as wrappers are downloaded lazily on demand and cached. It only fetches what it needs.
- **Composability** as wrappers can interact with each other and it would greatly reduce the need to rewrite code our re-do integrations in different languages.
- **Portability**, as WebAssembly is application-language agnostic; so wrappers can be written once, and using the consistent interaction interface: the code that we'd write in a lambda in Go, or a Node service, or a Python app is virutally the same

This is all well explained in their docs and website, so I'd recommend you took a look at those. Here's a brief flowchart that illustrates, in simple terms, how the process looks like:

--- Schema/Diagrama of the app, component,

Speaking about ideas for **revenue generation**, we could add a "referral code" to our transactions and partner with the organizations behind projects to do some form of revenue sharing with us, given the users that we drive to them. We wouldn't need to charge extra fees, although we could. Defillama's swap platform, is an example of this model.

An important aspect to keep in mind is that Polywrap isn't a SaaS service like Utopia. It makes it easier to interact with protocols, but it doesn't interact with them on your behalf.

> Even without a referral code it could be worthwhile. I'd check how platforms like zapper.fi make a profit.
> [name=Nestor]

### Demo

I've prepared a small demo to show you how with a few lines of code I was able to get off the ground an app that adds liquidity to a Uniswap pool, supports Metamask connections, and fetches data from a subgraph.

## **Timeline:**

*What is the proposed timeline for the implementation? Include specific next steps, whose time will be required to proceed, handoff process, etc.*

Most of the things proposed in this document are either already covered by their existing wrappers and tools; or very easily implementable. So the effort and time required to go forward with an implementation shouldn't be high.

I've already reached out to them, and discussed some hypothetical approaches of using their tool in Python data applications with Streamlit. They found it really interesting and it's something their tech already supports. They're willing and more than happy to chat about how they could help us with any of our needs.

## **Alternatives Considered:**

The alternative is to make the integrations ourselves, either from scratch or by importing a collection of different SDKs in our DataApps.

Just to compare, I created a component myself that contains minimal interaction with Metamask. Here's how that looked:

--- Video---

But it's inefficient and unnecessary to code something that's already been done; and attempt to repeat patterns over and over through different codebases.

Additionally, installing libraries like web3.js or hardhart make the application unnecessarily heavy; specially if you just want a handful of their features.

With Poly, in a third of the time, with no unused code, and just a few lines, I quickly implemented 3 features. And note that adding liquidity, from scratch, to a UniswapV3 pool with no prior knowledge is not as easy as it sounds.

## **Security/Privacy/Compliance:**

*What security/privacy/compliance aspects should be considered?*

*If you're not certain, never assume there aren’t any. Always circulate these considerations with the team.*

There's always an intrinsic risk when enabling protocol interactions, but these risks are not inherent to Polywrap. And with it, we can mitigate that risk considerably more than regular, popular, dApps.

Relying on a vast array of different third party SDKs is a lot of code surface area to put our trust in. On the other hand, wrappers are isolated and their dependencies can be controlled through a permissions system. Only the Polywrap Client needs to be trusted; hence there's very little surface area to trust.

## **Revisions:**

1. *RFC Created*
2. *Update for major changes, including status changes.*

---

## Discussion

**Date:** *date*

***********************************************************************Here, include relevant notes from live discussions related to this RFC. Indicate the speaker and substance of the speaker’s point.***********************************************************************