Future Work
Some work that needs to get done :)
Looking to contribute to the protocol ?
Here are some upcoming upgrades that need attention. If interested let us know on the telegram channel, and or other Gitcoin.
System
Elegant Integration to Open Z's upgradeable system.
Simple Storage/Eternal Storage: May need to implement a simple storage/eternal storage custom solution for features.
Automation scripts: Starting/submitting/upgrading feature contracts.
On-chain contract feature submission process: Ability for contract owners to submitted contract for consideration of being included in the service as as service.
TheGraph.com GraphQL integration for indexing events for front end Dapp creators.
Proxy Upgrades: Update proxying of features to use an array/mapping design so that many features can be linked to the gateway without the gateway needing to be upgraded. This means removing all functions from the gateway and instead implementing a cyclicling scanning mechanism to check a list of contracts for the transaction method thats being called. Should be implemented into the fallback function. This would greatly reduce the need to add additional function to the gateway everytime a new feature is implemented.I cannot find examples of anyone doing this, so maybe we can start a medium article with this design and check what the security implications are.
Updating Feature Abstraction: Currently the Feature abstract contract needs to upgraded to include future design limitation/constructs, this means adding new functions and processes that contributors must utilize in order to submit features.
Design/Protocol
Feature: NFT YIELD: Create a feature for generating tokens based on and NFT's sold amount when transffering to new owner. These tokens are sent to the users that staked on those NFTs. (Staking -->Yield Tokens)
Feature: NFT Hot Deploy: Create a feature for on-chain deployment of NFT 7xx standard and 1155. Should involve users being able to call the huddln gateway to mint a custom token and return that new address.
Feature: Partner Fee (bps): Currently the Huddln service charges a fee on earnings as its business model, the protocol needs a mechanism that allows partners (DAPP creators) to add their own fee when their users call the service. This should all Dapp creators a way to create revenue. Could possible involve a new contract that has a mapping of datastructs that hold info about each partner, such as metadata (images, links, service contracts, wallet address).
Feature: Staked Huddls: Create an event staking feature that forces people that wish to attend to locked-up funds and can only pull their funds out when the host has declared they are present. Similar to Kickback except without the hassle and need to go through a process. This is more similar to a facebook event (simple, fast, intimate). How could it work? When a host creates an event that ID is sent to participants to join, when joining that must lock up funds into the contract and are given back a unique identifying ID number (hash ticket). When they go to the event, they present that hash to the host which will could scan that hash then sign and send that transaction back to the contract to show they are in attendance. Things to consider, this should probably be done in batches so many people can be confirmed via one tx.
Token Agnostic: Adding the ability to use any ERC20 token for staking features. Specifically, the first token should be DAI.
Last updated