SmartContract Code OverView

The pilot project has a total of two Smart Contracts.

Marketing Reception Contract for writing and recording MDX Contract is a reward for the user and a payment method for the user We used ERC20 to create tokens that serve as a means of payment.

MDX (MadongX Token)

It used the ERC20 standard and added Pausible to prepare for special situations, BlackList to prevent fraudulent users, and MultiTransfer Token for administrators.

MarketingReception

Marketing Contract provides rewards to users who agree to receive marketing. Additional data is needed to manage marketing consent. So we separated the above functions into three Contracts: RewardPool, UserStore, and MarketingReceptionStore. Each Contract does not call each other, and each manages Reward, UserData, and MarketingReceptionData.

Improvements

Gas cost

Like Sign Up, in Smart Contract, a problem in which conditional statements are added or functions are separated due to specific data easily occurs. Even in this situation, if there was no userCount in UserData, the number of functions would decrease, and the conditions checked in the function that users call each time they register a text would decrease, reducing Gas Used by Transaction. It was necessary to calculate the need for gas and userCount that can be reduced due to the userCount variable

Preventing Abusing

All Transactions, such as membership registration and consent to receive marketing, are signed by the User’s Private Key. This means that the user can call the functions of Contract directly other than the method of accessing through the service. However, since all transactions generated in the service operate as Fe Delegated, there is no burden on the user, while accessing the contract directly is not a significant benefit for the user because the user has to pay the Transaction Fe directly. However, if the value of the token obtained by writing is greater than the Transaction Fee entered when registering a text, users will be able to view it regardless of the Transaction Fee. The easiest way to solve this is to sign Transaction with the administrator’s private key, not the user’s private key. However, this could easily prevent viewing, but it would not be able to utilize Klaytn’s Fee Delegated, and could mean losing ‘decentralization’.