Feel free to dive in! Open an issue, start a discussion or submit a PR. For any inquiries or feedback, send us an email.

Contributions to Asylum Labs are welcome by anyone interested in writing tests, improving readability, optimizing the build, or extending the protocol via new features.

You will need the following software on your machine:

Familiarity with Solidity and contract ABIs will be helpful but not required for frontend-only contributions.

First, create a fork of this repository to your GitHub account. You can do this by visiting the repository page and clicking the "Fork" button in the top right corner.

• Asylum Labs dApp
• Asylum Labs Contracts
• Asylum Labs Testnet

Once you have forked the repository, clone your fork to your local machine:

git clone https://github.com/<your-username>/asylum-dapp.git

To keep your fork up-to-date with the original repository, add the original repository as a remote:

cd asylum-dapp
git remote add upstream https://github.com/asylum-Labs/asylum-dapp.git

To build locally, copy the .env.sample file to a new .env file at the root of the repo and populate it with the appropriate environment values.

⚠️ NOTE: Only put sensitive data in .env files which are included in the .gitignore! DO NOT save sensitive data in .env.sample.

All work should be done on it's own branch. Once you are done working on a branch, create a pull request to merge it back into main.

When making a pull request, ensure that:

• All tests pass.
  • Fork testing requires environment variables to be set up in the forked repo.
• Code coverage remains the same or greater.
• All new code adheres to the style guide:
  • All lint checks pass
  • Code is thoroughly commented where relevant.
• If making a change to the contracts:
  • forge fmt and forge test pass.
  • Gas snapshots are provided and demonstrate an improvement (or an acceptable deficit given other improvements).
  • Reference contracts are modified correspondingly if relevant.
  • New tests are included for all new features or code paths.
• A descriptive summary of the PR has been provided.
• Assign reviewers to the PR and request a code review.
• Address any feedback or requested changes promptly.

In order to maintain high quality code that is easy to collaborate on, please make sure to stick to best practices. Expectations for code management are listed below.

• Always create a new branch from main for any new feature or bug fix.
• To avoid merge conflicts, each branch should only serve a single purpose.
• Use descriptive branch names that clearly indicate the purpose of the branch, such as:

`ui/integrate-ui-kit`
`feature/update-hedging-contracts`
`bugfix/fix-login-issue`

• Reviewers should provide constructive feedback and look for potential issues or improvements.
• Make sure to test the changes locally before approving the PR.
• Only approve PRs that meet our quality standards and follow our coding guidelines.

• Once the PR is approved and all checks pass, squash and merge into main.
  • Use squash and merge to keep the commit history clean (unless the branch contains logically distinct commits that should be preserved).

• Regularly pull the latest changes from main into your working branches to avoid conflicts.
• After merging a branch, delete it to keep the repo clean.
• Document any significant changes or new features in our project documentation (README.md and associated files).

• Commit Messages: Write clear and concise commit messages that accurately describe the changes made. Use the imperative mood and present tense (e.g., "Fix bug in user authentication").
• Coding Standards: Follow our coding standards and style guides to ensure consistency across the codebase. Refer to the project's documentation for specific guidelines.
• Testing: Write and maintain unit and integration tests for all new features and bug fixes. Ensure that all tests pass before submitting a pull request.
• Documentation: Keep the documentation up-to-date with any code changes. This includes comments within the code, as well as external documentation like the README.md and any additional guides.

Asylum Labs ❤️ gitmoji!

These guidelines apply to all code in the Asylum Labs codebase and this CONTRIBUTING.md file should accompany every repository in the organization.