Background 🏛️


This article will focus on the web3 use cases according to our Feature List, I will briefly talk about the reason of chain selection, polygon, and whether and how to support interchain transaction.

Chain Selection ⛓️


The reason we choose polygon is for its cheap transaction fee and faster confirmation, we foresee the transaction we host may be sized up to millions per day, putting those transaction on etherium mainnet would be multi million dollars per day only for transactions which is not realistic. Therefore polygon is a long tested and secure option of chains for transaction.

Use Cases ☑️


3.1.Login(AuthE and AuthO)

Magic.link will handle the authE and our backend and smart contract will control authO. It provides polygon as one of the supported chains.

3.2. UUM distribution, airdropping

After we have the list of users, we may list certain users to airdrop

3.3. UUM trading or exchange (polygon or other chain)

For users who are interested to trade on polygon, it is naturally supported as UUM sits on polygon, however, if user wants to exchange or trade on mainnet, we would need to provide a polygon bridge mapping. It is not very economic for users to convert tokens to mainnet back and forth, the machenism of tokens to go across chains for our case, is initially to mint UUMs in polygon, and transfer to mainnet(1. burn the tokens in polygon and 2.mint them in mainnet).

3.4. Course Content NFT, Badge NFT

ERC721 tokens will be minted to the creator, the basic NFT structure is:

1.png

For json formatted metadata, it could be composed in three ways.

2.png

Method 1: we store the information of course like image, title, creator inside IPFS, and get the contentID from IPFS and register it inside NFT.

3.png

Method 2: we store the information inside some online storage like AWS S3, GPS Storage, and put the link inside NFT.

4.jpg

Method 3: The metadata is stored in a server, so the endpoint is put inside NFT.

Method 1 is immutable, however method 3 provides the most flexibility. Since we are in a phase where the fields could be changed from day to day, it is better for us to put into a server so changing the metadata would not involve generation new contentID or putting inside online storage causing new link, and both of this requires update of the token info on chain frequently and hard to manage in a batch.

3.5. Course Share Token

Course shares would be transferable to represent partial ownership, thus it could be represented by ERC1155, and it will be linked to a course. People can gain ownership by staking their UUM in the project or initial crowdfunding or later transfer to others.

The Entity relationship between contracts including controller, course, badge and shares is like below:

5.png

The controller can mint course and share by calling course and share contract, also mint badge with badge contract.

The infrastructure design is like below:

6.jpg

The contract interaction service is the controlling service to calling smart contract written in golang, take NFT minting process for example, it calls mintCourseAndShares method in smart contract ContinuumController.sol contract after the token is minted, it listens to minted event and the event carries the tokenID, it then pings metadata service to create the metadata for that tokenID.

Conclusion ⬇️


The use cases of web3 on the platform encompass the creation, transfer of $UUM and NFTs, ERC1155s to facilitate and forge the vision for our education service, which embodies the realization of gamification to incentivize the lifelong learning of frontiers of knowledge and incubate a learners’ community.