The problem Scamscan solves

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.

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 (Soulbound Tokens) 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.

IPFS Hash: Qmb69c2aRcjW4LVsLtgsoczP7joJWhj3jgNfFi7pEjRWwj

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 (https://eips.ethereum.org/EIPS/eip-4973 / https://github.com/shunkakinoki/contracts/blob/main/contracts/EIP4973/src/EIP4973.sol) in that the exemplary application is well-organized so 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 MetaMask provides.

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, and 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.