-
-
Landing hero in light mode
-
Landing features + CTA in light mode
-
Dashboard Call to action
-
Profile with a yield vault display and back CTA
-
Dashboard in dark mode with some empty views
-
Back a project with Matic or ERC-20 (has to be whitelisted by protocol governance)
-
Dashboard in dark mode
-
Create a profile form
-
Dashboard with some data
-
Deposit into a profile's yield trust vault
-
Withdraw from a profile's yield trust vault
-
Dashboard -- Claim yield from own yield trust vault in dark mode
-
Responsive dash at smaller screen size
-
Stored IPFS metadata json example
-
Balaji gets a special tag!
-
Project types
-
Profile types
-
Intermediate IPFS upload step when creating a profile -- had to upload to supabase then to NFT.storage so as not to share my API key!
Repositories
Contracts -- the protocol:
https://github.com/bk62/buidl-protocol
Frontend -- a Dapp interface
https://github.com/bk62/buidl-protocol-app
Inspiration
Lens Protocol, Lossless lottery and ERC-4626 vaults (Rari, PoolTogether), Gitcoin, RabbitHole, Pointer, Chainlink Hackathon
Also inspired by Balaji Srinivasan's writings and talks about Defi matrix and mirrored cap tables.
Initial idea
Since I've only been learning web3 for a couple months ago (since I watched Patrick's 16hr Freecodecamp tutorial), I initially wanted to do a simple on-chain fundraising platform.
In the meanwhile, I encountered PoolTogether which gave me the idea of using Lossless yields as a fundraising mechanism. I learned about ERC-4626 compatible vaults from that community which I've used in this project.
Pointer.gg, RabbitHole -> ?? -> Gitcoin & Profit
While on my web3 learning journey, I was quite fascinated by Pointer and Rabbithole, and that companies like Polygon and Solana were willing to help finance people learning to use their technologies. After learning about Gitcoin, I felt that there was a step missing in the learning journey of beginning web3 developers. While you could get paid to complete tutorials or to close actual issues and bounties in production ready projects, there wasn't anything incentivizing intermediate projects, toy and prototype projects -- e.g. toy ENS system, command line and for-developer tools etc.
Building small-medium projects is a great way to learn and I thought that some companies should be willing to finance this for the same reasons chainlink is organizing and companies are sponsoring this hackathon.
E.g., if I wanted to build a project combining PoolTogether, Lens, Chanilink, Polygon and Filecoin, I'd rather have these communities discover my project/idea and "invest", rather than have to apply to each separate grant.
I also wanted to add Defi -- specifically contributing yields -- and crowdsourcing to the equation.
Various communities, I believe, have a great incentive and desire to encourage #buidling on their favorite stacks and platforms. Also, it'd be a great way for people to incentivize projects they'd like to be made -- whether its for actual use as in the case of tooling or to learn from as in the case of prototype projects (e.g. the contracts in solidity by example).
Lens Protocol
Reading the Lens protocol contracts was quite fascinating. I really like the idea of issuing NFTs for interacting with the protocol and the modularity that Lens prioritizes. The code base organization was also interesting and obviously extendible. Which is why the buidl-protocol
contracts repository is heavily and wholly inspired by Lens -- in fact I've pretty much implemented every method by referring to Lens. The code is often 90% similar but I've implemented my contracts line by line by referring to Lens but not copying anything unless I understood exactly what was happening.
What it does
Major concepts:
The terminology is a bit arbitrary based on the vision I had for the platform.
Profiles
Profiles are NFTs issued to wallets. They are meant to indicate a single github account i.e. an individual, team, organization etc, but could be used in any way users want.
Images and ERC-721 metadata json file are uploaded to IPFS+Filecoin via NFT.storage.
A github username is stored on chain and on IPFS (I use Github oauth via supabase) to indicate "validation" that the wallet is connected to the github account.
Complete anonymity does not make sense IMO for creators as they need to atleast showcase their projects, so hybrid web2-web3 -- web 2.5 -- approaches are necessary.
Projects
Projects are meant to represent a single project i.e. a single github repository.
Images and ERC-721 metadata json file are uploaded to IPFS+Filecoin via NFT.storage.
A github repo name is stored on chain and on IPFS (I use Github oauth via supabase) to indicate "validation" that the wallet "owns" the project repo.
Backers
To "back" a profile is to support or contribute to a creator or team of creators. The issued NFT might be used to airdrop tokens etc at some later time based on well thought out criteria as the Optimism protocol is doing.
The only back module currently implemented clones and deploys an mintable ERC-20 contract that mints erc-20s to backers based on the USD price set by the creator. Contribution amounts are converted to USD via chainlink pricefeeds and the profile's ERC-20 tokens are issued accordingly.
Investors
To "invest" in a project, is to contribute to a specific undertaking by creator/team.
Similarly to projects, NFTs are issued on investments.
Yield Trust Vaults
Profiles can create ERC-4626 vaults for each whitelisted ERC-20 token. The current vault implementation is meant to deposit into Aave pools. The depositors always get a 1:1 assets:shares ratio. All the yield is only claimable and withdrawable by the owner of the corresponding profile NFT.
How I built it
I wrote the contracts in the github.com/bk62/buidl-protocol repository. The frontend has been separately built in the github.com/bk62/buidl-protocol-app repository. Since the contracts comprise an entire protocol, the frontend is just one vision for how the protocol could be used.
Contracts overview
Core
BuidlHub
- entry point for all interactions
BackNFT
- implementation of NFT given to backers -- proxy clones deployed per profile
InvestNFT
- same as above for project investors
Modules
BackerOnlyInvestModule
- can only invest in a project if already backed the owning profile
InvestERC20ICOModule
- wip - Deploy and distribute ERC-20s based on fiat USD price per token (protocol stores price feed addresses for all native and whitelisted erc-20 tokens)
BackERC20ICOModule
- Deploy proxy clone mintable ERC-20, mint to all backers based on some fiat USD to profile's ERC-20 ratio
Libraries
BuidlingLogic
- create profiles, projects, deploy their NFT proxy clones etc
FundingLogic
- back profiles, invest in projects logic
TokenURILogic
- build token URI metadata JSON string from on-chain data dynamically -- should be useful for github based reputation score extension
Event
, Error
, DataType
etc - self explanatory
Defi
IERC4626
- ERC-4626 interface copy pasted from another project
IYieldTrustVault
, YieldTrustVault
- 1:1 assets:shares vault where the creator profile NFT owner claims all the yield for themselves
etc
Polygon Mumbai Deployment
Deployed contract but, unfortunately, ran into issues configuring the protocol and needs some debugging.
The contract addresses are:
{
"deployer": "0x35E9c78125466bFC5484C61800Ef1d66FbA54379",
"governance": "0x35E9c78125466bFC5484C61800Ef1d66FbA54379",
"hub": "0xab81eF797E580967505Bd34fb96eF50472a0CfcE",
"backNFTAddress": "0x727ec6581903c0e0c08a62f1f5a57ce227a66f78",
"investNFTAddress": "0x217866e368b34edd2ca6f3a1bd1fb08e8703aa1f",
"ytVaultAddress": "0xdb01a19c440f648fa0b729abc08c26321e1f99ff",
"erco20IcoAddress": "0x43de18b5583acdca45f6769e8974db8e3feb7eb6",
"buidling-logic-lib": "0x576bCb8aa6379820e99b64CA3F8eA537a18F4A83",
"funding-logic-lib": "0x1f8d263e3db90E6a26E714EF93330eb572514466",
"token-uri-logic-lib": "0x811B680a099D10EC177E70956BceB9c08DE3f902",
"backerOnlyInvestModule": "0x23cF4C58441D886e55434C6ded64305c0469AEfF",
"backErc20IcoModule": "0x15E82DF4d00799ff00FC3257Cbd5Dc7A538e0d1F"
}
Polygon scan of deployer account
Challenges I ran into
The biggest challenge was not getting excited about all of the cool extensions and features that could be built, while getting sidetracked from what could be built by one person today :)
Both the contracts and frontend codebases have gotten quite large and complicated.
Long solidity methods that often lead to stack too deep errors. Some hard to debug errors that hardhat was unable to identify -- usually calling the wrong contract.
I've had to abandon a lot of the initial implementation plans like random NFT modules, chainlink any-api + external-adapter based reputation scores based on github forks & stars, using chainlink keeper + PoolTogether inspired Time weighed average balance to periodically reward Yield Trust Vault depositors based on the amount and times they stayed in the vaults etc.
What's next for Buidl Protocol
I think there is a germ of a good idea for an actual project that people would find useful here. Depending on the feedback I get, I think deciding on a set of MVP features to implement and launching a production ready MVP might possibly be a good idea.
But first, lots of debugging, testing, refactoring etc.
Then maybe implement some extensions mentioned above.
Running it locally
Clone both the repositories into the same folder.
mkdir buidl
cd buidl
git clone https://github.com/bk62/buidl-protocol
git clone https://github.com/bk62/buidl-protocol-app
Install requirements in both repos:
cd buidl-protocol-app
yarn
cd ../buidl-protocol
yarn
Create .env
files in both repos based on example env files. NFT storage, supabase API keys needed for frontend -- or simply simulate NFT storage by referring to .env.example
.
Deploy the contracts
yarn hardhat node
Unpause and seed contracts
yarn hardhat unpause --network localhost && yarn hardhat seed --network localhost
Start the frontend app
cd ../buidl-protocol-app
yarn next
Built With
- chainlinkpricefeeds
- filecoin
- hardhat
- ipfs
- nextjs
- nft.storage
- polygon
- react
- solidity
- typescript
Log in or sign up for Devpost to join the conversation.