# RFC-0002: Messari 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:**

Enabling web3 integrations in DataApps, which will bring about new opportunities for analysis, experiences, and revenue streams. The approach is language agnostic, secure and open-source. That easly fit with our current set up for datapps. As if we were talking of web2 service like stripe.

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

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

The goal is to enhance DataApps with more interactivity and functionality, turning them into dapps. This will allow users to interact with protocols and read their wallets, among other features.

## **Background & Motivation:**

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

*Define any key terms or internal names here.*

Thorughout history, as new technologies come along, tools and resources emerge to help people navigate them. But eventually, after enough time, aggregation tools for these technologies are released. For example, in the past, you'd have a trading analysis and intel application open, while also having another trading application to operate; but now you have both things in a single app.

In the crypto space, most of things are open source. But still, the entry barrier and learning curve to interact with robust protocols and projects are higher. Visibility and a smooth developer experience for interactions are also notably more difficult, when you compare them with the classic web2 sphere.

This is precisely why companies like ours exist; to give context, tools and valuable information to enable an easier navigation through the web3 world. For users and projects, products like Quarterlies, are that valuable for the protocols/projects because they bring transparency/attention and context to users, what potencial could bring them more users that at the end of the day is what they want and for what they paid for.

There are many competitors providing aggregation resources, dashboards and apps giving context an insight about chains and protoocols. But almost none of them let you interact with these protocols from within their application, even for pretty simple operations.

Why not reducing the entry level, create an app with analysis and also one where you can interact with that protocol or project from. This translates to less steps in the funnel/user journey. Users wouldn't need to leave our application and jump elsewhere to perform transactions.

What you are about to read is the solution I came up with that enables this functionality in the most secure, scalable, native, and smooth possible for Messari.

## **Revenue:**

Ideally what you would want is going to a place, where you find valuable content/tools/anaylsis, and with that information doing something. Like Uniswaps LP app, you realise something, and base on that information you can add liquidity on a pool from that same side. Without needing to leave it. As we know with more steps on the funnel the chances of a potencial user failing increases.
This translates on a easy way of measurable ROI.

You may be wondering how could we turn this into measurable ROI. Well, we could add a "referral code" to our transactions and partner with the organization behind projects to do some form of revenue sharing with us, given the users that we drive to them. However, charging any extra fees, or redirect user operations though anything wouldn't be ideal. The experience should be as transparent and native as interacting with a protocol directly through their own application.

We do add our referral code to transtactions tho, so, for protocols/projects with revenue sharing, they will send us part of the fee they earn. (like a referral code.)

It would make us more crypto native, being the real 101 of interacting with crypto and doing 10x to price for grants and enterprise. As web3 integrations have a cost. As we would directly drive clients to their protocol

All protocols could host a “Messari FE”, a trusted gateway for users to interact with the protocols, that integrates analysis, tools, and educational content.

This ideas, and thoughts where confirmed with uniswaps grant. They mentioned, that as a soft requirement

So, concretely, how could we do that in a way that doesn't require lots of effort, doesn't compromise security, and has a smooth plug-and-play developer experience?

## **Design:**

What Streamlit does is wrapping the front end, and with their components you are able to inject no python code into the applications. Althought they have a couple of limitations.

Most of the things we would like to do are interacting with exisitng contracts, or doing things that a lot of people are already doing like wallet integration on the dapps world.

There is a project that does a similar concept but with web3 integrations, is called "Polywrap".

Polywrap, is a developer tool that enables easy integration of Web3 protocols into any application. It makes it possible for applications on any platform, written in any language, to read and write data to Web3 protocols.

They are backed by a bunch of protocol, and projects. And they have grant to build "wrappers" for their SDKs, or projects.
> We don't have grants, but rather making interested people in building wrapper to fund those
> [name=Cesar Brazon]

And they have grant to build "wrappers" for their SDKs, or projects.
They have already a list of them created, like uniswaps...
> Gnosis safe: https://github.com/ConsiderItDone/safe-contracts-wrapper
> Coingecko: https://github.com/defiwrapper/coingecko-rs
> IPFS: https://github.com/polywrap/ipfs
> Ethereum: https://github.com/polywrap/ethereum
> ENS: https://github.com/polywrap/ens
> [name=Cesar Brazon]
>
And plugins with functionalties that we could leverage right aways like ...ethers, ens...(Examples here).

> I would only name the wrappers and only reference plugin to access host capabilities (like signing, file system or http)
> [name=Cesar Brazon]

As you will see on the demo, with a line of code you will be able to get signers address. Or add liquidity to a given pool.

On top of that, their tecnology has more advatages that make them great fit:

- Composable. Endlessly compose and extend wrappers with imports and standard interfaces. What is perfect, and solves one limitation that streamlit has, what is being able to communicate with other components.
- Secure. Sandboxing keeps users safe by isolating wrappers from application memory.
- Scalable. Keep apps lightweight and efficient, download wrappers on-demand as needed. What is essential for streamlit apps.

Most of this thinks can be found here, and in their docs. If you want to go deeper into it.

This is how to flow would look like:

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

On the componenets side, we could make that way so things are hardcoded for messari, like the referral fee we said or ...

Custom React Componenet creation using their react wrappers...

## **Timeline:**

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

I think most of things we would like to do are cover by their existing pluggins, or wrappers. But when I reached out while a was doing the first interation, and I told them the idea of using it on streamlit they thought that was a really good idea and made a lot of sense as python and data people dont know about integrations that much.

And X,, Y z, reasons like...

They told me that are more than happy to chat about how they could help us with our web3 integration needs.

## **Alternatives Considered:**

So before going with the Polwrap, I created a component by myself
that would just interact with metamask.

Componenent espcifico para cada aplicacion, y con sus integracions.

Cada datapp, sus integraciones de cero. Y la forma de interaccion no es lo mismo, y a parte necesitamos muchos mas conocimientos para cada uno de los projectos y protocolos.

En este caso todo esta estandarizado.

--- Video---

But its kinda stupid to code something that eveyone is doing over and over again. And instaling libraries like web3 or hardhat cosnume made the app heavy. Took me a lot of time, and lines of code just for one feature that they had.

In the thirt of the amount of time, onces the incoquer and parse was done. 3 new feautres where added, in a blick. Working right away.

- Time cost
- Code rewritting
- Deep Web3 knowledge and awarreness. Adding liquidity on hand would be something like that:
- Antonio github
- Code needed right now to add liquidity.

## **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.*

I think there would be more risk or possible securty issue if we would build from scratch all of this functionaltys by our own. As I did with the metamask example.

There risk that would exist here, would be the same ones that the existing SDKs or Contract would have. As the wrapper just involve the existing functioanlty.

1- Usar en el cliente de polywrap, igual que
2-
- Legal
- Hacks

## **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.***********************************************************************