Scamscan | Devpost

Title
screenshot for minting a reputation sbt
Mainpage
screenshot for checkon a reputation sbt

Inspiration

We came up with an idea for Scamscan with the question, "Why are there so many frauds and attacks in crypto?” One answer is that it’s because there are no disadvantages to their malicious actions in crypto. However, if we have a distinct reputation, we can make people hesitate to harm someone and protect them from attacks.

What it does

This is the place where our solution begins. Scamscan has 3 main features for reputation. The first one is Positive / Negative Reputation Points. In Scamscan, you can mint reputation SBTs for positive and negative points up to 100 points at once. The second is verifying the transaction log. Only the people who have interacted with a certain account can mint reputation points for that account. Scamscan would verify the transaction log that you submitted and authorize you to mint reputation points. And the last one is the Quadratic Burning System. You need to burn the square of reputation points you want to mint. For example, you can mint 4 points by burning 16 MATIC.

Additionally, we would charge 10 MATIC as a constant fee to prevent malicious distortion of reputation with a low fee. We could express the total fee as below:

p = reputation quadratic burning c = constant fee = 10 MATIC r = gas fee

R = total fee = p^2 + c + r

With these three features related to minting the reputation, represented in SBTs, Scamscan could warn people when trying to interact with malicious actors.

How we built it

We built an ERC721-like SBT(SoulBound Token) contract that inherits EIP712, IERC721Metadata and ERC165.

The main feature of our product is implemented in give function.

A user can mint a RepuationToken and give it to one the user had interacted before. In specific, a user submits a transaction hash that s/he was on sender's side and give the minted SBT token to the transaction recipient, after burning some amount of asset(e.g. MATIC) following quadratic burning mechanism.

Transaction hash used for ReputationToken is stored and managed in BitMap to verify that only one SBT could be minted and sent from a transaction.

The mapping of address to received SBT tokens & total reputation score is managed in the ReputationToken contract to ease querying each address' balance and reputation score.

Challenges we ran into

From the contract’s point of view, we faced the lack of a mutually agreed interface that implements the nascent concept of SBT (Soul-Bounded Tokens). The developers had researched the draft proposals on the EIP board — Ethereum Improvement Proposals — to adopt the basic idea of implementation, including ERC735, ERC5107, ERC1238, and more. We have chosen to follow the underlying interface of ERC4973 in that the exemplary application is well-organized, so that our project has been influenced.

In addition, we have implemented the EIP712 standard to permit users to sign the transactions before giving out new SBTs to other users. A user can sign transactions off-chain which other users can later execute on-chain. To achieve this, we added a salt value that functions as a disambiguating entropy on top of the existing draft-EIP712.sol file. In order to execute tests that verify the signing procedure, we learned and adopted the eth_signTypedData_v4 method, which is provided by MetaMask.

The problem from the frontend's perspective was that each input had an organic relationship when receiving parameters to mint an SBT, and multiple verifications were necessary. We utilized the react-hook-form library to address this issue. This allowed for smooth validation processing. It was attempted to show that the user was loading through skeleton UI and spinner so that the user did not depart during verification logic.

Accomplishments that we're proud of

SBT is expected to be a concept to lead innovations in the crypto ecosystem. However, the technical implementation and usage of SBT need to be improved yet. One of the uses of SBT is creating a reputation system. Scamscan suggest a glimpse of how can we build a reputation system using SBT technology. We anticipate Scamscan could enable the contribution of participants in the ecosystem to be rewarded and prevent misbehavior including scams, fraud, rug pull, and malicious attacks by helping users to distinguish suspicious accounts.

What we learned

We have learned how to make an optimized project to achieve its purpose. First, we defined our number one purpose that needs to be solved. It was useful for us not to lose direction. Second, we select a strategy that could minimize attack points. It’s impossible to remove all possible attack points, so it’s important to choose a strategy that could alleviate malicious attacks with the most simple solution. Third, we learned how to design UX to maximize the project’s advantages with an easy-to-use product. Finally, we learned how to build a project with released contracts and open-source codes.

What's next for Scamscan

We are planning to add some features. First, we would show a scatter graph of someone’s reputation. Second, we would provide API service to build other projects or analyses on top of Scamscan. We are also considering introducing some additional strategies to prevent attacks including reset reputations, limitation of minting, and many more.