forReal.io

Inspiration

In a post covid world, scams are everywhere, and it has become harder than ever to discern authentic luxury items from fakes. Despite this, consumers are purchasing more than ever, and they have been at the mercy of such scams, till now.

What it does

We created a decrentralised validation system using a mobile application. This system consists of buyers, sellers, and validators.

Sellers request for their products to be validated, the product then gets added to a product pool. The sellers must pay a 2% tax for this service.

Validators randomly get assigned to validate an item, for which they can accept or decline. If they decline, they are timed out for some time, to prevent repeated requests and collaboration between seller and validator. If they accept, they will stake 25% of the product's price for the privilege to validate it. It is then up to the validator to perform off-chain research about the seller and product. For each successful validation, validators receive 1% of the product's price as a reward, while the other 1% goes to the forReal.io.

Buyers can search for products they are interested in to see if they have been validated, and by who. They can do so using a unique product id, assigned to each registered product.

How we built it

The building blocks of our backend lies on a Solana on-chain program, also known as smart contracts in some other blockchain.

As we want to focus on the decentralization of the validation process, we build the an on-chain program that stores states of any transactions made on forReal.io, as well as handling any monetary movements between buyers and sellers.

Accounts in Solana would be able to store and keep hold of lamports (A fractional native token with the value of 0.000000001 Sol) from the buyer, to prevent the case of "non-paying buyers". But the sellers would not be able to receive the lamports unless the buyers and validators confirmed the transaction.

We conceptualized 3 types of validators:

internal: in which the validations are done on automated basis by our on-chain program, out of which has the lowest cost for the buyers and sellers.
manual: public validators who are going to validate transactions in a manual process, validators are chosen based on randomly assigned basis, out of which has the allowance to be up to 10% rate as cost for the buyers and sellers.
auto: public validators that are able to validate based on a self-implemented validation process, this can open up to public validators to any sort of implementations they could develop, such as through the means of AI-based validations. This is mainly interfaced through cross-program-invocations on the Solana blockchain.

Anchor framework was heavily used in the program to handle the building of the on-chain program. With Anchor, we are able to let Anchor do a lot of the heavy work behind the scene for building a Solana on-chain program and solely focusing on the building of account struct and how each instruction behave on-chain.

With mainly 3 instructions: Initialize, Confirm, and Reject. These 3 basic instructions handles how the on-chain state changes based on the outcome of the transactions.

Difficulties faced: One major difficulty we faced, was the limitations by Solana DevNet rate limits. Because of the rate limits, we weren't able to test a lot of the features in a smooth rate, which result in difficulties for on-chain debugging, as our program does require testing across various users. This caused testing and debugging on Localnet hosted testing ledger to be very difficult to test our program logic.

Another difficult we faced was to do with the poor integration that was built with Flutter and Solana's wallet solutions. With many attempts to connect wallets, such as Phantom Wallet to the Flutter application, we weren't able to secure a stable connection between the Flutter application, Phantom wallet, and Localnet ledger.

Accomplishment we're proud of: With the limited time and manpower of 2 people, we were proud to have developed the desired frontend interface on Flutter, and deployed the on-chain application on Solana's DevNet ledger.

Opened API endpoints: http://ec2-35-77-45-186.ap-northeast-1.compute.amazonaws.com:3000/api/v1/initialize http://ec2-35-77-45-186.ap-northeast-1.compute.amazonaws.com:3000/api/v1/confirm/{accountPubkey} http://ec2-35-77-45-186.ap-northeast-1.compute.amazonaws.com:3000/api/v1/reject/{accountPubkey}