RFC-0002: Messari as a Frontend for Web3

# 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. ``` Enabling web3 integrations in DataApps, opening new type of analysis, experiences and revenue streams. On a pythonic / click-and-play / agnostic but secure way as if we were talking as web2 service like stripe. > - Agnostic -> Language agnostic > - It's also open source > - Certain advantages like portability and an universal way of interacting with protocols should probably be stated as well > - Also, there's an ongoing effort to implement a permissions system (like Android and Apple do in their mobile OS). Would need to ask Jure about it but it's in our roadmap. > [name=Nestor] ## **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. ``` - Enable datapps with more capabilities and interactivity. Converting them into a dapps. Allowing things like reading users wallet, interacting with protocol and so on. > Here I'd say something like: "Provide a universal way of interacting with datasources; while also providing support for mutation operations (like signing transactions)". > [name=Nestor] ## **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. 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. So why don't we try to reduce this barrier? We could create an app with analysis capabilities but also support for operations with the systems that we aggregate. This would generate a direct ROI; users wouldn't need to leave our application and jump elsewhere to perform transactions. This translates to less steps in the funnel/user journey. ... 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. 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 front-end components, and you are able to use them from Python, and pass data into them. There is a project that does something similar in concept but with web3 integrations, is called "Polywrap". Instead of wrapping visual components, it wraps protocols (and pretty much anything) into "wrappers"; which are similar to SDKs but have a standard interface, have an isolated execution enviornment, among other advantages. With Polywrap, it'd be possible to not only perform read, but also write, operations on any protocol we currently have in our platform. They are backed by a bunch of organizations, and prominent projects. They've also earned grants to build "wrappers" for orgs like Uniswap or Near. > We don't have grants, but rather making interested people in building wrapper to fund those > [name=Cesar Brazon] > We don't issue grants, but we've won grants ourselves, right? Like from Uniswap, Tezos, Near > [name=Cesar Brazon] Here's a list of some of the wrappers in their showcase: > 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] > 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. Wrappers can interact with each other, so there's endless potential for composition and extension of already existing functionality. Which is not only great, but also solves a Streamlit limitation which is precisely that components can't communicate with each other. - Secure. Wrappers, at a low level, are WebAssembly modules, which execute in an isolated execution environment and have no access to the host machine. Nonetheless, Polywrap does offer a solution to perform actions that require access to the host (like signing a Metamask tx) without compromising security. - Scalable. WebAssembly modules are extremely performant. Using Polywrap, we only need to, lazily, download and cache wrappers on-demand at runtime. So we can keep apps lightweight and efficient, which is essential for apps using Streamlit. - Portable. Since wrappers are WebAssembly modules, they can be consumed, through Polywrap, from different application languages with virtually no changes to the interaction code. Imagine having a Streamlit app in Python, and a NodeJS service or Go lambda where the code to interact with Uniswap is practically equal. Most of these things 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 covered by their existing wrappers. When I reached out to them, and told them the idea of using it on Streamlit they thought that was a really interesting idea and something their tech would already support. It also made a lot of sense as Python and data people don't need to be concerned about the integration hot-wiring or the web3 nits and specifics that happen under the hood. It'd give us flexbility and we would need to rewrite less code, without compromising performance or security. We could even make our own re-usable integration widget gallery. 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. --- 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. ## **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 security issue if we build from scratch all of these functionalties, or need to rely on a vast array of different third party SDKs. There are always certain risks when interacting with contracts or using existing SDKs. But these aren't risks that are inherent to Polywrap; if anything, it'd help us mitigate them. ## **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.***********************************************************************