crosschain.md

The following doc explores how we'd go about updating the codebase to support cross chain integrations.

These requires a lot of documentation + strict guidelines which engineering WILL have to f ollow to ensure we can get a decent implementation of the idea listed below of it.

Currently the following are tightly coupled with Ethereum + Metamask.

• Frontend (FE)
• Backend (BE)
• Data Model (DB)

^ Decoupling that and make it super generic is what I've based my ideas on

This would inolve rewriting the every product one by one! As that is not a small task -> It makes sense to start with the smallest product we've got aka TIPS.

NOTE: A couple of terms I refer to in the below description are described here in detail _FE + BE : frontend + backend _ core business logic : concerned with the logic on how the tips feature works irrespective of the underlying blockchain used orchestrator : responsible/smart enough to deciding which blockchain flow to invoke psuedo-interface : a well documented README consisting of what function every blockchain would have to implement. Every function in the psuedo interface WOULD have be defined in the blockchain implementation.

FE + BE

Endstate:

When we onboard a new blockchain, the core business logic for tips should not change (except for a few lines of code of integrating) The FE + BE would both have their version of orchestrator and this what the core business logic would interact with

How do we get there ?

Since python + JS don't support interfaces, we'd have to create a pseudo interface to ensure easy onboarding of new chains can be done in an isolated manner without touching the rest of the app

Ideally we'd have have something along the lines of

// frontend
psuedo-interface Tip {
  send()    {}  // Business logic to send money to address 
  recieve() {}  // Business logic to recieve money from address
}

// backend
psuedo-interface Tip {
  send()    {}  // Business logic + save money to address 
  recieve() {}  // Business logic to recieve money from address
}

The FE / BE would talk to it's respective orchestrator which would be responsible for for deciding which implementation of the interface to be invoked.

---

Data Model Design

Following Seperation of Concern : Cleaned way would be creating a new model for each blockchain

Tip Model which would store generic infomration which we would need Tip Model - { id, from_profile, to_profile, amount} Aka Ethereum Tips would have Model Tip-Ethereum - {id, tip_id, gas_fees, address} While Ontology Tips would have Model Tip-Ontology - {id, tip_id, xyz} // we don't know what xyz could be

Anything we need to store in terms of the Tips on Gitcoin would be in Tip Model, Any remotely specific field to a particular blockchain and not the Tips product itself would reside in it's own model

---

Adding a new chain would involve

• creating a new implementation for FE + BE which would talk to it's respective data model
• wiring it to the FE + BE orchestrator

Removing a chain would involve

• removing the blockchain implmentation of the interface
• remove the handling logic within the orchestrator in FE + BE

@owocki I believe we are aiming at the same thing !
Could you check out this section
https://gist.github.com/thelostone-mc/9bd990d38eeca3ccb31db975d2710a47#how-do-we-get-there-

Essentially something like this

---

@danlipert said

re: cross-chain, what do you think about having a Chain model with a foreign key to
the different types of tips, bounties, etc.. instead of doing new models per chain?

Hmm that could work! Since we treat our products independent of chains.
Have a separate mapping table would make sense. Though wouldn't we still end up creating a new table for each chain per product to store information to unique to that chain ? aka basically getting back to what I proposed 🤔

Here is a visual of what I want to do architecture-wise. design is meant to minimize the amount of work for each cross-chain integration.: