Journal3 - Live on-chain Resume
Allowing data scientists and devs to create on-chain credentials from their validated work on Kaggle, Google Colab, Github, and Research Publications
Project Description
Candidates need help with subjective job descriptions, and recruiters cannot objectively evaluate PDF resumes at scale. Journal3 converts job descriptions into decision trees that candidates can "function call" with their wallet addresses. Each node in the decision tree is an NFT address representing a specific skill requirement that gets compared to all the skill NFTs present on the candidate's wallet address. Candidates receive skill NFTs when their work history is validated and mined by on-chain participants. This helps the user maintain a "live" resume always in their metamask wallet. So they can focus on building, not creating pdfs after every git push :)
This is a significant improvement over the internal testing and certification features on sites like Fiverr, Linkedin, and Upwork. Our solution is better as it hands over control of the credentials back to the users allowing them to import it efficiently as opposed to Linkedin auto-fills. Our token-gated job listing process will enable recruiters to assess candidates more objectively. Since the credentials reside on your Metamask, candidates can use them in pseudonymous job applications.
How it's Made
-
Protocol Design: We knew we wanted to build a decision tree of skill NFTs that depended on proof of work. But the remaining parts of the protocol architecture took a lot of debates and trial/error to perfect various components, especially token creator royalties, validator ROI, and byzantine attack scenarios.
-
Data-Definition Language: Since our tokens have conditional mint, we wanted the token creator to have maximum flexibility short of deploying separate contracts. Finally, we decided to move ahead with a modified/minimal version of the MongoDB query schema.
-
Frontend Integrations: Since we had to spend a lot of time perfecting the protocol itself, we did not have enough time to create a full-fledged UI, so we went with a CLI interface and only included UI components for the core visualization we needed in terms of the platform, i.e., the decision tree made.
