Hackathon Task Ideas
During the Unstoppable Hackathon, you are free to work on any ideas you would like. The more aligned with the Hackathon goals of unstoppability and the more valuable these ideas are to the sponsors, the higher the chances of winning. Here are some ideas of tasks you may take up and that would be specially valuable to the hackathon sponsors:
Solve good first issues in the repos of the sponsors.
TODO: Good First Issues in Repos of Ergo.
Solve harder issues too (issues not necessarily tagged with "Good First Issue") in any of the GitHub orgs mentioned above.
Solve Ergo bounties.
Take an EVM project of ours and port it to one of the non-EVM chains that The Stable Order currently supports: Ergo, Cardano, Sui.
We would specially welcome porting to Ergo, since Ergo is a sponsor of the Hackathon.
Take an EVM project of ours whose smart contract has been deployed to only a few of our supported EVM chains and deploy the contract to another supported EVM chain or to a new worthy EVM chain that we do not support yet.
Our supported EVM chains are Ethereum Classic, Ethereum, BSC, Base, Citrea Testnet.
A worthy not yet supported EVM chain is a chain that shares our values and principles and has a good chance of long-term sustainability.
Please talk to us to know the constructor parameter values.
For an EVM project that has been deployed to a new chain, update the frontend with configurations to connect to the new chain.
All our frontends should have a footer. If you find a frontend missing a footer, you are welcome to add one.
All our footers should have all the following elements. If you find a footer missing any of these, you are welcome to add them:
Copyright statement of the form "© 2025 The Stable Order" (for frontends in the repos of the Stability Nexus or the Djed Alliance) or "© 2025 AOSSIE" (for frontends in the repos of AOSSIE).
KYA (Know Your Assumptions)
Bene for Ergo is a project that does KYA very nicely, as a modal that is shown when the user first visits the website and also when the user clicks the link in the footer. We should follow this approach.
Links to all our social media accounts, telegram channels, discord server...
All our projects (in Stability Nexus, Djed Alliance and AOSSIE repos) are supposed to have a ReadMe according to this ReadMe template. But, because some of our projects are older than the template, their ReadMe files still do not follow this template. The task of updating these old ReadMe files would be very valuable for ourselves, because style uniformity across repos conveys professionalism.
Most repos that are already using the new ReadMe template are nevertheless still missing a "Project Maturity" section in their ReadMe files according to the template. Adding this section is valuable because it makes it easier for us to see what remains to be done to make the project more mature.
If you take up this task for any of our repos, please analyze the maturity of the project and check the checkboxes that can be checked.
Some of our projects are still missing favicons and it would be valuable to add them.
Many of our projects need better open-graph metadata to be displayed nicely when shared in Twitter, Discord, Telegram, LinkedIn, ...
If you take up this task for any of our repos, please include, in the PR's description, screenshots of how the project looks like when shared in Twitter, Discord, Telegram, LinkedIn, ...
All our projects need to be shareable more easily, so that they can be discovered by users more easily. We should add discrete, but visible "Share" buttons in their frontends. Clicking on the share buttons should open a modal allowing the user to choose a social media platform and then redirect the user to the chosen social media platform, preferably with a pre-filled message already written. The pre-filled message should tag our accounts.
Some of our projects have frontends that do not display well in mobile browsers. The sizes of elements do not adjust well. Making our frontends look good in all screen sizes would be very valuable.
Some of our EVM-based projects rely on ReOwn's WalletConnect libraries/SDKs to handle wallet connection. But ReOwn is becoming increasingly centralized, requiring all projects to have a project id, imposing usage limits and becoming able to censor any project from using its libraries/SDKs. Implementing alternative multi-chain wallet connection methods without such drawbacks would be very aligned with hackathon's unstoppability goal.
Some of our EVM-based projects allow users to deploy contracts while choosing a custom ERC20 token that the deployed contract should use. All such projects should allow users to either choose an ERC20 token from our list of supported tokens or input the ERC20's contract address. But some of our projects are currently still only doing the later. Doing the former as well would greatly improve the user experience.
Many of AOSSIE's projects currently depend on centralized services, such as backend database servers, AWS, GCP, various LLM APIs... This traps AOSSIE into providers of such software/infrastructure as a service. Truly free and open software is software that can be run locally, permissionlessly, without being dependent on companies that may decide to shut down, "enshitify" or raise costs of their closed and non-free services. Therefore, the following ideas would be useful for AOSSIE:
When a project depends on a paid external service API, make it possible for the end-user to provide their own API key.
When a project depends on a paid external service and there are many providers of similar services, make it possible for the end-user to choose which service to use.
Consider replacing the dependency on a external service by a local internal alternative. For instance:
Sometimes data that is being stored in a database server can be stored locally in the user's browser using localStorage or indexedDB and giving the user the option to back-up this data to his/her computer or to his/her own cloud storage.
Some of AOSSIE's AI projects could consider using in-browser or in-device LLM models, instead of relying on external LLM APIs.
Our Bene project for EVM (https://github.com/StabilityNexus/Bene-FundRaising-EVM-Contracts and https://github.com/StabilityNexus/Bene-FundRaising-EVM-Frontend) was made for fundraising in ETH. We started generalizing it to allow fundraising campaigns that accept any ERC20 token, but we haven't finished it. Finishing this generalization would be great.
Last updated
Was this helpful?