Toban -当番-
What it does
Toban is a simplest way to record contribution and distribute rewards.
Projects that involve a diverse people, such as open source development, collaborative works by multiple creators, and volunteer activities, and in which the people involved change one after another, can be very exciting, but they also have their own unique difficulties.
For example
- Annoying to Track Works:
- It's very tedious to report what you've accomplished for each task
- Nobody are running a community to measure contributions by weighting each task.
- We always forget anyway lol
- Rewards are required for Long term Contribution
- There is no long-term contribution, just a volunteer spirit
- There is no money to give out of the blue, and no one starts because of money.
- Someone needs to do the housework and chores
- Ladder for Onboarding to the Community
- Few people can participate on their own
- It is difficult to understand the community enough to actually be able to do something
- It's important to have a starting point that makes it easy to contribute something
Therefore, we created Role Based Rewards Distribution system to track contributions and distribute rewards by role.
Core features are
1. Manage responsibilities and rights on rolls
2. Track little contributions with P2P token transfer
3. Determine the rewards rate based on roll and engaged period
4. Distribute rewards quickly to a large number of people
These solutions were combined with ideas from Hats Protocol, Splits, and Protocol Guild.
Challenges I ran into
During this hackathon, we challenged ourselves to understand and integrate the technical features of multiple protocols. This integration was particularly challenging for us.
Specifically, we worked with Hat Protocol, Sprits, ENS subdomain mechanisms, and the INTMAX Wallet SDK.
Technologies I used
contract side
- HatsProtocol
- Splits
- Protocol Guild
- OpenZeppelin Defender
- hardhat
- ethers.jsV6
- OpenZeppelin
- ENS
frontend side
- Next.js
- Chakra-UI
- INTMAX Wallet SDK
- MetaTransaction
- HatsProtocol SDK
- OpenZeppelin Defender
How we built it
What we learned
During this hackathon, we explored the technical features of multiple protocols and learned their detailed technical specifications.
Specifically, we studied the technical specifications of Hat Protocol, Sprits, the ENS subdomain mechanism, and the INTMAX Wallet SDK.
Bug Report
We found a bug of cabinet RPC URL.
I discovered a bug where meta-transactions are not processed correctly when using the Cabinet RPC URL.
Specifically, I was unable to generate TypedSignedData that includes a tuple of objects.
*Note: The same code worked correctly when using the Alchemy RPC URL.
What's next for
1. Creation of Big Bang transaction (making it possible to mint Hatter Hats to TopHat, HatterHat, and TimeFrameContract in a single transaction)
2. Modification to adapt Hats.sol, which was written in Foundry, to HardHat
3. Expansion of Hats Module (integration with other protocols such as Safe and Collab.Land)