Inspiration
How can you tell if someone is really a crypto enthusiast or just pretending to be one or better yet how can you prove to recruiters you spend all your time on-chain? TrustLink allows you to do that and more.
What it does
Our project bridges the Web2 and Web3 worlds by allowing you to mint an on-chain SVG SoulBound NFT, linking your GitHub account with your EVM wallet address and verifying your identity using Jackal. This immutable NFT serves as a record of your technical expertise and passion for Web3, enabling startups to easily verify both your crypto transaction and GitHub commit history. It simplifies the process of proving address ownership and facilitates identification of potential job applicants in the crypto space.
How we built it
React and Vite make up our frontend while JackalJS and Ethers for our blockchain connection. Our backend was made using Express to Github's API. The SoulBound Smart Contract is deployed to Ethereum’s Sequoia testnet at 0x45a47CE4a5423b0083272914bbF12c5E63C509a6. The Smart Contract is an ERC721URIStorage contract. It implements the Soul Bounding by adding additional functionality to the _beforeTokenTransfer and the _afterTokenTransfer functions.
//Override ERC721 _beforeTokenTransfer function so that these nfts cannot be transferred
function _beforeTokenTransfer(address from, address to, uint256 /*firstTokenId*/, uint256 /*batchSize*/) internal override virtual {
//If user is buring the token or recieving the token let it go through. Else don't allow
require(from == address(0) || to == myGlobalAddress, "You Cannot Transfer this token");
}
We add a required statement which will make any transfer not going to the zero address to revert.
//emit event Transfer if we burn or mint
function _afterTokenTransfer(address from, address to, uint256 firstTokenId, uint256 /*batchSize*/) internal override virtual {
if(from == address(0) || to == address(0)){
emit Transfer(from, to, firstTokenId);
}
}
In the _afterTokenTransfer function we override the functionality so that we only emit a transfer event when the user is burning or minting this Soul Bound NFT. Our Smart Contract is fully on-chain, eliminating the need for IPFS to store NFT images. By leveraging abi.encodePacked, we store metadata as encoded bytes, ensuring secure on-chain storage. Instead of relying on IPFS links, we store images as encoded SVG code. Additionally, our contract offers mappings for external users to query wallet addresses linked to specific GitHub accounts and uses chainlink gas optimization naming conventions
Challenges we ran into
During the development of TrustLink, we embarked on a journey to explore cross-chain verification with Jackal and Axelar. Although we encountered unexpected challenges and dependency issues, our perseverance allowed us to gain deeper insights into the protocol, ultimately revealing its tremendous potential as a groundbreaking solution in the blockchain industry.
Accomplishments that we're proud of
We take immense pride in the fact that our NFTs are stored directly on the blockchain instead of relying on IPFS hosting. Our strong belief in the power of on-chain NFTs stems from their inherent decentralization, surpassing the reliance on external networks like IPFS. Furthermore, our accomplishment in successfully implementing Soul Bound NFTs serves as a testament to our dedication and ingenuity in pushing the boundaries of NFT innovation.
What we learned
- Cross-chain SoulBound NFTs.
- onChain NFTs.
- Jackal storage system
- Dug deeper into the IBC ecosystem
- authentication with Github
What's next for TrustLink
- Cross-chain functionality with Axelar
- Using Jackal Fileshare when the feature gets out
- Hosting front end on AWS
Built With
- ethers.js
- express.js
- githubapi
- jackaljs
- react
- scss
- solidity
- tailwind
- vite
Log in or sign up for Devpost to join the conversation.