Hackathon Issues and Tasks
Issues and Tasks for the Open Contribution Track of the Unstoppable Hackathon
During the Unstoppable Hackathon, in the Open Contribution track, you may work on issues in the issue tracker of the repositories of the sponsors and on tasks described here.
Issues
Good First Issues:
All issues:
Tasks
Here are some ideas of tasks you may take up and that would be specially valuable to the hackathon sponsors:
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.
Here are some examples of basic Ergo projects that you may look at to learn how to develop for Ergo.
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, Polygon, 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.
Use this KYA Template.
Links to all our social media accounts, telegram channels, discord servers...
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.
Almost all our repositories (in Stability Nexus, Djed Alliance and AOSSIE orgs) are lacking a "COPYRIGHT.md". Please add The Stable Order's COPYRIGHT.md file to every repo created by Stability Nexus or Djed Alliance orgs and AOSSIE's COPYRIGHT.md file to every repo created by the AOSSIE org.
All the frontend code in AOSSIE, Stability Nexus and Djed Alliance are licensed under GPL v3. However, most repos are lacking an explicit LICENSE.md file. For every frontend repo, please add this LICENSE.md file to the root folder of the repo.
Attention: do not do this to repos that contain smart contracts or to repos that contain both frontend and smart contracts. This task is only for pure frontend repos.
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.
Most of our projects need improved SEO (Search Engine Optimization).
Ensure metadata, indexing and content signals align with SEO best practices.
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 latter. Doing the former as well would greatly improve the user experience.
See, for instance, this issue in the Fate project, which is one the projects that is only doing the latter. But Fate is not the only one. This issue gives more details about how to tackle this task.
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.
For our Djed stablecoin projects on EVM, a lot needs to be done. We currently have two versions of the Djed Stablecoin Protocol (Osiris and Shu) implemented in Solidity. Furthermore, we have implementations that use ETH as the backing asset (both Osiris and Shu) and we have implementations that use ERC20 tokens as the backing asset (only Osiris). Only Djed Osiris backed by ETH has been launched on Ethereum Classic (see: https://etc.djed.one). Djed Shu backed by ETH is ready too, but has never been launched. The frontend for Djed Osiris is in the main branch of the Djed-Solidity-WebDashboard repo. The frontend for Djed Shu is in the feat/shu-frontend branch. For the implementations that use ERC20 tokens as backing assets, we have a frontend that allows users to deploy new stablecoins backed by any ERC20 token and use the deployed stablecoins. But this frontend is not completely ready yet. We also have a new Oracle project (see https://github.com/StabilityNexus/OrbOracle-Solidity and https://github.com/StabilityNexus/OrbOracle-EVM-Frontend) to allow users to deploy and operate oracles for the ERC20 tokens that will be used as backing tokens. We also have StablePay (see: https://github.com/DjedAlliance/StablePay , https://github.com/DjedAlliance/StablePay-MerchantWebsiteDemo , https://github.com/DjedAlliance/StablePay-MerchantDashboard and https://github.com/DjedAlliance/StablePay-LandingPage), which is a widget that allows payments to be done using Djed stablecoins, but it currently works only with Djed Osiris. Finally, the next evolution in the family of Djed Stablecoin protocols, after Minimal Djed, Djed Osiris and Djed Shu, is Djed Tefnut. This new version of Djed simplifies Djed Shu in the following simple ways: minimum and maximum reserve ratios should be removed, the
sellBothCoinsfunction should be removed, the linear decay of the treasury fee should be removed. Another new version of Djed is Djed Isis. Djed Isis simplifies Djed Osiris in the same way that Djed Tefnut simplifies Djed Shu.Considering all this, the following tasks are open:
Implement Djed Tefnut smart contracts with ETH backing. (Use the Djed Shu smart contracts as a starting point.)
Adapt the Djed Shu frontend to Djed Tefnut.
Deploy Djed Tefnut on a testnet and make it work with the Djed Tefnut frontend.
Adapt Stablepay, so that it can work with Djed Tefnut.
Implement Djed Isis with ERC20 backing. (Use the Djed Osiris smart contracts as a starting point.)
Adapt this frontend https://github.com/DjedAlliance/Djed-Solidity-ERC20BaseCoin-WebUI to work with Djed Isis with ERC20 backing.
To learn more about Djed, check the following resources:
Whiteboard Animation (A bit old, but short and still relevant)
First Technical Talk about Djed (a bit too long)
For our Gluon implementation on Ergo, we currently have a live deploument pegged to Gold (https://gluon.gold). We would like to make a new deployment, this time pegged to the USD. For this, we need a version of the frontend for USD. There was already a PR (https://github.com/StabilityNexus/Gluon-Ergo-UI/pull/96) that made everything that is peg-specific in the frontend part of a configuration file. This PR has not been merged yet. Here are some tasks:
Finish the PR, addressing the reviewer's comments.
Test the finished PR locally.
Create a PR for the configuration file for Gluon USD.
Last updated
Was this helpful?