MBADGEs: Now and Future

Friday, March 29, 2024

TL;DR

Everything about MBADGEs

Intro

Reputation breathes because of its subjectivity. The whole internet has clusters of data points which are generated by user interactions over a period of time. When it comes to Web3, there are core users that simply adore the space and enjoy testing out new networks and protocols, in turn demanding benefits that they richly deserve.

Now we at Mercle imagine a layer that runs parallel to the whole of Web3 listening to these interaction points and bringing them under a common decentralized body to unlock the true potential of a user’s interactions.

What’s tough to index is never indexed; many of these data points are lost due to the difficulties of indexing and labeling a user’s web3 interactions. We believe that such data points will be extremely valuable and reusable in web3 to reach the right audience for a variety of purposes, including assigning new Core Contributors to a DAO, protocols for airdropping tokens to early users, bounty runners to catch bad actors, collecting multiple identity infrastructures to create a unified source of truth, and so on.

Mercle Network aims to create a “decentralized reputation network” a parallel chain that communicates with the entire web3. This network will duplicate the concept of attestations, incorporating them into transactions as an on-chain indexable log. These attestations like structure become the building block of your reputation.

Attestations & MBADGEs

As we previously discussed, attestations are the building blocks of your reputation on Mercle. They assist you in creating your own little network of contributions, which others can access in an indexable method.

MBADGEs are supporting these building blocks by acting as an ad-hoc version of the attestation logs on the Mercle Network.

They are externally deployed (out of Mercle Chain) means of collecting and storing user attestations for that ecosystem. For example the Blast Bridger MBADGE was deployed to track the bridgers who enter the Blast ecosystem. Holding your MBADGE in your wallet puts forward a green light to our data oracles to track and generate attestations for your actions.

Technically MBADGE is your usual ERC-721 NFT with your attestations being stored inside them with an EIP 712 standard. The beta version of the Mercle Network involves the “Attested” stage. Here signed data is generated by Mercle or community admins to confirm that the user has successfully completed the task in question. Here’s a breakdown of the attestation data sets.

How do they work?

Here’s a breakdown of the sample URI.

Domain

The “Domain” contains context about the NFT token for which the signature is intended. Here’s what each field represents:

name: This is either the task title or the content description. For the MBADGEs Mercle oracles are acting as a general verifier hence the general name Mercle Attest Claims
version: Contrary to what the term usually indicates, this is the NFT token ID, not the contract version. Here — 859
chainId: The chain ID where the NFT token resides. Here — 534352 (Scroll Mainnet)
verifyingContract: The contract address of the NFT token. Here — 0x9c31e124C34C9743bf9631136CB6c5F91DF529B9

Types

This contains the data types of the attributes used in the message.

Message

The “Message” provides information on what has been successfully verified by Mercle or the community admin.

requesterSign: This is the exact signature from request.sign, confirming that what the user stated is accurate.
to: The receiver of this credential.
from: The issuer of this credential. During verification, ensure that the verified signature matches this from.
timestamp: The time when this credential was issued.
blockNumber: The blockchain block at which this credential was issued.

Verification

For the credential to be considered valid during verification, the following checks are important:

The sender (msg.sender) should match attested.message.to.
The signed data from the credential (signFromCred(...attested)) should match attested.message.from.
The issuer should have the role defined by keccak("CLAIM_ROLE_ISSUER").
The verifying contract’s address (address(this)) should match attested.domain.verifyingContract.

What do I get by holding these MBADGEs?

We previously mentioned that the primary goal of Mercle Network is to develop a unified layer of contributions; by collecting these MBADGE, you are among the to communicate with our network. The network allows everyone on the internet to find you and your contribution history in a consistent manner.

Now as these MBADGEs hold your contribution claims they are directly adding up to this story, and building your reputation on the Mercle Network. The attestations inside them become a part of our current 1.1M+ attestation data cluster which for others including you support the calculation of your reputation.

Hands Of Support NFT

MBADGE holders needs to be incentivized fairly. We are on the verge of pushing a big update around the dApp and user flows which is the next step towards, Mercle’s Testnet. We will be taking snapshot of the current MBADGE Holders and incentivize them with the Hands Of Support NFT, these NFTs will be available for direct claim based on the number of communities in which they have engaged, i.e. collected MBADGEs.

What’s next for MBADGEs?

The plan is to deploy these MBADGEs on 20+ L1 L2 AND L3 and allow the collectors of these NFTs to collect attestations of the set labels. Currently we are rolling out the NFTs on the Mercle dApp with basic labels like bridging swapping trading, in few weeks we’ll be adding more labels for users to collect.

Why am I paying a mint fee?

The mint fee for MBADGEs plays a dual role. Firstly, it protects against Sybil attacks, ensuring the network’s integrity against malicious actors. Secondly, it helps manage network congestion, supporting the establishment of robust data liquidity. This fee is crucial for bootstrapping the data liquidity, ensuring availability and reliability for all users. It helps us strike a balance, managing network costs while promoting growth and scalability.

Importantly, funds from this fee go directly to our treasury. The mentioned addresses provide transparency, giving stakeholders insight into resource flow. With oversight and strategic allocation, we’re committed to maintaining a secure and trustless environment in near future.

All the tokens submitted by users through EVM chains are first transferred to this address. Mercle admins then move the community treasury to a Gnosis Safe and another Cold Wallet deployed on Polygon (POS).