@0xneves @heronlancellot @RafaDSan
We are still in the early stages of this journey, meticulously brainstorming the architecture to deliver the most optimized, legible, and scalable code. Our primary focus lies in fine-tuning the parameters that will seamlessly intertwine the scorer, EAS badges, and the front-end. In this pivotal moment, our primary objective is to seamlessly bridge the gap between the data structure and design, leaving only a sliver of space for the Hadron Collider to unleash the most modular and scalable scorer contract for Karma.
We discussed the architecture in great detail because there isn't a clear standard on the internet to follow. We concluded that the best way to approach this was to observe other market players and understand how they register their grants. We observed the strongest projects, including Gitcoin, Chainlink, and Uniswap to come up with the following fields:
grantUID: bytes32 // Grant Id
network: uint256 // Blockchain network where the grant is being developed
protocol: string // Name of the protocol that issued the grant
grantee: address // Address of the person responsible for delivering and receiving the grant
project: string // Name of the project or company, that received the grant
externalLink: string // Link that redirects to the grant proposal
fundingToken[]: address // Tokens that will be granted
fundingAmount[]: uint256 // Amount of tokens granted to the grantee
initData: uint256 // Initial data for grant rewards and the beginning of grant development
endDate: uint256 // Expected completion date for the grant
status: enum(Status) // Current status of the grant
We considered the possibility of transforming this structure into an EIP (Ethereum Improvement Proposal) to standardize future development of grants.
We thought carefully about how the review process should work, the major challenge is ensuring that the person who receives the grant is indeed the one who will review the grant. And there is no escape but having the entire grant proposal registered on-chain. This way we can access the grantee, among other properties, and assure that the reviewer is indeed the owner of the grant.
We propose the following structure which contains the reference to the grant attestation, the grantee, the review date, and the badges that were reviewed with their respective scores. For now, we are thinking about storing badges as base 2 to save storage slots but still looking for non-exhaustive alternatives that avoid paginations and don't rely on lengthy arrays.
reviewUID: bytes32 // Review Unique Identifier
grantUID: bytes32 // Reference to the Grant's attestation
grantee: address // Who submitted (attested) the review
badges: uint256[] // The total sum of base2 values of all available badges
scorer: uint256[] // Value from 1 to 5 for each badge
reviewDate: uint256 // Review date in unix timestamp
Reflecting on the previous structures, we have the following workflow:
Grant Schema
shown above and having the grantee officialized for on-chain usage. We are still considering moving the Grant Schema to the Trustful Score because it will allow us to edit fields like status
, endDate
, and external links
. Which cannot be done using EAS.Review Schema
In the initial stages, we created the frontend-initial-design of the Review Section, with this we were able to create some Architecture to deal with the components related to the karma-gap infrastructure.
Looking at how the current Karma architecture is integrated, we created this to handle the new Review page feature:
Additionally: The folder structure was created to make the integration of the feature easy. Creating new components to replace the old “Reviews” and "Review this grant”, using now only the “Review” option. We won't be removing the old reviews as discussed with Karma.
For now, the frontend data is mocked. This data is not real data. In the next steps we will integrate the real data into these components. You can follow up current state in here: https://github.com/blockful-io/gap-app-v2/pull/2
We need to communicate with the blockchain through the Karma Gap application, specifically with the Ethereum Attestation Service (EAS) smart contracts, to create a permanent and immutable grant on the blockchain, which is the attestation of a single grant.
Considering this, within the Karma Gap project, we created a file that will run every time a new grant is created. It will automatically generate a unique grant on the blockchain that can later be referenced so that the grantee can review this grant.
At present, this file remains in its developmental phase, requiring further refinement to dynamically interact with varying dataset information. Currently, it operates exclusively with predefined data sets, laying the groundwork for its eventual full functionality.
To effectively showcase the grantee's review, we must retrieve the pertinent data from the blockchain. To streamline this process, we've developed a dedicated file tasked with managing these data retrievals. Upon submission of a review by the grantee, this triggers an event on the blockchain, encapsulating all necessary data of the grant, the review, and the user.
We use Subgraph to extract the required information, which is then displayed to the user through the frontend interface. Given the structured nature and widespread adoption of this process within the industry, our task primarily involves customizing it to fit within our specific operational context.
At the moment this process is not yet finalized, working only with predefined data, as it is necessary to have the architecture completed and finalized to know exactly what data we need to fetch from the blockchain.
There are two contexts in the smart contract at the moment: the Resolver Contract and the Scorer Contract.
Currently, the contracts are our smallest focus since our team is more experienced in the subject and can handle it more easily. The most important thing at the moment is having the architecture and design finalized and validated with Karma's approval.
Another challenge is to guarantee that other protocols will be able to use these data schemas for their scores. And that the old scores can still be used and recognized by future changes in the protocol.
Finalize the Grant Structure
Switch the Review/Write Review button
Enhance File Development for Grant Attestations
Finalize Data Retrieval Mechanism
Badge Registry Research